Dear Christian,

thank you for the review.
We have prepared and uploaded a new version of the draft (06) including 
your corrections and suggestions.

Il 24/06/2014 05:28, Christian Groves ha scritto:
> how to update data model in the future? What method/process do we 
> need? Do we need to register updated attribute values with IANA etc?
1. We have added a new section about the schema extensibility.
>
> Specific comments:
> ==================
>
> - Cl.1 Do we need to provide some link to the CLUE protocol document? 
> i.e. the XML schema is used by the protocol messages defined in 
> draft-ietf-clue-protocol.
2. We have started to add some reference in the Introduction.
>
> - Cl.1 3rd para: The paragraph sounds like a proposal. I would propose 
> to reword along the lines of: "This document defines a structure for 
> information associated with the description of a telepresence scenario."
>
3. OK. We have corrected all the similar situations across the document.
> - Cl.2: I think it would be good to separate terms from the framework 
> vs ones introduced in this document. i.e. the introduction sounds that 
> the terms all come from the framework. CLUE participant however isn't 
> defined by the framework. I haven't checked which other terms are 
> different.

4. OK. We have  been clearer with respect to the separation by addind 
the following lines in the Terminology section introduction:
"This document refers to the same terminology used in <xref 
target="I-D.ietf-clue-framework"/>, except for the 'CLUE Participant' 
definition (which is still under discussion)."
and by modifying the definition as below:
"CLUE Participant: This term is not imported from the framework 
terminology and should be considered temporary since it is under review.
We introduced it for the sake of simplicity in order to identify a 
generic entity (either an Endpoint or a MCU) making use of the CLUE 
protocol."

> - Cl.3 1st para: Can remove "proposed", e.g. "This section contains 
> the CLUE data ...."
5. OK.
>
> - Cl.3 2nd para: "... given the Provider's offer." Does this relate to 
> a SIP offer or CLUE advertisement? Maybe we could more CLUE specific 
> language "... given the Provider's Advertisement."
>
6. OK. Replaced with "given the Media Provider's ADVERTISEMENT".
> - Cl.10 : This still contains the composed and switched elements (also 
> applies to cl.3, cl.10.8, cl.10.9). These were removed from the 
> framework so should be removed here.
>
7. Done.
> - Cl.10.2: "Each each media capture must be associated with one and 
> only one capture scene", how about when the media capture is used in 
> an MCC? May it would be better to say "Each media capture must be 
> defined in one and only one capture but may be referenced by other 
> scenes through multiple content captures" or similar.
>
8. Your text is clearer. We have replaced the existing one with the 
following lines:
"<captureSceneIDREF> is a mandatory field  containing the identifier of 
the capture scene  the media capture is defined in.
Indeed, each media capture MUST be defined within one and only one 
capture scene."
We have not added the part about MCCs, since MCCs are media captures as 
well. They are defined within one and only one capture scene and carry 
the capture scene identifier in the <captureSceneIDREF> like ordinary 
media captures.
They will show a <content> field referencing the included media 
captures, where the included media captures can belong to other capture 
scenes, but this has not so much to do with the definition of the 
<captureSceneIDREF> in Sec. 10.2.

> - Cl.10.4: I guess this would need to be updated to take into account 
> that there's no capture area information associated with audio captures?
9. Yes, but we have not added anything in that part since framework-15 
has not been updated yet.
We would like also to restore Botzko's <micPattern> (perharps with a 
different name) as a further feature for audio captures, since it 
represents exactly the concept of sensitivity pattern proposed by 
Coverdale to improve the audio capture description:

    <!-- MIC PATTERN TYPE -->
    <xs:simpleType name="micPatternType">
     <xs:restriction base="xs:string">
      <xs:enumeration value="uni"/>
      <xs:enumeration value="shotgun"/>
      <xs:enumeration value="omni"/>
      <xs:enumeration value="figure8"/>
      <xs:enumeration value="cardioid"/>
      <xs:enumeration value="hyper-cardioid"/>
     </xs:restriction>
    </xs:simpleType>

>
> - Cl.10.7: "...coming from the same room endpoint". I propose to 
> remove "room".
>
10. OK.
> - Cl.10.11: MaxCaptures needs to be updated to reflect to "<=" and "=" 
> constructs added to the framework.
11. Right. We have update the defition of the <maxCaptures> element as 
copied below:

<maxCaptures> is an optional element that can be used only for multiple 
content captures. It provides information about the number of media 
captures that can be represented in the multiple content capture at a 
time. The type definition is provided below.

<!-- MAX CAPTURES TYPE -->
<xs:complexType name="maxCapturesType">
   <xs:simpleContent>
     <xs:extension base="xs:unsignedInt">
       <xs:attribute name="exactNumber" type="xs:boolean" />
     </xs:extension>
   </xs:simpleContent>
</xs:complexType>

When the "exactNumber" attribute is set to "1", it means the 
<maxCaptures> element carries the exact number of the media captures 
appearing at a time. Otherwise, the number of the represented media 
captures MUST be considered "<=" of the <maxCaptures> value.

>
> - Cl.10.16/General: There a reference to CLUE framework for a 
> definition of the behaviour of an element. However there's no 
> references for other elements. In general should we provide a 
> reference to the section in the framework that describes the attribute?
>
12. I don't think we should, since it is stated more than once that each 
element reflects concepts presented in the framework document, and then 
we don't need to remark it.
We have removed this reference.
> - General: Do we need a statement about whether the framework or the 
> data model takes precedence regarding the definition of attributes?
13. I'm not sure we need such a statement in the data model.
However,  up to now, the data model has followed the news introduced in 
the framework.
By looking at how we conceived them, they are strictly interconnected, 
so updates in one should be reflected (if necessary, i.e., if new 
elements are defined, or the existing one are changed in their 
structure) in updates in the companion document (independently from the 
precedence rule).
> - General: Do we need some text regarding how to extend the data 
> model? e.g. what do I need to do if I want to add another value to the 
> presentationType.
14. We are preparing an example in order to explain how datamodel 
extensions can be managed to be included in Section "XML Schema 
Extensions" (cfr. bullet 1) - to appear.
>
> - Cl.10.21: I'm OK with the proposal.
15. OK (the element <capturedPeople> is a way to reference the Person 
Information and Person Type data about each participant captured in the 
media capture). Do the others think there is still discussion needed 
about it?
>
> - Cl.11: This needs to be updated to align with the framework 
> regarding the new audio parameters.
>
16. Yes, we are ready to do it.
> - Cl.14.4: Perhaps we can use the SI notation of "mm" for "millimeters"?
>
17. We have nothing against it. What about the others?_
_
> - Cl.15.3: Do we need the mediaType attribute if mediaType is also an 
> attribute of the referenced media captures? We don't have a mediaType 
> for STSs.
>
18. I have always used such an attribute in the definitions because, 
even if redundant, it can be useful for simplifying parsing (e.g., for 
rapidly filtering stss/cses/gses on the basis of the media type).
However, I have removed them also in the other data types dealing with 
set of captures.
> - Cl.18 : Is "mediaType" required when "globalSceneEntryID" isn't 
> included?
19. No, but there is a correction on that part. We have removed the 
mediaType attribute and set 'use="required"' for the globalSceneEntryID 
attribute. Other "use=required" specifications have been added to ID 
attributes in the schema file.
>
> - Cl.19.1 : "Such an element currently provides at least the vcard of 
> the person (via the <personInfo> element, see Section 19.1.2) and 
> optionally his conference role(s)." I think that these are 
> independent. The person Type may be provided without the need to 
> provide a vCard. There's no dependency in the framework.
>
20. I have corrected the introduction. The XML definition was already 
coherent with what stated in the framework, I have just made the 
"personID" attribute mandatory.
> - Cl.19.1.2: This clause makes reference to ietf-ecrit-additional-data 
> for the Xcard XML schema. What's the purpose of this? I thought a 
> reference to the Xcard RFC 6351 is sufficient however the definitions 
> of XML schemas is still a mystery.
>
21. Actually draft-ietf-ecrit-additional-data is the  source of the 
imported XML schema corresponding to the Relax NG schema in RFC 6351.
We have left the reference, for the moment.
> - Cl.20: "A possible solution to model...", I think we could strike 
> that sentence. I think we are defining "the" method.
>
22. OK.

Thank you again,

Roberta


----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITÀ DI NAPOLI
Codice Fiscale: 00876220633
www.unina.it/Vademecum5permille