Subject: [MMUSIC] Internet Media Guide comments from Brit's Pub

From: [email-masked]
Date: Fri, 14 Nov 2003 01:01:12 +0200

Hi Everyone

We had an IMG "design team bar bof" with Colin & Joerg on IMG in the Brit's Pub and collected multiple review comments face-to-face. We're updating the IMG requirements and framework and will release updated IDs ASAP.

Please review and comment the documents by email (and also tomorrow morning if you're with us in Minneapolis).

Here's a summary of the comments and some responses over the good old Internet... 

Cheers, Rod.

---

*** IMG Document Review, IETF-58 / 10.November.2003 / Brit's Pub ***

== Requirements Draft ==

RQ1. requirements should be numbered to make it easy to reperence (and identify) them

RQ2. "Agnostic" can have some negative conertainions so swap "agnostic" for "supports many different ones".

RQ3. Make it explicit that we assume many more receivers than senders as it's important to make the primary use clear.

RQ4. The receiver can be intermittently connected but it is unclear whether the document is saying the sender could be too. Show the assumption that, for the duration of interest, the sender is continually connected.

RQ5. Customizing and Scalability are somewhat exclusive. For general scalability we are talking of possibly millions of users, for customisation involving receiver -> sender/network messaging we can expect scalability to considerably smaller numbers.

RQ6. There are a few requirements draft terminology problems...
The term IMG -> changed to IMG metadata where appropriate, and IMG and IMG metadata definitions updated/added:
IMG networks -> networks
IMG transport -> IMG transport protocol
IMG system -> clarified in places
complete IMG knowledge -> complete IMG metadata knowledge
IMG originators -> IMG senders
IMG components -> IMG entities
IMG content -> IMG metadata

== IMG Framework ==

FW1. 3.2 is conent use cases. The use of the term "file" was verified in 3.2.1 - it (correctly) refers to a content type which maybe described (and have it's transport media described) in IMG metadata. Minor chanes to emphasis this will be made.

FW2. Where to put use cases - it was felt that they're ok where they are

FW3. A "reference/pointer" to an IMG delivery session would be useful - it gives for descriptors to define an IMG delivery session. (an SDP descriptor?) Clarification for this is added in 4.1.3.

FW4. Framework should not mix the description of IMGs with what is in the IETF scope and what is not. Thus the two are now seperated.

FW5. [Note - several other standards bodies could be good places for application specific metadata]

FW6. We condisered and change the "SHOULD" to "MUST" for the requirement on authenticating fragments of IMG metadata study the feasibility and imply options -> Relates, especially, to transceiver/proxy issues of middlebox fragmentation, reassembly, aggregation, and augmentation. I.e. can a middlebox authenticate original parts of the metadata with the original source 'signature' and new/modified parts with it's own 'signature'. Generally it's not going to be needed. If it is, the middlebox either gets the source to re-sign the fragment, or the original metadata must be reasonably fragmented already (allowing the middlebox to replace a small fragment without changing the authenticity of the remainder). Easy fixes in the req doc.

FW7. It's "IMG in IETF" scope to look at IMG Delivery (link traversing), whereas it is not "IMG in IETF" scope to standardise application-specific metadata including data models. This practically means multicast transport (§6.3.1), Usage of Unicast Transport Protocols (§6.3.2) and The Metadata Envelope (§6.3.3) are recommended for IETF work items. Whereas for the Baseline (Meta)Data Model Specification (§6.3.4) we acknowledge the need to exchange and agree on a baseline metadata model and application specific metadata for the purposes of interoperability testing between different implementations of IMG related IETF protocols - but the IETF standards process is not required for this.

FW8. Each connectity/network use case should show that unicast or multicast is needed, which they do

FW9. identifier - URL in HTTP, what about delta? how to describe the correlations? Identifier is likely to be a URI in all cases. Same ID for deltas, just that the payload type (in metadata envelope) would be different. We also discussed that SDP-delta would need to be a different type from SDP. Solution belongs to the metadata envelope spec.

FW10. Framework draft terminology problems
proxy -> deleted
IMG information -> IMG metadata
IMG protocol -> IMG transport protocol (in 2/3 places)
announcement protocol -> added a note that SAP is an announement protocol, but don't really need to define a fixed term

---

Comments are welcome!

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