From xcon-bounces@ietf.org Fri Mar 02 17:58:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNEkP-0004r8-Us; Fri, 02 Mar 2007 15:53:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNEhd-0000Wb-4B; Fri, 02 Mar 2007 15:50:09 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNEhc-0001Sw-0w; Fri, 02 Mar 2007 15:50:09 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A74FB26F17; Fri, 2 Mar 2007 20:50:05 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HNEhY-0002Zw-EO; Fri, 02 Mar 2007 15:50:04 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 02 Mar 2007 15:50:04 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-common-data-model-04.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Conference Information Data Model for Centralized Conferencing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-04.txt Pages : 71 Date : 2007-3-2 This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference object, which can be manipulated using a conference control protocol, at a conference server represents a particular instantiation of this data model. The conference information data model defined in this document is an extension of (and thus, compatible with) the model specified in the Session Initiation Protocol (SIP) Event Package for Conference State. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-common-data-model-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-common-data-model-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-2144628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-common-data-model-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-common-data-model-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-2144628.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --NextPart-- From xcon-bounces@ietf.org Fri Mar 02 21:20:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJrB-0000y8-NH; Fri, 02 Mar 2007 21:20:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJqc-0000Zf-2O for xcon@ietf.org; Fri, 02 Mar 2007 21:19:46 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNJqa-0007jc-Oc for xcon@ietf.org; Fri, 02 Mar 2007 21:19:46 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l232Jgt28686 for ; Fri, 2 Mar 2007 21:19:42 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C75D3A.6704755A" Date: Fri, 2 Mar 2007 20:19:42 -0600 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-boulton-xcon-userid-01.txt Thread-index: AcdcTaH6XxSMNMJnTB+X7LJvDLFRagAzzs1Q From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [XCON] FW: I-D ACTION:draft-boulton-xcon-userid-01.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C75D3A.6704755A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Per the following, we've updated the Conference User Identifier document, reflecting the mailing list comments (to which I'll respond separately). Per those comments, the approach is to provide general guidelines rather than prescriptive definition and mapping of the conference user identifiers within a conferencing system.=20 Any additional feedback is appreciated. This document is referenced in the XCON framework as a non-normative reference, but it would still be good to get feedback on whether this document should be a WG document. Thanks, Mary -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Thursday, March 01, 2007 2:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-boulton-xcon-userid-01.txt A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : A User Identifier for Centralized Conferencing (XCON) Author(s) : C. Boulton, M. Barnes Filename : draft-boulton-xcon-userid-01.txt Pages : 9 Date : 2007-3-1 =09 A conferencing system is defined by "A framework and Data Model for Centralized Conferencing" and represents a container for administering and managing all conference related information. The conference user concept is introduced in the framework to identify the entity participating in a conference and manipulating conferencing system related properties. This document defines a Conference User Identifier and provides some guidelines for identifying a specific conference user within a conferencing system. The document also provides some examples of the logical mapping of this conference user identifier to protocol and signaling interface specific user identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boulton-xcon-userid-01.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-boulton-xcon-userid-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-boulton-xcon-userid-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C75D3A.6704755A Content-Type: application/octet-stream; name="draft-boulton-xcon-userid-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-boulton-xcon-userid-01.URL Content-Disposition: attachment; filename="draft-boulton-xcon-userid-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VsdG9uLXhjb24tdXNlcmlkLTAxLnR4dA0K ------_=_NextPart_001_01C75D3A.6704755A Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon ------_=_NextPart_001_01C75D3A.6704755A-- From xcon-bounces@ietf.org Fri Mar 02 21:22:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJst-0001Vp-QK; Fri, 02 Mar 2007 21:22:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJsV-0001Ji-RE for xcon@ietf.org; Fri, 02 Mar 2007 21:21:43 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNJsU-0007uS-Hy for xcon@ietf.org; Fri, 02 Mar 2007 21:21:43 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l232Lew09866 for ; Fri, 2 Mar 2007 21:21:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Mar 2007 20:21:09 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated draft: draft-boulton-xcon-uri-01.txt Thread-index: AcddOptFy/He2/jXQ3SWGWRM6zA6mQ== From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [XCON] Updated draft: draft-boulton-xcon-uri-01.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org The draft defining a URI for identifying a specific conference object has also been updated (I don't have the general IETF announcement, so I'm assuming my spam filter ate it for some reason or I indavertently deleted while doing my manual spam filtering): http://www.ietf.org/internet-drafts/draft-boulton-xcon-uri-01.txt The primary changes in this version were the expansion of the section on distribution of the identifiers to include discussion of their creation, considering the cases where users join a conference via signaling mechanisms such as SIP versus using the conference control protocol. The security section also has real text now. It is hopefully also now clear in the document that the mapping mechanism is not prescriptive for systems that have other mechanisms to correlate the various signaling URIs with the XCON URI. =20 While this document isn't entirely complete (IANA registration section is still empty), it is believed to fairly comprehensive at this point. As with the user identifier document, this document is a non-normative reference in the framework, but it would still be good to get feedback as to whether this document is ready to be accepted as a WG document. Regards, Mary=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 02 21:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJtG-0001b5-Ae; Fri, 02 Mar 2007 21:22:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJsc-0001Jr-Bg for xcon@ietf.org; Fri, 02 Mar 2007 21:21:50 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNJsa-0007vD-Uq for xcon@ietf.org; Fri, 02 Mar 2007 21:21:50 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l232Liw09872; Fri, 2 Mar 2007 21:21:45 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-uri-00 Date: Fri, 2 Mar 2007 20:21:43 -0600 Message-ID: In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C041B263D@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Feedback requested: draft-boulton-xcon-uri-00 Thread-index: AccUuhsnaZV7lc3LTqyiocfCIu1QkwCMh4YgEYzRwgA= From: "Mary Barnes" To: "Even, Roni" , "Lorenzo Miniero" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Roni, Thanks for the comments and I believe that your concerns have been = reflected in the updated document (i.e., allowing users to join using = SIP), per comments below [MB]. =20 Mary -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il]=20 Sent: Sunday, December 03, 2006 9:15 AM To: Lorenzo Miniero; xcon@ietf.org Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-uri-00 Hi, I read the draft and my view is that the conference object identifier is = an XCON entity, it may be used for defining the conference name (user = part) for a signaling protocol like SIP but this is not mandatory. Even = in the example the conference access using signaling may be done using a = SIP URI or a Phone number. The major purpose of the identifier is for the XCON conference object. I = am not sre it saves something to have a pre-defined mapping since anyhow = you list the conference call signaling access in the document itself. [MB] We've clarified that the mapping proposal is an example or = guideline for an implementation that chooses to do it that way, but it = is not mandatory. The text hopefully clarifies that users may join with = SIP signaling and the the URI is required for the conferencing system = (and needed by any user that wants to manipulate the conference object). = [/MB] Another point to consider is that the conference call signaling access = (SIP URI, PSTN) may be the same for all conferences when using two stage = dialing (IVR), it may get a unique identifier only after the conference = is established but not when it is reserved. See RFC 4579 section 5.3 for = such a flow for SIP systems.=20 [MB] It is possible that some conferences will use the same blueprint or = reservation (and thus the same XCON URI), but once the conference is = active, there would be a unique XCON URI. [/MB] Roni Even=20 > -----Original Message----- > From: Lorenzo Miniero [mailto:rainmaker@libero.it] > Sent: Thursday, November 30, 2006 9:57 PM > To: xcon@ietf.org > Subject: Re: [XCON] Feedback requested: draft-boulton-xcon-uri-00 >=20 > Hi Mary, >=20 > > Per discussions at IETF-67, here's the reminder that we'd like = feedback > > on this draft: > > http://www.ietf.org/internet-drafts/draft-boulton-xcon-uri-00.txt > > > > This document defines a URI scheme and syntax for the conference = object > > identifier, as defined in "A Framework and Data Model for = Centralized > > Conferencing". > > > > This identifier has been a fundamental concept in the XCON framework > > from the beginning and seems quite necessary. I think this draft is > > fairly complete and the identifier itself is already part of the = data > > model, as pointed out by Oscar. > > > > So, the questions would be how much more detail is necessary in this > > document and can it be accepted as a WG document? > > > > Regards, > > Mary > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > >=20 >=20 > I absolutely agree on the fact that such an identifier was needed in = the > framework, and I'm glad that it has been proposed. What I still don't > understand after having the draft read, and I take advantage of this = new > draft proposal to repeat a question I made some weeks ago on this ML = and > got ignored: considering the conference joining matter, will this URI = be > directly used to join conferences using a message of the > soon-to-come-CCP, or will only its unique token be used to compose > signaling URIs to access conferences using the relative CSP (e.g. > xcon:123@xxx --> sip:123@xxx)? > I ask this since I consider the joining method matter very important = in > a framework that by definition will (should?) not depend upon a = specific > CSP for media, besides the fact that a running XCON conference could = be > text-only as well, which would make a CSP almost useless. I personally > think (and I ask the opinion of you all about that) that it could very > well be a message of the CCP, which would allow an user to join the > conference as an 'abstract' object, with no set of resources accessed > yet (e.g. still no audio/video/text/etc) until the user states its = will > to access one or more of them by means of the respective CSP = (accessing > the URIs as mapped in this draft), or with some resource always > available by default upon joining (text, for example) and others that > can be latterly requested and accessed. >=20 > Hope to hear from you soon, cheers, >=20 > Lorenzo >=20 > -- > Lorenzo Miniero, Junior Researcher > Dipartimento di Informatica e Sistemistica > Universit=E0 degli Studi di Napoli "Federico II" > Via Claudio 21 -- 80125 Napoli (Italy) > Phone: +390817683821 - Fax: +390817683816 > Email: lminiero@napoli.consorzio-cini.it >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 >=20 >=20 >=20 > = *************************************************************************= * > ********** > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & = computer > viruses. > = *************************************************************************= * > ********** >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 02 21:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJtG-0001bk-Gc; Fri, 02 Mar 2007 21:22:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJsk-0001KT-NB for xcon@ietf.org; Fri, 02 Mar 2007 21:21:58 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNJsj-0007vj-D6 for xcon@ietf.org; Fri, 02 Mar 2007 21:21:58 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l232Lnt28720; Fri, 2 Mar 2007 21:21:50 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-userid-00 Date: Fri, 2 Mar 2007 20:21:49 -0600 Message-ID: In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C041B2643@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Feedback requested: draft-boulton-xcon-userid-00 Thread-index: AccUpFkcft+tPN2WS5CCitqMyBURhACSfr5wEZJi9bA= From: "Mary Barnes" To: "Even, Roni" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: cboulton@ubiquity.net X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Roni, Thanks for the feedback, which has been incorporated into the -01. Hopefully, we've also addressed your last concern around the display-name by adding that as a recommendation (in section 5). Mary -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il]=20 Sent: Sunday, December 03, 2006 9:28 AM To: Barnes, Mary (RICH2:AR00); xcon@ietf.org Cc: cboulton@ubiquity.net Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-userid-00 Hi You had the following question in the draft 1. How much normative detail do we need to include in this document for the conference user identifier?=20 RE: My view is minimum 2. Or are the details of the conference user identifier implementation specific and we just need to provide examples?=20 RE: Just provide examples that will give some guidelines to how to specify users that are defined at conference reservation via XCON and how to give identity to unspecified users who dial the conference and join. 3. Does the definition require that the mapping to the user ids for other protocols be obvious (e.g., visibly derivable or would that be implementation specific?=20 RE: Like question 2, give some guidelines. In general the user identifier is internal to the XCON document; also be aware that the user may be unknown when defining the conference, this is typical for participants who will dial to the conference, their identity will appear in the conference roster based on something like "asserted identity". BTW: What about specifying non-English display names, suggest to add display name field to the URI. Roni Even > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Thursday, November 30, 2006 7:24 PM > To: xcon@ietf.org > Cc: cboulton@ubiquity.net > Subject: [XCON] Feedback requested: draft-boulton-xcon-userid-00 >=20 > Per discussions at IETF-67, here's the reminder that we'd like feedback > on this draft: > http://www.ietf.org/internet-drafts/draft-boulton-xcon-userid-00.txt >=20 > The conference user concept is introduced in the framework to identify > the entity participating in a conference and manipulating > conferencing system related properties. This document defines a > Conference User Identifier and syntax for identifying a specific > conference user within a conferencing system. The document also > describes the logical mapping of this conference user identifier to > protocol and signaling interface specific user identifiers. >=20 > The questions are around how prescriptive we need to be in XCON > specifications as to the allocation, distribution and definiton of this > identifier or would this all just be purely informational. This > concept has been part of the framework from day one and it does seem to > be an important concept and something that should be part of the basic > data model, as well. >=20 > Regards, > Mary >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 >=20 >=20 >=20 > ************************************************************************ ** > ********** > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & computer > viruses. > ************************************************************************ ** > ********** >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 02 21:22:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJtb-0001nd-CO; Fri, 02 Mar 2007 21:22:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJsr-0001Tv-TV for xcon@ietf.org; Fri, 02 Mar 2007 21:22:06 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNJsp-0007w3-IJ for xcon@ietf.org; Fri, 02 Mar 2007 21:22:05 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l232Lrt28724; Fri, 2 Mar 2007 21:21:53 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-uri-00 Date: Fri, 2 Mar 2007 20:21:52 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Feedback requested: draft-boulton-xcon-uri-00 Thread-index: AccUpGVuaXSlIFacQki9/VbtYga4OQaFz0sgC58zq8A= From: "Mary Barnes" To: "Srivatsa Srinivasan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: cboulton@ubiquity.net X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Srivatsa, Thanks for the feedback. Detailed responses embedded below [MB].=20 Mary -----Original Message----- From: Srivatsa Srinivasan [mailto:srivats@exchange.microsoft.com]=20 Sent: Wednesday, January 03, 2007 2:28 AM To: Barnes, Mary (RICH2:AR00); xcon@ietf.org Cc: cboulton@ubiquity.net Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-uri-00 Hi Mary and Chris, Sorry for the late comments. Overall, the idea of having a separate identifier to identify the conference object resource sounds useful. Was there a reason for using a new scheme based URI instead of a simple unique identifier? Some text in the introduction to make the motivation clear would help. Also, do you foresee the XCON URI to be a routable entity in the future? Perhaps some normative text there regarding its use would be beneficial? [MB] I'm not sure we've totally addressed your first concern in the updated -01, but hopefully the updated document is more complete in terms of clarifying the usage by the expanded text in section 6. I think the idea of using a URI is that it could be routable depending upon a conferencing system implementation and it seems reasonable to use a URI from that perspective. I guess we could add a statement somewhere in section 3 to explicit state this. [/MB] More comments follow. >From Section 3 " Editors Note: Part of the extension to the Conference Package for XCON? " [SS] The data model and conference package for XCON should have text describing where an XCON URI may appear in the document. It's usage should however be specified in this document, the framework and the conference control protocol if I understand correctly. [MB] Agreed - we've deleted that Editor's note. [/MB] >From Section 3.1 " The left hand side of the URI (to the left of the '@') represents the unique token. This token can be used by any protocol wishing to gain access to functionality associated with a specific conference object. For example, when used to construct a SIP INVITE request, the token would be used to populate the 'user' part of the SIP URI - as defined in RFC 3261[2]. The right hand side of the URI, as with any URI, provides domain level information ('example.com' in previous example). So continuing the previous example, the SIP URI domain part would be equal to this domain information." [SS] Is the above text implying that, given an XCON URI, a client/implementation can construct an equivalent SIP URI by just parsing out sections from the XCON URI and forming the SIP URI? I think giving normative detail here with respect to the mapping is quite unnecessary and may in fact cause inter-op issues (if implemented incorrectly). Inclusion of these terms should not prevent an implementation from using SIP URI's instead of XCON URI's all over the place (in the data model) without breaking normative behavior, correct? [MB] Hopefully, with the updated text this is clear that this mapping isn't normative and it's an implementation detail as to how a conferncing system logically maps things. [/MB] Srivatsa. > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Thursday, November 30, 2006 9:25 AM > To: xcon@ietf.org > Cc: cboulton@ubiquity.net > Subject: [XCON] Feedback requested: draft-boulton-xcon-uri-00 > > Per discussions at IETF-67, here's the reminder that we'd like feedback > on this draft: > http://www.ietf.org/internet-drafts/draft-boulton-xcon-uri-00.txt > > This document defines a URI scheme and syntax for the conference object > identifier, as defined in "A Framework and Data Model for Centralized > Conferencing". > > This identifier has been a fundamental concept in the XCON framework > from the beginning and seems quite necessary. I think this draft is > fairly complete and the identifier itself is already part of the data > model, as pointed out by Oscar. > > So, the questions would be how much more detail is necessary in this > document and can it be accepted as a WG document? > > Regards, > Mary > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 02 21:23:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJu0-00028F-SF; Fri, 02 Mar 2007 21:23:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJtQ-0001gd-I4 for xcon@ietf.org; Fri, 02 Mar 2007 21:22:40 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNJtO-000800-PC for xcon@ietf.org; Fri, 02 Mar 2007 21:22:40 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l232MSw09882; Fri, 2 Mar 2007 21:22:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-userid-00 Date: Fri, 2 Mar 2007 20:21:58 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Feedback requested: draft-boulton-xcon-userid-00 Thread-index: AccUpFkcft+tPN2WS5CCitqMyBURhACSfr5wBfTaxiALnfhV4A== From: "Mary Barnes" To: "Srivatsa Srinivasan" , "Even, Roni" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: cboulton@ubiquity.net X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Srivatsa, Sorry for the late reply :) As far as endpoints being identified, I think that's already covered in the data model and I don't think it needs to be addressed in this document. Or, do folks think that relationship also needs to be described?=20 Mary -----Original Message----- From: Srivatsa Srinivasan [mailto:srivats@exchange.microsoft.com]=20 Sent: Wednesday, January 03, 2007 2:33 AM To: 'Even, Roni'; Barnes, Mary (RICH2:AR00); xcon@ietf.org Cc: cboulton@ubiquity.net Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-userid-00 Sorry for the late comments. Agree with Roni on most of what was said below. I do not see why the mapping from user identifier to user id has to be strictly (normatively) specified. The data model could be modified to include the URIs that correspond to a specific user id. This could be easily accomplished by simply having a -like container element (with the asserted identities for that user) under the element such that automata can then use the mapping as necessary. On the same topic, how are endpoints under the user identified? In the case of SIP, the endpoint entity could be a simple numeric number (an endpoint id, unique within the conference) and the SIP URI corresponding to that could be a GRUU. The data model could be modified to include this SIP URI corresponding to the endpoint id. One use (albeit not great) of such an id is to use it as the RTP CNAME in cases where the RTP SSRC cannot be used to indicate active speaker. There could be other uses as well. Srivatsa. > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Sunday, December 03, 2006 7:28 AM > To: Mary Barnes; xcon@ietf.org > Cc: cboulton@ubiquity.net > Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-userid-00 > > Hi > You had the following question in the draft > > 1. How much normative detail do we need to include in this document for > the conference user identifier? > RE: My view is minimum > > > 2. Or are the details of the conference user identifier implementation > specific and we just need to provide examples? > > RE: Just provide examples that will give some guidelines to how to > specify users that are defined at conference reservation via XCON and > how to give identity to unspecified users who dial the conference and > join. > > 3. Does the definition require that the mapping to the user ids for > other protocols be obvious (e.g., visibly derivable or would that be > implementation specific? > > RE: Like question 2, give some guidelines. > > In general the user identifier is internal to the XCON document; also > be > aware that the user may be unknown when defining the conference, this > is > typical for participants who will dial to the conference, their > identity > will appear in the conference roster based on something like "asserted > identity". > > BTW: What about specifying non-English display names, suggest to add > display name field to the URI. > > Roni Even > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Thursday, November 30, 2006 7:24 PM > > To: xcon@ietf.org > > Cc: cboulton@ubiquity.net > > Subject: [XCON] Feedback requested: draft-boulton-xcon-userid-00 > > > > Per discussions at IETF-67, here's the reminder that we'd like > feedback > > on this draft: > > http://www.ietf.org/internet-drafts/draft-boulton-xcon-userid-00.txt > > > > The conference user concept is introduced in the framework to > identify > > the entity participating in a conference and manipulating > > conferencing system related properties. This document defines a > > Conference User Identifier and syntax for identifying a specific > > conference user within a conferencing system. The document also > > describes the logical mapping of this conference user identifier to > > protocol and signaling interface specific user identifiers. > > > > The questions are around how prescriptive we need to be in XCON > > specifications as to the allocation, distribution and definition of > this > > identifier or would this all just be purely informational. This > > concept has been part of the framework from day one and it does seem > to > > be an important concept and something that should be part of the > basic > > data model, as well. > > > > Regards, > > Mary > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > > > > *********************************************************************** > * > ** > > ********** > > This footnote confirms that this email message has been scanned by > > PineApp Mail-SeCure for the presence of malicious code, vandals & > computer > > viruses. > > > *********************************************************************** > * > ** > > ********** > > > > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Mar 05 05:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOAUe-0001LS-T2; Mon, 05 Mar 2007 05:32:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOAUd-0001LL-IQ for xcon@ietf.org; Mon, 05 Mar 2007 05:32:35 -0500 Received: from mail.unina.it ([192.132.34.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOAUY-0007qu-CH for xcon@ietf.org; Mon, 05 Mar 2007 05:32:35 -0500 Received: from [143.225.229.184] ([143.225.229.184]) by mail.unina.it (8.13.7/8.13.7) with ESMTP id l25AVFuZ005711; Mon, 5 Mar 2007 11:31:16 +0100 Message-ID: <45EBF134.8030104@unina.it> Date: Mon, 05 Mar 2007 11:30:12 +0100 From: Lorenzo Miniero User-Agent: Mozilla Thunderbird 1.5.0.9 (X11/20070212) MIME-Version: 1.0 To: "Oscar Novo (JO/LMF)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.unina.it id l25AVFuZ005711 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b157e6e8a3799aef911c0bc37fc93a6 Cc: xcon@ietf.org, "Gonzalo Camarillo \(JO/LMF\)" Subject: [XCON] Re: FW: [Fwd: Re: Elements in the data model] X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Oscar Novo (JO/LMF) ha scritto: > Hi Simon Pietro, >=20 > Here, I send you some comments. Before to put put a new revision of the > draft I would like to know your opinion for the last comments. >=20 > Regards, >=20 > Oscar >=20 Hi Gonzalo and Oscar, we're glad you found our comments useful in refining your document.=20 We've read the updated draft you sent us, and we think it's a good step=20 forward. We're putting the Mailing List in copy to this message, since we think=20 it can be of interest to the ongoing discussion upon the data model. Regarding your reply to our previous mail, you'll find our new comments=20 inline ([S&L&T] as Simon, Lorenzo and Tobia). >> -------- Original Message -------- >> Subject: Re: Elements in the data model >> Date: Tue, 6 Feb 2007 12:44:43 +0100 >> From: Simon Pietro Romano >> To: Gonzalo Camarillo >> CC: lorenzo.miniero@unina.it, tobia.castaldi@unina.it, Alfonso=20 >> >> References: <45B85AE1.3080606@ericsson.com> >> >> Dear Gonzalo, >> >> sorry for the late response...as you know we've been working on the > editing of the DCON drfat proposals during these last days. >> Please find in the following our considerations about the data model.=20 >> Take them >> as suggestions for improvement and keep in mind that probably many of > our concerns might disappear with a face-to-face clarification. I'm sur= e > the upcoming version of the draft is on the right track and helps > satisfy most of the "desiderata" expressed by the group. I keep on > thinking that the data model is the hardest part of the design work for > any project. >> We've checked the data model you sent us, analyzing the elements > marked with an '*' as you suggested, so in the following lines we'll > provide you with our thoughts and suggestions about them. >> Comments inline. >> >>> ! >>> | >>> |--! >>> | |-- >>> | |-- >>> | |--* >> We think this can stay. >> >>> | |-- >>> | |--* >> This too, even if it would probably fit better in some child element > of >> : this way you could have a more detailed list of > web-pages related to different conference-related services, instead of > the only one that's reported here. >> [Gonzalo&Oscar] We have removed this element from this part of the > data model. >>> | |--* >> This is a little vague and too complex to concentrate in a single > element. It should probably be elaborated. An idea could be removing it > for the moment, and leaving it to future extensions where this matter, > which is a very important and sensitive one, could be deeply considered. >> [Gonzalo&Oscar] Agree. That's too vague. We have removed this element > from this part of the data model. >>> | |--* >> This is fine, even if it would probably fit better in the related > sidebars section later, but it's just an idea. >> [Gonzalo&Oscar] we still think this element is fine as a child element > of the element. The sidebar-by-ref and > sidebar-by-val sections are not inside any global sidebar element just > for backward compatibility with RFC 4575. [S&L&T] That's okay then. >>> | |--* >> Is this a typo for or is it ? It > should be described better, but it probably is fine to let it stay. >> [Gonzalo&Oscar] It wasn't a typo but we've decided to remove it > because it wasn't clear the propose of this element.=20 >>> | |--* >>> | | |--* >>> | | | |--* >>> | | | |--* >>> | | | |--* >>> | | | |--* >>> | | | |--* >>> | | | |--* >>> | | | |--* >>> | | | |--* >> We think that this one, as the security-related element before, should > be better elaborated and analyzed. You could leave the as a stub= , > and furtherly enhance and improve it in later extensions. >> [Gonzalo&Oscar] we have read this section again and we can't see what > is not clear, we need a bit more help from you. what exactly you don't > understand from the text? Which element is not clear enough? Maybe, do > you have in mind a better text to put in the draft? [S&L&T] is surely enough to handle scheduled conferences and=20 their optional recurrency, being it an iCal object. As to the rest,=20 , and=20 are useful entries, but we don't see the=20 point of having the others in this data model, if it really means to be=20 only a base for future extensions. >>> | | ... >>> | |-- >>> | | |--* >>> | | | |-- >>> | | | |-- >>> | | | |-- >>> | | |--* >>> | | | |--* >>> | | | |--* >>> | | |--* >>> | | | |--* >>> | | | |--* >>> | | | |--* >>> | | | |--* >>> | | ... >> The ones that are reported are fine but there only are CSP (Call > Signaling Protocol) URIs. Will other media URIs be put here as well? >> We're thinking about IM-related resources, as Jabber channels that > could be associated with the conference for text, or any other URI > related to any media that could be available in the conference (e.g. >> whiteboarding). This is more a question than a suggestion, of course, > and it can be left to future study and extensions. >> [Gonzalo&Oscar] yes, other media URIs should be put in this section > (such Jabber), not only CSP. >> >>> | |-- >>> | | |--* >>> | | | |-- >>> | | | |-- >>> | | | |-- >>> | | |--* >>> | | | |--* >>> | | | |--* >>> | | |--* >>> | | | |--* >>> | | |--* >>> | | | |--* >>> | | ... >> The BFCP ConferenceID should be removed from here and put in > instead, where it would probaby fit much better. An= d > as we suggested before, maybe also web-related URLs as the conference >> web-page(s) would stay better here than where they are now. >> >> [Gonzalo&Oscar] we have moved the conferenceID to the > element. >>> | |-- >>> | | |--* >>> | | |--* >>> | | ... >> This is fine where it is but the child is not described well > enough. What will it contain? Will it have subchilds, and if so, which > ones? >> [Gonzalo&Oscar] we have removed the child element from the > element to have it align with RFC 4575.=20 >>> | |--* >>> | | |--* >>> | | |--* >>> | | ... >> This is too mixing-related in our opinion, and so it would probably be > better removing it for now and leaving it to future extensions. This > would allow better coordination with the work currently carried out by > the MediaCtrl WG, which could give us all a clearer view on what is > needed by the AS about mixing. >> [Gonzalo&Oscar] we have removed the element from the > data model. >>> | |--! >>> | | |--! >>> | | | |-- >>> | | | |-- >>> | | | |-- >>> | | | |--* >>> | | | |--* >>> | | | |--* >>> | | | | |--* >>> | | | | |--* >>> | | | | ... >>> | | | |--* >>> | | | | |--* >>> | | | | |--* >>> | | | | ... >> Same as before, the mixing-related matter is a little too vague at the > moment. >> [Gonzalo&Oscar] Exactly which element is too vague at the moment? > ? ? We can remove them if they are not enough > clear. [S&L&T] Having basic controls for media is absolutely fine, but only as=20 long as they keep being an abstraction to be laterly bound to the=20 underlying mixing layer, whatever and however this is made.=20 and are a bit too mixing-oriented to meet this=20 requirement, while should be kept at best as informative only,=20 read-only entries, and left to the CSP negotiation while joining a=20 conference. Some similar issues were raised by Srivatsa Srinivasan too=20 in a mail on the ML a couple of months ago. >>> | | |-- >>> | | | |-- >>> | | | |-- >>> | | | |-- >>> | | | |--* >>> | | | |--* >>> | | | |--* >>> | | | | |--* >>> | | | | |--* >>> | | | | ... >>> | | | |--* >>> | | | | |--* >>> | | | | |--* >>> | | | | ... >> Idem. >> >>> | | ... >>> | >>> |-- >>> | |-- >>> | |-- >>> | |--! >>> | | |--!* >>> | | | |--!* >>> | | | |--* >>> | | | |--* >>> | | |--* >>> | | | |--* >>> | | | |--* >>> | | |--* >>> | | | |--* >>> | ... >> What difference is there between these URIs and the ones that have > been reported before? Anyway, the observations are the same as the ones > we made for the URIs before. >> [Gonzalo&Oscar] This element contains information about the entity > hosting the conference. contains the URI to be used in orde= r > to access the conference. >> >>> |-- >>> | |--* >> We read on the draft that this element is related to the possibility > to subscribe to the conference event package. If so, it is probably fin= e > where it is, but a clearer name (e.g. >> ) wouldn't hurt, since the > current name can be confusing. >> [Gonzalo&Oscar] yes, the name you suggest is much more clear. Good > point. We have change it.=20 >>> | |-- >>> | |--! >>> | |-- >>> | >>> |--* >>> | |--* >>> | |--* >>> | |--* >>> | | |--* >>> | | | |--* >>> | | | |--* >>> | | | |--* >>> | | | |--* >>> | | | |--* >>> | | | ... >>> | | ... >> As we suggested befre, the BFCP ConferenceID that crrently sits in the > service URIs should be moved somewhere in here, where it surely is its > place.=20 >> [Gonzalo&Oscar] yes, now it's where you suggested=20 >> >> Regarding the existing elements, what exactly is the ? > Is it a CSP-related URI or a BFCP UserID?=20 >> [Gonzalo&Oscar] BFCP UserID >> >> It would probably be better having it be the second, rather than the > first, and thus having its name be something like or the > like. The rest is fine, other policies can be added in future > extensions. >> [Gonzalo&Oscar] we have change the name of moderator-uri to chair-id. >> >>> | >>> |--! >>> | |--* >>> | |--* >>> | |--* >>> | | |--* >>> | | |-- ... >> and are somewhat confusing and > overlapping concepts: it could be a good idea finding a way to merge > them together, unless they explicitely refer to different and separate > matters. [S&L&T] About this, their difference is clearer now. However,=20 envisages the possibility of having a PIN-driven access=20 to the conference by means of IVR interaction. But where is this PIN=20 stored in the data model, if needed? >> >>> | | >>> | |--* >>> | | |--* >>> | | | |--* >>> | | | | |--* >>> | | | | | |--* >>> | | | | | | | >>> | | | | | | ... >>> | | | | | | >>> | | | | | |--* >>> | | | | | | |--* >>> | | | | | | |--* >>> | | | | | >>> | | | | |--* >>> | | | | | | >>> | | | | | ... >>> | | | ... >> Since you just proposed the new discussion about policies on the WG > Mailing List, it may be better waiting for what will come out from the > discussion before putting policy-related stuff in the data model that > could be latterly rejected, thus leaving the matter to future > extensions. >> [Gonzalo&Oscar] we have removed the from the > new version of the draft. >>> | | >>> | |--! >>> | | |-- >>> | | |-- >>> | | |--* >> This is a little confuse, it should be better > explained and elaborated, otherwise it would be better to remove it for > the moment. >> [Gonzalo&Oscar] we have try to explain a bit better this element. > Please, tell us if now it's a bit more clear. [S&L&T] It is a bit clearer now, though it still presents some=20 ambiguity. The draft states: "the focus provides to the rest of the=20 participants an anonymous identity for that user, for example=20 anonymousX". What is not clear is: does this 'masquerading' also affects=20 the way the user information is stored in the data model as a whole, or=20 only its appearance to other users requesting or being notified about=20 it? To be more precise, is the real information about the user stored in=20 the data model, and then faked when this information needs to be shown=20 to the outside, or is the user completely anonymized directly in the=20 data model itself? >>> | | |-- >>> | | | | >>> | | | ... >>> | | |-- >>> | | |-- >>> | | |--* >> Why calling this instead of ? >> >> [Gonzalo&Oscar] We have remove sphere from the data model. It was too > vague. >>> | | |--* >>> | | |--* >>> | | |--* >>> | | |--! >>> | | | |-- >>> | | | |-- >>> | | | |-- >>> | | | |-- >>> | | | |-- >>> | | | |-- >>> | | | |-- >>> | | | |--! >>> | | | | |-- >>> | | | | |-- >>> | | | | |--