Subject: [clue] New Version Notification for draft-ietf-clue-data-model-schema-03.txt

From: Roberta Presta <[email-masked]>
Date: Mon, 03 Feb 2014 22:46:29 +0100

Dear Christian,

thank you for your review.
We have just uploaded a new version of the draft we have updated on the 
basis of your feedback.
Please find comments inline.
Cheers,

Roberta

> Hello Simon and Roberta,
>
> Thanks for the updated draft. A few comments / questions:
>
> 1. Clause 1 - 3 paragraph indicates "a straw man proposal". As this is 
> now a WG draft I think that paragraph could be removed.
>
[RP] Removed.
> 2. Clause 3 paragraph above XML - The text refers to 
> "I-D.romanow-clue-data-model", is it still relevant to refer to this 
> expired document given the framework is the main document?
>
[RP] Removed.
> 3. Clause 3 - Capture Encoding type: The type has elements for 
> "captureParameters" and "encodingParameters". The framework doesn't 
> allow parameters to be returned in a configure so these should be 
> removed.
>
[RP] Removed.
> 4. Clause 10.6 & 10.7
>
> For the MCC captures a "composed" and "switched" element has been 
> added (10.7 & 10.8) as attributes. However there are no "composed" or 
> "switched" attributes in the framework. Is this a proposal to add them 
> back in? otherwise the two documents won't be aligned. 4a:
>
[RP] They are actually proposals. That has been explicitely mentioned in 
the new version of the draft. There is an example of how to use them in 
multiple content captures provided in the end.
I will show the example in the upcoming design team meeting presentation.
> Clause 10.6: Editorial nit: ...can be alternative <remove "or"> a 
> single media...
>
[RP] Removed.
> 5. Clause 10.11 Single
>
> I was at first confused by this as it wasn't in the framework and I 
> also confused it with the case MCC(VC1). Would it be possible to add a 
> note indicating that the MCC(VC1) case where the MCC contains a single 
> individual CaptureID is not the same as the use of <single>. Maybe 
> rather than say "single" we could use "individual" for the element 
> name? Also during discussions it was also noted that it should be 
> possible to specify an MCC without any captureIDs. So the XML should 
> probably indicate "minoccurs="0". 6.
>
[RP] We have added text to specify that "single"/"individual" is just a 
proposal to mark *non*-multiple-content captures. We have put minOccurs 
= 0 for the capture IDs.
> Clause 10.13 Priority: This is actually contained in the framework. So 
> the reference could be updated and I-D.groves-clue-capture-attr removed.
>
[RP] Reference removed.
> 7. Clause 10.14 Language: As per above comment. Its now part of the 
> framework.
[RP] Reference removed.
>
> 8. Clause 10.17 Related to: As per above. Its now part of the framework.
[RP] Reference removed.
>
> 9. Clause 10.??
>
> The CLUE framework clause 7.2.1.3 has the synchronisation identity. 
> This appears to be missing from the data model?
>
[RP] Added.
> 10. Clause 11.1 AudioChannelFormat: We had a discussion on the list 
> previously 
> (http://www.ietf.org/mail-archive/web/clue/current/msg02778.html) 
> requirements regarding using an integer to indicate the format rather 
> than "mono", "stereo" etc. Should we update the framework and data 
> model to align with the requirements?
>
[RP] We will update it in the next version.
> 11. Clause 12.1 Embeddedtext: This is included in clause 7.1.1.13 of 
> the framework. So the last two sentences could be removed.
>
[RP] Done.
> 12. Clause 15.3: Is the media type needed here? The media type would 
> be associated with the individual captures. It seems like a duplication.
>
>
[RP] We think it can be useful for rapidly discriminating between audio 
entries and video entries, but it is redundant. We will remove it.

> 13. Clauses 16/17/18: With the decision to use SDP for encodings could 
> these sections be removed?
>
[RP] At least we have to list encoding identifiers in order to build 
encoding groups. Since we have prepared an example with some 
consideration about the max bandwidth, we have left them in that version.

> Regards, Christian