Re: [ietf-types] Registration of media type application/vcard+xml

[Chris Lilley <[e-mail]>]

On Thursday, April 7, 2011, 10:12:00 PM, Bjoern wrote:

BH> * Simon Perreault wrote:
>>   Type name:  application

>>   Subtype name:  vcard+xml

>>   Required parameters:  none

>>   Optional parameters:  none

BH> If you do not specify an optional 'charset' parameter, it is ambiguous
BH> what the encoding of `application/vcard+xml;charset=...` is; 

Or not; the XML specification amply covers how to determine the encoding of an XML document.

BH> if you only
BH> read the registration you are likely to ignore the parameter, 

The registration says there is no such parameter. Nor is it required for the application/* tree.

BH> while, if
BH> you read RFC 3023 you expect the 'charset' parameter to specify the en-
BH> coding, which has interoperability and security implications.

Considerations which don't arise if there is no such parameter, such as in this registration request.

Which is why the Technical Architecture group recommends against such use:
  "a receiving application can, with very high reliability, determine the encoding of an XML document by reading it, without reference to any external headers "

and

  "Thus there is no ambiguity when the charset is omitted, and the STRONGLY RECOMMENDED injunction to use the charset is misplaced for application/xml and for non-text "+xml" types."

http://www.w3.org/2001/tag/2002/0129-mime#char-encoding


BH> If this omission of the parameter is not an oversight, I would expect a
BH> rationale for its omission as part of the review request and expect the
BH> interoperability and security issues that arise from this to be noted in
BH> the specification.

Perhaps you can point to which part of the Internet Media types registration process *requires* a charset parameter for the application/* tree and why adding one would be a good idea when, as you point out, adding a charset parameter and expecting it to overide the encoding declared in the XML instance has poor interoperability and raises security worries as well.

In other words, I strongly suspect that the 'omission' of this problematic parameter is not an oversight but a rational technical decision.

(Omitting comments with which I agree).

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups