Subject: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 6 May 2016 15:56:15 +0200

Hi Alissa,

please find below our answers to your latest review (version -13 of the draft)...

> Thanks. I’ve reviewed the -13. Some responses below.
> 
>> On Mar 7, 2016, at 11:42 AM, Simon Pietro Romano <[email-masked]> wrote:
>> 
>>> (3) I think the explanation of each of the extensibility points in the document needs to be clearer. Some of the elements are extensible when I wouldn’t have expected them to be, and the document often doesn’t explain why the model’s extensibility is being specified as it is. For example, it’s not clear to me why the content type or the capture scene type are extensible, and there’s no explanation provided. For other types I can intuit why they are extensible, but it would help to make it explicit. 
>> 
>> We wanted to offer people enough flexibility as to define custom (and perhaps currently unforeseen) extensions to the schema, without losing compliance with the standard. We did this by leveraging  <xs:any> elemenrts and <xs:anyAttribute> attributes, which is a common approach with schemas, still matching the UPA (Unique Particle Attribution) Constraint. The "XML Schema extensibility” section was meant to illustrate the mentioned approach.
>> 
>>> (4) Furthermore, this data model seems to err way on the side of extensibility, leaving me to wonder just how much it will really facilitate interoperability. I think the trade-offs the WG is making here need to be thoroughly justified in the text. 
>> 
>> See my answer above to your comment number (3). What would you suggest to improve the way we deal with extensibility?
> 
> I think it would help to state in Section 14 that extensibility was purposefully favored as much as possible based on expectations about custom implementations. 

OK. We added to section 14 the following couple of sentences:

Elements or attributes from unknown namespaces MUST be ignored. Extensibility was purposefully favored as much as possible based on expectations about custom implementations. Hence, the schema offers people enough flexibility as to define custom extensions, without losing compliance with the standard. This is achieved by leveraging <xs:any> elements and <xs:anyAttribute> attributes, which is a common approach with schemas, still matching the UPA (Unique Particle Attribution) Constraint.

> 
>>> And why is it stated differently than how it’s stated in the protocol doc?
>> 
>> They are (or at least should be) indeed identical. I checked version -06 of the protocol and version -12 of the data model and found the following:
>> 
>> - Protocol:
>> 
>> CLUE Participant (CP):  An entity able to use the CLUE protocol within a telepresence session.  It can be an endpoint or an MCU able to use the CLUE protocol.
>> 
>> - Data Model:
>> 
>> This term is not imported from the framework terminology.  A CLUE Participant identifies a generic entity (either an Endpoint or a MCU) making use of the CLUE protocol.
>> 
>> If we decide that such a definition can survive, we might proceed as follows: (i) introduce it in the protocol draft; (ii) point to it in the data model draft. What’s your feeling about that?
> 
> Good idea.

Done. The CLUE Participant definition has been removed from the data model and replaced with a reference to the protocol document.

> 
>>> = Section 11.2 =
>>> 
>>> "Common values are "audio", "video",
>>> "text".  Other values can be provided.  It is assumed that
>>> implementations agree on the interpretation of those other values.”
>>> 
>>> This seems like an interop problem waiting to happen, since there is no registry specified for these values. Why not create one so that independent implementers can at least know what other values may be supported by other implementations?
>> 
>> I’m not sure I understand this point correctly. The idea here was to be as generic as possible. That’s why: (i) the basic media capture type is an abstract one; (ii) “concrete” definitions for audio, video and text capture types have been specified;
> 
> Referencing the registry as Roni suggested would help.
> 
>> (iii)  a 100% generic “otherCaptureType” type has been defined; (iv) the “mediaType” attribute has been generically defined as a string, with no particular template.
>> 
>> That’s why we assume that if one chooses to rely on a brand new media type and wants to interoperate with others, an (application-level) agreement is needed on how to interpret such information.
> 
> If I’m an implementer and I want to start using some new media type, it would be helpful for me to know if there are already other implementations out there using that media type name before I decide whether I want to risk collisions with however the attribute is already being interpreted, or whether I want to name mine something different and go negotiate what its interpretation should be. Not a huge deal and we can see if anyone else raises this in IETF LC or IESG review, but just an example where it seems like there could be a significant barrier to achieving interop if people decide to use this extension point.

We tried to summarize all of the above considerations (including Roni’s suggestion) and arrived at the following re-wording of Section 11.2. Please let us know what you think about it now:

The "mediaType" attribute is a mandatory attribute specifying the media type of the capture. Common standard values are "audio", "video", "text", as defined in [RFC6838] <http://xml2rfc.ietf.org/cgi-bin/xml2rfc-old.cgi#RFC6838>. Other values can be provided. It is assumed that implementations agree on the interpretation of those other values. The "mediaType" attribute is as generic as possible. Here is why: (i) the basic media capture type is an abstract one; (ii) "concrete" definitions for the standard ([RFC6838] <http://xml2rfc.ietf.org/cgi-bin/xml2rfc-old.cgi#RFC6838>) audio, video and text capture types have been specified; (iii) a generic "otherCaptureType" type has been defined; (iv) the "mediaType" attribute has been generically defined as a string, with no particular template. From the considerations above, it is clear that if one chooses to rely on a brand new media type and wants to interoperate with others, an application-level agreement is needed on how to interpret such information.

>> 
>>> = Section 11.23 =
>>> 
>>> "When defining new media capture types that are going to be described
>>> by means of the <otherMediaCapture> element, spatial properties of
>>> such new media capture types SHOULD be defined (e.g., whether or not
>>> they are spatially definable, whether or not they should be
>>> associated with an area of capture, etc.).”
>>> 
>>> Are there other spatial properties that should be defined besides the two that are listed? If this is going to be a normative requirement, the list should be precise.
>> 
>> What we wanted to state here is that a new media capture might require the definition of spatial properties. In such a case, the <spatialInformation> element would be present and would contain (at least) either the capture origin, or the capture area, or both. The list is not exhaustive, since, like all other pieces of information in the schema, further elements and attributes can be added if needed (extensibility).
> 
> Ok, I think you need something like
> s/etc./or other properties that may be defined/

Done.

> 
>>> = Section 15 =
>>> 
>>> (1) What does “full-optional” mean?
>> 
>> Nothing meaningful, indeed :-). We meant something like "full-fledged”, “thoroughly specified”, or similar. What would you suggest here?
> 
> Either of those would work.

Done (replaced with full-fledged).

> 
>> (2) "Data model information carried within CLUE messages SHOULD be accessed only by authenticated endpoints.” The exception cases to this recommendation should be described.
>> 
>> We tried to highlight the fact that authenticated access is strongly advisable, especially if you convey information about individuals (<personalInfo>) and/or scenes (<sceneInformation>). There might be more exceptions, depending on the level of criticality that is associated with the setup and configuration of a specific session. In principle, one might even decide that no protection at all is needed for a particular session; that’s why we did not make this a MUST.
> 
> Ok, please add some text to explain what you explain above.

Done. We added a short paragraph to the section, which states the following:

Indeed, authenticated access is strongly advisable, especially if you convey 
information about individuals (&lt;personalInfo&gt;) and/or scenes (&lt;sceneInformation&gt;). 
There might be more exceptions, depending on the level of criticality that is associated 
with the setup and configuration of a specific session. In principle, one might even decide 
that no protection at all is needed for a particular session; here is why authentication
has not been identified as a mandatory requirement. 

> Thanks,
> Alissa

Thank you! Your feedback was really helpful.

Cheers,

Simon

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 9 May 2016 14:03:02 -0700

Thanks! I requested IETF last call.

Alissa

> On May 6, 2016, at 6:56 AM, Simon Pietro Romano <[email-masked]> wrote:
> 
> Hi Alissa,
> 
>>> On Mar 7, 2016, at 11:42 AM, Simon Pietro Romano <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>                                            e-mail: [email-masked] <mailto:[email-masked]>
>

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 10 May 2016 07:16:05 +0200

Thank you! 

Simon

Il 09 Maggio 2016 23:03:02 CEST, Alissa Cooper <[email-masked]> ha scritto:
>>>>> (3) I think the explanation of each of the extensibility points in
>the document needs to be clearer. Some of the elements are extensible
>when I wouldn’t have expected them to be, and the document often
>doesn’t explain why the model’s extensibility is being specified as it
>is. For example, it’s not clear to me why the content type or the
>capture scene type are extensible, and there’s no explanation provided.
>For other types I can intuit why they are extensible, but it would help
>to make it explicit. 
>>>> 
>>>> We wanted to offer people enough flexibility as to define custom
>(and perhaps currently unforeseen) extensions to the schema, without
>losing compliance with the standard. We did this by leveraging 
><xs:any> elemenrts and <xs:anyAttribute> attributes, which is a common
>approach with schemas, still matching the UPA (Unique Particle
>Attribution) Constraint. The "XML Schema extensibility” section was
>meant to illustrate the mentioned approach.
>>>> 
>>>>> (4) Furthermore, this data model seems to err way on the side of
>extensibility, leaving me to wonder just how much it will really
>facilitate interoperability. I think the trade-offs the WG is making
>here need to be thoroughly justified in the text. 
>>>> 
>>>> See my answer above to your comment number (3). What would you
>suggest to improve the way we deal with extensibility?
>>> 
>>> I think it would help to state in Section 14 that extensibility was
>purposefully favored as much as possible based on expectations about
>custom implementations. 
>> 
>> Elements or attributes from unknown namespaces MUST be ignored.
>Extensibility was purposefully favored as much as possible based on
>expectations about custom implementations. Hence, the schema offers
>people enough flexibility as to define custom extensions, without
>losing compliance with the standard. This is achieved by leveraging
><xs:any> elements and <xs:anyAttribute> attributes, which is a common
>approach with schemas, still matching the UPA (Unique Particle
>Attribution) Constraint.
>> 
>>> 
>>>> They are (or at least should be) indeed identical. I checked
>version -06 of the protocol and version -12 of the data model and found
>the following:
>>>> 
>>>> - Protocol:
>>>> 
>>>> CLUE Participant (CP):  An entity able to use the CLUE protocol
>within a telepresence session.  It can be an endpoint or an MCU able to
>use the CLUE protocol.
>>>> 
>>>> - Data Model:
>>>> 
>>>> This term is not imported from the framework terminology.  A CLUE
>Participant identifies a generic entity (either an Endpoint or a MCU)
>making use of the CLUE protocol.
>>>> 
>>>> If we decide that such a definition can survive, we might proceed
>as follows: (i) introduce it in the protocol draft; (ii) point to it in
>the data model draft. What’s your feeling about that?
>>> 
>>> Good idea.
>> 
>> Done. The CLUE Participant definition has been removed from the data
>model and replaced with a reference to the protocol document.
>> 
>>> 
>>>>> = Section 11.2 =
>>>>> 
>>>>> This seems like an interop problem waiting to happen, since there
>is no registry specified for these values. Why not create one so that
>independent implementers can at least know what other values may be
>supported by other implementations?
>>>> 
>>>> I’m not sure I understand this point correctly. The idea here was
>to be as generic as possible. That’s why: (i) the basic media capture
>type is an abstract one; (ii) “concrete” definitions for audio, video
>and text capture types have been specified;
>>> 
>>>> (iii)  a 100% generic “otherCaptureType” type has been defined;
>(iv) the “mediaType” attribute has been generically defined as a
>string, with no particular template.
>>>> 
>>>> That’s why we assume that if one chooses to rely on a brand new
>media type and wants to interoperate with others, an
>(application-level) agreement is needed on how to interpret such
>information.
>>> 
>>> If I’m an implementer and I want to start using some new media type,
>it would be helpful for me to know if there are already other
>implementations out there using that media type name before I decide
>whether I want to risk collisions with however the attribute is already
>being interpreted, or whether I want to name mine something different
>and go negotiate what its interpretation should be. Not a huge deal and
>we can see if anyone else raises this in IETF LC or IESG review, but
>just an example where it seems like there could be a significant
>barrier to achieving interop if people decide to use this extension
>point.
>> 
>> We tried to summarize all of the above considerations (including
>Roni’s suggestion) and arrived at the following re-wording of Section
>11.2. Please let us know what you think about it now:
>> 
>> The "mediaType" attribute is a mandatory attribute specifying the
>media type of the capture. Common standard values are "audio", "video",
>"text", as defined in [RFC6838]
><http://xml2rfc.ietf.org/cgi-bin/xml2rfc-old.cgi#RFC6838>. Other values
>can be provided. It is assumed that implementations agree on the
>interpretation of those other values. The "mediaType" attribute is as
>generic as possible. Here is why: (i) the basic media capture type is
>an abstract one; (ii) "concrete" definitions for the standard
>([RFC6838] <http://xml2rfc.ietf.org/cgi-bin/xml2rfc-old.cgi#RFC6838>)
>audio, video and text capture types have been specified; (iii) a
>generic "otherCaptureType" type has been defined; (iv) the "mediaType"
>attribute has been generically defined as a string, with no particular
>template. From the considerations above, it is clear that if one
>chooses to rely on a brand new media type and wants to interoperate
>with others, an application-level agreement is needed on how to
>interpret such information.
>> 
>> 
>>>> 
>>>>> = Section 11.23 =
>>>>> 
>>>>> Are there other spatial properties that should be defined besides
>the two that are listed? If this is going to be a normative
>requirement, the list should be precise.
>>>> 
>>>> What we wanted to state here is that a new media capture might
>require the definition of spatial properties. In such a case, the
><spatialInformation> element would be present and would contain (at
>least) either the capture origin, or the capture area, or both. The
>list is not exhaustive, since, like all other pieces of information in
>the schema, further elements and attributes can be added if needed
>(extensibility).
>>> 
>>>> Nothing meaningful, indeed :-). We meant something like
>"full-fledged”, “thoroughly specified”, or similar. What would you
>suggest here?
>>> 
>>>> (2) "Data model information carried within CLUE messages SHOULD be
>accessed only by authenticated endpoints.” The exception cases to this
>recommendation should be described.
>>>> 
>>>> We tried to highlight the fact that authenticated access is
>strongly advisable, especially if you convey information about
>individuals (<personalInfo>) and/or scenes (<sceneInformation>). There
>might be more exceptions, depending on the level of criticality that is
>associated with the setup and configuration of a specific session. In
>principle, one might even decide that no protection at all is needed
>for a particular session; that’s why we did not make this a MUST.
>>> 
><mailto:[email-masked]>
>>