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.