August 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

Review requests: application/news-* + message/news
by Frank Ellermann 28 Aug '08

28 Aug '08

Hi, the USEFOR WG is about to finish <http://tools.ietf.org/html/draft-ietf-usefor-usepro> Section 4 of this draft -12 contains four MIME types: message/news (OBSOLETE) application/news-transmission (update) application/news-groupinfo (new) application/news-checkgroups (new) See the registration templates below, Frank --- MIME type name: message MIME subtype name: news Required parameters: none Optional parameters: charset, compare message/rfc822 Encoding considerations: compare message/rfc822 (RFC 2046) Security considerations: OBSOLETE, use message/rfc822. Interoperability considerations: Rarely used; and therefore often handled as application/octet-stream. Disposition should by default be inline. Published specification: [SON-OF-1036], RFCXXXX Applications that use this media type: Some old mail and news user agents. Intended usage: OBSOLETE Author: Henry Spencer Change controller: IETF --- MIME type name: application MIME subtype name: news-transmission Required parameters: none Optional parameters: One and only one of "usage=moderate", "usage=inject", or "usage=relay". Encoding considerations: A transfer-encoding different from that of the article transmitted MAY be supplied to ensure correct transmission over some 7bit transport medium. Security considerations: A news article may be a control message, which if processed could have effects on the recipient host's system beyond just storage of the article. Published specification: RFCXXXX Body part: A complete proto-article ready for injection into Netnews or an article being relayed to another agent. Applications that use this media type: Injecting agents, Netnews moderators. Intended usage: COMMON Change controller: IETF --- MIME type name: application MIME subtype name: news-groupinfo Required parameters: none Optional parameters: charset, which MUST be a charset registered for use with MIME text types and has the same syntax as the parameter defined for text/plain [RFC2046]. Specifies the charset of the body part. If not given, the charset defaults to US-ASCII [ASCII]. Encoding considerations: 7bit or 8bit MUST be used to maintain compatibility. Security considerations: None. Interoperability considerations: Disposition should by default be inline. Applications that use this media type: Control message issuers, relaying agents, serving agents. Published specification: RFCXXXX Intended usage: COMMON Change controller: IETF --- MIME type name: application MIME subtype name: news-checkgroups Required parameters: none Optional parameters: charset, which MUST be a charset registered for use with MIME text types and has the same syntax as the parameter defined for text/plain [RFC2046]. Specifies the charset of the body part. If not given, the charset defaults to US-ASCII [ASCII]. Encoding considerations: 7bit or 8bit MUST be used to maintain compatibility. Security considerations: This media type provides only a means for conveying a list of newsgroups and does not provide any information indicating whether the sender is authorized to state which newsgroups should exist within a hierarchy. Such authorization must be accomplished by other means. Interoperability considerations: Disposition should by default be inline. Applications that use this media type: Control message issuers, relaying agents, serving agents. Published specification: RFCXXXX Intended usage: COMMON Change controller: IETF ---

1 0

OpenType MIME Type
by Anne van Kesteren 26 Aug '08

26 Aug '08

Hi, Relatively soon Opera and Mozilla will ship with support for downloadable fonts. Rather than sniffing, as currently happens for images, or ignoring MIME types altogether (ECMAScript), we think it would be good to actually check for a MIME type this time around. :-) What would be a good MIME type to check for here? * font/opentype * application/opentype * something else? How do we go about registering this? Also, how do we ensure the registration happens fast enough for us to be able to implement it on time? Historically, if the implementation doesn't do things like this correctly from the start, it's close to impossible to fix it later on (see e.g. images or ECMAScript). (We realize Apple already shipped with this functionality without checking but we have some hope that can still be resolved by authors fixing their resources to also make it work for us and then later Apple fixing their product as well.) Thanks for your consideration and time, -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>

4 5

Re: Request for review of InkML media type: application/inkml+xml
by Frank Ellermann 25 Aug '08

25 Aug '08

Kazuyuki Ashimura wrote: > the security issues of RFC1738, section 6, should be considered. Please s/RFC1738, section 6/RFC3986, section 7/ if you have no special reasons to use the almost completely obsolete RFC 1738. > Published specification: > ------------------------- > > This media type registration is for InkML documents as described > by this specification. IMO you need a reference for "this" specification, IANA publishes only your registration template, where "this" would make no sense. Frank

2 2

Archives?
by Anne van Kesteren 25 Aug '08

25 Aug '08

Are the archives only occasionally regenerated? It seems none of the messages of this month so far made it to the list archives: http://www.alvestrand.no/pipermail/ietf-types/ -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>

1 0

For review: message/news is obsolete
by Frank Ellermann 24 Aug '08

24 Aug '08

Hi, message/news was registered about 14 years ago by Henry Specer in conjunction with "son-of-1036", a draft introducing MIME in NetNews. Meanwhile the IETF USEFOR WG produced a grandson-of-1036 (an approved RFC waiting for its number). A companion memo addresses technical issues, and among other things it will formally deprecate message/news. Informally RFC 2046 section 5.2.1 did this years ago by stating that message/rfc822 can be also used for News. What you see below is a proposed template that could be submitted to IANA when this memo (RFCXXXX) is approved: <http://tools.ietf.org/html/draft-ietf-usefor-usepro> : MIME type name: message : MIME subtype name: news : Required parameters: none : Optional parameters: charset, compare message/rfc822 : Encoding considerations: compare message/rfc822 (RFC 2046) : Security considerations: OBSOLETE, use message/rfc822 : Interoperability considerations: : Rarely used; and therefore often : handled as application/octet-stream : Published specification: son-of-1036, RFCXXXX : Applications that use this media type: : Some old mail and news user agents : Intended usage: OBSOLETE : Author: Henry Spencer : Change controller: IETF Frank

1 0

Request for review of media sub-type registration request
by Tim Moses 19 Aug '08

19 Aug '08

Colleagues - The attached draft contains a request for registration of a media sub-type and an XML namespace. I would very much welcome your guidance on the completeness and correctness of the information it provides prior to formal submission of the draft and the registration request. Thank you for your help. All the best. Tim. Tim Moses +1 613 270 3183

3 4

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

11 Aug '08

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 spt

1 0