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

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.

>>> 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?

>>> 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

>
>> 
>>>> 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).

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

         ~~Yves

Received on Wednesday, 26 August 2009 09:51:28 UTC