Subject: RE: [MMUSIC] Experiences with Media Discovery (for IMG)

From: [email-masked]
Date: Wed, 14 May 2003 11:57:34 +0300

Hi Hitoshi

see in-line...

> At the beginning, I'd like to ask you about the current situation
> about IMG.

We currently have 3 individual drafts relating to requirements and framework which are excellent input material, now we need more input material from anyone who is working or is interested in this area.

When we discussed the media discovery with the IETF Transport Area Directors we had anticipated talking protocol needs, but they made it clear that first up was that the requirements and use cases and a framework of how to use _existing_ protocols for these should come from the working group. To enable the broadest possible contribution to this area and provide natural justification for any specific work items that are needed, this makes a lot of sense.

Our goal for IMG is to get open and interoperable IETF standards for our IP-domain problems of delivering descriptions of multicast media and make sure that anyone trying to implement IMG has sufficient specification to do this and be interoperable. Because of this, we can anticipate some of the specific work items (e.g. the MUPPET protocol) that will be identified, but I'm trying to limit my field of view to the initial two IDs for now so we get progress.

The exact work that MMUSIC will pursue and support must be on its charter first, so I'm not being too specific at the moment (thought the IETF-56 IMG presentation is still alive and highly relevant).

> To be honest, I have a feeling IMG's draft doesn't give us the
> concreat architecture. I know this is because the current I-D is a
> framework draft, but it would not be sufficient for the point of the
> implementation and deployment.

Totally correct. The current drafts around IMG (and pguide before it) are neither sufficient nor finished. I hope the authors will get comments to influence them as they develop towards completion.

The end point for IMG must be a set of standards that allow interoperable implementations and we're some way from that yet. In this sense, it would be fantastic if you would contribute ideas and material to help make IMG work. Your paper on Channel Reflectors had very many good observations and ideas which should feed naturally into the IMG food chain.

> I'll consider that Channel Reflector (CR) should be included in the
> IMG's draft or mentioned in a new one. At this moment, I think
> separate draft may be better, in order to categorize each draft as a
> "framework" draft and a "architectural" draft (like MUPPET?).

For the purpose of communicating the idea, a separate draft is a great idea - I'm looking forward to it!

> > I am not quite sure how you partition your metadata to allow a host
> > to get specific entries from a CR (or indeed the CR to select the
> > entries to send and how to group those entries) - can you explain
> > (apologies if I missed this in the text).
> Are you talking about the method to validate or classify data
> sender/receiver? If so, it's not mentioned in my paper, since I think
> it depends on the implementation and there are several possibilities.
> But such information (that I mentioned in Sect. 5.2 and 5.3)
> maintained by CR can include the key word to handle it as its basic
> components.
> If this is not your answer, please tell me.

I get the feeling that it was my answer :)

Luoma's metadata ID (draft-luoma-mmusic-img-metadata-00) describes "metadata elements" and "content bundles" (among others), which could be used to identify a specific grouping of metadata. This metadata grouping is important, especially, for metadata management so that hosts can deal with expiry and renewal etc. Of course, it's also useful for the simple stuff like identifying the metadata for a certain media stream.

In the context of your Channel Reflector paper, you'll need some information (an HTTP URL I guess) to go and grab the metadata, but still we need to partition the metadata. For instance, fetching a full 6GB database may not be the most fun since space travel. Still fetching each single entry one by one may be rather laborious - and surely scalability arguments abound for both cases. Thus, by grouping/partitioning the metadata (and identifying that set of data), fetching it becomes more useful. If you have an ideas or work in this area, it would be good to hear them too.

I'm looking forward to seeing your use cases and requirements appear on the reflector soon!

Cheers, Rod.

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