RE: [Fwd: [IANA #628625] Request for MIME media type Application/Standards Tree - ttml+xml]

Some thoughts inline below prefaced with "MD>>"

I think we need to talk about the encoding.

Regards,

 Mike

-----Original Message-----
From: Philippe Le Hegaret [mailto:plh@w3.org] 
Sent: Thursday, November 15, 2012 3:58 AM
To: public-tt
Subject: [Fwd: [IANA #628625] Request for MIME media type Application/Standards Tree - ttml+xml]

Forward the response from IANA regarding application/ttml+xml. We'll need to respond to it,

Philippe

-------- Forwarded Message --------
From: Amanda Baber via RT <iana-mime@iana.org>
Reply-to: iana-mime@iana.org
To: plh@w3.org
Subject: [IANA #628625] Request for MIME media type Application/Standards Tree - ttml+xml
Date: Thu, 15 Nov 2012 08:41:02 +0000

Dear Philippe,

The IESG-designated expert has reviewed this application and returned the inline comments below. Please reply to this email within 30 days (i.e. by 15 December) with a revised application. 

If you have any questions, please don't hesitate to contact us.

Your other application is still with the expert. 

Best regards,

Amanda Baber
ICANN/IANA


> Name : Philippe Le Hegaret

> Email : plh@w3.org

> MIME media type name : Application

> MIME subtype name : Standards Tree - ttml+xml

> Required parameters : None

> Optional parameters :
> charset
> Same as application/xml media type, as specified in RFC 3023 or its 
> successors.

Since we cannot in general be sure what successors to RFC 3023 will do, it probably isn't appropriate to assume that successors will necessarily be in sync with this specification. So this should, in absence of other considerations, be reduced to a reference to RFC 3023.

MD>>  I agree.

> profile
> The document profile of a TTML document may be specified using an 
> optional profile parameter, which, if specified, the value of which 
> must adhere to the syntax and semantics of ttp:profile parameter 
> defined by Section 6.2.8 ttp:profile of the published specification.

A reference to the section, e.g.,

  http://www.w3.org/TR/ttaf1-dfxp/#parameter-attribute-profile

would be helpful here.

MD>> I agree.

> Encoding considerations : binary

MD>>  Although IANA did not comment, TTML Annex C points to application/xml, which points to RFC 3023, section 3.2. This is reproduced here:

Encoding considerations: This media type MAY be encoded as
      appropriate for the charset and the capabilities of the underlying
      MIME transport.  For 7-bit transports, data in either UTF-8 or
      UTF-16 MUST be encoded in quoted-printable or base64.  For 8-bit
      clean transport (e.g., 8BITMIME[RFC1652] ESMTP or NNTP[RFC0977]),
      UTF-8 is not encoded, but the UTF-16 family MUST be encoded in
      base64.  For binary clean transports (e.g., HTTP[RFC2616]), no
      content-transfer-encoding is necessary.

MD>> I believe "binary", although the most general and arguably never wrong, is a problem. We (and RFC 3023) do not require the charset parameter, and thus the encoding is impossible to determine by examining the document.   I believe we should consider constraining this to the common XML encodings in TTML and reflecting the decision in this registration.  Further, we should probably also make a statement about the encoding of foreign namespace extensions. Allowing them to be binary would result in a document potentially not being parseable at the core XML level.
MD>> This is really a new issue which I should file, but it impacts this registration.

> Security considerations :
> As with other XML types and as noted in RFC 3023 Section 10, repeated 
> expansion of maliciously constructed XML entities can be used to 
> consume large amounts of memory, which may cause XML processors in 
> constrained environments to fail.

There seems to be something missing at this point: A statement of the security consideration (or lack thereof) of TTML itself. Looking at the specification, I believe it is appropriate to say that TTML does not provide for any sort of active or executable content. If so, that should be stated here.

MD>> This is not true since foreign namespaces are supported without content restriction.  We could say that this spec doesn't define any active content, but it enables extensions that might.

The other issues that need to be covered are privacy and integrity concerns, or (again) the lack of any such concerns. I do not know enough about TTML and the environment it operates in to offer any advice here.
This material is especially important if there is any expectation that XML signatures or encryption would be employed.

> In addition, because of the extensibility features for TTML and of XML 
> in general, it is possible that "application/ttml+xml" may describe 
> content that has security implications beyond those described here.
> However, if the processor follows only the normative semantics of the 
> published specification, this content will be outside TTML namespaces 
> and may be ignored. Only in the case where the processor recognizes 
> and processes the additional content, or where further processing of 
> that content is dispatched to other processors, would security issues 
> potentially arise. And in that case, they would fall outside the 
> domain of this registration document.

Nicely stated.

> Interoperability considerations :


> Published specification :
> This media type registration is extracted from Appendix C Media Type 
> Registration of the Timed Text Markup Language (TTML) 1.0 specification.
> http://www.w3.org/TR/ttaf1-dfxp/#media-type-registration

This is a pointer back to the registration itself. This really needs to be a reference to the specification as a whole.

> Applications which use this media :
> TTML is used in the television industry for the purpose of authoring, 
> transcoding and exchanging timed text information and for delivering 
> captions for television material repurposed for the internet.

> There is partial and full support of TTML in components used by 
> several Web browsers plugins, and in a number of caption authoring tools.


> Additional information :

> 1. Magic number(s) : none
> 2. File extension(s) : .ttml
> 3. Macintosh file type code : TTML
> 4. Object Identifiers: org.w3c.ttml

> Fragment identifiers:

> For documents labeled as application/ttml+xml, the fragment identifier 
> notation is intended to be used with xml:id attributes, as described 
> in section 7.2.1 of the Timed Text Markup Language (TTML) 1.0 specification.

> Person to contact for further information :

> 1. Name : Timed Text Working Group
> 2. Email : public-tt@w3.org

> Intended usage : Common


> Author/Change controller : The published specification is a work 
> product of the World Wide Web Consortium's Timed Text (TT) Working 
> Group. The W3C has change control over this specification.

Received on Friday, 16 November 2012 17:41:21 UTC