- Ietf-types - example.com

Change to Registration of media type vnd.solent.sdkm+xml
by J. Clifford Gauntlett 27 Oct '09

27 Oct '09

Name : Cliff Gauntlett Email : cliff&solenttec.net MIME media type name : Application MIME subtype name : Vendor Tree - vnd.solent.sdkm+xml Required parameters : None. Optional parameters : None. Encoding considerations : 8bit This media type may require encoding on transports not capable of handling 8 bit text. Charset UTF-8 is the only supported character set for this MIME type. Security considerations : The document contains an XML description of a variable size sudoku puzzle. The format for the document is a standard xml document which is described in the namespace "http://www.sudokumagic.co.uk/sudokumagicds.xsd". Security precautions regarding xml documents should be used although the document contains no executable code. Interoperability considerations : This file format is intended to be used by an application call SudokuMagic which is available on a variety of platforms. This program currently uses Unicode character representation. Other programs from different vendors may also use this format and interoperability issues should be discussed in the appropriate documentation for those programs. Published specification : Schema definitions are available at "http://www.sudokumagic.co.uk/sudokumagicds.xsd". The current version of the definition is 2.009.10.13001 and maybe updated from time to time. Applications which use this media : SudokuMagicWFE, SudokuMagicPPC, SudokuMagicMAC, SudokuMagicMOB, SudokuMagicSRV, SudokuMagicWS. These are the currently known applications which use the format. Additional information : 1. Magic number(s) : None. 2. File extension(s) : sdkm sdkd sdkg 3. Macintosh file type code : SDKM 4. Object Identifiers: None. None. Person to contact for further information : 1. Name : Cliff Gauntlett 2. Email : cliff&solenttec.net Intended usage : Common Author: Cliff Gauntlett Change controller : Cliff Gauntlett Web URL has been updated as well as current version numbers.

1 0

IETF Types Review: application/cfw
by Eric Burger 27 Oct '09

27 Oct '09

Please review the MIME Type application/cfw, as defined in http://tools.ietf.org/id/draft-ietf-mediactrl-sip-control-framework-11 Cross-posting to mediactrl(a)ietf.org would be greatly appreciated.

2 1

please comment on media-type registrations for MathML
by Paul Libbrecht 07 Oct '09

07 Oct '09

Dear Media-types experts, the last-call period for MathML3 has now launched and is set to end Nov 11th. See the announce at: http://www.w3.org/mid/9F0A2A05-3BCD-4E00-8B63-0DE2419CB98E@ams.org In this specification draft, one can find three registrations for media-types related to MathML in the appendix B: http://www.w3.org/TR/2009/WD-MathML3-20090924/appendixb.html They are copied below. I would love comments on them until Nov 11th. Paul B.1 Media type for Generic MathML This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA. Type name: application Subtype name: mathml+xml Required parameters: none Optional parameters: charset as per [RFC3023] Encoding considerations: same as XML as specified in [RFC3023]. Security considerations: none Interoperability considerations: entities with this media type also have the media type application/xml and may also have the media types application/presentation-mathml+xml or application/content-mathml+xml. Published specification: MathML-3, draft at: http://www.w3.org/TR/MathML3/ Applications that use this media type: (todo) Additional information Magic number(s): see [RFC3023] File extension(s): .mml Windows Clipboard Name: MathML Macintosh file type code(s) MML Macintosh Universal Type Identifier code: public.mathml conforming to public.xml 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 and Change controller: The MathML specification is the product of the World Wide Web Consortium's Math Working Group. The W3C has change control over this specification. B.2 Media type for Presentation MathML This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA. Type name: application Subtype name: mathml-presentation+xml Required parameters: none Optional parameters: charset as per [RFC3023] Encoding considerations: same as XML as specified in [RFC3023]. Security considerations: none Interoperability considerations: This media type is a more specific type than application/mathml+xml. Hence any entity of this type is also of the type application/mathml+xml as well as application/xml. An agent offering this specific media type MUST also offer the application/mathml+xml media type. An agent delivering an entity of this media type SHOULD only do so if it knows the receiving party supports it, for example thanks to the Accept http header, and should otherwise deliver the more generic type. Published specification: MathML-3, draft at: http://www.w3.org/TR/MathML3/ Applications that use this media type: (todo) Additional information: Magic number(s): see [RFC3023] File extension(s): none Windows Clipboard Name: MathML Presentation Macintosh file type code(s) MMLp Macintosh Universal Type Identifier code: public.mathml.presentation conforming to public.mathml (described above) conforming to public.xml 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 and Change controller The MathML specification is the product of the World Wide Web Consortium's Math Working Group. The W3C has change control over this specification. B.3 Media type for Content MathML This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA. Type name: application Subtype name: mathml-content+xml Required parameters: none Optional parameters: charset as per [RFC3023] Encoding considerations: same as XML as specified in [RFC3023]. Security considerations: none Interoperability considerations: This media type is a more specific type than application/mathml+xml. Hence any entity of this type is also of the type application/mathml+xml as well as application/xml. An agent offering this specific media type MUST also offer the application/mathml+xml media type. An agent delivering an entity of this media type SHOULD only do so if it knows the receiving party supports it, for example thanks to the Accept http header, and should otherwise deliver the more generic type. Published specification: MathML-3, draft at: http://www.w3.org/TR/MathML3/ Applications that use this media type: (todo) Additional information: Magic number(s): see [RFC3023] File extension(s): none Windows Clipboard Name: MathML Content Macintosh file type code(s): MMLc Macintosh Universal Type Identifier code: public.mathml.content conforming to public.mathml (described above) conforming to public.xml 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 and Change controller: The MathML specification is the product of the World Wide Web Consortium's Math Working Group. The W3C has change control over this specification.

2 3

Registration of media type video/H264-RCDO
by Tom Kristensen 06 Oct '09

06 Oct '09

Last week we submitted a new version of draft-ietf-avt-rtp-h264-rcdo: http://tools.ietf.org/html/draft-ietf-avt-rtp-h264-rcdo-03 In this version of the draft the complete media type registration was included. The media subtype for RCDO for H.264 is allocated from the IETF tree. The media type registration is attached to this message, for convenience. Cheers, -- Tom

2 1

Re: Review of application/pkix-attr-cert Media Type
by Russ Housley 05 Oct '09

05 Oct '09

I just posted an update. Russ At 01:21 PM 10/5/2009, Bjoern Hoehrmann wrote: >* Russ Housley wrote: > >http://www.ietf.org/id/draft-ietf-pkix-attr-cert-mime-type-01.txt > > > >This document includes the application/pkix-attr-cert media type > >registration. The document is also going through WG Last Call in the > >PKIX WG. Please review. > >In the template, the "Person & email address" part does not properly >separate name and address (like is done under "Author" for example). > >File name extensions are usually given in lower case; if people are >actually to use the "AC" spelling and not "ac", that should be said >more clearly, otherwise it should say "ac" instead. > >The encoding considerations should simply say 7bit, 8bit, or one of >the other values specified in RFC 4288 section 4.8. I believe I said >as much earlier. > >Is there no pattern that could be cited in the magic number section? >-- >Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de >Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de >25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

1 0

Re: Review of application/pkix-attr-cert Media Type
by Russ Housley 05 Oct '09

05 Oct '09

> >http://www.ietf.org/id/draft-ietf-pkix-attr-cert-mime-type-01.txt > > > >This document includes the application/pkix-attr-cert media type > >registration. The document is also going through WG Last Call in the > >PKIX WG. Please review. > >In the template, the "Person & email address" part does not properly >separate name and address (like is done under "Author" for example). > >File name extensions are usually given in lower case; if people are >actually to use the "AC" spelling and not "ac", that should be said >more clearly, otherwise it should say "ac" instead. Thanks, I'll fix these. >The encoding considerations should simply say 7bit, 8bit, or one of >the other values specified in RFC 4288 section 4.8. I believe I said >as much earlier. I guess I missed the point. It is 8bit. >Is there no pattern that could be cited in the magic number section? No really, especially if we want to allow for the version number to in increased in the future. Russ

1 0

Review of application/pkix-attr-cert Media Type
by Russ Housley 05 Oct '09

05 Oct '09

http://www.ietf.org/id/draft-ietf-pkix-attr-cert-mime-type-01.txt This document includes the application/pkix-attr-cert media type registration. The document is also going through WG Last Call in the PKIX WG. Please review. Russ

2 1

Fwd: New Version Notification for draft-murata-kohn-lilley-xml-03
by Chris Lilley 02 Oct '09

02 Oct '09

This is a forwarded message From: IETF I-D Submission Tool <idsubmission(a)ietf.org> To: chris(a)w3.org Date: Thursday, September 24, 2009, 5:56:50 PM Subject: New Version Notification for draft-murata-kohn-lilley-xml-03 ===8<==============Original message text=============== A new version of I-D, draft-murata-kohn-lilley-xml-03.txt has been successfuly submitted by Chris Lilley and posted to the IETF repository. Filename: draft-murata-kohn-lilley-xml Revision: 03 Title: XML Media Types Creation_date: 2009-09-24 WG ID: Independent Submission Number_of_pages: 49 Abstract: This document standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while deprecating text/xml and text/ xml-external-parsed-entity. This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Major differences from [RFC3023] are deprecation of text/xml and text/xml-external-parsed-entity, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, mention of the XPointer Registry, and updating of many references. The IETF Secretariat. ===8<===========End of original message text=========== -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG

6 19

Re: New Version Notification for draft-murata-kohn-lilley-xml-03
by Julian Reschke 30 Sep '09

30 Sep '09

MURATA Makoto wrote: >> So how about changing it just for the HTTP transport then? > > You are proposing to fix HTTP 1.1. Then, you would need to write an > internet draft which would obsolete RFC 2068 and have it approved > by IESG. > ... Actually, it would be RFC2616, not RFC2068. Furthermore, we're actually doing this in the IETF HTTPbis Working Group. So let's rephrase it... do you have an opinion whether an update to HTTP/1.1 *should* make this change? BR, Julian

2 1

Re: Fwd: New Version Notification for draft-murata-kohn-lilley-xml-03
by Julian Reschke 29 Sep '09

29 Sep '09

Julian Reschke wrote: > Chris Lilley wrote: >> ... >> which also brings advice on the use of the charset parameter into line >> with current practice. In brief, the charset parameter should only be >> added if it agrees with the xml encoding declaration. In the absence >> of an explicit charset parameter, the encoding specified by the xml >> encoding declaration is used. (This is a change from RFC 3023, which >> required enforcing us-ascii in that case). >> ... > > Clarifying... this appears to apply only to application/xml, not > text/xml, right? > ... Furthermore, this was already the case in RFC 3023, so is there any change at all? BR, Julian

3 2