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

[Simon Pietro Romano <[e-mail]>]

Thank you! 

Simon

Il 09 Maggio 2016 23:03:02 CEST, Alissa Cooper <[e-mail]> ha scritto:
>Thanks! I requested IETF last call.
>
>Alissa
>
>> On May 6, 2016, at 6:56 AM, Simon Pietro Romano <[e-mail]>
>wrote:
>> 
>> 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 <[e-mail]
><mailto:[e-mail]>> 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: [phone] -- Fax: [phone]
>>                                            e-mail: [e-mail]
><mailto:[e-mail]>
>> 
>> 		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
>> 		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>>                			                     oooO
>>   ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>> 					                 \ (            (   )
>> 			                                  \_)          ) /
>>                                                                      
> (_/
>> 
>> 
>> 
>> 
>> 
>>