Subject: RE: [MMUSIC] Fwd: I-D ACTION:draft-walsh-mmusic-img-envelope-04.txt

From: [email-masked]
Date: Tue, 3 Jan 2006 21:23:05 +0200

In a nutshell, the whole IMG work aims to provide a consistent basic
tool box for metadata transport (including SDP). It's aimed at the kind
of multimedia services MMUSIC is all about and among other things, it's
likely to obsolete SAP (for multicast announcement) and specify SIP and
HTTP usage in a simple way. There's a spectrum of use cases with massive
multicast mediacast at one end.

If this is new to you, then please have a look for img-framework and
img-reqs I-Ds (both past WGLC and waiting for approval of post-IESG
comments before heading to the RFC Editor).

The IMG envelope is key to fulfilling the need for any metadata over any
transport. It acts as a metadata consistency and validation tool for
metadata transport and basic management.

This model of the envelope is now looking polished and near final (in
our limited design team view). Sweetly enough, it is also interoperable
with the metadata envelope in 3GPP/MBMS release 6 (TS26.346). Unless you
have a dire aversion to XML, take this very seriously if you're moving
media metadata between IP hosts.

Cheers, Rod.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Colin Perkins
>Sent: 23 December, 2005 22:31
>To: IETF MMUSIC working group
>Subject: [MMUSIC] Fwd: I-D 
>ACTION:draft-walsh-mmusic-img-envelope-04.txt 
>
>This is relevant to MMUSIC.
>Colin
>
>
>Begin forwarded message:
>> From: [email-masked]
>> Date: 20 December 2005 20:50:01 GMT
>> To: [email-masked]
>> Subject: I-D ACTION:draft-walsh-mmusic-img-envelope-04.txt
>> Reply-To: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>>
>> 	Title		: The IMG Envelope
>> 	Author(s)	: R. Walsh, et al.
>> 	Filename	: draft-walsh-mmusic-img-envelope-04.txt
>> 	Pages		: 34
>> 	Date		: 2005-12-20
>> 	
>> This document defines the metadata transfer envelope for Internet
>>    Media Guides (IMGs).  IMG metadata describes files, resources and
>>    multimedia programs available for streaming or downloading via
>>    multicast or unicast.  IMG metadata is encapsulated into, or
>>    associated with, an IMG envelope before actual transport.  The IMG
>>    envelope is a structure providing independence between IMG 
>> transport
>>    protocols and different metadata formats.  This specification
>>    provides the IMG envelope instantiation using structured 
>Extensible
>>    Markup Language (XML) syntax, both as a wrapper in which to embed 
>> an
>>    IMG metadata object and as a distinct object to associate with a
>>    distinct IMG metadata object.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-walsh-mmusic-img-
>> envelope-04.txt
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Wed, 4 Jan 2006 15:11:40 +0000

Rod,

> media metadata between IP hosts.

Some conceptual comments:

1) There was a long discussion over lunch at the 61st IETF  
(Washington DC) on whether IMG envelopes should be XML-based or  
should use MIME headers. It would be useful if the draft contained a  
design rationale section to explain why the XML-based approach is  
used, since there are good reasons for either approach.

2) I would also like to see more discussion on why IMG envelopes are  
allowed to contain or reference IMG metadata, rather than requiring  
the metadata always be contained within the envelope.

In neither case am I arguing to change the design, but I do think it  
appropriate for the draft to explain its design choices.

On a more detailed level, does section 3.2.5 ("Consistency Checking  
of IMG Metadata") impose a requirement for globally synchronised  
clocks? Such a thing would be difficult to achieve, so clarification  
on the requirements would be useful.

I am assuming that Appendix B will be replaced by a reference to the  
IMG framework draft at some point. What is the intent for Appendix C?  
Will this be split into a separate draft? Or can it be merged into  
the main body of this draft?

Colin