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

From: Oscar Novo <[email-masked]>
Date: Wed, 5 Jan 2011 13:04:37 +0100

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

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

Oscar

---

From: Robert Sparks <[email-masked]>
Date: Wed, 12 Jan 2011 14:32:51 -0600

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

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

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

> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Jan 2011 18:01:15 -0700

On 1/12/11 1:32 PM, Robert Sparks wrote:

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

I'll volunteer to look at that topics and other XML matters (probably
next week).

>>>> 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.
>>> 
>>> [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.
>> 
>> "If extensions (check section 6) beyond this specification are not
>> used, re-define anyAttribute as <empty/> and remove the definition
>> below"
>> 
> 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 agree with Robert here.

As a point of comparison, in XMPP we have many extension points. In some
environments, the deploying organization wishes to lock down the service
so that only particular extensions are allowed (say, only a small set of
known stream features during initial negotiation). And one way that such
organizations lock down the service is by performing schema validation
on all of the XMPP traffic, using a schema that removes ability to
extend the protocol at certain points. However, although we know that
some organizations do this, I don't think it's the kind of thing we'd
want to recommend or encourage, at least not in the core specification
for an XML protocol or format that by definition includes the extension
points.

Just my gram of silver...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Oscar Novo <[email-masked]>
Date: Thu, 13 Jan 2011 12:20:55 +0100

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:

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:[email-masked]] 
Sent: 12. tammikuuta 2011 22:33
To: Oscar Novo
Cc: [email-masked]; 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

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.

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?

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.

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

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. 

RjS

---

From: Oscar Novo <[email-masked]>
Date: Thu, 13 Jan 2011 12:21:24 +0100

Thanks Peter!

Oscar 

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: 13. tammikuuta 2011 3:01
To: Robert Sparks
Cc: Oscar Novo; [email-masked]; Gonzalo Camarillo
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19

> have is whether this is a normative update to 4575 as written.

I'll volunteer to look at that topics and other XML matters (probably next
week).

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

As a point of comparison, in XMPP we have many extension points. In some
environments, the deploying organization wishes to lock down the service so
that only particular extensions are allowed (say, only a small set of known
stream features during initial negotiation). And one way that such
organizations lock down the service is by performing schema validation on
all of the XMPP traffic, using a schema that removes ability to extend the
protocol at certain points. However, although we know that some
organizations do this, I don't think it's the kind of thing we'd want to
recommend or encourage, at least not in the core specification for an XML
protocol or format that by definition includes the extension points.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Robert Sparks <[email-masked]>
Date: Thu, 13 Jan 2011 14:44:35 -0600

One comment inline

>   especially when both lists contain the same user.

This is all good, but the last paragraph as written will require any future standardization effort that wants to create a new policy to include an RFC
that Updates this one. That may be required anyhow, but I want to make sure the group considers this consequence explicitly. It is not immediately
obvious to me what we might do differently.

---

From: Oscar Novo <[email-masked]>
Date: Fri, 14 Jan 2011 08:14:34 +0100

Hi Robert,

>obvious to me what we might do differently.

Right, I didnt think about that. Actually, allowing both lists may not be good idea. Most likely future extensions will create their own elements or will use the allowed-users-list and the deny-users-list separately. It might be better to disallow both list at the same time in future extensions.

What about changing the last paragraph to:

        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 disallow both appearing at the same time too.

Oscar

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

One comment inline

On Jan 13, 2011, at 5:20 AM, Oscar Novo wrote:

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

This is all good, but the last paragraph as written will require any future standardization effort that wants to create a new policy to include an RFC that Updates this one. That may be required anyhow, but I want to make sure the group considers this consequence explicitly. It is not immediately obvious to me what we might do differently.

>  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>.
>
>>> /------------------------Question-----------------------------------
>>> -
>>> -
>>>>
>>>>
>>>>
>>> /------------------------Question-----------------------------------
>>> -
>>> -
>>>>
>>>>
>>> explaining who the instructions are intended for and when they
>>> should be invoked.
>>>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 24 Jan 2011 12:41:50 -0600

That's probably too restrictive. It's not hard to imagine an authorization policy of "allow anyone on allowed unless they also appear on deny"
where someone not on either list gets one kind of rejection and someone on deny gets a different kind of rejection".  I don't think we buy anything
by preventing someone from specifying that as long as their specification is clear.

RjS

---

From: Oscar Novo <[email-masked]>
Date: Fri, 28 Jan 2011 16:03:23 +0100

So, what's your solution about it?

Oscar

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: 24. tammikuuta 2011 20:42
To: Oscar Novo
Cc: [email-masked]; Gonzalo Camarillo
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19

That's probably too restrictive. It's not hard to imagine an authorization policy of "allow anyone on allowed unless they also appear on deny"
where someone not on either list gets one kind of rejection and someone on deny gets a different kind of rejection".  I don't think we buy anything by preventing someone from specifying that as long as their specification is clear.

RjS

On Jan 14, 2011, at 1:14 AM, Oscar Novo wrote:

>
> Hi Robert,
>
>> This is all good, but the last paragraph as written will require any
>> future standardization effort that wants to create a new policy to
>> include an RFC that Updates this one. That may be required anyhow, but I want to make sure the group considers this consequence explicitly. It is not immediately obvious to me what we might do differently.
>
>>  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:
>>
>>  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.
>
>>>>> precedence? This should be made clear here, and the issue raised
>>>>> in the security considerations section.
>>>>>
>>>>>

---

From: Robert Sparks <[email-masked]>
Date: Fri, 28 Jan 2011 09:38:39 -0600

To stick with your first proposal (with a suggested tweak) and live with the consequences:

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 provide clear guidance on how to process
the lists when they occur concurrently,  especially when both lists contain the same user.
For example, such specification could disallow both list from appearing at the same time
similar to user-admission-policy values defined in this document. 

RjS

---

From: Oscar Novo <[email-masked]>
Date: Fri, 28 Jan 2011 16:47:04 +0100

OK, good enough. :)

So, I'll work in a new version of the draft next week.

Thanks Robert!

Oscar

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: 28. tammikuuta 2011 17:39
To: Oscar Novo
Cc: [email-masked]; Gonzalo Camarillo
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19

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 provide clear guidance on how to process the lists when they occur concurrently,  especially when both lists contain the same user.
For example, such specification could disallow both list from appearing at the same time similar to user-admission-policy values defined in this document.

RjS

On Jan 28, 2011, at 9:03 AM, Oscar Novo wrote:

>>>>> /------------------------Question---------------------------------
>>>>> -
>>>>> -
>>>>> -
>>>>> -
>>>>>>
>>>>>>
>>>>>>
>>>>> /------------------------Question---------------------------------
>>>>> -
>>>>> -
>>>>> -
>>>>> -
>>>>>>
>>>>>>