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

The Consumer Electronics Association (CEA) has released standard CEA-2018 on Task Model Descriptions (see http://www.ce.org/cea-2018. A task model is a formal description of the activities involved in completing a task, including both activities carried out by humans and those performed by machines. CEA-2018 defines the semantics and an XML notation for task models relevant to consumer electronics devices. CEA is requesting to assign the MIME type "application/cea-2018+xml" to Task Model Descriptions based on CEA-2018. See below for the registration request. Any comments/concerns are welcome. Thanks, Gottfried Zimmermann Editor of CEA-2018 PS: This registration request is a modification of a previous version http://www.alvestrand.no/pipermail/ietf-types/2007-December/001937.html which never got followed up. The new text has additional wording addressing possible security concerns about the inclusion of ECMAScript fragments in Task Model Descriptions. ----- 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. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023. Security considerations: All of the security considerations described in RFC 3023. Additionally, the inclusion of ECMAScript fragments (so-called "active content") in a CEA-2018 document bears risks in that a task-based application may execute malicious or erroneous ECMAScript code as part of a task model embedded condition or grounding statement. However, a task-based application will typically execute this code in sandbox and can thus prevent potential damage to local and other resources. Note that the embedded ECMAScript code fragments pose only minimal additional security risks for Web browsers since ECMAScript code is only embedded as content of XML elements other than <script>. The general utility of this media type to the Internet community is in the area of user interfaces for consumer electronics (and other areas of devices and services). Task models facilitate user interfaces that can be easier to use than traditional user interfaces. Task models can thus be discovered and shared over the Internet (and local home networks), and be uniquely identified as such by the receiving entity. Interoperability considerations: Same as interoperability considerations of text/xml as specified in RFC 3023. Published specification: CEA-2018 Applications that use this media type: Task-based applications, i.e. programs that interpret task model descriptions according to the semantics defined in CEA-2018. Additional information: Magic number(s): Same as magic number(s) of text/xml as specified in RFC 3023. File extension(s): .xml Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Gottfried Zimmermann <gzimmermann@acm.org> Intended usage: COMMON Restrictions on usage: none Author: CEA-2018 is a standard by the Consumer Electronics Association (CEA), and was edited by: Gottfried Zimmermann <gzimmermann@acm.org> Change controller: CEA R7 and its working group 12 have change control over CEA-2018.

* 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.
participants (2)
-
Bjoern Hoehrmann
-
Gottfried Zimmermann