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

Dear Cyril, Yves,

On Aug 26, 2009, at 9:32 AM, Cyril Concolato wrote:

> Hi Yves,
>
> Yves Lafon a écrit :
>> 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?
> No, application/mp21 is the file format based on the ISO base file  
> format. The XML description format in MPEG-21 called DID has, to my  
> knowledge, no registered mime type.
The mime type of MPEG-21 DIDL is text/xml and every XML parser can  
determine the namespace URN which is "urn:mpeg:mpeg21:2002:02-DIDL- 
NS" [1] and which is registered at MPEG according to [2].

>
>> And what is the relation with EXIF and XMP?
> I don't know how to answer this question.
MPEG-21 DID provides means to declare the structure of a Digital Item  
(or object or however one likes to call the thing one would like to  
consume (or produce) on his PC, her TV, or mobile devices). In other  
words, it provide means to express the relationship between the  
individual assets (audio, video, image, text, ...) and associated  
metadata of this thing. EXIF, XMP, ... could be part of this thing and  
included either by value or by reference.

>> Side question, what is the patent policy for MPEG21-Part17 and  
>> Part2 (ie: are there different policies depending on the parts)?
> I don't think there are different policies for different parts. I  
> think both follow the usual ISO rules. I don't see any patent  
> statement in Part 17, which does not mean there aren't any patent,  
> it just means people did not declare any.
Correct.

>
>>> 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,
> I think that's what MPEG did (not me). As I said, I don't know if  
> the process was right. I just wanted to mention that fact.
RFC3003 is from 2000 whereas MPEG-21 Part 17 was published in 2006.

The reason for including the statement cited above was because MPEG  
could only specify the syntax for URI fragment identifiers for known  
formats/codec, i.e., for which the specification is open to everyone.  
It is quite obvious that MPEG started with its own formats and it does  
not indicate any complexity issues with other formats. I think the  
idea was that other format developers (open or closed) are invited to  
extend MPEG-21 Part 17 for their own formats if desired or even  
required. MPEG-21 Part 17 has been defined in a generic way which  
should make this extension quite easy and I'm quite sure that for some  
of these other formats no extensions are required except for adding it  
to the above list.

Hope this information was helpful.

Best regards,
  -Christian

[1] http://www.chiariglione.org/mpeg/working_documents/general/URI.zip
[2] http://tools.ietf.org/html/rfc3614

> Cyril
>
> -- 
> Cyril Concolato
> Maître de Conférences/Associate Professor
> Groupe Mutimedia/Multimedia Group
> Département Traitement du Signal et Images
> /Dept. Signal and Image Processing
> Ecole Nationale Supérieure des Télécommunications
> 46 rue Barrault
> 75 013 Paris, France
> http://tsi.enst.fr/~concolat