June 2009 - Ietf-types

Registration of media type application/vnd.apple.mpegURL
by Roger Pantos 24 Jul '09

24 Jul '09

Hello there. I'm planning to submit this registration to IANA soon, but per RFC 4288 I'm sending it here first to solicit initial feedback. Thanks. Type name: application Subtype name: vnd.apple.mpegURL Required parameters: (none) Optional parameters: (none) Encoding considerations: Encoded as text, either ASCII or UTF-8. UTF-8 is recommended. Security considerations: - As with any text format, parsers must guard against buffer overflow attacks - Active content: - Several elements of this format are URIs, which clients will use to make network requests of arbitrary entities - Clients should range-check responses to prevent buffer overflows - Clients should load resources identified by URI lazily (specified by protocol) to reduce server DoS - See also Security Considerations in RFC 3986 - Privacy: - URIs are typically http. Implementations may send cookie data with http requests, which could include user data. - Implementations must follow cookie restriction & expiry rules specified by RFC 2965. - Compression: this media type does not employ compression. - The format includes the specification of encryption keys, by URI. The delivery of these keys should be secure, but it is up to the distributor of the media to ensure that it is, e.g. by using HTTP over TLS in conjunction with a secure realm or a session cookie. Interoperability considerations: - No byte-ordering issues, since files are encoded as ASCII or UTF-8 text - Applications may encounter unrecognized tags. These should be ignored. Published specification: http://tools.ietf.org/html/draft-pantos-http-live-streaming Applications that use this media type: - iPhone media player (OS 3.0) - QuickTime Player in Mac OS X (Snow Leopard) Additional information: Magic number(s): #EXTM3U File extension(s): m3u, m3u8 Macintosh file type code(s): none Person & email address to contact for further information: David Singer, singer@.apple.com Intended usage: LIMITED USE Restrictions on usage: (none) Author: Roger Pantos Change controller: David Singer Roger.

2 2

Registration of MIME media type application/vnd
by Gil bernabeu (GlobalPlatform Technical Director) 10 Jul '09

10 Jul '09

MIME media type name: application MIME subtype name: Vendor Tree - vnd.globalplatform.card-content-mgt-response Required parameters: version, charset The version parameter consists of one or more digits 0-9 Optional parameters: none Encoding considerations: binary Security considerations: This media type does not contain active or executable content. The information contained in the media type may need privacy and integrity services but these are provided by an underling security protocol (e.g. TLS) or specific coding Interoperability considerations: No interoperabilty issues identified Published specification: This MIME media type is required for GlobalPlatform (www.globalplatform.org) Card Specification v 2.2 - Amendment B - Card Remote Application Management over HTTP specification. Applications which use this media type: This MIME media type is required for GlobalPlatform for a remote administration protocol between a web server embedded in a smart card and a remote entity via a secure channel with mutual authentication to load , install, delete and personalized on card application. Additional information: 1. Magic number(s): n/a 2. File extension(s): None 3. Macintosh file type code: n/a 4. Object Identifiers: n/a Person & email address to contact for further information: 1. Name : Gil BERNABEU 2.Title : GlobalPlatform Technical Director 3. email : gil.bernabeu(a)globalplatform.org Intended usage: common Create a new protocol for smart card administration Author/Change controller: the specification using this new mime media type "Card Remote Application Management over HTTP - Card Specification v 2.2 - Amendment B" is available at https://www.globalplatform.org/specificationscard.asp

1 1

IETF Types Review: application/framework-attributes+xml
by Eric Burger 29 Jun '09

29 Jun '09

Please review the MIME Type application/framework-attributes+xml, as defined in http://tools.ietf.org/id/draft-ietf-mediactrl-sip-control-framework Cross-posting to mediactrl(a)ietf.org would be greatly appreciated.

3 3

Re: Registration of media type application/vnd.apple.mpegURL
by Roger Pantos 26 Jun '09

26 Jun '09

On Jun 26, 2009, at 10:36 AM, Roger Pantos wrote: > Type name: application > > Subtype name: vnd.apple.mpegURL Whoops, that should be: Subtype name: vnd.apple.mpegurl I don't think these are case-sensitive, but just in case... Roger.

1 0

Proposal to register application/vnd.dia+xml
by Ron Wilson 23 Jun '09

23 Jun '09

I am proposing to register application/vnd.dia+xml as the media type for diagrams created by Dia, a diagramming tool hosted at http://live.gnome.org/Dia I have made multiple attempts to contact the lead developer of Dia, have received no response, so I am advancing this proposal myself for the benefit of both the Dia project and its users (which included me). Proposed media type: application/vnd.dia+xml The Dia file format is based on XML, so all considerations regarding XML apply. Is this the best media type to use? I chose this because the similar application, Visio, appears to have registered application/vnd.visio (http://www.iana.org/assignments/media-types/application/vnd.visio) Please comment. If there are no objections, I will prepare and submit the registration request.

1 0

specific mime-types for MathML3 ?
by Paul Libbrecht 21 Jun '09

21 Jun '09

Hello mime-types experts, in the W3C Math working group, a hot debate is happening about the types of content. MathML defines two types of content in its specification, MathML- content and MathML-presentation. They are both specified in the same spec which also offers ways to combine them. In the future chapter 6 (draft at http://monet.nag.co.uk/~dpc/draft-spec/chapter6.html ), one can see that the need arises to qualify MathML objects of the two different types with a different name on the clipboard and this is agreed upon in the group. What is not agreed upon is whether the final spec should include a form for just one generic mime-type or three so as to allow negotiation similar to the clipboard: - application/presentation+mathml+xml - application/content+mathml+xml - application/mathml+xml The two first are the specific types, the last one is the generic type; our registration would append the form(s) at RFC 4288 within a normative part in the MathML spec. It's pretty clear we shall specify that the generic type should always be offered if a specific type is offered and, similarly, the generic type should be delivered if it's not clear that the specific type is supported. We do not have yet a big set of scenarios that depend on a content- negotiation where the knowledge of a specific mime-type is the sole enabler instead of "just accepting any MathML and try to do your best with it". Here are my questions: - do you see any danger in having three mime-types if we have the provision above? - is there a chance our registration for three mime-types is rejected for other reasons? thanks in advance paul

4 10

IETF Types Review: application/msc-ivr+xml
by Eric Burger 19 Jun '09

19 Jun '09

Please review the MIME Type application/msc-ivr+xml, as defined in http://tools.ietf.org/id/draft-ietf-mediactrl-ivr-control-package Cross-posting to mediactrl(a)ietf.org would be greatly appreciated.

1 0