From oscar.novo@ericsson.com  Wed Jan  5 04:02:35 2011
Return-Path: <oscar.novo@ericsson.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05DE03A6DDC for <xcon@core3.amsl.com>; Wed,  5 Jan 2011 04:02:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YZTl5+nUW-h for <xcon@core3.amsl.com>; Wed,  5 Jan 2011 04:02:34 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8FB963A6B74 for <xcon@ietf.org>; Wed,  5 Jan 2011 04:02:33 -0800 (PST)
X-AuditID: c1b4fb3d-b7b89ae0000036a3-33-4d245e5784f6
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 96.6E.13987.75E542D4; Wed,  5 Jan 2011 13:04:39 +0100 (CET)
Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.221]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 5 Jan 2011 13:04:39 +0100
From: Oscar Novo <oscar.novo@ericsson.com>
To: Robert Sparks <rjsparks@nostrum.com>
Date: Wed, 5 Jan 2011 13:04:37 +0100
Thread-Topic: [XCON] AD review: draft-ietf-xcon-common-data-model-19
Thread-Index: AcuivttgXOWYgeBdTEWl5ab3F8QwHAJ89YxA
Message-ID: <58E207308662A748A4AC1ECB4E88561401304EC4A5@ESESSCMS0355.eemea.ericsson.se>
References: <326FB158-5C3C-48FC-96C6-252ABE05A10B@nostrum.com> <58E207308662A748A4AC1ECB4E88561403D02C92@ESESSCMS0355.eemea.ericsson.se> <537E4975-C9FB-4046-A264-C3325310959B@nostrum.com> <58E207308662A748A4AC1ECB4E885614013029BA0E@ESESSCMS0355.eemea.ericsson.se> <0957E5CB-0D6C-4992-9AF5-55C1DC2E9AFF@nostrum.com>
In-Reply-To: <0957E5CB-0D6C-4992-9AF5-55C1DC2E9AFF@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "xcon@ietf.org" <xcon@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jan 2011 12:02:35 -0000

Hello Robert,

I've only included in this thread questions which need some answers, leavin=
g 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 t=
o a <conference-password> appearing inside an <associated-aors>?
>The schema allows it (or am I reading the schema wrong?). Did the group _i=
ntend_ for the schema to allow that, and do they anticipate that it will ha=
ve >any meaning at some point? Or should there be text that forbids that el=
ement appearing anywhere but <entry>?=20

[O] The data model uses the <associated-aors> child element defined in RFC4=
575. In this case, the data model doesn't extend the <associated-aors> chil=
d element with the <conference-password>.

I could add the following text to 4.6.5.2.:=20

   "The <associated-aors> child element is explained in [RFC4575], section =
5.6.2. This document does not extend the <associated-aors> child element wi=
th new elements or attributes."


>/------------------------Question-------------------------------------
>>=20
>>=20
>>=20
>> * 4.6.3 and 4.6.4 : if the same user appears in an=20
>> <allowed-users-list> and in a <deny-users-list>, which takes=20
>> precedence? This should be made clear here, and the issue raised in=20
>> the security considerations section.
>>=20
>>=20
>> [ON1] As we agreed in the WG, the semantic of those elements will be def=
ined in further documents.=20

> [Robert]I could possibly accept that if the group had defined a model tha=
t contained a <list> and handed semantics off to some attribute of the list=
 >(such as ><list name=3D"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 >interoper=
ability.

>I'll start a separate thread on this.

[O] The <allowed-users-list> and <deny-users-list> are linked with the <use=
r-admission-policy> element. This element lets an organizer to choose an ad=
mission policy for the conference. The data model defines three types of ad=
mission: closedAuthenticated, openAuthenticated, anonymous.=20
	- 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.=20

In the first case, banning a user is not support. In the second case, banni=
ng 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 conc=
ept.

I can understand the use of the <deny-users-list> is unclear in the documen=
t at this point.=20
I'm planning to add the following text in the 4.6.2 <user-admission policy>=
:

""openAuthenticated": An 'openAuthenticated' policy requires each conferenc=
ing participant to be sufficiently authenticated. Typically this implies th=
at anyone capable of authenticating with the conferencing system may join t=
he conference.
The 'openAuthenticated' policy permits the specification of "banned" confer=
encing participants. Such banned users are prevented from re-joining the co=
nference until they have been un-banned. An 'openAuthenticated' policy requ=
ires 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-------------------------------------
>>=20
>>=20
>> * In the Schama in section 5, there are several comment blocks=20
>> instructing someone to redefine something as <empty/> or <notAllowed>=20
>> (no trailing slash?).  Is this an established convention documented=20
>> somewhere? If so, can you provide a pointer? If not, please add text=20
>> explaining who the instructions are intended for and when they should=20
>> be invoked.
>>=20
>> [ON] The Data Model is an extensible schema. We just indicate to the imp=
lementor how to limit the schema if it's not extended. The trailing slash h=
as been included in the <notAllowed> element.
>=20
> [RObert] Then,  please add text
> explaining who the instructions are intended for and when they should=20
> be invoked.
>=20
> [ON1] Is not the current text self-explanatory? Which instructions would =
you suggest?=20

>[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 elem=
ents?

"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 rjsparks@nostrum.com  Wed Jan 12 12:30:43 2011
Return-Path: <rjsparks@nostrum.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC003A6A9C for <xcon@core3.amsl.com>; Wed, 12 Jan 2011 12:30:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level: 
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYr4MfgLxVAX for <xcon@core3.amsl.com>; Wed, 12 Jan 2011 12:30:42 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 82DEA3A6A93 for <xcon@ietf.org>; Wed, 12 Jan 2011 12:30:41 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0CKWp8h084257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jan 2011 14:32:52 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <58E207308662A748A4AC1ECB4E88561401304EC4A5@ESESSCMS0355.eemea.ericsson.se>
Date: Wed, 12 Jan 2011 14:32:51 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DE83F89-E769-4112-91E8-27F96AC69D45@nostrum.com>
References: <326FB158-5C3C-48FC-96C6-252ABE05A10B@nostrum.com> <58E207308662A748A4AC1ECB4E88561403D02C92@ESESSCMS0355.eemea.ericsson.se> <537E4975-C9FB-4046-A264-C3325310959B@nostrum.com> <58E207308662A748A4AC1ECB4E885614013029BA0E@ESESSCMS0355.eemea.ericsson.se> <0957E5CB-0D6C-4992-9AF5-55C1DC2E9AFF@nostrum.com> <58E207308662A748A4AC1ECB4E88561401304EC4A5@ESESSCMS0355.eemea.ericsson.se>
To: Oscar Novo <oscar.novo@ericsson.com>
X-Mailer: Apple Mail (2.1082)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: "xcon@ietf.org" <xcon@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jan 2011 20:30:43 -0000

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,
>=20
> 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.
>=20
>=20
>> [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>?=20
>=20
> [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.=20
  This document  only provides meaning for <conference-password> =
appearing as a descendent of=20
  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>=20
  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?).=20
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?

>=20
>=20
> I could add the following text to 4.6.5.2.:=20
>=20
>   "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."
>=20
>=20
>> =
/------------------------Question-------------------------------------
>>>=20
>>>=20
>>>=20
>>> * 4.6.3 and 4.6.4 : if the same user appears in an=20
>>> <allowed-users-list> and in a <deny-users-list>, which takes=20
>>> precedence? This should be made clear here, and the issue raised in=20=

>>> the security considerations section.
>>>=20
>>>=20
>>> [ON1] As we agreed in the WG, the semantic of those elements will be =
defined in further documents.=20
>=20
>> [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=3D"allowed users">).
>=20
>> 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.
>=20
>> I'll start a separate thread on this.
>=20
> [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.=20
> 	- 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.=20
>=20
> 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.
>=20
> I can understand the use of the <deny-users-list> is unclear in the =
document at this point.=20
> I'm planning to add the following text in the 4.6.2 <user-admission =
policy>:
>=20
> ""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."
>=20
> 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.


>=20
>=20
>=20
>> =
/------------------------Question-------------------------------------
>>>=20
>>>=20
>>> * In the Schama in section 5, there are several comment blocks=20
>>> instructing someone to redefine something as <empty/> or =
<notAllowed>=20
>>> (no trailing slash?).  Is this an established convention documented=20=

>>> somewhere? If so, can you provide a pointer? If not, please add text=20=

>>> explaining who the instructions are intended for and when they =
should=20
>>> be invoked.
>>>=20
>>> [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.
>>=20
>> [RObert] Then,  please add text
>> explaining who the instructions are intended for and when they should=20=

>> be invoked.
>>=20
>> [ON1] Is not the current text self-explanatory? Which instructions =
would you suggest?=20
>=20
>> [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.
>=20
> [O] Right, what about adding the following text in every extensibility =
elements?
>=20
> "If extensions (check section 6) beyond this specification are not =
used, re-define anyAttribute as <empty/> and remove the definition =
below"
>=20
> 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=20
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.=20

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


RjS

>=20
> Oscar


From stpeter@stpeter.im  Wed Jan 12 16:59:07 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0E43A67AE for <xcon@core3.amsl.com>; Wed, 12 Jan 2011 16:59:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.442
X-Spam-Level: 
X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drAuoRcEC0Hp for <xcon@core3.amsl.com>; Wed, 12 Jan 2011 16:59:06 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 55CCA3A67A4 for <xcon@ietf.org>; Wed, 12 Jan 2011 16:59:06 -0800 (PST)
Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B5F29400EE; Wed, 12 Jan 2011 18:16:23 -0700 (MST)
Message-ID: <4D2E4EDB.6000403@stpeter.im>
Date: Wed, 12 Jan 2011 18:01:15 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Robert Sparks <rjsparks@nostrum.com>
References: <326FB158-5C3C-48FC-96C6-252ABE05A10B@nostrum.com>	<58E207308662A748A4AC1ECB4E88561403D02C92@ESESSCMS0355.eemea.ericsson.se>	<537E4975-C9FB-4046-A264-C3325310959B@nostrum.com>	<58E207308662A748A4AC1ECB4E885614013029BA0E@ESESSCMS0355.eemea.ericsson.se>	<0957E5CB-0D6C-4992-9AF5-55C1DC2E9AFF@nostrum.com>	<58E207308662A748A4AC1ECB4E88561401304EC4A5@ESESSCMS0355.eemea.ericsson.se> <0DE83F89-E769-4112-91E8-27F96AC69D45@nostrum.com>
In-Reply-To: <0DE83F89-E769-4112-91E8-27F96AC69D45@nostrum.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060002040300040208030408"
Cc: "xcon@ietf.org" <xcon@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jan 2011 00:59:07 -0000

This is a cryptographically signed message in MIME format.

--------------ms060002040300040208030408
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

>>> /------------------------Question------------------------------------=
-
>>>>
>>>>
>>>>
>>>=20
* 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.
>>>>=20
>>>> [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.
>>>=20
>>> [RObert] Then,  please add text explaining who the instructions
>>> are intended for and when they should be invoked.
>>>=20
>>> [ON1] Is not the current text self-explanatory? Which
>>> instructions would you suggest?
>>=20
>>> [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.
>>=20
>> [O] Right, what about adding the following text in every
>> extensibility elements?
>>=20
>> "If extensions (check section 6) beyond this specification are not
>> used, re-define anyAttribute as <empty/> and remove the definition
>> below"
>>=20
>> Would it be clear adding the text above?
>=20
> 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.
>=20
> I think you should remove the comments from the document altogether.

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

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




--------------ms060002040300040208030408
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEx
MzAxMDExNlowIwYJKoZIhvcNAQkEMRYEFH4UUqaVhU/pStLPIJkGWqokcgDVMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBGeIV7kBMfv4n9gRdqr2FNJY/jz9jNSRAu6ukocvl+x3Q8XQCMVO8FiPyG
oUCcIe9GbuC0hM/S4aYCa3Kr0BRdl8F4f4cBKaSoBux4izNPRumuYpXJQ5qOh6o5wCl0yOq8
6/kI73EkuCyJBG3Q9y4gZrsk4ccAkIf5gzDQcx2BFcju1zY28wSUuGGYMWoFk8Jv3+ha3iAa
WyX6nVvJFk7lYuh1S8AzUL1rRQwSM2y6HBQEfAZWbDTWCyGbaVOoOXXtvF7MSPup5BOqy9YY
InDk2Pp49QMiGTmo4PKSAILw0PHcUKWmi+gIfPd6mG4NcnvS8ZVkZjqCp0ZGqR0FAz7aAAAA
AAAA
--------------ms060002040300040208030408--

From oscar.novo@ericsson.com  Thu Jan 13 03:18:37 2011
Return-Path: <oscar.novo@ericsson.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB6033A6B60 for <xcon@core3.amsl.com>; Thu, 13 Jan 2011 03:18:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HStUS-olZqK for <xcon@core3.amsl.com>; Thu, 13 Jan 2011 03:18:36 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 9F69B3A6B58 for <xcon@ietf.org>; Thu, 13 Jan 2011 03:18:35 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-04-4d2ee019e6f7
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CD.F8.23694.910EE2D4; Thu, 13 Jan 2011 12:20:57 +0100 (CET)
Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.2.69]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 13 Jan 2011 12:20:56 +0100
From: Oscar Novo <oscar.novo@ericsson.com>
To: Robert Sparks <rjsparks@nostrum.com>
Date: Thu, 13 Jan 2011 12:20:55 +0100
Thread-Topic: [XCON] AD review: draft-ietf-xcon-common-data-model-19
Thread-Index: Acuyl+gHyntYwBOcSQC5rDvMznU0+AAZdrAw
Message-ID: <58E207308662A748A4AC1ECB4E885614052C5D2655@ESESSCMS0355.eemea.ericsson.se>
References: <326FB158-5C3C-48FC-96C6-252ABE05A10B@nostrum.com> <58E207308662A748A4AC1ECB4E88561403D02C92@ESESSCMS0355.eemea.ericsson.se> <537E4975-C9FB-4046-A264-C3325310959B@nostrum.com> <58E207308662A748A4AC1ECB4E885614013029BA0E@ESESSCMS0355.eemea.ericsson.se> <0957E5CB-0D6C-4992-9AF5-55C1DC2E9AFF@nostrum.com> <58E207308662A748A4AC1ECB4E88561401304EC4A5@ESESSCMS0355.eemea.ericsson.se> <0DE83F89-E769-4112-91E8-27F96AC69D45@nostrum.com>
In-Reply-To: <0DE83F89-E769-4112-91E8-27F96AC69D45@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "xcon@ietf.org" <xcon@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jan 2011 11:18:38 -0000

Hi Robert,

As you said, our ideas start to converge. So, I think a real-time meeting w=
ouldn'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 abo=
ut 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 supers=
et of the data format defined in 4575.=20

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 ide=
a Peter Saint-Andre reviewed again the XML.=20

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 s=
yntax, for instance, "Conference Event Package Data Format Extension for XC=
ON" uses xcon-conference-info-diff.=20

I agree to include the following text in section 4.2.10:

  The schema in Section 5 allows <conference-password> to appear anywhere u=
ris-type is expanded.=20
  This document  only provides meaning for <conference-password> appearing =
as a descendent of
  the <conf-uris> element. Future standardization may give meaning to <conf=
erence-password> appearing
  in other elements of type uris-type. In the absence of such standardizati=
on, <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 p=
articipant 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 specif=
ic 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 partici=
pant being sufficiently (up to local policy) authenticated.
      Conference join requests for users not in the allowed users list or p=
articipants not authenticated should be rejected unless a
      <join-handling> action of 'confirm' is selected in which case the use=
r is placed on a pending list as indicated earlier. An 'closedAuthenticated=
' 	policy MUST NOT include a <deny-users-list>. If <deny-users-list> appear=
s in the data model, it MUST be ignored.
   o  "openAuthenticated": An 'openAuthenticated' policy requires each conf=
erencing participant to be sufficiently authenticated. Typically this impli=
es 	that anyone capable of authenticating with the conferencing system may =
join the conference. The 'openAuthenticated' policy permits the 	specificat=
ion of "banned" conferencing participants. Such banned users are prevented =
from re-joining the conference until they have been un-banned. 	An 'openAut=
henticated' policy SHOULD have a deny users list (listed under the <deny-us=
ers-list> XML element) to support banning of conferencing 	participants fro=
m 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 eithe=
r 	an <allowed-users-list> or a <deny-users-list>. If any of these lists ap=
pear 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 th=
ese
   lists MUST either disallow both appearing at the same time or provide cl=
ear guidance on how to process the lists when they occur concurrently, =20
   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:rjsparks@nostrum.com]=20
Sent: 12. tammikuuta 2011 22:33
To: Oscar Novo
Cc: xcon@ietf.org; 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 kno=
w if you want to shift to real-time after responding to this message - I ca=
n 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,
>=20
> I've only included in this thread questions which need some answers, leav=
ing all the other questions out of the thread for a matter of clarity.
>=20
>=20
>> [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>?=20
>=20
> [O] The data model uses the <associated-aors> child element defined in RF=
C4575. In this case, the data model doesn't extend the <associated-aors> ch=
ild 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 d=
efined in 4575 (using a RelaxNG schema), and shows where you take advantage=
 of the extension points that were already in that grammar by adding elemen=
ts using another namespace.

Using the grammar defined in this document, conference-password can be prod=
uced within associated-aor (and service-uris, host-info, users, and any oth=
er 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 o=
f section 4.2.10:

  The schema in Section 5 allows <conference-password> to appear anywhere u=
ris-type is expanded.=20
  This document  only provides meaning for <conference-password> appearing =
as a descendent of
  the <conf-uris> element. Future standardization may give meaning to <conf=
erence-password> appearing
  in other elements of type uris-type. In the absence of such standardizati=
on, <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?).=20
One question I have is whether this is a normative update to 4575 as writte=
n.

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 confere=
nce-info?

>=20
>=20
> I could add the following text to 4.6.5.2.:=20
>=20
>   "The <associated-aors> child element is explained in [RFC4575], section=
 5.6.2. This document does not extend the <associated-aors> child element w=
ith new elements or attributes."
>=20
>=20
>> /------------------------Question------------------------------------
>> -
>>>=20
>>>=20
>>>=20
>>> * 4.6.3 and 4.6.4 : if the same user appears in an=20
>>> <allowed-users-list> and in a <deny-users-list>, which takes=20
>>> precedence? This should be made clear here, and the issue raised in=20
>>> the security considerations section.
>>>=20
>>>=20
>>> [ON1] As we agreed in the WG, the semantic of those elements will be de=
fined in further documents.=20
>=20
>> [Robert]I could possibly accept that if the group had defined a model th=
at contained a <list> and handed semantics off to some attribute of the lis=
t >(such as ><list name=3D"allowed users">).
>=20
>> It doesn't. It defines lists and telegraphs semantics with the name. Wit=
h what you've specified so far, you are encouraging a low level of >interop=
erability.
>=20
>> I'll start a separate thread on this.
>=20
> [O] The <allowed-users-list> and <deny-users-list> are linked with the <u=
ser-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.=20
> 	- The "anonymous" policy allows everyone to connect to the conference.
> 	- The "closedAuthenticated" allows the users listed in the <allowed-user=
s-list> to connect to the conference
> 	- The "openAuthentication" allows anyone capable of authenticating to jo=
in the conference.=20
>=20
> In the first case, banning a user is not support. In the second case, ban=
ning a user can be accomplished by removing the user from the <allowed-user=
s-list>. In the third case, a <deny-users-list> is needed to support the co=
ncept.
>=20
> I can understand the use of the <deny-users-list> is unclear in the docum=
ent at this point.=20
> I'm planning to add the following text in the 4.6.2 <user-admission polic=
y>:
>=20
> ""openAuthenticated": An 'openAuthenticated' policy requires each confere=
ncing 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" conf=
erencing participants. Such banned users are prevented from re-joining the =
conference until they have been un-banned. An 'openAuthenticated' policy re=
quires a deny users list (listed under the <deny-users-list> XML element) t=
o support banning of conferencing participants from a conference."
>=20
> 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 allowe=
d-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 den=
y-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 describ=
ing 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.


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

Thinking about this some more, I believe this is dangerous, and is not some=
thing we should recommend as part of standardizing this model.
Basically, you're saying that an implementation that believes it isn't goin=
g 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 implemen=
ter from making this simplification if they choose to do so, but it's a haz=
ardous practice that is very likely to make rolling out extensions in the f=
uture more difficult.=20

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


RjS

>=20
> Oscar


From oscar.novo@ericsson.com  Thu Jan 13 03:19:07 2011
Return-Path: <oscar.novo@ericsson.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D3A28C0E4 for <xcon@core3.amsl.com>; Thu, 13 Jan 2011 03:19:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbYi2Tb2F1zI for <xcon@core3.amsl.com>; Thu, 13 Jan 2011 03:19:05 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 6E1F63A6B60 for <xcon@ietf.org>; Thu, 13 Jan 2011 03:19:05 -0800 (PST)
X-AuditID: c1b4fb3d-b7b89ae0000036a3-65-4d2ee036c3f0
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3E.F6.13987.630EE2D4; Thu, 13 Jan 2011 12:21:27 +0100 (CET)
Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.2.69]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 13 Jan 2011 12:21:26 +0100
From: Oscar Novo <oscar.novo@ericsson.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, Robert Sparks <rjsparks@nostrum.com>
Date: Thu, 13 Jan 2011 12:21:24 +0100
Thread-Topic: [XCON] AD review: draft-ietf-xcon-common-data-model-19
Thread-Index: AcuyvWnBnnuQDkc/QLuvObQ3M6/KRwAVo0JA
Message-ID: <58E207308662A748A4AC1ECB4E885614052C5D2659@ESESSCMS0355.eemea.ericsson.se>
References: <326FB158-5C3C-48FC-96C6-252ABE05A10B@nostrum.com> <58E207308662A748A4AC1ECB4E88561403D02C92@ESESSCMS0355.eemea.ericsson.se> <537E4975-C9FB-4046-A264-C3325310959B@nostrum.com> <58E207308662A748A4AC1ECB4E885614013029BA0E@ESESSCMS0355.eemea.ericsson.se> <0957E5CB-0D6C-4992-9AF5-55C1DC2E9AFF@nostrum.com> <58E207308662A748A4AC1ECB4E88561401304EC4A5@ESESSCMS0355.eemea.ericsson.se> <0DE83F89-E769-4112-91E8-27F96AC69D45@nostrum.com> <4D2E4EDB.6000403@stpeter.im>
In-Reply-To: <4D2E4EDB.6000403@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0085_01CBB324.C69DB550"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "xcon@ietf.org" <xcon@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jan 2011 11:19:07 -0000

------=_NextPart_000_0085_01CBB324.C69DB550
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanks Peter!

Oscar 

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

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

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

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/




------=_NextPart_000_0085_01CBB324.C69DB550
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQTzCCA2Ew
ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB
IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz
OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL
ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP
VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f
j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD
0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD
KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0
N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV
HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD
UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR
eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ
k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h
bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0
BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii
T2fXd+wgBWHeMIIELDCCAxSgAwIBAgIRAN/IQMlj//Cv3z+p60spO40wDQYJKoZIhvcNAQEFBQAw
OTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Ew
MTAeFw0wODA5MTIxMjU1MzlaFw0xMTA5MTIxMjU1MzdaMGcxETAPBgNVBAoMCEVyaWNzc29uMRgw
FgYDVQQDDA9Pc2NhciBOb3ZvIERpYXoxEDAOBgNVBAUTB2Vvc2NkaWExJjAkBgkqhkiG9w0BCQEW
F29zY2FyLm5vdm9AZXJpY3Nzb24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCauTfm
sPZmDlwdb3uXRzC/Z8QWUglXfQ2JCr9rT2KgrEuMx7tTjdAuvjlrG+kFTuKJbXNckvorSOVdtQcU
h4pC+KknCfwd4TlN25VyHn53EuAWxExqUZE288rcWblt6Wb1dwVaLCH/PIN47OUKDij10H91q+DH
/zHEkVcCynbi9QIDAQABo4IBgzCCAX8wgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3aHR0cDovL2Ny
bC50cnVzdC50ZWxpYS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZxbGRhcDovL2xk
YXAudHJ1c3QudGVsaWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFsJTIwQ0EwMSxv
PUVyaWNzc29uP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2UwIgYDVR0RBBsw
GYEXb3NjYXIubm92b0Blcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEF
BQcCARYjaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFIJrsFO6
y1q6GAAPL1BVRzyXoxLaMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB
/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAFNzmqx7D9IuugAo7hLrg7+APvUGwyMr4vSPV6LZp
b3vNg6iypGqU8oSJ4UUhYizdVvbS7118Wy9us7m4EV0i08kb6J6b6XniWYK2qj4eRf8Z1LRNIFeD
Nv/02pUM7ynrQcmnwj4X4Kc9ZFi1UHoGTsV07whc3mtfhrxaT2CmK+CKsrxN9BVNaBr8ba3kEEj9
Eey8CR1ixEfW1xsrg06xRBJqipUubsLc/yDfMPfWWTyN4rMpF5naVhZRj/mfDEQnoGsQnD64i4um
Vgr7QTwi22vJVQUnMgUr7zCQK0o+eL3S1vAV+8pbUflf/+UGefvUohSeFjt+GqCR3og24JSKIzCC
BEUwggMtoAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwR
VGVsaWFTb25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYx
MB4XDTA2MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAi
BgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqI
EyHv1rLnfub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFS
fhqTu3TT39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNf
HWMcCYXRlobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJ
qzUbAz2oFRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1Ud
EwEB/wQIMAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBz
Oi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8v
bGRhcC50cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0El
MjB2MSxvPVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaA
FEXb8I+4GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/Yn
whXIv6tPjhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8H
utzYFSzz6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJB
WZ67OzIKXrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1
Xq3kMXuiNuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXY
z+OYCMZ9lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEF
BQAwOjEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIw
NDggVjMwHhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNv
bmVyYSBHcm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lIC
KF5DuVdWPMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHp
N0pe1X7/jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1Qp
QhF46H1ibp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liD
BjghXYpw/+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMB
AAGjggFiMIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvw
j7gaYqGoIxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG
9w0FBgEwMDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7
BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5j
b20wcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMv
a2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5D
UkwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgv
hOUEkUm25PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3Zwh
MyDCfkDJSgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouM
vM6bKuTPBH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/
OLHntP+npjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHde
VxPdOI5GtDYPMYICfjCCAnoCAQEwTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJp
Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEA38hAyWP/8K/fP6nrSyk7jTAJBgUrDgMCGgUAoIIB
hjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMTMxMTIxMjRa
MCMGCSqGSIb3DQEJBDEWBBSDfNWnxvD/JhiNGuNZlzoLAe8ruzBdBgkrBgEEAYI3EAQxUDBOMDkx
ETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEC
EQDfyEDJY//wr98/qetLKTuNMF8GCyqGSIb3DQEJEAILMVCgTjA5MREwDwYDVQQKDAhFcmljc3Nv
bjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEA38hAyWP/8K/fP6nrSyk7
jTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTANBgkqhkiG
9w0BAQEFAASBgCA7VurIuFQqLuf5/nLJBfa95uiw/OnQzM8fu6xWY8Vieq10QU73KxRFZQx12Hnr
d6IGU/OpsE+OvUfNzBPvuKcl7LDEgRXmHRZxqYKzFS1VJvShXqzChlDk+jo5IbV3BKjQ0UcZLUuK
P46EdUYRDBE/5I3UD+zG4EAIXYZzPsb1AAAAAAAA

------=_NextPart_000_0085_01CBB324.C69DB550--

From rjsparks@nostrum.com  Thu Jan 13 12:42:20 2011
Return-Path: <rjsparks@nostrum.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F773A6A9F for <xcon@core3.amsl.com>; Thu, 13 Jan 2011 12:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzJ5IsOjIBCT for <xcon@core3.amsl.com>; Thu, 13 Jan 2011 12:42:18 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id EB3723A6A8E for <xcon@ietf.org>; Thu, 13 Jan 2011 12:42:15 -0800 (PST)
Received: from [192.168.2.105] (pool-173-74-105-210.dllstx.fios.verizon.net [173.74.105.210]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0DKiZFC006558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Jan 2011 14:44:35 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <58E207308662A748A4AC1ECB4E885614052C5D2655@ESESSCMS0355.eemea.ericsson.se>
Date: Thu, 13 Jan 2011 14:44:35 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <C7D69DB9-BF79-47DF-BCC1-D7512AAA7405@nostrum.com>
References: <326FB158-5C3C-48FC-96C6-252ABE05A10B@nostrum.com> <58E207308662A748A4AC1ECB4E88561403D02C92@ESESSCMS0355.eemea.ericsson.se> <537E4975-C9FB-4046-A264-C3325310959B@nostrum.com> <58E207308662A748A4AC1ECB4E885614013029BA0E@ESESSCMS0355.eemea.ericsson.se> <0957E5CB-0D6C-4992-9AF5-55C1DC2E9AFF@nostrum.com> <58E207308662A748A4AC1ECB4E88561401304EC4A5@ESESSCMS0355.eemea.ericsson.se> <0DE83F89-E769-4112-91E8-27F96AC69D45@nostrum.com> <58E207308662A748A4AC1ECB4E885614052C5D2655@ESESSCMS0355.eemea.ericsson.se>
To: Oscar Novo <oscar.novo@ericsson.com>
X-Mailer: Apple Mail (2.1082)
Received-SPF: pass (nostrum.com: 173.74.105.210 is authenticated by a trusted mechanism)
Cc: "xcon@ietf.org" <xcon@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jan 2011 20:42:20 -0000

One comment inline

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

> Hi Robert,
>=20
> 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.
>=20
> 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:
>=20
> The data model document is a normative document and it constitutes a =
superset of the data format defined in 4575.=20
>=20
> 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.=20
>=20
> 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.=20
>=20
> I agree to include the following text in section 4.2.10:
>=20
>  The schema in Section 5 allows <conference-password> to appear =
anywhere uris-type is expanded.=20
>  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>.
>=20
> Regarding the new text in 4.6.2 <user-admission policy> section. Would =
the following text fullfil your requirements?:
>=20
>   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:
>=20
>   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.
>=20
>   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, =20
>   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.

>=20
> Concerning your last question, as you suggested, I will remove the =
comments from all the extensibility elements.
>=20
> Cheers,
>=20
> Oscar
>=20
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]=20
> Sent: 12. tammikuuta 2011 22:33
> To: Oscar Novo
> Cc: xcon@ietf.org; Gonzalo Camarillo
> Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
>=20
> Hi Oscar -
>=20
> 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.
>=20
> RjS
>=20
> On Jan 5, 2011, at 6:04 AM, Oscar Novo wrote:
>=20
>> Hello Robert,
>>=20
>> 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.
>>=20
>>=20
>>> [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>?=20
>>=20
>> [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>.
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
> 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:
>=20
>  The schema in Section 5 allows <conference-password> to appear =
anywhere uris-type is expanded.=20
>  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>.
>=20
> I'll ask the xml directorate to review how we're restating 4575's =
schema. (Has such a review already been performed?).=20
> One question I have is whether this is a normative update to 4575 as =
written.
>=20
> 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?
>=20
>>=20
>>=20
>> I could add the following text to 4.6.5.2.:=20
>>=20
>>  "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."
>>=20
>>=20
>>> =
/------------------------Question------------------------------------
>>> -
>>>>=20
>>>>=20
>>>>=20
>>>> * 4.6.3 and 4.6.4 : if the same user appears in an=20
>>>> <allowed-users-list> and in a <deny-users-list>, which takes=20
>>>> precedence? This should be made clear here, and the issue raised in=20=

>>>> the security considerations section.
>>>>=20
>>>>=20
>>>> [ON1] As we agreed in the WG, the semantic of those elements will =
be defined in further documents.=20
>>=20
>>> [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=3D"allowed users">).
>>=20
>>> 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.
>>=20
>>> I'll start a separate thread on this.
>>=20
>> [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.=20
>> 	- 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.=20
>>=20
>> 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.
>>=20
>> I can understand the use of the <deny-users-list> is unclear in the =
document at this point.=20
>> I'm planning to add the following text in the 4.6.2 <user-admission =
policy>:
>>=20
>> ""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."
>>=20
>> Do the text above clarify your question?
>=20
> The additional text would help, but it's not sufficient yet.
> Given what you say here, I'm looking for something that says:
>=20
> 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.
>=20
> And I think it needs to say those things using 2119 words.
>=20
>=20
>>=20
>>=20
>>=20
>>> =
/------------------------Question------------------------------------
>>> -
>>>>=20
>>>>=20
>>>> * In the Schama in section 5, there are several comment blocks=20
>>>> instructing someone to redefine something as <empty/> or=20
>>>> <notAllowed> (no trailing slash?).  Is this an established=20
>>>> convention documented somewhere? If so, can you provide a pointer?=20=

>>>> If not, please add text explaining who the instructions are =
intended=20
>>>> for and when they should be invoked.
>>>>=20
>>>> [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.
>>>=20
>>> [RObert] Then,  please add text
>>> explaining who the instructions are intended for and when they =
should=20
>>> be invoked.
>>>=20
>>> [ON1] Is not the current text self-explanatory? Which instructions =
would you suggest?=20
>>=20
>>> [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.
>>=20
>> [O] Right, what about adding the following text in every =
extensibility elements?
>>=20
>> "If extensions (check section 6) beyond this specification are not =
used, re-define anyAttribute as <empty/> and remove the definition =
below"
>>=20
>> Would it be clear adding the text above?
>=20
> 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.=20
>=20
> I think you should remove the comments from the document altogether.
>=20
>=20
> RjS
>=20
>>=20
>> Oscar
>=20


From oscar.novo@ericsson.com  Thu Jan 13 23:12:15 2011
Return-Path: <oscar.novo@ericsson.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C20543A6C52 for <xcon@core3.amsl.com>; Thu, 13 Jan 2011 23:12:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD98BmSCmjVZ for <xcon@core3.amsl.com>; Thu, 13 Jan 2011 23:12:13 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 26A813A6AAE for <xcon@ietf.org>; Thu, 13 Jan 2011 23:12:12 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-49-4d2ff7db2340
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 13.12.23694.BD7FF2D4; Fri, 14 Jan 2011 08:14:36 +0100 (CET)
Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.2.69]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 14 Jan 2011 08:14:35 +0100
From: Oscar Novo <oscar.novo@ericsson.com>
To: Robert Sparks <rjsparks@nostrum.com>
Date: Fri, 14 Jan 2011 08:14:34 +0100
Thread-Topic: [XCON] AD review: draft-ietf-xcon-common-data-model-19
Thread-Index: AcuzYrJVvCBPJWFzRZ+NNBPJ63YThwAVkwvA
Message-ID: <58E207308662A748A4AC1ECB4E885614052C5D29E5@ESESSCMS0355.eemea.ericsson.se>
References: <326FB158-5C3C-48FC-96C6-252ABE05A10B@nostrum.com> <58E207308662A748A4AC1ECB4E88561403D02C92@ESESSCMS0355.eemea.ericsson.se> <537E4975-C9FB-4046-A264-C3325310959B@nostrum.com> <58E207308662A748A4AC1ECB4E885614013029BA0E@ESESSCMS0355.eemea.ericsson.se> <0957E5CB-0D6C-4992-9AF5-55C1DC2E9AFF@nostrum.com> <58E207308662A748A4AC1ECB4E88561401304EC4A5@ESESSCMS0355.eemea.ericsson.se> <0DE83F89-E769-4112-91E8-27F96AC69D45@nostrum.com> <58E207308662A748A4AC1ECB4E885614052C5D2655@ESESSCMS0355.eemea.ericsson.se> <C7D69DB9-BF79-47DF-BCC1-D7512AAA7405@nostrum.com>
In-Reply-To: <C7D69DB9-BF79-47DF-BCC1-D7512AAA7405@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "xcon@ietf.org" <xcon@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jan 2011 07:12:15 -0000

Hi Robert,

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

Right, I didnt think about that. Actually, allowing both lists may not be g=
ood idea. Most likely future extensions will create their own elements or w=
ill 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:rjsparks@nostrum.com]
Sent: 13. tammikuuta 2011 22:45
To: Oscar Novo
Cc: xcon@ietf.org; 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:

> 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 thin=
k 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 a=
bout 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 supe=
rset of the data format defined in 4575.
>
> The XML in the document has been reviewed many times. Jari and myself hav=
e validated the XML schema against 4575 too. However, I think it's a good i=
dea Peter Saint-Andre reviewed again the XML.
>
> I think changing the namespace name of the document will mess up the thin=
gs 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 standardizati=
on, <conference-password>  MUST NOT appear in elements of type uris-type ot=
her than <conf-uris>.
>
> Regarding the new text in 4.6.2 <user-admission policy> section. Would th=
e 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 conferenc=
e, using a mechanism of the conference's choosing.  Since a
>   variety of signaling protocols are possible, a variety of authenticatio=
n mechanism - determined by every individual conference
>   servers - may need to be mapped from the different protocols. The speci=
fic 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 partic=
ipant 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 us=
er is placed on a pending list as indicated earlier. An 'closedAuthenticate=
d'        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 con=
ferencing participant to be sufficiently authenticated. Typically this impl=
ies       that anyone capable of authenticating with the conferencing syste=
m may join the conference. The 'openAuthenticated' policy permits the  spec=
ification of "banned" conferencing participants. Such banned users are prev=
ented 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 incl=
ude 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 i=
s the least restrictive policy. An 'anonymous' policy MUST NOT include eith=
er        an <allowed-users-list> or a <deny-users-list>. If any of these l=
ists 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 t=
hese
>   lists MUST either disallow both appearing at the same time or provide c=
lear guidance on how to process the lists when they occur concurrently,
>   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 sur=
e the group considers this consequence explicitly. It is not immediately ob=
vious to me what we might do differently.

>
> Concerning your last question, as you suggested, I will remove the commen=
ts from all the extensibility elements.
>
> Cheers,
>
> Oscar
>
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> Sent: 12. tammikuuta 2011 22:33
> To: Oscar Novo
> Cc: xcon@ietf.org; 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 k=
now 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 ou=
t 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, lea=
ving 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 R=
FC4575. In this case, the data model doesn't extend the <associated-aors> c=
hild element with the <conference-password>.
>
> I was initially quite puzzled by this response. I went back and reread th=
is document (and 4575s) definitions carefully, and I think I might see wher=
e 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 advanta=
ge of the extension points that were already in that grammar by adding elem=
ents using another namespace.
>
> Using the grammar defined in this document, conference-password can be pr=
oduced within associated-aor (and service-uris, host-info, users, and any o=
ther 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 standardizati=
on, <conference-password>  MUST NOT appear in elements of type uris-type ot=
her 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 writ=
ten.
>
> Also, while talking through this with others, I had several people commen=
t that "xcon-conference-info" namespace and the "conference-info" namespace=
s are so visually similar that it's easy to misunderstand what this documen=
t is trying to do. How much implementation of xcon-conference-info exists n=
ow? Would it be feasible to change it to something more distinct from confe=
rence-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 w=
ith 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 d=
efined in further documents.
>>
>>> [Robert]I could possibly accept that if the group had defined a model t=
hat contained a <list> and handed semantics off to some attribute of the li=
st >(such as ><list name=3D"allowed users">).
>>
>>> It doesn't. It defines lists and telegraphs semantics with the name. Wi=
th what you've specified so far, you are encouraging a low level of >intero=
perability.
>>
>>> 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 conferen=
ce.
>>      - 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, ba=
nning a user can be accomplished by removing the user from the <allowed-use=
rs-list>. In the third case, a <deny-users-list> is needed to support the c=
oncept.
>>
>> I can understand the use of the <deny-users-list> is unclear in the docu=
ment at this point.
>> I'm planning to add the following text in the 4.6.2 <user-admission poli=
cy>:
>>
>> ""openAuthenticated": An 'openAuthenticated' policy requires each confer=
encing participant to be sufficiently authenticated. Typically this implies=
 that anyone capable of authenticating with the conferencing system may joi=
n the conference.
>> The 'openAuthenticated' policy permits the specification of "banned" con=
ferencing participants. Such banned users are prevented from re-joining the=
 conference until they have been un-banned. An 'openAuthenticated' policy r=
equires 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 allo=
wed-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-user=
s-list, but must not include an allowed-users-list (you must ignore any den=
y-users-list that appears).
> If you are using a closedAuthenticated policy, you must include an allowe=
d-users-list, and must not include a deny-users-list (you must ignore any d=
eny-users-list that appears).
> In all other cases, the appearance of an allowed-users-list and deny-user=
s-list has no meaning defined by this document. Future specifications descr=
ibing the use of these lists must either disallow both appearing at the sam=
e time or provide clear guidance on how to process the lists when they occu=
r 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 i=
mplementor 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 woul=
d you suggest?
>>
>>> [Robert] No, it's not self-explanatory - if it were, we wouldn't be hav=
ing this conversation.
>>> I suggest pulling it into an "Implementer note", introducing the note w=
ith a sentence or two explaining that this is something you can do if you k=
now >>you are not going to use any extensions.
>>
>> [O] Right, what about adding the following text in every extensibility e=
lements?
>>
>> "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 so=
mething we should recommend as part of standardizing this model.
> Basically, you're saying that an implementation that believes it isn't go=
ing to exercise an extension point can stub those extension points out.
> In practice, this will result in incompatible versions of the schema bein=
g fielded, and in the worst of cases, when the implementer was _wrong_ abou=
t this implementation (or the things around it) wanting to use the extensio=
n points, results in a brittle system. We certainly can't prevent an implem=
enter from making this simplification if they choose to do so, but it's a h=
azardous 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
>


From mary.ietf.barnes@gmail.com  Wed Jan 19 15:26:36 2011
Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EA528C0CE for <xcon@core3.amsl.com>; Wed, 19 Jan 2011 15:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.288
X-Spam-Level: 
X-Spam-Status: No, score=-103.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQIpZy1ygJdr for <xcon@core3.amsl.com>; Wed, 19 Jan 2011 15:26:30 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 84FBA3A7062 for <xcon@ietf.org>; Wed, 19 Jan 2011 15:26:29 -0800 (PST)
Received: by iwn40 with SMTP id 40so1413470iwn.31 for <xcon@ietf.org>; Wed, 19 Jan 2011 15:29:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RvoPmN99KEXHi0RijwIfpanxhX1jWkn1GE7RIZrUsHQ=; b=iexiEbyfdKTwxx59QkcLycy8Xz7e382X9w+ICBZjQhOeeYSmNh8v35/juW2tt5MiF2 rLvCbAyjI/ohj2FUkUjQ/nkmhNOmoHk2rEIf+UEg4QAIRV7D8HpVxFyqRVI72NsHb+ee T9DF4XrzkB7vaWcm9x83FXUHtoL87MNsye4Mw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AOzwRjJPk1LRV/ja8Zl4oxPsfwA461nrqIHc0nNbUxq1JlDZxMINOF+Z///vZtRNd2 5zobJSin5d8d3FG+LVf5W1TxCXkPHnywerF2Eed9JPsTnhkJqW9hvsrU0/IbC7L2/a6I MRBKhO7x/Z06/3WQgGQv+v+6GPWAbf40QdGl0=
MIME-Version: 1.0
Received: by 10.42.167.9 with SMTP id q9mr1687339icy.266.1295479750629; Wed, 19 Jan 2011 15:29:10 -0800 (PST)
Received: by 10.42.202.12 with HTTP; Wed, 19 Jan 2011 15:29:10 -0800 (PST)
In-Reply-To: <4D087FEC.5060301@unina.it>
References: <DE53D7D6-7FC6-445F-8500-FDE234681FA3@nostrum.com> <AANLkTinXKV-eCmpuDWUfm0ZGX6c4+YNxoF95G84gUSzc@mail.gmail.com> <CF9B2EC3-015C-42A8-A031-FE24EDB6583A@nostrum.com> <AANLkTi=kVZaD8jLPKKR-LVATkDgyqFEy-YS2=+kEbkAV@mail.gmail.com> <4D00EEE1.7030703@unina.it> <AANLkTi=wQYn_KV2eqHm6jcR-_Jq5KuQKEdAjk4jS=Pg=@mail.gmail.com> <4D069BB4.9090904@unina.it> <AANLkTik0Ff3EqqwsapSKCDNkeCYc1E7s-kYuGO5ky9b1@mail.gmail.com> <4D087FEC.5060301@unina.it>
Date: Wed, 19 Jan 2011 17:29:10 -0600
Message-ID: <AANLkTin+Ah5zT83=i2U0P485DyB_-OSbspkLzcp1dmpP@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Simon Pietro Romano <spromano@unina.it>
Content-Type: multipart/alternative; boundary=90e6ba6e8c34599899049a3b6255
Cc: xcon@ietf.org
Subject: Re: [XCON] AD review: draft-ietf-xcon-ccmp-10
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jan 2011 23:26:36 -0000

--90e6ba6e8c34599899049a3b6255
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Simon,

I apologize for the long delay.  I do finally get what you are saying and
see why a single dummy value won't work.  So, I would suggest we add text
something like the following.  Please let me know if that looks okay and
then I generate a new version.  Keith also had a few comments that require
changes:
http://www.ietf.org/mail-archive/web/xcon/current/msg02476.html

Thanks,
Mary.

OLD:
   To solve this kind of issues, the CCMP will fill all mandatory data
   model fields, for which no value is available at the client at the
   time the request is constructed, with fake values in the form of
   wildcard strings (e.g.  AUTO_GENERATE_X, with X being an incremental
   index initialized to a value of 1).  Upon reception of the mentioned
   kinds of requests, the server will (i) generate the proper
   identifier(s); (ii) produce a response in which the received fake
   identifier(s) carried in the request has (have) been replaced by the
   newly created one(s).

NEW:
   To resolve these issues, the CCMP MUST fill all mandatory data
   model fields, for which no value is available at the client at the
   time the request is constructed, with fake values in the form of
   the wildcard strings "AUTO_GENERATE_X".  The value of X MUST
   be initialized with a value of "1" and incremented for each mandatory
field in the
   for which the client does not have a value.  Upon receipt of requests
containing
   fields with wildcard strings, the server MUST:  (i) generate the proper
   identifier(s); (ii) produce a response in which the received fake
   identifier(s) carried in the request has (have) been replaced by the
   newly created one(s).


On Wed, Dec 15, 2010 at 2:44 AM, Simon Pietro Romano <spromano@unina.it>wro=
te:

> Hi Mary,
>
> as usual, inline ([spromano3] :-) ).
>
>
>
>> [MB3] So, I see the point that you need to have something in the attribu=
te
>> and that there needs to be a way to ensure it doesn't conflict with a va=
lue
>> that might collide with a valid value.  But, I cannot see the need for t=
he
>> unique increment - i.e, why won't a fixed "dummy" value work (e.g.,
>> dummy-user@domain, where the domain is the domain of the conf server)?
>>  The requesting user knows that they are adding a specific user to the
>> conference and other information associated with that user is unique.
>>  Unless the suggestion is that using the increment makes it easier for t=
he
>> client. But, I can't see that the information is useful to the conferenc=
ing
>> server since it will just see an identifier with a specific string and t=
hen
>> it knows that it needs to create one for that user. Unless you are
>> suggesting that the conferencing server is then ensuring they are unique=
 for
>> a specific user and returns an error if not?
>>
>
> [spromano3]
> Actually, the idea of enumerating AUTO_GENERATE_X dummy identifiers deriv=
es
> from the presence of potential "cross references" in some CCMP messages.
> Let's take once again the sidebars example, which is by no doubt the
> trickiest one. If I want to add two different streams (stream_1 and
> stream_2) in a sidebar, and in the same message I want to indicate that
> stream_2 has to be 'recvonly', I have to be able to tell the first
> identifier (associated with stream_1) apart from the second (associated w=
ith
> stream_2). An example like this can be found in the XCON examples documen=
t
> on page 73 (sidebarsByRefRequest/update). If I weren't able to make such
> distinction inside the client's message, the only remaining option would =
be
> to send to the server three distinct messages (two of which would be
> 'updates'): (i) 'update', to create the sidebar with stream_1 and stream_=
2
> (such message would just contain, for both streams, a generic AUTO_GENERA=
TE
> wildcard); (ii) 'retrieve', to get the (actual) identifiers created by th=
e
> server; (iii) 'update' (with the real identifier retrieved for stream_2),=
 to
> specify that stream_2 has to be 'recvonly'.
> All this just to say that both options (use AUTO_GENERATE_X or just
> AUTO_GENERATE for fake identifiers) are viable, but in our view the forme=
r
> allows for more flexibility in cases like the one described above. What i=
s
> your feeling?
> [/spromano3]
>
>
>  Also, the definition of the XCON-USERID needs to be updated in either
>> case:
>>     "The "confUserID" parameter is REQUIRED in
>>      the CCMP request and response messages with the exception of the
>>      case of a user who has no XCON-USERID and who wants to enter, via
>>      CCMP, a conference whose identifier is known.  In such case, a
>>      side-effect of the request is that the user is provided with an
>>      appropriate XCON-USERID.
>>
>> So, I'm assuming the AUTO_GENERATE_X is used in the case described above=
?
>>
>> Either way, whether there's an increment or not, we do need to add alot
>> more text around this mechanism.
>> [/MB3]
>>
>
> [spromano3]
> Indeed, I'm not sure we need to modify this, since the CCMP schema does n=
ot
> *mandate* the presence of the confUserID parameter inside CCMP messages. =
Do
> you agree with this?
> [/spromano3]
>
>
> Cheers,
> Simon
>
> --
>                            _\\|//_
>                            ( O-O )
>   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>                    Simon Pietro Romano
>              Universita' di Napoli Federico II
>                 Computer Science Department
>        Phone: +39 081 7683823 -- Fax: +39 081 7684219
>                e-mail: spromano@unina.it
>          http://www.comics.unina.it/simonpietro.romano
>
>    <<Molti mi dicono che lo scoraggiamento =C4=8D l'alibi degli
>   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>                         oooO
>   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>                          \ (    (   )
>                           \_)    ) /
>                                 (_/
>
>
>

--90e6ba6e8c34599899049a3b6255
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Simon,<div><br></div><div>I apologize for the long delay. =C2=A0I do fin=
ally get what you are saying and see why a single dummy value won&#39;t wor=
k. =C2=A0So, I would suggest we add text something like the following. =C2=
=A0Please let me know if that looks okay and then I generate a new version.=
 =C2=A0Keith also had a few comments that require changes:</div>
<div><a href=3D"http://www.ietf.org/mail-archive/web/xcon/current/msg02476.=
html">http://www.ietf.org/mail-archive/web/xcon/current/msg02476.html</a></=
div><div><br></div><div>Thanks,</div><div>Mary.=C2=A0</div><div><div><br></=
div>
<div>OLD:=C2=A0</div><div>=C2=A0=C2=A0 To solve this kind of issues, the CC=
MP will fill all mandatory data</div><div>=C2=A0=C2=A0 model fields, for wh=
ich no value is available at the client at the</div><div>=C2=A0=C2=A0 time =
the request is constructed, with fake values in the form of</div>
<div>=C2=A0=C2=A0 wildcard strings (e.g. =C2=A0AUTO_GENERATE_X, with X bein=
g an incremental</div><div>=C2=A0=C2=A0 index initialized to a value of 1).=
 =C2=A0Upon reception of the mentioned</div><div>=C2=A0=C2=A0 kinds of requ=
ests, the server will=C2=A0(i) generate the proper</div>
<div>=C2=A0=C2=A0 identifier(s); (ii) produce a response in which the recei=
ved fake</div><div>=C2=A0=C2=A0 identifier(s) carried in the request has (h=
ave) been replaced by the</div><div>=C2=A0=C2=A0 newly created one(s).=C2=
=A0</div></div><div><br></div><div>
NEW:</div><div>=C2=A0=C2=A0=C2=A0To resolve these issues, the CCMP MUST fil=
l all mandatory data</div><div>=C2=A0=C2=A0 model fields, for which no valu=
e is available at the client at the</div><div>=C2=A0=C2=A0 time the request=
 is constructed, with fake values in the form of</div>
<div>=C2=A0=C2=A0 the wildcard strings &quot;AUTO_GENERATE_X&quot;. =C2=A0T=
he value of X MUST</div><div>=C2=A0=C2=A0 be initialized with a value of &q=
uot;1&quot; and incremented for each mandatory field in the=C2=A0</div><div=
>=C2=A0=C2=A0 for=C2=A0which the client does not have a value. =C2=A0Upon r=
eceipt of requests containing</div>
<div>=C2=A0=C2=A0 fields with wildcard strings, the server MUST: =C2=A0(i) =
generate the proper</div><div>=C2=A0=C2=A0 identifier(s); (ii) produce a re=
sponse in which the received fake</div><div>=C2=A0=C2=A0 identifier(s) carr=
ied in the request has (have) been replaced by the</div>
<div>=C2=A0=C2=A0 newly created one(s).=C2=A0</div><div>=C2=A0=C2=A0</div><=
div><br><div class=3D"gmail_quote">On Wed, Dec 15, 2010 at 2:44 AM, Simon P=
ietro Romano <span dir=3D"ltr">&lt;<a href=3D"mailto:spromano@unina.it">spr=
omano@unina.it</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Hi Mary,<br>
<br>
as usual, inline ([spromano3] :-) ).<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
[MB3] So, I see the point that you need to have something in the attribute =
and that there needs to be a way to ensure it doesn&#39;t conflict with a v=
alue that might collide with a valid value. =C2=A0But, I cannot see the nee=
d for the unique increment - i.e, why won&#39;t a fixed &quot;dummy&quot; v=
alue work (e.g., dummy-user@domain, where the domain is the domain of the c=
onf server)? =C2=A0The requesting user knows that they are adding a specifi=
c user to the conference and other information associated with that user is=
 unique. =C2=A0Unless the suggestion is that using the increment makes it e=
asier for the client. But, I can&#39;t see that the information is useful t=
o the conferencing server since it will just see an identifier with a speci=
fic string and then it knows that it needs to create one for that user. Unl=
ess you are suggesting that the conferencing server is then ensuring they a=
re unique for a specific user and returns an error if not?<br>

</blockquote>
<br></div>
[spromano3]<br>
Actually, the idea of enumerating AUTO_GENERATE_X dummy identifiers derives=
 from the presence of potential &quot;cross references&quot; in some CCMP m=
essages. Let&#39;s take once again the sidebars example, which is by no dou=
bt the trickiest one. If I want to add two different streams (stream_1 and =
stream_2) in a sidebar, and in the same message I want to indicate that str=
eam_2 has to be &#39;recvonly&#39;, I have to be able to tell the first ide=
ntifier (associated with stream_1) apart from the second (associated with s=
tream_2). An example like this can be found in the XCON examples document o=
n page 73 (sidebarsByRefRequest/update). If I weren&#39;t able to make such=
 distinction inside the client&#39;s message, the only remaining option wou=
ld be to send to the server three distinct messages (two of which would be =
&#39;updates&#39;): (i) &#39;update&#39;, to create the sidebar with stream=
_1 and stream_2 (such message would just contain, for both streams, a gener=
ic AUTO_GENERATE wildcard); (ii) &#39;retrieve&#39;, to get the (actual) id=
entifiers created by the server; (iii) &#39;update&#39; (with the real iden=
tifier retrieved for stream_2), to specify that stream_2 has to be &#39;rec=
vonly&#39;.<br>

All this just to say that both options (use AUTO_GENERATE_X or just AUTO_GE=
NERATE for fake identifiers) are viable, but in our view the former allows =
for more flexibility in cases like the one described above. What is your fe=
eling?<br>

[/spromano3]<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Also, the definition of the XCON-USERID needs to be updated in either case:=
<br>
 =C2=A0 =C2=A0 &quot;The &quot;confUserID&quot; parameter is REQUIRED in<br=
>
 =C2=A0 =C2=A0 =C2=A0the CCMP request and response messages with the except=
ion of the<br>
 =C2=A0 =C2=A0 =C2=A0case of a user who has no XCON-USERID and who wants to=
 enter, via<br>
 =C2=A0 =C2=A0 =C2=A0CCMP, a conference whose identifier is known. =C2=A0In=
 such case, a<br>
 =C2=A0 =C2=A0 =C2=A0side-effect of the request is that the user is provide=
d with an<br>
 =C2=A0 =C2=A0 =C2=A0appropriate XCON-USERID.<br>
<br>
So, I&#39;m assuming the AUTO_GENERATE_X is used in the case described abov=
e?<br>
<br>
Either way, whether there&#39;s an increment or not, we do need to add alot=
 more text around this mechanism.<br>
[/MB3]<br>
</blockquote>
<br></div>
[spromano3]<br>
Indeed, I&#39;m not sure we need to modify this, since the CCMP schema does=
 not *mandate* the presence of the confUserID parameter inside CCMP message=
s. Do you agree with this?<br>
[/spromano3]<div><div></div><div class=3D"h5"><br>
<br>
Cheers,<br>
Simon<br>
<br>
-- <br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0_\\|//_<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0( O-O )<br>
 =C2=A0 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Simon=
 Pietro Romano<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Universita&#39; di Napoli =
Federico II<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Computer Science D=
epartment<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0Phone: +39 081 7683823 -- Fax: +39 081 7684219<=
br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e-mail: <a href=3D"=
mailto:spromano@unina.it" target=3D"_blank">spromano@unina.it</a><br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://www.comics.unina.it/si=
monpietro.romano" target=3D"_blank">http://www.comics.unina.it/simonpietro.=
romano</a><br>
<br>
 =C2=A0 =C2=A0&lt;&lt;Molti mi dicono che lo scoraggiamento =C4=8D l&#39;al=
ibi degli<br>
 =C2=A0 idioti. Ci rifletto un istante; e mi scoraggio&gt;&gt;. Magritte.<b=
r>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 oooO<br>
 =C2=A0 ~~~~~~~~~~~~~~~~~~~~~~( =C2=A0 )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~<br=
>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\ ( =C2=A0 =C2=A0( =C2=A0 )<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 \_) =C2=A0 =C2=A0) /<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (_/<br>
<br>
<br>
</div></div></blockquote></div><br></div>

--90e6ba6e8c34599899049a3b6255--

From rjsparks@nostrum.com  Mon Jan 24 10:39:02 2011
Return-Path: <rjsparks@nostrum.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCF13A6B26 for <xcon@core3.amsl.com>; Mon, 24 Jan 2011 10:39:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.548
X-Spam-Level: 
X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NusRQ1taYnlN for <xcon@core3.amsl.com>; Mon, 24 Jan 2011 10:39:00 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 0904C3A6B24 for <xcon@ietf.org>; Mon, 24 Jan 2011 10:38:59 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0OIfp7t063513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jan 2011 12:41:51 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <58E207308662A748A4AC1ECB4E885614052C5D29E5@ESESSCMS0355.eemea.ericsson.se>
Date: Mon, 24 Jan 2011 12:41:50 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <97615872-0BBA-4BBE-8165-88A4AB81B39C@nostrum.com>
References: <326FB158-5C3C-48FC-96C6-252ABE05A10B@nostrum.com> <58E207308662A748A4AC1ECB4E88561403D02C92@ESESSCMS0355.eemea.ericsson.se> <537E4975-C9FB-4046-A264-C3325310959B@nostrum.com> <58E207308662A748A4AC1ECB4E885614013029BA0E@ESESSCMS0355.eemea.ericsson.se> <0957E5CB-0D6C-4992-9AF5-55C1DC2E9AFF@nostrum.com> <58E207308662A748A4AC1ECB4E88561401304EC4A5@ESESSCMS0355.eemea.ericsson.se> <0DE83F89-E769-4112-91E8-27F96AC69D45@nostrum.com> <58E207308662A748A4AC1ECB4E885614052C5D2655@ESESSCMS0355.eemea.ericsson.se> <C7D69DB9-BF79-47DF-BCC1-D7512AAA7405@nostrum.com> <58E207308662A748A4AC1ECB4E885614052C5D29E5@ESESSCMS0355.eemea.ericsson.se>
To: Oscar Novo <oscar.novo@ericsson.com>
X-Mailer: Apple Mail (2.1082)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: "xcon@ietf.org" <xcon@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2011 18:39:02 -0000

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:

>=20
> Hi Robert,
>=20
>> 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.
>=20
> 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.
>=20
> What about changing the last paragraph to:
>=20
>        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.
>=20
> Oscar
>=20
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> Sent: 13. tammikuuta 2011 22:45
> To: Oscar Novo
> Cc: xcon@ietf.org; Gonzalo Camarillo
> Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
>=20
> One comment inline
>=20
> On Jan 13, 2011, at 5:20 AM, Oscar Novo wrote:
>=20
>> Hi Robert,
>>=20
>> 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.
>>=20
>> 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:
>>=20
>> The data model document is a normative document and it constitutes a =
superset of the data format defined in 4575.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> I agree to include the following text in section 4.2.10:
>>=20
>> 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>.
>>=20
>> Regarding the new text in 4.6.2 <user-admission policy> section. =
Would the following text fullfil your requirements?:
>>=20
>>  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:
>>=20
>>  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.
>>=20
>>  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.
>=20
> 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.
>=20
>>=20
>> Concerning your last question, as you suggested, I will remove the =
comments from all the extensibility elements.
>>=20
>> Cheers,
>>=20
>> Oscar
>>=20
>> -----Original Message-----
>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>> Sent: 12. tammikuuta 2011 22:33
>> To: Oscar Novo
>> Cc: xcon@ietf.org; Gonzalo Camarillo
>> Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
>>=20
>> Hi Oscar -
>>=20
>> 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.
>>=20
>> RjS
>>=20
>> On Jan 5, 2011, at 6:04 AM, Oscar Novo wrote:
>>=20
>>> Hello Robert,
>>>=20
>>> 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.
>>>=20
>>>=20
>>>> [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>?
>>>=20
>>> [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>.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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).
>>=20
>> 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:
>>=20
>> 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>.
>>=20
>> 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.
>>=20
>> 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?
>>=20
>>>=20
>>>=20
>>> I could add the following text to 4.6.5.2.:
>>>=20
>>> "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."
>>>=20
>>>=20
>>>> =
/------------------------Question-----------------------------------
>>>> -
>>>> -
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> * 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.
>>>>>=20
>>>>>=20
>>>>> [ON1] As we agreed in the WG, the semantic of those elements will =
be defined in further documents.
>>>=20
>>>> [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=3D"allowed users">).
>>>=20
>>>> 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.
>>>=20
>>>> I'll start a separate thread on this.
>>>=20
>>> [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.
>>>=20
>>> 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.
>>>=20
>>> 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>:
>>>=20
>>> ""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."
>>>=20
>>> Do the text above clarify your question?
>>=20
>> The additional text would help, but it's not sufficient yet.
>> Given what you say here, I'm looking for something that says:
>>=20
>> 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.
>>=20
>> And I think it needs to say those things using 2119 words.
>>=20
>>=20
>>>=20
>>>=20
>>>=20
>>>> =
/------------------------Question-----------------------------------
>>>> -
>>>> -
>>>>>=20
>>>>>=20
>>>>> * 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.
>>>>>=20
>>>>> [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.
>>>>=20
>>>> [RObert] Then,  please add text
>>>> explaining who the instructions are intended for and when they
>>>> should be invoked.
>>>>=20
>>>> [ON1] Is not the current text self-explanatory? Which instructions =
would you suggest?
>>>=20
>>>> [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.
>>>=20
>>> [O] Right, what about adding the following text in every =
extensibility elements?
>>>=20
>>> "If extensions (check section 6) beyond this specification are not =
used, re-define anyAttribute as <empty/> and remove the definition =
below"
>>>=20
>>> Would it be clear adding the text above?
>>=20
>> 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.
>>=20
>> I think you should remove the comments from the document altogether.
>>=20
>>=20
>> RjS
>>=20
>>>=20
>>> Oscar
>>=20
>=20


From rjsparks@nostrum.com  Mon Jan 24 11:29:01 2011
Return-Path: <rjsparks@nostrum.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD46428C0D8 for <xcon@core3.amsl.com>; Mon, 24 Jan 2011 11:29:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Level: 
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td1mK6jcQiSY for <xcon@core3.amsl.com>; Mon, 24 Jan 2011 11:28:59 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6DC0628C0DE for <xcon@ietf.org>; Mon, 24 Jan 2011 11:28:58 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0OJVpx2067696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jan 2011 13:31:51 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-143--237269481
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <AANLkTin+Ah5zT83=i2U0P485DyB_-OSbspkLzcp1dmpP@mail.gmail.com>
Date: Mon, 24 Jan 2011 13:31:50 -0600
Message-Id: <9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com>
References: <DE53D7D6-7FC6-445F-8500-FDE234681FA3@nostrum.com> <AANLkTinXKV-eCmpuDWUfm0ZGX6c4+YNxoF95G84gUSzc@mail.gmail.com> <CF9B2EC3-015C-42A8-A031-FE24EDB6583A@nostrum.com> <AANLkTi=kVZaD8jLPKKR-LVATkDgyqFEy-YS2=+kEbkAV@mail.gmail.com> <4D00EEE1.7030703@unina.it> <AANLkTi=wQYn_KV2eqHm6jcR-_Jq5KuQKEdAjk4jS=Pg=@mail.gmail.com> <4D069BB4.9090904@unina.it> <AANLkTik0Ff3EqqwsapSKCDNkeCYc1E7s-kYuGO5ky9b1@mail.gmail.com> <4D087FEC.5060301@unina.it> <AANLkTin+Ah5zT83=i2U0P485DyB_-OSbspkLzcp1dmpP@mail.gmail.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
X-Mailer: Apple Mail (2.1082)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: xcon@ietf.org
Subject: Re: [XCON] AD review: draft-ietf-xcon-ccmp-10
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2011 19:29:02 -0000

--Apple-Mail-143--237269481
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

This is heading in the right direction, but I think the server's =
behavior will still be underspecified
(if I've missed where these are already covered, please add pointers to =
to where they're covered to the text you propose below).

1) It needs to be clear whether or not the server looks for these using =
a case-sensitive comparison
2) It needs to be explicit that
     - the server will substitute the same string for every instance of =
AUTO_GENERATE_1 in a given document (similar for _2, _3, etc.)
     - the server will substitute different strings for AUTO_GENERATE_1 =
and AUTO_GENERATE_n for any n other than 1.
    -  there's no requirement for the server to substitute the same =
string for AUTO_GENERATE_1 in two different documents, even from the =
same client.
3) It should be explicit whether any security properties are expected =
from the values that are substituted. For instance, is it important that =
other clients=20
    not be able to guess what the server will substitute?
4) It should be explicit that the server generates a string that makes =
sense for the context that the variable appears in (see question below), =
and describe
    what error the server returns if it can't make a substitution =
resulting in a legal document.
5) Please take care to avoid implementer confusion about quotes around =
the string being substituted.


Please also make sure any use of this mechanism in the document (or =
-examples) lines up with the conclusion. Right now, there are some =
instances
of AUTO_GENERATE without a _n for any n in the document.

You may also want to consider why the incrementing integer is important. =
The mechanism would work just as well with a document that only =
contained
AUTO_GENERATE_1 and AUTO_GENERATE_512. (The server isn't asked to look =
for gaps, and I'm not seeing why it should. Should a request be
rejected because it has a gap in its AUTO_GENERATE sequence?).

You might also want to say in the document why the group didn't just =
allow strings like "AUTO_GENERATE_ALICE" and "AUTO_GENERATE_FOO".
I think the answer is that we wanted to keep the parsing simple for the =
server while facilitating substitution into arbitrary contexts (with =
examples being
replacing only the username part of an xcon-userid, and with the =
tradeoff being that you can't substitute into a context where the next =
character would be
a digit).

So coming back to point 4, assume the following stanza beginnings occur =
in different documents. What strings would you expect the server to =
substitute
in place of the placeholder in each case, and what would the server do =
next? What part of the spec actually tells an implementation to do what =
you expected?

A)             <userInfo =
entity=3D"xcon-userid:AUTO_GENERATE_1@example.com">
B)            <userInfo entity=3D"xcon-userid:AUTO_GENERATE_1">
C)            <userInfo entity=3D"AUTO_GENERATE_1">
D)            <userinfo =
entity=3D"xcon-userid:AUTO_GENERATE_1@AUTO_GENERATE_2">
E)            <userinfo AUTO_GENERATE_1>
F)            <userinfo =
entity=3D"xcon-userid:fooAUTO_GENERATE_1bar@example.com">

What text constrains where AUTO_GENERATE_n can appear? I suspect we =
don't want the server looking to replace it in an xmlns: declaration...

RjS


On Jan 19, 2011, at 5:29 PM, Mary Barnes wrote:


> Hi Simon,
>=20
> I apologize for the long delay.  I do finally get what you are saying =
and see why a single dummy value won't work.  So, I would suggest we add =
text something like the following.  Please let me know if that looks =
okay and then I generate a new version.  Keith also had a few comments =
that require changes:
> http://www.ietf.org/mail-archive/web/xcon/current/msg02476.html
>=20
> Thanks,
> Mary.=20
>=20
> OLD:=20
>    To solve this kind of issues, the CCMP will fill all mandatory data
>    model fields, for which no value is available at the client at the
>    time the request is constructed, with fake values in the form of
>    wildcard strings (e.g.  AUTO_GENERATE_X, with X being an =
incremental
>    index initialized to a value of 1).  Upon reception of the =
mentioned
>    kinds of requests, the server will (i) generate the proper
>    identifier(s); (ii) produce a response in which the received fake
>    identifier(s) carried in the request has (have) been replaced by =
the
>    newly created one(s).=20
>=20
> NEW:
>    To resolve these issues, the CCMP MUST fill all mandatory data
>    model fields, for which no value is available at the client at the
>    time the request is constructed, with fake values in the form of
>    the wildcard strings "AUTO_GENERATE_X".  The value of X MUST
>    be initialized with a value of "1" and incremented for each =
mandatory field in the=20
>    for which the client does not have a value.  Upon receipt of =
requests containing
>    fields with wildcard strings, the server MUST:  (i) generate the =
proper
>    identifier(s); (ii) produce a response in which the received fake
>    identifier(s) carried in the request has (have) been replaced by =
the
>    newly created one(s).=20
>  =20
>=20
> On Wed, Dec 15, 2010 at 2:44 AM, Simon Pietro Romano =
<spromano@unina.it> wrote:
> Hi Mary,
>=20
> as usual, inline ([spromano3] :-) ).
>=20
>=20
>=20
> [MB3] So, I see the point that you need to have something in the =
attribute and that there needs to be a way to ensure it doesn't conflict =
with a value that might collide with a valid value.  But, I cannot see =
the need for the unique increment - i.e, why won't a fixed "dummy" value =
work (e.g., dummy-user@domain, where the domain is the domain of the =
conf server)?  The requesting user knows that they are adding a specific =
user to the conference and other information associated with that user =
is unique.  Unless the suggestion is that using the increment makes it =
easier for the client. But, I can't see that the information is useful =
to the conferencing server since it will just see an identifier with a =
specific string and then it knows that it needs to create one for that =
user. Unless you are suggesting that the conferencing server is then =
ensuring they are unique for a specific user and returns an error if =
not?
>=20
> [spromano3]
> Actually, the idea of enumerating AUTO_GENERATE_X dummy identifiers =
derives from the presence of potential "cross references" in some CCMP =
messages. Let's take once again the sidebars example, which is by no =
doubt the trickiest one. If I want to add two different streams =
(stream_1 and stream_2) in a sidebar, and in the same message I want to =
indicate that stream_2 has to be 'recvonly', I have to be able to tell =
the first identifier (associated with stream_1) apart from the second =
(associated with stream_2). An example like this can be found in the =
XCON examples document on page 73 (sidebarsByRefRequest/update). If I =
weren't able to make such distinction inside the client's message, the =
only remaining option would be to send to the server three distinct =
messages (two of which would be 'updates'): (i) 'update', to create the =
sidebar with stream_1 and stream_2 (such message would just contain, for =
both streams, a generic AUTO_GENERATE wildcard); (ii) 'retrieve', to get =
the (actual) identifiers created by the server; (iii) 'update' (with the =
real identifier retrieved for stream_2), to specify that stream_2 has to =
be 'recvonly'.
> All this just to say that both options (use AUTO_GENERATE_X or just =
AUTO_GENERATE for fake identifiers) are viable, but in our view the =
former allows for more flexibility in cases like the one described =
above. What is your feeling?
> [/spromano3]
>=20
>=20
> Also, the definition of the XCON-USERID needs to be updated in either =
case:
>     "The "confUserID" parameter is REQUIRED in
>      the CCMP request and response messages with the exception of the
>      case of a user who has no XCON-USERID and who wants to enter, via
>      CCMP, a conference whose identifier is known.  In such case, a
>      side-effect of the request is that the user is provided with an
>      appropriate XCON-USERID.
>=20
> So, I'm assuming the AUTO_GENERATE_X is used in the case described =
above?
>=20
> Either way, whether there's an increment or not, we do need to add =
alot more text around this mechanism.
> [/MB3]
>=20
> [spromano3]
> Indeed, I'm not sure we need to modify this, since the CCMP schema =
does not *mandate* the presence of the confUserID parameter inside CCMP =
messages. Do you agree with this?
> [/spromano3]
>=20
>=20
> Cheers,
> Simon
>=20
> --=20
>                            _\\|//_
>                            ( O-O )
>   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>                    Simon Pietro Romano
>              Universita' di Napoli Federico II
>                 Computer Science Department
>        Phone: +39 081 7683823 -- Fax: +39 081 7684219
>                e-mail: spromano@unina.it
>          http://www.comics.unina.it/simonpietro.romano
>=20
>    <<Molti mi dicono che lo scoraggiamento =C4=8D l'alibi degli
>   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>                         oooO
>   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>                          \ (    (   )
>                           \_)    ) /
>                                 (_/
>=20
>=20
>=20


--Apple-Mail-143--237269481
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This =
is heading in the right direction,&nbsp;but I think the server's =
behavior will still be underspecified<div><div>(if I've missed where =
these are already covered, please add pointers to to where they're =
covered to the text you propose below).<div><br></div><div>1) It needs =
to be clear whether or not the server looks for these using a =
case-sensitive comparison</div><div>2) It needs to be explicit =
that</div><div>&nbsp;&nbsp; &nbsp; - the server will substitute the same =
string for every instance of AUTO_GENERATE_1 in a given document =
(similar for _2, _3, etc.)</div><div>&nbsp;&nbsp; &nbsp; - the server =
will substitute different strings for AUTO_GENERATE_1 and =
AUTO_GENERATE_n for any n other than 1.</div><div>&nbsp;&nbsp; &nbsp;- =
&nbsp;there's no requirement for the server to substitute the same =
string for AUTO_GENERATE_1 in two different documents, even from the =
same client.</div><div>3) It should be explicit whether any security =
properties are expected from the values that are substituted. For =
instance, is it important that other =
clients&nbsp;</div><div>&nbsp;&nbsp; &nbsp;not be able&nbsp;to guess =
what the server will substitute?</div><div>4) It should be explicit that =
the server generates a string that makes sense for the context that the =
variable appears in (see question below), and =
describe</div><div>&nbsp;&nbsp; &nbsp;what error the server returns if =
it can't make a substitution resulting in a legal document.</div><div>5) =
Please take care to avoid implementer confusion about quotes around the =
string being substituted.</div><div><br></div><div><br></div><div>Please =
also make sure any use of this mechanism in the document (or -examples) =
lines up with the conclusion. Right now, there are some =
instances</div><div>of AUTO_GENERATE without a _n for any n in the =
document.</div><div><br></div><div>You may also want to consider why the =
incrementing integer is important. The mechanism would work just as well =
with a document that only contained</div><div>AUTO_GENERATE_1 and =
AUTO_GENERATE_512. (The server isn't asked to look for gaps, and I'm not =
seeing why it should. Should a request be</div><div>rejected because it =
has a gap in its AUTO_GENERATE sequence?).</div><div><br></div><div>You =
might also want to say in the document why the group didn't just allow =
strings like "AUTO_GENERATE_ALICE" and "AUTO_GENERATE_FOO".</div><div>I =
think the answer is that we wanted to keep the parsing simple for the =
server while facilitating substitution into arbitrary contexts (with =
examples being</div><div>replacing only the username part of an =
xcon-userid, and with the tradeoff being that you can't substitute into =
a context where the next character would be</div><div>a =
digit).</div><div><br></div><div>So coming back to point 4, assume the =
following stanza beginnings occur in different documents. What strings =
would you expect the server to substitute</div><div>in place of the =
placeholder in each case, and what would the server do next? What part =
of the spec actually tells an implementation to do what you =
expected?</div><div><br></div><div>A)&nbsp;&nbsp;&nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp;&lt;userInfo =
entity=3D"xcon-userid:AUTO_GENERATE_1@example.com"&gt;</div><div>B)&nbsp;&=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;userInfo =
entity=3D"xcon-userid:AUTO_GENERATE_1"&gt;</div><div>C) &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;&lt;userInfo =
entity=3D"AUTO_GENERATE_1"&gt;</div><div>D) &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;&lt;userinfo =
entity=3D"xcon-userid:AUTO_GENERATE_1@AUTO_GENERATE_2"&gt;</div><div>E) =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;userinfo =
AUTO_GENERATE_1&gt;</div><div>F) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;&lt;userinfo =
entity=3D"xcon-userid:fooAUTO_GENERATE_1bar@example.com"&gt;</div><div><br=
></div><div>What text constrains where AUTO_GENERATE_n can appear? I =
suspect we don't want the server looking to replace it in an xmlns: =
declaration...</div><div><br></div><div>RjS</div><div><br></div><div><br><=
/div><div><div><div><div>On Jan 19, 2011, at 5:29 PM, Mary Barnes =
wrote:</div><br class=3D"Apple-interchange-newline"><br><blockquote =
type=3D"cite">Hi Simon,<div><br></div><div>I apologize for the long =
delay. &nbsp;I do finally get what you are saying and see why a single =
dummy value won't work. &nbsp;So, I would suggest we add text something =
like the following. &nbsp;Please let me know if that looks okay and then =
I generate a new version. &nbsp;Keith also had a few comments that =
require changes:</div>
<div><a =
href=3D"http://www.ietf.org/mail-archive/web/xcon/current/msg02476.html">h=
ttp://www.ietf.org/mail-archive/web/xcon/current/msg02476.html</a></div><d=
iv><br></div><div>Thanks,</div><div>Mary.&nbsp;</div><div><div><br></div>
<div>OLD:&nbsp;</div><div>&nbsp;&nbsp; To solve this kind of issues, the =
CCMP will fill all mandatory data</div><div>&nbsp;&nbsp; model fields, =
for which no value is available at the client at =
the</div><div>&nbsp;&nbsp; time the request is constructed, with fake =
values in the form of</div>
<div>&nbsp;&nbsp; wildcard strings (e.g. &nbsp;AUTO_GENERATE_X, with X =
being an incremental</div><div>&nbsp;&nbsp; index initialized to a value =
of 1). &nbsp;Upon reception of the mentioned</div><div>&nbsp;&nbsp; =
kinds of requests, the server will&nbsp;(i) generate the proper</div>
<div>&nbsp;&nbsp; identifier(s); (ii) produce a response in which the =
received fake</div><div>&nbsp;&nbsp; identifier(s) carried in the =
request has (have) been replaced by the</div><div>&nbsp;&nbsp; newly =
created one(s).&nbsp;</div></div><div><br></div><div>
NEW:</div><div>&nbsp;&nbsp;&nbsp;To resolve these issues, the CCMP MUST =
fill all mandatory data</div><div>&nbsp;&nbsp; model fields, for which =
no value is available at the client at the</div><div>&nbsp;&nbsp; time =
the request is constructed, with fake values in the form of</div>
<div>&nbsp;&nbsp; the wildcard strings "AUTO_GENERATE_X". &nbsp;The =
value of X MUST</div><div>&nbsp;&nbsp; be initialized with a value of =
"1" and incremented for each mandatory field in =
the&nbsp;</div><div>&nbsp;&nbsp; for&nbsp;which the client does not have =
a value. &nbsp;Upon receipt of requests containing</div>
<div>&nbsp;&nbsp; fields with wildcard strings, the server MUST: =
&nbsp;(i) generate the proper</div><div>&nbsp;&nbsp; identifier(s); (ii) =
produce a response in which the received fake</div><div>&nbsp;&nbsp; =
identifier(s) carried in the request has (have) been replaced by =
the</div>
<div>&nbsp;&nbsp; newly created =
one(s).&nbsp;</div><div>&nbsp;&nbsp;</div><div><br><div =
class=3D"gmail_quote">On Wed, Dec 15, 2010 at 2:44 AM, Simon Pietro =
Romano <span dir=3D"ltr">&lt;<a =
href=3D"mailto:spromano@unina.it">spromano@unina.it</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Mary,<br>
<br>
as usual, inline ([spromano3] :-) ).<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[MB3] So, I see the point that you need to have something in the =
attribute and that there needs to be a way to ensure it doesn't conflict =
with a value that might collide with a valid value. &nbsp;But, I cannot =
see the need for the unique increment - i.e, why won't a fixed "dummy" =
value work (e.g., dummy-user@domain, where the domain is the domain of =
the conf server)? &nbsp;The requesting user knows that they are adding a =
specific user to the conference and other information associated with =
that user is unique. &nbsp;Unless the suggestion is that using the =
increment makes it easier for the client. But, I can't see that the =
information is useful to the conferencing server since it will just see =
an identifier with a specific string and then it knows that it needs to =
create one for that user. Unless you are suggesting that the =
conferencing server is then ensuring they are unique for a specific user =
and returns an error if not?<br>

</blockquote>
<br></div>
[spromano3]<br>
Actually, the idea of enumerating AUTO_GENERATE_X dummy identifiers =
derives from the presence of potential "cross references" in some CCMP =
messages. Let's take once again the sidebars example, which is by no =
doubt the trickiest one. If I want to add two different streams =
(stream_1 and stream_2) in a sidebar, and in the same message I want to =
indicate that stream_2 has to be 'recvonly', I have to be able to tell =
the first identifier (associated with stream_1) apart from the second =
(associated with stream_2). An example like this can be found in the =
XCON examples document on page 73 (sidebarsByRefRequest/update). If I =
weren't able to make such distinction inside the client's message, the =
only remaining option would be to send to the server three distinct =
messages (two of which would be 'updates'): (i) 'update', to create the =
sidebar with stream_1 and stream_2 (such message would just contain, for =
both streams, a generic AUTO_GENERATE wildcard); (ii) 'retrieve', to get =
the (actual) identifiers created by the server; (iii) 'update' (with the =
real identifier retrieved for stream_2), to specify that stream_2 has to =
be 'recvonly'.<br>

All this just to say that both options (use AUTO_GENERATE_X or just =
AUTO_GENERATE for fake identifiers) are viable, but in our view the =
former allows for more flexibility in cases like the one described =
above. What is your feeling?<br>

[/spromano3]<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, the definition of the XCON-USERID needs to be updated in either =
case:<br>
 &nbsp; &nbsp; "The "confUserID" parameter is REQUIRED in<br>
 &nbsp; &nbsp; &nbsp;the CCMP request and response messages with the =
exception of the<br>
 &nbsp; &nbsp; &nbsp;case of a user who has no XCON-USERID and who wants =
to enter, via<br>
 &nbsp; &nbsp; &nbsp;CCMP, a conference whose identifier is known. =
&nbsp;In such case, a<br>
 &nbsp; &nbsp; &nbsp;side-effect of the request is that the user is =
provided with an<br>
 &nbsp; &nbsp; &nbsp;appropriate XCON-USERID.<br>
<br>
So, I'm assuming the AUTO_GENERATE_X is used in the case described =
above?<br>
<br>
Either way, whether there's an increment or not, we do need to add alot =
more text around this mechanism.<br>
[/MB3]<br>
</blockquote>
<br></div>
[spromano3]<br>
Indeed, I'm not sure we need to modify this, since the CCMP schema does =
not *mandate* the presence of the confUserID parameter inside CCMP =
messages. Do you agree with this?<br>
[/spromano3]<div><div></div><div class=3D"h5"><br>
<br>
Cheers,<br>
Simon<br>
<br>
-- <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;_\\|//_<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;( O-O )<br>
 &nbsp; ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;Simon Pietro Romano<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Universita' di Napoli =
Federico II<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Computer =
Science Department<br>
 &nbsp; &nbsp; &nbsp; &nbsp;Phone: +39 081 7683823 -- Fax: +39 081 =
7684219<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;e-mail: <a =
href=3D"mailto:spromano@unina.it" =
target=3D"_blank">spromano@unina.it</a><br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a =
href=3D"http://www.comics.unina.it/simonpietro.romano" =
target=3D"_blank">http://www.comics.unina.it/simonpietro.romano</a><br>
<br>
 &nbsp; &nbsp;&lt;&lt;Molti mi dicono che lo scoraggiamento =C4=8D =
l'alibi degli<br>
 &nbsp; idioti. Ci rifletto un istante; e mi scoraggio&gt;&gt;. =
Magritte.<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; oooO<br>
 &nbsp; ~~~~~~~~~~~~~~~~~~~~~~( &nbsp; )~~ =
Oooo~~~~~~~~~~~~~~~~~~~~~~~~~<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp;\ ( &nbsp; &nbsp;( &nbsp; )<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; \_) &nbsp; &nbsp;) /<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (_/<br>
<br>
<br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></body></html>=

--Apple-Mail-143--237269481--

From rifatyu@avaya.com  Mon Jan 24 11:34:59 2011
Return-Path: <rifatyu@avaya.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 371AA3A6B35 for <xcon@core3.amsl.com>; Mon, 24 Jan 2011 11:34:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ypc-V1GL+Ef for <xcon@core3.amsl.com>; Mon, 24 Jan 2011 11:34:58 -0800 (PST)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 4E3B53A6B24 for <xcon@ietf.org>; Mon, 24 Jan 2011 11:34:58 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAG9jPU2HCzI1/2dsb2JhbACEE59ra3OiegKIM5BAgSSDOHQEhHCJcIJe
X-IronPort-AV: E=Sophos;i="4.60,371,1291611600"; d="scan'208";a="55817806"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 24 Jan 2011 14:37:53 -0500
X-IronPort-AV: E=Sophos;i="4.60,371,1291611600"; d="scan'208";a="587735980"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Jan 2011 14:37:23 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.215]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 24 Jan 2011 14:37:22 -0500
From: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
To: "xcon@ietf.org" <xcon@ietf.org>
Date: Mon, 24 Jan 2011 14:37:22 -0500
Thread-Topic: Conference Focus Indicating CCMP Support
Thread-Index: Acu76WqZ1OEMYg6gTpaCQx/prArkhQAE59RA
Message-ID: <6369CB70BFD88942B9705AC1E639A33822090708DA@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Alan Johnston <alan.b.johnston@gmail.com>
Subject: [XCON] Conference Focus Indicating CCMP Support
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2011 19:34:59 -0000

SGkgQWxhbiwgUmljaGFyZCwNCg0KTWFyeSBhbmQgSSBoYXZlIHN1Ym1pdHRlZCB0aGUgZm9sbG93
aW5nIGRyYWZ0IHRoYXQgZGVhbHMgd2l0aCBhIGNvbmZlcmVuY2UgZm9jdXMgaW5kaWNhdGluZyBz
dXBwb3J0IGZvciBDQ01QLg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt
eXVzZWYteGNvbi1jY21wLWluZGljYXRpb24vDQoNCkNhbiB0aGlzIHdvcmsgYmUgZGlzY3Vzc2Vk
IGluIHRoZSBYQ09OIG9yIGRvIHdlIGhhdmUgdG8gZ28gdG8gdGhlIERJU1BBVENIIGZvciB0aGlz
Pw0KDQpXZSB3b3VsZCBhcHByZWNpYXRlIGFueSBjb21tZW50cyBvbiB0aGlzIGRvY3VtZW50Lg0K
DQpSZWdhcmRzLA0KIFJpZmFhdA0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiBGcm9tOiBJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0
Zi5vcmddDQo+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAyNCwgMjAxMSAxMjowNSBQTQ0KPiBUbzog
U2hla2gtWXVzZWYsIFJpZmFhdCAoUmlmYWF0KQ0KPiBDYzogbWFyeS5pZXRmLmJhcm5lc0BnbWFp
bC5jb20NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15dXNl
Zi14Y29uLWNjbXAtaW5kaWNhdGlvbi0wMA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1E
LCBkcmFmdC15dXNlZi14Y29uLWNjbXAtaW5kaWNhdGlvbi0wMC50eHQgaGFzIGJlZW4NCj4gc3Vj
Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSaWZhYXQgU2hla2gtWXVzZWYgYW5kIHBvc3RlZCB0byB0
aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6CSBkcmFmdC15dXNlZi14Y29u
LWNjbXAtaW5kaWNhdGlvbg0KPiBSZXZpc2lvbjoJIDAwDQo+IFRpdGxlOgkJIENvbmZlcmVuY2Ug
Rm9jdXMgSW5kaWNhdGluZyBDQ01QIFN1cHBvcnQNCj4gQ3JlYXRpb25fZGF0ZToJIDIwMTEtMDEt
MjQNCj4gV0cgSUQ6CQkgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KPiBOdW1iZXJfb2ZfcGFnZXM6
IDgNCj4gDQo+IEFic3RyYWN0Og0KPiBUaGUgQ2VudHJhbGl6ZWQgQ29uZmVyZW5jaW5nIE1hbmlw
dWxhdGlvbiBQcm90b2NvbCBkb2N1bWVudCBkZWZpbmVzIGENCj4gd2F5IGZvciBhIGNsaWVudCB0
byBkaXNjb3ZlciBhIGNvbmZlcmVuY2UgY29udHJvbCBzZXJ2ZXIgdGhhdA0KPiBzdXBwb3J0cyBD
Q01QLiBIb3dldmVyLCBpdCBkb2VzIG5vdCBkZWZpbmUgYSB3YXkgZm9yIGEgY2xpZW50IHRvDQo+
IGRpc2NvdmVyIGlmIGEgY29uZmVyZW5jZSBmb2N1cyBzdXBwb3J0cyBDQ01QLg0KPiANCj4gVGhp
cyBkcmFmdCBkZXNjcmliZXMgZmV3IG9wdGlvbnMgdG8gYWRkcmVzcyB0aGUgYWJvdmUgbGltaXRh
dGlvbiB3aXRoDQo+IHRoZSBwcm9zIGFuZCBjb25zIGZvciBlYWNoIGFwcHJvYWNoLg0KPiANCj4g
DQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdC4NCj4gDQoNCg==

From spromano@unina.it  Wed Jan 26 10:20:33 2011
Return-Path: <spromano@unina.it>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A59A3A6834 for <xcon@core3.amsl.com>; Wed, 26 Jan 2011 10:20:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.614
X-Spam-Level: 
X-Spam-Status: No, score=-100.614 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245,  HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTKsV2KubDYW for <xcon@core3.amsl.com>; Wed, 26 Jan 2011 10:20:30 -0800 (PST)
Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by core3.amsl.com (Postfix) with ESMTP id AADA03A67B3 for <xcon@ietf.org>; Wed, 26 Jan 2011 10:20:29 -0800 (PST)
Received: from [10.0.1.12] ([143.225.229.205]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id p0QINQq0026723 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Jan 2011 19:23:27 +0100
Message-ID: <4D406699.30002@unina.it>
Date: Wed, 26 Jan 2011 19:23:21 +0100
From: Simon Pietro Romano <spromano@unina.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Robert Sparks <rjsparks@nostrum.com>
References: <DE53D7D6-7FC6-445F-8500-FDE234681FA3@nostrum.com> <AANLkTinXKV-eCmpuDWUfm0ZGX6c4+YNxoF95G84gUSzc@mail.gmail.com> <CF9B2EC3-015C-42A8-A031-FE24EDB6583A@nostrum.com> <AANLkTi=kVZaD8jLPKKR-LVATkDgyqFEy-YS2=+kEbkAV@mail.gmail.com> <4D00EEE1.7030703@unina.it> <AANLkTi=wQYn_KV2eqHm6jcR-_Jq5KuQKEdAjk4jS=Pg=@mail.gmail.com> <4D069BB4.9090904@unina.it> <AANLkTik0Ff3EqqwsapSKCDNkeCYc1E7s-kYuGO5ky9b1@mail.gmail.com> <4D087FEC.5060301@unina.it> <AANLkTin+Ah5zT83=i2U0P485DyB_-OSbspkLzcp1dmpP@mail.gmail.com> <9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com>
In-Reply-To: <9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com>
Content-Type: multipart/alternative; boundary="------------040906080509070105040508"
Cc: xcon@ietf.org
Subject: Re: [XCON] AD review: draft-ietf-xcon-ccmp-10
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2011 18:20:33 -0000

This is a multi-part message in MIME format.
--------------040906080509070105040508
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Robert,

see our answers in-line ([spromano]).

> This is heading in the right direction, but I think the server's 
> behavior will still be underspecified
> (if I've missed where these are already covered, please add pointers 
> to to where they're covered to the text you propose below).
>
> 1) It needs to be clear whether or not the server looks for these 
> using a case-sensitive comparison
[spromano] Agreed. I would go for case sensitive operation, and specify 
that AUTO_GENERATE_n has to be upper case. OK?

> 2) It needs to be explicit that
>      - the server will substitute the same string for every instance 
> of AUTO_GENERATE_1 in a given document (similar for _2, _3, etc.)
[spromano] Agreed.

>      - the server will substitute different strings for 
> AUTO_GENERATE_1 and AUTO_GENERATE_n for any n other than 1.

[spromano] Agreed.

>     -  there's no requirement for the server to substitute the same 
> string for AUTO_GENERATE_1 in two different documents, even from the 
> same client.

[spromano] Agreed.

> 3) It should be explicit whether any security properties are expected 
> from the values that are substituted. For instance, is it important 
> that other clients
>     not be able to guess what the server will substitute?
[spromano] I don't really think so. These identifiers are not critical 
from the security perspective.

> 4) It should be explicit that the server generates a string that makes 
> sense for the context that the variable appears in (see question 
> below), and describe
>     what error the server returns if it can't make a substitution 
> resulting in a legal document.
[spromano] I guess the server should generate either a 400 Bad Request 
(see example E) below -- for the case when the request is syntactically 
incorrect), or a generic 500 Server Internal Error, in all cases when 
the request is OK, but the value obtained after the substitution on the 
server's side cannot be served because of semantic issues (e.g. a domain 
name which is not managed by the contacted server, see e.g. example F) 
below).

> 5) Please take care to avoid implementer confusion about quotes around 
> the string being substituted.

[spromano] Do you mean we have to make it explicit that the server 
substitutes just the content inside the quotes?

> Please also make sure any use of this mechanism in the document (or 
> -examples) lines up with the conclusion. Right now, there are some 
> instances
> of AUTO_GENERATE without a _n for any n in the document.

[spromano] OK. We'll double check this, both in the CCMP draft and in 
the call flows examples document.

> You may also want to consider why the incrementing integer is 
> important. The mechanism would work just as well with a document that 
> only contained
> AUTO_GENERATE_1 and AUTO_GENERATE_512. (The server isn't asked to look 
> for gaps, and I'm not seeing why it should. Should a request be
> rejected because it has a gap in its AUTO_GENERATE sequence?).
[spromano] Correct sequencing is irrelevant, as long as the server looks 
after proper differentiation of the identifiers. So, we'll make this 
explicit in the document.

>
> You might also want to say in the document why the group didn't just 
> allow strings like "AUTO_GENERATE_ALICE" and "AUTO_GENERATE_FOO".
> I think the answer is that we wanted to keep the parsing simple for 
> the server while facilitating substitution into arbitrary contexts 
> (with examples being
> replacing only the username part of an xcon-userid, and with the 
> tradeoff being that you can't substitute into a context where the next 
> character would be
> a digit).

[spromano] Agreed. The motivation should be exactly this one. Examples 
like F) below would not be allowed, otherwise.

>
> So coming back to point 4, assume the following stanza beginnings 
> occur in different documents. What strings would you expect the server 
> to substitute
> in place of the placeholder in each case, and what would the server do 
> next? What part of the spec actually tells an implementation to do 
> what you expected?
>
> A) <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
[spromano] <userInfo entity="xcon-userid:pippo@example.com">

> B) <userInfo entity="xcon-userid:AUTO_GENERATE_1">

[spromano] e.g.: <userInfo entity="xcon-userid:pluto@whatever.com">

> C) <userInfo entity="AUTO_GENERATE_1">

[spromano] e.g.: <userInfo entity="xcon-userid:paperino@whatever.com">

> D) <userinfo entity="xcon-userid:AUTO_GENERATE_1@AUTO_GENERATE_2">

[spromano] as above, e.g.: <userInfo 
entity="xcon-userid:topolino@whatever.com">
> E) <userinfo AUTO_GENERATE_1>

[spromano] Error! 404 Bad Request

> F) <userinfo entity="xcon-userid:fooAUTO_GENERATE_1bar@example.com">

[spromano] e.g.: <userInfo entity="xcon-userid:fooPaperinobar@example.com">

Basically, I tend to think that all of the above examples, except 
example E) (which, as said, generates a 400 "Bad Request" response), are 
OK. AUTO_GENERATE_n should actually always be 'inside' the value part of 
an attribute/element in the provided XML excerpt. It should also be a 
RESERVED string, in all cases which might generate conflict situations, 
as per section 4.1 (last paragraph) of the CCMP draft (mandatory fields 
in the data model for which a value has not been set by the server as 
yet). Obviously, nothing should prevent a client from using such a 
string wherever it is not possible to generate any conflicts (e.g. in 
the <display-text>, which is not a mandatory field in the data model). 
This should also clarify the next point (see below).

>
> What text constrains where AUTO_GENERATE_n can appear? I suspect we 
> don't want the server looking to replace it in an xmlns: declaration...

[spromano] Sure we don't! I would stick to the above definition of 
AUTO_GENERATE_n. What do you think?

Thank you once again for your precious feedback.

Cheers,

Simon

>
> RjS
>
>
> On Jan 19, 2011, at 5:29 PM, Mary Barnes wrote:
>
>
>> Hi Simon,
>>
>> I apologize for the long delay.  I do finally get what you are saying 
>> and see why a single dummy value won't work.  So, I would suggest we 
>> add text something like the following.  Please let me know if that 
>> looks okay and then I generate a new version.  Keith also had a few 
>> comments that require changes:
>> http://www.ietf.org/mail-archive/web/xcon/current/msg02476.html
>>
>> Thanks,
>> Mary.
>>
>> OLD:
>>    To solve this kind of issues, the CCMP will fill all mandatory data
>>    model fields, for which no value is available at the client at the
>>    time the request is constructed, with fake values in the form of
>>    wildcard strings (e.g.  AUTO_GENERATE_X, with X being an incremental
>>    index initialized to a value of 1).  Upon reception of the mentioned
>>    kinds of requests, the server will (i) generate the proper
>>    identifier(s); (ii) produce a response in which the received fake
>>    identifier(s) carried in the request has (have) been replaced by the
>>    newly created one(s).
>>
>> NEW:
>>    To resolve these issues, the CCMP MUST fill all mandatory data
>>    model fields, for which no value is available at the client at the
>>    time the request is constructed, with fake values in the form of
>>    the wildcard strings "AUTO_GENERATE_X".  The value of X MUST
>>    be initialized with a value of "1" and incremented for each 
>> mandatory field in the
>>    for which the client does not have a value.  Upon receipt of 
>> requests containing
>>    fields with wildcard strings, the server MUST:  (i) generate the 
>> proper
>>    identifier(s); (ii) produce a response in which the received fake
>>    identifier(s) carried in the request has (have) been replaced by the
>>    newly created one(s).
>>
>> On Wed, Dec 15, 2010 at 2:44 AM, Simon Pietro Romano 
>> <spromano@unina.it <mailto:spromano@unina.it>> wrote:
>>
>>     Hi Mary,
>>
>>     as usual, inline ([spromano3] :-) ).
>>
>>
>>
>>         [MB3] So, I see the point that you need to have something in
>>         the attribute and that there needs to be a way to ensure it
>>         doesn't conflict with a value that might collide with a valid
>>         value.  But, I cannot see the need for the unique increment -
>>         i.e, why won't a fixed "dummy" value work (e.g.,
>>         dummy-user@domain, where the domain is the domain of the conf
>>         server)?  The requesting user knows that they are adding a
>>         specific user to the conference and other information
>>         associated with that user is unique.  Unless the suggestion
>>         is that using the increment makes it easier for the client.
>>         But, I can't see that the information is useful to the
>>         conferencing server since it will just see an identifier with
>>         a specific string and then it knows that it needs to create
>>         one for that user. Unless you are suggesting that the
>>         conferencing server is then ensuring they are unique for a
>>         specific user and returns an error if not?
>>
>>
>>     [spromano3]
>>     Actually, the idea of enumerating AUTO_GENERATE_X dummy
>>     identifiers derives from the presence of potential "cross
>>     references" in some CCMP messages. Let's take once again the
>>     sidebars example, which is by no doubt the trickiest one. If I
>>     want to add two different streams (stream_1 and stream_2) in a
>>     sidebar, and in the same message I want to indicate that stream_2
>>     has to be 'recvonly', I have to be able to tell the first
>>     identifier (associated with stream_1) apart from the second
>>     (associated with stream_2). An example like this can be found in
>>     the XCON examples document on page 73
>>     (sidebarsByRefRequest/update). If I weren't able to make such
>>     distinction inside the client's message, the only remaining
>>     option would be to send to the server three distinct messages
>>     (two of which would be 'updates'): (i) 'update', to create the
>>     sidebar with stream_1 and stream_2 (such message would just
>>     contain, for both streams, a generic AUTO_GENERATE wildcard);
>>     (ii) 'retrieve', to get the (actual) identifiers created by the
>>     server; (iii) 'update' (with the real identifier retrieved for
>>     stream_2), to specify that stream_2 has to be 'recvonly'.
>>     All this just to say that both options (use AUTO_GENERATE_X or
>>     just AUTO_GENERATE for fake identifiers) are viable, but in our
>>     view the former allows for more flexibility in cases like the one
>>     described above. What is your feeling?
>>     [/spromano3]
>>
>>
>>         Also, the definition of the XCON-USERID needs to be updated
>>         in either case:
>>             "The "confUserID" parameter is REQUIRED in
>>              the CCMP request and response messages with the
>>         exception of the
>>              case of a user who has no XCON-USERID and who wants to
>>         enter, via
>>              CCMP, a conference whose identifier is known.  In such
>>         case, a
>>              side-effect of the request is that the user is provided
>>         with an
>>              appropriate XCON-USERID.
>>
>>         So, I'm assuming the AUTO_GENERATE_X is used in the case
>>         described above?
>>
>>         Either way, whether there's an increment or not, we do need
>>         to add alot more text around this mechanism.
>>         [/MB3]
>>
>>
>>     [spromano3]
>>     Indeed, I'm not sure we need to modify this, since the CCMP
>>     schema does not *mandate* the presence of the confUserID
>>     parameter inside CCMP messages. Do you agree with this?
>>     [/spromano3]
>>
>>
>>     Cheers,
>>     Simon
>>
>>     -- 
>>                                _\\|//_
>>                                ( O-O )
>>       ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>>                        Simon Pietro Romano
>>                  Universita' di Napoli Federico II
>>                     Computer Science Department
>>            Phone: +39 081 7683823 -- Fax: +39 081 7684219
>>                    e-mail: spromano@unina.it <mailto:spromano@unina.it>
>>     http://www.comics.unina.it/simonpietro.romano
>>
>>     <<Molti mi dicono che lo scoraggiamento č l'alibi degli
>>       idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>>                             oooO
>>       ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>>                              \ (    (   )
>>                               \_)    ) /
>>                                     (_/
>>
>>
>>
>

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: spromano@unina.it
           http://www.comics.unina.it/simonpietro.romano

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



--------------040906080509070105040508
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Hi Robert,<br>
    <br>
    see our answers in-line ([spromano]).<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">This is heading in the right direction, but I think
      the server's behavior will still be underspecified
      <div>
        <div>(if I've missed where these are already covered, please add
          pointers to to where they're covered to the text you propose
          below).
          <div><br>
          </div>
          <div>1) It needs to be clear whether or not the server looks
            for these using a case-sensitive comparison</div>
        </div>
      </div>
    </blockquote>
    [spromano] Agreed. I would go for case sensitive operation, and
    specify that AUTO_GENERATE_n has to be upper case. OK?<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>2) It needs to be explicit that</div>
          <div>     - the server will substitute the same string for
            every instance of AUTO_GENERATE_1 in a given document
            (similar for _2, _3, etc.)</div>
        </div>
      </div>
    </blockquote>
    [spromano] Agreed.<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>     - the server will substitute different strings for
            AUTO_GENERATE_1 and AUTO_GENERATE_n for any n other than 1.</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] Agreed.<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>    -  there's no requirement for the server to
            substitute the same string for AUTO_GENERATE_1 in two
            different documents, even from the same client.</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] Agreed.<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>3) It should be explicit whether any security properties
            are expected from the values that are substituted. For
            instance, is it important that other clients </div>
          <div>    not be able to guess what the server will substitute?</div>
        </div>
      </div>
    </blockquote>
    [spromano] I don't really think so. These identifiers are not
    critical from the security perspective.<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>4) It should be explicit that the server generates a
            string that makes sense for the context that the variable
            appears in (see question below), and describe</div>
          <div>    what error the server returns if it can't make a
            substitution resulting in a legal document.</div>
        </div>
      </div>
    </blockquote>
    [spromano] I guess the server should generate either a 400 Bad
    Request (see example E) below -- for the case when the request is
    syntactically incorrect), or a generic 500 Server Internal Error, in
    all cases when the request is OK, but the value obtained after the
    substitution on the server's side cannot be served because of
    semantic issues (e.g. a domain name which is not managed by the
    contacted server, see e.g. example F) below).<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>5) Please take care to avoid implementer confusion about
            quotes around the string being substituted.</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] Do you mean we have to make it explicit that the server
    substitutes just the content inside the quotes? <br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>Please also make sure any use of this mechanism in the
            document (or -examples) lines up with the conclusion. Right
            now, there are some instances</div>
          <div>of AUTO_GENERATE without a _n for any n in the document.</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] OK. We'll double check this, both in the CCMP draft and
    in the call flows examples document.<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>You may also want to consider why the incrementing
            integer is important. The mechanism would work just as well
            with a document that only contained</div>
          <div>AUTO_GENERATE_1 and AUTO_GENERATE_512. (The server isn't
            asked to look for gaps, and I'm not seeing why it should.
            Should a request be</div>
          <div>rejected because it has a gap in its AUTO_GENERATE
            sequence?).</div>
        </div>
      </div>
    </blockquote>
    [spromano] Correct sequencing is irrelevant, as long as the server
    looks after proper differentiation of the identifiers. So, we'll
    make this explicit in the document.<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div><br>
          </div>
          <div>You might also want to say in the document why the group
            didn't just allow strings like "AUTO_GENERATE_ALICE" and
            "AUTO_GENERATE_FOO".</div>
          <div>I think the answer is that we wanted to keep the parsing
            simple for the server while facilitating substitution into
            arbitrary contexts (with examples being</div>
          <div>replacing only the username part of an xcon-userid, and
            with the tradeoff being that you can't substitute into a
            context where the next character would be</div>
          <div>a digit).</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] Agreed. The motivation should be exactly this one.
    Examples like F) below would not be allowed, otherwise.<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div><br>
          </div>
          <div>So coming back to point 4, assume the following stanza
            beginnings occur in different documents. What strings would
            you expect the server to substitute</div>
          <div>in place of the placeholder in each case, and what would
            the server do next? What part of the spec actually tells an
            implementation to do what you expected?</div>
          <div><br>
          </div>
          <div>A)             &lt;userInfo
            entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:AUTO_GENERATE_1@example.com">"xcon-userid:AUTO_GENERATE_1@example.com"</a>&gt;</div>
        </div>
      </div>
    </blockquote>
    [spromano] &lt;userInfo entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:pippo@example.com">"xcon-userid:pippo@example.com"</a>&gt;<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>B)            &lt;userInfo
            entity="xcon-userid:AUTO_GENERATE_1"&gt;</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] e.g.: &lt;userInfo
    entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:pluto@whatever.com">"xcon-userid:pluto@whatever.com"</a>&gt;<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>C)            &lt;userInfo entity="AUTO_GENERATE_1"&gt;</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] e.g.: &lt;userInfo
    entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:paperino@whatever.com">"xcon-userid:paperino@whatever.com"</a>&gt;<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>D)            &lt;userinfo
            entity="xcon-userid:AUTO_GENERATE_1@AUTO_GENERATE_2"&gt;</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] as above, e.g.: &lt;userInfo
    entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:topolino@whatever.com">"xcon-userid:topolino@whatever.com"</a>&gt;<br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>E)            &lt;userinfo AUTO_GENERATE_1&gt;</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] Error! 404 Bad Request<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div>F)            &lt;userinfo
            entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:fooAUTO_GENERATE_1bar@example.com">"xcon-userid:fooAUTO_GENERATE_1bar@example.com"</a>&gt;</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] e.g.: &lt;userInfo
    entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:fooPaperinobar@example.com">"xcon-userid:fooPaperinobar@example.com"</a>&gt;<br>
    <br>
    Basically, I tend to think that all of the above examples, except
    example E) (which, as said, generates a 400 "Bad Request" response),
    are OK. AUTO_GENERATE_n should actually always be 'inside' the value
    part of an attribute/element in the provided XML excerpt. It should
    also be a RESERVED string, in all cases which might generate
    conflict situations, as per section 4.1 (last paragraph) of the CCMP
    draft (mandatory fields in the data model for which a value has not
    been set by the server as yet). Obviously, nothing should prevent a
    client from using such a string wherever it is not possible to
    generate any conflicts (e.g. in the &lt;display-text&gt;, which is
    not a mandatory field in the data model). This should also clarify
    the next point (see below). <br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div><br>
          </div>
          <div>What text constrains where AUTO_GENERATE_n can appear? I
            suspect we don't want the server looking to replace it in an
            xmlns: declaration...</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] Sure we don't! I would stick to the above definition of
    AUTO_GENERATE_n. What do you think?<br>
    <br>
    Thank you once again for your precious feedback.<br>
    <br>
    Cheers,<br>
    <br>
    Simon<br>
    <br>
    <blockquote
      cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com"
      type="cite">
      <div>
        <div>
          <div><br>
          </div>
          <div>RjS</div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>
            <div>
              <div>
                <div>On Jan 19, 2011, at 5:29 PM, Mary Barnes wrote:</div>
                <br class="Apple-interchange-newline">
                <br>
                <blockquote type="cite">Hi Simon,
                  <div><br>
                  </div>
                  <div>I apologize for the long delay.  I do finally get
                    what you are saying and see why a single dummy value
                    won't work.  So, I would suggest we add text
                    something like the following.  Please let me know if
                    that looks okay and then I generate a new version.
                     Keith also had a few comments that require changes:</div>
                  <div><a moz-do-not-send="true"
                      href="http://www.ietf.org/mail-archive/web/xcon/current/msg02476.html">http://www.ietf.org/mail-archive/web/xcon/current/msg02476.html</a></div>
                  <div><br>
                  </div>
                  <div>Thanks,</div>
                  <div>Mary. </div>
                  <div>
                    <div><br>
                    </div>
                    <div>OLD: </div>
                    <div>   To solve this kind of issues, the CCMP will
                      fill all mandatory data</div>
                    <div>   model fields, for which no value is
                      available at the client at the</div>
                    <div>   time the request is constructed, with fake
                      values in the form of</div>
                    <div>   wildcard strings (e.g.  AUTO_GENERATE_X,
                      with X being an incremental</div>
                    <div>   index initialized to a value of 1).  Upon
                      reception of the mentioned</div>
                    <div>   kinds of requests, the server will (i)
                      generate the proper</div>
                    <div>   identifier(s); (ii) produce a response in
                      which the received fake</div>
                    <div>   identifier(s) carried in the request has
                      (have) been replaced by the</div>
                    <div>   newly created one(s). </div>
                  </div>
                  <div><br>
                  </div>
                  <div>
                    NEW:</div>
                  <div>   To resolve these issues, the CCMP MUST fill
                    all mandatory data</div>
                  <div>   model fields, for which no value is available
                    at the client at the</div>
                  <div>   time the request is constructed, with fake
                    values in the form of</div>
                  <div>   the wildcard strings "AUTO_GENERATE_X".  The
                    value of X MUST</div>
                  <div>   be initialized with a value of "1" and
                    incremented for each mandatory field in the </div>
                  <div>   for which the client does not have a value.
                     Upon receipt of requests containing</div>
                  <div>   fields with wildcard strings, the server MUST:
                     (i) generate the proper</div>
                  <div>   identifier(s); (ii) produce a response in
                    which the received fake</div>
                  <div>   identifier(s) carried in the request has
                    (have) been replaced by the</div>
                  <div>   newly created one(s). </div>
                  <div>  </div>
                  <div><br>
                    <div class="gmail_quote">On Wed, Dec 15, 2010 at
                      2:44 AM, Simon Pietro Romano <span dir="ltr">&lt;<a
                          moz-do-not-send="true"
                          href="mailto:spromano@unina.it">spromano@unina.it</a>&gt;</span>
                      wrote:<br>
                      <blockquote class="gmail_quote" style="margin: 0pt
                        0pt 0pt 0.8ex; border-left: 1px solid rgb(204,
                        204, 204); padding-left: 1ex;">Hi Mary,<br>
                        <br>
                        as usual, inline ([spromano3] :-) ).
                        <div class="im"><br>
                          <br>
                          <blockquote class="gmail_quote" style="margin:
                            0pt 0pt 0pt 0.8ex; border-left: 1px solid
                            rgb(204, 204, 204); padding-left: 1ex;">
                            <br>
                            [MB3] So, I see the point that you need to
                            have something in the attribute and that
                            there needs to be a way to ensure it doesn't
                            conflict with a value that might collide
                            with a valid value.  But, I cannot see the
                            need for the unique increment - i.e, why
                            won't a fixed "dummy" value work (e.g.,
                            dummy-user@domain, where the domain is the
                            domain of the conf server)?  The requesting
                            user knows that they are adding a specific
                            user to the conference and other information
                            associated with that user is unique.  Unless
                            the suggestion is that using the increment
                            makes it easier for the client. But, I can't
                            see that the information is useful to the
                            conferencing server since it will just see
                            an identifier with a specific string and
                            then it knows that it needs to create one
                            for that user. Unless you are suggesting
                            that the conferencing server is then
                            ensuring they are unique for a specific user
                            and returns an error if not?<br>
                          </blockquote>
                          <br>
                        </div>
                        [spromano3]<br>
                        Actually, the idea of enumerating
                        AUTO_GENERATE_X dummy identifiers derives from
                        the presence of potential "cross references" in
                        some CCMP messages. Let's take once again the
                        sidebars example, which is by no doubt the
                        trickiest one. If I want to add two different
                        streams (stream_1 and stream_2) in a sidebar,
                        and in the same message I want to indicate that
                        stream_2 has to be 'recvonly', I have to be able
                        to tell the first identifier (associated with
                        stream_1) apart from the second (associated with
                        stream_2). An example like this can be found in
                        the XCON examples document on page 73
                        (sidebarsByRefRequest/update). If I weren't able
                        to make such distinction inside the client's
                        message, the only remaining option would be to
                        send to the server three distinct messages (two
                        of which would be 'updates'): (i) 'update', to
                        create the sidebar with stream_1 and stream_2
                        (such message would just contain, for both
                        streams, a generic AUTO_GENERATE wildcard); (ii)
                        'retrieve', to get the (actual) identifiers
                        created by the server; (iii) 'update' (with the
                        real identifier retrieved for stream_2), to
                        specify that stream_2 has to be 'recvonly'.<br>
                        All this just to say that both options (use
                        AUTO_GENERATE_X or just AUTO_GENERATE for fake
                        identifiers) are viable, but in our view the
                        former allows for more flexibility in cases like
                        the one described above. What is your feeling?<br>
                        [/spromano3]
                        <div class="im"><br>
                          <br>
                          <blockquote class="gmail_quote" style="margin:
                            0pt 0pt 0pt 0.8ex; border-left: 1px solid
                            rgb(204, 204, 204); padding-left: 1ex;">
                            Also, the definition of the XCON-USERID
                            needs to be updated in either case:<br>
                                "The "confUserID" parameter is REQUIRED
                            in<br>
                                 the CCMP request and response messages
                            with the exception of the<br>
                                 case of a user who has no XCON-USERID
                            and who wants to enter, via<br>
                                 CCMP, a conference whose identifier is
                            known.  In such case, a<br>
                                 side-effect of the request is that the
                            user is provided with an<br>
                                 appropriate XCON-USERID.<br>
                            <br>
                            So, I'm assuming the AUTO_GENERATE_X is used
                            in the case described above?<br>
                            <br>
                            Either way, whether there's an increment or
                            not, we do need to add alot more text around
                            this mechanism.<br>
                            [/MB3]<br>
                          </blockquote>
                          <br>
                        </div>
                        [spromano3]<br>
                        Indeed, I'm not sure we need to modify this,
                        since the CCMP schema does not *mandate* the
                        presence of the confUserID parameter inside CCMP
                        messages. Do you agree with this?<br>
                        [/spromano3]
                        <div>
                          <div class="h5"><br>
                            <br>
                            Cheers,<br>
                            Simon<br>
                            <br>
                            -- <br>
                                                       _\\|//_<br>
                                                       ( O-O )<br>
                             
                            ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~<br>
                                               Simon Pietro Romano<br>
                                         Universita' di Napoli Federico
                            II<br>
                                            Computer Science Department<br>
                                   Phone: +39 081 7683823 -- Fax: +39
                            081 7684219<br>
                                           e-mail: <a
                              moz-do-not-send="true"
                              href="mailto:spromano@unina.it"
                              target="_blank">spromano@unina.it</a><br>
                                     <a moz-do-not-send="true"
                              href="http://www.comics.unina.it/simonpietro.romano"
                              target="_blank">http://www.comics.unina.it/simonpietro.romano</a><br>
                            <br>
                               &lt;&lt;Molti mi dicono che lo
                            scoraggiamento č l'alibi degli<br>
                              idioti. Ci rifletto un istante; e mi
                            scoraggio&gt;&gt;. Magritte.<br>
                                                    oooO<br>
                              ~~~~~~~~~~~~~~~~~~~~~~(   )~~
                            Oooo~~~~~~~~~~~~~~~~~~~~~~~~~<br>
                                                     \ (    (   )<br>
                                                      \_)    ) /<br>
                                                            (_/<br>
                            <br>
                            <br>
                          </div>
                        </div>
                      </blockquote>
                    </div>
                    <br>
                  </div>
                </blockquote>
              </div>
              <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: <a class="moz-txt-link-abbreviated" href="mailto:spromano@unina.it">spromano@unina.it</a>
          <a class="moz-txt-link-freetext" href="http://www.comics.unina.it/simonpietro.romano">http://www.comics.unina.it/simonpietro.romano</a>

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

</pre>
  </body>
</html>

--------------040906080509070105040508--

From rjsparks@nostrum.com  Wed Jan 26 10:34:01 2011
Return-Path: <rjsparks@nostrum.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523AF3A6826 for <xcon@core3.amsl.com>; Wed, 26 Jan 2011 10:34:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.557
X-Spam-Level: 
X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wfmeXQT-mXC for <xcon@core3.amsl.com>; Wed, 26 Jan 2011 10:34:00 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 497433A6862 for <xcon@ietf.org>; Wed, 26 Jan 2011 10:33:59 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0QIawvp027125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Jan 2011 12:36:58 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-154--67763053
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <4D406699.30002@unina.it>
Date: Wed, 26 Jan 2011 12:36:56 -0600
Message-Id: <83193E1C-4584-4B1C-B024-0BD574BF8FF5@nostrum.com>
References: <DE53D7D6-7FC6-445F-8500-FDE234681FA3@nostrum.com> <AANLkTinXKV-eCmpuDWUfm0ZGX6c4+YNxoF95G84gUSzc@mail.gmail.com> <CF9B2EC3-015C-42A8-A031-FE24EDB6583A@nostrum.com> <AANLkTi=kVZaD8jLPKKR-LVATkDgyqFEy-YS2=+kEbkAV@mail.gmail.com> <4D00EEE1.7030703@unina.it> <AANLkTi=wQYn_KV2eqHm6jcR-_Jq5KuQKEdAjk4jS=Pg=@mail.gmail.com> <4D069BB4.9090904@unina.it> <AANLkTik0Ff3EqqwsapSKCDNkeCYc1E7s-kYuGO5ky9b1@mail.gmail.com> <4D087FEC.5060301@unina.it> <AANLkTin+Ah5zT83=i2U0P485DyB_-OSbspkLzcp1dmpP@mail.gmail.com> <9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com> <4D406699.30002@unina.it>
To: Simon Pietro Romano <spromano@unina.it>
X-Mailer: Apple Mail (2.1082)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: xcon@ietf.org
Subject: Re: [XCON] AD review: draft-ietf-xcon-ccmp-10
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2011 18:34:01 -0000

--Apple-Mail-154--67763053
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jan 26, 2011, at 12:23 PM, Simon Pietro Romano wrote:

> Hi Robert,
>=20
> see our answers in-line ([spromano]).
>=20
<snip>

>=20
>> 5) Please take care to avoid implementer confusion about quotes =
around the string being substituted.
>=20
> [spromano] Do you mean we have to make it explicit that the server =
substitutes just the content inside the quotes?=20

Yes, and I'm not necessarily asking for more text. Just make sure the =
existing text can't be read ambiguously, and that
the examples are not misleading.=20

<snip>

>=20
>>=20
>> So coming back to point 4, assume the following stanza beginnings =
occur in different documents. What strings would you expect the server =
to substitute
>> in place of the placeholder in each case, and what would the server =
do next? What part of the spec actually tells an implementation to do =
what you expected?
>>=20
>> A)             <userInfo =
entity=3D"xcon-userid:AUTO_GENERATE_1@example.com">
> [spromano] <userInfo entity=3D"xcon-userid:pippo@example.com">
>=20
>> B)            <userInfo entity=3D"xcon-userid:AUTO_GENERATE_1">
>=20
> [spromano] e.g.: <userInfo entity=3D"xcon-userid:pluto@whatever.com">
>=20
>> C)            <userInfo entity=3D"AUTO_GENERATE_1">
>=20
> [spromano] e.g.: <userInfo entity=3D"xcon-userid:paperino@whatever.com">=

>=20
>> D)            <userinfo =
entity=3D"xcon-userid:AUTO_GENERATE_1@AUTO_GENERATE_2">
>=20
> [spromano] as above, e.g.: <userInfo =
entity=3D"xcon-userid:topolino@whatever.com">

For A-D, I don't believe the existing text tells an implementation what =
kind of string it should have created. Do you think that's covered =
already?

>> E)            <userinfo AUTO_GENERATE_1>
>=20
> [spromano] Error! 404 Bad Request
>=20
>> F)            <userinfo =
entity=3D"xcon-userid:fooAUTO_GENERATE_1bar@example.com">
>=20
> [spromano] e.g.: <userInfo =
entity=3D"xcon-userid:fooPaperinobar@example.com">
>=20
> Basically, I tend to think that all of the above examples, except =
example E) (which, as said, generates a 400 "Bad Request" response), are =
OK. AUTO_GENERATE_n should actually always be 'inside' the value part of =
an attribute/element in the provided XML excerpt. It should also be a =
RESERVED string, in all cases which might generate conflict situations, =
as per section 4.1 (last paragraph) of the CCMP draft (mandatory fields =
in the data model for which a value has not been set by the server as =
yet). Obviously, nothing should prevent a client from using such a =
string wherever it is not possible to generate any conflicts (e.g. in =
the <display-text>, which is not a mandatory field in the data model). =
This should also clarify the next point (see below).=20
>=20
>>=20
>> What text constrains where AUTO_GENERATE_n can appear? I suspect we =
don't want the server looking to replace it in an xmlns: declaration...
>=20
> [spromano] Sure we don't! I would stick to the above definition of =
AUTO_GENERATE_n. What do you think?

That seems like a reasonable approach. The details on how you capture it =
in the document will be important.


>=20
> Thank you once again for your precious feedback.
>=20
> Cheers,
>=20
> Simon
>=20


--Apple-Mail-154--67763053
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 26, 2011, at 12:23 PM, Simon Pietro Romano wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
    Hi Robert,<br>
    <br>
    see our answers in-line ([spromano]).<br><br></div></blockquote>&lt;snip&gt;</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
    <br>
    <blockquote cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com" type="cite">
      <div>
        <div>
          <div>5) Please take care to avoid implementer confusion about
            quotes around the string being substituted.</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] Do you mean we have to make it explicit that the server
    substitutes just the content inside the quotes? <br></div></blockquote><div><br></div>Yes, and I'm not necessarily asking for more text. Just make sure the existing text can't be read ambiguously, and that</div><div>the examples are not misleading.&nbsp;</div><div><br></div><div>&lt;snip&gt;</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
    <br>
    <blockquote cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com" type="cite">
      <div>
        <div>
          <div><br>
          </div>
          <div>So coming back to point 4, assume the following stanza
            beginnings occur in different documents. What strings would
            you expect the server to substitute</div>
          <div>in place of the placeholder in each case, and what would
            the server do next? What part of the spec actually tells an
            implementation to do what you expected?</div>
          <div><br>
          </div>
          <div>A)&nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;userInfo
            entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:AUTO_GENERATE_1@example.com">"xcon-userid:AUTO_GENERATE_1@example.com"</a>&gt;</div>
        </div>
      </div>
    </blockquote>
    [spromano] &lt;userInfo entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:pippo@example.com">"xcon-userid:pippo@example.com"</a>&gt;<br>
    <br>
    <blockquote cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com" type="cite">
      <div>
        <div>
          <div>B)&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;userInfo
            entity="xcon-userid:AUTO_GENERATE_1"&gt;</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] e.g.: &lt;userInfo
    entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:pluto@whatever.com">"xcon-userid:pluto@whatever.com"</a>&gt;<br>
    <br>
    <blockquote cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com" type="cite">
      <div>
        <div>
          <div>C) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;userInfo entity="AUTO_GENERATE_1"&gt;</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] e.g.: &lt;userInfo
    entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:paperino@whatever.com">"xcon-userid:paperino@whatever.com"</a>&gt;<br>
    <br>
    <blockquote cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com" type="cite">
      <div>
        <div>
          <div>D) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;userinfo
            entity="xcon-userid:AUTO_GENERATE_1@AUTO_GENERATE_2"&gt;</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] as above, e.g.: &lt;userInfo
    entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:topolino@whatever.com">"xcon-userid:topolino@whatever.com"</a>&gt;<br></div></blockquote><div><br></div><div>For A-D, I don't believe the existing text tells an implementation what kind of string it should have created. Do you think that's covered already?</div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
    <blockquote cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com" type="cite">
      <div>
        <div>
          <div>E) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;userinfo AUTO_GENERATE_1&gt;</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] Error! 404 Bad Request<br>
    <br>
    <blockquote cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com" type="cite">
      <div>
        <div>
          <div>F) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;userinfo
            entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:fooAUTO_GENERATE_1bar@example.com">"xcon-userid:fooAUTO_GENERATE_1bar@example.com"</a>&gt;</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] e.g.: &lt;userInfo
    entity=<a class="moz-txt-link-rfc2396E" href="mailto:xcon-userid:fooPaperinobar@example.com">"xcon-userid:fooPaperinobar@example.com"</a>&gt;<br>
    <br>
    Basically, I tend to think that all of the above examples, except
    example E) (which, as said, generates a 400 "Bad Request" response),
    are OK. AUTO_GENERATE_n should actually always be 'inside' the value
    part of an attribute/element in the provided XML excerpt. It should
    also be a RESERVED string, in all cases which might generate
    conflict situations, as per section 4.1 (last paragraph) of the CCMP
    draft (mandatory fields in the data model for which a value has not
    been set by the server as yet). Obviously, nothing should prevent a
    client from using such a string wherever it is not possible to
    generate any conflicts (e.g. in the &lt;display-text&gt;, which is
    not a mandatory field in the data model). This should also clarify
    the next point (see below). <br>
    <br>
    <blockquote cite="mid:9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com" type="cite">
      <div>
        <div>
          <div><br>
          </div>
          <div>What text constrains where AUTO_GENERATE_n can appear? I
            suspect we don't want the server looking to replace it in an
            xmlns: declaration...</div>
        </div>
      </div>
    </blockquote>
    <br>
    [spromano] Sure we don't! I would stick to the above definition of
    AUTO_GENERATE_n. What do you think?<br></div></blockquote><div><br></div>That seems like a reasonable approach. The details on how you capture it in the document will be important.</div><div><br></div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
    <br>
    Thank you once again for your precious feedback.<br>
    <br>
    Cheers,<br>
    <br>
    Simon<br>
    <font class="Apple-style-span" color="#006312"><br></font>
    </div></blockquote></div><br></body></html>
--Apple-Mail-154--67763053--

From oscar.novo@ericsson.com  Fri Jan 28 07:00:23 2011
Return-Path: <oscar.novo@ericsson.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9343A68CB for <xcon@core3.amsl.com>; Fri, 28 Jan 2011 07:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J47sM384Tml7 for <xcon@core3.amsl.com>; Fri, 28 Jan 2011 07:00:21 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id DE5973A688F for <xcon@ietf.org>; Fri, 28 Jan 2011 07:00:18 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-e7-4d42dabcc9a6
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FA.A3.23694.CBAD24D4; Fri, 28 Jan 2011 16:03:24 +0100 (CET)
Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.2.69]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 28 Jan 2011 16:03:24 +0100
From: Oscar Novo <oscar.novo@ericsson.com>
To: Robert Sparks <rjsparks@nostrum.com>
Date: Fri, 28 Jan 2011 16:03:23 +0100
Thread-Topic: [XCON] AD review: draft-ietf-xcon-common-data-model-19
Thread-Index: Acu79l9xB3Bml9qtRl+lsbO2RTaw1ADBg4SQ
Message-ID: <58E207308662A748A4AC1ECB4E885614052C73E39B@ESESSCMS0355.eemea.ericsson.se>
References: <326FB158-5C3C-48FC-96C6-252ABE05A10B@nostrum.com> <58E207308662A748A4AC1ECB4E88561403D02C92@ESESSCMS0355.eemea.ericsson.se> <537E4975-C9FB-4046-A264-C3325310959B@nostrum.com> <58E207308662A748A4AC1ECB4E885614013029BA0E@ESESSCMS0355.eemea.ericsson.se> <0957E5CB-0D6C-4992-9AF5-55C1DC2E9AFF@nostrum.com> <58E207308662A748A4AC1ECB4E88561401304EC4A5@ESESSCMS0355.eemea.ericsson.se> <0DE83F89-E769-4112-91E8-27F96AC69D45@nostrum.com> <58E207308662A748A4AC1ECB4E885614052C5D2655@ESESSCMS0355.eemea.ericsson.se> <C7D69DB9-BF79-47DF-BCC1-D7512AAA7405@nostrum.com> <58E207308662A748A4AC1ECB4E885614052C5D29E5@ESESSCMS0355.eemea.ericsson.se> <97615872-0BBA-4BBE-8165-88A4AB81B39C@nostrum.com>
In-Reply-To: <97615872-0BBA-4BBE-8165-88A4AB81B39C@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "xcon@ietf.org" <xcon@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2011 15:00:23 -0000

So, what's your solution about it?

Oscar

-----Original Message-----
From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 24. tammikuuta 2011 20:42
To: Oscar Novo
Cc: xcon@ietf.org; 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 n=
ot immediately 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 mig=
ht 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:rjsparks@nostrum.com]
> Sent: 13. tammikuuta 2011 22:45
> To: Oscar Novo
> Cc: xcon@ietf.org; 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:
>
>> Hi Robert,
>>
>> As you said, our ideas start to converge. So, I think a real-time meetin=
g wouldn't be necessary at this moment. If the XCON chairs or you still thi=
nk 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 sup=
erset of the data format defined in 4575.
>>
>> The XML in the document has been reviewed many times. Jari and myself ha=
ve 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 thi=
ngs around. Note that there are other documents in the XCON WG using simila=
r 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 standardizat=
ion, <conference-password>  MUST NOT appear in elements of type uris-type o=
ther than <conf-uris>.
>>
>> Regarding the new text in 4.6.2 <user-admission policy> section. Would t=
he 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 authentica=
tion mechanism are beyond the scope of  this document.  The list of possibl=
e 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 partic=
ipant 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 us=
er is placed on a pending list as indicated earlier. An 'closedAuthenticate=
d'        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 con=
ferencing participant to be sufficiently authenticated. Typically this impl=
ies       that anyone capable of authenticating with the conferencing syste=
m may join the conference. The 'openAuthenticated' policy permits the  spec=
ification of "banned" conferencing participants. Such banned users are prev=
ented 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 incl=
ude 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 i=
s the least restrictive policy. An 'anonymous' policy MUST NOT include eith=
er        an <allowed-users-list> or a <deny-users-list>. If any of these l=
ists 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.
>
> This is all good, but the last paragraph as written will require any futu=
re standardization effort that wants to create a new policy to include an R=
FC that Updates this one. That may be required anyhow, but I want to make s=
ure the group considers this consequence explicitly. It is not immediately =
obvious to me what we might do differently.
>
>>
>> Concerning your last question, as you suggested, I will remove the comme=
nts from all the extensibility elements.
>>
>> Cheers,
>>
>> Oscar
>>
>> -----Original Message-----
>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>> Sent: 12. tammikuuta 2011 22:33
>> To: Oscar Novo
>> Cc: xcon@ietf.org; 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 o=
ut 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, le=
aving 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 meanin=
g to a <conference-password> appearing inside an <associated-aors>?
>>>> The schema allows it (or am I reading the schema wrong?). Did the grou=
p _intend_ for the schema to allow that, and do they anticipate that it wil=
l have >any meaning at some point? Or should there be text that forbids tha=
t 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 t=
his document (and 4575s) definitions carefully, and I think I might see whe=
re we haven't been coming together.
>>
>> Your statement above isn't quite right. This document restates the synta=
x defined in 4575 (using a RelaxNG schema), and shows where you take advant=
age of the extension points that were already in that grammar by adding ele=
ments using another namespace.
>>
>> Using the grammar defined in this document, conference-password can be p=
roduced 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 t=
o 4.6.5.2 below, I suggest instead to add this as a new paragraph at the en=
d 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 standardizat=
ion, <conference-password>  MUST NOT appear in elements of type uris-type o=
ther 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 wri=
tten.
>>
>> Also, while talking through this with others, I had several people comme=
nt that "xcon-conference-info" namespace and the "conference-info" namespac=
es are so visually similar that it's easy to misunderstand what this docume=
nt 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 conf=
erence-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 w=
ith 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 l=
ist >(such as ><list name=3D"allowed users">).
>>>
>>>> It doesn't. It defines lists and telegraphs semantics with the name. W=
ith what you've specified so far, you are encouraging a low level of >inter=
operability.
>>>
>>>> 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 a=
n admission policy for the conference. The data model defines three types o=
f admission: closedAuthenticated, openAuthenticated, anonymous.
>>>     - The "anonymous" policy allows everyone to connect to the conferen=
ce.
>>>     - 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, b=
anning a user can be accomplished by removing the user from the <allowed-us=
ers-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 doc=
ument at this point.
>>> I'm planning to add the following text in the 4.6.2 <user-admission pol=
icy>:
>>>
>>> ""openAuthenticated": An 'openAuthenticated' policy requires each confe=
rencing participant to be sufficiently authenticated. Typically this implie=
s that anyone capable of authenticating with the conferencing system may jo=
in the conference.
>>> The 'openAuthenticated' policy permits the specification of "banned" co=
nferencing participants. Such banned users are prevented from re-joining th=
e 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 all=
owed-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-use=
rs-list, but must not include an allowed-users-list (you must ignore any de=
ny-users-list that appears).
>> If you are using a closedAuthenticated policy, you must include an allow=
ed-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-use=
rs-list has no meaning defined by this document. Future specifications desc=
ribing the use of these lists must either disallow both appearing at the sa=
me time or provide clear guidance on how to process the lists when they occ=
ur 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 slas=
h 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 wou=
ld you suggest?
>>>
>>>> [Robert] No, it's not self-explanatory - if it were, we wouldn't be ha=
ving 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 s=
omething we should recommend as part of standardizing this model.
>> Basically, you're saying that an implementation that believes it isn't g=
oing to exercise an extension point can stub those extension points out.
>> In practice, this will result in incompatible versions of the schema bei=
ng fielded, and in the worst of cases, when the implementer was _wrong_ abo=
ut this implementation (or the things around it) wanting to use the extensi=
on points, results in a brittle system. We certainly can't prevent an imple=
menter 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 th=
e future more difficult.
>>
>> I think you should remove the comments from the document altogether.
>>
>>
>> RjS
>>
>>>
>>> Oscar
>>
>


From rjsparks@nostrum.com  Fri Jan 28 07:35:41 2011
Return-Path: <rjsparks@nostrum.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E823A6872 for <xcon@core3.amsl.com>; Fri, 28 Jan 2011 07:35:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.561
X-Spam-Level: 
X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vqJsnk0o1a8 for <xcon@core3.amsl.com>; Fri, 28 Jan 2011 07:35:38 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 81DF73A67A8 for <xcon@ietf.org>; Fri, 28 Jan 2011 07:35:37 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0SFcdGu063351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Jan 2011 09:38:40 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <58E207308662A748A4AC1ECB4E885614052C73E39B@ESESSCMS0355.eemea.ericsson.se>
Date: Fri, 28 Jan 2011 09:38:39 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F13E526-FCA4-45D6-B41B-73DF8CD2C684@nostrum.com>
References: <326FB158-5C3C-48FC-96C6-252ABE05A10B@nostrum.com> <58E207308662A748A4AC1ECB4E88561403D02C92@ESESSCMS0355.eemea.ericsson.se> <537E4975-C9FB-4046-A264-C3325310959B@nostrum.com> <58E207308662A748A4AC1ECB4E885614013029BA0E@ESESSCMS0355.eemea.ericsson.se> <0957E5CB-0D6C-4992-9AF5-55C1DC2E9AFF@nostrum.com> <58E207308662A748A4AC1ECB4E88561401304EC4A5@ESESSCMS0355.eemea.ericsson.se> <0DE83F89-E769-4112-91E8-27F96AC69D45@nostrum.com> <58E207308662A748A4AC1ECB4E885614052C5D2655@ESESSCMS0355.eemea.ericsson.se> <C7D69DB9-BF79-47DF-BCC1-D7512AAA7405@nostrum.com> <58E207308662A748A4AC1ECB4E885614052C5D29E5@ESESSCMS0355.eemea.ericsson.se> <97615872-0BBA-4BBE-8165-88A4AB81B39C@nostrum.com> <58E207308662A748A4AC1ECB4E885614052C73E39B@ESESSCMS0355.eemea.ericsson.se>
To: Oscar Novo <oscar.novo@ericsson.com>
X-Mailer: Apple Mail (2.1082)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: "xcon@ietf.org" <xcon@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2011 15:35:41 -0000

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

RjS

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

> So, what's your solution about it?
>=20
> Oscar
>=20
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> Sent: 24. tammikuuta 2011 20:42
> To: Oscar Novo
> Cc: xcon@ietf.org; Gonzalo Camarillo
> Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
>=20
> 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.
>=20
> RjS
>=20
> On Jan 14, 2011, at 1:14 AM, Oscar Novo wrote:
>=20
>>=20
>> Hi Robert,
>>=20
>>> 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.
>>=20
>> 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.
>>=20
>> What about changing the last paragraph to:
>>=20
>>       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.
>>=20
>> Oscar
>>=20
>> -----Original Message-----
>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>> Sent: 13. tammikuuta 2011 22:45
>> To: Oscar Novo
>> Cc: xcon@ietf.org; Gonzalo Camarillo
>> Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
>>=20
>> One comment inline
>>=20
>> On Jan 13, 2011, at 5:20 AM, Oscar Novo wrote:
>>=20
>>> Hi Robert,
>>>=20
>>> 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.
>>>=20
>>> 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:
>>>=20
>>> The data model document is a normative document and it constitutes a =
superset of the data format defined in 4575.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> I agree to include the following text in section 4.2.10:
>>>=20
>>> 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>.
>>>=20
>>> Regarding the new text in 4.6.2 <user-admission policy> section. =
Would the following text fullfil your requirements?:
>>>=20
>>> 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:
>>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> 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.
>>=20
>>>=20
>>> Concerning your last question, as you suggested, I will remove the =
comments from all the extensibility elements.
>>>=20
>>> Cheers,
>>>=20
>>> Oscar
>>>=20
>>> -----Original Message-----
>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>>> Sent: 12. tammikuuta 2011 22:33
>>> To: Oscar Novo
>>> Cc: xcon@ietf.org; Gonzalo Camarillo
>>> Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
>>>=20
>>> Hi Oscar -
>>>=20
>>> 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.
>>>=20
>>> RjS
>>>=20
>>> On Jan 5, 2011, at 6:04 AM, Oscar Novo wrote:
>>>=20
>>>> Hello Robert,
>>>>=20
>>>> 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.
>>>>=20
>>>>=20
>>>>> [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>?
>>>>=20
>>>> [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>.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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).
>>>=20
>>> 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:
>>>=20
>>> 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>.
>>>=20
>>> 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.
>>>=20
>>> 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?
>>>=20
>>>>=20
>>>>=20
>>>> I could add the following text to 4.6.5.2.:
>>>>=20
>>>> "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."
>>>>=20
>>>>=20
>>>>> =
/------------------------Question----------------------------------
>>>>> -
>>>>> -
>>>>> -
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> * 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.
>>>>>>=20
>>>>>>=20
>>>>>> [ON1] As we agreed in the WG, the semantic of those elements will =
be defined in further documents.
>>>>=20
>>>>> [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=3D"allowed users">).
>>>>=20
>>>>> 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.
>>>>=20
>>>>> I'll start a separate thread on this.
>>>>=20
>>>> [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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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>:
>>>>=20
>>>> ""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."
>>>>=20
>>>> Do the text above clarify your question?
>>>=20
>>> The additional text would help, but it's not sufficient yet.
>>> Given what you say here, I'm looking for something that says:
>>>=20
>>> 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.
>>>=20
>>> And I think it needs to say those things using 2119 words.
>>>=20
>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> =
/------------------------Question----------------------------------
>>>>> -
>>>>> -
>>>>> -
>>>>>>=20
>>>>>>=20
>>>>>> * 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.
>>>>>>=20
>>>>>> [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.
>>>>>=20
>>>>> [RObert] Then,  please add text
>>>>> explaining who the instructions are intended for and when they
>>>>> should be invoked.
>>>>>=20
>>>>> [ON1] Is not the current text self-explanatory? Which instructions =
would you suggest?
>>>>=20
>>>>> [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.
>>>>=20
>>>> [O] Right, what about adding the following text in every =
extensibility elements?
>>>>=20
>>>> "If extensions (check section 6) beyond this specification are not =
used, re-define anyAttribute as <empty/> and remove the definition =
below"
>>>>=20
>>>> Would it be clear adding the text above?
>>>=20
>>> 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.
>>>=20
>>> I think you should remove the comments from the document altogether.
>>>=20
>>>=20
>>> RjS
>>>=20
>>>>=20
>>>> Oscar
>>>=20
>>=20
>=20


From oscar.novo@ericsson.com  Fri Jan 28 07:44:03 2011
Return-Path: <oscar.novo@ericsson.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67CD3A67DA for <xcon@core3.amsl.com>; Fri, 28 Jan 2011 07:44:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PufZ-V1-Fbva for <xcon@core3.amsl.com>; Fri, 28 Jan 2011 07:44:02 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 083B63A68CC for <xcon@ietf.org>; Fri, 28 Jan 2011 07:44:00 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-e8-4d42e4f99ce3
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C9.68.23694.9F4E24D4; Fri, 28 Jan 2011 16:47:05 +0100 (CET)
Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.2.69]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 28 Jan 2011 16:47:05 +0100
From: Oscar Novo <oscar.novo@ericsson.com>
To: Robert Sparks <rjsparks@nostrum.com>
Date: Fri, 28 Jan 2011 16:47:04 +0100
Thread-Topic: [XCON] AD review: draft-ietf-xcon-common-data-model-19
Thread-Index: Acu/AXUyhGqIKlasTW++7hhCV4/W5AAAQcxA
Message-ID: <58E207308662A748A4AC1ECB4E885614052C73E3ED@ESESSCMS0355.eemea.ericsson.se>
References: <326FB158-5C3C-48FC-96C6-252ABE05A10B@nostrum.com> <58E207308662A748A4AC1ECB4E88561403D02C92@ESESSCMS0355.eemea.ericsson.se> <537E4975-C9FB-4046-A264-C3325310959B@nostrum.com> <58E207308662A748A4AC1ECB4E885614013029BA0E@ESESSCMS0355.eemea.ericsson.se> <0957E5CB-0D6C-4992-9AF5-55C1DC2E9AFF@nostrum.com> <58E207308662A748A4AC1ECB4E88561401304EC4A5@ESESSCMS0355.eemea.ericsson.se> <0DE83F89-E769-4112-91E8-27F96AC69D45@nostrum.com> <58E207308662A748A4AC1ECB4E885614052C5D2655@ESESSCMS0355.eemea.ericsson.se> <C7D69DB9-BF79-47DF-BCC1-D7512AAA7405@nostrum.com> <58E207308662A748A4AC1ECB4E885614052C5D29E5@ESESSCMS0355.eemea.ericsson.se> <97615872-0BBA-4BBE-8165-88A4AB81B39C@nostrum.com> <58E207308662A748A4AC1ECB4E885614052C73E39B@ESESSCMS0355.eemea.ericsson.se> <3F13E526-FCA4-45D6-B41B-73DF8CD2C684@nostrum.com>
In-Reply-To: <3F13E526-FCA4-45D6-B41B-73DF8CD2C684@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "xcon@ietf.org" <xcon@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2011 15:44:04 -0000

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:rjsparks@nostrum.com]
Sent: 28. tammikuuta 2011 17:39
To: Oscar Novo
Cc: xcon@ietf.org; Gonzalo Camarillo
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19

To stick with your first proposal (with a suggested tweak) and live with th=
e consequences:

In all other cases, the appearance of an <allowed-users-list> and <deny-use=
rs-list> MUST be ignored. Future specifications describing the use of these=
 lists must provide clear guidance on how to process the lists when they oc=
cur 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 docum=
ent.

RjS

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

> So, what's your solution about it?
>
> Oscar
>
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> Sent: 24. tammikuuta 2011 20:42
> To: Oscar Novo
> Cc: xcon@ietf.org; 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 authorizatio=
n 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 o=
n 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 i=
s 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.
>>
>> Right, I didnt think about that. Actually, allowing both lists may not b=
e good idea. Most likely future extensions will create their own elements o=
r will use the allowed-users-list and the deny-users-list separately. It mi=
ght 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:rjsparks@nostrum.com]
>> Sent: 13. tammikuuta 2011 22:45
>> To: Oscar Novo
>> Cc: xcon@ietf.org; 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:
>>
>>> Hi Robert,
>>>
>>> As you said, our ideas start to converge. So, I think a real-time meeti=
ng wouldn't be necessary at this moment. If the XCON chairs or you still th=
ink it's needed, I don't have any problem to set up a meeting with the grou=
p.
>>>
>>> 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 su=
perset of the data format defined in 4575.
>>>
>>> The XML in the document has been reviewed many times. Jari and myself h=
ave 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 th=
ings around. Note that there are other documents in the XCON WG using simil=
ar syntax, for instance, "Conference Event Package Data Format Extension fo=
r 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 standardiza=
tion, <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 authenticatio=
n mechanism - determined by every individual conference  servers - may need=
 to be mapped from the different protocols. The specific types of authentic=
ation mechanism are beyond the scope of  this document.  The list of possib=
le 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 partic=
ipant 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 us=
er is placed on a pending list as indicated earlier. An 'closedAuthenticate=
d'        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 con=
ferencing participant to be sufficiently authenticated. Typically this impl=
ies       that anyone capable of authenticating with the conferencing syste=
m may join the conference. The 'openAuthenticated' policy permits the  spec=
ification of "banned" conferencing participants. Such banned users are prev=
ented 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 incl=
ude 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 i=
s the least restrictive policy. An 'anonymous' policy MUST NOT include eith=
er        an <allowed-users-list> or a <deny-users-list>. If any of these l=
ists 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.
>>
>> This is all good, but the last paragraph as written will require any fut=
ure 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.
>>
>>>
>>> Concerning your last question, as you suggested, I will remove the comm=
ents from all the extensibility elements.
>>>
>>> Cheers,
>>>
>>> Oscar
>>>
>>> -----Original Message-----
>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>>> Sent: 12. tammikuuta 2011 22:33
>>> To: Oscar Novo
>>> Cc: xcon@ietf.org; 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, l=
eaving 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 meani=
ng to a <conference-password> appearing inside an <associated-aors>?
>>>>> The schema allows it (or am I reading the schema wrong?). Did the gro=
up _intend_ for the schema to allow that, and do they anticipate that it wi=
ll have >any meaning at some point? Or should there be text that forbids th=
at 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 wh=
ere we haven't been coming together.
>>>
>>> Your statement above isn't quite right. This document restates the synt=
ax defined in 4575 (using a RelaxNG schema), and shows where you take advan=
tage of the extension points that were already in that grammar by adding el=
ements 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 e=
nd 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 standardiza=
tion, <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 schem=
a. (Has such a review already been performed?).
>>> One question I have is whether this is a normative update to 4575 as wr=
itten.
>>>
>>> Also, while talking through this with others, I had several people comm=
ent that "xcon-conference-info" namespace and the "conference-info" namespa=
ces are so visually similar that it's easy to misunderstand what this docum=
ent 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 con=
ference-info?
>>>
>>>>
>>>>
>>>> I could add the following text to 4.6.5.2.:
>>>>
>>>> "The <associated-aors> child element is explained in [RFC4575], sectio=
n 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=3D"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 >inte=
roperability.
>>>>
>>>>> 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 conferen=
ce.
>>>>    - 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-u=
sers-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 do=
cument at this point.
>>>> I'm planning to add the following text in the 4.6.2 <user-admission po=
licy>:
>>>>
>>>> ""openAuthenticated": An 'openAuthenticated' policy requires each conf=
erencing participant to be sufficiently authenticated. Typically this impli=
es that anyone capable of authenticating with the conferencing system may j=
oin the conference.
>>>> The 'openAuthenticated' policy permits the specification of "banned" c=
onferencing participants. Such banned users are prevented from re-joining t=
he 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 al=
lowed-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-us=
ers-list, but must not include an allowed-users-list (you must ignore any d=
eny-users-list that appears).
>>> If you are using a closedAuthenticated policy, you must include an allo=
wed-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-us=
ers-list has no meaning defined by this document. Future specifications des=
cribing the use of these lists must either disallow both appearing at the s=
ame time or provide clear guidance on how to process the lists when they oc=
cur 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 sla=
sh 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 wo=
uld you suggest?
>>>>
>>>>> [Robert] No, it's not self-explanatory - if it were, we wouldn't be h=
aving 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 use=
d, 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 be=
ing fielded, and in the worst of cases, when the implementer was _wrong_ ab=
out this implementation (or the things around it) wanting to use the extens=
ion points, results in a brittle system. We certainly can't prevent an impl=
ementer 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 t=
he future more difficult.
>>>
>>> I think you should remove the comments from the document altogether.
>>>
>>>
>>> RjS
>>>
>>>>
>>>> Oscar
>>>
>>
>