- Ietf-types - alvestrand.no

Registration of media type image/vnd.radiance
by R Fritz 06 Jan '09

06 Jan '09

Type name: image Subtype name: vnd.radiance Required parameters: None Optional parameters: None Encoding considerations: Binary preferred. This is a binary image type with a text header; "binary" or "base64" are the only reasonable choices. Security considerations: The Radiance HDR file format does not include executable code or scripts; it is a graphics file with an ASCII header. Compression is used, which could crash an image viewer. There is no way to completely rule out the possibility of malicious content, however HDR viewer applications do not usually run with administrator privileges--they seem poor targets for such attacks. Interoperability considerations: byte orders are spelled in the published specification; we expect that Radiance HDR files will be readable on all systems. Published specification: *Radiance File Formats*, available freely at <http://radsite.lbl.gov/radiance/refer/> and also as part of Ch 18 of *Rendering With Radiance* (Booksurge/Amazon, ISBN 0974538108). Applications that use this media type: Adobe Photoshop, AHDRIA, AHDRIC, CinePaint, FDRTools, hdrgen, HDR Shop, PFStools, Photosphere, Qtpfsgui, RadDisplay, Radiance, Web HDR Additional information: Magic number(s): Text "#?RADIANCE\n" (octet sequence 23 3f 52 41 44 49 41 4e 43 45 0a) at the beginning of the file. File extension(s): pic, hdr, rgbe, xyze Macintosh file type code(s): Person & email address to contact for further information: rfritz(a)u.washington.edu Intended usage: COMMON Restrictions on usage: none Author: Randolph Fritz Change controller: Greg Ward (gregoryjward(a)gmail.com) / The Radiance Lighting Simulation Internet Group Notes: 1. The "pic" extension is also used for Macintosh PICT files; it is deprecated. 2. The rgbe and xyze extensions represent information about the content of the files, and may conflict with the actual content of files. Applications should check. 3. Radiance also uses "?RADIANCE\n" as a tag for its octree files; applications should read the file header to confirm that the file is indeed a Radiance HDR file, as described in the specification.

2 5

Registration of media type model/x3d+XXX
by Leonard Daly 05 Jan '09

05 Jan '09

Per the instructions in IETF RFC 4288, the Web3D Consortium (http://web3d.org/) is submitting model/x3d+XXX as a new MIME type. Please contact me if there are clarifications or questions. Thank you, Leonard Daly X3D WG Co-Chair, Web3D Consortium ----------------------------------------------------------- Type name: model Subtype names: x3d+vrml x3d+xml x3d+binary Required parameters: None Optional parameters: None Encoding considerations: This application represents the different MIME types used for three different encodings of the X3D ISO standard (see [1]). The standard defines an abstract information structural representation, for which several file formats are available. These formats are currently defined to be: VRML-Classic: (old-style curly brace format of the VRML97 ISO standard). UTF-8 (8-bit text) is to be supported. The recently introduced UTF-8 BOM cannot be supported by definition of the specification. XML: Encoding requirements as per the XML standards. Binary: (Effectively a binary XML encoding scheme based on the outcome of the W3C binary XML working group process). Still a work in progress and standardisation is not yet complete. Each content type may have an addition Content-Encoding to indicate whether the content has been compressed using GZIP in addition to the basic textual encoding. This is also indicated by modifying each file extension with the character "z". For example, the plaintext VRML-encoded file format would use the extension ".x3dv", and if compressed using GZIP uses the extension ".x3dvz" Security considerations: Scripting is defined as being available for the specification. Two languages are defined: Java and ECMAScript. Each scripting language is controlled by its local security model. As the content may run in many different situations, the X3D specification does not impose specific security policies. For example, some standalone applications will want to directly interact with the local file system, network or database, while others that run in a web browser would use the web-browser's security model. Interoperability considerations: The definition of the file format is maintained by the Web3d Consortium (http://www.web3d.org) and published through the ISO process. Several revisions of the specification have been made and it continues to be made. All revisions use the same MIME type definitions, and are backwards compatible internally and structurally. In addition, each of the file format encodings may be losslessly transformed between each other. Published specification: All revisions of the X3D specification can be found here: http://www.web3d.org/x3d/specifications/ Several revisions of each specification exist. The abstract specification is ISO/IEC 19775:2004. The individual file formats, which also specify the matching MIME types, are parts of the ISO/IEC 19777 specification. Applications that use this media type: There are well over 20 - both browsers, exporters and importers. Additional information: Magic number(s): x3d+vrml: “#X3D” x3d+xml: Use XML’s specification x3d+binary: “#X3D” File extension(s): x3d+vrml: .x3dv, .x3dvz x3d+xml: .x3d, .x3dz x3d+binary: .x3db Macintosh file type code(s): Person & email address to contact for further information: Leonard <mailto:Leonard> Daly (X3D Working Group Co-Chair) Leonard.Daly(a)realism.com Alan Hudson (Web3d Consortium President) giles(a)yumetech.com <mailto:giles@yumetech.com> Intended usage: COMMON Restrictions on usage: None Author: The Web3D Consortium Change controller: The Web3D Consortium The X3D standard is a continuation of the VRML standard that is defined in RFC2077. As part of this work, several large modifications were made to the file format and specification. The basic premise for the specification continues the VRML philosophy. The MIME types and file extensions were changed to indicate this modified standard. -- +-------- | Leonard Daly | Internet Solutions, eBusiness Specialist http://realism.com/ | LA ACM SIGGRAPH, Electronic Services Chair | X3D Book: http://x3dGraphics.com +------------------------------

5 4

Registration of media type for libpcap-format capture files
by Phil Vandry 20 Dec '08

20 Dec '08

Hello, We would like to register a media type (MIME type) for the file format used by the libpcap library ( http://www.tcpdump.org/ ). This file format is widely used by well-known software such as the network packet capturing packages tcpdump and Wireshark but up to now has had no official media-type to designate it. Per section 3 of RFC 4288, we believe the standards tree is the correct place for this new media type. In particular, we do not consider the vendor tree to be appropriate because there is no "vendor" that owns the type (libpcap is open source). We would like to request some clarification concerning the process established by RFC 4288 for regstering new types. Sections 3.1 and 5 state that registrations in the standards tree must either come from the IETF itself (in which case they must be published as RFCs) or from another "recognized standards body". However, the libpcap development community represents neither the IETF nor a recognized standards body, to our knowledge. How do you advise that the registration be made? Can the IETF sponsor an application that we prepare? We are considering "application/pcap-capture" or "application/pcap" for the name of the type but we have not made a decision yet (if you have a suggestion on this point we would be interested to hear it). It will not be a problem to document the file format as well as to meet the other requirements stated in RFC 4288 section 4. Thank you for your consideration. -Phil

3 2

The registration of the "vnd.3gpp.clearmode" RTP payload type at IANA
by John M Meredith 12 Dec '08

12 Dec '08

Dear All It is the intention of 3GPP to request IANA registration of the above code point. The information below is taken from annex D of 3GPP TS 29.007 v8.1.0 which will shortly be available in its entirety on the 3GPP site via http://www.3gpp.org/ftp/Specs/html-info/29007.htm . In accordance with past practice, I am sending the request via the ietf-types exploder for review and comment prior to the formal registration request. Please use the current "to" list which includes the editor of the specification concerned and the chairman and secretary of the responsible working group. Best seasonal wishes John M Meredith 3GPP Specifications Manager ================================================================================ Annex D (informative): IANA registration information for RTP payload types for SCUDIF in SIP-I based CS core network D.1 Introduction This Annex provides information required for the registration of the "vnd.3gpp.clearmode" RTP payload type at IANA. Editor´s note: MCC is requested to perform this registration on behalf of 3GPP at http://www.iana.org/cgi-bin/mediatypes.pl D.2 IANA Registartion information D.2.1 Media Type Name audio D.2.2 Subtype Name vnd.3gpp.clearmode D.2.3 Required parameters none D.2.4 Optional parameters "ptime" gives the length of time in milliseconds represented by the media in a packet, as described in RFC 4566. "maxptime" represents the maximum amount of media, which can be encapsulated in each packet, expressed as time in milliseconds, as described in IETF RFC 4566. "network-initiated-service-change" denotes if a network initiated servive change is supported or applied. It shall be used according to the rules in 3GPP TS 29.007 and 3GPP TS 23.172. No values shall be supplied for this parameter D.2.5 Encoding considerations Framed encoding. D.2.6 Security considerations See Section 6 of RFC 4040 [92] D.2.7 Interoperability considerations none D.2.8 Published specification 3GPP TS 29.007. D.2.9 Applications which use this media type Service change and UDI/RDI Fallback (SCUDIF), as defined in 3GPP TS 23.172 [83] D.2.10 Additional information This type is only defined for transfer via RTP. D.2.10.1 Magic number(s) none D.2.10.2 File extension(s) none D.2.10.3 Macintosh File Type Code(s none D.2.10.2 Object Identifier(s) or OID(s) none D.2.11 Intended usage Limited use. This RTP payload type will only be applied within a 3GPP SIP-I based circuit switched core network, as specified in 3GPP TS 23.231 [y] D.2.12 Other Information/General Comment none D.2.13 Person to contact for further information 3GPP Specifications Manager via 3gppContact(a)etsi.org

1 0

Request for two new media types submitted
by Phil Archer 03 Dec '08

03 Dec '08

To whom it may concern, On behalf of the W3C POWDER Working Group I have have today submitted two registration requests for Media Types. As cited in those requests, the key documentation is section 4 of Protocol for Web Description Resources (POWDER): Description Resources [1]. Although this is formally published as a working draft, we are close to reaching our Candidate Recommendation exit criteria and therefore expect to seek transition to Proposed Recommendation later this month. The reference numbers returned following the submissions were 208572 and 208576. These requests complement the separate request to register 'describedby' as an ATOM relationship type (currently under consideration). If I have missed any important detail or of you have any queries, please contact me, preferably copying in the POWDER WG's public mailing list. Thank you. Phil Archer POWDER WG Chair. [1] http://www.w3.org/TR/powder-dr/#assoc -- Phil Archer w. http://philarcher.org/

3 5

Types review: new parameters for audio/mpeg4-generic
by Tom Taylor 20 Nov '08

20 Nov '08

Review is requested for the parameters defined below. These parameters are optional additions for media type audio/mpeg4-generic. The quoted IANA Considerations section comes from draft-ietf-avt-mps-01.txt. Tom Taylor AVT Co-Chair =========================================== 5. IANA Considerations This memo defines additional optional format parameters to the Media subtype mpeg4-generic. These parameters SHALL only be used in combination with the AAC-lbr or AAC-hbr modes (cf. [RFC3640] section 3.3). 5.1. Media Type registration This memo defines the following additional optional parameters which SHALL be used if MPEG Surround data is present inside the payload of an AAC elementary stream. MPS-profile-level-id: A decimal representation of the MPEG Surround Profile Level indication as defined in [14496-3]. This parameter MUST be used in the capability exchange or session set-up procedure to indicate the MPEG Surround Profile and Level that the decoder must be capable in order to decode the stream. MPS-config: A hexadecimal representation of an octet string that expresses the AudioSpecificConfig (ASC) as defined in [14496-3] for MPEG Surround. The ASC is mapped onto the hexadecimal octet string in an MSB-first basis. The AOT in this ASC SHALL have the value 30. The SSC inside the ASC MUST have the sacPayloadEmbedding flag set to 1. 5.2. Registration of Mode Definitions with IANA This memo defines the modes MPS-hbr and MPS-lbr.

1 0

Types review request: draft-ietf-simple-xcap-diff-09.txt
by Robert Sparks 29 Oct '08

29 Oct '08

The SIMPLE working group will soon request publication of a draft that registers application/xcap-diff+xml and would appreciate this list's review. The draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-09.txt Thanks! Robert Sparks SIMPLE co-chair

2 1

Review requested: audio/G7221
by Tom Taylor 22 Oct '08

22 Oct '08

Please review the following registration, which updates the existing audio/G7221 registration provided by RFC 3047. The source documentation is draft-ietf-avt-rfc3047-bis-08.txt, which has passed AVT Working Group Last Call. (Big OOPS! for not invoking media type review at the same time.) Tom Taylor, AVT Co-Chair ============================================= Registration of media type audio/G7221 Media type name: audio Media subtype name: G7221 Required parameters: bitrate: the data rate for the audio bit stream. This parameter is mandatory because the bit rate is not signaled within the G.722.1 bit stream. At the standard G.722.1 bit rates, the value MUST be either 24000 or 32000 at 16 Khz sample rate, and 24000, 32000 or 48000 at 32 Khz sample rate. If using the non-standard bit rates, then it is RECOMMENDED that values in the range 16000 to 48000 be used. Non standard rates MUST have a value that is a multiple of 400 (this maintains octet alignment and does not then require (undefined) padding bits for each frame if not octet aligned). Optional parameters: rate: RTP timestamp clock rate, which is equal to the sampling rate. If the parameter is not specified a clock rate of 16 Khz is assumed. ptime: see RFC 4566. SHOULD be a multiple of 20 msec. maxptime: see RFC 4566. SHOULD be a multiple of 20 msec. Encoding considerations: This media type is framed and binary, see section 4.8 in [RFC4288]. Security considerations: See Section 6 [Quoted at the end of this note -- PTT] Interoperability considerations: Terminals SHOULD offer a media type at 16 Khz sample rate in order to interoperate with terminals that do not support the new 32 Khz sample rate. Published specification: RFC yyy [see RFCeditor notes]. Applications which use this media type: Audio and Video streaming and conferencing applications. Additional information: none Person and email address to contact for further information : Roni Even: ron.even.tlv(a)gmail.com Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time. Author: Roni Even Change controller: IETF Audio/Video Transport working group delegated from the IESG. ============================= 6. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and any appropriate RTP profile. This implies that confidentiality of the media streams is achieved by encryption. A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity.

2 1

Re: proposed media type: application/exi
by Martin Duerst 17 Oct '08

17 Oct '08

Hello Mark, It seems you are saying: 1) application/xml (and text/xml) was a bad ide 2) the +xml suffix was a bad idea 3) For EXI, application/exi is not needed, and a +exi suffix is not needed, because EXI will not be popular. As for 1) and 2), can you tell us what YOU think would be best? As for 3), please note that there is no need for a format to be (or expected to going to be) popular in order to register a media subtype. Regards, Martin. At 05:09 08/10/17, Mark Baker wrote: >On Wed, Oct 15, 2008 at 9:28 PM, Martin Duerst <duerst(a)it.aoyama.ac.jp> wrote: >> Hello Carine, >> >> At the moment, just a questions: >> >> Given that there are many types of the form application/foo+xml, >> will we see proposals for application/foo+exi in the future? > >That's a great question. > >In hindsight, I believe it was an error to mint application/xml and >text/xml for XML content. While there are valid uses cases for them, >they are rare in practice (similar reasons to why one would need to >deliver HTML content as text/plain). But every single time I've seen >them used in the wild was in error, and should have instead been a >format-specific type like application/xhtml+xml or >application/atom+xml. > >It naturally follows that I don't think EXI should have its own media >type. That's not to say I believe we need a "+exi" suffix though, >seeing as a) the value of the "+xml" suffix has been negligible, and >b) it's not clear that EXI is going to be popular. > >Mark. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp

2 1

proposed media type: application/exi
by Carine Bournez 17 Oct '08

17 Oct '08

The W3C EXI Working Group has issued a Last Call draft specification of the EXI Format 1.0 [1]. It includes a proposal for a new media type "application/exi" [2] (a text version follows). The review period for this specification ends on November 7th. [1] http://www.w3.org/TR/exi [2] http://www.w3.org/TR/exi/#internetMediaType =========================== A new media type registration "application/exi" described below is being proposed for community review, with the intent to eventually submit it to the IESG for review, approval, and registration with IANA. Type name: application Subtype name: exi Required parameters: none Optional parameters: none Encoding considerations: binary Security considerations: When used as an XML replacement in an application, EXI shares the same security concerns as XML, described in IETF RFC 3023 [IETF RFC 3023], section 10. In addition to concerns shared with XML, the schema identifier refers to information external to the EXI document itself. If an attacker is able to substitute another schema in place of the intended one, the semantics of the EXI document could be changed in some ways. As an example, EXI is sensitive to the order of the values in an enumeration. It is not known whether such an attack is possible on the actual structure of the document. Also, EXI supports user-defined datatype representations, and such representations, if present in a document and purportedly understood by a processor, can be a security weakness. Definitions of these representations are expected to be external, often application- or industry-specific, so any definition needs to be analyzed carefully from the security perspective before being adopted. Interoperability considerations: The datatype representation map feature of EXI requires coordination between the producer and consumer of an EXI document, and is not recommended except in controlled environments or using standardized datatype representations potentially defined in the future. EXI permits information necessary to decode a document to be omitted with the expectation that such information has been communicated out of band. Such omissions hinder interoperability in uncontrolled environments. Published specification: Efficient XML Interchange (EXI) Format 1.0, World Wide Web Consortium Applications that use this media type: No known applications currently use this media type. Additional information: Magic number(s): The first four octets may be hexadecimal 24 45 58 49 ("$EXI"). The first octet after these, or the first octet of the whole content if they are not present, has its high two bits set to values 1 and 0 in that order. File extension(s): .exi Macintosh file type code(s): APPL Person & email address to contact for further information: World Wide Web Consortium <web-human(a)w3.org> Intended usage: COMMON Restrictions on usage: none Author/Change controller: The EXI specification is the product of the World Wide Web Consortium's Efficient XML Interchange Working Group. The W3C has change control over this specification. =========================== Thank you. -- Carine Bournez -+- W3C Europe

3 5