November 2009 - Ietf-types

Registration of media type application/ttaf+xml
by Philippe Le Hegaret 26 Aug '10

26 Aug '10

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(a)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

7 9

Registration of MIME media type application/pdf-vt-stream
by tim.donahue＠kodak.com 30 Nov '09

30 Nov '09

MIME media type name: application MIME subtype name: pdf-vt-stream Required parameters: None Optional parameters: None Encoding considerations: None Security considerations: As this format is only reusing MIME and restricting it to only refer to PDF files of MIME type application/pdf and ICC files of MIME type application/vnd.iccprofile so this format inherits all known security considerations identified in the respective registrations of those file types. Interoperability considerations: Please refer to ISO 16612-2 Published specification: Currently available as Draft International Standard ISO/DIS 16612-2. This document is presently in ballot. Final document once approved will be published as ISO 16612-2 Graphic technology ? Variable data exchange ? Part 2: Using PDF/X-4 and PDF/X-5 (PDF/VT-1 and PDF/VT-2) The ISO/DIS16612-2 document is available for purchase from the ISO.org website. Applications which use this media type: Intended for communication between a graphical content creator (authoring system) and a graphical content reader that parses and renders the content for display or print. Additional information: None. Magic number(s): The file itself is a MIME stream of content type Multipart/Mixed and has a header field entry X-PDFVT-Stream-version with the value 1 that must be specified ahead of this MIME content type field. File extension(s): Not applicable Macintosh File Type Code(s): None. Person & email address to contact for further information: Tim Donahue, Eastman Kodak Company Tim.Donahue(a)kodak.com Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) LIMITED USE Author/Change controller: ISO Technical Committee 130 / Working Group 2 / Task Force 3 Task force Convener and document editor: Tim Donahue, Eastman Kodak Company, Tim.Donahue(a)kodak.com Secretariat: A. Karin Winkelmann, Secretariat ISO/TC130, Karin.Winkelmann(a)din.de (Any other information that the author deems interesting may be added below this line.)

1 0

Re: please comment on media-type registrations for MathML
by Paul Libbrecht 24 Nov '09

24 Nov '09

Dear media-types-expert, Dear Björn, > Forwarded-from : member-math(a)w3.org > From : "Robert Miner" <robertm(a)dessci.com> > Date : 24 novembre 2009 03:43:50 GMT+01:00 > To : <member-math(a)w3.org> > Archived-At: <http://www.w3.org/mid/D1EFB337111B674B8F1BE155B01C6DD6034CCA68@franklin.cor… > > > > Dear Björn, > > I am writing in response to your comments on the media-type > registrations for MathML given in Appendix B of the Last Call draft of > the MathML 3 Specification. Your original comments are recorded at > http://www.alvestrand.no/pipermail/ietf-types/2009-October/ > 002268.html. > > We have modified Appendix B, and believe we have addressed the issues > you noted. The changes are explained below, and you can see the draft > changes in an editor's draft of the spec located at > > http://monet.nag.co.uk/~dpc/draft-spec/appendixb.html > > Since we need to record the resolution of all Last Call comments, > could we ask you to let us know whether you accept these changes as > addressing your comments? Thanks in advance. > > The specific actions taken are: > > > The first problem I have with this is that there is no word on what > > exactly the various types are for, like if there are any > restrictions > > on what should be in a mathml-content+xml vs a mathml-presentation > +xml > > document, or if the types can be used with MathML 2.0. > > A new introductory section entitled "Selection of Media Types for > MathML Instances" was added to specifically address this issue. The > related text in section 6.2.3 of the spec is essentially summary in > nature, and was therefore left unchanged. It already referred to > appendix B for detailed information on the usage of the media types, > and that information is now given. > > The section carefully defines the presentation and content MathML > vocabularies, and gives a clear rule for determining what media type > should be used for a given MathML instance based on the contents of > that instance. > > The section also contains some explanation and examples to motivate > the usage of the three MathML media types. The section ends by > addressing use of the media types with earlier versions of MathML > > > As per RFC 3023, the charset definition and encoding considerations > > should be referenced as follows, which the proposals fails to do: > > > > Registrations for new XML-based media types under top-level types > > other than "text" SHOULD, in specifying the charset parameter and > > encoding considerations, define them as: "Same as [charset > parameter > > / encoding considerations] of application/xml as specified in RFC > > 3023." > > These sections have been edited to match the proper format. > > > The security considerations are missing (in fact the specification > > as a whole does not have a security considerations section either). > > Security considerations have been added. We have listed both the > generic issues common to similar XML languages, and two issues > specific to MathML: the possible presence of executable code in > semantic annotations, and the (possibly inadvertant) denial of service > risks arising in computational contexts from trying to solve > unsolvable problems. > > > I believe the text you have under "interoperability considerations" > > is misplaced there in all three cases. > > This text has been completely rewritten. Again, there are some > generic considerations common to similar XML languages, as well as > several MathML specific issues. In particular, lack of versioning > information in MathML instances introduces a backward compatibility > concern, and the result of evaluating MathML expressions is not > guaranteed to be the same in different computational systems. > > > I note that under "Applications that use this media type" you have > > "(todo)". Going to Last Call with "todo" markers left is not a good > > practise. I note that the purpose of this field is to give a general > > idea of what kind of applications use it, not to list individual > > software products. > > Thank you for the clarification on the purpose. We have filled out > the section appropriately. > > > Under "Person & email address to contact for further information" > > the proposal fails to properly separate name and email address, use > > something like "Name <address>" instead. I do not think having a > > generic W3C / W3C Webmaster combination there is a good practise > > Following other media type registrations under the BCP13 process, we > have changed this to list Paul as the person, with the Math WG group > mailing list for the address, followed by a pointer to the public W3C > Math web site for additional information. > > --Robert > >

1 0

Registration of media type application/xtm+xml
by Lars Marius Garshol 20 Nov '09

20 Nov '09

I intend to submit the following media type registration to the IESG for registration with IANA. However, before then I would welcome community review and feedback on the proposed registration. If you see any problems, please let me know. Assuming that the appropriate form for such a media type registration would be an RFC-style document I wrote one up using the xml2rfc syntax and published it here: http://www.isotopicmaps.org/sam/xtm-rfc.html The actual registration part is included below. --------------------------------------------------------------------- This is a media type registration as defined in RFC 4288, "Media Type Specifications and Registration Procedures" [RFC4288]. *MIME media type name:* application *MIME subtype name:* xtm+xml *Required parameters:* none *Optional parameters:* charset Same as charset parameter of application/xml, defined in RFC 3023 [RFC3023]. *Encoding considerations:* Same as encoding considerations of application/xml, defined in RFC 3023 [RFC3023]. *Security considerations:* See Section 5. *Interoperability considerations:* _NEED TO WRITE THIS PART_ *Published specification:* See the Topic Maps Data Model [ISO13250-2] and the XTM specification [ISO13250-3]. *Applications which use this media type:* XTM is device-, platform-, and vendor-neutral and is supported by a range of applications and web services. *Magic number(s):* none Although no byte sequences can be counted on to consistently identify XTM, XTM documents will have the sequence "http://www.topicmaps.org/xtm/" to identify the XTM namespace. This will usually be near the top of the document. *File extensions(s):* .xtm *Macintosh File Type Code(s):* "xtm " *For further information:* contact the editors, Lars Marius Garshol <larsga(a)garshol.priv.no> and Graham Moore <graham.moore(a)networkedplanet.com>, or ISO SC34. More information may be found on the website of ISO SC34 WG3: <http://www.isotopicmaps.org>. *Intended usage:* COMMON *Author/Change controller:* The XTM standard was produced by ISO SC34, which has change control over the standard. --------------------------------------------------------------------- --Lars M. http://www.garshol.priv.no/tmphoto/ http://www.garshol.priv.no/blog/

4 7

Re: Change Controller
by Julian Reschke 18 Nov '09

18 Nov '09

Martin J. Dürst wrote: > > > On 2009/11/17 19:41, Julian Reschke wrote: >> Martin J. Dürst wrote: >>> Hello Julian, >>> >>> A tiny bit more of context in your mail would have been helpful. >>> Apparently, you are talking about updates for the types text/html and >>> application/xhtml+xml, which may be sent to this list in the future. >> >> Indeed. >> >>> As for your specific concern below, these registrations go through >>> IESG approval, so it would be the IESG who has to figure out whom to >>> believe in the case of a conflict, not IANA. >>> ... >> >> <http://tools.ietf.org/html/rfc4288#section-9>: >> >> The owner of a media type may pass responsibility to another person >> or agency by informing the IANA and the ietf-types list; this can be >> done without discussion or review. >> >> So it appears that just changing the change controller does not require >> IESG approval (HTML5 does more than that; I'm just trying to understand >> the procedure in cases where *just* the ownership changed). > > Immediately afterwards, it says: > > The IESG may reassign responsibility for a media type. The most > common case of this will be to enable changes to be made to types > where the author of the registration has died, moved out of contact > or is otherwise unable to make changes that are important to the > community. > > So if e.g. the WhatWG went havoc and unilaterally sent the IANA a change > request to be the only owner of text/html, the IESG could simply > reassing it back to W3C (or vice versa). What if one of the change controllers did send a change request *not* changing the ownership, but something else. Would IANA confirm with other parties listed as change controller? > ... BR, Julian

2 1

Change Controller
by Julian Reschke 17 Nov '09

17 Nov '09

Hi, looking for feedback on who can be a change controller...: HTML5 currently says: "Change controller: W3C and WHATWG" (<http://dev.w3.org/html5/spec/Overview.html#iana>) I'm concerned that this may become a problem if, in the future, W3C and WHATWG would disagree about a change. Is IANA going to accept two separate groups as "change controller"? Best regards, Julian

2 3

Re-registration of media type video/H264
by Tom Taylor 11 Nov '09

11 Nov '09

draft-ietf-avt-rtp-rfc3984bis-08.txt has passed Working Group Last Call in the AVT Working Group. Section 8.1 provides the media type registration template for media type video/H264, which was first registered by RFC 3984. The bis document adds a number of new parameters. Comments on the registration are welcome. Tom Taylor AVT Co-Chair

1 0