October 2008 - Ietf-types

Registration request for MIME media type tag 3gpp-ims+xml
by John M Meredith 21 May '09

21 May '09

This proposed registration is being distributed to this list (ietf-types(a)iana.org) for preliminary review, in accordance with the instructions given by IANA. It is cc'ed, as suggested by IANA, to Chris Newman. It is also cc'ed to 3GPP delegates to TSG CT WG1 (http://www.3gpp.org/tb/home.htm, http://www.3gpp.org/tb/CT/CT1/CT1.htm) who have a technical interest in the matter. Best regards John M Meredith 3GPP Specifications Manager, ETSI ======================================================================== ======================================== > Name : John M Meredith (3GPP Specifications Manager) > Email : john.meredith&etsi.org > > > MIME media type name: > Application > > MIME subtype name: > 3gpp-ims+xml > > Required parameters: > None > > Optional parameters: > "charset" the parameter has identical semantics to the charset > parameter of the "application/xml" media type as specified in RFC > 3023 [132]. > "sv" or "schemaversion" the parameter's value is used to indicate: > - the versions of the 3GPP IM CN Subsystem XML schema that can be > used to validate the 3GPP IM CN subsystem XML body (if the MIME > type and parameter are present in the Content-Type header) or > - the accepted versions of the 3GPP IM CN Subsystem XML body (if the > MIME type and parameter are present in the Accept header). > > If the "sv" or "schemaversion" parameter is absent, it shall be > assumed that version 1 of the XML Schema for the IM CN subsystem > XML body is supported. > > This registration entry includes ABNF that modifies the m-parameter > definition in RFC 3261 [26]. m-parameter allows for > attribute/value pairs that are applicable to the media range. In > particular, the ABNF below is given for a media range > application/3gpp-ims+xml specific m-parameter. > > m-parameter /= ("sv" / "schemaversion") EQUAL LDQUOT [ sv-value- > list ] RDQUOT > sv-value-list = sv-value-range *( "," sv-value ) sv-value-range = > sv-value [ "-" sv-value ] > sv-value = number / token > number = 1*DIGIT [ "." 1*DIGIT ] > > Encoding considerations: > Same as encoding considerations of application/xml as specified in RFC > 3023 [132] > > Security considerations: > 3GPP has defined mechanisms for ensuring the privacy and integrity > protection of the bodies of SIP messages used in the 3GPP IM CN > Subsystem. > > Interoperability considerations: > This content type provides a format for exchanging information in SIP > Requests and Responses and used within the 3GPP IM CN Subsystem. > > Published specification: > ETSI TS 124 229 version 8.4.1, being a formal transposition of 3GPP TS 24.229 version 8.4.1: > "Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session > Description Protocol (SDP); Stage 3" > > Available via http://pda.etsi.org/pda/home.asp?wkr=RTS/TSGC-0124229v841 (http://www.3gpp.org/ftp/Specs/html-info/24229.htm) > > Applications which use this media: > Applications that use the 3GPP IM CN Subsystem as defined by 3GPP. > > Additional information : > > 1. Magic number(s) : none > 2. File extension(s) : none > 3. Macintosh file type code : none > 4. Object Identifiers: none > > Application submitted on behalf of the Organizational Partners of > 3GPP. > > Person to contact for further information : > > 1. Name : John M Meredith, 3GPP Specifications Manager > 2. Email : john.meredith&etsi.org > > > Intended usage: > This content type provides a format for exchanging information in SIP > Requests and Responses as used within the 3GPP IM CN Subsystem. > > Author/Change controller : 3GPP Specifications Manager via > www.3gpp.org > Technical contact: jbakker&rim.com >

3 4

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

test to ietf-types@ietf.org
by Chris Newman 07 Oct '08

07 Oct '08

Test. If someone accidentally uses ietf-types(a)ietf.org instead of ietf-types(a)iana.org, it should now work. - Chris

1 0

Types review request: draft-ietf-simple-imdn-07.txt
by Robert Sparks 06 Oct '08

06 Oct '08

The SIMPLE working group has requested publication of a draft that registers message/imdn+xml and would appreciate this lists review. The draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-07.txt Thanks! Robert Sparks SIMPLE co-chair

1 0

RE: Review for media types: application/ibe-pp-data, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml
by Luther Martin 03 Oct '08

03 Oct '08

> -----Original Message----- > From: mark(a)coactus.com [mailto:mark@coactus.com] On Behalf Of Mark > Baker > Sent: Friday, October 03, 2008 11:49 AM > To: Luther Martin > Cc: Chris Newman; Turner, Sean P.; ietf-types(a)iana.org; > tim.polk(a)nist.gov > Subject: Re: Review for media types: application/ibe-pp-data, > application/ibe-key-request+xml, and application/ibe-pkg-reply+xml > > On Fri, Oct 3, 2008 at 2:18 PM, Luther Martin <martin(a)voltage.com> > wrote: > >> -----Original Message----- > >> From: mark(a)coactus.com [mailto:mark@coactus.com] On Behalf Of Mark > >> Baker > >> > In the case of IBE, the public key is the identity, so the content > of > >> the proposed application/ibe-key-request is really just a subset of > >> what's encoded with application/pkcs10. (It's not-self signed, etc., > >> but that's really a minor difference.) > >> > > >> > What's the fundamental difference between these two that warrants > >> greatly different processing? > >> > >> It's the two mandatory media type parameters as described in sec > 5.4, > >> and (unmentioned until now) the mandatory parameter in 5.7. > > > > So if the mandatory parameter sections are deleted, then it would be > OK? That's the way that the media types application/pkcs10 and > application/pkcs7-mime are defined. > > Right. No problem. Communicating by e-mail just isn't as efficient as communicating in person, is it?

1 0

RE: Review for media types: application/ibe-pp-data, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml
by Turner, Sean P. 03 Oct '08

03 Oct '08

There was another update: http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-08.txt spt >-----Original Message----- >From: stian(a)mygrid.org.uk [mailto:stian@mygrid.org.uk] On >Behalf Of Stian Soiland-Reyes >Sent: Tuesday, September 23, 2008 7:07 AM >To: Turner, Sean P. >Cc: ietf-types(a)iana.org >Subject: Re: Review for media types: application/ibe-pp-data, >application/ibe-key-request+xml, and application/ibe-pkg-reply+xml > >On Mon, Aug 11, 2008 at 21:05, Turner, Sean P. ><turners(a)ieca.com> wrote: >> The Identity-based Encryption Architecture and Supporting Data >> Structures ID, an S/MIME WG item, is seeking to register >three new media types: >> application/ibe-pp-data, application/ibe-key-request+xml, and >> application/ibe-pkg-reply+xml. We're seeking a wider >community review >> of these media types. The ID can be found at: >> >> http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-07.txt > >I get a 404 error when trying to follow the above mentioned link. > >-- >Stian Soiland-Reyes, myGrid team >School of Computer Science >The University of Manchester

4 14

review of audio media types for G.719
by Roni Even 01 Oct '08

01 Oct '08

Hi, The AVT working group requests media type review for the g719 media type defined in section 7.1 of http://tools.ietf.org/html/draft-ietf-avt-rtp-g719-02 . This draft is currently in AVT working group last call. We would be grateful if any comments could be made by October 1st. Thanks, Roni Even (AVT co-chair)

3 2