Request for review of CEA Task Model Description media type:application/cea-2018+xml
duerst at it.aoyama.ac.jp
Thu Jul 31 03:57:20 CEST 2008
I'm not sure I agree fully with Bjoern. If you have something like
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.
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.
>>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
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
More information about the Ietf-types