W3C home > Mailing lists > Public > public-media-fragment@w3.org > July 2009

Re: ACTION-76 : Question if MPEG-21 Part 17 got registered on IANA as a media mime type for fragments

From: Yves Lafon <ylafon@w3.org>
Date: Thu, 23 Jul 2009 08:22:38 -0400 (EDT)
To: cyril.concolato@telecom-paristech.fr
cc: Media Fragment <public-media-fragment@w3.org>
Message-ID: <alpine.DEB.1.10.0907230812330.25314@wnl.j3.bet>
On Thu, 16 Jul 2009, Cyril Concolato wrote:

Dear Cyril,

>>> mpeg-4 and mpeg-21 chose to take the route that the mime registration
>>> was merely a registration, a pointer from the code point (the mime
>>> type) to the spec.  Is that a problem?
>> Honestly, I'm not in the position to tell if this is a problem, however,
>> when I did my review [1] I implicitly was working under this assumption,
>> yes.
>> Anyway, I think we are on the safe side, as the original question was about
>> frag IDs in audio/*, image/*, and video/*' and we learned that MPEG21 has
>> not registered anything there (but only in their own application/mp21).
> You have to make the distinction between the MPEG-21 Part 9 (File Format) and 
> the MPEG-21 Part 17 (Fragment Identification of MPEG Resources).
> Part 9 defines a file format based on the ISO Base Media File Format. Its 
> main purpose is to wrap media data with a XML description conformant to 
> MPEG-21 Part 2 (Digital Item Declaration). Therefore it is registered as 
> application/mp21. However due to the compatibility with the ISO BMFF, the 
> same file, if it contains media data and conforms to other specifications, 
> may be served as audio/mp4, video/mp4 ... I think looking at the MPEG-21 FF 
> to find the answer to the question on your Wiki is not the right approach.

Quick question there, is application/mp21 the XML description format? And 
what is the relation with EXIF and XMP?
Side question, what is the patent policy for MPEG21-Part17 and Part2 (ie: 
are there different policies depending on the parts)?

> On the other hands, Part 17 clearly indicates that it "specifies a normative 
> syntax for URI Fragment Identifiers to be used for addressing parts of any 
> resource whose Internet Media Type is one of:
> - audio/mpeg [RFC3003];
> - video/mpeg [RFC2045, RFC2046];
> - video/mp4 [RFC4337];
> - audio/mp4 [RFC4337];
> - application/mp4 [RFC4337]".
> Now, I don't know if the process was right, or if such fragment identifier 
> scheme should appear in the registration forms of those media types but it 
> seems to me that the important questions are more technical: is this scheme 
> good or not, is it too complex to implement or not, should it be profiled or 
> not, extended or not ...

Looking at RFC3003, there is no link from it to MPEG21-Part17, so it 
seems that you defined an inbound link from part7 to the data 
formats, but not the other way round. 

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Thursday, 23 July 2009 12:22:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:42 UTC