April 2010 - 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

Vendor-specific MIME type for review
by Tapani Otala 15 Jul '10

15 Jul '10

Hello, We would like to submit a new vendor-specific MIME type for your review. The basic idea is simple, but it did not quite fit in the IANA registration form and the recommendation was to post it to this mailing list for review. MIME media type name: application MIME subtype name: vnd.adobe.composite-asset Required parameters: final_type, final_subtype Optional parameters: none Description: This media type denotes a generic composite asset container that contains multiple sub-assets, each of which has an existing IANA registered text, image and video media types. The final type is identified by the final_type and final_subtype parameters. Sample usage: application/vnd.adobe.composite-asset; final_type=text, final_subtype=html Encoding considerations: binary This media type may require encoding on transports not capable of handling binary. Security considerations: This media type contains content that could be considered 'active' or 'executable'. However, it does not expand upon the existing security considerations already applicable to those media types. Published specification: This media type references existing IANA registered MIME types, for which there are existing specifications. Applications which use this media: Adobe Photoshop.com Web Service (http://www.photoshop.com) and its client applications. Person to contact for further information: Tapani Otala (otala(a)adobe.com) Intended usage: Limited Use The use of this media type is limited to the Photoshop.com web service and its client applications. Sincerely, Tapani Otala Sr. Engineering Manager, Photoshop.com Platform Services Adobe Systems Incorporated

4 8

Request for review of media type registration in draft-santoni-media-type-tsd-00.txt
by Adriano.Santoni 03 Jun '10

03 Jun '10

Hi all, would you please revise the media type registration in http://www.ietf.org/id/draft-santoni-media-type-tsd-00.txt Thanks Adriano Santoni

2 1

Registration of media type application/openurl-ctx+xml
by Young,Jeff (OR) 30 Apr '10

30 Apr '10

Type name: application Subtype name: openurl-ctx+xml This subtype refers XML documents that conform to "The XML ContextObject Format" <http://www.openurl.info/registry/dc/info:ofi/fmt:xml:xsd:ctx> Required parameters: none Optional parameters: charset Same as <http://tools.ietf.org/html/rfc3023#section-3.2> Encoding considerations: Same as <http://tools.ietf.org/html/rfc3023#section-3.2> Security considerations: Same as <http://tools.ietf.org/html/rfc3023#section-3.2> Interoperability considerations: Same as <http://tools.ietf.org/html/rfc3023#section-3.2> Published specification: See <http://www.openurl.info/registry/dc/info:ofi/fmt:xml:xsd:ctx> Applications that use this media type: OpenURL 1.0 <http://alcme.oclc.org/openurl/docs/pdf/z39_88_2004.pdf> Additional information: Magic number(s): None File extension(s): .ctx Macintosh file type code(s): None Person & email address to contact for further information: Phil Norman <norman(a)oclc.org> Intended usage: COMMON Restrictions on usage: None Author: Jeffrey A. Young <jyoung(a)oclc.org> Change controller: OpenURL Maintenance Agency <openurlagency(a)oclc.org>

1 0

IANA Registration Template from draft-ietf-marf-base
by Murray S. Kucherawy 28 Apr '10

28 Apr '10

Hi IANA, Below is a MIME type registration from the above document which is making its way toward the IESG. Please let me know if it contains any areas of concern. 6.1. MIME Type Registration of 'message/feedback-report' This section provides the media type registration application from [MIME-REG<http://tools.ietf.org/html/draft-ietf-marf-base-03#ref-MIME-REG>] for processing by IANA: To: ietf-types(a)iana.org Subject: Registration of media type message/feedback-report Type name: message Subtype name: feedback-report Required parameters: none Optional parameters: none Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers. Security considerations: See Section 7<http://tools.ietf.org/html/draft-ietf-marf-base-03#section-7> of [this document]. Interoperability considerations: Implementors MUST ignore any fields they do not support. Published specification: [this document] Applications that use this media type: Abuse helpdesk software for ISPs, mail service bureaus, mail certifiers, and similar organizations Additional information: none Person and email address to contact for further information: Yakov Shafranovich <ietf(a)shaftek.org> Murray S. Kucherawy <msk(a)cloudmark.com> Intended usage: COMMON Author: Yakov Shafranovich John Levine Murray S. Kucherawy Change controller: IESG

1 0

Re: plan for getting media type registrations updated w.r.t. media fragments?
by Mark Nottingham 28 Apr '10

28 Apr '10

Well, ietf-types is important from a functional standpoint, but I don't know that it should be used to discuss the document itself. That sort of coordination should happen on apps-discuss and the URI list, I think. Regards, On 23/04/2010, at 12:19 AM, Dan Connolly wrote: > +cc ietf-types(a)alvestrand.no ; > thread begins at > http://lists.w3.org/Archives/Public/public-media-fragment/2010Apr/0039.html > > On Wed, 2010-04-21 at 09:32 +1000, Silvia Pfeiffer wrote: >> On Wed, Apr 21, 2010 at 2:56 AM, Dan Connolly <connolly(a)w3.org> wrote: >>> http://www.w3.org/TR/2010/WD-media-frags-20100413/#standardisation-terminol… > [...] >>> "The Media Fragment WG has no authority to update registries of all >>> targeted media types. ... We recommend media type owners to harmonize >>> their existing schemes with the ones proposed in this document and >>> update or add the fragment semantics specification to their media type >>> registration." >>> >>> Is there a plan to get that recommendation implemented? >> >> I can offer to do an update of the Ogg RFC >> http://www.ietf.org/rfc/rfc5334.txt with these fragment >> specifications. >> >> Though, to be honest, it will be easier to just get implementations >> and then, if they catch on, update the RFC. > > Well, that's a plan of sorts... but it's important to coordinate > that with the IETF. It's not polite for W3C to unilaterally > encourage implementations to deploy certain designs that will > constrain updates to IETF RFCs. > > I wonder who to coordinate with from the IETF side... > The http://www.alvestrand.no/mailman/listinfo/ietf-types > page says it's owned/run by Harald Alvestrand and Mark Baker (distobj). > Does this play make sense to you? > > Otherwise, Mark N., would you suggest anybody in particular > to coordinate with? > >> The reason that we can do implementations without much issues is that >> virtually no other implementations of fragment schemes on media >> resources exist. Even where schemes were developed such as at YouTube, >> these schemes were not done on the media resource, but on the Web page >> URLs. Also see http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#Existing… >> for a more indepth analysis of the state of affairs. The exisiting >> MPEG scheme has not been implemented anywhere FAIK and would not clash >> since it always starts with mp(). >> >> Cheers, >> Silvia. >> > > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E > > -- Mark Nottingham http://www.mnot.net/

2 1

Re: plan for getting media type registrations updated w.r.t. media fragments?
by Silvia Pfeiffer 23 Apr '10

23 Apr '10

Hi Dan, Does the IETF have a mechanism to request mime type owners to update their specs to integrate something like a fragment specification for URIs? If so, that would be helpful. Regards, Silvia. On Fri, Apr 23, 2010 at 12:19 AM, Dan Connolly <connolly(a)w3.org> wrote: > +cc ietf-types(a)alvestrand.no ; > thread begins at > http://lists.w3.org/Archives/Public/public-media-fragment/2010Apr/0039.html > > On Wed, 2010-04-21 at 09:32 +1000, Silvia Pfeiffer wrote: >> On Wed, Apr 21, 2010 at 2:56 AM, Dan Connolly <connolly(a)w3.org> wrote: >> > http://www.w3.org/TR/2010/WD-media-frags-20100413/#standardisation-terminol… > [...] >> > "The Media Fragment WG has no authority to update registries of all >> > targeted media types. ... We recommend media type owners to harmonize >> > their existing schemes with the ones proposed in this document and >> > update or add the fragment semantics specification to their media type >> > registration." >> > >> > Is there a plan to get that recommendation implemented? >> >> I can offer to do an update of the Ogg RFC >> http://www.ietf.org/rfc/rfc5334.txt with these fragment >> specifications. >> >> Though, to be honest, it will be easier to just get implementations >> and then, if they catch on, update the RFC. > > Well, that's a plan of sorts... but it's important to coordinate > that with the IETF. It's not polite for W3C to unilaterally > encourage implementations to deploy certain designs that will > constrain updates to IETF RFCs. > > I wonder who to coordinate with from the IETF side... > The http://www.alvestrand.no/mailman/listinfo/ietf-types > page says it's owned/run by Harald Alvestrand and Mark Baker (distobj). > Does this play make sense to you? > > Otherwise, Mark N., would you suggest anybody in particular > to coordinate with? > >> The reason that we can do implementations without much issues is that >> virtually no other implementations of fragment schemes on media >> resources exist. Even where schemes were developed such as at YouTube, >> these schemes were not done on the media resource, but on the Web page >> URLs. Also see http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#Existing… >> for a more indepth analysis of the state of affairs. The exisiting >> MPEG scheme has not been implemented anywhere FAIK and would not clash >> since it always starts with mp(). >> >> Cheers, >> Silvia. >> > > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E > >

1 0

Re: Registration of media type application/its+xml
by Felix Sasaki 22 Apr '10

22 Apr '10

2010/4/21 Bjoern Hoehrmann <derhoermi(a)gmx.net> > * Felix Sasaki wrote: > >MIME media type name: > > application > > The registration is based on an obsoleted template. Could you resubmit > it using the RFC 4288 template? (In particular, the field names have > changed, and some fields have been split into multiple fields). > Yes, will do. > > >Applications which use this media type: > > This new media type is being registered to allow for deployment of ITS > >1.0 on the World Wide Web. > > This should give an idea what kinds of applications use the media type > (revision control software, word processing software, ...) > Propose to add: "ITS 1.0 information can be used e.g. by localization tools to extract localizable units (e.g. text strings) as an input to the localization process." > > >Additional information: > > File extension: > > its > > Fragment identifiers: > > A syntax identical to that of "application/xml" as described in > IETF > >RFC 3023. > > RFC 3023 does not define fragment identifier syntax for application/xml. > OK - I propose to leave the "Fragment identifiers" part out. > > > Base URI: > > As specified in IETF RFC 3023, section 6. > > RFC 3023 does not actually say something relevant here, for example, it > is unclear whether xml:base is considered for application/its+xml. > OK. > I do note that it is not actually clear to me what documents would be > labeled with this type, for instance, what would be the root element of > such documents? > Any XML document containing ITS 1.0 "its:rules" elements can be labelled with application/its+xml. At http://www.w3.org/TR/its/EX-link-external-rules-2.xml you see an example of a document linking to a file with ITS 1.0 "rules". The link target is at http://www.w3.org/TR/its/EX-link-external-rules-1.xml as you can see the link target does not have "its:rules" as a root element. The processing semantics here is that linked rules are gathered in document order. Felix -- > Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de > Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ >

2 3

Re: Potential media type registration: application/metalink4+xml for Metalink Download Description Format
by Anthony Bryan 22 Apr '10

22 Apr '10

On Thu, Apr 22, 2010 at 5:06 AM, Bjoern Hoehrmann <derhoermi(a)gmx.net> wrote: > * Anthony Bryan wrote: >>6.2. application/metalink4+xml MIME type > >> Additional information: >> >> Magic number(s): As specified for "application/xml" in [RFC3023], >> Section 3.2. > > This isn't quite accurate, as that would not identify metalink documents > (but rather all XML documents). I think "None" would be better, some XML > types also discuss presence of root elements or namespaces, but that's > not really helpful here, in my opinion. Changed to "None" >> File extension: .meta4 >> >> Macintosh File Type code: TEXT >> >> Person and email address to contact for further information: >> Anthony Bryan <anthonybryan(a)gmail.com> >> >> Intended usage: COMMON >> >> Restrictions on usage: None. >> >> Author/Change controller: IESG > > This should be two fields, with you as the author and the IESG as change > controller. Author: Anthony Bryan <anthonybryan(a)gmail.com> > Other than that this looks good. > > (You didn't copy the ietf-types list, so I'll send a mail there pointing > out that we've resolved this offlist, assuming you'll be making these > changes during auth48.) I copied the ietf-types list now. Here it is for one last review. Thanks for taking the time to catch these last minute! 6.2. application/metalink4+xml MIME type A Metalink Document, when serialized as XML 1.0, can be identified with the following media type: Type name: application Subtype name: metalink4+xml Required parameters: None. Optional parameters: "charset": This parameter has semantics identical to the charset parameter of the "application/xml" media type as specified in [RFC3023]. Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], Section 3.2. Security considerations: As defined in this specification. In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], Section 10. Interoperability considerations: There are no known interoperability issues. Published specification: This specification. Applications that use this media type: File transfer applications. Additional information: Magic number(s): None. File extension: .meta4 Macintosh File Type code: TEXT Person and email address to contact for further information: Anthony Bryan <anthonybryan(a)gmail.com> Intended usage: COMMON Restrictions on usage: None. Author: Anthony Bryan <anthonybryan(a)gmail.com> Change controller: IESG -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads

2 1

Request for review of media type registration in draft-ietf-keyprov-dskpp-10.txt
by Polk, William T. 22 Apr '10

22 Apr '10

Folks, Please review the following media type registration from draft-ietf-keyprov-dskpp-10.txt, which is currently in IETF Last Call. Note: The text is reproduced exactly from the draft. Based on recent experiences, I understand that the following lines should be deleted: To: ietf-types(a)iana.org Subject: Registration of MIME media type application/dskpp+xml Thanks, Tim Polk ------------ 12.3. MIME Media Type Registration This section registers the "application/dskpp+xml" MIME type: To: ietf-types(a)iana.org Subject: Registration of MIME media type application/dskpp+xml MIME media type name: application MIME subtype name: dskpp+xml Required parameters: (none) Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See [RFC3203], Section 3.2. Security considerations: This content type is designed to carry protocol data related to key management. Security mechanisms are built into the protocol to ensure that various threats are dealt with. Interoperability considerations: This content type provides a basis for a protocol. Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.] Applications which use this media type: Protocol for key exchange. Additional information: Magic Number(s): (none) File extension(s): .xmls Macintosh File Type Code(s): (none) Person & email address to contact for further information: Andrea Doherty (andrea.doherty(a)rsa.com) Intended usage: LIMITED USE Author/Change controller: The IETF Other information: This media type is a specialization of application/xml [RFC3203], and many of the considerations described there also apply to application/dskpp+xml.

2 1