From xcon-bounces@ietf.org Mon May 01 11:32:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaaNc-0007GQ-1E; Mon, 01 May 2006 11:32:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaaNb-0007GL-BX for xcon@ietf.org; Mon, 01 May 2006 11:32:07 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaaNa-0007Mh-1v for xcon@ietf.org; Mon, 01 May 2006 11:32:07 -0400 Received: from [192.168.0.102] (ppp-70-242-116-27.dsl.rcsntx.swbell.net [70.242.116.27]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.4) with ESMTP id k41FW5wE086290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 May 2006 10:32:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <445629EF.3030607@nostrum.com> Date: Mon, 01 May 2006 10:31:59 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en 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: 70.242.116.27 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Alan Johnston Subject: [XCON] IETF 65: Feedback Needed 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 [as chair] In an effort to improve the experience of meeting participants, the secretariat is requesting that all IETF participants -- including those who did not actually attend the Dallas meeting in person -- please fill out the following survey. As a personal aside, we had one of these after IETF 64, and the secretariat (in my opinion) did a pretty good job of acting on the feedback they received. Participating in the survey really is an effective way to change things you don't like and keep things that you do. http://www.surveymonkey.com/s.asp?u=649182049947 /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue May 02 02:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaoLN-0001JE-VO; Tue, 02 May 2006 02:26:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaoLN-0001J9-B4 for xcon@ietf.org; Tue, 02 May 2006 02:26:45 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaoLM-0001Se-GD for xcon@ietf.org; Tue, 02 May 2006 02:26:45 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 11D614F0001; Tue, 2 May 2006 08:26:43 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 08:26:42 +0200 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 08:26:42 +0200 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] Proposed small fixes to BFCP Date: Tue, 2 May 2006 08:26:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Proposed small fixes to BFCP Thread-Index: AcZrGtxM1uUsranfRs+CnDVGUyFXDAClYGDw From: "Oscar Novo \(JO/LMF\)" To: "Adam Roach" , "Gonzalo Camarillo \(JO/LMF\)" X-OriginalArrivalTime: 02 May 2006 06:26:42.0580 (UTC) FILETIME=[60B5BD40:01C66DB1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: Joerg Ott , Keith Drage , alan@sipstation.com, XCON 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 Hello, I think the solution is good but I have a question about the ChairAction operation: NEW: ChairAction =3D (COMMON-HEADER) 1*(FLOOR-REQUEST-STATUS) (FLOOR-REQUEST-ID) [STATUS-INFO] *[EXTENSION-ATTRIBUTE] =20 Why this operation does not use the OVERALL-REQUEST-STATUS attribute as well to refer to positions in a global queue? NEW PROPOSAL: ChairAction =3D (COMMON-HEADER) [OVERALL-REQUEST-STATUS] <-- 1*[FLOOR-REQUEST-STATUS] (FLOOR-REQUEST-ID) [STATUS-INFO] *[EXTENSION-ATTRIBUTE] Cheers, Oscar -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: 29. huhtikuuta 2006 2:27 To: Gonzalo Camarillo (JO/LMF) Cc: Joerg Ott; Keith Drage; alan@sipstation.com; XCON Subject: Re: [XCON] Proposed small fixes to BFCP I was hoping to hear more from working group members before making the decision -- but it appears that no one has any comments one way or the other on the issue. I'll discuss with our AD and try to determine the best way to move forward. /a Gonzalo Camarillo wrote: > Adam, Alan, > > I would like to, at least, get the "go ahead" from the chairs... > > Thanks, > > Gonzalo > > Gonzalo Camarillo wrote: >> Folks, >> >> while implementing our BFCP stack (the 'running code' part of the=20 >> protocol), we have discovered a couple of relatively minor bugs in=20 >> the BFCP spec that need to be fixed. They are probably too big to be=20 >> fixed thru RFC editor notes. My suggestion would be to remove the=20 >> draft from the queue, perform the changes I propose below, and send=20 >> it back to the queue. Opinions? >> >> >> Section 5.3.9 defines the ChairAction message. That message can=20 >> contain several floors (which belong to the same floor request >> operation) but can only provide a single queue position (within the=20 >> REQUEST-STATUS attribute) for all of them. We need to be able to=20 >> provide different queue positions for different floors (e.g., second=20 >> for floor 1 and third for floor 2). In order to do this, we need to=20 >> define a new grouped attribute called FLOOR-REQUEST-STATUS whose=20 >> definition would be the following: >> >> Attribute header: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |x x x x x x x|M| Length | Floor ID | >> =20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Attribute ABNF: >> >> FLOOR-REQUEST-STATUS =3D (FLOOR-REQUEST-STATUS-HEADER) >> (REQUEST-STATUS) >> [STATUS-INFO] >> *[EXTENSION-ATTRIBUTE] >> >> Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute >> would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)' >> >> The same for the already existing ChairAction message. >> >> >> Additionally, we would define a new grouped attribute called=20 >> OVERALL-REQUEST-STATUS, whose definition would be almost identical to >> the FLOOR-REQUEST-STATUS attribute. The only difference is that this=20 >> one would carry a Floor Request ID instead of a Floor ID. This=20 >> attribute would be used within the FLOOR-REQUEST-INFORMATION=20 >> attribute, whose ABNF would become: >> >> OLD: >> >> FLOOR-REQUEST-INFORMATION =3D (FLOOR-REQUEST-INFORMATION-HEADER) >> (REQUEST-STATUS) <-- >> 1*(FLOOR-ID) <-- >> [BENEFICIARY-INFORMATION] >> [REQUESTED-BY-INFORMATION] >> [PRIORITY] >> [PARTICIPANT-PROVIDED-INFO] >> [STATUS-INFO] <-- >> *[EXTENSION-ATTRIBUTE] >> >> NEW: >> >> FLOOR-REQUEST-INFORMATION =3D (FLOOR-REQUEST-INFORMATION-HEADER) >> (OVERALL-REQUEST-STATUS) >> 1*(FLOOR-REQUEST-STATUS) >> [BENEFICIARY-INFORMATION] >> [REQUESTED-BY-INFORMATION] >> [PRIORITY] >> [PARTICIPANT-PROVIDED-INFO] >> *[EXTENSION-ATTRIBUTE] >> >> >> >> Then, we would need to add a brief discussion on queues, indicating=20 >> that the queue positions in the OVERALL-REQUEST-STATUS attribute=20 >> refer to positions in a global queue for floor requests and that=20 >> queue positions in the FLOOR-REQUEST-STATUS attribute refer to=20 >> positions in a queue for floor requests for a particular floor. Of=20 >> course, implementations are free to implement (or provide information >> about) one, both, or none of these queue types. >> >> The ChairAction message would become: >> >> OLD: >> >> ChairAction =3D (COMMON-HEADER) >> 1*(FLOOR-ID) <-- >> (FLOOR-REQUEST-ID) >> (REQUEST-STATUS) <-- >> [STATUS-INFO] >> *[EXTENSION-ATTRIBUTE] >> >> NEW: >> >> ChairAction =3D (COMMON-HEADER) >> 1*(FLOOR-REQUEST-STATUS) >> (FLOOR-REQUEST-ID) >> [STATUS-INFO] >> *[EXTENSION-ATTRIBUTE] >> >> >> A different issue (more easily fixable than the issue above) is that=20 >> the FloorRequest and the FloorQuery messages should carry >> 1*(FLOOR-ID) instead of *(FLOOR-ID). >> >> Cheers, >> >> Gonzalo >> _______________________________________________ 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 May 02 06:12:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Farrj-0008HE-94; Tue, 02 May 2006 06:12:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Farri-0008H9-9X for xcon@ietf.org; Tue, 02 May 2006 06:12:22 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Farrg-0003CA-Gd for xcon@ietf.org; Tue, 02 May 2006 06:12:22 -0400 Received: from rly14b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly14b.srv.mailcontrol.com (MailControl) with ESMTP id k42ACBhG003021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 May 2006 11:12:13 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly14b.srv.mailcontrol.com (MailControl) id k42AC8sv002952 for xcon@ietf.org; Tue, 2 May 2006 11:12:08 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly14b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k42AC5vl002838; Tue, 02 May 2006 11:12:08 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 May 2006 11:12:06 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE03118A0A@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of Control Framework - draft-boulton-sip-control-framework-02 Thread-Index: AcZtziIuiRLD+2H/TQ2T08bO6Km86QAAF/Mg From: "Chris Boulton" To: "XCON-IETF" X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.66.1.124 X-Spam-Score: 1.1 (+) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 Cc: Asher Shiratzky , Tim Melanchuk , "McGlashan, Scott" Subject: [XCON] FW: New version of Control Framework - draft-boulton-sip-control-framework-02 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: , Content-Type: multipart/mixed; boundary="===============0854057734==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0854057734== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66DD0.DD5C9569" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66DD0.DD5C9569 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 As detailed in the mail below, a new version of the Control Framework (for use in media server control) has been released - this work is being discussed on the 'Media Control (Mediactrl)' mailing list. I have included the list details below for anyone who wishes to comment. =20 Best Regards, =20 Chris. =20 Instructions:- =20 - generate a mail to majordomo@lists.ubiquitysoftware.com - place text 'subscribe mediactrl' in the body of the message (plain text) - Follow remaining on-screen instructions to confirm list subscription =20 All subsequent mails need to be sent to mediactrl@lists.ubiquitysoftware.com =20 =20 I have also set up an archive, which can be found at:- =20 http://www.ubiquitysoftware.com/archives/ =20 =20 -----Original Message----- From: Chris Boulton=20 Sent: 02 May 2006 10:52 To: mediactrl@lists.ubiquitysoftware.com Cc: 'McGlashan, Scott'; Tim Melanchuk; 'Asher Shiratzky' Subject: New version of Control Framework - draft-boulton-sip-control-framework-02 =20 Hi all, =20 A new version of the SIP Control Framework has been submitted. Until it appears in the archives it can be retrieved from the following links:- =20 http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework -02.txt =20 http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework -02.html =20 Changes include a new mechanism for control channel and SIP dialog association + a detailed call flow. The authors would appreciate as much feedback as possible to help consolidate this version. =20 Best Regards, =20 Chris. =20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. ------_=_NextPart_001_01C66DD0.DD5C9569 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

As detailed in the mail below, a new version of the Control Framework (for use in media server control) has been released – this work is being discussed on the ‘Media Control (= Mediactrl)’ mailing list.  I have included the list details below for anyone who wishes to comment.

 

Best Regards,

 

Chris.

 

Instructions:-

 

-   &nb= sp;      generate a mail to majordomo@lists.ubiqui= tysoftware.com

-   &nb= sp;      place text 'subscribe mediactrl' in the body of the mess= age (plain text)

-   &nb= sp;      Follow remaining on-screen instructions to confirm list subscription

 

All subsequent ma= ils need to be sent to media= ctrl@lists.ubiquitysoftware.com

 

 

I have also set up an archive, which can be found at:-

 

http://www.ubiquitysoftware.com/archives/

 

 

-----Original Message-----
From: Chris Boulton
Sent: 02= May 2006= 10:52=
To: mediactrl@lists.ubiquitysoftware.com
Cc: 'McGlashan, Scott'; Tim Melanchuk; 'Asher Shiratzky'
Subject: New version of Cont= rol Framework - draft-boulton-sip-control-framework-02

 

Hi all,

 

A new version of the SIP Control Framework has be= en submitted.  Until it appears in the archives it can be retrieved from = the following links:-

 

http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-contro= l-framework-02.txt

 

http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-contr= ol-framework-02.html

 

Changes include a new mechanism for control chann= el and SIP dialog association + a detailed call flow.  The authors would appreciate as much feedback as possible to help consolidate this version.

 

Best Regards,

 

Chris.

 



Information contained in t= his e-mail and any attachments are intended for the use of the addressee on= ly, and may contain confidential information of Ubiquity Software Corporati= on. All unauthorized use, disclosure or distribution is strictly prohibited= .  If you are not the addressee, please notify the sender immediately = and destroy all copies of this email.  Unless otherwise expressly agre= ed in writing signed by an officer of Ubiquity Software Corporation, nothin= g in this communication shall be deemed to be legally binding. Thank-you ------_=_NextPart_001_01C66DD0.DD5C9569-- --===============0854057734== 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 --===============0854057734==-- From xcon-bounces@ietf.org Tue May 02 19:20:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4Ac-0007E8-H4; Tue, 02 May 2006 19:20:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4Ab-0007Dr-GA for xcon@ietf.org; Tue, 02 May 2006 19:20:41 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4AZ-0005xM-4S for xcon@ietf.org; Tue, 02 May 2006 19:20:41 -0400 Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.4) with ESMTP id k42NKbX1013225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 May 2006 18:20:38 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4457E945.5050409@nostrum.com> Date: Tue, 02 May 2006 18:20:37 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: XCON-IETF X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [XCON] Control Values and 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 In a recent discussion that the XCON operations document editors were having, an interesting issue arose. It's not clear to me that we have given a lot of thought to this issue, so I'd like to see what opinions the working group has on the topic: The current view of the data model as described in the framework is that we have a common conference portion (based primarily on the schema given in draft-ietf-sipping-conference-package-12); and we have a template portion (such as those described in draft-boulton-xcon-media-template-02). Eliding a lot of information, this leads us to a breakdown of information roughly along the lines of: participant audio video Now, here's the interesting issue: where, if anywhere, does this document represent what the specific value for Bob's gain for his AudioOut channel is? With the current structure: * It can't go in the Template portion, since the template has entries for each role, not for each user. In other words, it has precisely one "Participant" section, even though there can be multiple participants. * It can't go in the Common portion, since that part of the document is defined to not change regardless of the template in use. Because of this, I don't think we can start putting control values specific to the template up there. I can think of two ways to handle this, although there may be more: 1. Add yet another section to the document, associated with the template part, that basically forms the cross product of each user and their relevant controls. In other words, add a section like: ... 2. Don't include the literal control values in the document. Instead, clients can use the list of user devices and the roles associated with them to ascertain which controls are valid for which user/endpoint/media-stream combination. Then, the control values could be explicitly queried and set by the operations protocol. As an example, the XML document representing the conference state would never include the value of my "gain" control -- but you could learn what it was by issuing a command that basically said "query user=sip:adam@estacado.net, device=sip:adam@123.45.67.8, stream=AudioOut, control=gain". Thoughts? /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed May 03 12:51:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKZO-0003Ha-NO; Wed, 03 May 2006 12:51:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKZM-0003DY-T2 for xcon@ietf.org; Wed, 03 May 2006 12:51:20 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbKZI-00086g-AF for xcon@ietf.org; Wed, 03 May 2006 12:51:20 -0400 Received: from rly06b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly06b.srv.mailcontrol.com (MailControl) with ESMTP id k43GpFbi027974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 May 2006 17:51:15 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly06b.srv.mailcontrol.com (MailControl) id k43Gp2BD027822 for xcon@ietf.org; Wed, 3 May 2006 17:51:02 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly06b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k43Gp1Xl027785; Wed, 03 May 2006 17:51:02 +0100 (BST) 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" Subject: RE: [XCON] Control Values and the Data Model Date: Wed, 3 May 2006 17:51:01 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE03118A10@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Control Values and the Data Model Thread-Index: AcZuPw18b8S/27LkTcSzDwZW5wH9BQAkg1dw From: "Chris Boulton" To: "Adam Roach" , "XCON-IETF" X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.66.1.116 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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 Now, here's the interesting issue: where, if anywhere, does this document represent what the specific value for Bob's gain for his AudioOut channel is? [CJB] Adam - I'm a bit confused (doesn't take much :-). This is taken from the 02 version of the templates (http://www.ietf.org/internet-drafts/draft-boulton-xcon-media-template-0 2.txt):=20 1.0 As you can see we had a 'value' element that represents the gain. It can't go in the Template portion, since the template has entries for each role, not for each user. In other words, it has precisely one "Participant" section, even though there can be multiple participants. [CJB] But each participant will have a relevant view of the template - indicating there own particular gain. The Conference server will have a view of all participants and there relevant conference view. Chris. -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: 03 May 2006 00:21 To: XCON-IETF Subject: [XCON] Control Values and the Data Model In a recent discussion that the XCON operations document editors were having, an interesting issue arose. It's not clear to me that we have given a lot of thought to this issue, so I'd like to see what opinions the working group has on the topic: The current view of the data model as described in the framework is that we have a common conference portion (based primarily on the schema given in draft-ietf-sipping-conference-package-12); and we have a template portion (such as those described in draft-boulton-xcon-media-template-02). Eliding a lot of information, this leads us to a breakdown of information roughly along the lines of: participant audio video Now, here's the interesting issue: where, if anywhere, does this document represent what the specific value for Bob's gain for his AudioOut channel is? With the current structure: * It can't go in the Template portion, since the template has entries for each role, not for each user. In other words, it has precisely one "Participant" section, even though there can be multiple participants. * It can't go in the Common portion, since that part of the document is defined to not change regardless of the template in use. Because of this, I don't think we can start putting control values specific to the template up there. I can think of two ways to handle this, although there may be more: 1. Add yet another section to the document, associated with the template part, that basically forms the cross product of each user and their relevant controls. In other words, add a section like: ... 2. Don't include the literal control values in the document. Instead, clients can use the list of user devices and the roles associated with them to ascertain which controls are valid for which user/endpoint/media-stream combination. Then, the control values could be explicitly queried and set by the operations protocol. As an example, the XML document representing the conference state would never include the value of my "gain" control -- but you could learn what it was by issuing a command that basically said "query user=3Dsip:adam@estacado.net, device=3Dsip:adam@123.45.67.8, stream=3DAudioOut, control=3Dgain". Thoughts? /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed May 03 14:37:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbMEI-0002ip-J1; Wed, 03 May 2006 14:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbMEH-0002ik-MB for xcon@ietf.org; Wed, 03 May 2006 14:37:41 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbMEH-0004y5-6g for xcon@ietf.org; Wed, 03 May 2006 14:37:41 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FbMDy-0001xF-Aq; Wed, 03 May 2006 13:37:23 -0500 From: "Brian Rosen" To: "'Chris Boulton'" , "'Adam Roach'" , "'XCON-IETF'" Subject: RE: [XCON] Control Values and the Data Model Date: Wed, 3 May 2006 14:37:24 -0400 Message-ID: <022d01c66ee0$a1dcce50$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZuPw18b8S/27LkTcSzDwZW5wH9BQAkg1dwAAOWPdA= In-Reply-To: <45730E094814E44488F789C1CDED27AE03118A10@gbnewp0758m.eu.ubiquity.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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 I think I understand Adam's concern. If the conference state is represented by the conference object, then the template part of the object needs a branch for every participant (in the role) so that an authorized entity can read or set the value of Bob's gain different from Alice's gain. Sure, Bob may only see his own value, but the moderator may be able to see everyone's. I think this is pretty much tied to the protocol. The protocol can have a concept of a complex key (user+device+control), which doesn't imply that the object itself has branches for user and device. As I said in a previous message, I'm not so sure now, having reflected on the subject, that getting away from the central notion that the conference state is defined as an object with a schema that is part common and part template, and manipulating conference state is directly manipulating said object is a good idea. The "functional" protocol idea DOES get away from that notion; it imposes a different view of conference state which is not the conference object and provides methods that act on that view. If we were to get back to that notion (conference state = object state), then the object would indeed need branches for user and possibly device, which would change the template definition. We could then argue whether it was user.device.control or control.user.device (that is, which are the leaves and which are the main branches of the tree?) I don't think putting the controls into the common part of the object (which does have participant branches) is wise. Brian -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net] Sent: Wednesday, May 03, 2006 12:51 PM To: Adam Roach; XCON-IETF Subject: RE: [XCON] Control Values and the Data Model Now, here's the interesting issue: where, if anywhere, does this document represent what the specific value for Bob's gain for his AudioOut channel is? [CJB] Adam - I'm a bit confused (doesn't take much :-). This is taken from the 02 version of the templates (http://www.ietf.org/internet-drafts/draft-boulton-xcon-media-template-0 2.txt): 1.0 As you can see we had a 'value' element that represents the gain. It can't go in the Template portion, since the template has entries for each role, not for each user. In other words, it has precisely one "Participant" section, even though there can be multiple participants. [CJB] But each participant will have a relevant view of the template - indicating there own particular gain. The Conference server will have a view of all participants and there relevant conference view. Chris. -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: 03 May 2006 00:21 To: XCON-IETF Subject: [XCON] Control Values and the Data Model In a recent discussion that the XCON operations document editors were having, an interesting issue arose. It's not clear to me that we have given a lot of thought to this issue, so I'd like to see what opinions the working group has on the topic: The current view of the data model as described in the framework is that we have a common conference portion (based primarily on the schema given in draft-ietf-sipping-conference-package-12); and we have a template portion (such as those described in draft-boulton-xcon-media-template-02). Eliding a lot of information, this leads us to a breakdown of information roughly along the lines of: participant audio video Now, here's the interesting issue: where, if anywhere, does this document represent what the specific value for Bob's gain for his AudioOut channel is? With the current structure: * It can't go in the Template portion, since the template has entries for each role, not for each user. In other words, it has precisely one "Participant" section, even though there can be multiple participants. * It can't go in the Common portion, since that part of the document is defined to not change regardless of the template in use. Because of this, I don't think we can start putting control values specific to the template up there. I can think of two ways to handle this, although there may be more: 1. Add yet another section to the document, associated with the template part, that basically forms the cross product of each user and their relevant controls. In other words, add a section like: ... 2. Don't include the literal control values in the document. Instead, clients can use the list of user devices and the roles associated with them to ascertain which controls are valid for which user/endpoint/media-stream combination. Then, the control values could be explicitly queried and set by the operations protocol. As an example, the XML document representing the conference state would never include the value of my "gain" control -- but you could learn what it was by issuing a command that basically said "query user=sip:adam@estacado.net, device=sip:adam@123.45.67.8, stream=AudioOut, control=gain". Thoughts? /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank you. _______________________________________________ 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 Wed May 03 17:02:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbOUh-0002L8-BF; Wed, 03 May 2006 17:02:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbOUg-0002L3-AC for xcon@ietf.org; Wed, 03 May 2006 17:02:46 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbOUf-0002y5-HH for xcon@ietf.org; Wed, 03 May 2006 17:02:46 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k43L2d5B013051; Thu, 4 May 2006 00:02:40 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 00:02:06 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 16:01:46 -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] Control Values and the Data Model Date: Wed, 3 May 2006 16:01:46 -0500 Message-ID: <815E2AF6A087FF45A68EF2F310ADE11101C63383@daebe102.NOE.Nokia.com> In-Reply-To: <022d01c66ee0$a1dcce50$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Control Values and the Data Model Thread-Index: AcZuPw18b8S/27LkTcSzDwZW5wH9BQAkg1dwAAOWPdAABOlkAA== From: To: , , , X-OriginalArrivalTime: 03 May 2006 21:01:46.0893 (UTC) FILETIME=[CA21DBD0:01C66EF4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 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, In the template draft, we had defined an element called controlArray which is basically a control set on set of streams. From the basic-audio template, for the moderator role we have=20 False The intention of this element is to have the moderator the capability to mute the stream going to the participant. Of course what we are missing in this XML is the identification of the user (or device) and we will add that, but the point is the moderator can have the capability to set the values of the controls for each and every participant in the conference.=20 Umesh >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Wednesday, May 03, 2006 1:37 PM >To: 'Chris Boulton'; 'Adam Roach'; 'XCON-IETF' >Subject: RE: [XCON] Control Values and the Data Model > >I think I understand Adam's concern. If the conference state=20 >is represented by the conference object, then the template=20 >part of the object needs a branch for every participant (in=20 >the role) so that an authorized entity can read or set the=20 >value of Bob's gain different from Alice's gain. Sure, Bob=20 >may only see his own value, but the moderator may be able to=20 >see everyone's. > >I think this is pretty much tied to the protocol. The=20 >protocol can have a concept of a complex key=20 >(user+device+control), which doesn't imply that the object=20 >itself has branches for user and device. > >As I said in a previous message, I'm not so sure now, having=20 >reflected on the subject, that getting away from the central=20 >notion that the conference state is defined as an object with=20 >a schema that is part common and part template, and=20 >manipulating conference state is directly manipulating said=20 >object is a good idea. The "functional" protocol idea DOES=20 >get away from that notion; it imposes a different view of=20 >conference state which is not the conference object and=20 >provides methods that act on that view. > >If we were to get back to that notion (conference state =3D=20 >object state), then the object would indeed need branches for=20 >user and possibly device, which would change the template=20 >definition. We could then argue whether it was=20 >user.device.control or control.user.device (that is, which are=20 >the leaves and which are the main branches of the tree?) > >I don't think putting the controls into the common part of the=20 >object (which does have participant branches) is wise. > >Brian > >-----Original Message----- >From: Chris Boulton [mailto:cboulton@ubiquity.net] >Sent: Wednesday, May 03, 2006 12:51 PM >To: Adam Roach; XCON-IETF >Subject: RE: [XCON] Control Values and the Data Model > > > Now, here's the interesting issue: where, if anywhere, does this > document represent what the specific value for Bob's gain for >his > AudioOut channel is? > >[CJB] Adam - I'm a bit confused (doesn't take much :-). This is taken >from the 02 version of the templates >(http://www.ietf.org/internet-drafts/draft-boulton-xcon-media-t >emplate-0 >2.txt):=20 > > > > enable=3D"true" >> > > 1.0 > > > >As you can see we had a 'value' element that represents the gain. > > > It can't go in the Template portion, since the template has > entries for each role, not for each user. In other words, it has > precisely one "Participant" section, even though there can be > multiple participants. > >[CJB] But each participant will have a relevant view of the template - >indicating there own particular gain. The Conference server=20 >will have a >view of all participants and there relevant conference view. > >Chris. > > >-----Original Message----- >From: Adam Roach [mailto:adam@nostrum.com]=20 >Sent: 03 May 2006 00:21 >To: XCON-IETF >Subject: [XCON] Control Values and the Data Model > >In a recent discussion that the XCON operations document editors were >having, an interesting issue arose. It's not clear to me that we have >given a lot of thought to this issue, so I'd like to see what opinions >the working group has on the topic: > >The current view of the data model as described in the=20 >framework is that >we have a common conference portion (based primarily on the=20 >schema given >in draft-ietf-sipping-conference-package-12); and we have a template >portion (such as those described in >draft-boulton-xcon-media-template-02). > >Eliding a lot of information, this leads us to a breakdown of >information roughly along the lines of: > > > > > > > > participant > > > > audio > > > video > > > > > > > > > > > > >Now, here's the interesting issue: where, if anywhere, does this >document represent what the specific value for Bob's gain for his >AudioOut channel is? > >With the current structure: > > * It can't go in the Template portion, since the template has > entries for each role, not for each user. In other words, it has > precisely one "Participant" section, even though there can be > multiple participants. > > * It can't go in the Common portion, since that part of=20 >the document > is defined to not change regardless of the template in use. > Because of this, I don't think we can start putting=20 >control values > specific to the template up there. > >I can think of two ways to handle this, although there may be more: > > 1. Add yet another section to the document, associated with the > template part, that basically forms the cross product of=20 >each user > and their relevant controls. In other words, add a section like: > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > 2. Don't include the literal control values in the=20 >document. Instead, > clients can use the list of user devices and the roles associated > with them to ascertain which controls are valid for which > user/endpoint/media-stream combination. Then, the control values > could be explicitly queried and set by the operations=20 >protocol. As > an example, the XML document representing the conference state > would never include the value of my "gain" control -- but you > could learn what it was by issuing a command that basically said > "query user=3Dsip:adam@estacado.net, = device=3Dsip:adam@123.45.67.8, > stream=3DAudioOut, control=3Dgain". > > >Thoughts? > >/a > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon > > >Information contained in this e-mail and any attachments are=20 >intended for >the use of the addressee only, and may contain confidential=20 >information of >Ubiquity Software Corporation. All unauthorized use, disclosure or >distribution is strictly prohibited. If you are not the=20 >addressee, please >notify the sender immediately and destroy all copies of this=20 >email. Unless >otherwise expressly agreed in writing signed by an officer of Ubiquity >Software Corporation, nothing in this communication shall be=20 >deemed to be >legally binding. Thank you. > > >_______________________________________________ >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 > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed May 03 17:10:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbOcD-0001He-Ny; Wed, 03 May 2006 17:10:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbOcC-0001HU-RG for xcon@ietf.org; Wed, 03 May 2006 17:10:32 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbOcA-00034X-7r for xcon@ietf.org; Wed, 03 May 2006 17:10:32 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FbObt-0004jS-31; Wed, 03 May 2006 16:10:14 -0500 From: "Brian Rosen" To: , , , Subject: RE: [XCON] Control Values and the Data Model Date: Wed, 3 May 2006 17:10:17 -0400 Message-ID: <029601c66ef5$fc8c8bf0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZuPw18b8S/27LkTcSzDwZW5wH9BQAkg1dwAAOWPdAABOlkAAAAnT7w In-Reply-To: <815E2AF6A087FF45A68EF2F310ADE11101C63383@daebe102.NOE.Nokia.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 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 If I am following you, this control is ONLY available to moderators. I don't think that is the kind of thing we should be encouraging. I also don't think using the "LogicalStream" construction as a stand-In for the actual stream is a good idea. I really think the mute is a control on the user's "MainAudioOut" stream, defined under the participant role. It's available to him, and it's available to any entity the permissions allow. We need a way to address it. Brian -----Original Message----- From: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] Sent: Wednesday, May 03, 2006 5:02 PM To: br@brianrosen.net; cboulton@ubiquity.net; adam@nostrum.com; xcon@ietf.org Subject: RE: [XCON] Control Values and the Data Model Hi, In the template draft, we had defined an element called controlArray which is basically a control set on set of streams. From the basic-audio template, for the moderator role we have False The intention of this element is to have the moderator the capability to mute the stream going to the participant. Of course what we are missing in this XML is the identification of the user (or device) and we will add that, but the point is the moderator can have the capability to set the values of the controls for each and every participant in the conference. Umesh >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: Wednesday, May 03, 2006 1:37 PM >To: 'Chris Boulton'; 'Adam Roach'; 'XCON-IETF' >Subject: RE: [XCON] Control Values and the Data Model > >I think I understand Adam's concern. If the conference state >is represented by the conference object, then the template >part of the object needs a branch for every participant (in >the role) so that an authorized entity can read or set the >value of Bob's gain different from Alice's gain. Sure, Bob >may only see his own value, but the moderator may be able to >see everyone's. > >I think this is pretty much tied to the protocol. The >protocol can have a concept of a complex key >(user+device+control), which doesn't imply that the object >itself has branches for user and device. > >As I said in a previous message, I'm not so sure now, having >reflected on the subject, that getting away from the central >notion that the conference state is defined as an object with >a schema that is part common and part template, and >manipulating conference state is directly manipulating said >object is a good idea. The "functional" protocol idea DOES >get away from that notion; it imposes a different view of >conference state which is not the conference object and >provides methods that act on that view. > >If we were to get back to that notion (conference state = >object state), then the object would indeed need branches for >user and possibly device, which would change the template >definition. We could then argue whether it was >user.device.control or control.user.device (that is, which are >the leaves and which are the main branches of the tree?) > >I don't think putting the controls into the common part of the >object (which does have participant branches) is wise. > >Brian > >-----Original Message----- >From: Chris Boulton [mailto:cboulton@ubiquity.net] >Sent: Wednesday, May 03, 2006 12:51 PM >To: Adam Roach; XCON-IETF >Subject: RE: [XCON] Control Values and the Data Model > > > Now, here's the interesting issue: where, if anywhere, does this > document represent what the specific value for Bob's gain for >his > AudioOut channel is? > >[CJB] Adam - I'm a bit confused (doesn't take much :-). This is taken >from the 02 version of the templates >(http://www.ietf.org/internet-drafts/draft-boulton-xcon-media-t >emplate-0 >2.txt): > > > > enable="true" >> > > 1.0 > > > >As you can see we had a 'value' element that represents the gain. > > > It can't go in the Template portion, since the template has > entries for each role, not for each user. In other words, it has > precisely one "Participant" section, even though there can be > multiple participants. > >[CJB] But each participant will have a relevant view of the template - >indicating there own particular gain. The Conference server >will have a >view of all participants and there relevant conference view. > >Chris. > > >-----Original Message----- >From: Adam Roach [mailto:adam@nostrum.com] >Sent: 03 May 2006 00:21 >To: XCON-IETF >Subject: [XCON] Control Values and the Data Model > >In a recent discussion that the XCON operations document editors were >having, an interesting issue arose. It's not clear to me that we have >given a lot of thought to this issue, so I'd like to see what opinions >the working group has on the topic: > >The current view of the data model as described in the >framework is that >we have a common conference portion (based primarily on the >schema given >in draft-ietf-sipping-conference-package-12); and we have a template >portion (such as those described in >draft-boulton-xcon-media-template-02). > >Eliding a lot of information, this leads us to a breakdown of >information roughly along the lines of: > > > > > > > > participant > > > > audio > > > video > > > > > > > > > > > > >Now, here's the interesting issue: where, if anywhere, does this >document represent what the specific value for Bob's gain for his >AudioOut channel is? > >With the current structure: > > * It can't go in the Template portion, since the template has > entries for each role, not for each user. In other words, it has > precisely one "Participant" section, even though there can be > multiple participants. > > * It can't go in the Common portion, since that part of >the document > is defined to not change regardless of the template in use. > Because of this, I don't think we can start putting >control values > specific to the template up there. > >I can think of two ways to handle this, although there may be more: > > 1. Add yet another section to the document, associated with the > template part, that basically forms the cross product of >each user > and their relevant controls. In other words, add a section like: > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > 2. Don't include the literal control values in the >document. Instead, > clients can use the list of user devices and the roles associated > with them to ascertain which controls are valid for which > user/endpoint/media-stream combination. Then, the control values > could be explicitly queried and set by the operations >protocol. As > an example, the XML document representing the conference state > would never include the value of my "gain" control -- but you > could learn what it was by issuing a command that basically said > "query user=sip:adam@estacado.net, device=sip:adam@123.45.67.8, > stream=AudioOut, control=gain". > > >Thoughts? > >/a > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon > > >Information contained in this e-mail and any attachments are >intended for >the use of the addressee only, and may contain confidential >information of >Ubiquity Software Corporation. All unauthorized use, disclosure or >distribution is strictly prohibited. If you are not the >addressee, please >notify the sender immediately and destroy all copies of this >email. Unless >otherwise expressly agreed in writing signed by an officer of Ubiquity >Software Corporation, nothing in this communication shall be >deemed to be >legally binding. Thank you. > > >_______________________________________________ >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 > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed May 03 21:41:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbSpu-0005VL-Hd; Wed, 03 May 2006 21:40:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbSps-0005VG-9n for xcon@ietf.org; Wed, 03 May 2006 21:40:56 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbSpq-0006Xp-Rz for xcon@ietf.org; Wed, 03 May 2006 21:40:56 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k441eoHU029719; Thu, 4 May 2006 04:40:50 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 04:40:11 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 20:40:08 -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] Control Values and the Data Model Date: Wed, 3 May 2006 20:40:06 -0500 Message-ID: <815E2AF6A087FF45A68EF2F310ADE11101C6368D@daebe102.NOE.Nokia.com> In-Reply-To: <029601c66ef5$fc8c8bf0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Control Values and the Data Model Thread-Index: AcZuPw18b8S/27LkTcSzDwZW5wH9BQAkg1dwAAOWPdAABOlkAAAAnT7wAAk2s3A= From: To: , , , X-OriginalArrivalTime: 04 May 2006 01:40:08.0641 (UTC) FILETIME=[AD265B10:01C66F1B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 =20 >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Wednesday, May 03, 2006 4:10 PM >To: Chandra Umesh (Nokia-NRC/Dallas); cboulton@ubiquity.net;=20 >adam@nostrum.com; xcon@ietf.org >Subject: RE: [XCON] Control Values and the Data Model > >If I am following you, this control is ONLY available to moderators. >I don't think that is the kind of thing we should be encouraging. >I also don't think using the "LogicalStream" construction as a=20 >stand-In for the actual stream is a good idea. > >I really think the mute is a control on the user's=20 >"MainAudioOut" stream, defined under the participant role. =20 >It's available to him, and it's available to any entity the=20 >permissions allow. We need a way to address it. > Yes the control (to mute outoging stream of all the participants) is given only to moderator role. If I understand correctly the basis for classification for roles is the privileges each role is assigned. So for a basic audio template an moderator (or any other role name which we want to use) would have the privilge to mute the audio streams of all the participants. Anyways we have to define in the templates what roles are being specified for this conference and what controls are available in each role. Are you suggesting that the privilges (or permissions) assigned to each role would change during the course of the conference ? Umesh _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu May 04 02:18:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbXAP-0007zT-Fw; Thu, 04 May 2006 02:18:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbX43-0006lt-PQ for xcon@ietf.org; Thu, 04 May 2006 02:11:51 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbWqK-0008Gq-O0 for xcon@ietf.org; Thu, 04 May 2006 01:57:42 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DE01E4F0040; Thu, 4 May 2006 07:57:37 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 07:57:37 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 07:57:37 +0200 Received: from [131.160.126.8] (rvi2-126-8.lmf.ericsson.se [131.160.126.8]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E4851254B; Thu, 4 May 2006 08:57:36 +0300 (EEST) Message-ID: <445997D0.8030007@ericsson.com> Date: Thu, 04 May 2006 08:57:36 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Oscar Novo (JO/LMF)" Subject: Re: [XCON] Proposed small fixes to BFCP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2006 05:57:37.0428 (UTC) FILETIME=[A5582D40:01C66F3F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: Joerg Ott , alan@sipstation.com, Keith Drage , Adam Roach , XCON 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 Oscar, yes, we will also allow the chair to specify an overall queue position for the floor request. Thanks, Gonzalo Oscar Novo (JO/LMF) wrote: > Hello, > > I think the solution is good but I have a question about the ChairAction > operation: > > NEW: > > ChairAction = (COMMON-HEADER) > 1*(FLOOR-REQUEST-STATUS) > (FLOOR-REQUEST-ID) > [STATUS-INFO] > *[EXTENSION-ATTRIBUTE] > > > Why this operation does not use the OVERALL-REQUEST-STATUS attribute as > well to refer to positions in a global queue? > > NEW PROPOSAL: > > ChairAction = (COMMON-HEADER) > [OVERALL-REQUEST-STATUS] <-- > 1*[FLOOR-REQUEST-STATUS] > (FLOOR-REQUEST-ID) > [STATUS-INFO] > *[EXTENSION-ATTRIBUTE] > > Cheers, > > Oscar > > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 29. huhtikuuta 2006 2:27 > To: Gonzalo Camarillo (JO/LMF) > Cc: Joerg Ott; Keith Drage; alan@sipstation.com; XCON > Subject: Re: [XCON] Proposed small fixes to BFCP > > I was hoping to hear more from working group members before making the > decision -- but it appears that no one has any comments one way or the > other on the issue. I'll discuss with our AD and try to determine the > best way to move forward. > > /a > > Gonzalo Camarillo wrote: >> Adam, Alan, >> >> I would like to, at least, get the "go ahead" from the chairs... >> >> Thanks, >> >> Gonzalo >> >> Gonzalo Camarillo wrote: >>> Folks, >>> >>> while implementing our BFCP stack (the 'running code' part of the >>> protocol), we have discovered a couple of relatively minor bugs in >>> the BFCP spec that need to be fixed. They are probably too big to be >>> fixed thru RFC editor notes. My suggestion would be to remove the >>> draft from the queue, perform the changes I propose below, and send >>> it back to the queue. Opinions? >>> >>> >>> Section 5.3.9 defines the ChairAction message. That message can >>> contain several floors (which belong to the same floor request >>> operation) but can only provide a single queue position (within the >>> REQUEST-STATUS attribute) for all of them. We need to be able to >>> provide different queue positions for different floors (e.g., second >>> for floor 1 and third for floor 2). In order to do this, we need to >>> define a new grouped attribute called FLOOR-REQUEST-STATUS whose >>> definition would be the following: >>> >>> Attribute header: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |x x x x x x x|M| Length | Floor ID > | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Attribute ABNF: >>> >>> FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) >>> (REQUEST-STATUS) >>> [STATUS-INFO] >>> *[EXTENSION-ATTRIBUTE] >>> >>> Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute > >>> would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)' >>> >>> The same for the already existing ChairAction message. >>> >>> >>> Additionally, we would define a new grouped attribute called >>> OVERALL-REQUEST-STATUS, whose definition would be almost identical to > >>> the FLOOR-REQUEST-STATUS attribute. The only difference is that this >>> one would carry a Floor Request ID instead of a Floor ID. This >>> attribute would be used within the FLOOR-REQUEST-INFORMATION >>> attribute, whose ABNF would become: >>> >>> OLD: >>> >>> FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) >>> (REQUEST-STATUS) <-- >>> 1*(FLOOR-ID) <-- >>> [BENEFICIARY-INFORMATION] >>> [REQUESTED-BY-INFORMATION] >>> [PRIORITY] >>> [PARTICIPANT-PROVIDED-INFO] >>> [STATUS-INFO] <-- >>> *[EXTENSION-ATTRIBUTE] >>> >>> NEW: >>> >>> FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) >>> (OVERALL-REQUEST-STATUS) >>> 1*(FLOOR-REQUEST-STATUS) >>> [BENEFICIARY-INFORMATION] >>> [REQUESTED-BY-INFORMATION] >>> [PRIORITY] >>> [PARTICIPANT-PROVIDED-INFO] >>> *[EXTENSION-ATTRIBUTE] >>> >>> >>> >>> Then, we would need to add a brief discussion on queues, indicating >>> that the queue positions in the OVERALL-REQUEST-STATUS attribute >>> refer to positions in a global queue for floor requests and that >>> queue positions in the FLOOR-REQUEST-STATUS attribute refer to >>> positions in a queue for floor requests for a particular floor. Of >>> course, implementations are free to implement (or provide information >>> about) one, both, or none of these queue types. >>> >>> The ChairAction message would become: >>> >>> OLD: >>> >>> ChairAction = (COMMON-HEADER) >>> 1*(FLOOR-ID) <-- >>> (FLOOR-REQUEST-ID) >>> (REQUEST-STATUS) <-- >>> [STATUS-INFO] >>> *[EXTENSION-ATTRIBUTE] >>> >>> NEW: >>> >>> ChairAction = (COMMON-HEADER) >>> 1*(FLOOR-REQUEST-STATUS) >>> (FLOOR-REQUEST-ID) >>> [STATUS-INFO] >>> *[EXTENSION-ATTRIBUTE] >>> >>> >>> A different issue (more easily fixable than the issue above) is that >>> the FloorRequest and the FloorQuery messages should carry >>> 1*(FLOOR-ID) instead of *(FLOOR-ID). >>> >>> Cheers, >>> >>> Gonzalo >>> > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu May 04 09:18:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbdiz-00021G-1g; Thu, 04 May 2006 09:18:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbdix-00021B-Ci for xcon@ietf.org; Thu, 04 May 2006 09:18:31 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbdiv-0002fd-2r for xcon@ietf.org; Thu, 04 May 2006 09:18:31 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fbdid-0001H8-2R; Thu, 04 May 2006 08:18:11 -0500 From: "Brian Rosen" To: , , , Subject: RE: [XCON] Control Values and the Data Model Date: Thu, 4 May 2006 09:18:12 -0400 Message-ID: <03b501c66f7d$33d0b9b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZuPw18b8S/27LkTcSzDwZW5wH9BQAkg1dwAAOWPdAABOlkAAAAnT7wAAk2s3AAGIsOcA== In-Reply-To: <815E2AF6A087FF45A68EF2F310ADE11101C6368D@daebe102.NOE.Nokia.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 I don't think we really need to change permissions during a conference, but I don't think it's very difficult to allow it. I think that you need a permission system to be able to define who gets to view and/or change what. I think, for example, in most systems, you can get a roster, but you won't be able to see the details of all the streams each participant is sending or getting from the mixer. I do think that some controls will be available only to participants in a role. The example you are using (mute) is not a good one, because the user needs to control his own mute, and moderated conferences need the ability for the moderator to control it. I can even imagine defining a floor, where getting the floor changes the state of the mutes automatically. Brian -----Original Message----- From: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] Sent: Wednesday, May 03, 2006 9:40 PM To: br@brianrosen.net; cboulton@ubiquity.net; adam@nostrum.com; xcon@ietf.org Subject: RE: [XCON] Control Values and the Data Model >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: Wednesday, May 03, 2006 4:10 PM >To: Chandra Umesh (Nokia-NRC/Dallas); cboulton@ubiquity.net; >adam@nostrum.com; xcon@ietf.org >Subject: RE: [XCON] Control Values and the Data Model > >If I am following you, this control is ONLY available to moderators. >I don't think that is the kind of thing we should be encouraging. >I also don't think using the "LogicalStream" construction as a >stand-In for the actual stream is a good idea. > >I really think the mute is a control on the user's >"MainAudioOut" stream, defined under the participant role. >It's available to him, and it's available to any entity the >permissions allow. We need a way to address it. > Yes the control (to mute outoging stream of all the participants) is given only to moderator role. If I understand correctly the basis for classification for roles is the privileges each role is assigned. So for a basic audio template an moderator (or any other role name which we want to use) would have the privilge to mute the audio streams of all the participants. Anyways we have to define in the templates what roles are being specified for this conference and what controls are available in each role. Are you suggesting that the privilges (or permissions) assigned to each role would change during the course of the conference ? Umesh _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu May 04 09:32:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbdw3-00059Q-4P; Thu, 04 May 2006 09:32:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbdw1-00059K-62 for xcon@ietf.org; Thu, 04 May 2006 09:32:01 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbdvz-0003mm-Ni for xcon@ietf.org; Thu, 04 May 2006 09:32:01 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k44DVrNl009544; Thu, 4 May 2006 16:31:55 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 16:31:52 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 08:31:49 -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] Control Values and the Data Model Date: Thu, 4 May 2006 08:31:46 -0500 Message-ID: <815E2AF6A087FF45A68EF2F310ADE11101C63935@daebe102.NOE.Nokia.com> In-Reply-To: <03b501c66f7d$33d0b9b0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Control Values and the Data Model Thread-Index: AcZuPw18b8S/27LkTcSzDwZW5wH9BQAkg1dwAAOWPdAABOlkAAAAnT7wAAk2s3AAGIsOcAAATZcQ From: To: , , , X-OriginalArrivalTime: 04 May 2006 13:31:49.0238 (UTC) FILETIME=[18B06160:01C66F7F] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 inline as [UC} >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net]=20 >Sent: Thursday, May 04, 2006 8:18 AM >To: Chandra Umesh (Nokia-NRC/Dallas); cboulton@ubiquity.net;=20 >adam@nostrum.com; xcon@ietf.org >Subject: RE: [XCON] Control Values and the Data Model > >I don't think we really need to change permissions during a=20 >conference, but I don't think it's very difficult to allow it.=20 > I think that you need a permission system to be able to=20 >define who gets to view and/or change what. [UC} But then how do we indicate the change of the permissions in the template. The template is defining roles and in roles we are defining certain controls that are availble for that particular role. So if a template says that control foo is available only to a role of creator, then it is available only to the role of creator and not any other role. > >I think, for example, in most systems, you can get a roster,=20 >but you won't be able to see the details of all the streams=20 >each participant is sending or getting from the mixer. > >I do think that some controls will be available only to=20 >participants in a role. The example you are using (mute) is=20 >not a good one, because the user needs to control his own=20 >mute, and moderated conferences need the ability for the=20 >moderator to control it. I can even imagine defining a floor,=20 >where getting the floor changes the state of the mutes automatically. > >Brian > [UC} The control Mute is applicable not only to the participant role (the participant can mute its stream so as the moderator). We have defined the controlArray element in the moderator role section where the idea is to have the moderator be able to mute the streams of all the participants in the conference. And I do agree with your earlier comment that logicalstream might not be a good idea. We are planning to change that. BR Umesh _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu May 04 09:49:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeCO-0001WM-8k; Thu, 04 May 2006 09:48:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeCM-0001WH-FU for xcon@ietf.org; Thu, 04 May 2006 09:48:54 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbeCM-0004h6-6M for xcon@ietf.org; Thu, 04 May 2006 09:48:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FbeBs-00032d-T3; Thu, 04 May 2006 08:48:25 -0500 From: "Brian Rosen" To: , , , Subject: RE: [XCON] Control Values and the Data Model Date: Thu, 4 May 2006 09:48:25 -0400 Message-ID: <03c001c66f81$6d0d2480$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZuPw18b8S/27LkTcSzDwZW5wH9BQAkg1dwAAOWPdAABOlkAAAAnT7wAAk2s3AAGIsOcAAATZcQAADOILA= In-Reply-To: <815E2AF6A087FF45A68EF2F310ADE11101C63935@daebe102.NOE.Nokia.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 -----Original Message----- From: Umesh.Chandra@nokia.com [mailto:Umesh.Chandra@nokia.com] Sent: Thursday, May 04, 2006 9:32 AM To: br@brianrosen.net; cboulton@ubiquity.net; adam@nostrum.com; xcon@ietf.org Subject: RE: [XCON] Control Values and the Data Model inline as [UC} >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: Thursday, May 04, 2006 8:18 AM >To: Chandra Umesh (Nokia-NRC/Dallas); cboulton@ubiquity.net; >adam@nostrum.com; xcon@ietf.org >Subject: RE: [XCON] Control Values and the Data Model > >I don't think we really need to change permissions during a >conference, but I don't think it's very difficult to allow it. > I think that you need a permission system to be able to >define who gets to view and/or change what. [UC} But then how do we indicate the change of the permissions in the template. The template is defining roles and in roles we are defining certain controls that are availble for that particular role. So if a template says that control foo is available only to a role of creator, then it is available only to the role of creator and not any other role.
well, "available to" is problematic. It's defined ON the role; only people in the role have one. There is another question of who gets to view and/or change it. That's different from who owns it. > >I think, for example, in most systems, you can get a roster, >but you won't be able to see the details of all the streams >each participant is sending or getting from the mixer. > >I do think that some controls will be available only to >participants in a role. The example you are using (mute) is >not a good one, because the user needs to control his own >mute, and moderated conferences need the ability for the >moderator to control it. I can even imagine defining a floor, >where getting the floor changes the state of the mutes automatically. > >Brian > [UC} The control Mute is applicable not only to the participant role (the participant can mute its stream so as the moderator). We have defined the controlArray element in the moderator role section where the idea is to have the moderator be able to mute the streams of all the participants in the conference. And I do agree with your earlier comment that logicalstream might not be a good idea. We are planning to change that.
But then you have two controls that do exactly the same thing, and the user can't see the moderator's control. Would it not be better to have one control, and change who can set it? Brian _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu May 04 10:12:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeZR-0002n1-AC; Thu, 04 May 2006 10:12:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeZP-0002lv-IE for xcon@ietf.org; Thu, 04 May 2006 10:12:43 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbeZP-00059m-3a for xcon@ietf.org; Thu, 04 May 2006 10:12:43 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k44ECaqj004739; Thu, 4 May 2006 17:12:39 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 17:12:29 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 09:12:27 -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] Control Values and the Data Model Date: Thu, 4 May 2006 09:12:26 -0500 Message-ID: <815E2AF6A087FF45A68EF2F310ADE11101C63AB7@daebe102.NOE.Nokia.com> In-Reply-To: <03c001c66f81$6d0d2480$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Control Values and the Data Model Thread-Index: AcZuPw18b8S/27LkTcSzDwZW5wH9BQAkg1dwAAOWPdAABOlkAAAAnT7wAAk2s3AAGIsOcAAATZcQAADOILAAAKl6wA== From: To: , , , X-OriginalArrivalTime: 04 May 2006 14:12:27.0119 (UTC) FILETIME=[C5C77FF0:01C66F84] X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 =20 >[UC} But then how do we indicate the change of the permissions=20 >in the template. The template is defining roles and in roles=20 >we are defining certain controls that are availble for that=20 >particular role. So if a template says that control foo is=20 >available only to a role of creator, then it is available only=20 >to the role of creator and not any other role. > >
well, "available to" is problematic. It's defined ON the=20 >role; only people in the role have one. There is another=20 >question of who gets to view and/or change it. That's=20 >different from who owns it. > [UC] What I mean by "available" is that particular role owns it and can view it and change it. I quite didn't understand your distinction of owning the control and be able to view/change it. If a control is defined in a particular role, then the participant has to have that role to use that control. >[UC} The control Mute is applicable not only to the=20 >participant role (the participant can mute its stream so as=20 >the moderator). We have defined the controlArray element in=20 >the moderator role section where the idea is to have the=20 >moderator be able to mute the streams of all the participants=20 >in the conference. And I do agree with your earlier comment=20 >that logicalstream might not be a good idea. We are planning=20 >to change that. > >
But then you have two controls that do exactly the same=20 >thing, and the user can't see the moderator's control.=20 > >Would it not be better to have one control, and change who can set it? > >Brian > > [UC] But do we really want the user to know what controls are avaialable to the moderator. If we take the Mute example, you would want the moderator to have the control since it can mute the participant from the mix, if it not following the conference rules. At that same time you would want to have the control available to the user too... _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu May 11 19:18:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeKQA-00012i-Cn; Thu, 11 May 2006 19:18:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeKQ9-00012E-I3 for xcon@ietf.org; Thu, 11 May 2006 19:18:13 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeKQ8-0003h0-9q for xcon@ietf.org; Thu, 11 May 2006 19:18:13 -0400 Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.4) with ESMTP id k4BNIB3J036820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 May 2006 18:18:11 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4463C62D.1020107@nostrum.com> Date: Thu, 11 May 2006 18:18:05 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: XCON-IETF X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [XCON] 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 [as chair] As a reminder, the working group has a milestone for the data model in July. In discussions with people to date, it has become extremely apparent that people have a lot of opinions on the data model as it currently exists. I ask everyone participating in the working group to please take the time to look over the data model and provide feedback, even if that feedback is, "I think the current data model document is complete, and I'm happy with it." http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-00.txt Thanks. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri May 12 03:44:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeSKM-0000cR-9I; Fri, 12 May 2006 03:44:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeSKK-0000cM-9u for xcon@ietf.org; Fri, 12 May 2006 03:44:44 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeSKH-0002N9-Jc for xcon@ietf.org; Fri, 12 May 2006 03:44:44 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B54B64F0003 for ; Fri, 12 May 2006 09:44:28 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 09:44:28 +0200 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 09:44:28 +0200 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] Data Model Date: Fri, 12 May 2006 09:40:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Data Model Thread-Index: AcZ1UX04nZ9zX4zdRlCmnPL/8iz4RgARmBxA From: "Oscar Novo \(JO/LMF\)" To: "XCON-IETF" X-OriginalArrivalTime: 12 May 2006 07:44:28.0490 (UTC) FILETIME=[E5F09AA0:01C67597] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Thanks Adam, I would appreciate all your comments in the draft to work in the next version. Still I am waiting for some people that in the last IETF promise to me their comments in the draft. Thanks, Oscar=20 -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: 12. toukokuuta 2006 2:18 To: XCON-IETF Subject: [XCON] Data Model [as chair] As a reminder, the working group has a milestone for the data model in July. In discussions with people to date, it has become extremely apparent that people have a lot of opinions on the data model as it currently exists. I ask everyone participating in the working group to please take the time to look over the data model and provide feedback, even if that feedback is, "I think the current data model document is complete, and I'm happy with it." http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-00 .txt 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 Sat May 20 01:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhKM1-0007MO-UU; Sat, 20 May 2006 01:50:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhKM0-0007MJ-Ts for xcon@ietf.org; Sat, 20 May 2006 01:50:20 -0400 Received: from mail1.microsoft.com ([131.107.1.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhKLz-0007Iy-CE for xcon@ietf.org; Sat, 20 May 2006 01:50:20 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 22:50:18 -0700 Received: from RED-MSG-71.redmond.corp.microsoft.com ([157.54.62.18]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 22:50:18 -0700 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] Data Model Date: Fri, 19 May 2006 22:41:47 -0700 Message-ID: In-Reply-To: <4463C62D.1020107@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Data Model thread-index: AcZ1Ugpu0LmAFDekTZCnOORVH4JjSQGdtLXg From: "Srivatsa Srinivasan" To: "Adam Roach" , "XCON-IETF" X-OriginalArrivalTime: 20 May 2006 05:50:18.0413 (UTC) FILETIME=[4647CDD0:01C67BD1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f 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 Here are comments for the data model draft-ietf-xcon-common-data-model-00. This email incorporates comments from Sean Olson as well. What follows are some points to be addressed, in general, throughout the document followed by section-by-section comments.=20 There are inconsistencies between text, schema and examples for certain XML elements appearing throughout the document. That is, they are defined in text, but not in the schema or defined in the examples but not in the text or schema and such. Also, the document needs to be very clear as to what the keys are for XML elements appearing in sequences. Need to be consistently explicit about which top-level elements are mandatory and which are not (in text, rather than relying on schema definition). It would be useful to also indicate which elements make sense at conference creation time and which at conference run time. For readability, it may be beneficial to indicate, in text, which parts of the document are actually extensible rather than relying on the central text for XML extensibility through namespaces.=20 No clear indication is given as to how the system/client learns of supported values for specific enumerations or features in a conferencing system (see below 8.)? Surely, a conferencing system may not support all that is defined in this data model, correct?=20 We also need to work through the details of and elements for a user/endpoint in this document as templates also define similar concepts. So the following comments will NOT be going over those elements as these have been brought up elsewhere. 1. Section 3.2 appears to be in text and examples, but isn't in the schema definition. It also seems too limiting to just support four values. The implied FSM also is wrong. How is this any different than ? 2. Section 3.2 seems redundant, why not just use with defined ? 3. Section 3.2.2 and Section 3.2.3, There is no need for and type of to be changed/redefined from what is defined in conference event package. Why not just use the URI schema plus element and make it consistent across all the possible URI types? 4. Section 3.2.2 doesn't belong here and it is not defined in [2]. The restriction on a maximum of 6 phone numbers is also arbitrary. Without some corresponding label or purpose, it will be hard to tell or describe to the user which phone number to use. Multiple PIN codes should be supported at a minimum. Alternatively, one may remove this element for it to appear elsewhere in description or text. Remove any reference to H.320 bonding from the document as it is not necessary and is currently under-specified as to how this will work. 5. Section 3.2.5 The child of is too limiting -- we need to be able to express all the a=3D attributes in SDP that may accompany a codec if we are to say anything interesting about video codecs. 6. Section 3.5 Please remove entirely. It serves no useful purpose from either an organize-time or run-time perspective. 7. Section 3.6 Do floors and floor policies really belong here if floor controls are in templates? What is the key? Does template refer to floors defined here? Examples show attribute 'label' for but schema doesn't. 8. Section 3.7 What if the conferencing system does not support on a per-user setting, how is it conveyed? What if only a subset of joining methods is supported by the system (how would the client know what to choose from the UI)? Would an organizer have to try all possible choices before choosing the one that is supported for a given user? What about extensibility here? Same applies to other lists and features. 9. Section 3.7 Make explicitly fall under an admission-policy element. Also, the schema does not appear to define this element. Rename to something more meaningful: like 'closedAuthenticated' when users must be specified (and authenticated) and 'openAuthenticated' when users can be added after conference activation. =09 =09 10. Section 3.7.1.1 Can we cut for the first version of the model? This can be achieved through simpler operations without complicating the data model itself =20 11. Section 3.7.2 What does a domain mean in the ? (How do you enumerate the entities to dial out to?) =20 12. Section 3.7.2 Why differentiate between and ? It's clear that the Focus will act differently, just don't see the need to explicitly control this difference in behavior. This seems more reasonable to leave up to the implementation.=20 13. Section 3.7.2 , and can be restructured and combined into one list. That is, have a list with all users in it and then enlist allowed joining-method's referencing the available or supported joining-methods in the conferencing system. Make it extensible to support an 'auto' joining method to accomplish previous comment in (12).=20 14. Section 3.7.4 The seems too generic to be implemented in a reasonably interoperable fashion. It also seems to bloat the data model. Also, the conditions are ambiguous in several cases. For example, (section 3.7.4.2.1.10) may be meaningless in many conferences. How would this condition be interpreted in a conference that has no notion of passcodes? 15. Section 3.7.5 The element is too limiting ...Digest/Digest-AKA do not even begin to scratch the surface of possibilities. Perhaps more importantly, there is no use-case for this being in the data model at all as it may be derived from other elements like and/or . 16. There are several elements in the document that may require role-based definitions. For example, take . An organizer may want one set of service uri entries for presenters, but a *different* set of entries for attendees. Similarly, in some cases, one may want to display different display-text based on whether the user is a presenter or the user is an attendee. How would one achieve that?=20 17. Minor XML schema point: when defining XML elements and their types in schema, it's generally better to use the full name followed by a "-type" to remain consistent. In the schema definition for the data model, this has inconsistently been followed. For example: and elsewhere as Srivatsa > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, May 11, 2006 4:18 PM > To: XCON-IETF > Subject: [XCON] Data Model >=20 > [as chair] >=20 > As a reminder, the working group has a milestone for the data model in > July. In discussions with people to date, it has become extremely > apparent that people have a lot of opinions on the data model as it > currently exists. >=20 > I ask everyone participating in the working group to please take the > time to look over the data model and provide feedback, even if that > feedback is, "I think the current data model document is complete, and > I'm happy with it." >=20 > http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model- > 00.txt >=20 > Thanks. >=20 > /a >=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 Sat May 20 12:35:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhUPf-0008Im-G5; Sat, 20 May 2006 12:34:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhUPe-0008Ih-Fa for xcon@ietf.org; Sat, 20 May 2006 12:34:46 -0400 Received: from mail2.microsoft.com ([131.107.1.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhUPd-0002cf-6S for xcon@ietf.org; Sat, 20 May 2006 12:34:46 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 May 2006 09:34:42 -0700 Received: from RED-MSG-71.redmond.corp.microsoft.com ([157.54.62.18]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 May 2006 09:34:41 -0700 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] Data Model Date: Sat, 20 May 2006 09:27:10 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Data Model thread-index: AcZ1Ugpu0LmAFDekTZCnOORVH4JjSQGdtLXgABhNlCA= From: "Srivatsa Srinivasan" To: "Adam Roach" , "XCON-IETF" X-OriginalArrivalTime: 20 May 2006 16:34:41.0952 (UTC) FILETIME=[4B8BAA00:01C67C2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Typo corrected... > 9. Section 3.7 Make explicitly fall under an > admission-policy element. Also, the schema does not appear to define > this element. Rename to something more meaningful: like > 'closedAuthenticated' when users must be specified (and authenticated) > and 'openAuthenticated' when users can be added after conference > activation. >=20 > type=3D"tns:admission-policy-type"/> >=20 > > > > > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu May 25 03:01:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj9q8-0007na-Qg; Thu, 25 May 2006 03:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj9q7-0007n1-Fy for xcon@ietf.org; Thu, 25 May 2006 03:00:59 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj9py-0004hQ-M2 for xcon@ietf.org; Thu, 25 May 2006 03:00:59 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B3D434F0001; Thu, 25 May 2006 09:00:36 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 09:00:36 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 09:00:35 +0200 Received: from [131.160.126.90] (rvi2-126-90.lmf.ericsson.se [131.160.126.90]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0377A28CA; Thu, 25 May 2006 10:00:35 +0300 (EEST) Message-ID: <44755612.9020509@ericsson.com> Date: Thu, 25 May 2006 10:00:34 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Adam Roach Subject: Re: [XCON] Proposed small fixes to BFCP References: <4448DFAC.9080009@ericsson.com> <4451CC4B.7000801@ericsson.com> <4452A4C9.6010304@nostrum.com> In-Reply-To: <4452A4C9.6010304@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2006 07:00:35.0933 (UTC) FILETIME=[EC2F08D0:01C67FC8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: Joerg Ott , Keith Drage , alan@sipstation.com, XCON 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, here you have a new revision of the draft addressing the issues I discussed in my previous email: http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-07.txt http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-06-to-07.html Note that this revision will not be submitted until, as Adam pointed out, we discuss with our AD. Cheers, Gonzalo Adam Roach wrote: > I was hoping to hear more from working group members before making the > decision -- but it appears that no one has any comments one way or the > other on the issue. I'll discuss with our AD and try to determine the > best way to move forward. > > /a > > Gonzalo Camarillo wrote: >> Adam, Alan, >> >> I would like to, at least, get the "go ahead" from the chairs... >> >> Thanks, >> >> Gonzalo >> >> Gonzalo Camarillo wrote: >>> Folks, >>> >>> while implementing our BFCP stack (the 'running code' part of the >>> protocol), we have discovered a couple of relatively minor bugs in >>> the BFCP spec that need to be fixed. They are probably too big to be >>> fixed thru RFC editor notes. My suggestion would be to remove the >>> draft from the queue, perform the changes I propose below, and send >>> it back to the queue. Opinions? >>> >>> >>> Section 5.3.9 defines the ChairAction message. That message can >>> contain several floors (which belong to the same floor request >>> operation) but can only provide a single queue position (within the >>> REQUEST-STATUS attribute) for all of them. We need to be able to >>> provide different queue positions for different floors (e.g., second >>> for floor 1 and third for floor 2). In order to do this, we need to >>> define a new grouped attribute called FLOOR-REQUEST-STATUS whose >>> definition would be the following: >>> >>> Attribute header: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |x x x x x x x|M| Length | Floor ID | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Attribute ABNF: >>> >>> FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) >>> (REQUEST-STATUS) >>> [STATUS-INFO] >>> *[EXTENSION-ATTRIBUTE] >>> >>> Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute >>> would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)' >>> >>> The same for the already existing ChairAction message. >>> >>> >>> Additionally, we would define a new grouped attribute called >>> OVERALL-REQUEST-STATUS, whose definition would be almost identical to >>> the FLOOR-REQUEST-STATUS attribute. The only difference is that this >>> one would carry a Floor Request ID instead of a Floor ID. This >>> attribute would be used within the FLOOR-REQUEST-INFORMATION >>> attribute, whose ABNF would become: >>> >>> OLD: >>> >>> FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) >>> (REQUEST-STATUS) <-- >>> 1*(FLOOR-ID) <-- >>> [BENEFICIARY-INFORMATION] >>> [REQUESTED-BY-INFORMATION] >>> [PRIORITY] >>> [PARTICIPANT-PROVIDED-INFO] >>> [STATUS-INFO] <-- >>> *[EXTENSION-ATTRIBUTE] >>> >>> NEW: >>> >>> FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) >>> (OVERALL-REQUEST-STATUS) >>> 1*(FLOOR-REQUEST-STATUS) >>> [BENEFICIARY-INFORMATION] >>> [REQUESTED-BY-INFORMATION] >>> [PRIORITY] >>> [PARTICIPANT-PROVIDED-INFO] >>> *[EXTENSION-ATTRIBUTE] >>> >>> >>> >>> Then, we would need to add a brief discussion on queues, indicating >>> that the queue positions in the OVERALL-REQUEST-STATUS attribute >>> refer to positions in a global queue for floor requests and that >>> queue positions in the FLOOR-REQUEST-STATUS attribute refer to >>> positions in a queue for floor requests for a particular floor. Of >>> course, implementations are free to implement (or provide information >>> about) one, both, or none of these queue types. >>> >>> The ChairAction message would become: >>> >>> OLD: >>> >>> ChairAction = (COMMON-HEADER) >>> 1*(FLOOR-ID) <-- >>> (FLOOR-REQUEST-ID) >>> (REQUEST-STATUS) <-- >>> [STATUS-INFO] >>> *[EXTENSION-ATTRIBUTE] >>> >>> NEW: >>> >>> ChairAction = (COMMON-HEADER) >>> 1*(FLOOR-REQUEST-STATUS) >>> (FLOOR-REQUEST-ID) >>> [STATUS-INFO] >>> *[EXTENSION-ATTRIBUTE] >>> >>> >>> A different issue (more easily fixable than the issue above) is that >>> the FloorRequest and the FloorQuery messages should carry >>> 1*(FLOOR-ID) instead of *(FLOOR-ID). >>> >>> Cheers, >>> >>> Gonzalo >>> > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu May 25 20:27:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjQB4-00028L-R3; Thu, 25 May 2006 20:27:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjQB3-00028G-7y for xcon@ietf.org; Thu, 25 May 2006 20:27:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjP1Q-0003f9-1h for xcon@ietf.org; Thu, 25 May 2006 19:13:40 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjOVO-0007Ir-4R for xcon@ietf.org; Thu, 25 May 2006 18:40:35 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 25 May 2006 15:40:19 -0700 X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="283188730:sNHT1913962518" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k4PMeJUQ023265; Thu, 25 May 2006 15:40:19 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4PMeIsF006216; Thu, 25 May 2006 15:40:19 -0700 (PDT) Received: from [192.168.1.2] ([10.21.88.94]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 15:40:18 -0700 In-Reply-To: <44755612.9020509@ericsson.com> References: <4448DFAC.9080009@ericsson.com> <4451CC4B.7000801@ericsson.com> <4452A4C9.6010304@nostrum.com> <44755612.9020509@ericsson.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <52DDC543-88BC-47CD-AEC1-297D4D79C2EB@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [XCON] Proposed small fixes to BFCP Date: Thu, 25 May 2006 15:40:15 -0700 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 25 May 2006 22:40:18.0428 (UTC) FILETIME=[32C503C0:01C6804C] DKIM-Signature: a=rsa-sha1; q=dns; l=6130; t=1148596819; x=1149460819; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[XCON]=20Proposed=20small=20fixes=20to=20BFCP; X=v=3Dcisco.com=3B=20h=3DytXuLj9MSFypv5//3LLcD6iOuts=3D; b=YOXDG8t7u7dCOohdplxwd9WXMS998WxtfDcA3R3EjY3d9myYHUYfQUCHNy+5FlqWgM+7Z1f0 AdRhI0BoJp9a1KhS99RNSW2FYFUJB6IGrF19QFIW/JLZ9DoAKKceM4W4; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.4 (--) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Joerg Ott , alan@sipstation.com, Keith Drage , Adam Roach , XCON 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 Let me know if anyone see significant problems with these changes. In the mean time I will work with authors and RFC editor to figure out best way to get them done. Cullen On May 25, 2006, at 12:00 AM, Gonzalo Camarillo wrote: > Hi, > > here you have a new revision of the draft addressing the issues I > discussed in my previous email: > > http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-07.txt > http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-06-to-07.html > > Note that this revision will not be submitted until, as Adam > pointed out, we discuss with our AD. > > Cheers, > > Gonzalo > > Adam Roach wrote: >> I was hoping to hear more from working group members before making >> the >> decision -- but it appears that no one has any comments one way or >> the >> other on the issue. I'll discuss with our AD and try to determine the >> best way to move forward. >> /a >> Gonzalo Camarillo wrote: >>> Adam, Alan, >>> >>> I would like to, at least, get the "go ahead" from the chairs... >>> >>> Thanks, >>> >>> Gonzalo >>> >>> Gonzalo Camarillo wrote: >>>> Folks, >>>> >>>> while implementing our BFCP stack (the 'running code' part of the >>>> protocol), we have discovered a couple of relatively minor bugs in >>>> the BFCP spec that need to be fixed. They are probably too big >>>> to be >>>> fixed thru RFC editor notes. My suggestion would be to remove the >>>> draft from the queue, perform the changes I propose below, and send >>>> it back to the queue. Opinions? >>>> >>>> >>>> Section 5.3.9 defines the ChairAction message. That message can >>>> contain several floors (which belong to the same floor request >>>> operation) but can only provide a single queue position (within the >>>> REQUEST-STATUS attribute) for all of them. We need to be able to >>>> provide different queue positions for different floors (e.g., >>>> second >>>> for floor 1 and third for floor 2). In order to do this, we need to >>>> define a new grouped attribute called FLOOR-REQUEST-STATUS whose >>>> definition would be the following: >>>> >>>> Attribute header: >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 >>>> 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+-+ >>>> |x x x x x x x|M| Length | Floor >>>> ID | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+-+ >>>> >>>> Attribute ABNF: >>>> >>>> FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) >>>> (REQUEST-STATUS) >>>> [STATUS-INFO] >>>> *[EXTENSION-ATTRIBUTE] >>>> >>>> Now, the already existing FLOOR-REQUEST-INFORMATION grouped >>>> attribute >>>> would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)' >>>> >>>> The same for the already existing ChairAction message. >>>> >>>> >>>> Additionally, we would define a new grouped attribute called >>>> OVERALL-REQUEST-STATUS, whose definition would be almost >>>> identical to >>>> the FLOOR-REQUEST-STATUS attribute. The only difference is that >>>> this >>>> one would carry a Floor Request ID instead of a Floor ID. This >>>> attribute would be used within the FLOOR-REQUEST-INFORMATION >>>> attribute, whose ABNF would become: >>>> >>>> OLD: >>>> >>>> FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) >>>> (REQUEST-STATUS) <-- >>>> 1*(FLOOR-ID) <-- >>>> [BENEFICIARY-INFORMATION] >>>> [REQUESTED-BY-INFORMATION] >>>> [PRIORITY] >>>> [PARTICIPANT-PROVIDED-INFO] >>>> [STATUS-INFO] <-- >>>> *[EXTENSION-ATTRIBUTE] >>>> >>>> NEW: >>>> >>>> FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) >>>> (OVERALL-REQUEST-STATUS) >>>> 1*(FLOOR-REQUEST-STATUS) >>>> [BENEFICIARY-INFORMATION] >>>> [REQUESTED-BY-INFORMATION] >>>> [PRIORITY] >>>> [PARTICIPANT-PROVIDED-INFO] >>>> *[EXTENSION-ATTRIBUTE] >>>> >>>> >>>> >>>> Then, we would need to add a brief discussion on queues, indicating >>>> that the queue positions in the OVERALL-REQUEST-STATUS attribute >>>> refer to positions in a global queue for floor requests and that >>>> queue positions in the FLOOR-REQUEST-STATUS attribute refer to >>>> positions in a queue for floor requests for a particular floor. Of >>>> course, implementations are free to implement (or provide >>>> information >>>> about) one, both, or none of these queue types. >>>> >>>> The ChairAction message would become: >>>> >>>> OLD: >>>> >>>> ChairAction = (COMMON-HEADER) >>>> 1*(FLOOR-ID) <-- >>>> (FLOOR-REQUEST-ID) >>>> (REQUEST-STATUS) <-- >>>> [STATUS-INFO] >>>> *[EXTENSION-ATTRIBUTE] >>>> >>>> NEW: >>>> >>>> ChairAction = (COMMON-HEADER) >>>> 1*(FLOOR-REQUEST-STATUS) >>>> (FLOOR-REQUEST-ID) >>>> [STATUS-INFO] >>>> *[EXTENSION-ATTRIBUTE] >>>> >>>> >>>> A different issue (more easily fixable than the issue above) is >>>> that >>>> the FloorRequest and the FloorQuery messages should carry >>>> 1*(FLOOR-ID) instead of *(FLOOR-ID). >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> > > _______________________________________________ > 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