Bjoern, Martin, thanks for your review. It sounds like both options (with or without optional charset parameter) should be acceptable since UTF-8 is the required encoding. BTW, there is already an application/*+xml registration that does not have a charset parameter: application/oebps-package+xml, see http://www.ietf.org/rfc/rfc4839.txt. This one allows two encoding: UTF-8 and UTF-16. Regards, Gottfried
-----Original Message----- From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] Sent: Thursday, July 31, 2008 3:57 AM To: Bjoern Hoehrmann; gzimmermann@acm.org Cc: ietf-types@iana.org; iesg@ietf.org; 'Charles Rich'; 'Leslie King' Subject: Re: Request for review of CEA Task Model Description media type:application/cea-2018+xml
I'm not sure I agree fully with Bjoern. If you have something like Content-Type: application/cea-2018+xml;charset=example then that's simply an error as per the registration. There is no need that erroneous content behave the same on all implementations; garbage in means garbage out.
Regards, Martin.
At 20:35 08/07/30, Bjoern Hoehrmann wrote:
* Gottfried Zimmermann wrote:
The Consumer Electronics Association (CEA) has released standard CEA-2018 on Task Model Descriptions (see http://www.ce.org/cea-2018.
Registration Request:
Type name: application
Subtype name: cea-2018+xml
Required parameters: none
Optional parameters: none
Note that (in contrast to application/xml) no charset parameter is defined since CEA-2018 specifies UTF-8 as the required file format.
I do not think this is a valid reason to omit the charset parameter. Do note that including the charset parameter is a SHOULD-level requirement of RFC 3023 for +xml types. If you truly need to omit the parameter, it would be better to omit the +xml from the name.
The reason is that, if you actually have a `application/cea-2018+xml; charset=example` resource a tool with no knowledge of the specific type it would consider it to be in the `example` encoding, whereas CEA-2018 applications would probably ignore the parameter and assume UTF-8.
A better solution would be to have an optional charset parameter and e.g. require consumers of the type to reject content that specifies the parameter with a value indicating some other encoding than UTF-8, or whatever is done with entites that have a non-UTF-8 BOM or XML encoding declaration.
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp