Registration request for MIME media type tag 3gpp-ims+xml
This proposed registration is being distributed to this list (ietf-types@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
* John M Meredith wrote:
"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.
I am a bit confused by the use of "or" here, it sounds as if the naming of the parameter is unclear; perhaps it would be better to use "and". If the intent is to say that one may use one or the other, but not both at the same time, that should be said explicitly. Do I understand the first paragraph correctly, that the legal syntax and semantics of the parameters varies depending on the context where type and parameters are specified? If so, are there other registered types that have similar parameters?
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 ]
It seems incorrect to me to modify other specification's productions in a media type registration. Is the idea here simply to specify the legal syntax for the parameters? If so, it would be much better to just say what the legal parameter values are, and leave the rest to other speci- fications, so just something like sv-parameter-value = sv-value-list ... Permissable quote marks, placement of optional white space, and similar things as they are specified in the m-parameter production, are subject to higher level protocol specifications, and I believe existing ones do vary in how they encode the parameters and their values. -- 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/
Thanks for this rapid reaction, Bjoern. I will leave the technical response to the CT1 crowd. b/r John M -----Original Message----- From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] Sent: Tuesday, July 08, 2008 12:50 PM To: John M Meredith Cc: ietf-types@iana.org; georg.mayer@nokia.com; Frédéric Firmin; Andrew Allen; Atle Monrad; John-Luc Bakker Subject: Re: Registration request for MIME media type tag 3gpp-ims+xml * John M Meredith wrote:
"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.
I am a bit confused by the use of "or" here, it sounds as if the naming of the parameter is unclear; perhaps it would be better to use "and". If the intent is to say that one may use one or the other, but not both at the same time, that should be said explicitly. Do I understand the first paragraph correctly, that the legal syntax and semantics of the parameters varies depending on the context where type and parameters are specified? If so, are there other registered types that have similar parameters?
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 ]
It seems incorrect to me to modify other specification's productions in a media type registration. Is the idea here simply to specify the legal syntax for the parameters? If so, it would be much better to just say what the legal parameter values are, and leave the rest to other speci- fications, so just something like sv-parameter-value = sv-value-list ... Permissable quote marks, placement of optional white space, and similar things as they are specified in the m-parameter production, are subject to higher level protocol specifications, and I believe existing ones do vary in how they encode the parameters and their values. -- 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/
Hi Bjoern, Thank you for your quick response. 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. On your ABNF comment; I have no strong opinion on retaining the ABNF representing a modification to another specification's production. I have CC-ed someone who may have, however. Kind regards, John-Luc -----Original Message----- From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] Sent: Tuesday, July 08, 2008 5:50 AM To: John M Meredith Cc: ietf-types@iana.org; georg.mayer@nokia.com; Frederic Firmin; Andrew Allen; Atle Monrad; John-Luc Bakker Subject: Re: Registration request for MIME media type tag 3gpp-ims+xml * John M Meredith wrote:
"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.
I am a bit confused by the use of "or" here, it sounds as if the naming of the parameter is unclear; perhaps it would be better to use "and". If the intent is to say that one may use one or the other, but not both at the same time, that should be said explicitly. Do I understand the first paragraph correctly, that the legal syntax and semantics of the parameters varies depending on the context where type and parameters are specified? If so, are there other registered types that have similar parameters?
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 ]
It seems incorrect to me to modify other specification's productions in a media type registration. Is the idea here simply to specify the legal syntax for the parameters? If so, it would be much better to just say what the legal parameter values are, and leave the rest to other speci- fications, so just something like sv-parameter-value = sv-value-list ... Permissable quote marks, placement of optional white space, and similar things as they are specified in the m-parameter production, are subject to higher level protocol specifications, and I believe existing ones do vary in how they encode the parameters and their values. -- 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/ --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Hello all, This proposed registration is being re-distributed to this list (ietf-types@iana.org) for review, in accordance with the instructions given by Alexey Melnikov. Kind regards, John-Luc ============================ 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 is used to indicate: - the versions of the 3GPP IP multimedia (IM) Core Network (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" and schemaversion" parameters are absent, it shall be assumed that version 1 of the XML Schema for the IM CN subsystem XML body is supported. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 Security considerations: Same as general security considerations for application/xml as specified in section 10 of RFC 3023. In addition, this content type provides a format for exchanging information in SIP, so the security considerations from RFC 3261 apply. Interoperability considerations: Same as Interoperability considerations as specified in section 3.1 of RFC 3023. If both "sv" and "schemaversion" are specified, than the value of "schemaversion" MUST be ignored 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> and <http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-841.zip>. 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: COMMON Author/Change controller : 3GPP Specifications Manager via www.3gpp.org Technical contact: jbakker&rim.com ============================ -----Original Message----- From: John M Meredith [mailto:John.Meredith@etsi.org] Sent: Tuesday, July 08, 2008 4:01 AM [snip, snip] --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
participants (3)
-
Bjoern Hoehrmann -
John M Meredith -
John-Luc Bakker