- Ietf-types - alvestrand.no

Hello folks..
by Richard Shockey 10 Jul '07

10 Jul '07

I understand I need to submit this draft for approval since it defines a new media type. Is this the right list? Title : IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for Media type "application/cnam" Author(s) : R. Shockey, et al. Filename : draft-ietf-enum-cnam-05.txt Pages : 13 Date : 2007-5-29 This document registers the Enumservice "pstn" and subtype "cnam" using the URI scheme "data:" as per the IANA registration process defined in the ENUM specification, RFC 3761[1] and registers a new media type application/cnam [17]. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-05.txt Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 <mailto:richard(at)shockey.us> <mailto:richard.shockey(at)neustar.biz>

1 0

Review requested for MusicXML media type proposals
by Michael Good 10 Jul '07

10 Jul '07

MusicXML is a digital sheet music format currently used for interchange between Finale, Sibelius, and over 75 other music notation programs. The format was developed by Recordare LLC and you can find more information at Recordare's web site: http://www.recordare.com/xml.html The current version is 1.1, but version 2.0 is in beta test. The main goal of the MusicXML 2.0 update is to move from being primarily a music notation interchange format to being a music notation distribution format - the equivalent of MP3 files for digital sheet music. With this broader goal, it now seems appropriate to register media types. MusicXML 2.0 files will come in two versions: an uncompressed XML file similar to what is used in the current MusicXML format, and a zip-compressed XML file similar to what is used in ODF and other XML-based distribution formats. We are proposing two media types for these two versions: application/vnd.recordare.musicxml application/vnd.recordare.musicxml+xml The +xml version is for the uncompressed XML file; the other is for the compressed file format. We have posted draft registration proposals on the MusicXML developer mailing list and are now ready for review on this list. My next two e-mail messages will be the registration proposals for these two media types. Thank you very much for your assistance in reviewing these proposals. Best regards, Michael Good Recordare LLC www.recordare.com ____________________________________________________________________________________ We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265

3 12

review of media type and URI from draft-levin-mmusic-xml-media-control-11.txt
by Even, Roni 09 Jul '07

09 Jul '07

Hi, I would like to ask for review of a application media type defined in draft-levin-mmusic-xml-media-control-11.txt. This is an updated version based on the feedback I got. The usage of underscore in the subtype name is allowed by RFC 4288. This media type is part of an informational RFC that list an XML schema that is currently used for backward interoperability purpose. The text from the draft is listed here. 9.1. Application/media_control+xml media type registration Type name: application Subtype name: media_control+xml Required parameters: None Optional parameters: charset Indicates the character encoding of enclosed XML. Encoding considerations: 8bit Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [4], Section 3.2. Security considerations: Security considerations specific to uses of this type are discussed in RFC xxxx [[Note to RFC editor: replace xxxx with the RFC number of this document when published]]. RFC 1874 [1] and RFC 3023 [4] discuss security issues common to all uses of XML. Interoperability considerations: None. Published specification: RFC xxxx [[Note to RFC editor: replace xxxx with the RFC number of this document when published]] Applications that use this media type: This media type is used to convey information regarding media control commands and responses between SIP endpoints particularly for allowing a Video Fast Update intra-frame request. Additional information: Magic Number(s): None. File Extension(s): None. Macintosh File Type Code(s): None. Person and email address to contact for further information: Name: Orit Levin E-Mail: oritl(a)microsoft.com Intended usage: LIMITED USE Restrictions on usage: None. Author: Orit Levin. <oritl(a)microsoft.com> Change Controller: Orit Levin. <oritl(a)microsoft.com> Thanks Roni Even

1 0

MIME type for diffs, *any* MIME type
by Lisa Dusseault 27 Jun '07

27 Jun '07

Hi, This has come up before and stalled the whole attempt to standardize a PATCH method for HTTP: the lack of a properly registered MIME type for any binary or text diff format. The GDiff format described in http://www.w3.org/TR/NOTE- gdiff-19970901 states the MIME type but it was never registered. The IPR situation is completely unclear. No author of this has ever responded to my pings. The VCDIFF format is described in http://www.faqs.org/rfcs/ rfc3284.html does not choose a MIME type. The IPR disclosure <https:// datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=40> states that AT&T grants licenses to "transmit data over the Internet under HTTP 1.1". I do not want to start to interpret whether that covers new HTTP 1.1 methods as well as the ones that existed when this grant was made. An AT&T guy responded to my emails and said he'd suggest a more liberal license to the lawyers but we never saw anything come of that. Julian recently mentioned the POSIX 'diff' format which is most widely used and probably under the most liberal license due to existing source code licenses. No official MIME type was ever suggested for this until Julian's mail but a bit of googling suggests that some applications informally use application/diff and this is probably what is meant by that. I am unaware of an existing formal spec for this -- and that's the sticking point for registering this one -- although clearly interoperability is common. Can we just ask IANA to register any or all of these, perhaps with appropriate disclaimers in the form about IPR or specification formality? Surely that would be better than the status quo. Can I help cut red tape here? Lisa

2 1

review of media type and URI from draft-levin-mmusic-xml-media-control-10.txt
by Even, Roni 19 Jun '07

19 Jun '07

Hi, I would like to ask for review of a media type and new URI for an XML namespace defined in http://tools.ietf.org/wg/mmusic/draft-levin-mmusic-xml-media-control-10.txt. The text from the draft is listed here. 1. Application/media_control+xml media type registration Media Type Name: application subtype name: media_control+xml Required parameters: None Optional parameters: charset See RFC 3023 [4] for a discussion of the charset parameter on XML- derived types. Since this type is used exclusively in SIP, the use of UTF-8 encoding is strongly encouraged. Encoding considerations: 8-bit text Security considerations: Security considerations specific to uses of this type are discussed in RFC xxxx [[Note to RFC editor: replace xxxx with the RFC number of this document when published]]. RFC 1874 [1] and RFC 3023 [4] discuss security issues common to all uses of XML. Interoperability considerations: The use of this media type body is intended to be generally interoperable. No unique considerations have been identified. Published specification: RFC xxxx [[Note to RFC editor: replace xxxx with the RFC number of this document when published]] Applications which use this media type: This media type is used to convey information regarding media control commands and responses between SIP endpoints particularly for allowing a Video Fast Update intra-frame request. Additional information: Magic Number(s): None. File Extension(s): None. Macintosh File Type Code(s): None. Object Identifier(s) or OID(s): None. Intended usage: Limited Use Person to contact for further information: Name: Orit Levin E-Mail: oritl(a)microsoft.com Other Information/General Comment: None. Author/Change Controller: Orit Levin. 2. URN for XML schema URI: urn:ietf:params:xml:ns:media_control Description: This is the XML namespace URI for XML elements defined by [RFCXXXX] to describe information exchanged between SIP endpoints for media control. It is used in the application/media_control+xml body type. Registrant Contact: Name: Orit Levin E-Mail: oritl(a)microsoft.com Author/Change Controller: Orit Levin. XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=utf-8"/> <title>Namespace for Tight Media Control</title> </head> <body> <h1>Namespace for Tight Media Control</h1> <h2>application/media_control+xml</h2> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> </body> </html> END Thanks Roni Even

2 2

Review requested for SCVP media types
by David A. Cooper 15 Jun '07

15 Jun '07

Information about the four media types defined for the Server-based Certificate Validation Protocol (SCVP) may be found in Appendix A of the current draft of the document: http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-31.txt. For convenience, Appendix A is copied below. Appendix A. MIME Media Type Registrations Four MIME media type registrations are provided in this appendix. A.1 application/scvp-cv-request To: ietf-types(a)iana.org Subject: Registration of MIME media type application/scvp-cv-request MIME media type name: application MIME subtype name: scvp-cv-request Required parameters: None Optional parameters: None Encoding considerations: binary Security considerations: Carries a request for information. This request may optionally be cryptographically protected. Interoperability considerations: None Published specification: IETF PKIX Working Group Draft on Server- based Certificate Validation Protocol (SCVP) Applications that use this media type: SCVP clients Additional information: Magic number(s): None File extension(s): .SCQ Macintosh File Type Code(s): none Person & email address to contact for further information: Ambarish Malpani <ambarish(a)malpani.biz> Intended usage: COMMON Restrictions on usage: This media type can be used with any protocol that can transport digitally signed objects. Author: Ambarish Malpani <ambarish(a)malpani.biz> Change controller: IESG A.2 application/scvp-cv-response To: ietf-types(a)iana.org Subject: Registration of MIME media type application/scvp-cv- response MIME media type name: application MIME subtype name: scvp-cv-response Required parameters: None Optional parameters: None Encoding considerations: binary Security considerations: The client may require that this response be cryptographically protected, or may choose to use secure transport mechanism. DPD responses may be unprotected, but the client validates the information provided in the request. Interoperability considerations: None Published specification: IETF PKIX Working Group Draft on Server- based Certificate Validation Protocol (SCVP) Applications that use this media type: SCVP servers Additional information: Magic number(s): None File extension(s): .SCS Macintosh File Type Code(s): none Person & email address to contact for further information: Ambarish Malpani <ambarish(a)malpani.biz> Intended usage: COMMON Restrictions on usage: This media type can be used with any protocol that can transport digitally signed objects. Author: Ambarish Malpani <ambarish(a)malpani.biz> Change controller: IESG A.3 application/scvp-vp-request To: ietf-types(a)iana.org Subject: Registration of MIME media type application/scvp-vp-request MIME media type name: application MIME subtype name: scvp-vp-request Required parameters: None Optional parameters: None Encoding considerations: binary Security considerations: Carries a request for information. Interoperability considerations: None Published specification: IETF PKIX Working Group Draft on Server- based Certificate Validation Protocol (SCVP) Applications that use this media type: SCVP clients Additional information: Magic number(s): None File extension(s): .SPQ Macintosh File Type Code(s): none Person & email address to contact for further information: Ambarish Malpani <ambarish(a)malpani.biz> Intended usage: COMMON Restrictions on usage: none Author: Ambarish Malpani <ambarish(a)malpani.biz> Change controller: IESG A.4 application/scvp-vp-response To: ietf-types(a)iana.org Subject: Registration of MIME media type application/scvp-vp- response MIME media type name: application MIME subtype name: scvp-vp-response Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: None Interoperability considerations: None Published specification: IETF PKIX Working Group Draft on Server- based Certificate Validation Protocol (SCVP) Applications that use this media type: SCVP servers Additional information: Magic number(s): None File extension(s): .SPP Macintosh File Type Code(s): none Person & email address to contact for further information: Ambarish Malpani <ambarish(a)malpani.biz> Intended usage: COMMON Restrictions on usage: This media type can be used with any protocol that can transport digitally signed objects. Author: Ambarish Malpani <ambarish(a)malpani.biz> Change controller: IESG

2 2

Media type review requested for audio/vorbis and audio/vorbis-config
by Colin Perkins 15 Jun '07

15 Jun '07

The AVT working group requests media type review of the audio/vorbis and audio/vorbis-config media types, defined in section 6 of draft- ietf-avt-rtp-vorbis-05.txt. This draft is currently in working group last call, and we would appreciate comments by 25th June 2007. Thanks, Colin Perkins (AVT co-chair)

4 4

Draft registration for application/vnd.recordare.musicxml
by Michael Good 06 Jun '07

06 Jun '07

Type name: application Subtype name: vnd.recordare.musicxml Required parameters: none Optional parameters: none Encoding considerations: binary Security considerations: This compressed format shares security considerations common to both compressed formats and zip-based formats. Additional security issues associated with this type have not been assessed. Interoperability considerations: none Published specification: Currently in beta test. To be published at: http://www.musicxml.org/dtds/index.html Applications that use this media type: The uncompressed XML version of this format is used by Finale, Sibelius, and over 75 other applications, listed at: http://www.recordare.com/xml/software.html Once out of beta test, we expect many of these applications to add support for the compressed version of this format. Additional information: Magic number(s): File extension(s): mxl Macintosh file type code(s): MXML Person & email address to contact for further information: Michael Good info(a)recordare.com Intended usage: Common Restrictions on usage: none Author: Recordare LLC Change controller: Recordare LLC ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469

1 0

Draft registration for application/vnd.recordare.musicxml+xml
by Michael Good 06 Jun '07

06 Jun '07

Type name: application Subtype name: vnd.recordare.musicxml+xml Required parameters: none Optional parameters: "charset": This parameter has semantics identical to the charset parameter of the "application/xml" media type as specified in RFC 3023. Encoding considerations: Identical to those of "application/xml" as described in RFC 3023, Section 3.2. Security considerations: As this media type uses the "+xml" convention, it shares the same security considerations as described in RFC 3023, Section 10. Additional security issues associated with this type have not been assessed. Interoperability considerations: none Published specification: http://www.musicxml.org/dtds/index.html Applications that use this media type: Finale, Sibelius, and over 75 other applications, listed at: http://www.recordare.com/xml/software.html Additional information: Magic number(s): File extension(s): xml Macintosh file type code(s): Person & email address to contact for further information: Michael Good info(a)recordare.com Intended usage: Common Restrictions on usage: none Author: Recordare LLC Change controller: Recordare LLC ____________________________________________________________________________________ Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/

1 0

Registration of media type atomsvc+xml
by Paul Hoffman 05 Jun '07

05 Jun '07

MIME media type name: application MIME subtype name: atomsvc+xml Mandatory parameters: None. Optional parameters: "charset": This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC3023]. Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], section 3.2. Security considerations: As defined in draft-ietf-atompub-protocol-15.txt In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], section 10. Interoperability considerations: There are no known interoperability issues. Published specification: draft-ietf-atompub-protocol-15.txt Applications that use this media type: No known applications currently use this media type. Additional information: Magic number(s): As specified for "application/xml" in [RFC3023], section 3.2. File extension: .atomsvc Fragment identifiers: As specified for "application/xml" in [RFC3023], section 5. Base URI: As specified in [RFC3023], section 6. Macintosh File Type code: TEXT Person and email address to contact for further information: Joe Gregorio <joe(a)bitworking.org> Intended usage: COMMON Author/Change controller: The IETF

2 2