- From: Glenn Adams <gadams@xfsi.com>
- Date: Tue, 6 Oct 2009 09:35:24 +0800
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Philippe Le Hegaret <plh@w3.org>, ietf-types@iana.org, Glenn Adams <glenn@xfsi.com>, public-tt@w3.org
- Message-ID: <94ad087a0910051835u65cb7a21v13a06313a64a435a@mail.gmail.com>
DFXP's mime type is formally based on RFC 3023 [XML Media Types], which specifies ".xml" as file name extension (see Section 3.2 of that RFC, under Additional Information); On Tue, Oct 6, 2009 at 9:03 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>wrote: > I am concerned about the lack of a additional information typically > used in mime type registration RFCS, see e.g. > http://www.rfc-editor.org/rfc/rfc3839.txt (for 3gpp) or > http://tools.ietf.org/html/rfc4337 (mpeg4) or > http://www.ietf.org/rfc/rfc5334.txt (ogg): > > Magic number(s): (probably not relevant) > File extension(s): > Macintosh File Type Code(s): > > I think it is important that we specify a common file extension and a > mac file type code so as not to create confusion in the market with > some people creating .dfxp , some creating .xml and some creating > whatever they think is appropriate. This will make it very difficult > for example for Web servers to serve the correct mime types, since > they tend to do so based on file extensions. > > My suggestion is: > > File extension: .dfxp (I think four letters is reasonable nowadays, > even for windows?) > > Mac file type code: DFXP > > > Best Regards, > Silvia. > > > On Thu, Oct 1, 2009 at 6:46 AM, Philippe Le Hegaret <plh@w3.org> wrote: > > The following media type registration will be submitted to > > the IESG for review, approval, and registration with IANA (as per [1]). > > > > At this point, we would appreciate comments on this registration > > information. If you see any problems, please let us know. > > > > > > Regards, > > > > Philippe > > > > [1] http://www.w3.org/2002/06/registering-mediatype > > > > [[ > > > > This appendix registers a new MIME media type, "application/ttaf+xml" > > in conformance with [1144]BCP 13 and [1145]W3CRegMedia. The information > > in this appendix is being submitted to the Internet Engineering > > Steering Group (IESG) for review, approval, and registration with the > > Internet Assigned Numbers Authority (IANA). > > > > [1144] http://www.ietf.org/rfc/rfc4288.txt > > [1145] http://www.w3.org/2002/06/registering-mediatype.html > > > > MIME media type name: > > application > > > > MIME subtype name: > > ttaf+xml > > > > Required parameters: > > None. > > > > Optional parameters: > > The encoding of a TT AF document must be determined by the > > XML encoding declaration. This has identical semantics to the > > application/xml media type in the case where the charset > > parameter is omitted, as specified in [1146][XML Media], > > Sections 8.9, 8.10 and 8.11. > > > > The document profile of a TT AF 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 [1147]6.2.8 > > ttp:profile of the published specification. > > > > Encoding considerations: > > Same for application/xml. See [1148][XML Media], Section 3.2. > > > > Restrictions on usage: > > None. > > > > Security considerations: > > As with other XML types and as noted in [1149][XML Media] > > 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. > > > > In addition, because of the extensibility features for TT AF > > and of XML in general, it is possible that > > "application/ttaf+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 TT AF > > 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. > > > > Interoperability considerations: > > The published specification describes processing semantics > > that dictate behavior that must be followed when dealing > > with, among other things, unrecognized elements and > > attributes, both in TT AF namespaces and in other namespaces. > > > > Because TT AF is extensible, conformant > > "application/ttaf+xml" processors must expect that content > > received is well-formed XML, but it cannot be guaranteed that > > the content is valid to a particular DTD or Schema or that > > the processor will recognize all of the elements and > > attributes in the document. > > > > Published specification: > > This media type registration is extracted from Appendix > > [1150]D Media Type Registration of the [1151]Timed Text (TT) > > Authoring Format 1.0 - Distribution Format Exchange Profile > > (DFXP) specification. > > > > [1151] http://www.w3.org/TR/ttaf1-dfxp/ > > > > Additional information: > > None. > > > > Person & email address to contact for further information: > > Glenn Adams (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. > > > > ]] > > http://www.w3.org/TR/ttaf1-dfxp/#media-type-registration > > > > > > > > > > >
Received on Tuesday, 6 October 2009 01:36:00 UTC