Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19

[Oscar Novo <[e-mail]>]

Hi Robert,

As you said, our ideas start to converge. So, I think a real-time meeting wouldn't be necessary at this moment. If the XCON chairs or you still think it's needed, I don't have any problem to set up a meeting with the group.

Now, here's the answers to your last e-mail. Let me know what you think about them and I can start working in a new version of the draft ASAP:

The data model document is a normative document and it constitutes a superset of the data format defined in 4575. 

The XML in the document has been reviewed many times. Jari and myself have validated the XML schema against 4575 too. However, I think it's a good idea Peter Saint-Andre reviewed again the XML. 

I think changing the namespace name of the document will mess up the things around. Note that there are other documents in the XCON WG using similar syntax, for instance, "Conference Event Package Data Format Extension for XCON" uses xcon-conference-info-diff. 

I agree to include the following text in section 4.2.10:

  The schema in Section 5 allows <conference-password> to appear anywhere uris-type is expanded. 
  This document  only provides meaning for <conference-password> appearing as a descendent of
  the <conf-uris> element. Future standardization may give meaning to <conference-password> appearing
  in other elements of type uris-type. In the absence of such standardization, <conference-password>
  MUST NOT appear in elements of type uris-type other than <conf-uris>.

Regarding the new text in 4.6.2 <user-admission policy> section. Would the following text fullfil your requirements?:

   The <user-admission-policy> is an element that lets an organizer (or a participant with appropriate rights) choose a policy for the
   conference that controls how users are authenticated into the conference, using a mechanism of the conference's choosing.  Since a
   variety of signaling protocols are possible, a variety of authentication mechanism - determined by every individual conference
   servers - may need to be mapped from the different protocols. The specific types of authentication mechanism are beyond the scope of
   this document.  The list of possible values are:

   o  "closedAuthenticated": A 'closedAuthenticated' policy MUST have each conference participant in the allowed users list
      (listed under the <allowed-users-list> XML element) with each participant being sufficiently (up to local policy) authenticated.
      Conference join requests for users not in the allowed users list or participants not authenticated should be rejected unless a
      <join-handling> action of 'confirm' is selected in which case the user is placed on a pending list as indicated earlier. An 'closedAuthenticated' 	policy MUST NOT include a <deny-users-list>. If <deny-users-list> appears in the data model, it MUST be ignored.
   o  "openAuthenticated": An 'openAuthenticated' policy requires each conferencing participant to be sufficiently authenticated. Typically this implies 	that anyone capable of authenticating with the conferencing system may join the conference. The 'openAuthenticated' policy permits the 	specification of "banned" conferencing participants. Such banned users are prevented from re-joining the conference until they have been un-banned. 	An 'openAuthenticated' policy SHOULD have a deny users list (listed under the <deny-users-list> XML element) to support banning of conferencing 	participants from a conference. An 'openAuthenticated' policy MUST NOT include an <allowed-users-list>. If <allowed-users-list> appears in the data 	model, it MUST be ignored.
   o  "anonymous": An 'anonymous' policy allows any join requests in and is the least restrictive policy. An 'anonymous' policy MUST NOT include either 	an <allowed-users-list> or a <deny-users-list>. If any of these lists appear in the data model, they MUST be ignored.

   In all other cases, the appearance of an <allowed-users-list> and <deny-users-list> MUST be ignored. Future specifications describing the use of these
   lists MUST either disallow both appearing at the same time or provide clear guidance on how to process the lists when they occur concurrently,  
   especially when both lists contain the same user.

Concerning your last question, as you suggested, I will remove the comments from all the extensibility elements.

Cheers,

Oscar

-----Original Message-----
From: Robert Sparks [mailto:[e-mail]] 
Sent: 12. tammikuuta 2011 22:33
To: Oscar Novo
Cc: [e-mail]; Gonzalo Camarillo
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19

Hi Oscar -

I think we're making progress and might be starting to converge. Let me know if you want to shift to real-time after responding to this message - I can ask the chairs to set up a conference for us to iron any last things out with the group if we need it.

RjS

On Jan 5, 2011, at 6:04 AM, Oscar Novo wrote:

> Hello Robert,
> 
> I've only included in this thread questions which need some answers, leaving all the other questions out of the thread for a matter of clarity.
> 
> 
>> [Robert] Do you intend to allow users of the data model to give meaning to a <conference-password> appearing inside an <associated-aors>?
>> The schema allows it (or am I reading the schema wrong?). Did the group _intend_ for the schema to allow that, and do they anticipate that it will have >any meaning at some point? Or should there be text that forbids that element appearing anywhere but <entry>? 
> 
> [O] The data model uses the <associated-aors> child element defined in RFC4575. In this case, the data model doesn't extend the <associated-aors> child element with the <conference-password>.

I was initially quite puzzled by this response. I went back and reread this document (and 4575s) definitions carefully, and I think I might see where we haven't been coming together.

Your statement above isn't quite right. This document restates the syntax defined in 4575 (using a RelaxNG schema), and shows where you take advantage of the extension points that were already in that grammar by adding elements using another namespace.

Using the grammar defined in this document, conference-password can be produced within associated-aor (and service-uris, host-info, users, and any other place uris-type gets invoked).

So to address my primary question instead of your proposal to add text to 4.6.5.2 below, I suggest instead to add this as a new paragraph at the end of section 4.2.10:

  The schema in Section 5 allows <conference-password> to appear anywhere uris-type is expanded. 
  This document  only provides meaning for <conference-password> appearing as a descendent of
  the <conf-uris> element. Future standardization may give meaning to <conference-password> appearing
  in other elements of type uris-type. In the absence of such standardization, <conference-password>
  MUST NOT appear in elements of type uris-type other than <conf-uris>.

I'll ask the xml directorate to review how we're restating 4575's schema. (Has such a review already been performed?). 
One question I have is whether this is a normative update to 4575 as written.

Also, while talking through this with others, I had several people comment that "xcon-conference-info" namespace and the "conference-info" namespaces are so visually similar that it's easy to misunderstand what this document is trying to do. How much implementation of xcon-conference-info exists now? Would it be feasible to change it to something more distinct from conference-info?

> 
> 
> I could add the following text to 4.6.5.2.: 
> 
>   "The <associated-aors> child element is explained in [RFC4575], section 5.6.2. This document does not extend the <associated-aors> child element with new elements or attributes."
> 
> 
>> /------------------------Question------------------------------------
>> -
>>> 
>>> 
>>> 
>>> * 4.6.3 and 4.6.4 : if the same user appears in an 
>>> <allowed-users-list> and in a <deny-users-list>, which takes 
>>> precedence? This should be made clear here, and the issue raised in 
>>> the security considerations section.
>>> 
>>> 
>>> [ON1] As we agreed in the WG, the semantic of those elements will be defined in further documents. 
> 
>> [Robert]I could possibly accept that if the group had defined a model that contained a <list> and handed semantics off to some attribute of the list >(such as ><list name="allowed users">).
> 
>> It doesn't. It defines lists and telegraphs semantics with the name. With what you've specified so far, you are encouraging a low level of >interoperability.
> 
>> I'll start a separate thread on this.
> 
> [O] The <allowed-users-list> and <deny-users-list> are linked with the <user-admission-policy> element. This element lets an organizer to choose an admission policy for the conference. The data model defines three types of admission: closedAuthenticated, openAuthenticated, anonymous. 
> 	- The "anonymous" policy allows everyone to connect to the conference.
> 	- The "closedAuthenticated" allows the users listed in the <allowed-users-list> to connect to the conference
> 	- The "openAuthentication" allows anyone capable of authenticating to join the conference. 
> 
> In the first case, banning a user is not support. In the second case, banning a user can be accomplished by removing the user from the <allowed-users-list>. In the third case, a <deny-users-list> is needed to support the concept.
> 
> I can understand the use of the <deny-users-list> is unclear in the document at this point. 
> I'm planning to add the following text in the 4.6.2 <user-admission policy>:
> 
> ""openAuthenticated": An 'openAuthenticated' policy requires each conferencing participant to be sufficiently authenticated. Typically this implies that anyone capable of authenticating with the conferencing system may join the conference.
> The 'openAuthenticated' policy permits the specification of "banned" conferencing participants. Such banned users are prevented from re-joining the conference until they have been un-banned. An 'openAuthenticated' policy requires a deny users list (listed under the <deny-users-list> XML element) to support banning of conferencing participants from a conference."
> 
> Do the text above clarify your question?

The additional text would help, but it's not sufficient yet.
Given what you say here, I'm looking for something that says:

If you are using an anonymous policy, you must not include either an allowed-users-list or a deny-users-list (and must ignore any that appeared).
If you are using an openAuthenticated policy, you may include a deny-users-list, but must not include an allowed-users-list (you must ignore any deny-users-list that appears).
If you are using a closedAuthenticated policy, you must include an allowed-users-list, and must not include a deny-users-list (you must ignore any deny-users-list that appears).
In all other cases, the appearance of an allowed-users-list and deny-users-list has no meaning defined by this document. Future specifications describing the use of these lists must either disallow both appearing at the same time or provide clear guidance on how to process the lists when they occur concurrently, especially when both lists contain the same user.

And I think it needs to say those things using 2119 words.


> 
> 
> 
>> /------------------------Question------------------------------------
>> -
>>> 
>>> 
>>> * In the Schama in section 5, there are several comment blocks 
>>> instructing someone to redefine something as <empty/> or 
>>> <notAllowed> (no trailing slash?).  Is this an established 
>>> convention documented somewhere? If so, can you provide a pointer? 
>>> If not, please add text explaining who the instructions are intended 
>>> for and when they should be invoked.
>>> 
>>> [ON] The Data Model is an extensible schema. We just indicate to the implementor how to limit the schema if it's not extended. The trailing slash has been included in the <notAllowed> element.
>> 
>> [RObert] Then,  please add text
>> explaining who the instructions are intended for and when they should 
>> be invoked.
>> 
>> [ON1] Is not the current text self-explanatory? Which instructions would you suggest? 
> 
>> [Robert] No, it's not self-explanatory - if it were, we wouldn't be having this conversation.
>> I suggest pulling it into an "Implementer note", introducing the note with a sentence or two explaining that this is something you can do if you know >>you are not going to use any extensions.
> 
> [O] Right, what about adding the following text in every extensibility elements?
> 
> "If extensions (check section 6) beyond this specification are not used, re-define anyAttribute as <empty/> and remove the definition below"
> 
> Would it be clear adding the text above?

Thinking about this some more, I believe this is dangerous, and is not something we should recommend as part of standardizing this model.
Basically, you're saying that an implementation that believes it isn't going to exercise an extension point can stub those extension points out.
In practice, this will result in incompatible versions of the schema being fielded, and in the worst of cases, when the implementer was _wrong_ about this implementation (or the things around it) wanting to use the extension points, results in a brittle system. We certainly can't prevent an implementer from making this simplification if they choose to do so, but it's a hazardous practice that is very likely to make rolling out extensions in the future more difficult. 

I think you should remove the comments from the document altogether.


RjS

> 
> Oscar