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