From xcon-bounces@ietf.org Sun Dec 03 10:15:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqt46-0001kU-Op; Sun, 03 Dec 2006 10:15:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqt46-0001kP-5U for xcon@ietf.org; Sun, 03 Dec 2006 10:15:38 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gqt43-0001vG-IM for xcon@ietf.org; Sun, 03 Dec 2006 10:15:38 -0500 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: Sun, 3 Dec 2006 17:15:28 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C041B263D@IsrExch01.israel.polycom.com> In-Reply-To: <456F37A1.6000502@libero.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Feedback requested: draft-boulton-xcon-uri-00 Thread-Index: AccUuhsnaZV7lc3LTqyiocfCIu1QkwCMh4Yg From: "Even, Roni" To: "Lorenzo Miniero" , X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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, 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. 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. 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 From xcon-bounces@ietf.org Sun Dec 03 10:28:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqtGe-0002xw-Tw; Sun, 03 Dec 2006 10:28:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqtGc-0002xl-Qr for xcon@ietf.org; Sun, 03 Dec 2006 10:28:34 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqtGb-0005D2-DV for xcon@ietf.org; Sun, 03 Dec 2006 10:28:34 -0500 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: Sun, 3 Dec 2006 17:28:28 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C041B2643@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Feedback requested: draft-boulton-xcon-userid-00 Thread-Index: AccUpFkcft+tPN2WS5CCitqMyBURhACSfr5w From: "Even, Roni" To: "Mary Barnes" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 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 Tue Dec 05 15:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrhFQ-00022f-8T; Tue, 05 Dec 2006 15:50:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrhFI-000218-Mo; Tue, 05 Dec 2006 15:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GrhFI-0003SP-DA; Tue, 05 Dec 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 18452175CA; Tue, 5 Dec 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GrhEn-0004XD-M4; Tue, 05 Dec 2006 15:50:01 -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: Tue, 05 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-framework-06.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 : A Framework and Data Model for Centralized Conferencing Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-framework-06.txt Pages : 61 Date : 2006-12-5 This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions, along with a conferencing data model. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-06.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-framework-06.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-framework-06.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: <2006-12-5135400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-framework-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-5135400.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 Tue Dec 05 16:26:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grhnp-0000dz-UV; Tue, 05 Dec 2006 16:26:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grhno-0000cw-5z for xcon@ietf.org; Tue, 05 Dec 2006 16:26:12 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grhnm-0008Pe-ST for xcon@ietf.org; Tue, 05 Dec 2006 16:26:12 -0500 Received: from [172.16.4.30] (adsl-75-53-54-125.dsl.rcsntx.sbcglobal.net [75.53.54.125]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id kB5LQ8Wg002378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Dec 2006 15:26:09 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4575E3EA.3060405@nostrum.com> Date: Tue, 05 Dec 2006 15:26:02 -0600 From: Adam Roach User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: XCON-IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.125 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Mary Barnes , Alan Johnston Subject: [XCON] WGLC: draft-ietf-xcon-framework-06 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 working group chairs are announcing a two-week Working Group Last Call for the XCON Framework Document (draft-ietf-xcon-framework-06), starting today. It will continue until Wednesday, December 20th. http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-06.txt Please send any comments to the XCON mailing list. Thanks! /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Dec 26 14:00:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzHXT-00082Z-DX; Tue, 26 Dec 2006 14:00:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzHXS-00082R-Dw for xcon@ietf.org; Tue, 26 Dec 2006 14:00:38 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzHXQ-0000cZ-0c for xcon@ietf.org; Tue, 26 Dec 2006 14:00:38 -0500 Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBQJ0WQ5008912 for ; Tue, 26 Dec 2006 14:00:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] WGLC: draft-ietf-xcon-framework-06 Date: Tue, 26 Dec 2006 14:00:32 -0500 Message-ID: <6900257941B31D4A954C71DEF805B9A20BB799F4@nj7460avexu2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] WGLC: draft-ietf-xcon-framework-06 Thread-Index: AccYtD0vcEduyTUHTgm305MeD1+TqwQZTXAg From: "Braudes, Robert \(Bob\)" To: "Adam Roach" , "XCON-IETF" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Alan Johnston , Mary Barnes 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 I have two small nits and a few questions and comments. The first nit is that I believe that in Section 8.4, Floor Control, in the last sentence in the fifth paragraph, "conference identifier" is supposed to be "conference user identifier". A related question, which perhaps should be directed to draft-boutlon-xcon-userid-00, is whether conference user IDs are unique across a conferencing system or just within a given conference (and probably sidebars off of that conference). Having the id have a conference scope will allow a user to have different roles for different conferences, distinguished by his/her conference user ID. I can see arguments to implement this either way, and suggest that we leave this up to the policy of the conferencing system. =20 One question is in relation to section 9.4, Sidebar Manipulations. In this section, it is mentioned that no members from outside the parent conference instance can join a sidebar. Given the text in Section 9.4.1 that discusses whether or not "Bob" is a new user of this conferencing system, and the example in 9.4.2 of an External Sidebar, I am assuming that the statement of only allowing members of the parent conference is a local policy decision, and if so then this could be clarified in the draft. Another minor point is that in the examples that include the notification service, the person that initiated the action that caused the notification is not listed as a recipient of the notification. In practice, the event is often sent to all registered listeners, including the listener who triggered the event. In Section 9.5, it may be beneficial to add a note that when Analyst A1 asks his question, other members of the main conference will not hear the question, unless I am missing something. The second nit is that in the fourth paragraph of Section 9.9 it should say "coaching". I apologize in advance if any of these issues have been previously discussed. Bob -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, December 05, 2006 4:26 PM To: XCON-IETF Cc: Mary Barnes; Alan Johnston Subject: [XCON] WGLC: draft-ietf-xcon-framework-06 The working group chairs are announcing a two-week Working Group Last Call for the XCON Framework Document (draft-ietf-xcon-framework-06), starting today. It will continue until Wednesday, December 20th. http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-06.txt Please send any comments to the XCON mailing list. Thanks! /a _______________________________________________ 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 Tue Dec 26 16:08:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzJWh-0004Y4-P4; Tue, 26 Dec 2006 16:07:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzJWg-0004Xz-VU for xcon@ietf.org; Tue, 26 Dec 2006 16:07:58 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzJWf-0003wN-P9 for xcon@ietf.org; Tue, 26 Dec 2006 16:07:58 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id kBQL7vhE024134 for ; Tue, 26 Dec 2006 16:07:57 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBQL7uwP181820 for ; Tue, 26 Dec 2006 16:07:56 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBQL7uju009256 for ; Tue, 26 Dec 2006 16:07:56 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBQL7uSp009251 for ; Tue, 26 Dec 2006 16:07:56 -0500 From: Zon-Yin Shae To: xcon@ietf.org Message-ID: Date: Tue, 26 Dec 2006 16:08:03 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V80_M3_10312006|October 31, 2006) at 12/26/2006 16:08:04 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [XCON] Zon-Yin Shae is out of the office. 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 I will be out of the office starting 12/18/2006 and will not return until 01/02/2007. I will respond to your message when I return. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Dec 28 12:02:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzydh-00023X-CY; Thu, 28 Dec 2006 12:01:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzydf-00022j-3a for xcon@ietf.org; Thu, 28 Dec 2006 12:01:55 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gzydd-0000aA-M3 for xcon@ietf.org; Thu, 28 Dec 2006 12:01:55 -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 kBSH1eP02660; Thu, 28 Dec 2006 12:01:41 -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] WGLC: draft-ietf-xcon-framework-06 Date: Thu, 28 Dec 2006 11:01:25 -0600 Message-ID: In-Reply-To: <6900257941B31D4A954C71DEF805B9A20BB799F4@nj7460avexu2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] WGLC: draft-ietf-xcon-framework-06 Thread-Index: AccYtD0vcEduyTUHTgm305MeD1+TqwQZTXAgAGAVOOA= From: "Mary Barnes" To: "Braudes, Robert \(Bob\)" , "Adam Roach" , "XCON-IETF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Alan Johnston 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 Bob, Thanks for your comments and reviewing the document - responses are embedded below [MB]. Mary -----Original Message----- From: Braudes, Robert (Bob) [mailto:braudes@avaya.com]=20 Sent: Tuesday, December 26, 2006 1:01 PM To: Adam Roach; XCON-IETF Cc: Mary Barnes; Alan Johnston Subject: RE: [XCON] WGLC: draft-ietf-xcon-framework-06 I have two small nits and a few questions and comments. The first nit is that I believe that in Section 8.4, Floor Control, in the last sentence in the fifth paragraph, "conference identifier" is supposed to be "conference user identifier". [MB] Yes, I will fix that.=20 A related question, which perhaps should be directed to draft-boutlon-xcon-userid-00, is whether conference user IDs are unique across a conferencing system or just within a given conference (and probably sidebars off of that conference). Having the id have a conference scope will allow a user to have different roles for different conferences, distinguished by his/her conference user ID. I can see arguments to implement this either way, and suggest that we leave this up to the policy of the conferencing system. =20 [MB] From the text in section 6.3 (and the boulton draft), it seems clear that the conference user identifier is specified to be unique across a conferencing system. I think that's necessary to account for users that aren't participants in an active conference, but that might still be able to manipulate a conference. We didn't, however, include a definition upfront (in section 4) for the Conference User Identifier. =20 I would propose we add a definition like the following to section 4: NEW: Conference User Identifer: A unique identifer for a user within the scope of a conferencing system. =20 [/MB] One question is in relation to section 9.4, Sidebar Manipulations. In this section, it is mentioned that no members from outside the parent conference instance can join a sidebar. Given the text in Section 9.4.1 that discusses whether or not "Bob" is a new user of this conferencing system, and the example in 9.4.2 of an External Sidebar, I am assuming that the statement of only allowing members of the parent conference is a local policy decision, and if so then this could be clarified in the draft. [MB] Yes, the last sentence in the second paragraph of section 9.4 gives as an example a policy that restricts the membership of the sidebar to members of the parent conference and this is provided as an example of an "internal" sidebar in section 9.4.1. So, the text in section 9.4.1 (the last two sentences in the second to last paragraph) should be corrected to reflect that no members from outside the parent conference can join an internal sidebar. I'd propose the following change: OLD: The conferencing system must also validate the updated information in the reservation,=20 ensuring whether members like "Bob" are already a user of this conferencing system=20 or whether he is a new user. If "Bob" is a new user for this conferencing system, a=20 conference user identifier is created for Bob. Based upon the addressing information=20 provided for "Bob" by "Alice", the call signaling to add "Bob" to the conference is=20 instigated through the Focus. =20 NEW:=20 The conferencing system must also validate the updated information in the reservation,=20 ensuring that a member like "Bob" is already a user of this conferencing system.=20 [/MB] Another minor point is that in the examples that include the notification service, the person that initiated the action that caused the notification is not listed as a recipient of the notification. In practice, the event is often sent to all registered listeners, including the listener who triggered the event. [MB] Yes, this is an oversight and it should at least be mentioned that the initiator could also be notified. I propose to change the following statement to account for this (this is (similar to) the last sentence in the last paragraph in sections 9.4.1, 9.4.2 and 9.7): OLD: Depending upon the policies, the participants in the sidebar (i.e., "Bob") may be notified=20 of his addition to the sidebar via the conference notification service.=20 NEW: Depending upon the policies, the initiator of the request (i.e., "Alice") and the=20 participants in the sidebar (i.e., "Bob") may be notified=20 of his addition to the sidebar via the conference notification service.=20 [/MB] In Section 9.5, it may be beneficial to add a note that when Analyst A1 asks his question, other members of the main conference will not hear the question, unless I am missing something. [MB] I think the main conference would hear the question. However, I think the sentence in the paragraph just prior to Figure 14 might have been intended to say that all participants in the main conference receive the audio from the sidebar, as well as the main conference, so I'd propose the following change: OLD: All participants in the sidebar conference receive audio from the main conference. NEW:=20 All participants in the main conference receive audio from the sidebar conference, as well as=20 audio provided by the panelists in the main conference.=20 [/MB] The second nit is that in the fourth paragraph of Section 9.9 it should say "coaching". [MB] Yes, I'll fix that.=20 I apologize in advance if any of these issues have been previously discussed. [MB] No, these are all new points and worth discussing as alot of this is in newer sections and text which had not been reviewed during past detailed reviews. [/MB] Bob -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, December 05, 2006 4:26 PM To: XCON-IETF Cc: Mary Barnes; Alan Johnston Subject: [XCON] WGLC: draft-ietf-xcon-framework-06 The working group chairs are announcing a two-week Working Group Last Call for the XCON Framework Document (draft-ietf-xcon-framework-06), starting today. It will continue until Wednesday, December 20th. http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-06.txt Please send any comments to the XCON mailing list. Thanks! /a _______________________________________________ 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 Sun Dec 31 16:53:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H18cV-0002L1-9N; Sun, 31 Dec 2006 16:53:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H18cU-0002Kv-JK for xcon@ietf.org; Sun, 31 Dec 2006 16:53:30 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H18cS-0007Kq-1X for xcon@ietf.org; Sun, 31 Dec 2006 16:53:30 -0500 Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBVLrQG1022137 for ; Sun, 31 Dec 2006 16:53:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] WGLC: draft-ietf-xcon-framework-06 Date: Sun, 31 Dec 2006 16:53:26 -0500 Message-ID: <6900257941B31D4A954C71DEF805B9A20BBC5D35@nj7460avexu2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] WGLC: draft-ietf-xcon-framework-06 Thread-Index: AccYtD0vcEduyTUHTgm305MeD1+TqwQZTXAgAGAVOOAADdyFUA== From: "Braudes, Robert \(Bob\)" To: "Mary Barnes" , "Adam Roach" , "XCON-IETF" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: Alan Johnston 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 Mary,=20 Thanks for the detailed response. Please see comments below [BB]. Bob -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Thursday, December 28, 2006 12:01 PM To: Braudes, Robert (Bob); Adam Roach; XCON-IETF Cc: Mary Barnes; Alan Johnston Subject: RE: [XCON] WGLC: draft-ietf-xcon-framework-06 Bob, Thanks for your comments and reviewing the document - responses are embedded below [MB]. Mary -----Original Message----- From: Braudes, Robert (Bob) [mailto:braudes@avaya.com] Sent: Tuesday, December 26, 2006 1:01 PM To: Adam Roach; XCON-IETF Cc: Mary Barnes; Alan Johnston Subject: RE: [XCON] WGLC: draft-ietf-xcon-framework-06 I have two small nits and a few questions and comments. The first nit is that I believe that in Section 8.4, Floor Control, in the last sentence in the fifth paragraph, "conference identifier" is supposed to be "conference user identifier". [MB] Yes, I will fix that.=20 A related question, which perhaps should be directed to draft-boutlon-xcon-userid-00, is whether conference user IDs are unique across a conferencing system or just within a given conference (and probably sidebars off of that conference). Having the id have a conference scope will allow a user to have different roles for different conferences, distinguished by his/her conference user ID. I can see arguments to implement this either way, and suggest that we leave this up to the policy of the conferencing system. =20 [MB] From the text in section 6.3 (and the boulton draft), it seems clear that the conference user identifier is specified to be unique across a conferencing system. I think that's necessary to account for users that aren't participants in an active conference, but that might still be able to manipulate a conference. We didn't, however, include a definition upfront (in section 4) for the Conference User Identifier. =20 I would propose we add a definition like the following to section 4: NEW: Conference User Identifer: A unique identifer for a user within the scope of a conferencing system. =20 [/MB] [BB] After giving it additional thought, I didn't word my concern about the Conference User Identifier appropriately. I agree that each ID needs to uniquely identify a single User. What I would like to see is the potential for that User to have multiple identifiers in the Conferencing System, each (potentially) associated with a different set of attributes. =20 This does not have any impact on what you have written above, but you may=20 want to add a statement like=20 "A User MAY have multiple Conference User Identifiers defined within a Conferencing System." [/BB] One question is in relation to section 9.4, Sidebar Manipulations. In this section, it is mentioned that no members from outside the parent conference instance can join a sidebar. Given the text in Section 9.4.1 that discusses whether or not "Bob" is a new user of this conferencing system, and the example in 9.4.2 of an External Sidebar, I am assuming that the statement of only allowing members of the parent conference is a local policy decision, and if so then this could be clarified in the draft. [MB] Yes, the last sentence in the second paragraph of section 9.4 gives as an example a policy that restricts the membership of the sidebar to members of the parent conference and this is provided as an example of an "internal" sidebar in section 9.4.1. So, the text in section 9.4.1 (the last two sentences in the second to last paragraph) should be corrected to reflect that no members from outside the parent conference can join an internal sidebar. I'd propose the following change: OLD: The conferencing system must also validate the updated information in the reservation,=20 ensuring whether members like "Bob" are already a user of this conferencing system=20 or whether he is a new user. If "Bob" is a new user for this conferencing system, a=20 conference user identifier is created for Bob. Based upon the addressing information=20 provided for "Bob" by "Alice", the call signaling to add "Bob" to the conference is=20 instigated through the Focus. =20 NEW:=20 The conferencing system must also validate the updated information in the reservation,=20 ensuring that a member like "Bob" is already a user of this conferencing system.=20 [/MB] [BB] Thanks. [/BB] Another minor point is that in the examples that include the notification service, the person that initiated the action that caused the notification is not listed as a recipient of the notification. In practice, the event is often sent to all registered listeners, including the listener who triggered the event. [MB] Yes, this is an oversight and it should at least be mentioned that the initiator could also be notified. I propose to change the following statement to account for this (this is (similar to) the last sentence in the last paragraph in sections 9.4.1, 9.4.2 and 9.7): OLD: Depending upon the policies, the participants in the sidebar (i.e., "Bob") may be notified=20 of his addition to the sidebar via the conference notification service.=20 NEW: Depending upon the policies, the initiator of the request (i.e., "Alice") and the=20 participants in the sidebar (i.e., "Bob") may be notified=20 of his addition to the sidebar via the conference notification service.=20 [/MB] [BB] Thanks again. [/BB] In Section 9.5, it may be beneficial to add a note that when Analyst A1 asks his question, other members of the main conference will not hear the question, unless I am missing something. [MB] I think the main conference would hear the question. However, I think the sentence in the paragraph just prior to Figure 14 might have been intended to say that all participants in the main conference receive the audio from the sidebar, as well as the main conference, so I'd propose the following change: OLD: All participants in the sidebar conference receive audio from the main conference. NEW:=20 All participants in the main conference receive audio from the sidebar conference, as well as=20 audio provided by the panelists in the main conference.=20 [/MB] [BB] I agree that this will work given the constraints of the usage of this=20 sidebar, where only the Analyst asking the question has the floor. [/BB] The second nit is that in the fourth paragraph of Section 9.9 it should say "coaching". [MB] Yes, I'll fix that.=20 I apologize in advance if any of these issues have been previously discussed. [MB] No, these are all new points and worth discussing as alot of this is in newer sections and text which had not been reviewed during past detailed reviews. [/MB] Bob -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, December 05, 2006 4:26 PM To: XCON-IETF Cc: Mary Barnes; Alan Johnston Subject: [XCON] WGLC: draft-ietf-xcon-framework-06 The working group chairs are announcing a two-week Working Group Last Call for the XCON Framework Document (draft-ietf-xcon-framework-06), starting today. It will continue until Wednesday, December 20th. http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-06.txt Please send any comments to the XCON mailing list. Thanks! /a _______________________________________________ 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