- Ietf-types - alvestrand.no

Registration of MIME media type application/pdf-vt-stream
by tim.donahue＠kodak.com 30 Nov '09

30 Nov '09

MIME media type name: application MIME subtype name: pdf-vt-stream Required parameters: None Optional parameters: None Encoding considerations: None Security considerations: As this format is only reusing MIME and restricting it to only refer to PDF files of MIME type application/pdf and ICC files of MIME type application/vnd.iccprofile so this format inherits all known security considerations identified in the respective registrations of those file types. Interoperability considerations: Please refer to ISO 16612-2 Published specification: Currently available as Draft International Standard ISO/DIS 16612-2. This document is presently in ballot. Final document once approved will be published as ISO 16612-2 Graphic technology ? Variable data exchange ? Part 2: Using PDF/X-4 and PDF/X-5 (PDF/VT-1 and PDF/VT-2) The ISO/DIS16612-2 document is available for purchase from the ISO.org website. Applications which use this media type: Intended for communication between a graphical content creator (authoring system) and a graphical content reader that parses and renders the content for display or print. Additional information: None. Magic number(s): The file itself is a MIME stream of content type Multipart/Mixed and has a header field entry X-PDFVT-Stream-version with the value 1 that must be specified ahead of this MIME content type field. File extension(s): Not applicable Macintosh File Type Code(s): None. Person & email address to contact for further information: Tim Donahue, Eastman Kodak Company Tim.Donahue(a)kodak.com Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) LIMITED USE Author/Change controller: ISO Technical Committee 130 / Working Group 2 / Task Force 3 Task force Convener and document editor: Tim Donahue, Eastman Kodak Company, Tim.Donahue(a)kodak.com Secretariat: A. Karin Winkelmann, Secretariat ISO/TC130, Karin.Winkelmann(a)din.de (Any other information that the author deems interesting may be added below this line.)

1 0

Re: please comment on media-type registrations for MathML
by Paul Libbrecht 24 Nov '09

24 Nov '09

Dear media-types-expert, Dear Björn, > Forwarded-from : member-math(a)w3.org > From : "Robert Miner" <robertm(a)dessci.com> > Date : 24 novembre 2009 03:43:50 GMT+01:00 > To : <member-math(a)w3.org> > Archived-At: <http://www.w3.org/mid/D1EFB337111B674B8F1BE155B01C6DD6034CCA68@franklin.cor… > > > > Dear Björn, > > I am writing in response to your comments on the media-type > registrations for MathML given in Appendix B of the Last Call draft of > the MathML 3 Specification. Your original comments are recorded at > http://www.alvestrand.no/pipermail/ietf-types/2009-October/ > 002268.html. > > We have modified Appendix B, and believe we have addressed the issues > you noted. The changes are explained below, and you can see the draft > changes in an editor's draft of the spec located at > > http://monet.nag.co.uk/~dpc/draft-spec/appendixb.html > > Since we need to record the resolution of all Last Call comments, > could we ask you to let us know whether you accept these changes as > addressing your comments? Thanks in advance. > > The specific actions taken are: > > > The first problem I have with this is that there is no word on what > > exactly the various types are for, like if there are any > restrictions > > on what should be in a mathml-content+xml vs a mathml-presentation > +xml > > document, or if the types can be used with MathML 2.0. > > A new introductory section entitled "Selection of Media Types for > MathML Instances" was added to specifically address this issue. The > related text in section 6.2.3 of the spec is essentially summary in > nature, and was therefore left unchanged. It already referred to > appendix B for detailed information on the usage of the media types, > and that information is now given. > > The section carefully defines the presentation and content MathML > vocabularies, and gives a clear rule for determining what media type > should be used for a given MathML instance based on the contents of > that instance. > > The section also contains some explanation and examples to motivate > the usage of the three MathML media types. The section ends by > addressing use of the media types with earlier versions of MathML > > > As per RFC 3023, the charset definition and encoding considerations > > should be referenced as follows, which the proposals fails to do: > > > > Registrations for new XML-based media types under top-level types > > other than "text" SHOULD, in specifying the charset parameter and > > encoding considerations, define them as: "Same as [charset > parameter > > / encoding considerations] of application/xml as specified in RFC > > 3023." > > These sections have been edited to match the proper format. > > > The security considerations are missing (in fact the specification > > as a whole does not have a security considerations section either). > > Security considerations have been added. We have listed both the > generic issues common to similar XML languages, and two issues > specific to MathML: the possible presence of executable code in > semantic annotations, and the (possibly inadvertant) denial of service > risks arising in computational contexts from trying to solve > unsolvable problems. > > > I believe the text you have under "interoperability considerations" > > is misplaced there in all three cases. > > This text has been completely rewritten. Again, there are some > generic considerations common to similar XML languages, as well as > several MathML specific issues. In particular, lack of versioning > information in MathML instances introduces a backward compatibility > concern, and the result of evaluating MathML expressions is not > guaranteed to be the same in different computational systems. > > > I note that under "Applications that use this media type" you have > > "(todo)". Going to Last Call with "todo" markers left is not a good > > practise. I note that the purpose of this field is to give a general > > idea of what kind of applications use it, not to list individual > > software products. > > Thank you for the clarification on the purpose. We have filled out > the section appropriately. > > > Under "Person & email address to contact for further information" > > the proposal fails to properly separate name and email address, use > > something like "Name <address>" instead. I do not think having a > > generic W3C / W3C Webmaster combination there is a good practise > > Following other media type registrations under the BCP13 process, we > have changed this to list Paul as the person, with the Math WG group > mailing list for the address, followed by a pointer to the public W3C > Math web site for additional information. > > --Robert > >

1 0

Registration of media type application/xtm+xml
by Lars Marius Garshol 20 Nov '09

20 Nov '09

I intend to submit the following media type registration to the IESG for registration with IANA. However, before then I would welcome community review and feedback on the proposed registration. If you see any problems, please let me know. Assuming that the appropriate form for such a media type registration would be an RFC-style document I wrote one up using the xml2rfc syntax and published it here: http://www.isotopicmaps.org/sam/xtm-rfc.html The actual registration part is included below. --------------------------------------------------------------------- This is a media type registration as defined in RFC 4288, "Media Type Specifications and Registration Procedures" [RFC4288]. *MIME media type name:* application *MIME subtype name:* xtm+xml *Required parameters:* none *Optional parameters:* charset Same as charset parameter of application/xml, defined in RFC 3023 [RFC3023]. *Encoding considerations:* Same as encoding considerations of application/xml, defined in RFC 3023 [RFC3023]. *Security considerations:* See Section 5. *Interoperability considerations:* _NEED TO WRITE THIS PART_ *Published specification:* See the Topic Maps Data Model [ISO13250-2] and the XTM specification [ISO13250-3]. *Applications which use this media type:* XTM is device-, platform-, and vendor-neutral and is supported by a range of applications and web services. *Magic number(s):* none Although no byte sequences can be counted on to consistently identify XTM, XTM documents will have the sequence "http://www.topicmaps.org/xtm/" to identify the XTM namespace. This will usually be near the top of the document. *File extensions(s):* .xtm *Macintosh File Type Code(s):* "xtm " *For further information:* contact the editors, Lars Marius Garshol <larsga(a)garshol.priv.no> and Graham Moore <graham.moore(a)networkedplanet.com>, or ISO SC34. More information may be found on the website of ISO SC34 WG3: <http://www.isotopicmaps.org>. *Intended usage:* COMMON *Author/Change controller:* The XTM standard was produced by ISO SC34, which has change control over the standard. --------------------------------------------------------------------- --Lars M. http://www.garshol.priv.no/tmphoto/ http://www.garshol.priv.no/blog/

4 7

Re: Change Controller
by Julian Reschke 18 Nov '09

18 Nov '09

Martin J. Dürst wrote: > > > On 2009/11/17 19:41, Julian Reschke wrote: >> Martin J. Dürst wrote: >>> Hello Julian, >>> >>> A tiny bit more of context in your mail would have been helpful. >>> Apparently, you are talking about updates for the types text/html and >>> application/xhtml+xml, which may be sent to this list in the future. >> >> Indeed. >> >>> As for your specific concern below, these registrations go through >>> IESG approval, so it would be the IESG who has to figure out whom to >>> believe in the case of a conflict, not IANA. >>> ... >> >> <http://tools.ietf.org/html/rfc4288#section-9>: >> >> The owner of a media type may pass responsibility to another person >> or agency by informing the IANA and the ietf-types list; this can be >> done without discussion or review. >> >> So it appears that just changing the change controller does not require >> IESG approval (HTML5 does more than that; I'm just trying to understand >> the procedure in cases where *just* the ownership changed). > > Immediately afterwards, it says: > > The IESG may reassign responsibility for a media type. The most > common case of this will be to enable changes to be made to types > where the author of the registration has died, moved out of contact > or is otherwise unable to make changes that are important to the > community. > > So if e.g. the WhatWG went havoc and unilaterally sent the IANA a change > request to be the only owner of text/html, the IESG could simply > reassing it back to W3C (or vice versa). What if one of the change controllers did send a change request *not* changing the ownership, but something else. Would IANA confirm with other parties listed as change controller? > ... BR, Julian

2 1

Change Controller
by Julian Reschke 17 Nov '09

17 Nov '09

Hi, looking for feedback on who can be a change controller...: HTML5 currently says: "Change controller: W3C and WHATWG" (<http://dev.w3.org/html5/spec/Overview.html#iana>) I'm concerned that this may become a problem if, in the future, W3C and WHATWG would disagree about a change. Is IANA going to accept two separate groups as "change controller"? Best regards, Julian

2 3

Re-registration of media type video/H264
by Tom Taylor 11 Nov '09

11 Nov '09

draft-ietf-avt-rtp-rfc3984bis-08.txt has passed Working Group Last Call in the AVT Working Group. Section 8.1 provides the media type registration template for media type video/H264, which was first registered by RFC 3984. The bis document adds a number of new parameters. Comments on the registration are welcome. Tom Taylor AVT Co-Chair

1 0

[widgets] Media Type Registration for application/widget
by Marcos Caceres 28 Oct '09

28 Oct '09

Dear IETF, As part of the Widgets 1.0: Packaging and Configuration Specification progressing to Last Call, the W3C Web Applications Working Group would like to begin registration procedures for the "application/widget" MIME type. We have written a draft of the registration text for you to review and comment (full text below). The section in our specification that defines the registration can be found here: http://dev.w3.org/2006/waf/widgets/#media-type-registration-for-applicationw Our Last Call Review Period ends 19 of November, 2009. Kind regards, Marcos ------------ Media Type Registration for application/widget This appendix registers a new MIME media type, "application/widget" in conformance with BCP 13 and W3CRegMedia. This registration is for community review and will be submitted to the IANA. Type name: application subtype name: widget Required parameters: None. Optional parameters: None. Encoding considerations: Widget packages are binary data and thus are encoded for MIME transmission. As a widget package is binary, it requires encoding on transports not capable of handling binary. The same guidelines that apply to application/octet-stream apply to widget packages (see [MIME]). Security considerations: In addition to the security considerations specified for Zip files in the [Zip-MIME] registration, there are a number of security considerations that need to be taken into account when dealing with widget packages and configuration documents. As the configuration document format is [XML] and will commonly be ecoded using [Unicode], the security considerations described in [XML-MIME] and [UTR36] apply. In additon, implementers need to impose their own implementation-specific limits on the values of otherwise unconstrained attribute types, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. The configuration document allows authors, through the feature element, to request permission to enable third-party runtime components and APIs. As these features are outside the scope of this specification, significant caution needs to be taken when granting a widget the capability to use a feature. Features themselves define their own security considerations. Widget packages will generally contain ECMAscript, HTML, CSS files, and other media, which are executed in a sand boxed environment. As such, implementers need to be aware of the security implications for the types they support. Specifically, implementers need to consider the security implications outlined in the [CSS-MIME] specification, the [ECMAScript-MIME] specification, and the [HTML-MIME] specification. As widget packages can contain content that is able to simultaneously interact with the local device and a remote host, implementers need to consider the privacy implications resulting from exposing private information to a remote host. Mitigation and in-depth defensive measures are an implementation responsibility and not prescribed by this specification. However, in designing these measures, implementors are advised to enable user awareness of information sharing, and to provide easy access to interfaces that enable revocation of permissions. As this specification relies on the standardized heuristics for determining the content type of files defined in the [SNIFF] specification, implementers need to consider the security considerations discussed in the [SNIFF] specification. As this specification allows for the declaration of IRIs within certain elements of a configuration documents, implementers need to consider the security considerations discussed in the [IRI] specification. Interoperability considerations: Some issues can arise with regards to character encodings of file names, the length of zip relative paths, and the use of certain strings as file names. This specification does not put a restriction on the byte length of a Zip relative path, so a user agent needs to be able to deal with Zip relative paths that have lengths longer than 250 bytes. As some operating systems have restrictions on how long a path length can be, authors need to keep the lengths of relative paths at less than 250 bytes. Unicode code points may require more than one byte to encode a character, which can result in a path whose length is less than 250 characters but whose size is greater than 250 bytes. Authors need to be aware that, at the time of publication, there are interoperability issues with regards to using characters outside the safe-chars range for file or folder names in a Zip archive when using Zipping tools bundled with operating systems. The interoperability issues have arisen from non-conforming implementations of the [ZIP] specification across operating systems: very few, if any, correctly support encoding file names in Unicode. In the case where the Zip relative path is encoded using [UTF-8], the language encoding flag (EFS) needs to be set. If an author chooses to use the utf8-chars, they need to thoroughly test their widgets on various platforms prior to distribution; otherwise it is suggested that authors restrict file and folder names to the safe-chars (characters in the US-ASCII range). In addition, having excessively long path names (e.g. over 120 characters) can also result in interoperability issues on some operating systems. Authors need to avoid using forbidden characters when naming the files used by a widget. These characters are reserved to maintain interoperability across various file systems and with [URI]s. Authors need to avoid using the following words as either a folder or a file-name in a Zip relative path as they are reserved by some operating systems (case-insensitive): CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, CLOCKS$. For example, the following names are ok: "CON-tact.txt", "printer.lpt1", "DCOM1.pdf". However, "com3.txt" "Lpt1", "CoM9.gif" would not be. In addition, authors need to avoid having a "." U+002E FULL STOP as the last character of a file or folder name as some operating systems will remove the character when the file is extracted from the Zip archive onto the device. Furthermore, avoid having the space character (SP) at the start or end of a file name; and take caution when using the "+" U+002B PLUS SIGN, as it might cause issues on some operating systems. Published specification: http://www.w3.org/TR/widgets/ Applications that use this media type: User agents that claim conformance to this specification. Magic number(s): 50 4B 03 04 File extension(s): wgt Macintosh file type code(s): None. Person & email address to contact for further information: Steven Pemberton, member-webapps(a)w3.org Intended usage: Common. Restrictions on usage: None. Author: The W3C's Web Applications Working Group

1 0

[widgets] Media Type Registration for application/widget
by Marcos Caceres 28 Oct '09

28 Oct '09

Dear IETF, As part of the Widgets 1.0: Packaging and Configuration Specification progressing to Last Call, the W3C Web Applications Working Group would like to begin registration procedures for the "application/widget" MIME type. We have written a draft of the registration text for you to review and comment (full text below). The section in our specification that defines the registration can be found here: http://dev.w3.org/2006/waf/widgets/#media-type-registration-for-applicationw Our Last Call Review Period ends 19 of November, 2009. Kind regards, Marcos ------------ Media Type Registration for application/widget This appendix registers a new MIME media type, "application/widget" in conformance with BCP 13 and W3CRegMedia. This registration is for community review and will be submitted to the IANA. Type name: application subtype name: widget Required parameters: None. Optional parameters: None. Encoding considerations: Widget packages are binary data and thus are encoded for MIME transmission. As a widget package is binary, it requires encoding on transports not capable of handling binary. The same guidelines that apply to application/octet-stream apply to widget packages (see [MIME]). Security considerations: In addition to the security considerations specified for Zip files in the [Zip-MIME] registration, there are a number of security considerations that need to be taken into account when dealing with widget packages and configuration documents. As the configuration document format is [XML] and will commonly be ecoded using [Unicode], the security considerations described in [XML-MIME] and [UTR36] apply. In additon, implementers need to impose their own implementation-specific limits on the values of otherwise unconstrained attribute types, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. The configuration document allows authors, through the feature element, to request permission to enable third-party runtime components and APIs. As these features are outside the scope of this specification, significant caution needs to be taken when granting a widget the capability to use a feature. Features themselves define their own security considerations. Widget packages will generally contain ECMAscript, HTML, CSS files, and other media, which are executed in a sand boxed environment. As such, implementers need to be aware of the security implications for the types they support. Specifically, implementers need to consider the security implications outlined in the [CSS-MIME] specification, the [ECMAScript-MIME] specification, and the [HTML-MIME] specification. As widget packages can contain content that is able to simultaneously interact with the local device and a remote host, implementers need to consider the privacy implications resulting from exposing private information to a remote host. Mitigation and in-depth defensive measures are an implementation responsibility and not prescribed by this specification. However, in designing these measures, implementors are advised to enable user awareness of information sharing, and to provide easy access to interfaces that enable revocation of permissions. As this specification relies on the standardized heuristics for determining the content type of files defined in the [SNIFF] specification, implementers need to consider the security considerations discussed in the [SNIFF] specification. As this specification allows for the declaration of IRIs within certain elements of a configuration documents, implementers need to consider the security considerations discussed in the [IRI] specification. Interoperability considerations: Some issues can arise with regards to character encodings of file names, the length of zip relative paths, and the use of certain strings as file names. This specification does not put a restriction on the byte length of a Zip relative path, so a user agent needs to be able to deal with Zip relative paths that have lengths longer than 250 bytes. As some operating systems have restrictions on how long a path length can be, authors need to keep the lengths of relative paths at less than 250 bytes. Unicode code points may require more than one byte to encode a character, which can result in a path whose length is less than 250 characters but whose size is greater than 250 bytes. Authors need to be aware that, at the time of publication, there are interoperability issues with regards to using characters outside the safe-chars range for file or folder names in a Zip archive when using Zipping tools bundled with operating systems. The interoperability issues have arisen from non-conforming implementations of the [ZIP] specification across operating systems: very few, if any, correctly support encoding file names in Unicode. In the case where the Zip relative path is encoded using [UTF-8], the language encoding flag (EFS) needs to be set. If an author chooses to use the utf8-chars, they need to thoroughly test their widgets on various platforms prior to distribution; otherwise it is suggested that authors restrict file and folder names to the safe-chars (characters in the US-ASCII range). In addition, having excessively long path names (e.g. over 120 characters) can also result in interoperability issues on some operating systems. Authors need to avoid using forbidden characters when naming the files used by a widget. These characters are reserved to maintain interoperability across various file systems and with [URI]s. Authors need to avoid using the following words as either a folder or a file-name in a Zip relative path as they are reserved by some operating systems (case-insensitive): CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, CLOCKS$. For example, the following names are ok: "CON-tact.txt", "printer.lpt1", "DCOM1.pdf". However, "com3.txt" "Lpt1", "CoM9.gif" would not be. In addition, authors need to avoid having a "." U+002E FULL STOP as the last character of a file or folder name as some operating systems will remove the character when the file is extracted from the Zip archive onto the device. Furthermore, avoid having the space character (SP) at the start or end of a file name; and take caution when using the "+" U+002B PLUS SIGN, as it might cause issues on some operating systems. Published specification: http://www.w3.org/TR/widgets/ Applications that use this media type: User agents that claim conformance to this specification. Magic number(s): 50 4B 03 04 File extension(s): wgt Macintosh file type code(s): None. Person & email address to contact for further information: Steven Pemberton, member-webapps(a)w3.org Intended usage: Common. Restrictions on usage: None. Author: The W3C's Web Applications Working Group

1 0

Registration of MIME media type application/framework-attributes+xml
by Eric Burger 28 Oct '09

28 Oct '09

[Thanks to Martin... specification is at http://tools.ietf.org/id/draft-ietf-mediactrl-sip-control-framework-11 ] MIME media type name: application MIME subtype name: framework-attributes+xml Required parameters: (none) Optional parameters: Same as charset parameter application/xml as specified in RFC 3023. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023. Security considerations: No known security considerations outside of those provided by core Media Control Channel Framework. Interoperability considerations: This content type provides common constructs for related Media Control Channel packages. Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.] Applications which use this media type: Implementations of appropriate Media Control Channel packages. Additional Information: Magic Number(s): (none) File extension(s): (none) Macintosh File Type Code(s): (none) Person & email address to contact for further information: Chris Boulton <chris(a)ns-technologies.com> Intended usage: LIMITED USE Author/Change controller: The IETF Other information: None.

1 0

Registration of MIME Media Type application/cfw
by Eric Burger 28 Oct '09

28 Oct '09

[Thanks to Martin... specification is at http://tools.ietf.org/id/draft-ietf-mediactrl-sip-control-framework-11 ] MIME media type name: application MIME subtype name: cfw Required parameters: None Optional parameters: None Encoding considerations: See section 4 of RFC XXXX Security considerations: See Section 12 of RFC XXXX. Interoperability considerations: Endpoint compliant to this specification must use this MIME type. Receivers who cannot support this specification will reject using appropriate protocol mechanism. Published specification: RFC XXXX Applications that use this media type: Media Control Channel compliant applications. Additional information: None Person and email address to contact for further information: Chris Boulton: chris(a)ns-technologies.com Intended usage: COMMON Restrictions on usage: Should be used only in conjunction with this specification, RFC XXXX. Author: Chris Boulton Change controller: IETF MediaCtrl working group, delegated from the IESG.

1 0