March 2009 - Ietf-types - alvestrand.no

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

Registration of Media types proposed by LC
by Ray Denenberg, Library of Congress 07 May '09

07 May '09

The following media types are proposed for registration on the standards tree: application/mods+xml application/mads+xml application/mets+xml application/marcxml+xml application/sru+xml These are proposed by the Library of Congress on behalf of several constituencies including the library/bibliographic and metadata communities. These all correspond to standards maintained at the Library of Congress. Please see the document at: http://www.loc.gov/standards/register-media-types.doc for background and for the filled-out template as required by RFC 4288. According to RFC 4288, "Registration of a new media type or types starts with the construction of a registration proposal." This correspondence together with the above referenced document is intended to serve as construction of the proposal. RFC 4288 further states: "Proposals for media types registered in the standards tree by the IETF itself MUST be published as RFCs. Standards tree registrations for media types defined in documents produced by other standards bodies MUST be described by a formal standards specification produced by that body." Formal specifications are cited in the referenced document for each media type. So may I infer that an RFC is not necessary? Further .... "Proposed registrations in the standards tree by other standards bodies should be communicated to the IESG (at iesg(a)ietf.org) and to the ietf-types list (at ietf-types(a)iana.org) .. Notice of a potential media type registration in the standards tree MUST be sent to the "ietf-types(a)iana.org" mailing list for review." Thus I an sending this correspondence to iesg(a)ietf.org and ietf-types(a)iana.org. Further.... "Provided that the media type meets all of the relevant requirements and has obtained whatever approval is necessary, the author may submit the registration request to the IANA... IESG approval in effect submits the registration to the IANA. There is no need for an additional registration request." Based on this I am not sure what further steps if any I need to take, so I await guidance. (I have not previously registered a media type.) Thank you. Ray Denenberg, Library of Congress

3 5

Request for mime type registration for application/vnd.pkg5.info
by jmr 05 Apr '09

05 Apr '09

Hi, I am a developer working on the Packaging System which is part of the OpenSolaris.org project [1]. I would like to register a mime type for OpenSolaris.org's IPS packaging system, pkg(5) [2]: MimeType: application/vnd.pkg5.info File extension(s): .p5i Magic number(s): None The contents of the file are in JSON format (http://www.json.org/) and specify one or more Publishers to add to a users system that is running OpenSolaris, along with an optional number of packages [3]. The mime type is bound to files of .p5i extension [4] and clicking on such a file on the OpenSolaris system launches the Package Manager application to process the file, prompting the user to install the named Repositories and Packages. I have read rfc4288: - Media Type Specification and Registration Procedures: http://tools.ietf.org/html/rfc4288 And as per guidelines in Section 5, wanted to submit this mime type for initial review and comment before submitting a formal request via: http://www.iana.org/cgi-bin/mediatypes.pl Best regards, John Rice Snr. Staff Engineer Dublin, Ireland Sun Microsystems [1]: http://www.opensolaris.org/os/ [2]: http://opensolaris.org/sc/src/pkg/gate/src/man/pkg.5.txt http://www.opensolaris.org/os/project/pkg/ http://www.opensolaris.org/os/package/ [3]: http://blogs.sun.com/jmr/entry/packagemanager_for_2009_06 [4]: Example .p5i file: ----------------------------------- { "publishers": [ { "name": "opensolaris.org", "packages": [ "SUNWfirefoxl10n-pl-PL", "SUNWthunderbirdl10n-pl-PL" ], "repositories": [ { "collection_type": "core", "description": "opensolaris.org", "legal_uris": [ "http://opensolaris.org/license.html" ], "mirrors": [], "name": "opensolaris.org", "origins": [ "http://osol-re.sfbay.sun.com/" ], "refresh_seconds": 43200, "registration_uri": "", "related_uris": [] } ] }, { "name": "sunfree", "packages": [ "IPSFWjoe" ], "repositories": [ { "collection_type": "supplemental", "description": "sunfree", "legal_uris": [], "mirrors": [], "name": "sunfree", "origins": [ "http://pkg.sunfreeware.com:9000/" ], "refresh_seconds": 43200, "registration_uri": "", "related_uris": [] } ] }, { "name": "contrib", "repositories": [ { "collection_type": "supplemental", "description": "contrib", "legal_uris": [ "http://pkg.opensolaris.org/contrib/license.html" ], "mirrors": [], "name": "contrib", "origins": [ "http://pkg.opensolaris.org/contrib/" ], "refresh_seconds": 43200, "registration_uri": "", "related_uris": [] } ] } ], "version": 1 }

3 2

Registration of MIME media type MESSAGE/DISCLAIMER
by Ravishankar Nandagopalan 26 Mar '09

26 Mar '09

MIME media type name: MESSAGE MIME subtype name: DISCLAIMER Required parameters: Disclaiming Domain (DD), Boundary Optional parameters: Disclaimer Action (DA), Department Identification (DID) Encoding considerations: Appropriate encoding should be used based on the media being encoded as the types can include text plain, HTML, images and other multimedia contents Security considerations: Since disclaimers can be constructed using 'External-body' media type and can contain 'Image' media, the security considerations outlined in RFC 2046<http://www.rfc-editor.org/rfc/rfc2046.txt> and RFC 2045<http://www.rfc-editor.org/rfc/rfc2045.txt> will apply for the media type and the RFC list specified for the Image media sub-type specified here<http://www.iana.org/assignments/media-types/image/>. Applications which use this media type: Fax and Messaging Person & email address to contact for further information: Ravishankar Nandagopalan ravisn(a)microsoft.com Intended usage: COMMON Author/Change controller: Ravishankar Nandagopalan Parameter descriptions: 1. Disclaiming domain (DD): Defines the domain that inserts/owns the disclaimer. 2. Boundary: Boundary delimiters, which is defined in RFC 2046<http://www.rfc-editor.org/rfc/rfc2045.txt> 3. Disclaimer Action (DA): This optional parameter informs the user agent whether to append or prepend the disclaimer to the message body. The default action if omitted or unspecified should be 'Append'. 4. Department Identification (DID): This parameter is used in the scenario where departments or entities disclaim using the same SMTP domain. This parameter should be populated when the aforementioned scenario exists to manage the disclaimers without duplication. Media subtype usage: This media sub-type is intended to make disclaimers more manageable and legible for the users by avoiding duplication of disclaimers and help manage their rich content for effective and error free encoding and transmission. The media type will be used to treat disclaimers as a unique part of the message and all the norms that apply for a normal message body content will apply.

3 3

R: R: general question
by Santoni Adriano 09 Mar '09

09 Mar '09

Thank you, Adriano -----Messaggio originale----- Da: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Inviato: lunedì 9 marzo 2009 10.30 A: Santoni Adriano Cc: Roni Even; ietf-types(a)alvestrand.no Oggetto: Re: R: general question Santoni Adriano skrev: > Roni, > > thank you for replying. > >>> Are you asking if the media type registration need to be in the same > document as the payload specification > > Yes, exactly. > >>> Look in RFC 4855 ........ there it says that registration and the > payload specification can be different documents. > > Indeed, but some may argue that RFC4855 is related to the RTP > (Real-time Transport Protocol) case only. > > RFC 4288, which is mote general, seems to state the opposite at par. 4.10: > > "Proposals for media types registered in the standards tree by the > IETF itself MUST be published as RFCs." > There is plenty of cases where the Media Registration is done in one document and the specification of the format is in another. And the above rule you are citing is only saying that the media types registered by IETF needs to be published in an RFC. It doesn't put any requirement on them being the same. > So it is still not clear (to me) if RFC 4855 is an exception to the > general rule, or not. > >>> I am not sure that I know of such cases... > > I think you are right. After a closer examination of several cases, I > have always found a (sort of) media type registration in each of them. > > Again, I wonder if a media type can be registered after the payload > specification has been published; it may not always be clear, at the > payload specifications' publication time, that a corresponding new > media type is also needed. > So registration of media types for files etc can definitely be done later and in separate documents. See RFC 3839 when this is done for a format that is specified outside of IETF. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund(a)ericsson.com ----------------------------------------------------------------------

1 0

general question
by Santoni Adriano 09 Mar '09

09 Mar '09

Hello, I have the following doubt, and would like someone to enlighten me. Is it mandatory that a media type registration be included in the RFC that defines such media type? It seems to me, if I am not mistaken, that there are several media types defined in RFCs which does not contain an explicit media type registration.... TIA, Adriano

3 3