- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 6 Oct 2009 13:25:00 +1100
- To: Glenn Adams <gadams@xfsi.com>
- Cc: Philippe Le Hegaret <plh@w3.org>, ietf-types@iana.org, Glenn Adams <glenn@xfsi.com>, public-tt@w3.org
Hmm, I see. I guess that works, too. Thanks for clarifying. Regards, Silvia. On Tue, Oct 6, 2009 at 12:35 PM, Glenn Adams <gadams@xfsi.com> wrote: > 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 02:25:55 UTC