February 2009 - Ietf-types

Registration request for MIME media type tag 3gpp-ims+xml
by John M Meredith 21 May '09

21 May '09

This proposed registration is being distributed to this list (ietf-types(a)iana.org) for preliminary review, in accordance with the instructions given by IANA. It is cc'ed, as suggested by IANA, to Chris Newman. It is also cc'ed to 3GPP delegates to TSG CT WG1 (http://www.3gpp.org/tb/home.htm, http://www.3gpp.org/tb/CT/CT1/CT1.htm) who have a technical interest in the matter. Best regards John M Meredith 3GPP Specifications Manager, ETSI ======================================================================== ======================================== > Name : John M Meredith (3GPP Specifications Manager) > Email : john.meredith&etsi.org > > > MIME media type name: > Application > > MIME subtype name: > 3gpp-ims+xml > > Required parameters: > None > > Optional parameters: > "charset" the parameter has identical semantics to the charset > parameter of the "application/xml" media type as specified in RFC > 3023 [132]. > "sv" or "schemaversion" the parameter's value is used to indicate: > - the versions of the 3GPP IM CN Subsystem XML schema that can be > used to validate the 3GPP IM CN subsystem XML body (if the MIME > type and parameter are present in the Content-Type header) or > - the accepted versions of the 3GPP IM CN Subsystem XML body (if the > MIME type and parameter are present in the Accept header). > > If the "sv" or "schemaversion" parameter is absent, it shall be > assumed that version 1 of the XML Schema for the IM CN subsystem > XML body is supported. > > This registration entry includes ABNF that modifies the m-parameter > definition in RFC 3261 [26]. m-parameter allows for > attribute/value pairs that are applicable to the media range. In > particular, the ABNF below is given for a media range > application/3gpp-ims+xml specific m-parameter. > > m-parameter /= ("sv" / "schemaversion") EQUAL LDQUOT [ sv-value- > list ] RDQUOT > sv-value-list = sv-value-range *( "," sv-value ) sv-value-range = > sv-value [ "-" sv-value ] > sv-value = number / token > number = 1*DIGIT [ "." 1*DIGIT ] > > Encoding considerations: > Same as encoding considerations of application/xml as specified in RFC > 3023 [132] > > Security considerations: > 3GPP has defined mechanisms for ensuring the privacy and integrity > protection of the bodies of SIP messages used in the 3GPP IM CN > Subsystem. > > Interoperability considerations: > This content type provides a format for exchanging information in SIP > Requests and Responses and used within the 3GPP IM CN Subsystem. > > Published specification: > ETSI TS 124 229 version 8.4.1, being a formal transposition of 3GPP TS 24.229 version 8.4.1: > "Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session > Description Protocol (SDP); Stage 3" > > Available via http://pda.etsi.org/pda/home.asp?wkr=RTS/TSGC-0124229v841 (http://www.3gpp.org/ftp/Specs/html-info/24229.htm) > > Applications which use this media: > Applications that use the 3GPP IM CN Subsystem as defined by 3GPP. > > Additional information : > > 1. Magic number(s) : none > 2. File extension(s) : none > 3. Macintosh file type code : none > 4. Object Identifiers: none > > Application submitted on behalf of the Organizational Partners of > 3GPP. > > Person to contact for further information : > > 1. Name : John M Meredith, 3GPP Specifications Manager > 2. Email : john.meredith&etsi.org > > > Intended usage: > This content type provides a format for exchanging information in SIP > Requests and Responses as used within the 3GPP IM CN Subsystem. > > Author/Change controller : 3GPP Specifications Manager via > www.3gpp.org > Technical contact: jbakker&rim.com >

3 4

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