MIME Type Review Request: text/CSTA-type

[Onno Elzinga]

Dear reviewers,

Thanks for your constructive feedback.

Task Group 11 has reviewed your comments and agrees that both MIME types are meant for machines. Therefore they propose to change the second MIME type from "text/CSTA-types" to "application/CSTAdata+xml".

Hope this helps. 
We are meeting all week, so we would appreciate your speedy feedback.

Thanks,
Onno.


-----Original Message-----
From: Bruce Lilly [mailto:blilly at erols.com]
Sent: Saturday, November 06, 2004 6:22 PM
To: ietf-types at alvestrand.no
Cc: Onno Elzinga; 'ietf-types at alvestrand.no'; 'sah at 428cobrajet.net';
Hollenbeck, Scott
Subject: Re: MIME Type Review Request: text/CSTA-type


On Tue November 2 2004 08:54, Hollenbeck, Scott wrote:
> Please review the MIME type registration template described below.  The IESG
> has received a request to register this MIME type in the standards tree.  It
> is a product of Ecma International.  A URL for the formal specification is
> included in the template.
> 
> -Scott-
> ----------
> MIME media type name: text
> 
> MIME subtype name: CSTA-type
[...]
> Security considerations:
> This content type is designed to carry CSTA data types over network
> protocols. Appropriate precautions should be taken to insure that
> applications observing these CSTA objects are authorized to do so.
[...]
> Applications which use this media type:
> The text/CSTA-type MIME type is used to carry CSTA data types specified in
> CSTA XML (ECMA-323) over various types of network protocols.
> 
> Additional information:
> CSTA XML (ECMA-323) is an application level protocol that enables an
> application to control and observe communications involving various types of
> media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
> and devices associated with the media.

Why is this being proposed for registration in the text media type tree?
As far as I can tell, this media type appears to be an application data
format containing control data, not textual information (in the sense
of the use of "text" in the MIME standards (RFC 2046) and Internet
Best Current Practice (RFC 2277):

RFC 2046:
   The five discrete top-level media types are:

    (1)   text -- textual information.  The subtype "plain" in
          particular indicates plain text containing no
          formatting commands or directives of any sort. Plain
          text is intended to be displayed "as-is". No special
          software is required to get the full meaning of the
          text, aside from support for the indicated character
          set. Other subtypes are to be used for enriched text in
          forms where application software may enhance the
          appearance of the text, but such software must not be
          required in order to get the general idea of the
          content.  Possible subtypes of "text" thus include any
          word processor format that can be read without
          resorting to software that understands the format.  In
          particular, formats that employ embeddded binary
          formatting information are not considered directly
          readable. A very simple and portable subtype,
          "richtext", was defined in RFC 1341, with a further
          revision in RFC 1896 under the name "enriched".

RFC 2277:

   All human-readable text has a language.

   Many operations, including high quality formatting, text-to-speech
   synthesis, searching, hyphenation, spellchecking and so on benefit
   greatly from access to information about the language of a piece of
   text. [WC 3.1.1.4].

   Humans have some tolerance for foreign languages, but are generally
   very unhappy with being presented text in a language they do not
   understand; this is why negotiation of language is needed.

   In most cases, machines will not be able to deduce the language of a
   transmitted text by themselves; the protocol must specify how to
   transfer the language information if it is to be available at all.

   The interaction between language and processing is complex; for
   instance, if I compare "name-of-thing(lang=en)" to "name-of-
   thing(lang=no)" for equality, I will generally expect a match, while
   the word "ask(no)" is a kind of tree, and is hardly useful as a
   command verb.

 4.2.  Requirement for language tagging

   Protocols that transfer text MUST provide for carrying information
   about the language of that text.


Buried in an Annex in the 530-page referenced ECMA document one finds:

This annex specifies a schema for CSTA data types that can be used to encapulatate CSTA data objects so that they can be carried over various types of network protocols such as SIP. A specific MIME media type, text/CSTA-type is designed to contain these data objects. The formats of the data types are specified in Clause 9.

I can see nothing in the proposed media type registration or in the
referenced document that indicates that the media type is to be
used to convey human-readable natural language text as
opposed to application-specific data type, nor do I see any provision
for carrying information about language of text as required by
RFC 2277.

A concrete example of how the proposed media type would be
used to convey human-readable text in some specified language
would help to provide justification for registration of the
proposed subtype in the text media type tree.