April 2009 - Ietf-types - alvestrand.no

specific mime-types for MathML3 ?
by Paul Libbrecht 21 Jun '09

21 Jun '09

Hello mime-types experts, in the W3C Math working group, a hot debate is happening about the types of content. MathML defines two types of content in its specification, MathML- content and MathML-presentation. They are both specified in the same spec which also offers ways to combine them. In the future chapter 6 (draft at http://monet.nag.co.uk/~dpc/draft-spec/chapter6.html ), one can see that the need arises to qualify MathML objects of the two different types with a different name on the clipboard and this is agreed upon in the group. What is not agreed upon is whether the final spec should include a form for just one generic mime-type or three so as to allow negotiation similar to the clipboard: - application/presentation+mathml+xml - application/content+mathml+xml - application/mathml+xml The two first are the specific types, the last one is the generic type; our registration would append the form(s) at RFC 4288 within a normative part in the MathML spec. It's pretty clear we shall specify that the generic type should always be offered if a specific type is offered and, similarly, the generic type should be delivered if it's not clear that the specific type is supported. We do not have yet a big set of scenarios that depend on a content- negotiation where the knowledge of a specific mime-type is the sole enabler instead of "just accepting any MathML and try to do your best with it". Here are my questions: - do you see any danger in having three mime-types if we have the provision above? - is there a chance our registration for three mime-types is rejected for other reasons? thanks in advance paul

4 10

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

MIME Type Review: application/nlsml+xml, text/grammar-ref-list
by Eric Burger 28 Apr '09

28 Apr '09

http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2 defines the following MIME types: application/nlsml+xml is defined in section 13.2.1 text/grammar-ref-list is defined in section 13.5.1 Please do not panic about section 13.5.2, text/uri-list. Since it is substantially identical to the definition in RFC 2483, we will most likely remove the definition in section 13.5.2 and reference the IANA registry, with an Informative reference to RFC 2483. We have been at this for five years, and to be honest we cannot remember if we asked for review. We really, really, really are done. Thus, we would appreciate a quick look. Thanks.

1 0

Mime type registration
by Shane Ruman 17 Apr '09

17 Apr '09

Hello, Below is our request for a registered mime-type. The purpose of this mime type has a limited scope - to communicate a video uuid between our browser-based video player and our desktop video player. If there is some issue with the request or further steps must be take, please let me know. Thanks. Subject: Registration of media type vendor/application Type name: application Subtype name: vnd.extendmedia.ocmf Required parameters: none Optional parameters: none Encoding considerations: none Security considerations: none Interoperability considerations: none Published specification: none Applications that use this media type: ExtendMedia OpenCASE Additional information: none Person & email address to contact for further information: sruman(a)extend.com Intended usage: LIMITED USE Restrictions on usage: Strictly to be used between two components of the OpenCASE video asset management suite. Author: Shane Ruman Change controller: Shane Ruman

1 0

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

08 Apr '09

Mark - we are not sure at present if we will be registering other vnd.pkg5.* types, which is why we left it like this. I plan to get a spec for the p5i file next week and will post it then. Thanks, JR Message: 1 Date: Sun, 5 Apr 2009 17:14:52 -0400 From: Mark Baker <mark(a)coactus.com> Subject: Re: Request for mime type registration for application/vnd.pkg5.info To: jmr <John.Rice(a)sun.com> Cc: ietf-types(a)iana.org Message-ID: <e9dffd640904051414w5ed1415dta624a0900b5ceae2(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 27, 2009 at 2:18 PM, jmr <John.Rice(a)sun.com> wrote: > > 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 > Can I assume by your choice of name structure that you're planning to register other vnd.pkg5.* types? If yes, then that's fine, otherwise you might just want to go with vnd.pkg5-info. Mark.

1 0

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

Re[2]: Registration of media type application/vnd.emclient.accessrequest+xml
by Filip Navara 02 Apr '09

02 Apr '09

Hello, sorry for late reply. You might be right about the "version" parameter, we included it only to prevent compatibility problems in future and we actually don't plan to use it. Your suggestion of new MIME type seems reasonable and we might as well drop the parameter entirely (and keep the "1.0" value as only possible, for compatibility). The "Encoding considerations" section has been changed to match RFC 3023. It's primarily used as XML MIME part inside an e-mail message. There is no published specification currently and there will not be one until May or so. Thanks for suggestions. Best regards, Filip Navara > -----Original Message----- > From: Mark Baker <mark(a)coactus.com> > To: Filip Navara <navara(a)emclient.com> > Cc: "ietf-types(a)iana.org" <ietf-types(a)iana.org> > Date: 02/19/09 22:17 > Subject: Re: Registration of media type application/vnd.emclient.accessrequest+xml > > On Thu, Jan 22, 2009 at 11:14 AM, Filip Navara <navara(a)emclient.com> wrote: > > > > Type name: application > > > > Subtype name: Vendor Tree - vnd.emclient.accessrequest+xml > > > > Required parameters: none > > > > Optional parameters: > > > > version - in the X.Y notation where X specifies major version change and Y > > specifies minor version change. Applications supporting this MIME type should > > not try to process the content unless the major version number is recognize > > by the particular implementation. > > I would recommend against this approach if not too late to change it > in your software. If a change occurs to the format such that old > software will not be able to process new documents, then you should > mint a new media type. > > > > > Encoding considerations: > > > > The content of this media type consists of lines of 7bit or 8bit text. > > In the latter case use of quoted-printable or base64 may be needed > > when operating over 7bit transports. > > I'm confused. If you're using the "+xml" suffix, the format needs to > be XML based and not some transformed version of XML. Transfer > codings ala HTTP are of course permitted, but it's not clear to me > that this is what you're talking. > > > > > Security considerations: > > > > The type exists to provide a limited and safe subset of operations to media > > authors, but the full spectrum of security issues associated with this type > > has not been completely assessed. > > Explicit actions based on the content should be done only after confirmation > > by the recepient. Embedding inside S/MIME container with digital signature > > is recommended. > > See RFC 3023, section 10 for a more complete analysis of XML related > > security issues. > > > > Interoperability considerations: > > > > There are no special known interoperability issues, but the full spectrum > > of interoperability issues associated with this type has not been completely > > assessed. > > > > Published specification: > > Is there one? > > Mark.

1 0