July 2009 - Ietf-types - alvestrand.no

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

please review "text/rif+xml" media type registration
by Sandro Hawke 21 Jul '09

21 Jul '09

The following media type registration has been recently published as part of a W3C Last Call Working Draft [1], and will soon be submitted to the IESG for review, approval, and registration with IANA (as per [2]). An earlier version of this registration was posted here for review about a year ago [3]. The changes made since then reflect changes in the organization of the RIF family of dialects; there were no changes suggested by reviewers of that posting. At this point, we would appreciate comments on this registration information. If you see any problems, please let us know; I'll act as a liason between these IETF lists and the W3C Working Group responsible for these specifications. -- Sandro [1] http://www.w3.org/TR/rif-core/#Appendix:_RIF_Media_Type_Registration [2] http://www.w3.org/2002/06/registering-mediatype [3] http://lists.w3.org/Archives/Public/www-archive/2008Sep/0023.html ================================================================ Type name: application Subtype name: rif+xml Required parameters: none Optional parameters: charset, as per RFC 3023 (XML Media Types) Encoding considerations: same as RFC 3023 (XML Media Types) Security considerations: Systems which consume RIF documents are potentially vulnerable to attack by malicious producers of RIF documents. The vulnerabilities and forms of attack are similar to those of other Web-based formats with programming or scripting capabilities, such as HTML with embedded Javascript. Excessive Resource Use / Denial of Service Attacks Complete processing of a RIF document, even a conformant RIF Core document, may require arbitrarily great CPU and memory resources. Through the use of "import", processing may also require arbitrary URI dereferencing, which may consume all available network resources on the consuming system or other systems. RIF consuming systems SHOULD implement reasonable defenses against these attacks. Exploiting Implementation Flaws RIF is a relatively complex format, and rule engines can be extremely sophisticated, so it is likely that some RIF consuming systems will have bugs which allow specially constructed RIF documents to perform inappropriate operations. We urge RIF implementors to make systems which carefully anticipate and handle all possible inputs, including those which present syntactic or semantic errors. External (Application) Functions Because RIF may be extended with local, application defined datatypes and functions, new vulnerabilities may be introduced. Before being installed on systems which consume untrusted RIF documents, these external functions should be closely reviewed for their own vulnerabilities and for the vulnerabilities that may occur when they are used in unexpected combinations, like "cross-site scripting" attacks. In addition, as this media type uses the "+xml" convention, it shares the same security considerations as other XML formats; see RFC 3023 (XML Media Types). Interoperability considerations: This media type is intended to be shared with other RIF dialects, to be specified in the future. Interoperation between the dialects is governed by the RIF specifications. Published specifications: RIF Core Dialect W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-core/ RIF Datatypes and Builtins W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-dtb/ RIF Basic Logic Dialect W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-bld/ RIF Production Rule Dialect W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-prd/ RIF Framework for Logic Dialects W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-fld/ This media type is intended for use by all RIF dialects, including those to be specified in the future. Identification of the RIF dialect in use by a document is done by examining the use of specific XML elements within the document. Applications that use this media type: Unknown at the time of these drafts. Multiple applications are expected, however, before the specification reaches W3C Proposed Recommendation status. Additional information: Magic number(s): As with XML in general (See RFC 3023 (XML Media Types)), there is no magic number for this format. However, the XML namespace "http://www.w3.org/2007/rif#" will normally be present in the document. It may theoretically be missing if the document uses XML entities in an obfuscatory manner. The hex form of that namespace will depend on the charset. For utf-8, the hex is: 68 74 74 70 3a 2f 2f 77 77 77 2e 77 33 2e 6f 72. File extension(s): .rif (or .xml) Macintosh file type code(s): "TEXT" (like other XML) Person & email address to contact for further information: Sandro Hawke, sandro(a)w3.org. Please send technical comments and questions about RIF to public-rif-comments(a)w3.org, a mailing list with a public archive at http://lists.w3.org/Archives/Public/public-rif-comments/ Intended usage: COMMON Restrictions on usage: None Author: The editor and contact for this media type registration is Sandro Hawke, sandro(a)w3.org. Change controller: RIF is a product of the Rule Interchange Format (RIF) Working Group of the World Wide Web Consortium (W3C). See http://www.w3.org/2005/rules/wg for information on the group. The W3C (currently acting through this working group) has change control over the RIF specification.

1 0

Registration of media type application/ipfix in draft-ietf-ipfix-file
by Brian Trammell 17 Jul '09

17 Jul '09

Greetings, Submitted for feedback, the following media type registration appears in draft-ietf-ipfix-file, currently in IESG processing. Thanks, Brian Type name: application Subtype name: ipfix Required parameters: none Optional parameters: none Encoding considerations: IPFIX files are binary, and therefore must be encoded in non-binary contexts. Security considerations: See the Security Considerations section (Section 12) of this document, and the Security Considerations section of [RFC5101]. Interoperability considerations: See the Detailed Specification section (Section 7) of this document. The format is designed to be broadly interoperable, as any valid stream of IPFIX Messages over any transport specified in [RFC5101] MUST be recognizable as a valid IPFIX File. Published specification: This document, especially Section 7, and [RFC5101]. Applications that use this media type: Various IPFIX implementations (see [RFC5153]) support the construction of IPFIX File Readers and Writers. Additional information: none Magic number(s): None, although the first two bytes of any IPFIX file are the first two bytes of a message header, the Version field, which as of [RFC5101] are always 10 in network byte order: 0x00, 0x0A. File extension(s): .ipfix Macintosh file type code(s): none For further information: Authors of this document, IETF IPFIX Working Group Intended usage: LIMITED USE Restrictions on usage: none Change controller: Authors of this document, IETF IPFIX Working Group

1 0

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

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

05 Jul '09

It's a coincidence for the most part, unless the original author had m3u playlists in mind when text/uri-list was conceived. Note that vnd.apple.mpegurl goes beyond what uri-list specifies by defining tags that relate specifically to media URIs. Roger. On Jul 2, 2009, at 6:58 PM, Jan Algermissen wrote: > Roger, > > Out of curiosity.. > > is the compatibility with text/uri-list a purpose or a coincidence? > > Jan > > > > > On Jun 26, 2009, at 1:36 PM, Roger Pantos wrote: > >> >> 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. >

1 0