Subject: RE: [MMUSIC] RE: Test FLUTE for Service/Session Announcement for Multicast Apps

From: [email-masked]
Date: Mon, 5 Jan 2004 18:54:23 +0200

Hi Stig & Sami

Thanks for the ideas. I'm thinking along the same lines as Sami, with the addition that it makes some sense to seperate the initial "announement channel discovery /boot-strapping" from the announcement protocol (i.e. make it an assumption). So a seperate specification would be needed to cover just this.

For the "get the details from a web page" option no additional spec is really needed (I guess a FLUTE URL is an option). For the simple "register me with IANA" option, it'd be a very small (unecesary?) spec, with whatever SSM and IPv6 complications the authors dare to tackle. Etc, etc.

Any thoughts?

Cheers, Rod.

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

---

From: [email-masked]
Date: Mon, 5 Jan 2004 18:54:01 +0200

Hi Philippe & Sami

> > Secondly could you explain if/why there is a specific need for a
> > "joint" work
> > between program guides and their mulitcast distribution ?

The IMG philosphy is to keep these orthogonal. i.e. the multicast (and unicast) delivery protocol should be distinct from the application metadata (we are not dealing with the intricacies of the latter in MMUSIC). One aspect of delivery which is important to metadata (and many other data) is consistency. For this reason a "metadata envelope" decsribing the bare minimum to maintain and expire metadata is under work. Currently the idea is to seperate multicast delivery prtocol and metadata envelope (i.e. seperate specificatons) so the same envelope can be used regarless of the underlying multicats distribution methods. Other ideas and opinions are very welcome!

Happy New Year,
Rod.

---

From: [email-masked]
Date: Mon, 5 Jan 2004 18:04:17 +0100

Hi Rod,

my point was: there maybe  reasons to adapt a format to the transport (e.g. RTP...)
but in the case of *reliable* multicast I dont see any need for a difference with HTTP?

then this consistency issue is purely a matter of format , so I understand the subject  does not
include/relate to transport except that you want reliable transport for this metadata format, right ?

regards,

Philippe Gentric
Chief Architect
Philips Software
[email-masked]
http://www.software.philips.com

                                                                                                                                       
                                                   To:   <[email-masked]>                                                       
                                                    <[email-masked]>                                                     
                                                   cc:   <[email-masked]>                                                             
                                                   Subject:    RE: [MMUSIC] Test FLUTE for Service/Session Announcement for Multicast  
               [email-masked]                  Apps                                                                               
                                                                                                                                       
               Sent by:                            Classification:                                                                     
               [email-masked]                                                                                                   
                                                                                                                                       
               05/01/2004 17:54                                                                                                        

Hi Philippe & Sami

> > between program guides and their mulitcast distribution ?

The IMG philosphy is to keep these orthogonal. i.e. the multicast (and unicast) delivery protocol should be distinct from the application metadata (we are not dealing with the intricacies of the latter in MMUSIC). One aspect of delivery which is important
to metadata (and many other data) is consistency. For this reason a "metadata envelope" decsribing the bare minimum to maintain and expire metadata is under work. Currently the idea is to seperate multicast delivery prtocol and metadata envelope (i.e.
seperate specificatons) so the same envelope can be used regarless of the underlying multicats distribution methods. Other ideas and opinions are very welcome!

Happy New Year,
Rod.