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. 
Cheers,

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

         ~~Yves
Received on Thursday, 23 July 2009 12:22:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:34 GMT