July 2008 - Ietf-types - alvestrand.no

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

Re: Request for review of InkML media type: application/inkml+xml
by Frank Ellermann 25 Aug '08

25 Aug '08

Kazuyuki Ashimura wrote: > the security issues of RFC1738, section 6, should be considered. Please s/RFC1738, section 6/RFC3986, section 7/ if you have no special reasons to use the almost completely obsolete RFC 1738. > Published specification: > ------------------------- > > This media type registration is for InkML documents as described > by this specification. IMO you need a reference for "this" specification, IANA publishes only your registration template, where "this" would make no sense. Frank

2 2

Request for review of media sub-type registration request
by Tim Moses 19 Aug '08

19 Aug '08

Colleagues - The attached draft contains a request for registration of a media sub-type and an XML namespace. I would very much welcome your guidance on the completeness and correctness of the information it provides prior to formal submission of the draft and the registration request. Thank you for your help. All the best. Tim. Tim Moses +1 613 270 3183

3 4

Re: Request for review of CEA Task Model Description media type:application/cea-2018+xml
by Martin Duerst 31 Jul '08

31 Jul '08

I'm not sure I agree fully with Bjoern. If you have something like Content-Type: application/cea-2018+xml;charset=example then that's simply an error as per the registration. There is no need that erroneous content behave the same on all implementations; garbage in means garbage out. Regards, Martin. At 20:35 08/07/30, Bjoern Hoehrmann wrote: >* Gottfried Zimmermann wrote: >>The Consumer Electronics Association (CEA) has released standard CEA-2018 on >>Task Model Descriptions (see http://www.ce.org/cea-2018. > >>Registration Request: >> >>Type name: application >> >>Subtype name: cea-2018+xml >> >>Required parameters: none >> >>Optional parameters: none >> >> Note that (in contrast to application/xml) no charset parameter is >>defined since CEA-2018 specifies UTF-8 as the required file format. > >I do not think this is a valid reason to omit the charset parameter. Do >note that including the charset parameter is a SHOULD-level requirement >of RFC 3023 for +xml types. If you truly need to omit the parameter, it >would be better to omit the +xml from the name. > >The reason is that, if you actually have a `application/cea-2018+xml; >charset=example` resource a tool with no knowledge of the specific type >it would consider it to be in the `example` encoding, whereas CEA-2018 >applications would probably ignore the parameter and assume UTF-8. > >A better solution would be to have an optional charset parameter and >e.g. require consumers of the type to reject content that specifies the >parameter with a value indicating some other encoding than UTF-8, or >whatever is done with entites that have a non-UTF-8 BOM or XML encoding >declaration. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp

2 1

RE: [IANA #178083] Registration request for MIME media type tag 3gpp-ims+xml
by John M Meredith 30 Jul '08

30 Jul '08

Dear IESG Following the instructions provided by IANA's Amanda Baber (below) and successful resolution of all comments raised in response to the original posting to ietf-types(a)iana.org on 8 July 2008, I am pleased to request formal registration of MIME media type tag 3gpp-ims+xml (agreed details immediately below). Thanks to all contributors. John M Meredith 3GPP Specifications Manager ETSI ======================================================================== ================================= 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. "sv" or "schemaversion" the parameter's value indicates versions corresponding to 3GPP IM CN Subsystem XML schema documents as specified in 3GPP TS 24.228. 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: 3GPP TS 24.229 version 8.4.1: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), stage 3" Available via http://www.3gpp.org/specs/numbering.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 ======================================================================== ================================= -----Original Message----- From: Amanda Baber via RT [mailto:iana-questions@icann.org] Sent: Monday, July 07, 2008 7:26 PM To: John M Meredith Subject: [IANA #178083] Registration request for MIME media type tag 3gpp-ims+xml Dear John, IANA is unable to process requests for media type registrations in the standards tree. Standards tree registrations must instead be submitted directly to the IESG, which will instruct us to add them to the registry upon approval. Standards tree applicants should follow these steps, as outlined by Applications Area Director Chris Newman: * Write registration that complies with mandatory features of RFC 4288. <http://tools.ietf.org/html/rfc4288#section-4> * Post registration form on ietf-types(a)iana.org list for preliminary review. <http://www.alvestrand.no/mailman/listinfo/ietf-types> <http://tools.ietf.org/html/rfc4288#section-5.1> * Respond to review comments and re-post as necessary. * Send an email to iesg(a)ietf.org pointing to the final version of the registration template, and preferably pointing to the review posting in the ietf-types archive. You may also wish to contact Chris Newman directly at chris.newman(a)sun.com. Best regards, Amanda Baber Internet Assigned Numbers Authority (IANA) On Mon Jul 07 13:18:30 2008, John.Meredith(a)etsi.org wrote: > Name : John M Meredith > 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: > 3GPP TS 24.229 version 8.4.1: "IP multimedia call control protocol > based on Session Initiation Protocol (SIP) and Session Description > Protocol (SDP), stage 3" > > Available via http://www.3gpp.org/specs/numbering.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 >

1 0

Re: Registration request for MIME media type tag 3gpp-ims+xml
by Bjoern Hoehrmann 30 Jul '08

30 Jul '08

* John-Luc Bakker wrote: >In SIP, use of the accept header field and the content-type header >field provides open and extensible data typing and type negotiation > >The Accept header field (RFC 3261, section 20.1) of a SIP request >indicates the formats accepted by the SIP UAC. MIME media type and their >parameters can be listed in the Accept header for that purpose. Thus, >what the SIP UAC is indicating are the variations of the MIME type (i.e. >application/3gpp-ims+xml) that are accepted. > >The Content-Type header field (RFC 3261, section 20.15) can be found in >a SIP response and request and indicates the MIME media type of the SIP >message-body. MIME media type and their parameters can be listed in the >Content-Type header field for that purpose. Thus, it provides a hint to >the recipient as to how to decode the material and, in particular in the >case of "application/3gpp-ims+xml", which schema to validate the body >against. > >The semantics of the parameter are those of the header field the >parameter is placed in. Thanks, I see now where my confusion is coming from. From my perspective the semantics of the parameter and its value are the same in both cases, and was under the impression that, as an example, you can specify ranges in the parameter when used in 'Accept' and must specify a single version in the 'Content-Type' parameter. I think it would be preferable if this could be reworded to avoid this confusion; but I can't immediately offer better text, other than some- thing more unspecific ala "Indicates relevant 3GPP IM CN Subsystem XML versions (e.g., that an implementation or document conforms to)" which I am not sure you would find an improvement. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

2 2

Request for review of CEA Task Model Description media type: application/cea-2018+xml
by Gottfried Zimmermann 30 Jul '08

30 Jul '08

The Consumer Electronics Association (CEA) has released standard CEA-2018 on Task Model Descriptions (see http://www.ce.org/cea-2018. A task model is a formal description of the activities involved in completing a task, including both activities carried out by humans and those performed by machines. CEA-2018 defines the semantics and an XML notation for task models relevant to consumer electronics devices. CEA is requesting to assign the MIME type "application/cea-2018+xml" to Task Model Descriptions based on CEA-2018. See below for the registration request. Any comments/concerns are welcome. Thanks, Gottfried Zimmermann Editor of CEA-2018 PS: This registration request is a modification of a previous version http://www.alvestrand.no/pipermail/ietf-types/2007-December/001937.html which never got followed up. The new text has additional wording addressing possible security concerns about the inclusion of ECMAScript fragments in Task Model Descriptions. ----- Registration Request: Type name: application Subtype name: cea-2018+xml Required parameters: none Optional parameters: none Note that (in contrast to application/xml) no charset parameter is defined since CEA-2018 specifies UTF-8 as the required file format. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023. Security considerations: All of the security considerations described in RFC 3023. Additionally, the inclusion of ECMAScript fragments (so-called "active content") in a CEA-2018 document bears risks in that a task-based application may execute malicious or erroneous ECMAScript code as part of a task model embedded condition or grounding statement. However, a task-based application will typically execute this code in sandbox and can thus prevent potential damage to local and other resources. Note that the embedded ECMAScript code fragments pose only minimal additional security risks for Web browsers since ECMAScript code is only embedded as content of XML elements other than <script>. The general utility of this media type to the Internet community is in the area of user interfaces for consumer electronics (and other areas of devices and services). Task models facilitate user interfaces that can be easier to use than traditional user interfaces. Task models can thus be discovered and shared over the Internet (and local home networks), and be uniquely identified as such by the receiving entity. Interoperability considerations: Same as interoperability considerations of text/xml as specified in RFC 3023. Published specification: CEA-2018 Applications that use this media type: Task-based applications, i.e. programs that interpret task model descriptions according to the semantics defined in CEA-2018. Additional information: Magic number(s): Same as magic number(s) of text/xml as specified in RFC 3023. File extension(s): .xml Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Gottfried Zimmermann <gzimmermann(a)acm.org> Intended usage: COMMON Restrictions on usage: none Author: CEA-2018 is a standard by the Consumer Electronics Association (CEA), and was edited by: Gottfried Zimmermann <gzimmermann(a)acm.org> Change controller: CEA R7 and its working group 12 have change control over CEA-2018.

2 1