- Ietf-types - alvestrand.no

Registration of media type application/atomcat+xml
by Paul Hoffman 05 Jun '07

05 Jun '07

MIME media type name: application MIME subtype name: atomcat+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: .atomcat 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

1 0

Media type for output of POSIX "diff" utility
by Julian Reschke 04 Jun '07

04 Jun '07

Hi, I think it would be good to have a specific media type for the output of the POSIX "diff" tool (see <http://www.opengroup.org/onlinepubs/000095399/utilities/diff.html>). Questions: - Am I missing something (meaning, is there already one)? - Were there previous attempts to to this that failed? (why?) - Would the specification at <http://www.opengroup.org/onlinepubs/000095399/utilities/diff.html> be sufficient as specification of the contents of the file? - Would it make sense to define individual types for the different diff output formats (simple, context, ...), or would that be something for a type parameter? Feedback appreciated, Julian

5 13

Re: Media type for output of POSIX "diff" utility
by Julian Reschke 01 Jun '07

01 Jun '07

Simon Josefsson wrote: > This sounds like a good idea to me. Gnus has used text/x-patch for a > long time for this purpose. I suspect this has been influenced from > older tools, and Gnus usage has possibly also influenced more recent > tools. So would you suggest to stick with "text/x-diff", and just register that, or would you prefer "text/diff"? >> - Would it make sense to define individual types for the different >> diff output formats (simple, context, ...), or would that be something >> for a type parameter? > > I don't believe that doing either (i.e., neither type parameter nor > multiple media types) will serve the goal of interoperability well. In which case we'll have to explicitly list which flavors of diff outputs the media type includes... Best regards, Julian

3 2

Re: Media type for output of POSIX "diff" utility
by Julian Reschke 31 May '07

31 May '07

Simon Josefsson wrote: > I don't think you can register text/x-diff, can you? x-* is reserved > for non-standard media types. I guess an exception could be made if this would just document widespread practice (if we wanted that). > I think we should standardize either text/diff or text/patch. Even > though the name 'diff' denotes the tool, 'patch' may be somewhat more > descriptive, and there is existing deployment of text/x-patch. I'm not > sure which to prefer. Good point. "text/patch" makes more sense. >>>> - Would it make sense to define individual types for the different >>>> diff output formats (simple, context, ...), or would that be something >>>> for a type parameter? >>> I don't believe that doing either (i.e., neither type parameter nor >>> multiple media types) will serve the goal of interoperability well. >> In which case we'll have to explicitly list which flavors of diff >> outputs the media type includes... > > Yes. Best regards, Julian

1 0

RE: MPEG asks for MIME review for the MPEG21 file format
by Dave Singer 24 May '07

24 May '07

At 14:27 +0200 24/05/07, Christian Timmerer (ITEC) wrote: >Dear Graham, > >> Is there any chance that the standardization committee might be >> persuaded to >> make public release of part 9, describing this file format, in addition >> to parts >> 1, 2 and the schema already made public? I think that doing so would >> make the >> MPEG21 vision accessible to a wider base of developers. >[Christian Timmerer (ITEC)] Yes there is a >chance but it might be difficult since ISO is >usually doing this only for technical reports, >reference software, and in some exceptional >cases for so-called "baseline" standards, i.e., >those that are most relevant for a particular >standard in order to become adopted by others >(e.g., Part 2 of MPEG-21). > >Furthermore, MPEG-21 Part 9 is based on the ISO >base media file format which is a joint standard >between MPEG and JPEG. The ISO base media file >format is indeed publicly available [1-4]. >However, we might get into troubles why we're >asking ISO to make MPEG-21 Part 9 publicly >available but not other MPEG file formats, etc. >Dave might correct me if I say something wrong >here. > >I think the best and easiest way how to proceed >is to provide you (=IETF) the relevant >(=MPEG-21) file format standard(s) through >liaison at the next meeting which is at the >beginning of July in Lausanne. Anyway, I'll also >ask whether it is feasible to make Part 9 of >MPEG-21 publicly available. > >Thanks. >Best regards, > -Christian We can probably sum up what part 9 says well enough for you. It's short enough! An MPEG-21 file has the following boxes from the public part 12 spec.: ftyp meta, whose primary item is an MPEG-21 DIDL handler, saying it's mpeg-21 item location item information and probably an mdat > >[1] >http://standards.iso.org/ittf/PubliclyAvailableStandards/c041828_ISO_IEC_14… >[2] >http://standards.iso.org/ittf/PubliclyAvailableStandards/c042292_ISO_IEC_14… >[3] >http://standards.iso.org/ittf/PubliclyAvailableStandards/c043226_ISO_IEC_14… >[4] >http://standards.iso.org/ittf/PubliclyAvailableStandards/c043689_ISO_IEC_14… > > > >> >> #g >> -- >> >> >> Christian Timmerer (ITEC) wrote: >> > >> > >> > Dear all, >> > >> > as the "source" of this MIME type please apologize my late reply >> > because I was one week w/o email access. It took some time to catch >> up. >> > Regarding the "+xml" suffix I agree that it is inappropriate since an >> > MPEG-21 file is not purely XML (see below for further details). >> > >> > >> > >> > MPEG-21 Part 1 (Technical Report) is publicly available [1]. >> > >> > >> > >> > Concerning Digital Items, Digital Item Declaration, and MPEG-21 File >> > Format, let me try to clarify something because I think there's a >> > misunderstanding: >> > >> > · A Digital Item can be seen as a digital container format >> that >> > puts (media) resources (e.g., audio, video, image, text (PDF), etc.) >> and >> > metadata (e.g., data describing the resources, licenses, identifiers, >> > etc.) within a standardized structure. >> > >> > · A Digital Item is declared by an Digital Item Declaration >> > (DID) which is based on the Digital Item Declaration Language (DIDL) >> > that is a representation of the Digital Item Declaration Model. The >> > model and DIDL are specified in MPEG-21 Part 2 which is publicly >> > available [2]. The model is an abstract model defined using EBNF >> whereas >> > DIDL - the representation of the model - is defined using XML Schema, >> > thus, DID is XML-based. That is, it is possible that other, >> > non-XML-based representation may be derived from the model (However, >> > this should not be the discussion point) >> > >> > · A Digital Item may be distributed which means that its >> > declaration (i.e., DID) may be at one location whereas its (media) > > > resources and metadata may be located elsewhere on various locations. >> > >> > · The MPEG-21 file puts everything, i.e., (media) resources, >> > metadata, and structure (i.e., declaration), into one file, the MPEG- >> 21 >> > file which is binary and contains the DID and (maybe) also the >> > referenced/included (media) resources. >> > >> > >> > >> > Hope this information is helpful for you. >> > >> > >> > >> > Thank you. >> > >> > Best regards, >> > >> > -Christian >> > >> > >> > >> > [1] >> > >> http://standards.iso.org/ittf/PubliclyAvailableStandards/c040611_ISO_IE >> C_TR_21000-1_2004(E).zip >> > >> > [2] >> > >> http://standards.iso.org/ittf/PubliclyAvailableStandards/c041112_ISO_IE >> C_21000-2_2005(E).zip >> >> >> -- >> Graham Klyne >> For email: >> http://www.ninebynine.org/#Contact -- David Singer Apple Computer/QuickTime

1 0

Registration of media type vnd.iptvforum1fec
by shuji NAKAMURA 24 May '07

24 May '07

This document requests registration of four new media subtypes: vnd.iptvforum.1dparityfec_1010, vnd.iptvforum.1dparityfec_2005, vnd.iptvforum.2dparityfec_1010, and vnd.iptvforum.2dparityfec_2005, as follows. MIME media type name : Video MIME subtype name : Vendor Tree -vnd.iptvforum.1dparityfec_1010 and MIME media type name : Video MIME subtype name : Vendor Tree -vnd.iptvforum.1dparityfec_2005 and MIME media type name : Video MIME subtype name : Vendor Tree -vnd.iptvforum.2dparityfec_1010 and MIME media type name : Video MIME subtype name : Vendor Tree -vnd.iptvforum.2dparityfec_2005 Required parameters : None Optional parameters : None Encoding considerations : binary Security considerations : Security issues have not been assessed. Interoperability considerations : None Published specification : Currently not publicly available. To be published by IPTV Forum. Applications which use this media : Applications that run on IPTV devices that conform to the interoperability guidelines defined by the IPTVForum. Additional information : 1. Magic number(s) : None 2. File extension(s) : Undefined 3. Macintosh file type code : Undefined 4. Object Identifiers: None Person to contact for further information : 1. Name : Shuji Nakamura 2. Email : shuji(a)mri.co.jp Intended usage : Common Audio and video streaming tools which seek to improve resiliency to loss bysending additional data with the media stream. Author/Change controller : Shuji Nakamura on behalf of the IPTV Forum. (file created 24 May 2007)

1 0

Registration of media type vnd.iptvforum.tts
by shuji NAKAMURA 24 May '07

24 May '07

This document requests registration of four new media subtypes: vnd.iptvforum.ttsmpeg2 and vnd.iptvforum.ttsavc, as follows. MIME media type name : Video MIME subtype name : Vendor Tree - vnd.iptvforum.ttsmpeg2 and MIME media type name : Video MIME subtype name : Vendor Tree - vnd.iptvforum.ttsavc Required parameters : None Optional parameters : None Encoding considerations : binary This media type may require encoding on transports not capable of handling binary. Security considerations : Security issues have not been assessed, although they should not differ substantially from similar considerations defined for data elements that use the video/mpeg MIME type when the video data uses MPEG-2 Transport Streams for encapsulation. Interoperability considerations : None Published specification : Currently not publicly available. To be published by IPTV Forum. Applications which use this media : Applications that run on IPTV devices that conform to the interoperability guidelines defined by IPTVForum. Additional information : 1. Magic number(s) : None 2. File extension(s) : Undefined 3. Macintosh file type code : Undefined 4. Object Identifiers: None Person to contact for further information : 1. Name : Shuji Nakamura 2. Email : shuji(a)mri.co.jp Intended usage : Common This media type identifies audiovisual streams multiplexed using an MPEG-2 Transport Stream packet format that include time stamps. Author/Change controller : Shuji Nakamura on behalf of the IPTV Forum. (file created 24 May 2007)

1 0

Re: MPEG asks for MIME review for the MPEG21 file format
by Graham Klyne 24 May '07

24 May '07

[Restricting mailing list circulation to ietf-types for now] Christian, Thank you for the references - they are most helpful. >From part 1, and referring back to the proposed MIME type registration, posted at: http://www.alvestrand.no/pipermail/ietf-types/2007-May/001804.html it becomes clear that the content is NOT the DIDL which is what I had first thought. Is there any chance that the standardization committee might be persuaded to make public release of part 9, describing this file format, in addition to parts 1, 2 and the schema already made public? I think that doing so would make the MPEG21 vision accessible to a wider base of developers. #g -- Christian Timmerer (ITEC) wrote: > > > Dear all, > > as the “source” of this MIME type please apologize my late reply > because I was one week w/o email access. It took some time to catch up. > Regarding the “+xml” suffix I agree that it is inappropriate since an > MPEG-21 file is not purely XML (see below for further details). > > > > MPEG-21 Part 1 (Technical Report) is publicly available [1]. > > > > Concerning Digital Items, Digital Item Declaration, and MPEG-21 File > Format, let me try to clarify something because I think there’s a > misunderstanding: > > · A Digital Item can be seen as a digital container format that > puts (media) resources (e.g., audio, video, image, text (PDF), etc.) and > metadata (e.g., data describing the resources, licenses, identifiers, > etc.) within a standardized structure. > > · A Digital Item is declared by an Digital Item Declaration > (DID) which is based on the Digital Item Declaration Language (DIDL) > that is a representation of the Digital Item Declaration Model. The > model and DIDL are specified in MPEG-21 Part 2 which is publicly > available [2]. The model is an abstract model defined using EBNF whereas > DIDL – the representation of the model – is defined using XML Schema, > thus, DID is XML-based. That is, it is possible that other, > non-XML-based representation may be derived from the model (However, > this should not be the discussion point) > > · A Digital Item may be distributed which means that its > declaration (i.e., DID) may be at one location whereas its (media) > resources and metadata may be located elsewhere on various locations. > > · The MPEG-21 file puts everything, i.e., (media) resources, > metadata, and structure (i.e., declaration), into one file, the MPEG-21 > file which is binary and contains the DID and (maybe) also the > referenced/included (media) resources. > > > > Hope this information is helpful for you. > > > > Thank you. > > Best regards, > > -Christian > > > > [1] > http://standards.iso.org/ittf/PubliclyAvailableStandards/c040611_ISO_IEC_TR… > > [2] > http://standards.iso.org/ittf/PubliclyAvailableStandards/c041112_ISO_IEC_21… -- Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

Media type review requested for audio/EVRCWB, audio/EVRCWB0, audio/EVRCWB1, audio/EVRCB, audio/EVRCB1
by Even, Roni 24 May '07

24 May '07

Hi, The AVT working group requests media type review for the audio/EVRCWB, audio/EVRCWB0, audio/EVRCWB1, audio/EVRCB, audio/EVRCB1 media types defined in section 9.1 of draft-ietf-avt-rtp-evrc-wb-02.txt. This draft is currently in working group last call. We would be grateful if any comments could be made by 7th June 2007. Thanks, Roni Even (AVT co-chair)

1 0

Re: MPEG asks for MIME review for the MPEG21 file format
by Graham Klyne 23 May '07

23 May '07

[restricting cc's per Larry's suggestion] Chris Lilley wrote: > On Monday, May 21, 2007, 6:24:33 PM, Graham wrote: > > GK> Chris Lilley wrote: >>> On Monday, May 21, 2007, 11:13:58 AM, Graham wrote: >>> GK> For clarification: this would be the case only when a suitable MIME >>> GK> content-transfer-encoding header is applied, n'est pas? > >>> If its compressed on the fly, yes. If its stored compressed on the server, then Content-Encoding is used. > > GK> Ah, I hadn't considered Content-encoding here. > > GK> I note that this header is defined by RFC2616 and registered only for use with > GK> HTTP > GK> (http://www.iana.org/assignments/message-headers/perm-headers.html) which > GK> suggests that it is defined only as part of an HTTP protocol transfer. > > Yes, I was talking of HTTP here. Well, what you said here was "stored compressed on the server", which is, I think, somewhat beyond the scope of a protocol specification. > Clearly if one uses, for example, FTP then that isn't an option. But then, neither is the Internet Media type :) This isn't helping me. Let's see if I can rewind. This thread started with a question about whether +xml was appropriate for the MIME type being registered. If the MIME type can contain binary (non-character) data (independently of any applied encoding which can be determined by appropriate MIME encoding headers), then that seems to be inappropriate. Thus far I think we were in agreement. But when you mentioned an HTTP *protocol* header in the context of "stored compressed on the server" I felt we'd strayed from specifications of requirements for interoperability to specification of implementation, which is beyond the scope of a wire-protocol specification. So on that count I think application of Content-encoding is not a consideration. MIME is not protocol-specific (even if it does have its roots in email), so the registration of a MIME content-type should not be dependent on the interpretation in the context of any particular protocol. So on that count too, I think application of Content-encoding is not a consideration. All of which I think does not affect the content type registration under consideration, unless I'm missing something. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0