From xcon-bounces@ietf.org Mon Nov 06 22:38:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHmd-0004Ba-V4; Mon, 06 Nov 2006 22:37:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHjj-0002as-0V for xcon@ietf.org; Mon, 06 Nov 2006 22:34:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhHV5-0008Om-Vk for xcon@ietf.org; Mon, 06 Nov 2006 22:19:50 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2006 19:19:47 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="340160065:sNHT69705492" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA73Jlgt021469 for ; Mon, 6 Nov 2006 19:19:47 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA73JlOV016354 for ; Mon, 6 Nov 2006 19:19:47 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:19:47 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:19:46 -0800 Message-ID: <454FFB52.4010205@cisco.com> Date: Mon, 06 Nov 2006 22:19:46 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: XCON Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 03:19:47.0020 (UTC) FILETIME=[93C9D8C0:01C7021B] DKIM-Signature: a=rsa-sha1; q=dns; l=1898; t=1162869587; x=1163733587; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20tutorial=3A=20Lunch=20logistics=20update=20[DO=20NOT=20REPLY]; X=v=3Dcisco.com=3B=20h=3Dwvzj+J9U4bGAuwmnCCs9T7HKQa8=3D; b=O6mlmQHYfWyPxQxKeh7Vyx5d25Q2gJ+KAiw3Y3Gn4RC9xhgoKpiFQBIDQaunmsNiU1f7JVCq KAg0xjTtXPrF9VGzXf9yrMA4pHuyHCbuB0O73hReF8QNS7xmccuGj33c; Authentication-Results: sj-dkim-6.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [XCON] ICE tutorial: Lunch logistics update [DO NOT REPLY] 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 Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-12.txt) WHEN: Tuesday, November 7 1130-1300 Lunch will be provided at a nominal fee of $10 Sandwiches, salad and chips Bring-your-own beverage Please get me your $10 prior to the end of the IETF meeting. Only 90 lunches have been ordered, its first-come-first-served I am covering this out of my own pocket, so please do get me your $10 if you partake of the food. I'm not tracking who eats or pays - we're on the honor system here! WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice). !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Nov 07 16:01:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY4L-0001OV-Rv; Tue, 07 Nov 2006 16:01:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY4K-0001OP-Ul for xcon@ietf.org; Tue, 07 Nov 2006 16:01:16 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhY3s-0004Au-LV for xcon@ietf.org; Tue, 07 Nov 2006 16:01:16 -0500 Received: from dhcp69-4.ietf67.org ([130.129.69.4]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1GhY3r-000JFk-Ee; Tue, 07 Nov 2006 16:00:48 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.69.4 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <4550F3FD.4040602@sipstation.com> Date: Tue, 07 Nov 2006 15:00:45 -0600 From: Alan Johnston User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Adam Roach Subject: [XCON] WGLC of draft-ietf-xcon-bfcp-connection-02.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org We are calling for a two week working group last call for draft-ietf-xcon-bfcp-connection-02.txt. Please send all comments to the authors and the list. The WGLC period will end on November 21. Thanks, Alan Johnston co-chair XCON _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Nov 07 21:16:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhczN-0006IY-Pm; Tue, 07 Nov 2006 21:16:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhczM-0006IT-Kv for xcon@ietf.org; Tue, 07 Nov 2006 21:16:28 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhczK-0002f6-CH for xcon@ietf.org; Tue, 07 Nov 2006 21:16:28 -0500 Received: from [130.129.67.54] (dhcp67-54.ietf67.org [130.129.67.54]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id kA82GKek099306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Nov 2006 20:16:25 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <45513DDA.1070209@nostrum.com> Date: Tue, 07 Nov 2006 18:15:54 -0800 From: Adam Roach User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) 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: 130.129.67.54 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [XCON] XCON Minutes X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I have uploaded draft minutes from today's meeting to the materials page: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 Please review the minutes, and send any proposed amendments to me and Alan. Today's presentations have also been uploaded. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Nov 09 16:48:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHlC-0000lN-SB; Thu, 09 Nov 2006 16:48:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHlC-0000ki-6H for xcon@ietf.org; Thu, 09 Nov 2006 16:48:34 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHbF-0007rc-5C for xcon@ietf.org; Thu, 09 Nov 2006 16:38:18 -0500 Received: from bear.cs.columbia.edu (IDENT:nHW0NtP/2AE3pEVUYmGM9qMuJQxSAqhV@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id kA9LbupB026850 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 9 Nov 2006 16:38:13 -0500 (EST) Received: from boyaci (boyacipc.cs.columbia.edu [128.59.16.22]) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id kA9LbteL005264 for ; Thu, 9 Nov 2006 16:37:56 -0500 From: "Omer Boyaci" To: Date: Thu, 9 Nov 2006 16:37:45 -0500 Message-ID: <000401c70447$4e142280$16103b80@boyaci> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccER0riwrCfgf1kRTS59M44Z0RNNA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [XCON] Any reference implementation for BFCP? 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="===============1866573484==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1866573484== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7041D.653E1A80" This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C7041D.653E1A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Is there a reference implementation for BFCP (Binary Floor Control Protocol)? Sincerely, Omer Boyaci ------=_NextPart_000_0005_01C7041D.653E1A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Is there a reference implementation for BFCP (Binary = Floor Control Protocol)?

 

Sincerely,

 

Omer Boyaci

------=_NextPart_000_0005_01C7041D.653E1A80-- --===============1866573484== 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 --===============1866573484==-- From xcon-bounces@ietf.org Thu Nov 09 17:01:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHy4-00007V-9D; Thu, 09 Nov 2006 17:01:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHy2-00007O-Eo for xcon@ietf.org; Thu, 09 Nov 2006 17:01:50 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHxr-0002je-W3 for xcon@ietf.org; Thu, 09 Nov 2006 17:01:50 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AD4561A2; Thu, 9 Nov 2006 23:01:07 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 23:01:06 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 23:01:06 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E6174236E; Fri, 10 Nov 2006 00:01:05 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AF2034DB8F; Fri, 10 Nov 2006 00:01:05 +0200 (EET) Received: from localhost.localdomain (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C2D814DB51; Fri, 10 Nov 2006 00:01:04 +0200 (EET) Subject: Re: [XCON] Any reference implementation for BFCP? From: "Salvatore Loreto (JO/LMF)" To: Omer Boyaci In-Reply-To: <000401c70447$4e142280$16103b80@boyaci> References: <000401c70447$4e142280$16103b80@boyaci> Content-Type: text/plain Date: Fri, 10 Nov 2006 00:01:10 +0200 Message-Id: <1163109671.3511.5.camel@dhcp69-120.ietf67.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 09 Nov 2006 22:01:06.0350 (UTC) FILETIME=[8E3864E0:01C7044A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: xcon@ietf.org 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 Omer, here the link to the implementation https://sourceforge.net/projects/confiance regards Sal On Thu, 2006-11-09 at 16:37 -0500, Omer Boyaci wrote: > Hi, > > > > Is there a reference implementation for BFCP (Binary Floor Control > Protocol)? > > > > Sincerely, > > > > Omer Boyaci > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Nov 13 06:48:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjaHp-0008KL-AB; Mon, 13 Nov 2006 06:47:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjaHc-0008Hi-RR for xcon@ietf.org; Mon, 13 Nov 2006 06:47:24 -0500 Received: from mail.unina.it ([192.132.34.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gja4Q-00074H-5K for xcon@ietf.org; Mon, 13 Nov 2006 06:33:48 -0500 Received: from [143.225.229.186] ([143.225.229.186]) by mail.unina.it (8.13.7/8.13.7) with ESMTP id kADBXdLr011405 for ; Mon, 13 Nov 2006 12:33:43 +0100 Message-ID: <455857D0.5040600@libero.it> Date: Mon, 13 Nov 2006 12:32:32 +0100 From: Lorenzo Miniero User-Agent: Mozilla Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-unina-it-MailScanner-Information: Please contact www.csi.unina.it for information X-unina-it-MailScanner: Found to be clean X-unina-it-MailScanner-SpamCheck: non spam, SpamAssassin (punteggio=0.007, necessario 6, autolearn=disabled, AWL 0.01) X-unina-it-MailScanner-From: rainmaker@libero.it Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.unina.it id kADBXdLr011405 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [XCON] Some doubts 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, this are a couple of doubts I've been having for some time already. First, even if such a question could be considered premature considering=20 the current state of the framework itself: how do we want to really have=20 conferences joined in XCON? For ad-hoc conferences, the scenarios draft=20 presents the example of calling a specific URI to join a conference=20 (which is what we did too for the Confiance demo, a phone number=20 associated to a conference), but I'd actually prefer it to be a method=20 of the CCP, by accessing an xcon uri as proposed by Mary at the meeting,=20 for example: a method that would allow an user to join the conference as=20 an object, with no set of resources accessed yet (e.g. still no=20 audio/video/text/etc) until the user states its will to access one or=20 more of them by means of the respective signaling protocol, or with some=20 resource always available by default upon joining (text, for example)=20 and others that have to be requested. I have another doubt partially related to the join one: we still have=20 not decided yet how we want BFCP information notified to the participant=20 that has just joined a conference and/or wants to access a moderated=20 resource. For the Confiance demo we implemented the SDP+BFCP feature,=20 which actually works, but so far requires the client to use SIP as=20 signaling protocol, besides requiring non-standard extensions to it.=20 While it will probably work like a charm in SIP-related contexts (e.g.=20 the Call Completion Service through BFCP proposed by Adam in SIPPING,=20 which I consider an excellent proposal), I personally don't like to the=20 idea of forcely having SIP and the like everywhere in this WG, mostly=20 considering how the XCON framework has been conceived, that is allowing=20 participants to use various signaling protocols of any kind. Besides,=20 the SDP+BFCP wouldn't probably cover the case of non-typical moderated=20 resources as whiteboards, file-sharing, shared desktops and so on,=20 unless there are ways to access them through SIP extensions too, which I=20 frankly don't know. Again, as for the Join, I think that also exchange=20 of BFCP information should be managed through what will be our CCP: the=20 Floor Control Server policies for each conference will almost surely be=20 managed just through the CCP (since they appear in the current Data=20 Model and the BFCP specification explicitely states that how the=20 policies are defined is not in its scope), so why don't we plan to add=20 the exchange of BFCP info there too? An objection could probaby be that=20 this would be an ad-hoc solution for XCON, that wouldn't be suitable for=20 the use of BFCP in other scenarios and frameworks... What do you think about it? I hope my considerations were not related to=20 already discussed or taken for granted matters, in which case I apologize. Hope to hear you soon, cheers, Lorenzo --=20 Lorenzo Miniero, Junior Researcher Dipartimento di Informatica e Sistemistica Universit=E0 degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) Phone: +390817683821 - Fax: +390817683816 Email: lminiero@napoli.consorzio-cini.it --=20 Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Nov 15 07:19:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkJjb-0000Hy-P1; Wed, 15 Nov 2006 07:19:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkJja-0000Hk-VH for xcon@ietf.org; Wed, 15 Nov 2006 07:19:18 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkJjU-00015R-GX for xcon@ietf.org; Wed, 15 Nov 2006 07:19:18 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9832D4F0002 for ; Wed, 15 Nov 2006 13:17:54 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 13:17:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] WGLC of draft-ietf-xcon-bfcp-connection-02.txt Date: Wed, 15 Nov 2006 13:15:27 +0100 Message-ID: In-Reply-To: <4550F3FD.4040602@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] WGLC of draft-ietf-xcon-bfcp-connection-02.txt Thread-Index: AccCr9OlZv3zXAstTfi+ToeCy396wAF/f4MQ From: "Oscar Novo \(JO/LMF\)" To: X-OriginalArrivalTime: 15 Nov 2006 12:17:54.0519 (UTC) FILETIME=[13F13670:01C708B0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Gonzalo Camarillo \(JO/LMF\)" 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, Just a couple of comments in the draft: - Reference 12 is mentioned in the text (page 4) but it isn't defined. - Section 5.2.1: "The nonce to be placed in the NONCE attribute by the client is typically provided by the floor control server in an Error response with Error Code 10 (DIGEST Attribute Required) or 6 (Invalid Nonce)." -> Should be Error Code 11, not 6. -Check the references, some of them are a bit old. For instance the BFCP reference. Cheers, Oscar -----Original Message----- From: Alan Johnston [mailto:alan@sipstation.com]=20 Sent: 7. marraskuuta 2006 23:01 To: xcon@ietf.org Cc: Adam Roach Subject: [XCON] WGLC of draft-ietf-xcon-bfcp-connection-02.txt We are calling for a two week working group last call for draft-ietf-xcon-bfcp-connection-02.txt. Please send all comments to the authors and the list. The WGLC period will end on November 21. Thanks, Alan Johnston co-chair 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 Mon Nov 20 12:07:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCc0-0008Ly-TQ; Mon, 20 Nov 2006 12:07:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCc0-0008JF-0y for xcon@ietf.org; Mon, 20 Nov 2006 12:07:16 -0500 Received: from webmail.unina.it ([192.132.34.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmCbv-0007Tw-Il for xcon@ietf.org; Mon, 20 Nov 2006 12:07:16 -0500 Received: from webmail.unina.it (localhost [127.0.0.1]) by webmail.unina.it (8.12.11/8.12.11) with ESMTP id kAKH7uPa008342 for ; Mon, 20 Nov 2006 18:07:56 +0100 Received: (from nobody@localhost) by webmail.unina.it (8.12.11/8.12.11/Submit) id kAKH7uup008341 for xcon@ietf.org; Mon, 20 Nov 2006 18:07:56 +0100 X-Authentication-Warning: webmail.unina.it: nobody set sender to spromano@unina.it using -f Received: from 194.251.206.165 ([194.251.206.165]) by webmail.unina.it (IMP) with HTTP for ; Mon, 20 Nov 2006 18:07:56 +0100 Message-ID: <1164042476.4561e0ec0dae2@webmail.unina.it> Date: Mon, 20 Nov 2006 18:07:56 +0100 From: Simon Pietro Romano To: xcon@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 194.251.206.165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by webmail.unina.it id kAKH7uPa008342 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [XCON] CONFIANCE: WS-enabled session control 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 Dear all, a new package (http://prdownloads.sourceforge.net/confiance/confiance_wip_webservice-03= .zip?download) has been made available on the CONFIANCE project's page: it is a set of w= eb applications which enables you to interact with the CONFIANCE framework through the web, using a WebService-based approach.=20 For more information on the architecture and the implementation details, checkout the documentation in the package, and feel free to contact us if= you need further information or are interested in the work.=20 Cheers, Simon --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Nov 20 14:48:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmF8U-0005fe-QR; Mon, 20 Nov 2006 14:48:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmF8U-0005fP-1x for xcon@ietf.org; Mon, 20 Nov 2006 14:48:58 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmF8R-0000cq-R4 for xcon@ietf.org; Mon, 20 Nov 2006 14:48:58 -0500 Received: from 71-10-183-137.dhcp.stls.mo.charter.com ([71.10.183.137] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1GmF8R-00088W-F3; Mon, 20 Nov 2006 14:48:55 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.10.183.137 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <456206A9.1090201@sipstation.com> Date: Mon, 20 Nov 2006 13:48:57 -0600 From: Alan Johnston User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Alan Johnston Subject: Re: [XCON] WGLC of draft-ietf-xcon-bfcp-connection-02.txt References: <4550F3FD.4040602@sipstation.com> In-Reply-To: <4550F3FD.4040602@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Adam Roach , xcon@ietf.org 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 Just a reminder to get your working group last call comments in to the authors and the list by the end of today. Thanks, Alan Johnston co-chair XCON Alan Johnston wrote: > We are calling for a two week working group last call for > draft-ietf-xcon-bfcp-connection-02.txt. > > Please send all comments to the authors and the list. > > The WGLC period will end on November 21. > > Thanks, > Alan Johnston > co-chair 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 Mon Nov 20 16:52:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmH4A-00081e-DU; Mon, 20 Nov 2006 16:52:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmH48-0007xR-UD for xcon@ietf.org; Mon, 20 Nov 2006 16:52:36 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmH40-0000nF-Ol for xcon@ietf.org; Mon, 20 Nov 2006 16:52:36 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 25FB396B; Mon, 20 Nov 2006 22:52:28 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 22:52:27 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 22:52:27 +0100 Received: from [131.160.126.61] (rvi2-126-61.lmf.ericsson.se [131.160.126.61]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 58AAA236E; Mon, 20 Nov 2006 23:52:27 +0200 (EET) Message-ID: <4562239B.2050906@ericsson.com> Date: Mon, 20 Nov 2006 23:52:27 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Alan Johnston Subject: Re: [XCON] WGLC of draft-ietf-xcon-bfcp-connection-02.txt References: <4550F3FD.4040602@sipstation.com> <456206A9.1090201@sipstation.com> In-Reply-To: <456206A9.1090201@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2006 21:52:27.0712 (UTC) FILETIME=[2BA1C400:01C70CEE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Cullen Jennings , Adam Roach , xcon@ietf.org, Eric Rescorla 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, it has been suggested to replace the digest mechanism the draft currently defines with TLS-PSK (RFC 4279). Even though TLS-PSK is a relatively new mechanism, OpenSSL 0.9.8 already implements it. Therefore, its use should not be a problem for early deployments. If somebody thinks that this is a terrible idea and that we should keep the digest mechanism, please speak up. Thanks, Gonzalo Alan Johnston wrote: > Just a reminder to get your working group last call comments in to the > authors and the list by the end of today. > > Thanks, > Alan Johnston > co-chair XCON > > Alan Johnston wrote: >> We are calling for a two week working group last call for >> draft-ietf-xcon-bfcp-connection-02.txt. >> >> Please send all comments to the authors and the list. >> >> The WGLC period will end on November 21. >> >> Thanks, >> Alan Johnston >> co-chair 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 > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Nov 20 22:20:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmMBB-0003GC-6p; Mon, 20 Nov 2006 22:20:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmMB9-0003Fw-Vq for xcon@ietf.org; Mon, 20 Nov 2006 22:20:11 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmMB6-0000mX-As for xcon@ietf.org; Mon, 20 Nov 2006 22:20:11 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.20; Mon, 20 Nov 2006 19:20:07 -0800 Received: from NA-EXMSG-C105.redmond.corp.microsoft.com ([157.54.52.48]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Mon, 20 Nov 2006 19:20:07 -0800 From: Srivatsa Srinivasan To: "xcon@ietf.org" Date: Mon, 20 Nov 2006 19:20:02 -0800 Thread-Topic: data model -03 comments Thread-Index: AccNG+72IRawKsqJT2eDjL/9TXRb+g== Message-ID: <6512F99DEFF77C418E6738CE6E12FD4E26A3761A50@NA-EXMSG-C105.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Subject: [XCON] data model -03 comments 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 http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-03.tx= t Had a chance to look at the updated data model draft, so here are some deta= iled comments. My prior comments still hold, but I will try not to repeat t= hem here. Overall, simplification would greatly help reduce some of the com= plexity (see comments below). There are some XML elements that don't appear= in the RELAX-NG schema (like 'mute') -- this was discussed and I think a b= ase set of controls should be included in the data model schema and a secti= on that describes how additional controls may be added. That said, this ver= sion is certainly better than the previous one! -- Srivatsa. Section 3.3.5: " The contains the maximum number of streams that are permitted to be involved in a conference. It contains a sequence of child elements. An element MAY contain the number of streams of every specific type of stream, for instance, audio or video. The minimum value permitted is "1" and the maximum value permitted is "128". This element is optional." [SS] should be sufficient to derive maximum streams as= necessary by the conferencing system. What is the intent here (where would= this be used)? Section 3.3.6: " The element specifies the allowed codecs in the conference. It has an attribute 'decision' that specifies if the focus decides the common codec automatically or needs the approvement of the moderator of the conference (automatic, moderator-controlled). The element contains a elements. A element can have the attribute 'name' and 'policy'. The 'name' attribute identifies a codec, and the 'decision' attribute and the policy attribute contains the policy for that codec (allowed, or disallowed)." [SS] What is the real-world scenario that policies and such address with re= spect to codecs? In the example below, does it imply that a conference clie= nt would specify this at conference scheduling time (like an organizer)? Or= was this introduced as a result of a non-SIP implementation? In a SIP impl= ementation, would the conferencing client learn of the allowed codecs prior= to sending an INVITE to the Focus? "The child elements , describe a default policy by which the mixer will build the outgoing stream from the incoming streams. Notice that this policy is different that the policy describe for the floors for each media. The child element describes the number of participants in audio media streams or the number of sub-windows in video media streams (for instance, a value of 4 in the element for video stremas means 2x2 layout). The child element MUST contain one and only one of the "Moderator-controlled", "FCFS", and "Automatic" values indicating the default algorithm to be use with every media stream." [SS] This section is not at all clear. Mixing mode is a very specific imple= mentation detail of mixing. What does it mean to define a mixing-mode for e= very stream -- is this mode applied to the incoming stream to or the outgoi= ng ones from the mixer? And why would a conference participant (organizer o= r moderator or attendee) be interested in choosing one over the other? [SS] Also, for layouts, an enumeration of specific layout string identifier= s with localized description strings for each layout will be more useful th= an just an integer aka mix-level. Note that this can be clubbed or rather r= eplaced with a element for layouts. Also, a specific mixer output= stream may only support one layout. A client capable of receiving multiple= streams may receive more than one stream, each with different layouts or m= ultiple streams each with the same layout. For example, a mixer may output = two streams each capable of only a single layout (fixed layouts by the mixe= r) -- the main video with active speaker and another stream (or multiple st= reams) of a proprietary mix (like enhanced video from a conference room). T= his section needs scrubbing. "3.3.7.1. mute The 'mute' control is used in conjunction with a audio stream to cease transmission of associated media. It has a 'Boolean' value. If this control is not specify, the access to the control is not available to the client and media SHOULD not be transported for the associated media stream." [SS] This comment applies to all controls. It is quite useful to still have= the ability to indicate that the control exists, but cannot be modified. T= his is useful for example, to know whether another participant is muted or = not. This was possible via 'enabled=3Dtrue' or 'enabled=3Dfalse' in the pre= vious version of the data model. Why was this removed? "3.4. The element contains information about the entity hosting the conference. It contains the , child elements. These child elements are explained in [2]. contains the child element as well. contains a sequence of child elements: , , and . The child elements of are described in section." [SS] Can the part be removed in a way that will make this work in a b= ackward-compatible manner? I see some value in leaving H.323 and PSTN/ISDN = in there, but the can very well be removed. Also "" isn't = valid XML, you may want to check up on that. Section 3.5 " The element represents a boolean action. If set to TRUE, the focus is instructed to allow the subscription to conference state events, such as the SIP Event Package for Conference State [2]. If set to FALSE, the subscription to conference state events would be rejected. If this element is undefined it has a value of TRUE, causing the subscription to conference state events to be accepted." [SS] The purpose of this element beats me. Is there a scenario where an org= anizer may want to set this at conference scheduling time? Why restrict onl= y subscriptions? Wouldn't an organizer want to Section 3.7 " The element defines the actions used by the conference focus to control conference participation. This element defines the action that the focus is to take when processing a particular request to join a conference. This element defines values of: o block: This action instructs the focus to deny access to the conference. This action is the default action taken in the absence of any other actions. o confirm: This action instructs the focus to place the participant on a pending list (e.g., by parking the call on a music-on-hold server), awaiting moderator input for further actions. o allow: This action instructs the focus to accept the conference join request and grant access to the conference within the instructions specified in the transformations of this rule. o IVR: This action instructs the focus that the user has to define the PIN code. o directed-operator: This action instructs the focus to direct the user to an operator." [SS] More clarification here would help. For example, what does it mean to = have a value of join handling under element (see example be= low)? Would all join requests be rejected?? block " The element is a list of three elements: 'closedAuthenticated', 'openAuthenticated', and 'anonymous'. If the element is set to 'closedAuthenticated', users must be specified (and authenticate). If the attribute is set to 'openAuthenticated', users can be add after conference activation." [SS] Please reword: "The is an element that lets an= organizer (or a participant with appropriate rights) choose a policy for t= he conference that controls how users are allowed into the conference. A 'c= losedAuthenticated' policy requires each conference participant to be in th= e allowed users list (listed under the XML element) wi= th each participant being sufficiently (up to local policy) authenticated. = Conference join requests for users not in the allowed users list or partici= pants not authenticated should be rejected unless a action= of 'confirm' is selected in which case the user is placed on a pending lis= t as indicated earlier. An 'openAuthenticated' policy requires each confere= ncing participant to be sufficiently authenticated (as before) but does not= restrict which participants can join the conference. Typically this implie= s that anyone capable of authenticating with the conferencing system may jo= in the conference. An 'anonymous' policy allows any join requests in and is= the least restrictive in policies." [SS] Note the combination of and a specific should be worked out. For example, if there is an and what does it mean? Why would I need to enter a PIN when I am= a) already authenticated b) have joined the conference using a conference = URI (example: SIP URI) and c) such that the conferencing system has already= authorized me to join the conference? Section 3.7.1 " The 'method' attribute is a list with the following values: "dial-in", "dial-out, and "refer". The value "dial-in" is used by the focus to determine who can join the conference. Value "refer" is used by the focus to determine the resources that the focus needs to "refer to" the conference." [SS] Why would a conferencing system want to let conference organizer descr= ibe "how" a conference participant joins? This is up-to local implementatio= n. If a specific participant has a value of 'dial-in' but is later dialed-o= ut, what does that mean? "3.7.2. The refers to a virtual set of rights pertaining to operations. This element contains the element. " [SS] Re-using common policy is great. But implementing such a system that d= escribes access privileges to XML elements in XML for conferencing is compl= icated. I suggest that we start simple here and push this section out to a = separate draft for further investigation. Since this isn't a must-have scen= ario moving this section out would greatly simplify this document so energi= es can be focused on making the simple case work: having a conferencing cli= ent inter-op with a conference server for a base set of modalities. Section 3.8. " The , and elements are defined in the previous section." [SS] Would an organizer specify these as conference policies? This ought to= be based on the role of the participant instead, right? This again can go = into a draft that discusses conference policies. Suggest we leave this out = of the base data model. Section 3.8.1 " Similarly that the controls defined in the element, controls that apply to a particular user appear at this place in the document. The element details properties associated with the incoming streams to the mixer. element details properties associated with the outgoing streams from the mixer. Both of these elements have the attribute 'name'. 'Name' attribute has the values "VideoIn", "VideoOut", "AudioOut", and "AudioIn". The "VideoOut" and "AudioOut" media streams detail properties associated with the outgoing video and audio from the mixer. The "VideoIn" and "AudioIn" media stream details properties associated with the incoming video and audio to the mixer. More values can be defined in the future. Every of these elements have the and child elements." [SS] This needs to be re-worded. A draft I submitted (SDP media usages) has= text that can be borrowed to cover this section. If not, let me know and I= can help re-word this. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Nov 28 03:54:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goyjb-0002Tz-KE; Tue, 28 Nov 2006 03:54:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoyjZ-0002Tr-Ur for xcon@ietf.org; Tue, 28 Nov 2006 03:54:33 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goyj9-0002XU-61 for xcon@ietf.org; Tue, 28 Nov 2006 03:54:33 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2694D692; Tue, 28 Nov 2006 09:53:54 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 09:53:54 +0100 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 -03 comments Date: Tue, 28 Nov 2006 09:51:16 +0100 Message-ID: In-Reply-To: <6512F99DEFF77C418E6738CE6E12FD4E26A3761A50@NA-EXMSG-C105.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] data model -03 comments Thread-Index: AccNG+72IRawKsqJT2eDjL/9TXRb+gDcEnKA From: "Oscar Novo \(JO/LMF\)" To: X-OriginalArrivalTime: 28 Nov 2006 08:53:54.0059 (UTC) FILETIME=[BB6DFDB0:01C712CA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 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 Hello Srivatsa and Sean, Thanks for your comments! Comments inline. -----Original Message----- From: Srivatsa Srinivasan [mailto:srivats@microsoft.com]=20 Sent: 21. marraskuuta 2006 5:20 To: xcon@ietf.org Subject: [XCON] data model -03 comments http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-03 .txt Had a chance to look at the updated data model draft, so here are some detailed comments. My prior comments still hold, but I will try not to repeat them here. Overall, simplification would greatly help reduce some of the complexity (see comments below). There are some XML elements that don't appear in the RELAX-NG schema (like 'mute') -- this was discussed and I think a base set of controls should be included in the data model schema and a section that describes how additional controls may be added. That said, this version is certainly better than the previous one! [ON] In version 04, I have introduced the 'mute' element as well as other elements that were missing. The data model document is getting very big and sometimes is difficult for me to handle it all. Version 04 has over 80 pages and I guess the document will increase in the following revisions. Thanks to point me the missing element. In IETF-67, I asked to the audience about more controls we should include in the data model. A 'video-layout' control will be include in version 04. If you think the data model should include more controls, please send your suggestions to the mailing list.=20 Section 3.3.5: " The contains the maximum number of streams that are permitted to be involved in a conference. It contains a sequence of child elements. An element MAY contain the number of streams of every specific type of stream, for instance, audio or video. The minimum value permitted is "1" and the maximum value permitted is "128". This element is optional." [SS] should be sufficient to derive maximum streams as necessary by the conferencing system. What is the intent here (where would this be used)? [ON] This information is defined in the old template draft. A normal participant in the conference may have different streams (audio, video, text, whiteboard...). only tells you the maximum number of participants for every role a conference can hold but not the maximum number of streams a conference can hold.=20 So, is more a 'conference policy' element since is more a 'bandwidth' element. Section 3.3.6: " The element specifies the allowed codecs in the conference. It has an attribute 'decision' that specifies if the focus decides the common codec automatically or needs the approvement of the moderator of the conference (automatic, moderator-controlled). The element contains a elements. A element can have the attribute 'name' and 'policy'. The 'name' attribute identifies a codec, and the 'decision' attribute and the policy attribute contains the policy for that codec (allowed, or disallowed)." [SS] What is the real-world scenario that policies and such address with respect to codecs? In the example below, does it imply that a conference client would specify this at conference scheduling time (like an organizer)? Or was this introduced as a result of a non-SIP implementation? In a SIP implementation, would the conferencing client learn of the allowed codecs prior to sending an INVITE to the Focus? [ON] The XCON data model should work beyond SIP protocol. This element has two scenarios, first the client can learn the allowed codecs and second the organizer can control which codecs can be use in the conference. "The child elements , describe a default policy by which the mixer will build the outgoing stream from the incoming streams. Notice that this policy is different that the policy describe for the floors for each media. The child element describes the number of participants in audio media streams or the number of sub-windows in video media streams (for instance, a value of 4 in the element for video stremas means 2x2 layout). The child element MUST contain one and only one of the "Moderator-controlled", "FCFS", and "Automatic" values indicating the default algorithm to be use with every media stream." [SS] This section is not at all clear. Mixing mode is a very specific implementation detail of mixing. What does it mean to define a mixing-mode for every stream -- is this mode applied to the incoming stream to or the outgoing ones from the mixer?=20 [ON] It implies to the incoming streams to the server. And why would a conference participant (organizer or moderator or attendee) be interested in choosing one over the other? [ON] I think is quite important to have media control. For instance in a video conferencing the moderator may want to control the video streams to show different participants. =20 [SS] Also, for layouts, an enumeration of specific layout string identifiers with localized description strings for each layout will be more useful than just an integer aka mix-level. Note that this can be clubbed or rather replaced with a element for layouts. Also, a specific mixer output stream may only support one layout. A client capable of receiving multiple streams may receive more than one stream, each with different layouts or multiple streams each with the same layout. For example, a mixer may output two streams each capable of only a single layout (fixed layouts by the mixer) -- the main video with active speaker and another stream (or multiple streams) of a proprietary mix (like enhanced video from a conference room). This section needs scrubbing. [ON] I think we have discussed this in the last IETF. That's why I will include a new control in the data model in version 04. "3.3.7.1. mute The 'mute' control is used in conjunction with a audio stream to cease transmission of associated media. It has a 'Boolean' value. If this control is not specify, the access to the control is not available to the client and media SHOULD not be transported for the associated media stream." [SS] This comment applies to all controls. It is quite useful to still have the ability to indicate that the control exists, but cannot be modified. This is useful for example, to know whether another participant is muted or not. This was possible via 'enabled=3Dtrue' or 'enabled=3Dfalse' in the previous version of the data model. Why was = this removed? [ON] It was removed for simplicity. The use case you propose is still possible, every user has an element floor that tells you if the user is using that floor or not. The access of a control is specify for the 'read-only' and 'read-write' attributes of the element. "3.4. The element contains information about the entity hosting the conference. It contains the , child elements. These child elements are explained in [2]. contains the child element as well. contains a sequence of child elements: , , and . The child elements of are described in section." [SS] Can the part be removed in a way that will make this work in a backward-compatible manner? I see some value in leaving H.323 and PSTN/ISDN in there, but the can very well be removed.=20 [ON] do you mean backward-compatible with the SIP even package? 04 version is already backward-compatible with the SIP even package. Also "" isn't valid XML, you may want to check up on that. [ON] Thanks to point me that out. I have corrected it in the 04 version. Section 3.5 " The element represents a boolean action. If set to TRUE, the focus is instructed to allow the subscription to conference state events, such as the SIP Event Package for Conference State [2]. If set to FALSE, the subscription to conference state events would be rejected. If this element is undefined it has a value of TRUE, causing the subscription to conference state events to be accepted." [SS] The purpose of this element beats me. Is there a scenario where an organizer may want to set this at conference scheduling time?=20 [ON] scenario -> low-bandwidth environment. Section 3.7 " The element defines the actions used by the conference focus to control conference participation. This element defines the action that the focus is to take when processing a particular request to join a conference. This element defines values of: o block: This action instructs the focus to deny access to the conference. This action is the default action taken in the absence of any other actions. o confirm: This action instructs the focus to place the participant on a pending list (e.g., by parking the call on a music-on-hold server), awaiting moderator input for further actions. o allow: This action instructs the focus to accept the conference join request and grant access to the conference within the instructions specified in the transformations of this rule. o IVR: This action instructs the focus that the user has to define the PIN code. o directed-operator: This action instructs the focus to direct the user to an operator." [SS] More clarification here would help.=20 [ON] Please, provide me with the text and I can include it in the next version of the draft. I can't see what is unclear.=20 For example, what does it mean to have a value of join handling under element (see example below)? Would all join requests be rejected?? block [ON] yes " The element is a list of three elements: 'closedAuthenticated', 'openAuthenticated', and 'anonymous'. If the element is set to 'closedAuthenticated', users must be specified (and authenticate). If the attribute is set to 'openAuthenticated', users can be add after conference activation." [SS] Please reword: "The is an element that lets an organizer (or a participant with appropriate rights) choose a policy for the conference that controls how users are allowed into the conference. A 'closedAuthenticated' policy requires each conference participant to be in the allowed users list (listed under the XML element) with each participant being sufficiently (up to local policy) authenticated. Conference join requests for users not in the allowed users list or participants not authenticated should be rejected unless a action of 'confirm' is selected in which case the user is placed on a pending list as indicated earlier. An 'openAuthenticated' policy requires each conferencing participant to be sufficiently authenticated (as before) but does not restrict which participants can join the conference. Typically this implies that anyone capable of authenticating with the conferencing system may join the conference. An 'anonymous' policy allows any join requests in and is the least restrictive in policies." [ON] thanks, your text has been added in the 04 version of the draft. [SS] Note the combination of and a specific should be worked out. For example, if there is an and what does it mean? Why would I need to enter a PIN when I am a) already authenticated b) have joined the conference using a conference URI (example: SIP URI) and c) such that the conferencing system has already authorized me to join the conference? [ON] The propose of the XCON data model is to provide all the necessary information in a centralized conference. Providing consistence to the data model is out-of-scope of the document. The organizer or creator of the conference should be the person in charge to create consistence in the data model.=20 Section 3.7.1 " The 'method' attribute is a list with the following values: "dial-in", "dial-out, and "refer". The value "dial-in" is used by the focus to determine who can join the conference. Value "refer" is used by the focus to determine the resources that the focus needs to "refer to" the conference." [SS] Why would a conferencing system want to let conference organizer describe "how" a conference participant joins? This is up-to local implementation. If a specific participant has a value of 'dial-in' but is later dialed-out, what does that mean? [ON] we have already discussed this in the IETF-66. You were there. :) "3.7.2. The refers to a virtual set of rights pertaining to operations. This element contains the element. " [SS] Re-using common policy is great. But implementing such a system that describes access privileges to XML elements in XML for conferencing is complicated. I suggest that we start simple here and push this section out to a separate draft for further investigation. Since this isn't a must-have scenario moving this section out would greatly simplify this document so energies can be focused on making the simple case work: having a conferencing client inter-op with a conference server for a base set of modalities. [ON] The data model has to have some kind of common policy. In the framework draft is specified like that. Section 3.8. " The , and elements are defined in the previous section." [SS] Would an organizer specify these as conference policies? This ought to be based on the role of the participant instead, right? This again can go into a draft that discusses conference policies. Suggest we leave this out of the base data model. [ON] same comment than before. Section 3.8.1 " Similarly that the controls defined in the element, controls that apply to a particular user appear at this place in the document. The element details properties associated with the incoming streams to the mixer. element details properties associated with the outgoing streams from the mixer. Both of these elements have the attribute 'name'. 'Name' attribute has the values "VideoIn", "VideoOut", "AudioOut", and "AudioIn". The "VideoOut" and "AudioOut" media streams detail properties associated with the outgoing video and audio from the mixer. The "VideoIn" and "AudioIn" media stream details properties associated with the incoming video and audio to the mixer. More values can be defined in the future. Every of these elements have the and child elements." [SS] This needs to be re-worded. A draft I submitted (SDP media usages) has text that can be borrowed to cover this section. If not, let me know and I can help re-word this. [ON] Just tell me which text you would like to have and if it's better than the one in 03 version I can change it. _______________________________________________ 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 Nov 28 11:42:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp62Y-0007xB-OA; Tue, 28 Nov 2006 11:42:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp62X-0007wP-Lf for xcon@ietf.org; Tue, 28 Nov 2006 11:42:37 -0500 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp62T-0007sD-UN for xcon@ietf.org; Tue, 28 Nov 2006 11:42:37 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.20; Tue, 28 Nov 2006 08:42:33 -0800 Received: from NA-EXMSG-C105.redmond.corp.microsoft.com ([157.54.52.48]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Tue, 28 Nov 2006 08:42:32 -0800 From: Srivatsa Srinivasan To: "Oscar Novo (JO/LMF)" , "xcon@ietf.org" Date: Tue, 28 Nov 2006 08:42:29 -0800 Subject: RE: [XCON] data model -03 comments Thread-Topic: [XCON] data model -03 comments Thread-Index: AccNG+72IRawKsqJT2eDjL/9TXRb+gDcEnKAAJ13JkA= Message-ID: <6512F99DEFF77C418E6738CE6E12FD4E26A7E1DC9A@NA-EXMSG-C105.redmond.corp.microsoft.com> References: <6512F99DEFF77C418E6738CE6E12FD4E26A3761A50@NA-EXMSG-C105.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 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 More comments inline (preceded by '>'). My suggestion is: if the specific X= ML element is not covering a specific use-case in the scenarios document, remove it. No reason to have various bells and whistles for complicated sce= narios or less-important use-cases. They can very well be extensions. -- Srivatsa Section 3.3.5: " The contains the maximum number of streams that are permitted to be involved in a conference. It contains a sequence of child elements. An element MAY contain the number of streams of every specific type of stream, for instance, audio or video. The minimum value permitted is "1" and the maximum value permitted is "128". This element is optional." [SS] should be sufficient to derive maximum streams as necessary by the conferencing system. What is the intent here (where would this be used)? [ON] This information is defined in the old template draft. A normal participant in the conference may have different streams (audio, video, text, whiteboard...). only tells you the maximum number of participants for every role a conference can hold but not the maximum number of streams a conference can hold. So, is more a 'conference policy' element since is more a 'bandwidth' element. > [SS] Bandwidth?? Please explain. I don't see how declaring the number of > streams controls the bandwidth. Section 3.3.6: " The element specifies the allowed codecs in the conference. It has an attribute 'decision' that specifies if the focus decides the common codec automatically or needs the approvement of the moderator of the conference (automatic, moderator-controlled). The element contains a elements. A element can have the attribute 'name' and 'policy'. The 'name' attribute identifies a codec, and the 'decision' attribute and the policy attribute contains the policy for that codec (allowed, or disallowed)." [SS] What is the real-world scenario that policies and such address with respect to codecs? In the example below, does it imply that a conference client would specify this at conference scheduling time (like an organizer)? Or was this introduced as a result of a non-SIP implementation? In a SIP implementation, would the conferencing client learn of the allowed codecs prior to sending an INVITE to the Focus? [ON] The XCON data model should work beyond SIP protocol. This element has two scenarios, first the client can learn the allowed codecs and second the organizer can control which codecs can be use in the conference. > [SS] The latter is what is bothersome. Why would an organizer want > to specify something like this? The codecs should be a negotiation > between the Focus+MCU and the conferencing client. Restricting this > at conference schedule time makes no sense. IMO this section should > be informational only (i.e. read-only) at best or in-fact removed. "The child elements , describe a default policy by which the mixer will build the outgoing stream from the incoming streams. Notice that this policy is different that the policy describe for the floors for each media. The child element describes the number of participants in audio media streams or the number of sub-windows in video media streams (for instance, a value of 4 in the element for video stremas means 2x2 layout). The child element MUST contain one and only one of the "Moderator-controlled", "FCFS", and "Automatic" values indicating the default algorithm to be use with every media stream." [SS] This section is not at all clear. Mixing mode is a very specific implementation detail of mixing. What does it mean to define a mixing-mode for every stream -- is this mode applied to the incoming stream to or the outgoing ones from the mixer? [ON] It implies to the incoming streams to the server. > [SS] How would one implement Moderator-controlled, FCFS and Automatic > modes? Where are these algorithms defined? I suggest we remove this. And why would a conference participant (organizer or moderator or attendee) be interested in choosing one over the other? [ON] I think is quite important to have media control. For instance in a video conferencing the moderator may want to control the video streams to show different participants. > [SS] I was referring to the mixing-mode. Would the mixing mode be set > by an organizer?? Which specific scenario is this covering > from the scenarios document? [SS] Also, for layouts, an enumeration of specific layout string identifiers with localized description strings for each layout will be more useful than just an integer aka mix-level. Note that this can be clubbed or rather replaced with a element for layouts. Also, a specific mixer output stream may only support one layout. A client capable of receiving multiple streams may receive more than one stream, each with different layouts or multiple streams each with the same layout. For example, a mixer may output two streams each capable of only a single layout (fixed layouts by the mixer) -- the main video with active speaker and another stream (or multiple streams) of a proprietary mix (like enhanced video from a conference room). This section needs scrubbing. [ON] I think we have discussed this in the last IETF. That's why I will include a new control in the data model in version 04. > [SS] You mean, you will remove mix-level and introduce a video-layout con= trol > instead? "3.3.7.1. mute The 'mute' control is used in conjunction with a audio stream to cease transmission of associated media. It has a 'Boolean' value. If this control is not specify, the access to the control is not available to the client and media SHOULD not be transported for the associated media stream." [SS] This comment applies to all controls. It is quite useful to still have the ability to indicate that the control exists, but cannot be modified. This is useful for example, to know whether another participant is muted or not. This was possible via 'enabled=3Dtrue' or 'enabled=3Dfalse' in the previous version of the data model. Why was this removed? [ON] It was removed for simplicity. The use case you propose is still possible, every user has an element floor that tells you if the user is using that floor or not. The access of a control is specify for the 'read-only' and 'read-write' attributes of the element. > [SS] These attributes are not defined in the schema. Are you expecting > a generic conferencing client to check EVERY element to see if it > is read-only or read-write? The conference protocol may very well > have a method called modifyEndpointMedia. You are saying here that t= he > client should by looking at every XML element determine whether > that operation (with its data) is permissible or not? > This makes it MORE complex. It is much simpler to have a schema > defined declaring which elements the client should check for read-on= ly > or read-write access and that the meaning of those attributes must b= e > defined in text in the data model. Otherwise, this is quite impossib= le > to implement and will cause a whole slew of inter-op issues. Section 3.5 " The element represents a boolean action. If set to TRUE, the focus is instructed to allow the subscription to conference state events, such as the SIP Event Package for Conference State [2]. If set to FALSE, the subscription to conference state events would be rejected. If this element is undefined it has a value of TRUE, causing the subscription to conference state events to be accepted." [SS] The purpose of this element beats me. Is there a scenario where an organizer may want to set this at conference scheduling time? [ON] scenario -> low-bandwidth environment. > [SS] Please explain how this would solve the low-bandwidth problem when y= ou > can have a combination of low-bandwidth and high-bandwidth access > with different clients. Would the organizer say that all clients wou= ld not > get notifications? If a client (or the server) deems itself as being= on a > low-bandwidth network, then it could clearly not SUBSCRIBE (or rejec= t the SUBSCRIBE) > Wouldn't that serve the purpose? Section 3.7 " The element defines the actions used by the conference focus to control conference participation. This element defines the action that the focus is to take when processing a particular request to join a conference. This element defines values of: o block: This action instructs the focus to deny access to the conference. This action is the default action taken in the absence of any other actions. o confirm: This action instructs the focus to place the participant on a pending list (e.g., by parking the call on a music-on-hold server), awaiting moderator input for further actions. o allow: This action instructs the focus to accept the conference join request and grant access to the conference within the instructions specified in the transformations of this rule. o IVR: This action instructs the focus that the user has to define the PIN code. o directed-operator: This action instructs the focus to direct the user to an operator." [SS] More clarification here would help. [ON] Please, provide me with the text and I can include it in the next version of the draft. I can't see what is unclear. > [SS] Will do later. [SS] Note the combination of and a specific should be worked out. For example, if there is an and what does it mean? Why would I need to enter a PIN when I am a) already authenticated b) have joined the conference using a conference URI (example: SIP URI) and c) such that the conferencing system has already authorized me to join the conference? [ON] The propose of the XCON data model is to provide all the necessary information in a centralized conference. Providing consistence to the data model is out-of-scope of the document. The organizer or creator of the conference should be the person in charge to create consistence in the data model. > [SS] Huh? I disagree. If the data model is defining elements with > certain meaning, shouldn't it be more explicit as to how these > elements will be used? Either that or abstract the problem out. Section 3.7.1 " The 'method' attribute is a list with the following values: "dial-in", "dial-out, and "refer". The value "dial-in" is used by the focus to determine who can join the conference. Value "refer" is used by the focus to determine the resources that the focus needs to "refer to" the conference." [SS] Why would a conferencing system want to let conference organizer describe "how" a conference participant joins? This is up-to local implementation. If a specific participant has a value of 'dial-in' but is later dialed-out, what does that mean? [ON] we have already discussed this in the IETF-66. You were there. :) > [SS] Yes and I still do not agree -- I think we should remove 'method'. > The only useful scenario in there is perhaps a 'auto-dial-out' > attribute or some such indicating that the conference server > should automatically dial-out to the user. But that scenario is > NOT defined in the scenarios document, so we should remove it :) "3.7.2. The refers to a virtual set of rights pertaining to operations. This element contains the element. " [SS] Re-using common policy is great. But implementing such a system that describes access privileges to XML elements in XML for conferencing is complicated. I suggest that we start simple here and push this section out to a separate draft for further investigation. Since this isn't a must-have scenario moving this section out would greatly simplify this document so energies can be focused on making the simple case work: having a conferencing client inter-op with a conference server for a base set of modalities. [ON] The data model has to have some kind of common policy. In the framework draft is specified like that. > [SS] I am okay with common policy, except for generic logic describing > which portions of the XML data structure the client can modify. > That is quite hard to implement and will cause inter-op pains. I > think having the schema state which elements carry the read-write et= c. > attributes and the common policy declaring which of those elements > can be modified would greatly help. > For example, a common policy action of is much simple= r > for an organizer to specify than specifying a pointer to an XML elem= ent. > In section 3.7.2.2 you have o The element represents a boolean action. If set to TRUE, the identity is allowed to modify the element described inside the 'element' attribute in the conference policy. If set to FALSE, any modifications to the element are rejected. o The element represents a boolean action. If set to TRUE, the identity is allowed to read the element described inside the 'element' attribute in the conference policy. If set to FALSE, any attempts to read the element are rejected. > [SS] Which 'element' attribute is this referring to?? It does not even > appear in the schema! Section 3.8. " The , and elements are defined in the previous section." [SS] Would an organizer specify these as conference policies? This ought to be based on the role of the participant instead, right? This again can go into a draft that discusses conference policies. Suggest we leave this out of the base data model. [ON] same comment than before. > [SS] Please remove from the data model. Some of this is SIP specific and > also, which specific scenario in the scenarios document is this addr= essing? _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Nov 30 12:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppeQ-0004Dq-Rx; Thu, 30 Nov 2006 12:24:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppeP-0004AU-DH for xcon@ietf.org; Thu, 30 Nov 2006 12:24:45 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GppeO-00026h-5q for xcon@ietf.org; Thu, 30 Nov 2006 12:24:45 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAUHOVL07784; Thu, 30 Nov 2006 12:24:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Nov 2006 11:24:10 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback requested: draft-boulton-xcon-userid-00 Thread-Index: AccUpFkcft+tPN2WS5CCitqMyBURhA== From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: cboulton@ubiquity.net Subject: [XCON] Feedback requested: draft-boulton-xcon-userid-00 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 Per discussions at IETF-67, here's the reminder that we'd like feedback on this draft: http://www.ietf.org/internet-drafts/draft-boulton-xcon-userid-00.txt The conference user concept is introduced in the framework to identify the entity participating in a conference and manipulating conferencing system related properties. This document defines a Conference User Identifier and syntax for identifying a specific conference user within a conferencing system. The document also describes the logical mapping of this conference user identifier to protocol and signaling interface specific user identifiers. The questions are around how prescriptive we need to be in XCON specifications as to the allocation, distribution and definiton of this identifier or would this all just be purely informational. This concept has been part of the framework from day one and it does seem to be an important concept and something that should be part of the basic data model, as well.=20 Regards, Mary=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Nov 30 12:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppeV-0004JP-1f; Thu, 30 Nov 2006 12:24:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppeT-0004GX-Hk for xcon@ietf.org; Thu, 30 Nov 2006 12:24:49 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GppeS-00026q-9X for xcon@ietf.org; Thu, 30 Nov 2006 12:24:49 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAUHOaL07799; Thu, 30 Nov 2006 12:24:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Nov 2006 11:24:31 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback requested: draft-boulton-xcon-userid-00 Thread-Index: AccUpFkcft+tPN2WS5CCitqMyBURhA== From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: cboulton@ubiquity.net Subject: [XCON] Feedback requested: draft-boulton-xcon-userid-00 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 Per discussions at IETF-67, here's the reminder that we'd like feedback on this draft: http://www.ietf.org/internet-drafts/draft-boulton-xcon-userid-00.txt The conference user concept is introduced in the framework to identify the entity participating in a conference and manipulating conferencing system related properties. This document defines a Conference User Identifier and syntax for identifying a specific conference user within a conferencing system. The document also describes the logical mapping of this conference user identifier to protocol and signaling interface specific user identifiers. The questions are around how prescriptive we need to be in XCON specifications as to the allocation, distribution and definiton of this identifier or would this all just be purely informational. This concept has been part of the framework from day one and it does seem to be an important concept and something that should be part of the basic data model, as well.=20 Regards, Mary=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Nov 30 12:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppeV-0004JP-1f; Thu, 30 Nov 2006 12:24:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppeT-0004GX-Hk for xcon@ietf.org; Thu, 30 Nov 2006 12:24:49 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GppeS-00026q-9X for xcon@ietf.org; Thu, 30 Nov 2006 12:24:49 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAUHOaL07799; Thu, 30 Nov 2006 12:24:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Nov 2006 11:24:31 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback requested: draft-boulton-xcon-uri-00 Thread-Index: AccUpGVuaXSlIFacQki9/VbtYga4OQ== From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: cboulton@ubiquity.net Subject: [XCON] Feedback requested: draft-boulton-xcon-uri-00 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 Per discussions at IETF-67, here's the reminder that we'd like feedback on this draft: http://www.ietf.org/internet-drafts/draft-boulton-xcon-uri-00.txt This document defines a URI scheme and syntax for the conference object identifier, as defined in "A Framework and Data Model for Centralized Conferencing". This identifier has been a fundamental concept in the XCON framework from the beginning and seems quite necessary. I think this draft is fairly complete and the identifier itself is already part of the data model, as pointed out by Oscar. =20 So, the questions would be how much more detail is necessary in this document and can it be accepted as a WG document? Regards, Mary _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon xm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback requested: draft-boulton-xcon-uri-00 Thread-Index: AccUpGVuaXSlIFacQki9/VbtYga4OQ== From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: cboulton@ubiquity.net Subject: [XCON] Feedback requested: draft-boulton-xcon-uri-00 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 Per discussions at IETF-67, here's the reminder that we'd like feedback on this draft: http://www.ietf.org/internet-drafts/draft-boulton-xcon-uri-00.txt This document defines a URI scheme and syntax for the conference object identifier, as defined in "A Framework and Data Model for Centralized Conferencing". This identifier has been a fundamental concept in the XCON framework from the beginning and seems quite necessary. I think this draft is fairly complete and the identifier itself is already part of the data model, as pointed out by Oscar. =20 So, the questions would be how much more detail is necessary in this document and can it be accepted as a WG document? Regards, Mary _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Nov 30 14:59:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gps3Z-0002Pv-Jc; Thu, 30 Nov 2006 14:58:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gps3Y-0002Pq-7Z for xcon@ietf.org; Thu, 30 Nov 2006 14:58:52 -0500 Received: from smtp8.libero.it ([193.70.192.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gps3W-0004gU-JX for xcon@ietf.org; Thu, 30 Nov 2006 14:58:52 -0500 Received: from localhost (172.16.1.79) by smtp8.libero.it (7.0.027-DD01) id 453F68F6030B98D1 for xcon@ietf.org; Thu, 30 Nov 2006 20:58:49 +0100 Received: from smtp2.libero.it ([172.16.1.225]) by localhost (asav1.libero.it [193.70.192.150]) (amavisd-new, port 10024) with ESMTP id 14003-12-7 for ; Thu, 30 Nov 2006 20:58:48 +0100 (CET) Received: from [192.168.1.100] (unknown [151.55.247.208]) by smtp2.libero.it (Postfix) with ESMTP id 9B795A8C18 for ; Thu, 30 Nov 2006 20:58:48 +0100 (MET) Message-ID: <456F37A1.6000502@libero.it> Date: Thu, 30 Nov 2006 20:57:21 +0100 From: Lorenzo Miniero User-Agent: Mozilla Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: xcon@ietf.org Subject: Re: [XCON] Feedback requested: draft-boulton-xcon-uri-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned: with antispam and antivirus automated system at libero.it Content-Transfer-Encoding: Quoted-Printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Mary, > Per discussions at IETF-67, here's the reminder that we'd like feedback > on this draft: > http://www.ietf.org/internet-drafts/draft-boulton-xcon-uri-00.txt > > This document defines a URI scheme and syntax for the conference object > identifier, as defined in "A Framework and Data Model for Centralized > Conferencing". > > This identifier has been a fundamental concept in the XCON framework > from the beginning and seems quite necessary. I think this draft is > fairly complete and the identifier itself is already part of the data > model, as pointed out by Oscar. =20 > > So, the questions would be how much more detail is necessary in this > document and can it be accepted as a WG document? > > Regards, > Mary > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > =20 I absolutely agree on the fact that such an identifier was needed in the=20 framework, and I'm glad that it has been proposed. What I still don't=20 understand after having the draft read, and I take advantage of this new=20 draft proposal to repeat a question I made some weeks ago on this ML and=20 got ignored: considering the conference joining matter, will this URI be=20 directly used to join conferences using a message of the=20 soon-to-come-CCP, or will only its unique token be used to compose=20 signaling URIs to access conferences using the relative CSP (e.g.=20 xcon:123@xxx --> sip:123@xxx)? I ask this since I consider the joining method matter very important in=20 a framework that by definition will (should?) not depend upon a specific=20 CSP for media, besides the fact that a running XCON conference could be=20 text-only as well, which would make a CSP almost useless. I personally=20 think (and I ask the opinion of you all about that) that it could very=20 well be a message of the CCP, which would allow an user to join the=20 conference as an 'abstract' object, with no set of resources accessed=20 yet (e.g. still no audio/video/text/etc) until the user states its will=20 to access one or more of them by means of the respective CSP (accessing=20 the URIs as mapped in this draft), or with some resource always=20 available by default upon joining (text, for example) and others that=20 can be latterly requested and accessed. Hope to hear from you soon, cheers, Lorenzo --=20 Lorenzo Miniero, Junior Researcher Dipartimento di Informatica e Sistemistica Universit=E0 degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) Phone: +390817683821 - Fax: +390817683816 Email: lminiero@napoli.consorzio-cini.it _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon