- Ietf-types - alvestrand.no

R: R: general question
by Santoni Adriano 09 Mar '09

09 Mar '09

Thank you, Adriano -----Messaggio originale----- Da: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Inviato: lunedì 9 marzo 2009 10.30 A: Santoni Adriano Cc: Roni Even; ietf-types(a)alvestrand.no Oggetto: Re: R: general question Santoni Adriano skrev: > Roni, > > thank you for replying. > >>> Are you asking if the media type registration need to be in the same > document as the payload specification > > Yes, exactly. > >>> Look in RFC 4855 ........ there it says that registration and the > payload specification can be different documents. > > Indeed, but some may argue that RFC4855 is related to the RTP > (Real-time Transport Protocol) case only. > > RFC 4288, which is mote general, seems to state the opposite at par. 4.10: > > "Proposals for media types registered in the standards tree by the > IETF itself MUST be published as RFCs." > There is plenty of cases where the Media Registration is done in one document and the specification of the format is in another. And the above rule you are citing is only saying that the media types registered by IETF needs to be published in an RFC. It doesn't put any requirement on them being the same. > So it is still not clear (to me) if RFC 4855 is an exception to the > general rule, or not. > >>> I am not sure that I know of such cases... > > I think you are right. After a closer examination of several cases, I > have always found a (sort of) media type registration in each of them. > > Again, I wonder if a media type can be registered after the payload > specification has been published; it may not always be clear, at the > payload specifications' publication time, that a corresponding new > media type is also needed. > So registration of media types for files etc can definitely be done later and in separate documents. See RFC 3839 when this is done for a format that is specified outside of IETF. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund(a)ericsson.com ----------------------------------------------------------------------

1 0

general question
by Santoni Adriano 09 Mar '09

09 Mar '09

Hello, I have the following doubt, and would like someone to enlighten me. Is it mandatory that a media type registration be included in the RFC that defines such media type? It seems to me, if I am not mistaken, that there are several media types defined in RFCs which does not contain an explicit media type registration.... TIA, Adriano

3 3

Registration of media type model/x3d+XXX (Revised 09.02.01)
by Leonard Daly 24 Feb '09

24 Feb '09

I wish to thank everyone for their comments on the proposed X3D MIME types (model/x3d+xxx). We have considered your comments and revised our submission based on those comments. All of the comments were concerned with the various subtypes. From our perspective, it seems that the consensus is to use x3d-vrml for the ClassicVRML encoding. x3d+xml. We have made that change. x3d+xml was acceptable from previous use. We made a change to the binary encoding. It was x3d+binary. After review of the other MIME types approved and that our encoding algorithm uses FastInfoSet compression, we have changed the MIME subtype for the binary encoding to x3d+fastinfoset. This appears to be compatible with the existing subtype of soap+fastinfoset (http://www.iana.org/assignments/media-types/application/soap+fastinfoset) Please note that the reference X3D specifications do not contain these revisions. The specifications will be updated after they are approved. Again we welcome comments and suggestions. Thank you, Leonard Daly X3D Working Group Co-Chair ------------------------------ Type name: model Subtype names: x3d-vrml x3d+xml x3d+fastinfoset Required parameters: None Optional parameters: None Encoding considerations: This application represents the different MIME types used for three different encodings of the X3D ISO standard (see [1]). The standard defines an abstract information structural representation, for which several file formats are available. These formats are currently defined to be: VRML-Classic: (old-style curly brace format of the VRML97 ISO standard). UTF-8 (8-bit text) is to be supported. The recently introduced UTF-8 BOM cannot be supported by definition of the specification. XML: Encoding requirements as per the XML standards. Binary: (Effectively a binary XML encoding scheme based on the outcome of the W3C binary XML working group process). Still a work in progress and standardisation is not yet complete. Each content type may have an addition Content-Encoding to indicate whether the content has been compressed using GZIP in addition to the basic textual encoding. This is also indicated by modifying each file extension with the character "z". For example, the plaintext VRML-encoded file format would use the extension ".x3dv", and if compressed using GZIP uses the extension ".x3dvz" Security considerations: Scripting is defined as being available for the specification. Two languages are defined: Java and ECMAScript. Each scripting language is controlled by its local security model. As the content may run in many different situations, the X3D specification does not impose specific security policies. For example, some standalone applications will want to directly interact with the local file system, network or database, while others that run in a web browser would use the web-browser's security model. Interoperability considerations: The definition of the file format is maintained by the Web3d Consortium (http://www.web3d.org) and published through the ISO process. Several revisions of the specification have been made and it continues to be made. All revisions use the same MIME type definitions, and are backwards compatible internally and structurally. In addition, each of the file format encodings may be losslessly transformed between each other. Published specification: All revisions of the X3D specification can be found here: http://www.web3d.org/x3d/specifications/ Several revisions of each specification exist. The abstract specification is ISO/IEC 19775:2004. The individual file formats, which also specify the matching MIME types, are parts of the ISO/IEC 19777 specification. Applications that use this media type: There are well over 20 - both browsers, exporters and importers. Additional information: Magic number(s): x3d-vrml: "#X3D" x3d+xml: Use XML's specification x3d+fastinfoset: "#X3D" File extension(s): x3d-vrml: .x3dv, .x3dvz x3d+xml: .x3d, .x3dz x3d+fastinfoset: .x3db Macintosh file type code(s): Person & email address to contact for further information: Leonard Daly (X3D Working Group Co-Chair) Leonard.Daly(a)realism.com Alan Hudson (Web3d Consortium President) giles(a)yumetech.com Intended usage: COMMON Restrictions on usage: None Author: The Web3D Consortium Change controller: The Web3D Consortium The X3D standard is a continuation of the VRML standard that is defined in RFC2077. As part of this work, several large modifications were made to the file format and specification. The basic premise for the specification continues the VRML philosophy. The MIME types and file extensions were changed to indicate this modified standard. ------------------------------ -- +-------- | Leonard Daly | Internet Solutions, eBusiness Specialist http://realism.com/ | LA ACM SIGGRAPH, Electronic Services Chair | X3D Book: http://x3dGraphics.com +------------------------------

3 3

Registration of media type application/vnd.emclient.accessrequest+xml
by Filip Navara 19 Feb '09

19 Feb '09

Type name: application Subtype name: Vendor Tree - vnd.emclient.accessrequest+xml Required parameters: none Optional parameters: version - in the X.Y notation where X specifies major version change and Y specifies minor version change. Applications supporting this MIME type should not try to process the content unless the major version number is recognize by the particular implementation. Encoding considerations: The content of this media type consists of lines of 7bit or 8bit text. In the latter case use of quoted-printable or base64 may be needed when operating over 7bit transports. Security considerations: The type exists to provide a limited and safe subset of operations to media authors, but the full spectrum of security issues associated with this type has not been completely assessed. Explicit actions based on the content should be done only after confirmation by the recepient. Embedding inside S/MIME container with digital signature is recommended. See RFC 3023, section 10 for a more complete analysis of XML related security issues. Interoperability considerations: There are no special known interoperability issues, but the full spectrum of interoperability issues associated with this type has not been completely assessed. Published specification: None. Applications that use this media type: eM Client IceWarp Mail Server Additional information: Magic number(s): File extension(s): Macintosh file type code(s): Person & email address to contact for further information: Filip Navara <navara(a)emclient.com> Libor Grafnetr <grafnetr(a)emclient.com> Intended usage: COMMON Restrictions on usage: None Author: Filip Navara, Libor Grafnetr Change controller: Filip Navara, Libor Grafnetr

2 1

Registration of media type application/schema+json
by Kris Zyp 19 Feb '09

19 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Type name: application Subtype name: schema+json Required parameters: Optional parameters: schema schema.items Encoding considerations: Encoded in application/json format Published specification: http://www.json-schema.org/ on-going efforts at: http://groups.google.com/group/json-schema Applications that use this media type: Persevere Python JSON Schema validator Dojo PHP schema validator Person & email address to contact for further information: Kris Zyp kris(a)sitepen.com Intended usage: COMMON Author: Kris Zyp Change controller: Kris Zyp - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmcoBkACgkQ9VpNnHc4zAw3xQCeNkLQIIj2Sy+z7UcpRGGBLdwu LAsAn0fL6dACjNINcfVMJPowSGX5Mtw1 =JjYd -----END PGP SIGNATURE-----

2 2

Media Type Registration request for POWDER and POWDER-S
by Phil Archer 22 Jan '09

22 Jan '09

To whom it may concern, This e-mail is sent in line with "How to Register an Internet Media Type for a W3C Spec" [1] and follows an earlier attempt to follow the IANA process (see 2, 3). Having taken advice [4], the W3C POWDER Working Group requests that consideration be given to registering two Media types for POWDER and POWDER-S documents. POWDER: application/powder+xml ============================== POWDER is a constrained dialect of XML that transports RDF properties and objects that can be associated with multiple subjects. The media type details are included in Appendix B of POWDER: Description Resources [5] which has just completed its (second) Last Call period. The version cited here includes changes made in response to last call comments and is not yet published, however, it is the one (or very close to the one) the working group will present as the Proposed Recommendation. It is anticipated that this happen within the next 2 weeks. The relevant section of the Description Resources document is as follows: Appendix B: POWDER Internet Media Type and Macintosh File Type The following Media Type has been submitted to the IESG for review, approval, and registration with IANA contact: Phil Archer or Matt Womer See also: How to Register a Media Type for a W3C Specification Internet Media Type registration, consistency of use TAG Finding 3 June 2002 (Revised 4 September 2002) The Internet Media Type / MIME Type for POWDER is "application/powder+xml". It is recommended that POWDER files use the file extension of .xml (all lowercase) on all platforms. It is recommended that POWDER files stored on Macintosh HFS file systems be given a file type of "TEXT". Type name: application Subtype name: powder+xml Required parameters: None Optional parameters: None Encoding considerations: Identical to those of "application/xml" as specified in [RFC3023], section 3.2. Security considerations: POWDER is used to make assertions, sometimes socially sensitive, about web resources. Consumers of POWDER should be aware of the source and chain of custody of this data. Security considerations for URIs (Section 7 of RFC 3986 [RFC3986]) and IRIs (Section 8 of RFC 3987 [RFC3987]) apply to the extent that describing resources in POWDER may prompt consumers to retrieve those resources. Interoperability considerations: There are no known interoperability issues. Published specification: http://www.w3.org/TR/powder-dr/ Applications which use this media type: No known applications currently use this media type. Additional information: Magic number(s): As specified for "application/xml" in RFC 3023 [RFC3023], section 3.2. File extension(s): .xml Fragment identifiers: Identical to that of "application/xml" as described in RFC 3023 [RFC3023], section 5. Base URI: As specified in RFC 3023 [RFC3023], section 6. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: public-powderwg(a)w3.org Intended usage: COMMON Restrictions on usage: None Author/Change controller: The POWDER specification is a work product of the World Wide Web Consortium's Protocol for Web Description Resources (POWDER) Working Group. The W3C has change control over these specifications. POWDER-S: application/powder-s+xml ================================== Semantic POWDER, or POWDER-S, is typically generated by performing a transformation on a POWDER document. Each POWDER-S document is an OWL ontology from which properties and values can be inferred for a given resource. In order for inferences to be drawn, however, OWL tools must implement a semantic extension (defined separately) and it is for this reason that a new media type is requested, rather than using the existing RDF/OWL media types. A POWDER-S document is valid RDF/OWL but is essentially meaningless without the semantic extension. The media type details are included in Appendix C of POWDER: Description Resources [5] as follows: Appendix C: POWDER-S Internet Media Type and Macintosh File Type The following Media Type has been submitted to the IESG for review, approval, and registration with IANA contact: Phil Archer or Matt Womer See also: How to Register a Media Type for a W3C Specification Internet Media Type registration, consistency of use TAG Finding 3 June 2002 (Revised 4 September 2002) The Internet Media Type / MIME Type for POWDER-S is "application/powder-s+xml". It is recommended that POWDER-S files use the file extension of .rdf (all lowercase) on all platforms. It is recommended that POWDER-S files stored on Macintosh HFS file systems be given a file type of "TEXT". Type name: application Subtype name: powder-s+xml Required parameters: None Optional parameters: None Encoding considerations: Identical to those of "application/xml" as specified in [RFC3023], section 3.2. Security considerations: POWDER-S is used to make assertions, sometimes socially sensitive, about web resources. Consumers of POWDER should-S be aware of the source and chain of custody of this data. Security considerations for URIs (Section 7 of RFC 3986 [RFC3986]) and IRIs (Section 8 of RFC 3987 [RFC3987]) apply to the extent that describing resources in POWDER-S may prompt consumers to retrieve those resources. Interoperability considerations: There are no known interoperability issues. Published specification: http://www.w3.org/TR/powder-dr/ Applications which use this media type: No known applications currently use this media type. Additional information: Magic number(s): As specified for "application/xml" in RFC 3023 [RFC3023], section 3.2. File extension(s): .rdf Fragment identifiers: Identical to that of "application/xml" as described in RFC 3023 [RFC3023], section 5. Base URI: As specified in RFC 3023 [RFC3023], section 6. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: public-powderwg(a)w3.org Intended usage: COMMON Restrictions on usage: None Author/Change controller: The POWDER-S specification is a work product of the World Wide Web Consortium's Protocol for Web Description Resources (POWDER) Working Group. The W3C has change control over these specifications. Please advise if there is any missing or incorrect information in this request. Yours faithfully Phil Archer POWDER WG Chair. [1] http://www.w3.org/2002/06/registering-mediatype [2] http://lists.w3.org/Archives/Public/public-powderwg/2008Dec/0001.html [3] http://lists.w3.org/Archives/Public/public-powderwg/2008Dec/0002.html [4] For example http://lists.w3.org/Archives/Public/public-powderwg/2008Dec/0026.html and http://lists.w3.org/Archives/Public/public-powderwg/2008Dec/0012.html [5] http://www.w3.org/2007/powder/Group/powder-dr/20081205.html -- Phil Archer w. http://philarcher.org/

2 2

Please review "application/richmedia+xml" and "application/richmediacommand+xml"
by Hall, Edward, VF-Group 18 Jan '09

18 Jan '09

Dear IETF Types list, I am writing to you as the OMA MCE Interim Chairman. We have recently approved the Rich Media Environment (RME) v1.0 as a candidate enabler at the OMA. As a result, we would like to socialise the registration of the associated MIME types for this specification. We would appreciate any comments you may have on this registration information. Please feel free to review the specification linked for further details about the use of these potential MIME types, or contact me (or the copied OMA List) directly. If you see any problems, please let us know. Many thanks, Eddy Hall Edward Hall Standards Engineer II&S, Vodafone Group Technology - R&D Mobile: +44 (0) 7717424404 E-mail: edward.hall(a)vodafone.com <mailto:edward.hall@vodafone.com> Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001 For RME Initial Scenes: Type name: application Subtype name: richmedia+xml Required parameters: none Optional parameters: charset useFullRequestHost pathComponents Encoding considerations: Same as for application/xml. See [7]RFC3023 , section 3.2. Security considerations: The media type defines a Rich Media scene viewed by an end user. It is possible for content to surge computational and memory resources from the receiver. Therefore user confirmation is recommended before consuming this media type. Interoperability considerations: none Published specification: OMA Rich Media Enabler Technical Specification The published enabler specification can be found at: http://www.openmobilealliance.org/Technical/release_program/rme_v1_0.asp x <blocked::http://www.openmobilealliance.org/Technical/release_program/rm e_v1_0.aspx> <blocked::http://member.openmobilealliance.org/ftp/public_documents/bt/M AE/Permanent_documents/OMA-TS-RME-V1_0-20071123-D.zip> Applications that use this media type: Applications implementing the Rich Media Enable Technical Specification. Typically these are rich media environments on mobile devices. Additional information: Magic number(s): None File extension(s): svg Macintosh file type code(s): None Person & email address to contact for further information: Edward Hall, Vodafone Group edward.hall(a)vodafone.com <blocked::mailto:edward.hall@vodafone.com> Intended usage: COMMON Restrictions on usage: none Author: The author of this specification is the Open Mobile Alliance working group Mobile Client Environment. See http://www.openmobilealliance.org/Technical/mobile_client_environ.aspx <blocked::http://www.openmobilealliance.org/Technical/mobile_client_envi ron.aspx> Change controller: Change control of this specification is done by the Open Mobile Alliance working group Mobile Client Environment. See http://www.openmobilealliance.org/Technical/mobile_client_environ.aspx <blocked::http://www.openmobilealliance.org/Technical/mobile_client_envi ron.aspx> For RME Commands: Type name: application Subtype name: richmediacommand+xml Required parameters: none Optional parameters: charset useFullRequestHost pathComponents Encoding considerations: Same as for application/xml. See [7]RFC3023 , section 3.2. Security considerations: The media type defines update commands to data viewed by an end user. Updates from an malicious source can perform harmful changes to the image viewed by the end user. A specific form of updates consists of scripts executed by the receiver of the media type. If the scripting language so permits access to data can be given allowing this data to be disclosed to unintended parties. It is also possible for content to surge computational and memory resources from the receiver. Therefore user confirmation is recommended before consuming this media type. Interoperability considerations: none Published specification: OMA Rich Media Enabler Technical Specification. The published enabler specification can be found at: http://www.openmobilealliance.org/Technical/release_program/rme_v1_0.asp x <blocked::http://www.openmobilealliance.org/Technical/release_program/rm e_v1_0.aspx> <blocked::http://member.openmobilealliance.org/ftp/public_documents/bt/M AE/Permanent_documents/OMA-TS-RME-V1_0-20071123-D.zip> Applications that use this media type: Applications implementing the Rich Media Enable Technical Specification. Typically these are rich media environments on mobile devices. Additional information: Magic number(s): None File extension(s): scg Macintosh file type code(s): None Person & email address to contact for further information: Edward Hall, Vodafone Group edward.hall(a)vodafone.com <blocked::mailto:edward.hall@vodafone.com> Intended usage: COMMON Restrictions on usage: none Author: The author of this specification is the Open Mobile Alliance working group Mobile Client Environment. See http://www.openmobilealliance.org/Technical/mobile_client_environ.aspx <blocked::http://www.openmobilealliance.org/Technical/mobile_client_envi ron.aspx> Change controller: Change control of this specification is done by the Open Mobile Alliance working group Mobile Client Environment. See http://www.openmobilealliance.org/Technical/mobile_client_environ.aspx <blocked::http://www.openmobilealliance.org/Technical/mobile_client_envi ron.aspx> Edward Hall Standards Engineer II&S, Vodafone Group Technology - R&D Mobile: +44 (0) 7717424404 E-mail: edward.hall(a)vodafone.com <mailto:edward.hall@vodafone.com> Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001

2 1

Registration of media type audio/vnd.dvb.file and video/vnd.dvb.file
by Stefan Döhla 16 Jan '09

16 Jan '09

Dear members of ietf-types, attached is a copy of the MIME type as already defined within the DVB File Format specification that is publicly available as http://www.dvb.org/technology/standards/a121.tm3904r3.ff0020r12.DVB_File_Fo… The following text was copied from the specification with the single change of contact information (Eoghan O'sullivan took over the responsibilities of Peter MacAvock). Best Regards - Stefan Doehla == DVB Files with audio but no visual content The type "audio/vnd.dvb.file" may be used for files that contain no other tracks than audio tracks. Type name: audio Subtype name: vnd.dvb.file Required parameters: none Optional parameters: codecs: is a single value or a comma-separated list that identifies the codec(s) needed for rendering the content contained (in tracks) of a file. The codecs parameter is defined in RFC 4281 [19]. The ISO file format name space and ISO syntax in clauses 3.2 and 3.3 of RFC 4281 [19], respectively, shall be used. protected-content: is value '1' if some or all of the media data in the file is protected, otherwise '0'. brands: is a field which contains a textual representation of the file type box of the DVB File. It consists of dot-separated elements, enclosed in double quotes. The first element is the major brand as a printable four-character code, followed by the second element, which is the minor version of the major brand. The following elements are the compatible brands of the file as printable four-character codes. Example: brands="dvt1.0.iso3" Encoding considerations: files are binary and should be transmitted in a suitable encoding without CR/LF conversion, 7-bit stripping etc.; base64 (RFC 4648 [21]) is a suitable encoding. Security considerations: DVB files may contain audio, video, displayable text data images, ESG metadata, etc. Clearly it is possible to author malicious files which attempt to call for e.g., an excessively large picture size, high-sampling rate audio, etc. However, clients can and usually do protect themselves against this kind of attack. It should be noted that the file may contain fields that encompass information partly intended to protect media against unauthorized use or distribution. In this case, the intention is that alteration or removal of the data in these fields would be treated as an offense under national agreements based on World Intellectual Property Organization (WIPO) treaties. Interoperability considerations: DVB has defined this specification. Interoperability considerations will be in the corresponding Implementation Guidelines document. Published specification: Applications which use this media type: Multi-media Additional information: The type "audio/vnd.dvb.file" may be used for files containing audio but no visual presentation. Files served under this type must not contain any visual material. (Note that timed text is visually presented and is considered to be visual material). Magic number(s): None. However, the file type box must occur first in the file, and must have a DVB brand as the major brand. File extension(s): 'dvb' Macintosh File Type Code(s): none Person & email address to contact for further information: Eoghan O'sullivan Digital Video Broadcasting (DVB) osullivan(a)dvb.org Intended usage: COMMON Restrictions on usage: Note that this MIME type is used only for files; separate types are used for real-time transfer, such as for the RTP payload formats. Authors: Members of the Digital Video Broadcasting Project - Technical Module File Format (DVB TM-FF). Change controller: DVB TM / DVB TM-FF == Any DVB Files The type "video/vnd.dvb.file" is valid for all files, including files that contain audio tracks only. It is valid to serve an audio-only file as "video/vnd.dvb.file". Type name: video Subtype name: vnd.dvb.file Required parameters: none Optional parameters: codecs: is a single value or a comma-separated list that identifies the codec(s) needed for rendering the content contained (in tracks) of a file. The codecs parameter is defined in RFC 4281 [19]. The ISO file format name space and ISO syntax in clauses 3.2 and 3.3 of RFC 4281 [19], respectively, shall be used. protected-content: is value '1' if some or all of the media data in the file is protected, otherwise '0'. brands: is a field which contains a textual representation of the file type box of the DVB File. It consists of dot-separated elements, enclosed in double quotes. The first element is the major brand as a printable four-character code, followed by the second element, which is the minor version of the major brand in decimal representation. The following elements are the compatible brands of the file as printable four-character codes. Example: brands="dvt1.0.iso3" Encoding considerations: files are binary and should be transmitted in a suitable encoding without CR/LF conversion, 7-bit stripping etc.; base64 (RFC 4648 [21]) is a suitable encoding. Security considerations: DVB files may contain audio, video, displayable text data images, ESG metadata, etc. Clearly it is possible to author malicious files which attempt to call for e.g., an excessively large picture size, high-sampling rate audio, etc. However, clients can and usually do protect themselves against this kind of attack. It should be noted that the file may contain fields that encompass information partly intended to protect media against unauthorized use or distribution. In this case, the intention is that alteration or removal of the data in these fields would be treated as an offense under national agreements based on World Intellectual Property Organization (WIPO) treaties. Interoperability considerations: DVB has defined this specification. Interoperability considerations will be in the corresponding Implementation Guidelines document. Published specification: Applications which use this media type: Multi-media Additional information: Magic number(s): None. However, the file type box must occur first in the file, and must have a DVB brand as the major brand. File extension(s): 'dvb' Macintosh File Type Code(s): none Person & email address to contact for further information: Eoghan O'sullivan Digital Video Broadcasting (DVB) osullivan(a)dvb.org Intended usage: COMMON Restrictions on usage: Note that this MIME type is used only for files; separate types are used for real-time transfer, such as for the RTP payload formats. Authors: Members of the Digital Video Broadcasting Project - Technical Module File Format (DVB TM-FF). Change controller: DVB TM / DVB TM-FF -- Dipl.-Ing. Stefan Döhla | Email: stefan.doehla(a)iis.fraunhofer.de Multimedia Transport | Phone: +49 (0)9131 776 6042 (!NEW!) Audio Department | Fax: +49 (0)9131 776 6099 (!NEW!) Fraunhofer IIS | Am Wolfmantel 33 | 91058 Erlangen, Germany | Web: http://www.iis.fraunhofer.de/amm

2 1

Please review "application/richmedia+xml" and "application/richmediacommand+xml"
by Hall, Edward, VF-Group 09 Jan '09

09 Jan '09

Dear IETF Types list, I am forwarding an email I believe I sent to the wrong list! Sorry, Eddy ________________________________ From: Hall, Edward, VF-Group Sent: 09 January 2009 15:38 To: ietf-types(a)iana.org Cc: OMA-MCE(a)MAIL.OPENMOBILEALLIANCE.ORG Subject: Please review "application/richmedia+xml" and "application/richmediacommand+xml" Dear IETF Types list, I am writing to you as the OMA MCE Interim Chairman. We have recently approved the Rich Media Environment (RME) v1.0 as a candidate enabler at the OMA. As a result, we would like to socialise the registration of the associated MIME types for this specification. We would appreciate any comments you may have on this registration information. Please feel free to review the specification linked for further details about the use of these potential MIME types, or contact me (or the copied OMA List) directly. If you see any problems, please let us know. Many thanks, Eddy Hall Edward Hall Standards Engineer II&S, Vodafone Group Technology - R&D Mobile: +44 (0) 7717424404 E-mail: edward.hall(a)vodafone.com <mailto:edward.hall@vodafone.com> Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001 For RME Initial Scenes: Type name: application Subtype name: richmedia+xml Required parameters: none Optional parameters: charset useFullRequestHost pathComponents Encoding considerations: Same as for application/xml. See [7]RFC3023 , section 3.2. Security considerations: The media type defines a Rich Media scene viewed by an end user. It is possible for content to surge computational and memory resources from the receiver. Therefore user confirmation is recommended before consuming this media type. Interoperability considerations: none Published specification: OMA Rich Media Enabler Technical Specification The published enabler specification can be found at: http://www.openmobilealliance.org/Technical/release_program/rme_v1_0.asp x <blocked::http://www.openmobilealliance.org/Technical/release_program/rm e_v1_0.aspx> <blocked::http://member.openmobilealliance.org/ftp/public_documents/bt/M AE/Permanent_documents/OMA-TS-RME-V1_0-20071123-D.zip> Applications that use this media type: Applications implementing the Rich Media Enable Technical Specification. Typically these are rich media environments on mobile devices. Additional information: Magic number(s): None File extension(s): svg Macintosh file type code(s): None Person & email address to contact for further information: Edward Hall, Vodafone Group edward.hall(a)vodafone.com <blocked::mailto:edward.hall@vodafone.com> Intended usage: COMMON Restrictions on usage: none Author: The author of this specification is the Open Mobile Alliance working group Mobile Client Environment. See http://www.openmobilealliance.org/Technical/mobile_client_environ.aspx <blocked::http://www.openmobilealliance.org/Technical/mobile_client_envi ron.aspx> Change controller: Change control of this specification is done by the Open Mobile Alliance working group Mobile Client Environment. See http://www.openmobilealliance.org/Technical/mobile_client_environ.aspx <blocked::http://www.openmobilealliance.org/Technical/mobile_client_envi ron.aspx> For RME Commands: Type name: application Subtype name: richmediacommand+xml Required parameters: none Optional parameters: charset useFullRequestHost pathComponents Encoding considerations: Same as for application/xml. See [7]RFC3023 , section 3.2. Security considerations: The media type defines update commands to data viewed by an end user. Updates from an malicious source can perform harmful changes to the image viewed by the end user. A specific form of updates consists of scripts executed by the receiver of the media type. If the scripting language so permits access to data can be given allowing this data to be disclosed to unintended parties. It is also possible for content to surge computational and memory resources from the receiver. Therefore user confirmation is recommended before consuming this media type. Interoperability considerations: none Published specification: OMA Rich Media Enabler Technical Specification. The published enabler specification can be found at: http://www.openmobilealliance.org/Technical/release_program/rme_v1_0.asp x <blocked::http://www.openmobilealliance.org/Technical/release_program/rm e_v1_0.aspx> <blocked::http://member.openmobilealliance.org/ftp/public_documents/bt/M AE/Permanent_documents/OMA-TS-RME-V1_0-20071123-D.zip> Applications that use this media type: Applications implementing the Rich Media Enable Technical Specification. Typically these are rich media environments on mobile devices. Additional information: Magic number(s): None File extension(s): scg Macintosh file type code(s): None Person & email address to contact for further information: Edward Hall, Vodafone Group edward.hall(a)vodafone.com <blocked::mailto:edward.hall@vodafone.com> Intended usage: COMMON Restrictions on usage: none Author: The author of this specification is the Open Mobile Alliance working group Mobile Client Environment. See http://www.openmobilealliance.org/Technical/mobile_client_environ.aspx <blocked::http://www.openmobilealliance.org/Technical/mobile_client_envi ron.aspx> Change controller: Change control of this specification is done by the Open Mobile Alliance working group Mobile Client Environment. See http://www.openmobilealliance.org/Technical/mobile_client_environ.aspx <blocked::http://www.openmobilealliance.org/Technical/mobile_client_envi ron.aspx> Edward Hall Standards Engineer II&S, Vodafone Group Technology - R&D Mobile: +44 (0) 7717424404 E-mail: edward.hall(a)vodafone.com <mailto:edward.hall@vodafone.com> Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001

1 0

please review "text/owl-functional" and "application/owl+xml"
by Sandro Hawke 06 Jan '09

06 Jan '09

The following two media type registrations are currently published, each as part a of W3C Last Call Working Draft ([1] [2]), and will soon be submitted to the IESG for review, approval, and registration with IANA (as per [3]). At this point, we would appreciate comments on this registration information. If you see any problems, please let us know; I'll act as a liason between these IETF lists and the W3C Working Group responsible for these specifications. -- Sandro [1] http://www.w3.org/TR/owl2-syntax/#Appendix:_Internet_Media_Type.2C_File_Ext… [2] http://www.w3.org/TR/owl2-xml-serialization/#Appendix:_Internet_Media_Type.… [3] http://www.w3.org/2002/06/registering-mediatype ================================================================ Type name text Subtype name owl-functional Required parameters None Optional parameters charset This parameter may be required when transfering non-ASCII data across some protocols. If present, the value of charset should be UTF-8. Encoding considerations The syntax of the OWL functional-style Syntax is expressed over code points in Unicode [UNICODE]. The encoding should be UTF-8 [RFC3629], but other encodings are allowed. [[ UNICODE: The Unicode Standard Version 3.0, Addison Wesley, Reading MA, 2000, ISBN: 0-201-61633-5, http://www.unicode.org/unicode/standard/standard.html ]] Security considerations The OWL functional-style Syntax uses IRIs as term identifiers. Applications interpreting data expressed in the OWL functional-style Syntax should address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifiers (URI): Generic Syntax [RFC3986] Section 7. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "o" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER E WITH ACUTE). Any person or application that is writing or interpreting data in the OWL functional-style Syntax must take care to use the IRI that matches the intended semantics, and avoid IRIs that may look similar. Further information about matching of similar characters can be found in Unicode Security Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8. [[ UNISEC: Unicode Security Considerations, Mark Davis and Michel Suignard, July 2008, http://www.unicode.org/reports/tr36/ ]] Interoperability considerations There are no known interoperability issues. Published specification This specification. [[ http://www.w3.org/TR/owl2-syntax/ ]] Applications which use this media type No widely deployed applications are known to currently use this media type. It is expected that OWL tools will use this media type in the future. Additional information None. Magic number(s) OWL functional-style Syntax documents may have the strings 'Namespace:' or 'Ontology:' (case dependent) near the beginning of the document. File extension(s) ".ofn" Base IRI There are no constructs in the OWL functional-style Syntax to change the Base IRI. Macintosh file type code(s) "TEXT" Person & email address to contact for further information Sandro Hawke <sandro(a)w3.org> Intended usage COMMON Restrictions on usage None Author/Change controller The OWL functional-style Syntax is the product of the W3C OWL Working Group; W3C reserves change control over this specification. ================================================================ Type name application Subtype name owl+xml Required parameters None Optional parameters charset This parameter may be required when transfering non-ascii data across some protocols. Encoding considerations The syntax of the OWL XML Serialization is expressed over code points in Unicode [UNICODE]. [[ UNICODE: The Unicode Standard Version 3.0, Addison Wesley, Reading MA, 2000, ISBN: 0-201-61633-5, http://www.unicode.org/unicode/standard/standard.html ]] Security considerations The OWL XML Serialization uses IRIs as term identifiers. Applications interpreting data expressed in the OWL XML Serialization should address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifiers (URI): Generic Syntax [RFC3986] Section 7. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "o" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER E WITH ACUTE). Any person or application that is writing or interpreting data in the OWL XML Serialization must take care to use the IRI that matches the intended semantics, and avoid IRIs that may look similar. Further information about matching of similar characters can be found in Unicode Security Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8. [[ UNISEC: Unicode Security Considerations, Mark Davis and Michel Suignard, July 2008, http://www.unicode.org/reports/tr36/ ]] Interoperability considerations There are no known interoperability issues. Published specification This specification. [[ http://www.w3.org/TR/owl2-xml-serialization/ ]] Applications which use this media type None at current time. Additional information None. Magic number(s) OWL XML documents are XML documents and thus may have initial strings similar to any XML document. File extension(s) ".owx" Base URI As in XML. Macintosh file type code(s) "TEXT" Person & email address to contact for further information Sandro Hawke <sandro(a)w3.org> Intended usage COMMON Restrictions on usage None Author/Change controller The OWL XML Serialization is the product of the W3C OWL Working Group; W3C reserves change control over this specification.

2 1