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

John M Meredith John.Meredith at etsi.org
Tue Jul 8 16:14:55 CEST 2008


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


More information about the Ietf-types mailing list