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

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

From: Christian Timmerer (ITEC) <christian.timmerer@itec.uni-klu.ac.at>
Date: Wed, 26 Aug 2009 14:11:11 +0200
To: Yves Lafon <ylafon@w3.org>
Message-Id: <8AD634B1-D85A-43AB-840C-31D777501AE7@itec.uni-klu.ac.at>
Cc: cyril.concolato@telecom-paristech.fr, Media Fragment <public-media-fragment@w3.org>

On Aug 26, 2009, at 11:51 AM, Yves Lafon wrote:

> On Wed, 26 Aug 2009, Christian Timmerer (ITEC) wrote:
>>>>> 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].
> Ok, so if you have mixed content, it is hard to define the main  
> purpose of the document. Having a specific mime type helps defining  
> the intent of a document, even if it's not a silver bullet.
MPEG-21 Part 2 does not serve a single purpose, it can be used for  
many. Therefore, application formats have been defined in order to  
let's say "profile" a certain combination of MPEG tools for specific  
application areas (e.g., music, photo). These application formats  
serve a specific purpose for which it's worth defining a mime type.  
See [1] for an overview and further application formats can be  
defined, I would say, even outside of MPEG.

>>>> 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.
> By reference, using a URI, or other means?
Yes (anyURI) and see the definition of the Resource element at [2] and  
[3] for the semantics as MPEG-21 Part 2 is publicly available.

>>>> 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.
> Is this the right one?
> http://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/Common_Policy.htm
Looks good but note that I for myself can be categorized as  
"Recommendations | Deliverables are drawn up by technical and not  
patent experts" according to this document ;-)

>>>>> 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.
> It looks like RFC3003 hasn't been obsoleted by another version  
> including this definition, and there are no links from the IANA  
> registry to MPEG-21 Part 17, so how is an implementor supposed to  
> figure out this? (Note that it is not only an issue in this case,  
> but for many other parties trying to define fragments for specific  
> mime types).

I wonder whether this is really necessary. If the answer is yes, it  
looks like a nightmare updating all mime type registrations for which  
fragments are applicable. Have I missed something?

Best regards,

[1] http://www.chiariglione.org/mpeg/standards/mpeg-a/mpeg-a.htm
[2] http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-21_schema_files/did/didl.xsd
[3] http://standards.iso.org/ittf/PubliclyAvailableStandards/c041112_ISO_IEC_21000-2_2005(E).zip

> -- 
> Baroula que barouleras, au tiéu toujou t'entourneras.
>        ~~Yves
Received on Wednesday, 26 August 2009 12:11:53 UTC

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