Registration request for MIME media type tag 3gpp-ims+xml

[John-Luc Bakker]

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 at gmx.net] 
Sent: Tuesday, July 08, 2008 5:50 AM
To: John M Meredith
Cc: ietf-types at iana.org; georg.mayer at 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 at 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.