Subject: [clue] Pre-WGLC: draft-ietf-clue-data-model-schema-05.txt

From: Mary Barnes <[email-masked]>
Date: Fri, 20 Jun 2014 10:41:26 -0500

Per the schedule on the wiki, we are starting a pre-WGLC on the data model
document:
https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/

The objective of this pre-WGLC review is for folks to take a fresh look at
the document and re-review the entire document. If you missed the design
team meeting on June 10th, you might also find it helpful to look at the
minutes/presentation for some background:
http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-140610.txt

There are currently two open issues against this document in the tracker:
#35: Consistency between framework and data model
#48:  Linking participant Information with Participant Type

This review is intended to ensure that there are no other outstanding
issues so that once we close the above open issues the document is ready
for WGLC.

Note, reviews that provide a general summary and then separate the major
and minor issues from the editorial nits, something like the following,
would be quite helpful.

Summary: (e.g., Needs Work, Almost Ready, Ready, etc)

Major issues:

Minor Issues:

Editorial nits:

Please review and send any comments to the mailing list no later than
Friday, July 4th, 2014.

Thanks,
Mary.

---

From: Christian Groves <[email-masked]>
Date: Tue, 24 Jun 2014 13:28:30 +1000

Hello Roberta, all,

Please find attached some comments on the draft.

Summary: I think its in good shape. Obviously aligning with the 
framework is the main issue. I think the other issue that needs to be 
addressed is 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?

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.

- 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."

- 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.

- Cl.3 1st para: Can remove "proposed", e.g. "This section contains the 
CLUE data ...."

- 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."

- 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.

- 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.

- 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?

- Cl.10.7: "...coming from the same room endpoint". I propose to remove 
"room".

- Cl.10.11: MaxCaptures needs to be updated to reflect to "<=" and "=" 
constructs added to the framework.

- 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?

- General: Do we need a statement about whether the framework or the 
data model takes precedence regarding the definition of attributes?

- 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.

- Cl.10.21: I'm OK with the proposal.

- Cl.11: This needs to be updated to align with the framework regarding 
the new audio parameters.

- Cl.14.4: Perhaps we can use the SI notation of "mm" for "millimeters"?

- 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.

- Cl.18 : Is "mediaType" required when "globalSceneEntryID" isn't included?

- 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.

- 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.

- Cl.20: "A possible solution to model...", I think we could strike that 
sentence. I think we are defining "the" method.

Regards, Christian

On 21/06/2014 1:41 AM, Mary Barnes wrote:
> Per the schedule on the wiki, we are starting a pre-WGLC on the data 
> model document:
> The objective of this pre-WGLC review is for folks to take a fresh 
> look at the document and re-review the entire document. If you missed 
> the design team meeting on June 10th, you might also find it helpful 
> to look at the minutes/presentation for some background:
> issues so that once we close the above open issues the document is 
> ready for WGLC.
>
> Note, reviews that provide a general summary and then separate the 
> major and minor issues from the editorial nits, something like the 
> following, would be quite helpful.
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Roberta Presta <[email-masked]>
Date: Fri, 27 Jun 2014 12:12:37 +0200

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:
2. We have started to add some reference in the Introduction.
> 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 

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 
6. OK. Replaced with "given the Media Provider's ADVERTISEMENT".
> 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.

> 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.
> 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.
> 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?_
_
> attribute of the referenced media captures? We don't have a mediaType 
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 
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.
> 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.
> 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

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 27 Jun 2014 13:51:39 -0700

Hi Roberta,

I added just a few comments of my own.  I cut out the rest of the conversation which I am not commenting on.
Sorry I don’t have time to do a more complete pre-WGLC review before the deadline, but I do plan to do it soon after.

Is it possible to have a media capture type that is not video or audio or text?  Could it be done using just the mediaCaptureType generic element?

I thought we agreed <capturePoint> should be optional, and some text and the XML for it needs to be updated.  See the previous discussion here:
http://www.ietf.org/mail-archive/web/clue/current/msg03594.html

The title page says “Intended status: Informational”, but I think this should be Standards Track.

Regards,
Mark

From: clue [mailto:[email-masked]] On Behalf Of Roberta Presta
Sent: Friday, June 27, 2014 6:13 AM
To: [email-masked]; Christian Groves
Subject: [clue] Review Groves al data model 05 [Re: Pre-WGLC: draft-ietf-clue-data-model-schema-05.txt]

Dear Christian,

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

- 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?
[Duckworth, Mark] It looks good to me.  To Paul’s previous question, the “personTypeType” is ok with me.

- Cl.14.4: Perhaps we can use the SI notation of "mm" for "millimeters"?
17. We have nothing against it. What about the others?
[Duckworth, Mark] I’m in favor of using “mm” for the enumeration value.

- 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.
[Duckworth, Mark] Can there really be more than one “personInfo” vcard in a personType?

Thank you again,

Roberta

----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice Fiscale: 00876220633
www.unina.it/Vademecum5permille<http://www.unina.it/Vademecum5permille>

---

From: Christian Groves <[email-masked]>
Date: Mon, 30 Jun 2014 13:04:26 +1000

Hello Roberta,

Thanks for the reply. I'm OK with the handling of most of the comments. 
Please see my responses to the open ones below.

Regards, Christian

On 27/06/2014 8:12 PM, Roberta Presta wrote:
> ..snip..
> However,  up to now, the data model has followed the news introduced 
> in the framework.
> structure) in updates in the companion document (independently from 
> the precedence rule).
[CNG] I agree they are fairly well aligned. However we may find in the 
future that the description of something is open to interpretation. In 
that case does the reader follow what the framework says or what the 
data model says?
_..snip.._
> __
[CNG] I'm OK. We should just be consistent how it is applied.
> ..snip..
>> - 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.
>>
[CNG] I'm not sure I follow. Why can't CLUE import the RFC6351 XML 
directly without the dependency on draft-ietf-ecrit-additional-data ?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jun 2014 11:59:24 -0400

> that case does the reader follow what the framework says or what the

How can the data model not be definitive? If the model schema disagrees 
with the FW, then how can you follow the fw? You are constrained by what 
you can say with the schema.

So ISTM that we ought to at least say that if the *schema* differs from 
what the fw or the data model *text* say then the schema takes 
precedence. We then must do a careful review to ensure consistency.

	Thanks,
	Paul