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

From: Alissa Cooper <[email-masked]>
Date: Mon, 11 Apr 2016 16:23:12 -0700

Hi Simon,

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. 

> 
> 
>> = Section 3 =
>> 
>> CLUE consists of a small number of tightly coordinated specs. Why is this spec not using the definition of "CLUE Participant” from the Framework doc? What was the point of defining it the way it’s defined in the framework doc if it can’t be used in the schema? 
> 
> The CLUE Framework doc does not actually include a definition of the "CLUE Participant”. It rather introduces the “CLUE Endpoint”, consisting of “...of one or more physical devices...and exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent)”. What we needed in the data model doc was a definition as simple as “...a generic entity (either an Endpoint or a MCU) making use of the CLUE protocol”. Such a definition does not match the “CLUE Endpoint” of the framework and cannot even be replaced by the RFC4353 definition. Indeed, in the most general case, a CLUE Participant might even not use SIP at all. That’s why we took a freedom to put this (and only this) new definition in the data model document.

Ok.

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

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

> 
> 
>> (2)
>> Same comment as section 11.2.
>> 
>> = Section 11.18 and 11.19 =
>> 
>> The text says “The current possible values are …” — is there a plan to add more values? (I note this is different from the personType definition, which doesn’t say “current.”)
> 
> These are actually consistent, respectively, with section 7.1.1.7. (Presentation) and section 7.1.1.8. (View) of the framework document.

Ok.

> 
> 
>> = 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/

> 
>> = Section 11.27.2 =
>> 
>> Why is the media type attribute optional?
> 
> If the simultaneous set contains references to media captures, than you don’t need to specify the media type, since it is a mandatory attribute for each (referenced) media capture. On the other hand, as the last part of the paragraph explains, if you only use capture scene identifiers, than you’ll necessarily need to indicate the media type associated with the media captures belonging to the set in question and which can be sent simultaneously.

Ok, Mark’s explanation helped with this.

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

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

Thanks,
Alissa

> 
> 
>> 
>> = Section 29 =
>> 
>> The references are not split between normative and informative. It seems to me that only RFC 3550, RFC 3688, RFC 4353, and RFC 7667 should be informative references. The rest should be normative.
> 
> Agreed.
> 
>> Nits:
>> 
>> = General =
>> 
>> (1) For the ID elements, I think it would help to specify the scope within which the IDs are expected to be unique (e.g., within the advertisement, or more narrowly).
> 
> XML ID elements are defined in W3C terms, which means that: (i) the value is unique within the XML document; (ii) each element has at most one single unique identifier. When we wanted to relax such a constraint, we defined the “iD” as a string.
> 
>> = Section 11.1 =
>> 
>> s/(e.g., simultaneous sets, capture encodings, and others)/(e.g., simultaneous sets, capture encodings, and others via <captureIDREF>)
> 
> Done.
> 
>> = Section 11.7 =
>> 
>> s/last ones/latter ones/
> 
> Done.
> 
>> = Section 11.29.1.2 =
>> 
>> I think this section should point to Appendix A in the ecrit document.
> 
> Done.
> 
> Thanks again for your feedback and comments!
> 
> Simon
> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/clue
>