- Ietf-types - example.com

Request for review: draft-ietf-mmusic-sdp-media-content-03.txt
by Colin Perkins 13 Apr '06

13 Apr '06

The MMUSIC working group is considering draft-ietf-mmusic-sdp-media- content-03.txt: This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream in more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big screen or small screen) based on its content. It has been suggested that members of the ietf-types list may have experience with this type of attribute in other areas. Accordingly, this message is to solicit cross-area review of the draft. We would be grateful if any comments could be provided before 1st May 2006. Thanks, Colin (mmusic co-chair)

1 0

Re: media type review requested for application/auth-policy+xml
by Mark Baker 13 Apr '06

13 Apr '06

Hi, On 4/13/06, Tschofenig, Hannes <hannes.tschofenig(a)siemens.com> wrote: > > - security section should also reference sec 10 of RFC 3023. > > Why do you think so? > I read through Section 10 of RFC 3023 and I don't think that the aspects > there are applicable for our usage environment. The aspects of security described in that section are quite generic, so I'd be surprised if that were the case. Just as one example, do you rule out the use of external entities with auth-policy+xml? If not, then that section is relevant as it describes some potential security problems with their use. FWIW, I think any +xml type should reference it as a matter of course. > > - I'd recommend picking a file extension specific to this media type, > > as many Web servers come pre-configured to serve .xml files as > > application/xml, or even an RSS media type. > I don't care about the file extension. Can you > suggest something reasonable? How about "apxml"? I checked "apx", but it's been used before; http://filext.com/detaillist.php?extdetail=apx&Search=Search Cheers, Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca

1 0

Media Type Dilution
by Greg Smith 13 Apr '06

13 Apr '06

I was pointed to this mailing list as the most appropriate to post the following email. These originally were two postings made previously to the AVT working group. My first post of this on Sunday prior to my subscription resulted in moderation-land. My apologies if you receive this multiple times. It appears that alternate means are being deployed to differentiate between major media types in part because the original uses of the Media Type are not being strictly followed. Please exuse me if these issues have been addressed before, I would appreciate a link or two to the appropriate postings. I have recently been asked about the Media Type being able to distinguish between audio and video. It was stated to me that, for example, application/ogg, application/smil, and application/smil+xml each can contain either audio, video, or test, and these Media Type registrations do not distinguish between audio and video. My response was that the Media Type *should* differentiate between audio, video, and other major types of media. But the top-level Media Types appear to be suffering from dilution. RSS Media (excerpt from version 1.1.0) In addition the latest draft of the Media RSS Specification justifies the addition of a "medium" attribute that differentiates between major "mediums" (image | audio | video | document | executable) because "it simplifies decision making on the reader side, as well as flushes out any ambiguities between MIME type and object type" This appears to model EXACTLY the original purpose of the Media Type (section 3 of http://www.isi.edu/in-notes/rfc2046.txt where we see: text | image | audio | video | application, as well as composite types: multipart | message, and later-adopted "model"). ATOM While ATOM (http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt) Proposes to differentiate between an "entry" (in ATOM format) and all other "media". It seems like a very useful construct (within ATOM) to be able to differentiate collections based on both Top-level Media Type and Sub-type. Further dilution of the Top-level Media Types seems contradictory to the entire purpose of Media Type registrations. RSS and Atom Feed Auto-Discovery for Internet TV http://maketelevision.com/log/rss_and_atom_feed_auto-discovery_for_internet… Makes use of an attribute: media="tv", to differentiate between what (in my opinion) should be Top-level Media Type (using for example, "video/*"). Granted that these examples are not standards (yet), they substantiate the view that Top-level Media Types are not sufficient for media differentiation for purposes of dispatch. Ogg As a concrete example of the dilution, application/ogg is the Media Type for use of all audio and/or video that is in the Ogg file format. Ogg often contains vorbis-encoded audio or theora-encoded video. It seems appropriate, then, that either audio/ogg and video/ogg, or audio/vorbis and video/theora, be appropriated for use for files using the Ogg format. I found that in Feb 2006, there was an application that included appropriation of audio/vorbis, specifically for RTP transport, and not for Ogg file format. This concerns me only because audio/vorbis seems very appropriate to use for Ogg file format Vorbis-encoded audio and its appropriation for use only using RTP "container" format seems premature or somehow misguided. Over the past year, I've had quite an introduction to video container formats vs. encoding formats. I maintain the "Media Chart" for Pocket PCs at http://www.feederreader.com/mediachart.html , which attempts to sort out some of the confusion. Part of the issue is that Major Type, Media Container, and Media Encoding are variously intertwined and mixed. But not essentially addressed by the Media Type specification. And because these issues are at a level above individual Media Types, it seems they would need to be addressed outside any Media Type application. These issues appear to me to be ripe for "de-confusioning" and it occurred to me that the organization responsible for Media Types would be the place to start. I'm open the the suggestion that I am not fully aware of how Media Types are used in their entirety. I am, however, suggesting that there is a growing problem with use of Media Types in determining dispatch requirements. Functional Interpretation Although I have not seen dispatching based on Media Types generically described in the RFCs that I reviewed, I have found the description in a w3c document "Client handling of MIME headers" [1] and RFC3023 Section 13 (Appendix A) [2]. This seems to me to be a major use and benefit of defining appropriate Media Types, especially with respect to the assignment of Sub-types within the appropriate Top-level types. Common browsers and operating systems both allow dispatching based on Media Types, in addition to the "similar-to-dispatching" uses I mentioned previously in ATOM, RSS Media, and Autodiscovery. Even at the operating system or the browser level, this sometimes run into problems for the user where a particular audio or video Media Container contains a Media Encoding that is not decodable by the application that has been associated based on the Media Type. Terminology Interpretation RFC4288 Section 4.1 "Functionality Requirement" states that "Media types MUST function as an actual media format." The next sentence states "Registration of things that are better thought of as a transfer encoding...are not allowed." and then goes on to give base64 as an example of a transfer encoding. It is still unclear which, if any, of the following categories (using my prior terminology) are construed as a "transfer encoding": Major Type, Media Container, and Media Encoding. To me, these "categories" are the logical way of distinguishing audio and video media simply because these are the broad categories determining how and if a particular file can be played on any particular system. "Major Type" clearly corresponds to top-level Media Type (audio, video, etc.). Media Containers (such as Ogg, MPEG-4 Part 14, "AVI", "MOV") clearly do *not* correspond to RFC4288 Section 4.1 "Transfer Encoding" and clearly correspond to actual media formats. So the remaining question is: do Media Encodings commonly in use correspond to "transfer encodings", in which case they do not qualify as distinct Media Types. As examples of Media Encoding I offer: Vorbis (audio), Theora (video), MPEG-4 Part 2 (video), MPEG-4 Part 3 (audio), MPEG-4 Part 10 (video). A deeper and more exhaustive survey of current actual Media Type registrations would be useful here. Part of the issue may be that "transfer encoding" in the sense of RFC4288 Section 4.1 seems to refer to "lossless," "reversible," and "universally decodable". Such is not the case with many audio and/or video encodings. Based on this interpretation, I would argue that Transfer Encodings do not refer to the common audio and/or video encodings, and therefore that these audio and video encodings qualify for Media Type registration. Possible Solution The danger is that if every combination of Media Containers and Media Encodings were registered as distinct Media Types, the result would be an astronomical increase in the number of Media Types and it would increase the number, if not the complexity, of the dispatch rules within operating systems and browsers. It seems one way around this might be to use a "+suffix" mechanism (obviously specified such that it is backward compatible with RFC3023), or some other "extension". It could be specified that only Media Containers qualify as a Media Sub-type, and that one or more (optional) suffixes would indicate the contained media encodings. And that for containers that can contain or do commonly contain only audio, then they be registered under the audio top-level type. For contains that can contain or do commonly contain video (with synchronized audio), they should be registered as a video top-level Media Type. For Media Containers that serve both functions (including audio only), they should be registered as audio and video top-level Media Types. With the added "Encoding extension" mechanism, there may be complications in that current dispatching mechanisms are "fixed" meaning that the media dispatchers expect a fixed string match of Media Type to dispatchee. This does not easily permit interpretation of added-in-arbitrary-order suffixes. To solve this problem, the order of suffixes could be programmatically determined (for example, either absolute alphabetical or alphabetical within major groups of audio, video, other). This way, only one permutation of each combination of Media Encodings would need to be added. Summary I'm not sure if this is viewed as a problem by others, but it seems to be a serious issue that is beginning to be "worked around" outside of, and parallel to, the Media Type definitions in several different and incompatible ways. Inclusion of more strict interpretation and differentiation of top-level types and/or formal recognition of Media Containers and Media Encodings within the Media Type system seems like significant and appropriate improvements to Media Type registration. References [1] "Client handling of MIME headers" http://www.w3.org/2001/tag/doc/mime-respect-20030709 "The architecture of the Web depends on applications making dispatching and security decisions for resources based on their Internet Media Types and other MIME headers." http://www.w3.org/2001/tag/doc/mime-respect.html The current version states "For example, HTTP and MIME use the value of the "Content-Type" header field to indicate the Internet media type of the representation, which influences the dispatching of handlers and security-related decisions made by recipients of the message." Section 3.1 A media type is not simply an indication of data format; it also refers to a preferred interpretation of that data format. This preferred interpretation may impact the recipient's functional decisions, such as whether the data is rendered, stored, or executed. In practice, media types are often used as the key for selecting an appropriate handler to interpret the data received. It is possible for a single data format to be associated with multiple media types and for a single media type to describe a superset of many different data formats. --- end excerpt [2] http://www.ietf.org/rfc/rfc3023.txt Greg Smith __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

AW: media type review requested for application/auth-policy+xml
by Tschofenig, Hannes 13 Apr '06

13 Apr '06

Hi Mark, thanks for your comments. > Some comments; > > - I'd suggest removing the UTF-8 default, because in the absence of a > charset parameter the XML document itself would be self-descriptive > about its encoding. I'd recommend simply punting to application/xml's > definition. Fine for me. > > - security section should also reference sec 10 of RFC 3023. Why do you think so? I read through Section 10 of RFC 3023 and I don't think that the aspects there are applicable for our usage environment. > > - I'd recommend picking a file extension specific to this media type, > as many Web servers come pre-configured to serve .xml files as > application/xml, or even an RSS media type. I don't care about the file extension. Can you suggest something reasonable? Ciao Hannes > > Cheers, > > Mark. > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca >

1 0

Re: [cellml-discussion] Review solicited forapplication/cellml-1.0+xmlandapplication/cellml-1.1+xml
by Andrew Miller 12 Apr '06

12 Apr '06

Quoting Matt Halstead <matt.halstead(a)auckland.ac.nz>: > Just to add my two cents worth. > > I think a single content-type would be fine in practice. It basically > gives us the first and rather important filter that plants us in the > CellML domain. I think from then on we are free to implement any > services we want that allow an application to probe a piece of content. > > This discussion seems to be mixing some interpretations of the > extensibility and backwards compatibility of XML standards with the > extensibility and backwards compatibility of the model language and > rules represented by the CellML/XML. I see a similar problem with > XMI, essentially one is free to implement an unlimited array of > metamodels - e.g. UML (and versions of those therein). I can't > imagine them wanting to support a content type for every utility of > XMI. At present I don't even think XMI has its own mime-type. I'm not sure that is a parallel - only backwards incompatible changes to XMI itself(I am not sure if there have ever been any) would need new MIME types, not changes to the metadata representation on top. Essentially, in the CellML case, we have three layers: 1) XML / XML infoset 2) CellML (data) 3) RDF metadata and extension elements. (metadata and extension information) We can consider 1 stable for all intents and purposes. 2 is less stable(new specifications are rare, but when they do happen, will break backwards compatibility). 3 is completely unstable, as arbitrary organisations can define new metadata/extension elements at any time. However, these changes do not break backwards compatibility for other metadata, or 'layer 2 compatibility'. I don't think anyone is proposing a new media type every time layer 3 changes, which is roughly equivalent to the new media type for every XMI example. However, a new media type layer 2 changes seems sensible, and within the normal reasons for defining media types(i.e. a new incompatible format). > > With CellML, the kind of backwards compatability we would break by > adding new structures are nearly always because the mathematical > model without these becomes unsound and so a piece of software > reading only say CellML 1.0 will likely produce an invalid > mathematical model. There are other axis to this; for example, the > mathematical formulation of the model. At present we leave it up to > the software to guess (by reading the model) or we simply assume it > is limited to sets of ordinary differential equations in R.H.S form. MathML expressions are supposed to be declarative, rather than procedural, and as such, the core model does not define how software is supposed to evaluate it. Therefore, I don't believe that it makes sense to define new media types based on the usual way of evaluating a model(i.e. having a application/cellml-1.1+xml type is quite distinct from having a application/cellml-1.1-system-of-odes+xml type, because the former is describing the format in which a model is in, while the latter is abusing media types to make a suggestion to certain types of software as to how the content should be used). > This is an axis that we need to provide details on in the metadata > and provide a webservice for, so that applications can in the future > query such details to see if they can actually make use of them. Kind > of like querying an XMI file to see if it is the right version of UML > for your needs. I agree that information on the evaluation of models should be in the metadata, but I wouldn't extend this to the version of CellML, as the metadata is(at least conceptually) built on top of CellML, and so requires CellML to be working first. > > I don't see the problem (and I see it as more flexible) to provide a > web service for CellML model content that returns the cellml versions > that it can be represented in soundly and that offers to return the > model in whatever form is requested. A classic example is someone > wanting us to return a model in CellML 1.0 form that was modelled > using CellML 1.1 (that has the imports structure). We know that this > is a simple flattening to get it into 1.0 form and can do this for > the requester. I cannot think of a way to do this(robustly, i.e. allowing for fallback on earlier versions if a later one is not available) in one round-trip without either adding a new header(not good for web-based applications), adding extra information to the response entity body on top of the XML, or checking the namespace of the response. It seems unwise to define our own non-standard content-negotiation protocol based on URL mangling(especially if it adds round-trips to the protocol) when there is a perfectly good one in HTTP. Of course, repository software which uses Accept: headers for content negotiation could still allow this to be overriden by query parameters on the URL, to allow the desired model to be downloaded and saved in a CellML-unaware browser for later use. > > It does mean that an existing piece of software needs to be upgraded > to manage the handshake, but it is just as likely it needs to be > upgraded to now send requests using the new content-type it wanted to > ask for; so I don't really see much of an invasion on old software in > those cases. Without knowing what protocol you had in mind, it is hard to compare this with the Accept: situation, but with accept and Content-Type headers: 1) You can just give one URL to everyone, e.g. http://www.example.org/repository/MyFavouriteModel.xml a) Users with a CellML unaware browser can visit that file an get a CellML file(repository decides what version they want). The browser will send a single request and get the file back. If the user has set up 'helpers' or similar in their browser, a version appropriate one will be launched based on the Content-Type. b) Tools which only support some versions of CellML send a request, and get their preferred version(if the repository knows how to convert to that version). The tool knows what version it got from the Content-Type header, and if it got a version it doesn't support, can give an error advising the user. c) Putting XML files on a static web-server still works(provided that the tools can handle CellML documents with text/xml or application/xml media types). d) Only one round trip required, with no non-standard/extension headers. Best regards, Andrew Miller ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

2 1

RE: Registration of MIME media type Application/Vendor Tree vnd.hp-jlyt (mime-media-type)
by Gaash, Amir 11 Apr '06

11 Apr '06

Hello IANA Following your request, I filed the online form so it goes into your ticketing system. Thank you Amir ------------------------------------------------------------------------ - Name : Amir Gaash Email : amir.gaash(a)hp.com MIME media type name : Application MIME subtype name : Vendor Tree - vnd.vnd.hp-jlyt Required parameters : None Optional parameters : None Encoding considerations : binary This media type may require encoding on transports not capable of handling binary. Security considerations : There are no known security issues associated with this type. The file contains no executable content. Interoperability considerations : None Published specification : Job Layout (JLYT) Software Development Kit is available at http://new.hpdevelopersolutions.com/spp/Public/Sdk/SdkPublicDownload.asp x The Job Layout (JLYT) language is the HP Indigo Digital Press internal language used to define job structure, document layout and essential job ticket information. JLYT enables the description of objects, pages, documents and jobs. JLYT can be used to describe a range of jobs, from simple short run jobs to imposed documents and even complex variable data printing (personalization) jobs. If you are a developer who seeks the ability to submit jobs in the native language of the press, you can use the Job Layout (JLYT) SDK that includes the language definition and an API. While JLYT is the description language use for job and page definition, standard graphic art formats, as found in the description specification, should be used to represent the actual content data. To obtain this kit please use the Submit Business Proposal for Indigo Digital Press at the home page of this site. Applications which use this media : Additional information : 1. Magic number(s) : %jlyt 2. File extension(s) : jlt 3. Macintosh file type code : TEXT 4. Object Identifiers: jlyt Person to contact for further information : 1. Name : Amir Gaash 2. Email : amir.gaash(a)hp.com Intended usage : Common Author/Change controller : -----Original Message----- From: IANA [mailto:iana@iana.org] Sent: Monday, April 10, 2006 18:56 To: Gaash, Amir Cc: ietf-types(a)iana.org Subject: RE: Registration of MIME media type Application/Vendor Tree vnd.hp-jlt (mime-media-type) Dear Amir, It would be very helpful if you could complete the online form so that your request can go directly into our ticketing system. Please see: http://www.iana.org/cgi-bin/mediatypes.pl We look forward to receiving your template. Thank you, IANA ________________________________ From: Gaash, Amir [mailto:amir.gaash@hp.com] Sent: Monday, April 10, 2006 1:55 AM To: ietf-types(a)iana.org; iana(a)iana.org Subject: Registration of MIME media type Application/Vendor Tree vnd.hp-jlt Hello We would like to make a registration for "application/vnd.hp-jlt" Can you assist me with the required actions? Here below is more information on our request. Best regards Amir ------------------------------------------------------------------------ ---- -- MIME media type name: application MIME media subtype name: vnd.hp-jlt Required parameters: N/A Optional parameters: N/A Encoding considerations: N/A Security considerations: This file does not contain any executable content. It contains instructions for the HP PPML job consumer to refer to JLT image files, as appropriate to the job design. Interoperability considerations: N/A Published specification: JLT is an HP Press job and images format. Specifications are available from HP per demand. Applications which use this media type: HP Indigo Press 5000, HP Indigo Yours Truly Designer Additional information: Magic Number(s): N/A File Extension(s): .jlt Macintosh File Type Code(s): N/A Person and email address for further information: Amir Gaash, amir.gaash(a)hp.com <mailto:amir.gaash@hp.com> Intended usage: Common Author / Change Controller: Amir Gaash Hewlett-Packard Kiryat Weizmann P.O.Box 150 Rehovot 76101 Israel Tel: +972 8 9381854 Fax: +972 8 9381341 Email: amir.gaash(a)hp.com Mime Type: application/vnd.hp-jlt; charset=iso- Notes:

1 0

Request for review of draft-taylor-types-example-02.txt
by Magnus Westerlund 11 Apr '06

11 Apr '06

This is an request for review of http://www.ietf.org/internet-drafts/draft-taylor-types-example-02.txt This document will be in a 4 week IETF last call so please provide any comments before 2006-05-09. Thanks Magnus Westerlund

1 0

Registration of MIME media type Application/Vendor Tree vnd.hp-jlt
by Gaash, Amir 10 Apr '06

10 Apr '06

Hello We would like to make a registration for "application/vnd.hp-jlt" Can you assist me with the required actions? Here below is more information on our request. Best regards Amir ------------------------------------------------------------------------ ------ MIME media type name: application MIME media subtype name: vnd.hp-jlt Required parameters: N/A Optional parameters: N/A Encoding considerations: N/A Security considerations: This file does not contain any executable content. It contains instructions for the HP PPML job consumer to refer to JLT image files, as appropriate to the job design. Interoperability considerations: N/A Published specification: JLT is an HP Press job and images format. Specifications are available from HP per demand. Applications which use this media type: HP Indigo Press 5000, HP Indigo Yours Truly Designer Additional information: Magic Number(s): N/A File Extension(s): .jlt Macintosh File Type Code(s): N/A Person and email address for further information: Amir Gaash, amir.gaash(a)hp.com Intended usage: Common Author / Change Controller: Amir Gaash Hewlett-Packard Kiryat Weizmann P.O.Box 150 Rehovot 76101 Israel Tel: +972 8 9381854 Fax: +972 8 9381341 Email: amir.gaash(a)hp.com Mime Type: application/vnd.hp-jlt; charset=iso- Notes:

2 1

media type review requested for application/auth-policy+xml
by Allison Mankin 10 Apr '06

10 Apr '06

draft-ietf-geopriv-common-policy-08.txt is currently in IETF Last Call. Please review its media type registration for application/auth-policy+xml Please note that the document is used by both GEOPRIV and SIMPLE (and designed for using protocols) despite its ownership by geopriv. One modification to the registration we know is needed is to update a reference from RFC 2048 to RFC 4288 We will also modify the Author/Change controller section to read: Author: This specification is a work item of the IETF GEOPRIV working group, with mailing list address <geopriv(a)ietf.org>. Change Controller: The IESG Please provide any comments by April 21. Thanks, Allison (co-chair of the geopriv WG)

2 1

Request for review of audio/eac3 media type
by Colin Perkins 04 Apr '06

04 Apr '06

The AVT working group requests media type review for the audio/eac3 media type defined in section 5.1 of draft-ietf-avt-rtp-eac3-00.txt. This draft is currently in working group last call. We would be grateful if any comments could be made by 18th April 2006. Thanks, Colin (AVT co-chair)

1 0