Request for review of CEA Task Model Description media type:application/cea-2018+xml

[Martin Duerst]

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 at it.aoyama.ac.jp