Subject: [MMUSIC] FW: Comments on draft-luoma-mmusic-img-metadata-envelope-00.txt

From: "Evain, Jean-Pierre" <[email-masked]>
Date: Tue, 18 May 2004 11:01:37 +0200

Dear all,

second attempt after having sent it to the admin first.

Thanks in advance for your comments.

Best regards,

Jean-Pierre

>  -----Original Message-----
> From: 	Evain, Jean-Pierre  
> Sent:	jeudi, 13. mai 2004 13:53
> To:	[email-masked]'
> Subject:	Comments on draft-luoma-mmusic-img-metadata-envelope-00.txt
> 
> Dear all,
> 
> TV-Anytime has a look at the
> draft-luoma-mmusic-img-metadata-envelope-00.txt.
> 
> We don't know exactly what is the status of this draft but we would like
> to submit the following comments:
> 
> 1. We believe fragment identification and versioning are at the wrong
> level within the protocol stack. It would require a receiver to acquire
> the entire envelope structure (which also contains the metadata fragment)
> before the data can be parsed and its version and fragment identifier
> extracted. Instead, this information should be signalled within the packet
> header carrying the envelope. This is to enable a receiver to efficiently
> filter/monitor the stream for metadata updates.
> 2. For efficiency reasons it would be advantageous for an IP packet to be
> able to carry more than one envelope.
> 3. It is not clear whether the receiver should have a validating parser.
> 4. It should not be a requirement to decrypt the envelope to acquire the
> version and fragment ID.
> 5. The Envelope schema says that there can be multiple XML payloads but
> they would all have the same version and fragment ID. We don't thing this
> is right.
> 6. The solution implies that the data MUST be delivered as raw XML. What
> about binarisation? 
> 7. No Syntax has been provided for IMG QUERY, IMG ANNOUNCE, IMG RESOLVE,
> IMG NOTIFY, and IMG SUBSCRIBE.
> 8. How do you identify where a Delta goes within the identified fragment.
> i.e. what is its XPath?
> 9. TV-Anytime already provides an envelope. More information can be found
> in the technical specification ETSI 102 822 -3/2 (www.etsi.org). In
> addition it further explains the requirements on the delivery layer.
> 10. It is not clear what the purpose of the expiry date within the
> envelope is. I think this is application specific. If it stays it should
> be made clear what the semantics are. What is the use case?
> 
> What do you think ?
> 
> Best regards,
> 
> Jean-Pierre Evain
> 
> 
>  

**********************************************************************
 This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

---

From: [email-masked]
Date: Tue, 18 May 2004 16:39:49 +0300

Hi Jean-Pierre
 
Thanks for the comments (I'm replying on Pekka's behalf since he's not in the office until June).
 
See in-line...
     W  e don't know exactly what is the status of this draft but we would like to submit the following comments:  
 
It's an individual draft aimed at given an example of what the metadata envelope could look like, and hopefully accelerating this the work on a WG solution if MMUSIC charters this. It's also long overdue an update.
 
   1. We believe fragment identification and versioning are at the wrong level within the protocol stack. It would require a receiver to acquire the entire envelope structure (which also contains the metadata fragment) before the data can be parsed and its version and fragment identifier extracted. Instead, this information should be signalled within the packet header carrying the envelope. This is to enable a receiver to efficiently filter/monitor the stream for metadata updates.
 
In the sense that if you have the fragment embedded then the XML does not formally get the complete envelope until after all the fragment data so potentially the whole fragment would be passed to the application, but that's not the only design. I'm pretty sure that it would be possible to extract the version and fragment id from the envelope before the final /metadataEnvelope> is received if the XML parser is designed to handle this - please educate me if I'm wrong!
 
Note that the I-D has not been updated for some time (it's overdue for an update). As a result, it emphasises only the "embedded fragment" method and 
not also the "referenced fragment" method. The latter enables the envelope data to be received somewhat independently of the fragment (e.g. separate objects within a FLUTE session) and seems to meet your use case. This will be corrected when the I-D is updated.
 
To put the envelope data into the transport protocol header (with fragment payload) was considered in the first stage of envelope discussion, but since it is protocol bound, it is not transport independent and so does not meet the IMG requirements. (Secondary issues concerned transport efficiency).
 
   2. For efficiency reasons it would be advantageous for an IP packet to be able to carry more than one envelope. 
 
Where fragments are generally smaller than half the MTU, two fragments in an IP packet has better header efficiency - I see the point.
 
But this is more a transport into IP packing and fragmentation issue. In any case, the purpose a single metadata envelope is to enable the transport independent use of a single metadata fragment. Grouping of fragments into larger fragments/blocks with a single combined envelope is fine, but a data model issue, not envelope.
 
I'll take another look into this idea so feel free to ask again anytime (my opinion should not change, but that's not mandatory :)

Can you be a little more specific please? (Whether the envelope parser should be validating?) In any case, any XML which is not valid according to the schema should be rejected.
 
   4. It should not be a requirement to decrypt the envelope to acquire the version and fragment ID. 
 
Yes. It should be recommended that this info is not encrypted (the IMG requirements cover the relay and proxy cases which require this for versioning without seeing the content) - a little more simple than the SAP/SDP approach. In some cases the provider of a closed system may wish encrypt the envelope, but in most cases I expect not.
 
The envelope I-D does need to make this clear.
 
   5. The Envelope schema says that there can be multiple XML payloads but they would all have the same version and fragment ID. We don't thing this is right. 
 
Only one "payload" per envelope (payload = metadata fragment, whether it is referenced or embedded).
 
In the sense that the same version of a pointer, delta and complete instantiations of the same metadata fragment will all be identified by the same URI, it is possible for the "payload" to differ (delta vs. complete) for the same URI+version.
 
   6. The solution implies that the data MUST be delivered as raw XML. What about binarisation? 
 
"Binarisation" (for compression, encryption, etc) needs supporting. For a "referenced fragment" it's obvious (e.g. FLUTE FDT MIME type or content-encoding gives it away). For an embedded fragment the "type" of the embedded object needs specifying in the "payload tag". (Such as ASCII or XML). If you consider embedded fragments as binary objects necessary please say and we'll look into the schema change needed (and any suggested new schema are welcome too).
 
   7. No Syntax has been provided for IMG QUERY, IMG ANNOUNCE, IMG RESOLVE, IMG NOTIFY, and IMG SUBSCRIBE. 
 
The envelope is not responsible for that functionality or the identification of that functionality. The instantiation of these operations would specify any use of the envelope (e.g. an IMG ANNOUNCE instantiation could specify the use of envelope and FLUTE).
 
   8. How do you identify where a Delta goes within the identified fragment. i.e. what is its XPath?
 
Could be done my means of the MIME type of the URI'd fragment - e.g. as a type of delta (with IANA registration if for general Internet use). It is assumed that the "delta type" deals with "placing itself" in the fragment. E.g. binary diff and patch, and use of Xpath are good examples.
 
   9. TV-Anytime already provides an envelope. More information can be found in the technical specification ETSI 102 822 -3/2 (  <file://www.etsi.org/> www.etsi.org). In addition it further explains the requirements on the delivery layer.
 
Excellent. I think the TVA review of IMG Requirements and IMG Framework was very positive and showed that TVA would fit smoothly into the IMG framework. It's not surprising that the need for a metadata envelope is common.
 
I just had a whirlwind read of "ETSI TS 102 822-3-2 V1.1.1 (2003-10)" and formed these views (since I'm a relative TVA novice, please set me straight on any misunderstandings):
* TVA "Encapsulation Format" fulfils a very similar function to IMG "metadata envelope"
* TVA "container" (or "access unit") is not the same as metadata envelope, although it seems similar in the case of "one contained fragment". However the purpose if different. (The "container" is to group the delivery of several fragments together like with DSM-CC object carousel "containers" over MPEG-2 TS).
* When TVA "container" and "encapsulation" are taken together, they fit roughly into the same place in the protocol stack as IMG "envelope"
* TVA "container" and "encapsulation" are binary coded and provide only BiM payloads (although TVA registered numbers could be added for other TVA fragment syntaxes).
* IMG "envelope" is XML coded and its purpose is to allows any payload syntax. (BiM being a possible payload syntax or an XML fragment content-encoding - I think the latter is more generic).
* IMG envelope could be content-encoded (e.g. gzip, BiM, etc) and it may be feasible to consider specifying "the TVA encapsulation binary encoding of an XML IMG envelope" - but that's beyond the scope of the I-D we're talking about
* The IMG envelope uses a URI to identify fragments, TVA uses a 24 bit number. This makes enabling "global scope" straightforward for IMGs (although a 24 bit number, bit-encoded or URN, is perfectly suited to "organization/operator scope").
* Both IMG "envelope" and TVA "encapsulation" provide a version number for the fragment (as well as the id).
* IMG "envelope" also provides expiry data. TVA defines messages (e.g. delete) separate from the envelope to achieve some of this functionality.
* IMG "envelope" could be transported separately from the fragments (e.g. different objects in a FLUTE session). It would be relatively trivial to enable TVA "encapsulation" to do the same - possibly with a name change :)
 
So (IMHO) IMG envelope and TVA encapsulation have almost the same purpose in relation to their payload (although different payload scopes). IMG "envelope" has wider applicability, although it could be content-encoded into a bit-encoding equal to the TVA "encapsulation" so that TVA ETSI standards could be used "as is" (although I would prefer the ability to carry TVA over any IMG transport).
 
   10. It is not clear what the purpose of the expiry date within the envelope is. I think this is application specific. If it stays it should be made clear what the semantics are. What is the use case?
 
It expires that metadata fragment, so that: (a) I client would know that it needs to check it's metadata is consistent with the server, (b) if the metadata is no longer of use it is fine to discard, (c) the same fragment version may be unchanged but have it's time validity changed (so the client would know that an update of the fragment is unnecessary although the expiry is extended or shortened)
 
What do you think ? 
 
Excellent comments, most of which need to be reflected in the I-D. If you have suggested I-D text and a place to put them please send by email - this is always welcome. Otherwise, stay posted and I guess there will be an update before the end of June.
 
Cheers, Rod.