From xcon-bounces@ietf.org Thu Mar 02 05:18:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEktK-0003ZS-89; Thu, 02 Mar 2006 05:18:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEktI-0003ZN-IU for xcon@ietf.org; Thu, 02 Mar 2006 05:18:36 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEktI-0007OW-4C for xcon@ietf.org; Thu, 02 Mar 2006 05:18:36 -0500 Received: from rly27b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly27b.srv.mailcontrol.com (MailControl) with ESMTP id k22AIVav002643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Mar 2006 10:18:35 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly27b.srv.mailcontrol.com (MailControl) id k22AIRNl002564 for xcon@ietf.org; Thu, 2 Mar 2006 10:18:27 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly27b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k22AILCW002513; Thu, 02 Mar 2006 10:18:27 +0000 (GMT) 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] XCON Agenda Requests Date: Thu, 2 Mar 2006 10:18:21 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE03118969@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] XCON Agenda Requests Thread-Index: AcY7ESQW541+xWAmTpOUBcsXYO/6TAAgA6bgAAgNmgAAjBTF8A== From: "Chris Boulton" To: "Sean Olson" , "Adam Roach" , X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.66.1.137 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Alan Johnston X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org This is a good list which unfortunately has not been commented on - I believe that if we do nothing else in Dallas we must leave the room with this resolved. I'm pretty sure, as I originally started the main discussion with a proposal, that folks know my feelings. It must be remembered that even though list activity has been low, there are folks discussing behind the scenes who are willing and waiting to get this work done - we just need to get over this hurdle to make the effort worthwhile. Chris. I would second that and add that there are probably a number of sub-decisions that need to be made as well in support of a final decision on the control protocol: 1) Encoding: Binary, Text, or Both? 2) Operations: What is a reasonable list of operations that need to be supported in the first version of the protocol?=20 3) Multimedia: Is this just for audio/video or are we truly building a multimedia capable protocol? 4) Mobile: Is this just for mobile devices or are we truly building an intelligent endpoint capable protocol? 5) Best Practices: What practical implementation experience using BFCP or the conference event package can we leverage while designing the protocol? /sean -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: Monday, February 27, 2006 3:33 AM To: Adam Roach; xcon@ietf.org Cc: Alan Johnston Subject: RE: [XCON] XCON Agenda Requests We had an excellent discussion on the Control Protocol recently and if this work is to move forward we just need to bite the bullet and make a decision. =20 There are folks ready and waiting to get this work completed but this is a real sticking point for progress. Chris. -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: 26 February 2006 20:13 To: xcon@ietf.org Cc: Alan Johnston Subject: [XCON] XCON Agenda Requests [as chair] Anyone who would like agenda time during XCON at the upcoming 65th IETF meeting, please send me and Alan an email by Wednesday, March 8th; include a draft name and an approximate amount of time that you believe discussion will take. Thanks. /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 Thu Mar 02 06:35:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEm5E-0000bb-Tf; Thu, 02 Mar 2006 06:35:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEm5E-0000bR-9b for xcon@ietf.org; Thu, 02 Mar 2006 06:35:00 -0500 Received: from smtp3.wanadoo.co.uk ([193.252.22.156] helo=smtp3.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEm5C-00023y-RM for xcon@ietf.org; Thu, 02 Mar 2006 06:35:00 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3207.me.freeserve.com (SMTP Server) with ESMTP id A99F69000088 for ; Thu, 2 Mar 2006 12:34:53 +0100 (CET) Received: from RW (user-1289.lns4-c11.dsl.pol.co.uk [84.69.37.9]) by mwinf3207.me.freeserve.com (SMTP Server) with SMTP id 6A2CF9000083 for ; Thu, 2 Mar 2006 12:34:53 +0100 (CET) X-ME-UUID: 20060302113453435.6A2CF9000083@mwinf3207.me.freeserve.com Message-ID: <100301c63ded$50544000$b100a8c0@RW> From: "Pete Cordell" To: References: <45730E094814E44488F789C1CDED27AE03118969@gbnewp0758m.eu.ubiquity.net> Date: Thu, 2 Mar 2006 11:34:38 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Subject: [XCON] Encoding: Binary, Text, or Both and Lumas 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 just noticed that Chris's email mentioned that one of the points for debate was whether the XCON 'protocol' should be Binary, Text, or Both. I just wanted to mention that, as well as a text encoding, Lumas also has binary encoding rules. As already mentioned, there is already code to convert a Lumas definition into ABNF, and conceivably code could be written to convert Lumas into ASCII-art style drawings similar to that used in BFCP. Hence, by using a higher level of abstraction like Lumas you can make such details as text vs. binary vs. ABNF vs. ASCII-art an implementation detail! As before, more info on Lumas is at: http://www.tech-know-ware.com/lumas Regards, Pete. P.S. Further to my previous e-mail, to give you another idea of how a standard Lumas text message might look compared to other encodings, I've dug out a file I created a long time back that compares an old SIP message encoded using 'ABNF', Lumas and XML. Obviously in the latter 2 cases there are a number of ways that the encoding could have been done, so they should be considered for guidance only! Note also that in the case of Lumas and XML, line breaks have no significance so the line breaks shown are effectively pretty-print issues. Additionally, if I was doing a Lumas encoding of SIP I would have used shorter tag/header names more along the lines of SDP, but again, that's an implementation issue. ----------------- 'ABNF' --------------------- INVITE sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: T. Watson Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Subject: Mr. Watson, come here. Content-Type: application/sdp Content-Length: 111 v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 s=Mr. Watson, come here. c=IN IP4 kton.bell-tel.com m=audio 3456 RTP/AVP 0 3 4 5 --------------- LUMAS ------------------------ INVITE={sip:watson@boston.bell-tel.com SIP/2.0 Via={SIP/2.0/UDP kton.bell-tel.com} From={sip:a.g.bell@bell-tel.com "A. Bell"} To={sip:watson@bell-tel.com "T. Watson"} Call-ID=3298420296@kton.bell-tel.com CSeq={1 INVITE } Subject="Mr. Watson, come here." Content-Type=application/sdp } SDP={ v=0 o={bell 53655765 2353687637 IN=IP4=128.3.4.5} s="Mr. Watson, come here." c={IN=IP4=kton.bell-tel.com} m={audio 3456 RTP=AVP 0,3,4,5} } --------------- XML ---------------------- 3298420296@kton.bell-tel.com Mr. Watson, come here. Mr. Watson, come here. 0345 -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 03 08:20:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFACq-0007GT-58; Fri, 03 Mar 2006 08:20:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFACo-0007FO-8t for xcon@ietf.org; Fri, 03 Mar 2006 08:20:26 -0500 Received: from smtp2.wanadoo.co.uk ([193.252.22.157] helo=smtp2.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFACm-0004ty-W7 for xcon@ietf.org; Fri, 03 Mar 2006 08:20:26 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3102.me.freeserve.com (SMTP Server) with ESMTP id 64FD02400085 for ; Fri, 3 Mar 2006 14:20:24 +0100 (CET) Received: from RW (user-2785.lns2-c8.dsl.pol.co.uk [84.66.202.225]) by mwinf3102.me.freeserve.com (SMTP Server) with SMTP id 304592400084 for ; Fri, 3 Mar 2006 14:20:24 +0100 (CET) X-ME-UUID: 20060303132024197.304592400084@mwinf3102.me.freeserve.com Message-ID: <000601c63ec5$3a0826d0$0600a8c0@RW> From: "Pete Cordell" To: References: <45730E094814E44488F789C1CDED27AE03118969@gbnewp0758m.eu.ubiquity.net> <100301c63ded$50544000$b100a8c0@RW> Date: Fri, 3 Mar 2006 13:20:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [XCON] On-line Lumas 2 ABNF Converter 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 all, So that it is easier to experiment with, I have put a web interface version of the Lumas 2 ABNF converter on-line. You can see it at: http://tech-know-ware.com/lumas/2abnf.cgi The output could be tarted up, and there may be some errors in it, but I think it shows the principle. I've also put up an on-line definition checker at: http://tech-know-ware.com/lumas/check.cgi Regards, Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sun Mar 05 15:23:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFzlQ-0001TZ-SL; Sun, 05 Mar 2006 15:23:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFzlP-0001TU-S0 for xcon@ietf.org; Sun, 05 Mar 2006 15:23:35 -0500 Received: from smtp3.wanadoo.co.uk ([193.252.22.156] helo=smtp3.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFzlP-0000d2-FP for xcon@ietf.org; Sun, 05 Mar 2006 15:23:35 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3207.me.freeserve.com (SMTP Server) with ESMTP id BDD1E9000086 for ; Sun, 5 Mar 2006 21:23:34 +0100 (CET) Received: from RW (user-1993.wfd80a.dsl.pol.co.uk [84.64.231.201]) by mwinf3207.me.freeserve.com (SMTP Server) with SMTP id 883659000089 for ; Sun, 5 Mar 2006 21:23:34 +0100 (CET) X-ME-UUID: 20060305202334558.883659000089@mwinf3207.me.freeserve.com Message-ID: <003801c64092$ac634e70$0600a8c0@RW> From: "Pete Cordell" To: References: <45730E094814E44488F789C1CDED27AE03118969@gbnewp0758m.eu.ubiquity.net><100301c63ded$50544000$b100a8c0@RW> <000601c63ec5$3a0826d0$0600a8c0@RW> Date: Sun, 5 Mar 2006 20:23:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [XCON] On-line Lumas to C Compiler 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, I've now put on-line a Lumas to C compiler. This can be accessed at: http://tech-know-ware.com/lumas/2c.cgi Enter a Lumas definition and it will generate a corresponding C .h file and C .c file. This is far from commercial grade code (and most people would prefer Java / C++ / C# I guess), but once again, hopefully it shows the principle. One of the main limitations is the lack of documentation. Basically to encode a message you'd populate an instance of the C struct appropriately and then call the corresponding write routine. Similarly, when decoding a message, you'd call the appropriate read function and then interact with the resulting populated struct. If you do want to use the generated code, you will need to compile and link it with the code in the ZIP file mentioned when you get the C results. Regards, Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= ----- Original Message ----- From: "Pete Cordell" To: Sent: Friday, March 03, 2006 1:20 PM Subject: [XCON] On-line Lumas 2 ABNF Converter > Hi all, > > So that it is easier to experiment with, I have put a web interface > version of the Lumas 2 ABNF converter on-line. You can see it at: > > http://tech-know-ware.com/lumas/2abnf.cgi > > The output could be tarted up, and there may be some errors in it, but I > think it shows the principle. > > I've also put up an on-line definition checker at: > > http://tech-know-ware.com/lumas/check.cgi > > Regards, > > Pete. > -- > ============================================= > Pete Cordell > Tech-Know-Ware Ltd > for XML to C++ data binding visit > http://www.tech-know-ware.com/lmx > (or http://www.xml2cpp.com) > ============================================= _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sun Mar 05 15:31:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFzsd-0007ht-KA; Sun, 05 Mar 2006 15:31:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFzsb-0007gZ-Vq for xcon@ietf.org; Sun, 05 Mar 2006 15:31:01 -0500 Received: from smtp3.wanadoo.co.uk ([193.252.22.156] helo=smtp3.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFzsa-0000rI-Mn for xcon@ietf.org; Sun, 05 Mar 2006 15:31:01 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3208.me.freeserve.com (SMTP Server) with ESMTP id B3FC77400086 for ; Sun, 5 Mar 2006 21:30:59 +0100 (CET) Received: from RW (user-1993.wfd80a.dsl.pol.co.uk [84.64.231.201]) by mwinf3208.me.freeserve.com (SMTP Server) with SMTP id 814127400084 for ; Sun, 5 Mar 2006 21:30:59 +0100 (CET) X-ME-UUID: 20060305203059529.814127400084@mwinf3208.me.freeserve.com Message-ID: <003f01c64093$b59922c0$0600a8c0@RW> From: "Pete Cordell" To: References: <45730E094814E44488F789C1CDED27AE03118969@gbnewp0758m.eu.ubiquity.net><100301c63ded$50544000$b100a8c0@RW> <000601c63ec5$3a0826d0$0600a8c0@RW> Date: Sun, 5 Mar 2006 20:30:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [XCON] Refreshed Lumas I-D submitted 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've submitted a refreshed draft of the Lumas spec to replace the expired version. Until it becomes available in the archives, you can get it here: http://www.tech-know-ware.com/lumas/draft-cordell-lumas-04.txt Thanks, Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 07 02:39:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGWnB-0003s9-8y; Tue, 07 Mar 2006 02:39:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGWmq-0003eg-GN for xcon@ietf.org; Tue, 07 Mar 2006 02:39:16 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGWji-0004uP-Hs for xcon@ietf.org; Tue, 07 Mar 2006 02:36:09 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BDD603B6; Tue, 7 Mar 2006 08:36:01 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 08:36:01 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 08:36:01 +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 Date: Tue, 7 Mar 2006 08:36:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of the data model draft Thread-Index: AcYAbz2Ce/P5lmxiEdq0TwARJEEJ/AAEskTwEE1h7pA= From: "Oscar Novo \(JO/LMF\)" To: "XCON-IETF" X-OriginalArrivalTime: 07 Mar 2006 07:36:01.0270 (UTC) FILETIME=[C8597960:01C641B9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Dave.Morgan@fmr.com, "Gonzalo Camarillo \(JO/LMF\)" Subject: [XCON] New version of the data model draft 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, Yesterday, we submit the version 01 of the "A Common Conference Information Data Model for Centralized Conferencing" draft before the cutoff. Until it appears in the archives, you can fetch it from: http://users.piuha.net/gonzalo/temp/draft-novo-xcon-common-data-model-01 .txt Here's an overall summary of the changes: - New section Template (3.10.) explaining how to hook the templates in the data model. - Definition of new elements for the PSTN and H.323 protocols.=20 - Additional elements added (, , , etc...) - Modification of the handling of times in the data model. Now, it uses the RFC2445 iCal objects to talk about times and recurrence. - Added the XML schema of the document. Note that this XML schema is NOT validate yet. We will release a new version with the full validation of the XML schema later. Regards, Oscar _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 07 09:29:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdCC-00077d-84; Tue, 07 Mar 2006 09:29:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdCA-00077N-UR for xcon@ietf.org; Tue, 07 Mar 2006 09:29:50 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdC9-0004fC-JK for xcon@ietf.org; Tue, 07 Mar 2006 09:29:50 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k27ETkB23101 for ; Tue, 7 Mar 2006 09:29:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Mar 2006 08:29:16 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated XCON Framework Thread-Index: AcZB84MRMjhDuSOrS/uPEL7orrTfeg== From: "Mary Barnes" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [XCON] Updated XCON Framework 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 all, We have submitted updates to the XCON Framework. Until it's available in the repository, you can retrieve it from: http://home.comcast.net/~mary.barnes/IETF/draft-ietf-xcon-framework-03.t xt http://home.comcast.net/~mary.barnes/IETF/draft-ietf-xcon-framework-03.h tml The changes are as follows: * DP 4/4.1: CCI/templates (in/out) problem. Resolution per the thread:=20 http://www1.ietf.org/mail-archive/web/xcon/current/msg01602.html - Updated the definition of Blueprint=20 - Added text in 7.3, reiterating that the blueprint comprises both=20 the common conference information and a template. * DP 4.2: Defining new templates.=20 - Added text to section 5.2 per the thread indicating that adding new elements or modifying elements requires the definition of a new template:=20 http://www1.ietf.org/mail-archive/web/xcon/current/msg01603.html * DP 4.3: Can a blueprint contain more than one template?=20 - Added text to 7.3 per the thread (i.e., a blueprint is common conference information + one template, multiple templates is FFS):=20 http://www1.ietf.org/mail-archive/web/xcon/current/msg01568.html * Section 9.4 - Sidebars - add Ascii art to show FW interactions=20 * Section 9.5 - Added text (and definition upfront) for Whisper. Need to add more detail if basic concept is agreed.=20 * Section 9.6 - Conf Anncs and Recordings - added some general, high level text. Need to add more detail and example if basic concept is agreed.=20 * Section 8.3 - Updated the protocol section to include only those protocols under discussion per the 31 Dec 2005 deadline. =20 And, of course, that is the primary open issue. There was one other more minor issue that we need to discuss around the roles. Right now, we've defined roles in both the Common conference information and the templates. Based on our updated definition of a blueprint, you would always have a template within a blueprint, thus it would seem reasonable to have the roles defined in the templates. As always, additional feedback on the document is appreciated. Regards, Mary.=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Mar 08 20:47:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHAFn-0007hh-1h; Wed, 08 Mar 2006 20:47:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHAFl-0007gR-Qq for xcon@ietf.org; Wed, 08 Mar 2006 20:47:45 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHAFj-0005tT-Gw for xcon@ietf.org; Wed, 08 Mar 2006 20:47:45 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 8 Mar 2006 17:47:42 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.156]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 17:47:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Mar 2006 17:47:41 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A killing argument for SOAP-based Web Services approach for XCON thread-index: AcZDG3QKMaSCL4oDRl2La0bjfo4XfA== From: "Orit Levin" To: "XCON-IETF" X-OriginalArrivalTime: 09 Mar 2006 01:47:42.0738 (UTC) FILETIME=[74AE0F20:01C6431B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [XCON] A killing argument for SOAP-based Web Services approach for 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: , Content-Type: multipart/mixed; boundary="===============1606548857==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1606548857== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6431B.7473CBF9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6431B.7473CBF9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, Take a look at the list of Web Services being defined already by Parley X 2.0 /ETSI jointly with 3GPP... http://www.parlay.org/en/specifications/=20 =20 Take a look at "Part 12" specifically, Orit. ------_=_NextPart_001_01C6431B.7473CBF9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Guys,

Take a look at the list of Web Services being defined already by Parley X 2.0  /ETSI jointly with = 3GPP…

http://www.parlay.org/e= n/specifications/

 

Take a look at “Part = 12” specifically,

Orit.

------_=_NextPart_001_01C6431B.7473CBF9-- --===============1606548857== 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 --===============1606548857==-- From xcon-bounces@ietf.org Thu Mar 09 06:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJ0T-0007uk-NF; Thu, 09 Mar 2006 06:08:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJ08-0007hm-AQ for xcon@ietf.org; Thu, 09 Mar 2006 06:08:12 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHJ06-0005oJ-HU for xcon@ietf.org; Thu, 09 Mar 2006 06:08:12 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 65AB14F005F; Thu, 9 Mar 2006 12:08:09 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 12:08:09 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 12:08:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] A killing argument for SOAP-based Web Services approach forXCON Date: Thu, 9 Mar 2006 12:08:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] A killing argument for SOAP-based Web Services approach forXCON Thread-Index: AcZDG3QKMaSCL4oDRl2La0bjfo4XfAATCgFQ From: "Oscar Novo \(JO/LMF\)" To: "Orit Levin" , "XCON-IETF" X-OriginalArrivalTime: 09 Mar 2006 11:08:08.0895 (UTC) FILETIME=[BF6E6CF0:01C64369] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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: , Content-Type: multipart/mixed; boundary="===============1535413564==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1535413564== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64369.50AD0542" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64369.50AD0542 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Orit, =20 If you take a look the one year old 3GPP specifications, you can see most of them defined the CPCP protocol as the "conference control protocol" for XCON. If Parley X 2.0 /ETSI is using SOAP in their specifications is not enough reason (at least for me ) to discard the other proposals.=20 Oscar =20 ________________________________ From: Orit Levin [mailto:oritl@microsoft.com]=20 Sent: 9. maaliskuuta 2006 3:48 To: XCON-IETF Subject: [XCON] A killing argument for SOAP-based Web Services approach forXCON Guys, Take a look at the list of Web Services being defined already by Parley X 2.0 /ETSI jointly with 3GPP... http://www.parlay.org/en/specifications/=20 =20 Take a look at "Part 12" specifically, Orit. ------_=_NextPart_001_01C64369.50AD0542 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Orit,
 
If you=20 take a look the one year old 3GPP specifications, you can see most of = them=20 defined the CPCP protocol as the "conference control = protocol" for=20 XCON. If Parley X 2.0 /ETSI is using SOAP in their specifications is not = enough=20 reason (at least for me ) to discard the other proposals.=20

Oscar
 
From: Orit Levin = [mailto:oritl@microsoft.com]=20
Sent: 9. maaliskuuta 2006 3:48
To:=20 XCON-IETF
Subject: [XCON] A killing argument for SOAP-based = Web=20 Services approach forXCON

Guys,

Take a look at the list of = Web=20 Services being defined already by Parley X 2.0  /ETSI jointly with=20 3GPP…

http://www.parlay.org/e= n/specifications/=20

 

Take a look = at “Part=20 12” specifically,

Orit.

------_=_NextPart_001_01C64369.50AD0542-- --===============1535413564== 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 --===============1535413564==-- From xcon-bounces@ietf.org Thu Mar 09 06:55:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJjs-0004dq-9B; Thu, 09 Mar 2006 06:55:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJjr-0004dl-3s for xcon@ietf.org; Thu, 09 Mar 2006 06:55:27 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHJjp-0007LL-JF for xcon@ietf.org; Thu, 09 Mar 2006 06:55:27 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k29BtOLp004138 for ; Thu, 9 Mar 2006 12:55:24 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k29BtO3r017403 for ; Thu, 9 Mar 2006 12:55:24 +0100 Received: from MCHP7I5A.ww002.siemens.net ([139.25.131.136]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 12:55:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [XCON] A killing argument for SOAP-based Web Services approachforXCON Date: Thu, 9 Mar 2006 12:55:18 +0100 Message-ID: <784A66466728424D93027C59B6478B9E7782C2@MCHP7I5A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] A killing argument for SOAP-based Web Services approachforXCON Thread-Index: AcZDG3QKMaSCL4oDRl2La0bjfo4XfAATCgFQAAHK8pA= From: "Leis, Peter" To: "XCON-IETF" X-OriginalArrivalTime: 09 Mar 2006 11:55:23.0457 (UTC) FILETIME=[58F64310:01C64370] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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, 3GPP does _NOT_ refer to CPCP as "conference policy control protocol" in = its specs for conferencing in Rel-6. Even in Rel-7 the protocol to use for conferenc policy control is for = further study. regards Peter ________________________________ Von: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Gesendet: Donnerstag, 9. M=E4rz 2006 12:08 An: Orit Levin; XCON-IETF Betreff: RE: [XCON] A killing argument for SOAP-based Web Services = approachforXCON =09 =09 Hi Orit, =20 If you take a look the one year old 3GPP specifications, you can see = most of them defined the CPCP protocol as the "conference control = protocol" for XCON. If Parley X 2.0 /ETSI is using SOAP in their = specifications is not enough reason (at least for me ) to discard the = other proposals.=20 =09 Oscar =20 ________________________________ From: Orit Levin [mailto:oritl@microsoft.com]=20 Sent: 9. maaliskuuta 2006 3:48 To: XCON-IETF Subject: [XCON] A killing argument for SOAP-based Web Services approach = forXCON =09 =09 Guys, Take a look at the list of Web Services being defined already by Parley = X 2.0 /ETSI jointly with 3GPP... http://www.parlay.org/en/specifications/=20 =20 Take a look at "Part 12" specifically, Orit. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Mar 09 08:01:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKlL-0002oW-3F; Thu, 09 Mar 2006 08:01:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKlK-0002oR-8W for xcon@ietf.org; Thu, 09 Mar 2006 08:01:02 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHKlJ-0000ja-Q8 for xcon@ietf.org; Thu, 09 Mar 2006 08:01:02 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k29D10fk014434; Thu, 9 Mar 2006 14:01:00 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k29D10ua023264; Thu, 9 Mar 2006 14:01:00 +0100 Received: from MCHP7I5A.ww002.siemens.net ([139.25.131.136]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 14:00:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [XCON] A killing argument for SOAP-based Web ServicesapproachforXCON Date: Thu, 9 Mar 2006 14:00:57 +0100 Message-ID: <784A66466728424D93027C59B6478B9E7782C6@MCHP7I5A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] A killing argument for SOAP-based Web ServicesapproachforXCON Thread-Index: AcZDG3QKMaSCL4oDRl2La0bjfo4XfAATCgFQAAHK8pAAAc0qgAAArthA From: "Leis, Peter" To: "XCON-IETF" X-OriginalArrivalTime: 09 Mar 2006 13:00:58.0143 (UTC) FILETIME=[8237B2F0:01C64379] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 Oscar, CPCP was part of the early versions of 3GPP TS 24.147 in Release-6. = However, due to its immaturity CPCP was scratched from Release 6 in = November 2004 when Release 6 was frozen. For Rel-7 the situation with regards to CPCP has not changed, it is not = part of TS 24.147. regards Peter > -----Urspr=FCngliche Nachricht----- > Von: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 > Gesendet: Donnerstag, 9. M=E4rz 2006 13:52 > An: Leis, Peter > Betreff: RE: [XCON] A killing argument for SOAP-based Web=20 > ServicesapproachforXCON >=20 > Hello Peter, >=20 > I am not an expert in 3GPP but just as an example: >=20 > TS 24.147 document, section "A.3.6 Conference creation with=20 > CPCP" date 2004-09 (Release 6).=20 >=20 > This documentation is referring to=20 > draft-ietf-xcon-cpcp-xcap-00 one of the protocols proposed in=20 > the past by XCON.=20 >=20 > That's true in Rel-7 it doesn't appear because they decided=20 > to remove it from the specifications.=20 >=20 > O. >=20 > -----Original Message----- > From: Leis, Peter [mailto:peter.leis@siemens.com]=20 > Sent: 9. maaliskuuta 2006 13:55 > To: XCON-IETF > Subject: AW: [XCON] A killing argument for SOAP-based Web=20 > ServicesapproachforXCON >=20 > hello, >=20 > 3GPP does _NOT_ refer to CPCP as "conference policy control=20 > protocol" in its specs for conferencing in Rel-6. > Even in Rel-7 the protocol to use for conferenc policy=20 > control is for further study. >=20 > regards > Peter >=20 > ________________________________ >=20 > Von: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 > Gesendet: Donnerstag, 9. M=E4rz 2006 12:08 > An: Orit Levin; XCON-IETF > Betreff: RE: [XCON] A killing argument for SOAP-based=20 > Web Services approachforXCON > =09 > =09 > Hi Orit, > =20 > If you take a look the one year old 3GPP=20 > specifications, you can see most of them defined the CPCP=20 > protocol as the "conference control protocol" for XCON. If=20 > Parley X 2.0 /ETSI is using SOAP in their specifications is=20 > not enough reason (at least for me ) to discard the other proposals.=20 > =09 > Oscar > =20 > ________________________________ >=20 > From: Orit Levin [mailto:oritl@microsoft.com]=20 > Sent: 9. maaliskuuta 2006 3:48 > To: XCON-IETF > Subject: [XCON] A killing argument for SOAP-based Web=20 > Services approach forXCON > =09 > =09 >=20 > Guys, >=20 > Take a look at the list of Web Services being defined=20 > already by Parley X 2.0 /ETSI jointly with 3GPP... >=20 > http://www.parlay.org/en/specifications/=20 >=20 > =20 >=20 > Take a look at "Part 12" specifically, >=20 > Orit. >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Mar 09 10:19:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHMux-0002b8-Nf; Thu, 09 Mar 2006 10:19:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHMuv-0002U9-OX for xcon@ietf.org; Thu, 09 Mar 2006 10:19:05 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHMut-0005LD-QN for xcon@ietf.org; Thu, 09 Mar 2006 10:19:05 -0500 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly27b.srv.mailcontrol.com (MailControl) with ESMTP id k29FIG5x005292 for ; Thu, 9 Mar 2006 15:18:22 GMT x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Mar 2006 15:18:16 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE04E78C20@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Control Framework + Control Packages submission Thread-Index: AcZDjJX/5IsuzGocT96FU7rqhMc6ewAAAyKA From: "Chris Boulton" To: X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.66.0.137 X-Spam-Score: 0.0 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 Subject: [XCON] FW: Control Framework + Control Packages submission 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="===============1943672109==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1943672109== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6438C.B0D02C28" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6438C.B0D02C28 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sent for Information. =20 Chris. =20 =20 -----Original Message----- From: Chris Boulton=20 Sent: 09 March 2006 15:18 To: mediactrl@lists.ubiquitysoftware.com Cc: Tim Melanchuk; Asher Shiratzky; 'McGlashan, Scott'; 'Burger, Eric' Subject: Control Framework + Control Packages submission =20 Hi All, =20 The authors of the Control Framework and associated Control Packages have submitted the latest versions. The Control Framework and IVR package have been edited based on feedback received. VXML functionality has been split from the core IVR package into an IVR extension and there is also a new Control Package for Conference Control. More details provided below. =20 A Control Framework for the Session Initiation Protocol (SIP) =20 Until it appears in the archives can be found at draft-boulton-sip-control-framework-01.txt and draft-boulton-sip-control-framework-01.html . =20 A Basic Interactive Voice Response (IVR) Control Package for the Session Initiation Protocol (SIP) =20 Until it appears in the archives can be found at draft-boulton-ivr-control-package-01.txt and draft-boulton-ivr-control-package-01.html . =20 A VoiceXML Interactive Voice Response (IVR) Control Package for the Session Initiation Protocol (SIP) =20 Until it appears in the archives can be found at draft-boulton-ivr-vxml-control-package-00.txt and draft-boulton-ivr-vxml-control-package-00.html . =20 A Conference Control Package for the Session Initiation Protocol (SIP) =20 Until it appears in the archives can be found at draft-boulton-conference-control-package-00.txt and draft-boulton-conference-control-package-00.html . =20 Eric, please could you update the 'Mediactrl' web site. All comments gratefully received. =20 Best Regards, =20 Chris Boulton et al. =20 =20 =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_01C6438C.B0D02C28 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sent for Information.

 

Chris.

 

 

-----Original Message-----
From: Chris Boulton
Sent: 09= March 2006= 15:18=
To: mediactrl@lists.ubiquitysoftware.com
Cc: Tim Melanchuk; Asher Shiratzky; 'McGlashan, Scott'; 'Burger, Eric'
Subject: Control Framework + Control Packages submission

 

Hi All,

 

The authors of the Control Framework and associated Cont= rol Packages have submitted the latest versions.  The Control Framework and IVR package have been edited based on feedback received.  VXML functionality has been split from the core IVR package into an IVR extension and there is also a new Control Package for Conference Control.  More details provided below.

 

A Control Framework for the Session Initiation Protocol (SIP)

 

Until it appears in the archives can be found at = draft-boulton-sip-control-framework-01.txt and draft-boulton-sip-control-framework-01.html.<= /span>

 

A Basic Interactive Voice Response (IVR) Control Package for the Session Initiation Protocol (SIP)=

 

Until it appears in the archives can be found at = draft-boulton-ivr-control-package-01.txt and draft-boulton-ivr-control-package-01.html.<= /span>

 

A VoiceXML Interactive Voice Response (= IVR) Control Package for the Session Initiation Protocol (SIP)=

 

Until it appears in the archives can be found at = draft-boulton-ivr-vxml-control-package-00.txt and draft-boulton-ivr-vxml-control-package-00.html.<= /span>

 

A Conference Control Package for the Session Initiation Protocol (SIP)

 

Until it appears in the archives can be found at = draft-boulton-conference-control-package-00.txt  and draft-boulton-conference-control-package-00.html.<= /span>

 

Eric, please could you update the ‘Mediactrl’ web site.  All comments gratefully received.

 

Best Regards,

 

Chris Boulton et al.

 

 

 



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_01C6438C.B0D02C28-- --===============1943672109== 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 --===============1943672109==-- From xcon-bounces@ietf.org Thu Mar 09 12:32:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHP0I-0005Vi-AY; Thu, 09 Mar 2006 12:32:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHP0H-0005Vd-Hn for xcon@ietf.org; Thu, 09 Mar 2006 12:32:45 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHP0G-00012u-1r for xcon@ietf.org; Thu, 09 Mar 2006 12:32:45 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 9 Mar 2006 09:32:43 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.156]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 09:32:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] A killing argument for SOAP-based Web Services approach forXCON Date: Thu, 9 Mar 2006 09:32:40 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] A killing argument for SOAP-based Web Services approach forXCON thread-index: AcZDG3QKMaSCL4oDRl2La0bjfo4XfAATCgFQAA2GubA= From: "Orit Levin" To: "Oscar Novo \(JO/LMF\)" , "XCON-IETF" X-OriginalArrivalTime: 09 Mar 2006 17:32:43.0287 (UTC) FILETIME=[78D73A70:01C6439F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f 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: , Content-Type: multipart/mixed; boundary="===============1662617575==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1662617575== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6439F.78404C69" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6439F.78404C69 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I provided this link only as an additional input for the decision to be finally made :-) . =20 Your comment touches the same argument... 3GPP delegates the work to standardization bodies and expects working solutions... =20 Orit. =20 ________________________________ From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Thursday, March 09, 2006 3:08 AM To: Orit Levin; XCON-IETF Subject: RE: [XCON] A killing argument for SOAP-based Web Services approach forXCON =20 Hi Orit, =20 If you take a look the one year old 3GPP specifications, you can see most of them defined the CPCP protocol as the "conference control protocol" for XCON. If Parley X 2.0 /ETSI is using SOAP in their specifications is not enough reason (at least for me ) to discard the other proposals.=20 Oscar =20 ________________________________ From: Orit Levin [mailto:oritl@microsoft.com]=20 Sent: 9. maaliskuuta 2006 3:48 To: XCON-IETF Subject: [XCON] A killing argument for SOAP-based Web Services approach forXCON Guys, Take a look at the list of Web Services being defined already by Parley X 2.0 /ETSI jointly with 3GPP... http://www.parlay.org/en/specifications/=20 =20 Take a look at "Part 12" specifically, Orit. ------_=_NextPart_001_01C6439F.78404C69 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I provided this link only as an = additional input for the decision to be finally made J = .

 

Your comment touches the same = argument… 3GPP delegates the work to standardization bodies and expects working = solutions...

 

Orit.

 

From: Oscar = Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: Thursday, March 09, = 2006 3:08 AM
To: Orit Levin; = XCON-IETF
Subject: RE: [XCON] A = killing argument for SOAP-based Web Services approach forXCON

 

Hi Orit,

 

If you take a look the one year old = 3GPP specifications, you can see most of them defined the CPCP protocol as the "conference control protocol" for XCON. If = Parley X 2.0 /ETSI is using SOAP in their specifications is not enough reason (at = least for me ) to discard the other proposals.


Oscar

 

From: Orit Levin [mailto:oritl@microsoft.com]
Sent: 9. maaliskuuta 2006 = 3:48
To: XCON-IETF
Subject: [XCON] A killing = argument for SOAP-based Web Services approach forXCON

Guys,

Take a look at the list of Web Services being defined already by Parley X 2.0  /ETSI jointly with = 3GPP…

http://www.parlay.org/e= n/specifications/

 

Take a look at “Part = 12” specifically,

Orit.

------_=_NextPart_001_01C6439F.78404C69-- --===============1662617575== 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 --===============1662617575==-- From xcon-bounces@ietf.org Thu Mar 09 15:50:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS5d-0001nn-8T; Thu, 09 Mar 2006 15:50:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS5E-0000vp-TA; Thu, 09 Mar 2006 15:50:04 -0500 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 1FHS5E-0007EC-Qy; Thu, 09 Mar 2006 15:50:04 -0500 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FHS5C-0005Qm-C7; Thu, 09 Mar 2006 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko2vP024945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5B-000058-WB; Thu, 09 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 09 Mar 2006 15:50:01 -0500 X-Spam-Score: -2.6 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-framework-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : A Framework and Data Model for Centralized Conferencing Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-framework-02.txt Pages : 56 Date : 2005-10-27 This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions, along with a conferencing data model. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-framework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-framework-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-9112337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9112337.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --NextPart-- From xcon-bounces@ietf.org Thu Mar 09 19:02:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHV56-00041V-HE; Thu, 09 Mar 2006 19:02:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHV54-00040l-FE for xcon@ietf.org; Thu, 09 Mar 2006 19:02:06 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHV54-0007ul-31 for xcon@ietf.org; Thu, 09 Mar 2006 19:02:06 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2A023l29188 for ; Thu, 9 Mar 2006 19:02:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C643D5.DB684CEC" Subject: FW: [XCON] I-D ACTION:draft-ietf-xcon-framework-02.txt Date: Thu, 9 Mar 2006 18:02:01 -0600 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [XCON] I-D ACTION:draft-ietf-xcon-framework-02.txt Thread-Index: AcZDu2cI5PJZbJZ4QiuHaVK1mCEYuQAGjUaw From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C643D5.DB684CEC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This is not the correct version of the FW document. I just double-checked my email and I did send them a -03. Until that gets corrected, please pull the document from my server: http://home.comcast.net/~mary.barnes/IETF/draft-ietf-xcon-framework-03.t xt http://home.comcast.net/~mary.barnes/IETF/draft-ietf-xcon-framework-03.h tml Mary -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Thursday, March 09, 2006 2:50 PM To: i-d-announce@ietf.org Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-framework-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : A Framework and Data Model for Centralized Conferencing Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-framework-02.txt Pages : 56 Date : 2005-10-27 =09 This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions, along with a conferencing data model. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-02.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-framework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-framework-02.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C643D5.DB684CEC Content-Type: application/octet-stream; name="ATT791612.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT791612.TXT Content-Disposition: attachment; filename="ATT791612.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi0zLTkxMTIzMzcuSS1EQGlldGYub3JnPg0KDQpFTkNP RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi14Y29uLWZyYW1ld29y ay0wMi50eHQNCg== ------_=_NextPart_001_01C643D5.DB684CEC Content-Type: application/octet-stream; name="draft-ietf-xcon-framework-02.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-xcon-framework-02.URL Content-Disposition: attachment; filename="draft-ietf-xcon-framework-02.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXhjb24tZnJhbWV3b3JrLTAyLnR4dA0K ------_=_NextPart_001_01C643D5.DB684CEC Content-Type: text/plain; name="ATT791613.txt" Content-Transfer-Encoding: base64 Content-Description: ATT791613.txt Content-Disposition: attachment; filename="ATT791613.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClhDT04gbWFp bGluZyBsaXN0DQpYQ09OQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby94Y29uDQo= ------_=_NextPart_001_01C643D5.DB684CEC Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon ------_=_NextPart_001_01C643D5.DB684CEC-- From xcon-bounces@ietf.org Fri Mar 10 02:57:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHcVN-0007zO-1r; Fri, 10 Mar 2006 02:57:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHcU2-0006iB-MX; Fri, 10 Mar 2006 02:56:22 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHcNu-0004Wc-96; Fri, 10 Mar 2006 02:50:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k2A7o10e028043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Mar 2006 07:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHcNt-0001xq-S8; Fri, 10 Mar 2006 02:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 10 Mar 2006 02:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-framework-03.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : A Framework and Data Model for Centralized Conferencing Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-framework-03.txt Pages : 56 Date : 2006-3-9 This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions, along with a conferencing data model. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-framework-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-framework-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-9194021.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-framework-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9194021.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --NextPart-- From xcon-bounces@ietf.org Fri Mar 10 04:27:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdu3-0005lQ-5K; Fri, 10 Mar 2006 04:27:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdu0-0005kT-Ui for xcon@ietf.org; Fri, 10 Mar 2006 04:27:16 -0500 Received: from smtp1.wanadoo.co.uk ([193.252.22.158] helo=smtp1.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHdu0-00005e-Fm for xcon@ietf.org; Fri, 10 Mar 2006 04:27:16 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3007.me.freeserve.com (SMTP Server) with ESMTP id 1E7F31C0008E; Fri, 10 Mar 2006 10:27:16 +0100 (CET) Received: from RW (user-5477.lns6-c10.dsl.pol.co.uk [84.68.181.101]) by mwinf3007.me.freeserve.com (SMTP Server) with SMTP id CC64B1C00082; Fri, 10 Mar 2006 10:27:15 +0100 (CET) X-ME-UUID: 20060310092715837.CC64B1C00082@mwinf3007.me.freeserve.com Message-ID: <008e01c64424$d245a990$0600a8c0@RW> From: "Pete Cordell" To: "Oscar Novo (JO/LMF)" References: Date: Fri, 10 Mar 2006 09:27:06 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: XCON-IETF Subject: [XCON] Re: I-D ACTION:draft-novo-xcon-common-data-model-01.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Oscar, I had a quick scan of the XSD in this draft and noticed that you had defined some choices using the form: ... rather than simply (?): ... Is it intended to be an extensibility mechanism? Cheers, Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= ----- Original Message ----- From: To: Sent: Thursday, March 09, 2006 8:50 PM Subject: I-D ACTION:draft-novo-xcon-common-data-model-01.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : A Common Conference Information Data Model > for Centralized Conferencing (XCON) > Author(s) : O. Novo, et al. > Filename : draft-novo-xcon-common-data-model-01.txt > Pages : 49 > Date : 2006-3-9 > > This document collects, organizes, and describes the conference > variables that have been introduced in various protocol drafts of the > XCON and SIPPING working groups. The goal of this document is to > allow the conference control protocols to use a unified common > conference information data model for XCON. This document formally > defines an Extensible Markup Language (XML) Schema that represents > the common conference information in a conferencing server. The > information is modeled as a series of elements, each of which > contains a set of children and attributes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-novo-xcon-common-data-model-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-novo-xcon-common-data-model-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-novo-xcon-common-data-model-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 10 04:27:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdu3-0005lt-Aw; Fri, 10 Mar 2006 04:27:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdu1-0005lD-UU for xcon@ietf.org; Fri, 10 Mar 2006 04:27:17 -0500 Received: from smtp1.wanadoo.co.uk ([193.252.22.158] helo=smtp1.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHdu0-00005d-Ev for xcon@ietf.org; Fri, 10 Mar 2006 04:27:17 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3007.me.freeserve.com (SMTP Server) with ESMTP id B59F51C0008C for ; Fri, 10 Mar 2006 10:27:15 +0100 (CET) Received: from RW (user-5477.lns6-c10.dsl.pol.co.uk [84.68.181.101]) by mwinf3007.me.freeserve.com (SMTP Server) with SMTP id 6E7971C00082 for ; Fri, 10 Mar 2006 10:27:15 +0100 (CET) X-ME-UUID: 20060310092715452.6E7971C00082@mwinf3007.me.freeserve.com Message-ID: <008d01c64424$d203e5a0$0600a8c0@RW> From: "Pete Cordell" To: "XCON-IETF" Date: Fri, 10 Mar 2006 09:13:08 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0044_01C64422.D8B31670" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Subject: [XCON] Fw: I-D ACTION:draft-cordell-lumas-04.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C64422.D8B31670 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit FYI - This draft is now refreshed in the archives. It took slightly longer than expected because I had an old reference to the IPR RFC. Thankfully the I-D staff managed to do a good job and turn around my amended doc. BTW - You may not need to read all of it to get an idea of what is being proposed. You probably only need to look at the following (about 4 pages with example) to understand the message definition format: 5. Lumas Message Definition 5.1 Basic Principles of the Message Definition 5.2 An Example Message Definition and the following (which amounts to about 1 1/2 pages) to understand the default text based encoded message format: 6. On-the-Wire Representation 6.1 Principles of On-the-Wire Encoding 6.2 Example On-the-Wire Representation Regards, Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= ----- Original Message ----- From: To: Sent: Thursday, March 09, 2006 11:50 PM Subject: I-D ACTION:draft-cordell-lumas-04.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Lumas - Language for Universal Message Abstraction and > Specification > Author(s) : P. Cordell > Filename : draft-cordell-lumas-04.txt > Pages : 44 > Date : 2006-3-9 > > A number of methods and tools are available for defining the format > of messages used for application protocols. However, many of these > methods and tools have been designed for purposes other than message > definition, and have been adopted on the basis that they are > available rather than being ideally suited to the task. This often > means that the methods make it difficult to get definitions correct, > or result in unnecessary complexity and verbosity both in the > definition and on the wire. > > Lumas - Language for Universal Message Abstraction and Specification > - has been custom designed for the purpose of message definition. It > is thus easy to specify messages in a compact, extensible format that > is readily machine manipulated to produce a compact encoding on the > wire. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cordell-lumas-04.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-cordell-lumas-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-cordell-lumas-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > ------=_NextPart_000_0044_01C64422.D8B31670 Content-Type: application/octet-stream; name="ATT00052.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00052.dat" Content-Type: text/plain Content-ID: <2006-3-9152220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cordell-lumas-04.txt ------=_NextPart_000_0044_01C64422.D8B31670 Content-Type: text/plain; format=flowed; name="draft-cordell-lumas-04.txt"; reply-type=original Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-cordell-lumas-04.txt" Content-Type: text/plain Content-ID: <2006-3-9152220.I-D@ietf.org> ------=_NextPart_000_0044_01C64422.D8B31670 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon ------=_NextPart_000_0044_01C64422.D8B31670-- From xcon-bounces@ietf.org Mon Mar 13 17:23:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvRM-0003r5-B8; Mon, 13 Mar 2006 17:23:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvRK-0003r0-T6 for xcon@ietf.org; Mon, 13 Mar 2006 17:22:58 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIvRJ-0007du-E3 for xcon@ietf.org; Mon, 13 Mar 2006 17:22:58 -0500 Received: from [172.17.2.251] ([172.17.2.251]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2DMMu9A031990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Mar 2006 16:22:56 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <4415F0DD.6060503@estacado.net> Date: Mon, 13 Mar 2006 16:23:25 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell Subject: Re: [XCON] Encoding: Binary, Text, or Both and Lumas References: <45730E094814E44488F789C1CDED27AE03118969@gbnewp0758m.eu.ubiquity.net> <100301c63ded$50544000$b100a8c0@RW> In-Reply-To: <100301c63ded$50544000$b100a8c0@RW> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 [as chair] While the Developer in me thinks Lumas looks really cool and would be a barrel of monkeys to play around with, the Working Group Chair in me requires me to exclude it from consideration. After floundering in this area for a while, we had a deadline a few months ago on new proposals for the conference manipulation protocol. Consequently, we cannot take on additional candidates at this time. The protocol will be selected from the set of CCCP, CSCP, or some variant on the SOAP proposals. /a Pete Cordell wrote: > I just noticed that Chris's email mentioned that one of the points for > debate was whether the XCON 'protocol' should be Binary, Text, or > Both. I just wanted to mention that, as well as a text encoding, > Lumas also has binary encoding rules. > > As already mentioned, there is already code to convert a Lumas > definition into ABNF, and conceivably code could be written to convert > Lumas into ASCII-art style drawings similar to that used in BFCP. > > Hence, by using a higher level of abstraction like Lumas you can make > such details as text vs. binary vs. ABNF vs. ASCII-art an > implementation detail! > > As before, more info on Lumas is at: http://www.tech-know-ware.com/lumas > > Regards, > > Pete. > > P.S. Further to my previous e-mail, to give you another idea of how a > standard Lumas text message might look compared to other encodings, > I've dug out a file I created a long time back that compares an old > SIP message encoded using 'ABNF', Lumas and XML. Obviously in the > latter 2 cases there are a number of ways that the encoding could have > been done, so they should be considered for guidance only! Note also > that in the case of Lumas and XML, line breaks have no significance so > the line breaks shown are effectively pretty-print issues. > Additionally, if I was doing a Lumas encoding of SIP I would have used > shorter tag/header names more along the lines of SDP, but again, > that's an implementation issue. > > ----------------- 'ABNF' --------------------- > > INVITE sip:watson@boston.bell-tel.com SIP/2.0 > Via: SIP/2.0/UDP kton.bell-tel.com > From: A. Bell > To: T. Watson > Call-ID: 3298420296@kton.bell-tel.com > CSeq: 1 INVITE > Subject: Mr. Watson, come here. > Content-Type: application/sdp > Content-Length: 111 > > v=0 > o=bell 53655765 2353687637 IN IP4 128.3.4.5 > s=Mr. Watson, come here. > c=IN IP4 kton.bell-tel.com > m=audio 3456 RTP/AVP 0 3 4 5 > > --------------- LUMAS ------------------------ > > INVITE={sip:watson@boston.bell-tel.com SIP/2.0 > Via={SIP/2.0/UDP kton.bell-tel.com} > From={sip:a.g.bell@bell-tel.com "A. Bell"} > To={sip:watson@bell-tel.com "T. Watson"} > Call-ID=3298420296@kton.bell-tel.com > CSeq={1 INVITE } > Subject="Mr. Watson, come here." > Content-Type=application/sdp > } > SDP={ > v=0 > o={bell 53655765 2353687637 IN=IP4=128.3.4.5} > s="Mr. Watson, come here." > c={IN=IP4=kton.bell-tel.com} > m={audio 3456 RTP=AVP 0,3,4,5} > } > > > --------------- XML ---------------------- > > > > > > > 3298420296@kton.bell-tel.com > > Mr. Watson, come here. > > > > > Mr. Watson, come here. > > > 0345 > > > -- > ============================================= > Pete Cordell > Tech-Know-Ware Ltd > for XML to C++ data binding visit > http://www.tech-know-ware.com/lmx > (or http://www.xml2cpp.com) > ============================================= > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Mar 13 17:23:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvS5-0004U9-Jg; Mon, 13 Mar 2006 17:23:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvS4-0004U4-W0 for xcon@ietf.org; Mon, 13 Mar 2006 17:23:44 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIvS2-0007ez-Ho for xcon@ietf.org; Mon, 13 Mar 2006 17:23:44 -0500 Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2DMNecF018341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Mar 2006 16:23:41 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4415F10A.8030807@nostrum.com> Date: Mon, 13 Mar 2006 16:24:10 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell Subject: Re: [XCON] Encoding: Binary, Text, or Both and Lumas References: <45730E094814E44488F789C1CDED27AE03118969@gbnewp0758m.eu.ubiquity.net> <100301c63ded$50544000$b100a8c0@RW> In-Reply-To: <100301c63ded$50544000$b100a8c0@RW> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 093efd19b5f651b2707595638f6c4003 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 [as chair] While the Developer in me thinks Lumas looks really cool and would be a barrel of monkeys to play around with, the Working Group Chair in me requires me to exclude it from consideration. After floundering in this area for a while, we had a deadline a few months ago on new proposals for the conference manipulation protocol. Consequently, we cannot take on additional candidates at this time. The protocol will be selected from the set of CCCP, CSCP, or some variant on the SOAP proposals. /a Pete Cordell wrote: > I just noticed that Chris's email mentioned that one of the points for > debate was whether the XCON 'protocol' should be Binary, Text, or > Both. I just wanted to mention that, as well as a text encoding, > Lumas also has binary encoding rules. > > As already mentioned, there is already code to convert a Lumas > definition into ABNF, and conceivably code could be written to convert > Lumas into ASCII-art style drawings similar to that used in BFCP. > > Hence, by using a higher level of abstraction like Lumas you can make > such details as text vs. binary vs. ABNF vs. ASCII-art an > implementation detail! > > As before, more info on Lumas is at: http://www.tech-know-ware.com/lumas > > Regards, > > Pete. > > P.S. Further to my previous e-mail, to give you another idea of how a > standard Lumas text message might look compared to other encodings, > I've dug out a file I created a long time back that compares an old > SIP message encoded using 'ABNF', Lumas and XML. Obviously in the > latter 2 cases there are a number of ways that the encoding could have > been done, so they should be considered for guidance only! Note also > that in the case of Lumas and XML, line breaks have no significance so > the line breaks shown are effectively pretty-print issues. > Additionally, if I was doing a Lumas encoding of SIP I would have used > shorter tag/header names more along the lines of SDP, but again, > that's an implementation issue. > > ----------------- 'ABNF' --------------------- > > INVITE sip:watson@boston.bell-tel.com SIP/2.0 > Via: SIP/2.0/UDP kton.bell-tel.com > From: A. Bell > To: T. Watson > Call-ID: 3298420296@kton.bell-tel.com > CSeq: 1 INVITE > Subject: Mr. Watson, come here. > Content-Type: application/sdp > Content-Length: 111 > > v=0 > o=bell 53655765 2353687637 IN IP4 128.3.4.5 > s=Mr. Watson, come here. > c=IN IP4 kton.bell-tel.com > m=audio 3456 RTP/AVP 0 3 4 5 > > --------------- LUMAS ------------------------ > > INVITE={sip:watson@boston.bell-tel.com SIP/2.0 > Via={SIP/2.0/UDP kton.bell-tel.com} > From={sip:a.g.bell@bell-tel.com "A. Bell"} > To={sip:watson@bell-tel.com "T. Watson"} > Call-ID=3298420296@kton.bell-tel.com > CSeq={1 INVITE } > Subject="Mr. Watson, come here." > Content-Type=application/sdp > } > SDP={ > v=0 > o={bell 53655765 2353687637 IN=IP4=128.3.4.5} > s="Mr. Watson, come here." > c={IN=IP4=kton.bell-tel.com} > m={audio 3456 RTP=AVP 0,3,4,5} > } > > > --------------- XML ---------------------- > > > > > > > 3298420296@kton.bell-tel.com > > Mr. Watson, come here. > > > > > Mr. Watson, come here. > > > 0345 > > > -- > ============================================= > Pete Cordell > Tech-Know-Ware Ltd > for XML to C++ data binding visit > http://www.tech-know-ware.com/lmx > (or http://www.xml2cpp.com) > ============================================= > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Mar 13 17:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvVu-0007a2-C0; Mon, 13 Mar 2006 17:27:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvVs-0007Zx-Ns for xcon@ietf.org; Mon, 13 Mar 2006 17:27:40 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIvVr-0007kz-Fc for xcon@ietf.org; Mon, 13 Mar 2006 17:27:40 -0500 Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2DMRc8h018598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Mar 2006 16:27:39 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4415F1F8.3060801@nostrum.com> Date: Mon, 13 Mar 2006 16:28:08 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcon@ietf.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 7d33c50f3756db14428398e2bdedd581 Subject: [XCON] Action Required: Meeting Preparation 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] The preliminary agenda for our upcoming meeting next week has been posted: http://www.softarmor.com/xcon/meets/ietf65/agenda.pl In preparation for this session, I implore everyone to make themselves familiar with the protocol proposals. It is the chairs' intention that we will leave Dallas with a decision on a conference state manipulation protocol. The specific documents to familiarize yourself with are: draft-levin-xcon-cccp-04.txt draft-jennings-xcon-cscp-03.txt draft-barnes-xcon-ccmp-00.txt draft-schulzrinne-xcon-comp-00.txt These are all conveniently linked off the agenda page. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Mar 15 13:25:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJagQ-00082V-VL; Wed, 15 Mar 2006 13:25:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJagP-00082Q-Nl for xcon@ietf.org; Wed, 15 Mar 2006 13:25:17 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJagO-0002QA-DP for xcon@ietf.org; Wed, 15 Mar 2006 13:25:17 -0500 Received: from [172.17.2.251] ([172.17.2.251]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2FIPAQ6027305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Mar 2006 12:25:11 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <44185C7C.9030201@estacado.net> Date: Wed, 15 Mar 2006 12:27:08 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Oscar Novo (JO/LMF)" Subject: Re: [XCON] New version of the data model draft References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Dave.Morgan@fmr.com, XCON-IETF , "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 (not as chair) Oscar Novo (JO/LMF) wrote: >Hello, > >Yesterday, we submit the version 01 of the "A Common Conference >Information Data Model for Centralized Conferencing" draft before the >cutoff. > > ... >- Modification of the handling of times in the data model. Now, it uses >the RFC2445 iCal objects to talk about times and recurrence. > > Thanks; this looks much better. One comment: indicating , , and the other offsets as absolute times doesn't appear to make much sense. If you have a time object indicating a recurrence, but the various <...-offset> objects indicating absolute times, it's a bit difficult to apply the offsets to later occurrences of the conference. I would instead propose expressing such offsets as (e.g.) signed integers representing seconds before/after the DTSTART field (for , and ) and seconds before/after the DTEND field (for ). So, the example in the document would become: BEGIN:VCALENDAR PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:20051103T140728Z UID:carol at example.com ORGANIZER:MAILTO:carol at example.com DTSTART:20061017T143000Z RRULE:FREQ=WEEKLY DTEND:20061017T163000Z -15 60 600 ...which means that mixing starts 15 seconds before the start time and ends 60 seconds after the end time. It also means that participants must join within the first 10 minutes (600 seconds) of the conference. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Mar 15 14:08:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbMT-0004ms-Uq; Wed, 15 Mar 2006 14:08:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbMR-0004mm-Ri for xcon@ietf.org; Wed, 15 Mar 2006 14:08:43 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbMR-0003qA-Gy for xcon@ietf.org; Wed, 15 Mar 2006 14:08:43 -0500 Received: from [172.17.2.251] ([172.17.2.251]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2FJ8a05036432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Mar 2006 13:08:37 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <441866AA.9080504@estacado.net> Date: Wed, 15 Mar 2006 13:10:34 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Why Size Really Can Matter (was Re: [XCON] Conference Control) References: <45730E094814E44488F789C1CDED27AE03118907@gbnewp0758m.eu.ubiquity.net> <43DA4377.5020900@cs.columbia.edu> In-Reply-To: <43DA4377.5020900@cs.columbia.edu> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by vicuna.estacado.net id k2FJ8a05036432 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Adam Roach , Chris Boulton , xcon@ietf.org, ajohnston@tello.com 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 (not as chair) Because I've spent an inordinate amount of time over the past 5 years=20 working with issues surrounding mobile terminals, signaling size,=20 latency, and compression, I wanted to throw in a couple of relevant=20 points on the topic of message sizes. Henning Schulzrinne wrote: >> */[Chris Boulton] I get the handset bandwidth =96 I have heard it in=20 >> almost every IETF meeting I=92ve been to + I also agree it=92s a major= =20 >> consideration BUT lets not just keep harping back to it./* >> > > This is largely a bogus argument. In any multimedia conference, the=20 > control bandwidth is going to be a tiny fraction of the overall=20 > bandwidth consumed by media. Right now, more than one major US wireless carrier has deployed voice=20 services over their existing data networks, which nominally pass 9.6kbps=20 of data; once you factor in overhead, the real data throughput of these=20 data connections is on the order of 8kbps. (I use these carriers as data=20 points because I'm familiar with them; I would guess that similar=20 deployments have been made in other countries as well). In order to pass voice over these connections, carriers are generally=20 using codecs like half-rate EVRC, which consumes 4kbps. This leaves on=20 the order of 4kbps to perform signaling. Using the examples in the CCCP, COMP, and CSCP proposals, a=20 representative request/response exchange takes on the order of the=20 following sizes: - CCCP: ~1800 bytes - COMP: ~700 bytes - CSCP: ~156 bytes Over the 4kbps available on these actually deployed voice systems, these=20 exchanges will take the following amounts of time: - CCCP: ~3.6 seconds - COMP: ~1.4 seconds - CSCP: ~300 ms This raises an issue around how long users will be willing to wait=20 between requesting an action and it taking effect. Is it okay for it to=20 take several seconds to adjust a volume level or mute a participant? > Have you actually measured the latency for compression? We're =20 > probably talking 2-3 ms here, based on my experience. > For the middle-of-the-line mobile terminals in wide use today (~100 MHz=20 processors), running deflate over a 1kb message (the order of messages=20 we're talking about here) is on the order of 100 ms. Not outrageous, but=20 not trivial. The bigger issue by an order of magnitude is the fact that=20 doing this on the CPU requires 100% CPU utilization during this time=20 period, which impacts battery life probably more than you would expect.=20 (700 mAh doesn't take you too far when it's expected to last several days= ). /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Mar 15 14:26:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbdx-0004Io-IM; Wed, 15 Mar 2006 14:26:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbdw-0004Ij-HR for xcon@ietf.org; Wed, 15 Mar 2006 14:26:48 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbdw-0004T2-2I for xcon@ietf.org; Wed, 15 Mar 2006 14:26:48 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 15 Mar 2006 11:26:47 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 11:26:46 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 11:26:46 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 11:26:46 -0800 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: Why Size Really Can Matter (was Re: [XCON] Conference Control) Date: Wed, 15 Mar 2006 11:26:45 -0800 Message-ID: In-Reply-To: <441866AA.9080504@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why Size Really Can Matter (was Re: [XCON] Conference Control) thread-index: AcZIZBcIfARwS3K3SM+/azVksii0YAAAFE/A From: "Sean Olson" To: "Adam Roach" , "Henning Schulzrinne" X-OriginalArrivalTime: 15 Mar 2006 19:26:46.0189 (UTC) FILETIME=[6601B5D0:01C64866] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Chris Boulton , Adam Roach , xcon@ietf.org, ajohnston@tello.com X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org This is a great analysis of why we have to be mindful of bandwidth and processing on mobile devices. Now let's talk about why limiting every device that wants to do conferencing to these same constraints may not make sense.=20 First, there is multimedia where you won't always be able to squeeze the media into 4Kbps (or want to). This includes many video codecs, application sharing, file exchange, etc. Second, there are advanced conferencing applications which may require truly intelligent endpoints (pushing the 100MHz envelope ;-). Examples include application sharing for CAD/CAM, advanced cascading architectures, bots as moderators, gaming, etc.=20 Third, there are many conferencing scenarios that may not involve a mobile device at all. Of course these scenarios can benefit from the reach of mobile technology, but there are simply cases where a mobile device does not fit. Examples include conferencing capabilities integrated with factory processes, web conferencing for B2C, customer service kiosks, etc. I'm very much in favor of designing a protocol which works and makes sense for mobile devices. I don't want to hobble the rest of the system in order to make this work. Could we do two different encodings of the same base protocol? -----Original Message----- From: Adam Roach [mailto:adam@estacado.net]=20 Sent: Wednesday, March 15, 2006 11:11 AM To: Henning Schulzrinne Cc: Adam Roach; Chris Boulton; xcon@ietf.org; ajohnston@tello.com Subject: Why Size Really Can Matter (was Re: [XCON] Conference Control) (not as chair) Because I've spent an inordinate amount of time over the past 5 years working with issues surrounding mobile terminals, signaling size, latency, and compression, I wanted to throw in a couple of relevant points on the topic of message sizes. Henning Schulzrinne wrote: >> */[Chris Boulton] I get the handset bandwidth - I have heard it in=20 >> almost every IETF meeting I've been to + I also agree it's a major=20 >> consideration BUT lets not just keep harping back to it./* >> > > This is largely a bogus argument. In any multimedia conference, the=20 > control bandwidth is going to be a tiny fraction of the overall=20 > bandwidth consumed by media. Right now, more than one major US wireless carrier has deployed voice services over their existing data networks, which nominally pass 9.6kbps of data; once you factor in overhead, the real data throughput of these data connections is on the order of 8kbps. (I use these carriers as data points because I'm familiar with them; I would guess that similar deployments have been made in other countries as well). In order to pass voice over these connections, carriers are generally using codecs like half-rate EVRC, which consumes 4kbps. This leaves on the order of 4kbps to perform signaling. Using the examples in the CCCP, COMP, and CSCP proposals, a representative request/response exchange takes on the order of the following sizes: - CCCP: ~1800 bytes - COMP: ~700 bytes - CSCP: ~156 bytes Over the 4kbps available on these actually deployed voice systems, these exchanges will take the following amounts of time: - CCCP: ~3.6 seconds - COMP: ~1.4 seconds - CSCP: ~300 ms This raises an issue around how long users will be willing to wait between requesting an action and it taking effect. Is it okay for it to take several seconds to adjust a volume level or mute a participant? > Have you actually measured the latency for compression? We're probably > talking 2-3 ms here, based on my experience. > For the middle-of-the-line mobile terminals in wide use today (~100 MHz=20 processors), running deflate over a 1kb message (the order of messages=20 we're talking about here) is on the order of 100 ms. Not outrageous, but not trivial. The bigger issue by an order of magnitude is the fact that=20 doing this on the CPU requires 100% CPU utilization during this time=20 period, which impacts battery life probably more than you would expect.=20 (700 mAh doesn't take you too far when it's expected to last several days). /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 Wed Mar 15 14:34:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbkx-0000HI-E8; Wed, 15 Mar 2006 14:34:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbkw-0000C2-3b for xcon@ietf.org; Wed, 15 Mar 2006 14:34:02 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbkv-0004bM-O6 for xcon@ietf.org; Wed, 15 Mar 2006 14:34:02 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FJbkI-0004iO-MB; Wed, 15 Mar 2006 13:33:23 -0600 From: "Brian Rosen" To: "'Sean Olson'" , "'Adam Roach'" , "'Henning Schulzrinne'" Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control) Date: Wed, 15 Mar 2006 14:33:25 -0500 Message-ID: <293e01c64867$55f6b220$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.2670 Thread-Index: AcZIZBcIfARwS3K3SM+/azVksii0YAAAFE/AAACOuPA= In-Reply-To: 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: 2beba50d0fcdeee5f091c59f204d4365 Cc: 'Chris Boulton' , 'Adam Roach' , xcon@ietf.org, ajohnston@tello.com X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I'm sorry, but I don't quite get this. Are you saying that CSCP somehow hobbles devices that are multimedia endpoints consuming oodles of bandwidth? I'd agree with your sentiments if there was actually a substantive difference in what you can DO with the protocols. Right now, while there are some very clear model differences, as well as very clear encoding differences, I don't see a lot of expressiveness differences. If you see some, would you point them out to me? Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Wednesday, March 15, 2006 2:27 PM To: Adam Roach; Henning Schulzrinne Cc: Chris Boulton; Adam Roach; xcon@ietf.org; ajohnston@tello.com Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control) This is a great analysis of why we have to be mindful of bandwidth and processing on mobile devices. Now let's talk about why limiting every device that wants to do conferencing to these same constraints may not make sense. First, there is multimedia where you won't always be able to squeeze the media into 4Kbps (or want to). This includes many video codecs, application sharing, file exchange, etc. Second, there are advanced conferencing applications which may require truly intelligent endpoints (pushing the 100MHz envelope ;-). Examples include application sharing for CAD/CAM, advanced cascading architectures, bots as moderators, gaming, etc. Third, there are many conferencing scenarios that may not involve a mobile device at all. Of course these scenarios can benefit from the reach of mobile technology, but there are simply cases where a mobile device does not fit. Examples include conferencing capabilities integrated with factory processes, web conferencing for B2C, customer service kiosks, etc. I'm very much in favor of designing a protocol which works and makes sense for mobile devices. I don't want to hobble the rest of the system in order to make this work. Could we do two different encodings of the same base protocol? -----Original Message----- From: Adam Roach [mailto:adam@estacado.net] Sent: Wednesday, March 15, 2006 11:11 AM To: Henning Schulzrinne Cc: Adam Roach; Chris Boulton; xcon@ietf.org; ajohnston@tello.com Subject: Why Size Really Can Matter (was Re: [XCON] Conference Control) (not as chair) Because I've spent an inordinate amount of time over the past 5 years working with issues surrounding mobile terminals, signaling size, latency, and compression, I wanted to throw in a couple of relevant points on the topic of message sizes. Henning Schulzrinne wrote: >> */[Chris Boulton] I get the handset bandwidth - I have heard it in >> almost every IETF meeting I've been to + I also agree it's a major >> consideration BUT lets not just keep harping back to it./* >> > > This is largely a bogus argument. In any multimedia conference, the > control bandwidth is going to be a tiny fraction of the overall > bandwidth consumed by media. Right now, more than one major US wireless carrier has deployed voice services over their existing data networks, which nominally pass 9.6kbps of data; once you factor in overhead, the real data throughput of these data connections is on the order of 8kbps. (I use these carriers as data points because I'm familiar with them; I would guess that similar deployments have been made in other countries as well). In order to pass voice over these connections, carriers are generally using codecs like half-rate EVRC, which consumes 4kbps. This leaves on the order of 4kbps to perform signaling. Using the examples in the CCCP, COMP, and CSCP proposals, a representative request/response exchange takes on the order of the following sizes: - CCCP: ~1800 bytes - COMP: ~700 bytes - CSCP: ~156 bytes Over the 4kbps available on these actually deployed voice systems, these exchanges will take the following amounts of time: - CCCP: ~3.6 seconds - COMP: ~1.4 seconds - CSCP: ~300 ms This raises an issue around how long users will be willing to wait between requesting an action and it taking effect. Is it okay for it to take several seconds to adjust a volume level or mute a participant? > Have you actually measured the latency for compression? We're probably > talking 2-3 ms here, based on my experience. > For the middle-of-the-line mobile terminals in wide use today (~100 MHz processors), running deflate over a 1kb message (the order of messages we're talking about here) is on the order of 100 ms. Not outrageous, but not trivial. The bigger issue by an order of magnitude is the fact that doing this on the CPU requires 100% CPU utilization during this time period, which impacts battery life probably more than you would expect. (700 mAh doesn't take you too far when it's expected to last several days). /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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Mar 15 14:45:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbw4-0005cz-H2; Wed, 15 Mar 2006 14:45:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbw3-0005cu-UP for xcon@ietf.org; Wed, 15 Mar 2006 14:45:31 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbw2-0004kr-Aa for xcon@ietf.org; Wed, 15 Mar 2006 14:45:31 -0500 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 15 Mar 2006 11:45:29 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 11:45:29 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 11:45:28 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 11:45:28 -0800 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: Why Size Really Can Matter (was Re: [XCON] Conference Control) Date: Wed, 15 Mar 2006 11:45:27 -0800 Message-ID: In-Reply-To: <293e01c64867$55f6b220$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why Size Really Can Matter (was Re: [XCON] Conference Control) thread-index: AcZIZBcIfARwS3K3SM+/azVksii0YAAAFE/AAACOuPAAAE5dQA== From: "Sean Olson" To: , "Adam Roach" , "Henning Schulzrinne" X-OriginalArrivalTime: 15 Mar 2006 19:45:28.0340 (UTC) FILETIME=[02DC5D40:01C64869] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Chris Boulton , Adam Roach , xcon@ietf.org, ajohnston@tello.com 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 look at the difference as being ASN.1 vs. XML (bear with me :-)=20 Using XML has a lot of advantages in terms of implementation and expressiveness. You can achieve the same sort of thing with ASN.1. But there are obviously some differences in the way you would approach extending each and implementing each. In a CPU and bandwidth constained device, I too would want a optimized binary protocol with a very tight data structure. In a richer conferencing device, I want to deal with technologies that I'm already implementing and which I feel very comfortable in extending. XML is a lingua franca for a lot of applications today. It has its warts, but if I show an XSD to most developers today, they "get it" and can get up and running quickly. PLUS, they are comfortable with how to rapidly extend and prototype new applications built on top of this base. Not to mention all the toolsets already in the marketplace today to make this sort of thing trivial. I'm not saying you can't do any of this with CSCP, it's just not my preferred approach when I have device which has ample CPU power, bandwidth, and the toolsets to make something like COMP or C3P work. This is very similar to ASN.1 vs XML/text and why I like SIP so much better than H.323 :-)=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, March 15, 2006 11:33 AM To: Sean Olson; 'Adam Roach'; 'Henning Schulzrinne' Cc: 'Chris Boulton'; 'Adam Roach'; xcon@ietf.org; ajohnston@tello.com Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control) I'm sorry, but I don't quite get this. Are you saying that CSCP somehow hobbles devices that are multimedia endpoints consuming oodles of bandwidth? I'd agree with your sentiments if there was actually a substantive difference in what you can DO with the protocols. Right now, while there are some very clear model differences, as well as very clear encoding differences, I don't see a lot of expressiveness differences. If you see some, would you point them out to me? Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Wednesday, March 15, 2006 2:27 PM To: Adam Roach; Henning Schulzrinne Cc: Chris Boulton; Adam Roach; xcon@ietf.org; ajohnston@tello.com Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control) This is a great analysis of why we have to be mindful of bandwidth and processing on mobile devices. Now let's talk about why limiting every device that wants to do conferencing to these same constraints may not make sense.=20 First, there is multimedia where you won't always be able to squeeze the media into 4Kbps (or want to). This includes many video codecs, application sharing, file exchange, etc. Second, there are advanced conferencing applications which may require truly intelligent endpoints (pushing the 100MHz envelope ;-). Examples include application sharing for CAD/CAM, advanced cascading architectures, bots as moderators, gaming, etc.=20 Third, there are many conferencing scenarios that may not involve a mobile device at all. Of course these scenarios can benefit from the reach of mobile technology, but there are simply cases where a mobile device does not fit. Examples include conferencing capabilities integrated with factory processes, web conferencing for B2C, customer service kiosks, etc. I'm very much in favor of designing a protocol which works and makes sense for mobile devices. I don't want to hobble the rest of the system in order to make this work. Could we do two different encodings of the same base protocol? -----Original Message----- From: Adam Roach [mailto:adam@estacado.net] Sent: Wednesday, March 15, 2006 11:11 AM To: Henning Schulzrinne Cc: Adam Roach; Chris Boulton; xcon@ietf.org; ajohnston@tello.com Subject: Why Size Really Can Matter (was Re: [XCON] Conference Control) (not as chair) Because I've spent an inordinate amount of time over the past 5 years working with issues surrounding mobile terminals, signaling size, latency, and compression, I wanted to throw in a couple of relevant points on the topic of message sizes. Henning Schulzrinne wrote: >> */[Chris Boulton] I get the handset bandwidth - I have heard it in=20 >> almost every IETF meeting I've been to + I also agree it's a major=20 >> consideration BUT lets not just keep harping back to it./* >> > > This is largely a bogus argument. In any multimedia conference, the=20 > control bandwidth is going to be a tiny fraction of the overall=20 > bandwidth consumed by media. Right now, more than one major US wireless carrier has deployed voice services over their existing data networks, which nominally pass 9.6kbps of data; once you factor in overhead, the real data throughput of these data connections is on the order of 8kbps. (I use these carriers as data points because I'm familiar with them; I would guess that similar deployments have been made in other countries as well). In order to pass voice over these connections, carriers are generally using codecs like half-rate EVRC, which consumes 4kbps. This leaves on the order of 4kbps to perform signaling. Using the examples in the CCCP, COMP, and CSCP proposals, a representative request/response exchange takes on the order of the following sizes: - CCCP: ~1800 bytes - COMP: ~700 bytes - CSCP: ~156 bytes Over the 4kbps available on these actually deployed voice systems, these exchanges will take the following amounts of time: - CCCP: ~3.6 seconds - COMP: ~1.4 seconds - CSCP: ~300 ms This raises an issue around how long users will be willing to wait between requesting an action and it taking effect. Is it okay for it to take several seconds to adjust a volume level or mute a participant? > Have you actually measured the latency for compression? We're probably > talking 2-3 ms here, based on my experience. > For the middle-of-the-line mobile terminals in wide use today (~100 MHz processors), running deflate over a 1kb message (the order of messages we're talking about here) is on the order of 100 ms. Not outrageous, but not trivial. The bigger issue by an order of magnitude is the fact that doing this on the CPU requires 100% CPU utilization during this time period, which impacts battery life probably more than you would expect.=20 (700 mAh doesn't take you too far when it's expected to last several days). /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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Mar 15 15:56:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJd2S-0003UB-3G; Wed, 15 Mar 2006 15:56:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJd2Q-0003U6-VB for xcon@ietf.org; Wed, 15 Mar 2006 15:56:10 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJd2Q-00078S-Ef for xcon@ietf.org; Wed, 15 Mar 2006 15:56:10 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FJd1x-0004tR-Ud; Wed, 15 Mar 2006 14:55:42 -0600 From: "Brian Rosen" To: "'Sean Olson'" , "'Adam Roach'" , "'Henning Schulzrinne'" Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control) Date: Wed, 15 Mar 2006 15:55:44 -0500 Message-ID: <296401c64872$d65d53f0$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.2670 Thread-Index: AcZIZBcIfARwS3K3SM+/azVksii0YAAAFE/AAACOuPAAAE5dQAABh7ig In-Reply-To: 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: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: 'Chris Boulton' , 'Adam Roach' , xcon@ietf.org, ajohnston@tello.com X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Extending the mechanism is part and parcel of the job; we have a notion of template, it's an XML data structure, and you can create all sorts of nifty extensions by creating an XSD. The ON THE WIRE protocol that manipulates the template doesn't have to be xml itself to get the advantages of that. I don't especially want a lot of extensions to the on-the-wire part; if we have done our job correctly, the template captures the range of extensions we need. I'll agree that debugging the on-the-wire bits is easier with a text based protocol that with a binary one. I'll agree that if COMP or C3P pushes down the number of bits for real use cases (which would NOT include any fixed dictionary things) to the range of CSCP then there isn't a good argument for binary encoding. I too much prefer SIP to H.323. I was part of the Megaco binary/text arguments and we showed that there was not a great deal of difference between the number of bits for the common operations in ASN.1 and text encodings, which favored a text encoding. So far, the evidence I've seen shows we aren't in the same ballpark here, and we do want bandwidth restricted devices to work well. So, it seems to me that you are saying that the ease of development and debugging is more important than supporting bandwidth restricted clients. I don't think you get any significant advantage for development ease, you do get some advantage for debugging, and the tradeoff, if there is one, should favor supporting bandwidth restricted devices. I'd really rather see you show that text encoding isn't any substantial difference in size, rather than arguing the other advantages of text. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Wednesday, March 15, 2006 2:45 PM To: br@brianrosen.net; Adam Roach; Henning Schulzrinne Cc: Chris Boulton; Adam Roach; xcon@ietf.org; ajohnston@tello.com Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control) I look at the difference as being ASN.1 vs. XML (bear with me :-) Using XML has a lot of advantages in terms of implementation and expressiveness. You can achieve the same sort of thing with ASN.1. But there are obviously some differences in the way you would approach extending each and implementing each. In a CPU and bandwidth constained device, I too would want a optimized binary protocol with a very tight data structure. In a richer conferencing device, I want to deal with technologies that I'm already implementing and which I feel very comfortable in extending. XML is a lingua franca for a lot of applications today. It has its warts, but if I show an XSD to most developers today, they "get it" and can get up and running quickly. PLUS, they are comfortable with how to rapidly extend and prototype new applications built on top of this base. Not to mention all the toolsets already in the marketplace today to make this sort of thing trivial. I'm not saying you can't do any of this with CSCP, it's just not my preferred approach when I have device which has ample CPU power, bandwidth, and the toolsets to make something like COMP or C3P work. This is very similar to ASN.1 vs XML/text and why I like SIP so much better than H.323 :-) -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, March 15, 2006 11:33 AM To: Sean Olson; 'Adam Roach'; 'Henning Schulzrinne' Cc: 'Chris Boulton'; 'Adam Roach'; xcon@ietf.org; ajohnston@tello.com Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control) I'm sorry, but I don't quite get this. Are you saying that CSCP somehow hobbles devices that are multimedia endpoints consuming oodles of bandwidth? I'd agree with your sentiments if there was actually a substantive difference in what you can DO with the protocols. Right now, while there are some very clear model differences, as well as very clear encoding differences, I don't see a lot of expressiveness differences. If you see some, would you point them out to me? Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Wednesday, March 15, 2006 2:27 PM To: Adam Roach; Henning Schulzrinne Cc: Chris Boulton; Adam Roach; xcon@ietf.org; ajohnston@tello.com Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control) This is a great analysis of why we have to be mindful of bandwidth and processing on mobile devices. Now let's talk about why limiting every device that wants to do conferencing to these same constraints may not make sense. First, there is multimedia where you won't always be able to squeeze the media into 4Kbps (or want to). This includes many video codecs, application sharing, file exchange, etc. Second, there are advanced conferencing applications which may require truly intelligent endpoints (pushing the 100MHz envelope ;-). Examples include application sharing for CAD/CAM, advanced cascading architectures, bots as moderators, gaming, etc. Third, there are many conferencing scenarios that may not involve a mobile device at all. Of course these scenarios can benefit from the reach of mobile technology, but there are simply cases where a mobile device does not fit. Examples include conferencing capabilities integrated with factory processes, web conferencing for B2C, customer service kiosks, etc. I'm very much in favor of designing a protocol which works and makes sense for mobile devices. I don't want to hobble the rest of the system in order to make this work. Could we do two different encodings of the same base protocol? -----Original Message----- From: Adam Roach [mailto:adam@estacado.net] Sent: Wednesday, March 15, 2006 11:11 AM To: Henning Schulzrinne Cc: Adam Roach; Chris Boulton; xcon@ietf.org; ajohnston@tello.com Subject: Why Size Really Can Matter (was Re: [XCON] Conference Control) (not as chair) Because I've spent an inordinate amount of time over the past 5 years working with issues surrounding mobile terminals, signaling size, latency, and compression, I wanted to throw in a couple of relevant points on the topic of message sizes. Henning Schulzrinne wrote: >> */[Chris Boulton] I get the handset bandwidth - I have heard it in >> almost every IETF meeting I've been to + I also agree it's a major >> consideration BUT lets not just keep harping back to it./* >> > > This is largely a bogus argument. In any multimedia conference, the > control bandwidth is going to be a tiny fraction of the overall > bandwidth consumed by media. Right now, more than one major US wireless carrier has deployed voice services over their existing data networks, which nominally pass 9.6kbps of data; once you factor in overhead, the real data throughput of these data connections is on the order of 8kbps. (I use these carriers as data points because I'm familiar with them; I would guess that similar deployments have been made in other countries as well). In order to pass voice over these connections, carriers are generally using codecs like half-rate EVRC, which consumes 4kbps. This leaves on the order of 4kbps to perform signaling. Using the examples in the CCCP, COMP, and CSCP proposals, a representative request/response exchange takes on the order of the following sizes: - CCCP: ~1800 bytes - COMP: ~700 bytes - CSCP: ~156 bytes Over the 4kbps available on these actually deployed voice systems, these exchanges will take the following amounts of time: - CCCP: ~3.6 seconds - COMP: ~1.4 seconds - CSCP: ~300 ms This raises an issue around how long users will be willing to wait between requesting an action and it taking effect. Is it okay for it to take several seconds to adjust a volume level or mute a participant? > Have you actually measured the latency for compression? We're probably > talking 2-3 ms here, based on my experience. > For the middle-of-the-line mobile terminals in wide use today (~100 MHz processors), running deflate over a 1kb message (the order of messages we're talking about here) is on the order of 100 ms. Not outrageous, but not trivial. The bigger issue by an order of magnitude is the fact that doing this on the CPU requires 100% CPU utilization during this time period, which impacts battery life probably more than you would expect. (700 mAh doesn't take you too far when it's expected to last several days). /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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Mar 15 19:42:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJgZE-000190-Eu; Wed, 15 Mar 2006 19:42:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJgZE-00018v-6c for xcon@ietf.org; Wed, 15 Mar 2006 19:42:16 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJgZB-0005i1-SV for xcon@ietf.org; Wed, 15 Mar 2006 19:42:16 -0500 Received: from [172.17.2.251] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2G0gCEj064964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Mar 2006 18:42:13 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4418B4D9.9040806@nostrum.com> Date: Wed, 15 Mar 2006 18:44:09 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton References: <45730E094814E44488F789C1CDED27AE03118904@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE03118904@gbnewp0758m.eu.ubiquity.net> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=windows-1252; format=flowed Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nostrum.com id k2G0gCEj064964 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ajohnston@tello.com, Adam Roach , xcon@ietf.org Subject: [XCON] Multiple Protocols: What Do You Really Want? 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 [not as chair] Chris Boulton wrote: > It is for these reasons that I was pondering the prospect of XCON=20 > allowing both a handset friendly interface such as CSCP and a SOAP=20 > interface for web services where the client might well be another=20 > application and not a handset. I realise that having two interfaces is=20 > not ideal, but as long as we are careful in our rules on minimal=20 > implementation and ability to advertise capabilities to a Conference=20 > Client I personally feel that this is the best solution to make XCON=20 > appealing to a wide variety of architectures. > There have been a number of favorable responses to this proposal, and=20 I'd like to feel out some of the thoughts people have on the topic. In particular, if we choose more than one protocol for conference=20 control, we still must select from one of the following four models: 1. The focus must implement all protocols; the endpoints may choose on= e. 2. The endpoints must implement all protocols; the focus may choose on= e. 3. Both endpoints and focuses must implement a single specified protocol, and may implement others. 4. Endpoints and focuses implement whichever of the protocols they want; arbitrary combinations of implementations simply don=92t work together. I would offer that option 4 is a complete nonstarter. There's no point=20 coming up with a standard that just flat-out doesn't interoperate in=20 some large percentage of the cases. If we want that, we may as well let=20 each vendor come up with their own proprietary signaling protocol. Option 3 gets us back to selecting the one sole mandatory-to-implement=20 protocol, which probably doesn't clear us from the current logjam.=20 (Anyone who is currently championing a proposal and would be happy=20 seeing it as an option but not the "mandatory-to-implement" option in=20 such a scheme, speak up). Selecting either option 1 or option 2 would be a tacit admission that=20 implementation complexity is a non-issue (since doing so approximately=20 doubles the implementation complexity of either the focuses or the=20 endpoints) -- and admitting this takes *all* of the wind out of any=20 arguments regarding the relative implementation complexity of XML versus=20 binary. So, of those who have so far spoken in favor of having multiple=20 protocols to do the same thing: which of these four models did you have=20 in mind? (Or did I miss one?) /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Mar 15 20:28:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhHU-0002FP-0n; Wed, 15 Mar 2006 20:28:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhHS-0002FK-BK for xcon@ietf.org; Wed, 15 Mar 2006 20:27:58 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJhHR-0007RV-QU for xcon@ietf.org; Wed, 15 Mar 2006 20:27:58 -0500 Received: from mail1.microsoft.com ([157.54.63.55]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 15 Mar 2006 17:26:29 -0800 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 17:26:29 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 17:26:29 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 17:26:29 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 17:26:28 -0800 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] Multiple Protocols: What Do You Really Want? Date: Wed, 15 Mar 2006 17:26:26 -0800 Message-ID: In-Reply-To: <4418B4D9.9040806@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Multiple Protocols: What Do You Really Want? thread-index: AcZIkqSDL7aZm+mHTjC0+E3rVTkBtQABVB0Q From: "Sean Olson" To: "Adam Roach" , "Chris Boulton" X-OriginalArrivalTime: 16 Mar 2006 01:26:28.0738 (UTC) FILETIME=[A6355620:01C64898] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ajohnston@tello.com, 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 I would say that option 4 is not a complete non-starter. I would draw the analogy between a WAP browser and a normal browser. There are sites that offer support only for WAP, sites that support WAP and regular browsers, and sites that support only a full browser like Firefox or IE. This has not proven to be a non-starter for the web. WBXML/WML is a compact encoding of the same data model that a richer XML encoding offers and I think a good example of how we can offer both an encoding that works well for mobile while preserving the richness of functionality for other clients. -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Wednesday, March 15, 2006 4:44 PM To: Chris Boulton Cc: ajohnston@tello.com; Adam Roach; xcon@ietf.org Subject: [XCON] Multiple Protocols: What Do You Really Want? [not as chair] Chris Boulton wrote: > It is for these reasons that I was pondering the prospect of XCON=20 > allowing both a handset friendly interface such as CSCP and a SOAP=20 > interface for web services where the client might well be another=20 > application and not a handset. I realise that having two interfaces is > not ideal, but as long as we are careful in our rules on minimal=20 > implementation and ability to advertise capabilities to a Conference=20 > Client I personally feel that this is the best solution to make XCON=20 > appealing to a wide variety of architectures. > There have been a number of favorable responses to this proposal, and I'd like to feel out some of the thoughts people have on the topic. In particular, if we choose more than one protocol for conference control, we still must select from one of the following four models: 1. The focus must implement all protocols; the endpoints may choose one. 2. The endpoints must implement all protocols; the focus may choose one. 3. Both endpoints and focuses must implement a single specified protocol, and may implement others. 4. Endpoints and focuses implement whichever of the protocols they want; arbitrary combinations of implementations simply don't work together. I would offer that option 4 is a complete nonstarter. There's no point coming up with a standard that just flat-out doesn't interoperate in some large percentage of the cases. If we want that, we may as well let each vendor come up with their own proprietary signaling protocol. Option 3 gets us back to selecting the one sole mandatory-to-implement protocol, which probably doesn't clear us from the current logjam.=20 (Anyone who is currently championing a proposal and would be happy seeing it as an option but not the "mandatory-to-implement" option in such a scheme, speak up). Selecting either option 1 or option 2 would be a tacit admission that implementation complexity is a non-issue (since doing so approximately doubles the implementation complexity of either the focuses or the endpoints) -- and admitting this takes *all* of the wind out of any arguments regarding the relative implementation complexity of XML versus binary. So, of those who have so far spoken in favor of having multiple protocols to do the same thing: which of these four models did you have in mind? (Or did I miss one?) /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 Wed Mar 15 21:06:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhsU-0007P2-Ez; Wed, 15 Mar 2006 21:06:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhsT-0007Ox-8T for xcon@ietf.org; Wed, 15 Mar 2006 21:06:13 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJhsS-0008Cw-Vr for xcon@ietf.org; Wed, 15 Mar 2006 21:06:13 -0500 Received: from [172.17.2.251] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2G26B2e068745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Mar 2006 20:06:12 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4418C888.1090003@nostrum.com> Date: Wed, 15 Mar 2006 20:08:08 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson Subject: Re: [XCON] Multiple Protocols: What Do You Really Want? References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Chris Boulton , ajohnston@tello.com, 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 [not as chair] Adam Roach wrote: > 4. Endpoints and focuses implement whichever of the protocols they > want; arbitrary combinations of implementations simply don't work > together. > > >I would offer that option 4 is a complete nonstarter. There's no point >coming up with a standard that just flat-out doesn't interoperate in >some large percentage of the cases. If we want that, we may as well let >each vendor come up with their own proprietary signaling protocol. > > To which Sean Olson responded: >I would say that option 4 is not a complete non-starter. I would draw >the analogy between a WAP browser and a normal browser. There are sites >that offer support only for WAP, sites that support WAP and regular >browsers, and sites that support only a full browser like Firefox or IE. >This has not proven to be a non-starter for the web. > I'm not sure I'd hold out WAP/WML as a model of how to build a successful protocol. I have a WAP browser on my phone. So far, I've discovered that I can get to the National Weather Service; a tiny, tiny fraction of Yahoo's offerings; and whatever stuff Google can manage to automatically translate from HTML without complete information destruction. By contrast, the range of information that I can get with HTTP/HTML is virtually limitless. Of course, I'm happy to be proven wrong. I'll hand you my phone next week (WAP/WML only), and I'll borrow Robert's phone (HTTP/HTML). I'll try to find information you can't, and you'll try to find information that I can't. We'll see whether whether these two optional protocols for "the web" have resulted in an even vaguely similar user experience for both kinds of clients. On the balance, it is my opinion that WAP/WML serves as a terrifying cautionary tale warning XCON in the strongest terms possible *away* from selecting multiple protocols (with none mandatory) -- not an example to follow to our own consequent doom. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Mar 15 22:16:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJiy5-00055i-AY; Wed, 15 Mar 2006 22:16:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJiy4-00055d-3B for xcon@ietf.org; Wed, 15 Mar 2006 22:16:04 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJiy3-0001vG-Le for xcon@ietf.org; Wed, 15 Mar 2006 22:16:04 -0500 Received: from mail2.microsoft.com ([157.54.63.12]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 15 Mar 2006 19:16:02 -0800 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 19:16:02 -0800 Received: from tuk-hub-01.redmond.corp.microsoft.com ([157.54.70.27]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 19:16:03 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 19:16:02 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 19:16:00 -0800 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] Multiple Protocols: What Do You Really Want? Date: Wed, 15 Mar 2006 19:15:53 -0800 Message-ID: In-Reply-To: <4418C888.1090003@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Multiple Protocols: What Do You Really Want? thread-index: AcZInjuCsDMYLkBFQZeOL6VfIseKigACYuyQ From: "Sean Olson" To: "Adam Roach" X-OriginalArrivalTime: 16 Mar 2006 03:16:00.0680 (UTC) FILETIME=[F3641A80:01C648A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Chris Boulton , ajohnston@tello.com, 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 Interesting point ... Where would the web be today if they had chosen WAP/WML as the "one" standard to fit the needs of mobile devices? Do you think we would have reached the level of innovation that we have including Web 2.0?=20 -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Wednesday, March 15, 2006 6:08 PM To: Sean Olson Cc: Chris Boulton; ajohnston@tello.com; xcon@ietf.org Subject: Re: [XCON] Multiple Protocols: What Do You Really Want? [not as chair] Adam Roach wrote: > 4. Endpoints and focuses implement whichever of the protocols they > want; arbitrary combinations of implementations simply don't work > together. > > >I would offer that option 4 is a complete nonstarter. There's no point=20 >coming up with a standard that just flat-out doesn't interoperate in=20 >some large percentage of the cases. If we want that, we may as well let >each vendor come up with their own proprietary signaling protocol. > =20 > To which Sean Olson responded: >I would say that option 4 is not a complete non-starter. I would draw=20 >the analogy between a WAP browser and a normal browser. There are sites >that offer support only for WAP, sites that support WAP and regular=20 >browsers, and sites that support only a full browser like Firefox or IE. >This has not proven to be a non-starter for the web. > I'm not sure I'd hold out WAP/WML as a model of how to build a successful protocol. I have a WAP browser on my phone. So far, I've discovered that I can get to the National Weather Service; a tiny, tiny fraction of Yahoo's offerings; and whatever stuff Google can manage to automatically translate from HTML without complete information destruction. By contrast, the range of information that I can get with HTTP/HTML is virtually limitless. Of course, I'm happy to be proven wrong. I'll hand you my phone next week (WAP/WML only), and I'll borrow Robert's phone (HTTP/HTML). I'll try to find information you can't, and you'll try to find information that I can't. We'll see whether whether these two optional protocols for "the web" have resulted in an even vaguely similar user experience for both kinds of clients. On the balance, it is my opinion that WAP/WML serves as a terrifying cautionary tale warning XCON in the strongest terms possible *away* from selecting multiple protocols (with none mandatory) -- not an example to follow to our own consequent doom. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Mar 16 01:33:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJm2k-00021k-VQ; Thu, 16 Mar 2006 01:33:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJm2k-00021f-7r for xcon@ietf.org; Thu, 16 Mar 2006 01:33:06 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJm2i-0006jb-Uz for xcon@ietf.org; Thu, 16 Mar 2006 01:33:06 -0500 Received: from [192.168.0.102] (ppp-70-249-144-46.dsl.rcsntx.swbell.net [70.249.144.46]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2G6X3dY079989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Mar 2006 00:33:03 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <44190699.5050203@nostrum.com> Date: Thu, 16 Mar 2006 00:32:57 -0600 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: Sean Olson Subject: Re: [XCON] Multiple Protocols: What Do You Really Want? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.144.46 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Chris Boulton , ajohnston@tello.com, 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 (not as chair) Sean Olson wrote: >Interesting point ... Where would the web be today if they had chosen >WAP/WML as the "one" standard to fit the needs of mobile devices? Do you >think we would have reached the level of innovation that we have >including Web 2.0? > > To demonstrate why the analogy is imperfect, I would have to delve into my opinions around the quality of standards produced by engineering organizations versus those produced by parliamentary organizations. Since that's a distraction from the issue at hand, I'll rephrase your question to be more relevant: Where would the web would be today if it had been based on a single underlying protocol that was developed with *both* bandwidth constrained devices *and* extremely rich and powerful devices in mind? Exactly where it is today, *except* without many mobile phone users stuck in a protocol ghetto created by the creation of two ways to do one thing. A key reason WAP/WML is so poorly supported when compared to HTTP/HTML is that supporting *both* requires *twice* the effort. This goes all the way from designing protocol extensions up through the implementation of servers and on to the actual creation of content. Very few people are willing to spend twice as much time, effort, and money than should be necessary at every step of the process. The use of a *single* protocol would have avoided these issues. Your objections so far seem based on an underlying assertion that the selection of a concise encoding for the protocol somehow limits functionality. Brian directly requested that you point out something that can be done in a bloated protocol that can't be done in a concise one. Your response, by my reading, related not to his question, but to the relative ease with which developers could make proprietary extensions. I will repeat Brian's question: since your objections are based on an assertion that a concise encoding will "hobble the rest of the system," I request an example. Please provide a simple existence proof of one operation that cannot be done simply because we make syntactic concessions to bandwidth-constrained devices. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Mar 16 09:18:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJtIv-0005Fs-5R; Thu, 16 Mar 2006 09:18:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJtIt-0005Fn-T4 for xcon@ietf.org; Thu, 16 Mar 2006 09:18:15 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJtIr-0003QK-DS for xcon@ietf.org; Thu, 16 Mar 2006 09:18:15 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2GEIB9a014904 for ; Thu, 16 Mar 2006 08:18:12 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Mar 2006 14:18:11 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0124F958A@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: xcon@ietf.org Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control ) Date: Thu, 16 Mar 2006 14:18:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b 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 remember seeing anybody yet quantifying response times for the conference control protocol, apart from some mails a while back that some people seemed to think it could be a replacement for the floor control protocol. On the floor control protocol, I would expect good round trip response times to the user. For the conference control protocol as I see it at the moment (i.e. with floor control as an entirely separate protocol) we should be looking for response times of the same order that we achieve with SIP. For SIP on 3GPP we found it necessary to mandate SIGComp in order to reduce message size, and therefore reduce transmission delay, and in a similar manner with a conference control protocol using XML, we may need to look at having some compression protocol specified, but we probably do not need to get any more extreme that that. Incidentally I do not think that H.323 is a good example to use for ASN.1 usage. H.323 uses just about every coding scheme going, quite frequently in the worst possible manner, and in many respects I see the usage of the packed encoding rules as adding to that. regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 15 March 2006 20:56 > To: 'Sean Olson'; 'Adam Roach'; 'Henning Schulzrinne' > Cc: 'Chris Boulton'; 'Adam Roach'; xcon@ietf.org; ajohnston@tello.com > Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference > Control) > > > Extending the mechanism is part and parcel of the job; we > have a notion of > template, it's an XML data structure, and you can create all > sorts of nifty > extensions by creating an XSD. > > The ON THE WIRE protocol that manipulates the template > doesn't have to be > xml itself to get the advantages of that. I don't especially > want a lot of > extensions to the on-the-wire part; if we have done our job > correctly, the > template captures the range of extensions we need. > > I'll agree that debugging the on-the-wire bits is easier with > a text based > protocol that with a binary one. I'll agree that if COMP or > C3P pushes down > the number of bits for real use cases (which would NOT > include any fixed > dictionary things) to the range of CSCP then there isn't a > good argument for > binary encoding. I too much prefer SIP to H.323. I was part > of the Megaco > binary/text arguments and we showed that there was not a great deal of > difference between the number of bits for the common > operations in ASN.1 and > text encodings, which favored a text encoding. So far, the > evidence I've > seen shows we aren't in the same ballpark here, and we do > want bandwidth > restricted devices to work well. > > So, it seems to me that you are saying that the ease of > development and > debugging is more important than supporting bandwidth > restricted clients. I > don't think you get any significant advantage for development > ease, you do > get some advantage for debugging, and the tradeoff, if there > is one, should > favor supporting bandwidth restricted devices. > > I'd really rather see you show that text encoding isn't any > substantial > difference in size, rather than arguing the other advantages of text. > > Brian > > -----Original Message----- > From: Sean Olson [mailto:Sean.Olson@microsoft.com] > Sent: Wednesday, March 15, 2006 2:45 PM > To: br@brianrosen.net; Adam Roach; Henning Schulzrinne > Cc: Chris Boulton; Adam Roach; xcon@ietf.org; ajohnston@tello.com > Subject: RE: Why Size Really Can Matter (was Re: [XCON] > Conference Control) > > I look at the difference as being ASN.1 vs. XML (bear with me :-) > > Using XML has a lot of advantages in terms of implementation and > expressiveness. You can achieve the same sort of thing with ASN.1. But > there are obviously some differences in the way you would approach > extending each and implementing each. In a CPU and bandwidth > constained > device, I too would want a optimized binary protocol with a very tight > data structure. In a richer conferencing device, I want to deal with > technologies that I'm already implementing and which I feel very > comfortable in extending. XML is a lingua franca for a lot of > applications today. It has its warts, but if I show an XSD to most > developers today, they "get it" and can get up and running quickly. > PLUS, they are comfortable with how to rapidly extend and > prototype new > applications built on top of this base. Not to mention all > the toolsets > already in the marketplace today to make this sort of thing > trivial. I'm > not saying you can't do any of this with CSCP, it's just not my > preferred approach when I have device which has ample CPU power, > bandwidth, and the toolsets to make something like COMP or C3P work. > This is very similar to ASN.1 vs XML/text and why I like SIP so much > better than H.323 :-) > > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 15, 2006 11:33 AM > To: Sean Olson; 'Adam Roach'; 'Henning Schulzrinne' > Cc: 'Chris Boulton'; 'Adam Roach'; xcon@ietf.org; ajohnston@tello.com > Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference > Control) > > I'm sorry, but I don't quite get this. Are you saying that > CSCP somehow > hobbles devices that are multimedia endpoints consuming oodles of > bandwidth? > > I'd agree with your sentiments if there was actually a substantive > difference in what you can DO with the protocols. Right now, while > there are some very clear model differences, as well as very clear > encoding differences, I don't see a lot of expressiveness differences. > > If you see some, would you point them out to me? > > Brian > > > -----Original Message----- > From: Sean Olson [mailto:Sean.Olson@microsoft.com] > Sent: Wednesday, March 15, 2006 2:27 PM > To: Adam Roach; Henning Schulzrinne > Cc: Chris Boulton; Adam Roach; xcon@ietf.org; ajohnston@tello.com > Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference > Control) > > This is a great analysis of why we have to be mindful of bandwidth and > processing on mobile devices. Now let's talk about why limiting every > device that wants to do conferencing to these same constraints may not > make sense. > > First, there is multimedia where you won't always be able to > squeeze the > media into 4Kbps (or want to). This includes many video codecs, > application sharing, file exchange, etc. > > Second, there are advanced conferencing applications which may require > truly intelligent endpoints (pushing the 100MHz envelope ;-). Examples > include application sharing for CAD/CAM, advanced cascading > architectures, bots as moderators, gaming, etc. > > Third, there are many conferencing scenarios that may not involve a > mobile device at all. Of course these scenarios can benefit from the > reach of mobile technology, but there are simply cases where a mobile > device does not fit. Examples include conferencing capabilities > integrated with factory processes, web conferencing for B2C, customer > service kiosks, etc. > > I'm very much in favor of designing a protocol which works and makes > sense for mobile devices. I don't want to hobble the rest of > the system > in order to make this work. Could we do two different encodings of the > same base protocol? > > > -----Original Message----- > From: Adam Roach [mailto:adam@estacado.net] > Sent: Wednesday, March 15, 2006 11:11 AM > To: Henning Schulzrinne > Cc: Adam Roach; Chris Boulton; xcon@ietf.org; ajohnston@tello.com > Subject: Why Size Really Can Matter (was Re: [XCON] > Conference Control) > > (not as chair) > > Because I've spent an inordinate amount of time over the past 5 years > working with issues surrounding mobile terminals, signaling size, > latency, and compression, I wanted to throw in a couple of relevant > points on the topic of message sizes. > > Henning Schulzrinne wrote: > > >> */[Chris Boulton] I get the handset bandwidth - I have heard it in > >> almost every IETF meeting I've been to + I also agree it's a major > >> consideration BUT lets not just keep harping back to it./* > >> > > > > This is largely a bogus argument. In any multimedia conference, the > > control bandwidth is going to be a tiny fraction of the overall > > bandwidth consumed by media. > > > Right now, more than one major US wireless carrier has deployed voice > services over their existing data networks, which nominally > pass 9.6kbps > of data; once you factor in overhead, the real data > throughput of these > data connections is on the order of 8kbps. (I use these > carriers as data > points because I'm familiar with them; I would guess that similar > deployments have been made in other countries as well). > > In order to pass voice over these connections, carriers are generally > using codecs like half-rate EVRC, which consumes 4kbps. This leaves on > the order of 4kbps to perform signaling. > > Using the examples in the CCCP, COMP, and CSCP proposals, a > representative request/response exchange takes on the order of the > following sizes: > > - CCCP: ~1800 bytes > - COMP: ~700 bytes > - CSCP: ~156 bytes > > Over the 4kbps available on these actually deployed voice > systems, these > exchanges will take the following amounts of time: > > - CCCP: ~3.6 seconds > - COMP: ~1.4 seconds > - CSCP: ~300 ms > > This raises an issue around how long users will be willing to wait > between requesting an action and it taking effect. Is it okay > for it to > take several seconds to adjust a volume level or mute a participant? > > > Have you actually measured the latency for compression? > We're probably > > > talking 2-3 ms here, based on my experience. > > > > For the middle-of-the-line mobile terminals in wide use today > (~100 MHz > processors), running deflate over a 1kb message (the order of messages > we're talking about here) is on the order of 100 ms. Not > outrageous, but > > not trivial. The bigger issue by an order of magnitude is the > fact that > doing this on the CPU requires 100% CPU utilization during this time > period, which impacts battery life probably more than you > would expect. > (700 mAh doesn't take you too far when it's expected to last several > days). > > /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 > > > _______________________________________________ > 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 Thu Mar 16 10:43:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJudX-00070L-Kv; Thu, 16 Mar 2006 10:43:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJudW-00070G-Lh for xcon@ietf.org; Thu, 16 Mar 2006 10:43:38 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJudU-000639-BX for xcon@ietf.org; Thu, 16 Mar 2006 10:43:38 -0500 Received: from [192.168.0.102] (ppp-70-249-144-46.dsl.rcsntx.swbell.net [70.249.144.46]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2GFhX5J005262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Mar 2006 09:43:35 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441987A0.3020300@nostrum.com> Date: Thu, 16 Mar 2006 09:43:28 -0600 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: "Drage, Keith (Keith)" Subject: Re: Why Size Really Can Matter (was Re: [XCON] Conference Control ) References: <475FF955A05DD411980D00508B6D5FB0124F958A@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0124F958A@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.144.46 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 [not as chair] Drage, Keith (Keith) wrote: >I don't remember seeing anybody yet quantifying response times for the conference control protocol, apart from some mails a while back that some people seemed to think it could be a replacement for the floor control protocol. > Neither did I, which is why I went through the effort. I quantified the predicted characteristics of the three proposals being offered. I also attempted to quantify the requirements somewhat (or, at least, ask for opinions on the topic) by pondering whether multi-second response times for adjusting media would be acceptable. If the consensus of the working group is "yes," then I'm done. I want to make sure the issue has been considered. That said, I *do* have an informed opinion on the topic, and I'm happy to share it. >For the conference control protocol as I see it at the moment (i.e. with floor control as an entirely separate protocol) we should be looking for response times of the same order that we achieve with SIP. > I'm not certain this is true. While people are willing to wait multiple seconds to establish a call, it seems unlikely that they're willing to wait that long for something they perceive as being interactive, such as adjusting the volume of a participant. Those kinds of operations typically carry with them a user expectation of being as close to instantaneous as possible. That generally means that your time budget for reaction is on the order of one second or less. See, e.g., http://www.useit.com/papers/responsetime.html >For SIP on 3GPP we found it necessary to mandate SIGComp in order to reduce message size, and therefore reduce transmission delay, and in a similar manner with a conference control protocol using XML, we may need to look at having some compression protocol specified, but we probably do not need to get any more extreme that that. > > I believe the situation differs dramatically. By the time the constraints of mobile terminals were taken into account, the SIP protocol was effectively set down in stone (or, at least, written in moist concrete). At that point, the only realistic solutions were inventing a new protocol or retrofitting compression on top of SIP. I think choosing to add a compression layer to SIP was the right choice in this case. On the other hand, if bandwidth constraints can be considered during the development phase of a protocol, you prevent issues surrounding such retrofits. (And they are not without pain -- you'll notice that ROHC is still struggling with issues surrounding mapping of compression states to SIP constructs). /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Mar 16 12:31:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJwKG-00076V-Fi; Thu, 16 Mar 2006 12:31:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJwKG-00076B-7M for xcon@ietf.org; Thu, 16 Mar 2006 12:31:52 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJwKE-0001rC-SH for xcon@ietf.org; Thu, 16 Mar 2006 12:31:52 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FJwK2-0002eB-40; Thu, 16 Mar 2006 11:31:38 -0600 From: "Brian Rosen" To: "'Adam Roach'" , "'Drage, Keith \(Keith\)'" Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control ) Date: Thu, 16 Mar 2006 12:31:40 -0500 Message-ID: <2af001c6491f$7e679810$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.2670 Thread-Index: AcZJEGRvxm5WisBYRf6GRssCFwULSgADacLg In-Reply-To: <441987A0.3020300@nostrum.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: 386e0819b1192672467565a524848168 Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I agree with Adam. I keep harping on the operation of setting a value to a mixer control as the most significant influence on the protocol design. Sean (and others) have wanted to talk about richness of conference establishment. I don't get it; you establish the call seldom, you change the mixer often. We can put up with considerable ugliness on conference management in exchange for efficient mixer management. I don't think the "mixer efficient" protocols are particularly ugly on the conference management side, but the "conference management rich" proposals are pretty awful for mixer management efficiency. I really do think a mobile client wants to manage its mixer, and the "1 second" cite below is NOT representative of acceptable response to manipulating a control that is changing what you hear or see. That number is in the 100-200 ms range or less, although 500 is not completely off the wall. 3 seconds is. Please don't cite sidebar management as a counter-example, or I'll go back to my argument that sidebars are mixer state. Brian -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: Thursday, March 16, 2006 10:43 AM To: Drage, Keith (Keith) Cc: xcon@ietf.org Subject: Re: Why Size Really Can Matter (was Re: [XCON] Conference Control ) [not as chair] Drage, Keith (Keith) wrote: >I don't remember seeing anybody yet quantifying response times for the conference control protocol, apart from some mails a while back that some people seemed to think it could be a replacement for the floor control protocol. > Neither did I, which is why I went through the effort. I quantified the predicted characteristics of the three proposals being offered. I also attempted to quantify the requirements somewhat (or, at least, ask for opinions on the topic) by pondering whether multi-second response times for adjusting media would be acceptable. If the consensus of the working group is "yes," then I'm done. I want to make sure the issue has been considered. That said, I *do* have an informed opinion on the topic, and I'm happy to share it. >For the conference control protocol as I see it at the moment (i.e. with floor control as an entirely separate protocol) we should be looking for response times of the same order that we achieve with SIP. > I'm not certain this is true. While people are willing to wait multiple seconds to establish a call, it seems unlikely that they're willing to wait that long for something they perceive as being interactive, such as adjusting the volume of a participant. Those kinds of operations typically carry with them a user expectation of being as close to instantaneous as possible. That generally means that your time budget for reaction is on the order of one second or less. See, e.g., http://www.useit.com/papers/responsetime.html >For SIP on 3GPP we found it necessary to mandate SIGComp in order to reduce message size, and therefore reduce transmission delay, and in a similar manner with a conference control protocol using XML, we may need to look at having some compression protocol specified, but we probably do not need to get any more extreme that that. > > I believe the situation differs dramatically. By the time the constraints of mobile terminals were taken into account, the SIP protocol was effectively set down in stone (or, at least, written in moist concrete). At that point, the only realistic solutions were inventing a new protocol or retrofitting compression on top of SIP. I think choosing to add a compression layer to SIP was the right choice in this case. On the other hand, if bandwidth constraints can be considered during the development phase of a protocol, you prevent issues surrounding such retrofits. (And they are not without pain -- you'll notice that ROHC is still struggling with issues surrounding mapping of compression states to SIP constructs). /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 Thu Mar 16 15:07:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJykx-0007La-Cc; Thu, 16 Mar 2006 15:07:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJykw-0007LS-Kb for xcon@ietf.org; Thu, 16 Mar 2006 15:07:34 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJykw-0006uR-4l for xcon@ietf.org; Thu, 16 Mar 2006 15:07:34 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FJykm-0003yN-Ev for xcon@ietf.org; Thu, 16 Mar 2006 14:07:26 -0600 From: "Brian Rosen" To: Subject: FW: Why Size Really Can Matter (was Re: [XCON] Conference Control ) Date: Thu, 16 Mar 2006 15:07:28 -0500 Message-ID: <2b5901c64935$42dafce0$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.2670 Thread-Index: AcZJEGRvxm5WisBYRf6GRssCFwULSgADacLgAANpfxAAANOhYAABglVA 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: 86f85b2f88b0d50615aed44a7f9e33c7 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org We seemed to have dropped the list from the cc: in the last exchange. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, March 16, 2006 2:42 PM To: 'Sean Olson' Cc: 'Adam Roach' Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control ) Clearly, I'm more focused on audio and video for conference control. I'll admit I have little implementation experience with text. I think the only media we have is audio, video, text and screen/cursor data. If you are worried about smell or taste, we have other issues. While I haven't IMPLEMENTED text, I've used it a fair amount, and I still don't see the issue. With "AIM" style IM, you can create a chat room, but, in my experience, you don't change membership much. In larger scale chat room (IRC channel) stuff, there is a lot of coming and going, but it's on the order of one every several seconds; a 1/2 second delay would be nothing, the semantics of joining or leaving is simple, and the roster announcement is simple. I'll agree that in either case, you don't do much mixer modification on a text media channel. There is not a lot of experience beyond H.323/T.120 for "data" (screen/cursor) media that I'm aware of. Henning has been doing some work. While I can imagine some "mixer" controls, I would think that you wouldn't be doing a lot beyond the floor control related stuff (who has the pen?). OTOH its overall management is pretty simple. And, BTW, sidebars are most definitely mixer state for all media I know of. If you establish a sidebar within a conference, it's the mixer that tells you what you see/hear when someone sends media to the sidebar. You only have a single media stream from the mixer, and you have a single stream to the mixer (per media type, for most kinds of devices in centralized mixer conferences). You tell the mixer whether your media is main conference or sidebar on media sent to the mixer, and the mixer sends you what you should get from other participants versions of the same thing. Unless you plan to change the RTP connections (or the MSRP mechanism), a sidebar is mixer state. For example, unless you plan to signal a separate MSRP connection in the SDP for a sidebar (which I did not think was in anyone's plan), text sidebars are mixer state. Similarly, if you wanted to share a quick sketch with your sidebar buddy, you would send it to the (single) signaled data port you have established with the mixer, and your buddy would get it on his dataport from the mixer INSTEAD OF (not in addition to) the "main conference" data. It's the mixer that does this. Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Thursday, March 16, 2006 2:09 PM To: br@brianrosen.net; Adam Roach Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control ) I see the disconnect and this is a really good point to raise. You are very much focused on mixer management. I am very much focused on conference management. And it feels to me like a train wreck to force both into the same protocol if they have such different requirements (in terms of latency, for example). Your comment that mixer management is more important or more frequent makes a lot of sense if you are talking about audio and video only. I think that is a critical use case, but not the only use case. I'm concerned also about data collaboration, instant messaging, and host of other non-audio/video media for which "mixing" takes on a whole new meaning. BTW, in those other media, sidebars are most definitely not just "mixer state" :-) I can give other examples, but I get the impression it doesn't matter because those examples apply to non-audio/video scenarios or at least to true multimedia scenarios. Is this a goal for XCON? In my experience with these more general conferencing scenarios, the state notification traffic dwarfs the conference/mixer control traffic. What is your opinion on how this will be handled for mobile devices? Will you not subscribe to event notifications? Will you not care about the latency of those notifications? -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, March 16, 2006 9:32 AM To: 'Adam Roach'; 'Drage, Keith (Keith)' Cc: xcon@ietf.org Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control ) I agree with Adam. I keep harping on the operation of setting a value to a mixer control as the most significant influence on the protocol design. Sean (and others) have wanted to talk about richness of conference establishment. I don't get it; you establish the call seldom, you change the mixer often. We can put up with considerable ugliness on conference management in exchange for efficient mixer management. I don't think the "mixer efficient" protocols are particularly ugly on the conference management side, but the "conference management rich" proposals are pretty awful for mixer management efficiency. I really do think a mobile client wants to manage its mixer, and the "1 second" cite below is NOT representative of acceptable response to manipulating a control that is changing what you hear or see. That number is in the 100-200 ms range or less, although 500 is not completely off the wall. 3 seconds is. Please don't cite sidebar management as a counter-example, or I'll go back to my argument that sidebars are mixer state. Brian -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: Thursday, March 16, 2006 10:43 AM To: Drage, Keith (Keith) Cc: xcon@ietf.org Subject: Re: Why Size Really Can Matter (was Re: [XCON] Conference Control ) [not as chair] Drage, Keith (Keith) wrote: >I don't remember seeing anybody yet quantifying response times for the conference control protocol, apart from some mails a while back that some people seemed to think it could be a replacement for the floor control protocol. > Neither did I, which is why I went through the effort. I quantified the predicted characteristics of the three proposals being offered. I also attempted to quantify the requirements somewhat (or, at least, ask for opinions on the topic) by pondering whether multi-second response times for adjusting media would be acceptable. If the consensus of the working group is "yes," then I'm done. I want to make sure the issue has been considered. That said, I *do* have an informed opinion on the topic, and I'm happy to share it. >For the conference control protocol as I see it at the moment (i.e. >with floor control as an entirely separate protocol) we should be looking for response times of the same order that we achieve with SIP. > I'm not certain this is true. While people are willing to wait multiple seconds to establish a call, it seems unlikely that they're willing to wait that long for something they perceive as being interactive, such as adjusting the volume of a participant. Those kinds of operations typically carry with them a user expectation of being as close to instantaneous as possible. That generally means that your time budget for reaction is on the order of one second or less. See, e.g., http://www.useit.com/papers/responsetime.html >For SIP on 3GPP we found it necessary to mandate SIGComp in order to >reduce message size, and therefore reduce transmission delay, and in a similar manner with a conference control protocol using XML, we may need to look at having some compression protocol specified, but we probably do not need to get any more extreme that that. > > I believe the situation differs dramatically. By the time the constraints of mobile terminals were taken into account, the SIP protocol was effectively set down in stone (or, at least, written in moist concrete). At that point, the only realistic solutions were inventing a new protocol or retrofitting compression on top of SIP. I think choosing to add a compression layer to SIP was the right choice in this case. On the other hand, if bandwidth constraints can be considered during the development phase of a protocol, you prevent issues surrounding such retrofits. (And they are not without pain -- you'll notice that ROHC is still struggling with issues surrounding mapping of compression states to SIP constructs). /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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Mar 16 22:46:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK5vR-00043k-85; Thu, 16 Mar 2006 22:46:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK5vQ-00043e-4Q for xcon@ietf.org; Thu, 16 Mar 2006 22:46:52 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK5vP-0006a3-RH for xcon@ietf.org; Thu, 16 Mar 2006 22:46:52 -0500 Received: from [192.168.0.41] (pool-141-153-201-232.mad.east.verizon.net [141.153.201.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k2H3kfwD000802 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 16 Mar 2006 22:46:42 -0500 (EST) In-Reply-To: <441866AA.9080504@estacado.net> References: <45730E094814E44488F789C1CDED27AE03118907@gbnewp0758m.eu.ubiquity.net> <43DA4377.5020900@cs.columbia.edu> <441866AA.9080504@estacado.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Subject: Re: Why Size Really Can Matter (was Re: [XCON] Conference Control) Date: Thu, 16 Mar 2006 22:46:30 -0500 To: Adam Roach X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Adam Roach , Chris Boulton , xcon@ietf.org, ajohnston@tello.com 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 Jumping into the middle of an interesting conversation... There seems to be some agreement that delays will matter (mostly) for =20= "slider" style operations, such as adjusting the volume. (I'm =20 extrapolating here from the examples given.) For all examples given, only the command delay matters, since the =20 command will take effect once the command reaches the server. Thus, =20 we can ignore the response size for our calculation, for all protocols. At least in my view of the SOAPy proposals, we would not convey the =20 whole conference state with each request, but rather just the =20 parameter you want to change, as in 80 for changing volume for channel 17 to 80. There's a bit of a SOAP wrapper around that, but this is nowhere near =20= 1800 bytes. I cut-and-pasted this into our SOAP header that got =20 generated for our LUMP (ECRIT) prototype by the standard Java SOAP =20 library and got 230 bytes without trying hard to minimize namespace =20 declaration size. HTTP is extra, but probably around 50-100 bytes, =20 depending on the length of the request URL. In practice, you can do much better since you can use gzip =20 compression in this case, either through HTTP Encoding or below HTTP, =20= in TLS. Since the SOAP header is a constant, it will be compressed =20 into a 1-2 byte pointer into the dictionary after the second message. =20= Indeed, I just tried this: 3 messages of the kind above, with SOAP =20 headers, yield a total of 169 bytes, i.e., an average cost per =20 message of about 55 bytes. Four messages compress down to 172 bytes, =20 i.e., 43 bytes/message. I don't see a need for SigComp here Thus, in this particular case, XML "wins" the size competition :-) By the way, does anybody know what happened to the W3C Binary =20 Characterization Working Group? The group supposedly closed in April =20 2005, but it seems to have petered out earlier, judging from http://=20 www.w3.org/XML/Binary/ Henning On Mar 15, 2006, at 2:10 PM, Adam Roach wrote: > (not as chair) > > Because I've spent an inordinate amount of time over the past 5 =20 > years working with issues surrounding mobile terminals, signaling =20 > size, latency, and compression, I wanted to throw in a couple of =20 > relevant points on the topic of message sizes. > > Henning Schulzrinne wrote: > >>> */[Chris Boulton] I get the handset bandwidth =96 I have heard it =20= >>> in almost every IETF meeting I=92ve been to + I also agree it=92s a =20= >>> major consideration BUT lets not just keep harping back to it./* >>> >> >> This is largely a bogus argument. In any multimedia conference, =20 >> the control bandwidth is going to be a tiny fraction of the =20 >> overall bandwidth consumed by media. > > > Right now, more than one major US wireless carrier has deployed =20 > voice services over their existing data networks, which nominally =20 > pass 9.6kbps of data; once you factor in overhead, the real data =20 > throughput of these data connections is on the order of 8kbps. (I =20 > use these carriers as data points because I'm familiar with them; I =20= > would guess that similar deployments have been made in other =20 > countries as well). > > In order to pass voice over these connections, carriers are =20 > generally using codecs like half-rate EVRC, which consumes 4kbps. =20 > This leaves on the order of 4kbps to perform signaling. > > Using the examples in the CCCP, COMP, and CSCP proposals, a =20 > representative request/response exchange takes on the order of the =20 > following sizes: > > - CCCP: ~1800 bytes > - COMP: ~700 bytes > - CSCP: ~156 bytes > > Over the 4kbps available on these actually deployed voice systems, =20 > these exchanges will take the following amounts of time: > > - CCCP: ~3.6 seconds > - COMP: ~1.4 seconds > - CSCP: ~300 ms > > This raises an issue around how long users will be willing to wait =20 > between requesting an action and it taking effect. Is it okay for =20 > it to take several seconds to adjust a volume level or mute a =20 > participant? > >> Have you actually measured the latency for compression? We're =20 >> probably talking 2-3 ms here, based on my experience. >> > > For the middle-of-the-line mobile terminals in wide use today (~100 =20= > MHz processors), running deflate over a 1kb message (the order of =20 > messages we're talking about here) is on the order of 100 ms. Not =20 > outrageous, but not trivial. The bigger issue by an order of =20 > magnitude is the fact that doing this on the CPU requires 100% CPU =20 > utilization during this time period, which impacts battery life =20 > probably more than you would expect. (700 mAh doesn't take you too =20 > far when it's expected to last several days). > > /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Mar 16 22:55:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK63u-0005F2-L3; Thu, 16 Mar 2006 22:55:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK63t-0005Ew-Iz for xcon@ietf.org; Thu, 16 Mar 2006 22:55:37 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK63t-0006wH-9P for xcon@ietf.org; Thu, 16 Mar 2006 22:55:37 -0500 Received: from [192.168.0.41] (pool-141-153-201-232.mad.east.verizon.net [141.153.201.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k2H3tZNW001694 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 16 Mar 2006 22:55:36 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [XCON] Multiple Protocols: What Do You Really Want? Date: Thu, 16 Mar 2006 22:55:26 -0500 To: "Sean Olson" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Chris Boulton , Adam Roach , ajohnston@tello.com, 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 Without addressing the question itself, we have had another object lesson, much closer to home: binary and text encoding of Megaco/H. 248. I haven't been closely involved with Megaco, but this seems to have been exactly a similar compromise: similar functionality, one in a textual rendition (albeit not XML) and one in a binary rendition (ASN.1 BER). Maybe somebody here can say more about this experience. See RFC 3015. On Mar 15, 2006, at 8:26 PM, Sean Olson wrote: > I would say that option 4 is not a complete non-starter. I would draw > the analogy between a WAP browser and a normal browser. There are > sites > that offer support only for WAP, sites that support WAP and regular > browsers, and sites that support only a full browser like Firefox > or IE. > This has not proven to be a non-starter for the web. WBXML/WML is a > compact encoding of the same data model that a richer XML encoding > offers and I think a good example of how we can offer both an encoding > that works well for mobile while preserving the richness of > functionality for other clients. > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Wednesday, March 15, 2006 4:44 PM > To: Chris Boulton > Cc: ajohnston@tello.com; Adam Roach; xcon@ietf.org > Subject: [XCON] Multiple Protocols: What Do You Really Want? > > [not as chair] > > Chris Boulton wrote: > >> It is for these reasons that I was pondering the prospect of XCON >> allowing both a handset friendly interface such as CSCP and a SOAP >> interface for web services where the client might well be another >> application and not a handset. I realise that having two >> interfaces is > >> not ideal, but as long as we are careful in our rules on minimal >> implementation and ability to advertise capabilities to a Conference >> Client I personally feel that this is the best solution to make XCON >> appealing to a wide variety of architectures. >> > > There have been a number of favorable responses to this proposal, and > I'd like to feel out some of the thoughts people have on the topic. > > In particular, if we choose more than one protocol for conference > control, we still must select from one of the following four models: > > 1. The focus must implement all protocols; the endpoints may choose > one. > > 2. The endpoints must implement all protocols; the focus may choose > one. > > 3. Both endpoints and focuses must implement a single specified > protocol, and may implement others. > > 4. Endpoints and focuses implement whichever of the protocols they > want; arbitrary combinations of implementations simply don't > work > together. > > > I would offer that option 4 is a complete nonstarter. There's no point > coming up with a standard that just flat-out doesn't interoperate in > some large percentage of the cases. If we want that, we may as well > let > each vendor come up with their own proprietary signaling protocol. > > Option 3 gets us back to selecting the one sole mandatory-to-implement > protocol, which probably doesn't clear us from the current logjam. > (Anyone who is currently championing a proposal and would be happy > seeing it as an option but not the "mandatory-to-implement" option in > such a scheme, speak up). > > Selecting either option 1 or option 2 would be a tacit admission that > implementation complexity is a non-issue (since doing so approximately > doubles the implementation complexity of either the focuses or the > endpoints) -- and admitting this takes *all* of the wind out of any > arguments regarding the relative implementation complexity of XML > versus > binary. > > So, of those who have so far spoken in favor of having multiple > protocols to do the same thing: which of these four models did you > have > in mind? (Or did I miss one?) > > /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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Mar 16 23:19:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK6R9-0003kT-D7; Thu, 16 Mar 2006 23:19:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK6R7-0003hK-QE for xcon@ietf.org; Thu, 16 Mar 2006 23:19:37 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK6R7-00083I-Ig for xcon@ietf.org; Thu, 16 Mar 2006 23:19:37 -0500 Received: from [192.168.0.41] (pool-141-153-201-232.mad.east.verizon.net [141.153.201.232]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k2H4JaoK020469 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Mar 2006 23:19:37 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: XCON-IETF From: Henning Schulzrinne Date: Thu, 16 Mar 2006 23:19:27 -0500 X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [XCON] On encodings 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 Since we're on the perennially fun topic of protocol encodings, maybe we can get past the stereotypes and try to do an engineering comparison, or at least an attempt at an approximation. Roughly speaking, an XML element is equivalent in functionality to a TLV object: it contains a label (element tag and the 'type' field), length or delimiter fields to figure out the boundaries, and the actual data (value). ASN.1 BER is close enough to TLV for this apples- to-pears comparison. For TLV, you have a type value of 16 to 32 bits, depending on the predictions on the need to extend the protocol. For XML, you have , thus, 4 bytes plus whatever length you make the tag from 'X' to 'WeLikeToPutTheWholeRFCIntoTheTagSoThatTheImplementerDoesntHaveToReadThe RFC'. For length, this is already counted above for XML; for TLV, it would presumably be again 16 or 32 bits. Thus, the basic overhead is fairly similar if you choose small element names. Since numeric labels aren't self-describing at all, this only seems like a fair comparison. The big difference is in the datatypes. Clearly, if you have long binary opaque data, base64 encoding typical for XML costs you about 30%. Integers and floats are trickier: Unless you believe in ASN.1-style variable-length encoding, it is quite possible that in many practical cases, XML integers will be shorter since TLV always has to allocate the maximum range, presumably 32 bits for integers and 32 (single precision) or 64 bits for floats. You can build custom fixed-point types in binary encodings, but they are a pain to get right (All kinds of funny things happen because of signed vs. unsigned issues, for example. Java programmers will hate you if you try this...) Strings are obviously the same size in either TLV or XML, except for the use of delimiters (such as ") or length fields, but that's a wash at roughly 2 bytes each. The one big difference for XML is the namespace declaration. The impact of that depends on the number of namespaces and the size of the overall document. This is also hard to compare since they give you proprietary extensions without the kludges like vendor IDs that binary protocols have to go through (unless they choose similar Java- style or domain-style tags). Indeed, for namespace-style extensions that aren't IANA registered, TLV is usually a pain. You end up with either per-TLV long labels or re-invent the XML-style indirection approach. This is a rough comparison, but it indicates that for the same functionality, the cost isn't all that different. I'm guessing that for protocols that have a common application mix of text and mostly- integer numeric values, that we're talking about 10 to 30%. You do pay a price for very long tags, but only if you can't use gzip- style compression, which essentially does the text-to-code translation automatically and without penalty. I'm not comparing other textual, non-XML approaches here. Frankly, I don't think they have a chance in the market place and the size difference for the ones I have seen isn't all that large. A separate issue is the functionality. This is left as an exercise for another post. Henning _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 00:43:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK7kc-0004VN-5h; Fri, 17 Mar 2006 00:43:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK7kb-0004UD-Cm for xcon@ietf.org; Fri, 17 Mar 2006 00:43:49 -0500 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK7ka-0001PF-Pk for xcon@ietf.org; Fri, 17 Mar 2006 00:43:49 -0500 Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (rwcrmhc11) with SMTP id <20060317054347m1100c6vmbe>; Fri, 17 Mar 2006 05:43:48 +0000 Message-ID: <134b01c64985$78c9ffe0$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: Subject: Re: [XCON] Multiple Protocols: What Do You Really Want? Date: Thu, 16 Mar 2006 23:41:42 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 FWIW, I spent about six months looking at VoIP traces on deployed networks last year, and was only seeing H.248 text encoding on production networks. I can ask former co-workers what they are seeing now (since I changed employers, I don't see the same things :-), but I'm pretty sure that having two encodings is likely to give one that's actually used in most situations. Spencer p.s. I was also seeing a heckuva lot more MGCP than H.248, but everybody was testing H.248. Oh, well. From: "Henning Schulzrinne" > Without addressing the question itself, we have had another object > lesson, much closer to home: binary and text encoding of Megaco/H. 248. I > haven't been closely involved with Megaco, but this seems to have been > exactly a similar compromise: similar functionality, one in a textual > rendition (albeit not XML) and one in a binary rendition (ASN.1 BER). > Maybe somebody here can say more about this experience. See RFC 3015. > > On Mar 15, 2006, at 8:26 PM, Sean Olson wrote: > >> I would say that option 4 is not a complete non-starter. I would draw >> the analogy between a WAP browser and a normal browser. There are sites >> that offer support only for WAP, sites that support WAP and regular >> browsers, and sites that support only a full browser like Firefox or IE. >> This has not proven to be a non-starter for the web. WBXML/WML is a >> compact encoding of the same data model that a richer XML encoding >> offers and I think a good example of how we can offer both an encoding >> that works well for mobile while preserving the richness of >> functionality for other clients. >> >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Wednesday, March 15, 2006 4:44 PM >> To: Chris Boulton >> Cc: ajohnston@tello.com; Adam Roach; xcon@ietf.org >> Subject: [XCON] Multiple Protocols: What Do You Really Want? >> >> [not as chair] >> >> Chris Boulton wrote: >> >>> It is for these reasons that I was pondering the prospect of XCON >>> allowing both a handset friendly interface such as CSCP and a SOAP >>> interface for web services where the client might well be another >>> application and not a handset. I realise that having two interfaces is >> >>> not ideal, but as long as we are careful in our rules on minimal >>> implementation and ability to advertise capabilities to a Conference >>> Client I personally feel that this is the best solution to make XCON >>> appealing to a wide variety of architectures. >>> >> >> There have been a number of favorable responses to this proposal, and >> I'd like to feel out some of the thoughts people have on the topic. >> >> In particular, if we choose more than one protocol for conference >> control, we still must select from one of the following four models: >> >> 1. The focus must implement all protocols; the endpoints may choose >> one. >> >> 2. The endpoints must implement all protocols; the focus may choose >> one. >> >> 3. Both endpoints and focuses must implement a single specified >> protocol, and may implement others. >> >> 4. Endpoints and focuses implement whichever of the protocols they >> want; arbitrary combinations of implementations simply don't work >> together. >> >> >> I would offer that option 4 is a complete nonstarter. There's no point >> coming up with a standard that just flat-out doesn't interoperate in >> some large percentage of the cases. If we want that, we may as well let >> each vendor come up with their own proprietary signaling protocol. >> >> Option 3 gets us back to selecting the one sole mandatory-to-implement >> protocol, which probably doesn't clear us from the current logjam. >> (Anyone who is currently championing a proposal and would be happy >> seeing it as an option but not the "mandatory-to-implement" option in >> such a scheme, speak up). >> >> Selecting either option 1 or option 2 would be a tacit admission that >> implementation complexity is a non-issue (since doing so approximately >> doubles the implementation complexity of either the focuses or the >> endpoints) -- and admitting this takes *all* of the wind out of any >> arguments regarding the relative implementation complexity of XML versus >> binary. >> >> So, of those who have so far spoken in favor of having multiple >> protocols to do the same thing: which of these four models did you have >> in mind? (Or did I miss one?) >> >> /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 > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 02:09:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK95S-0008K6-5A; Fri, 17 Mar 2006 02:09:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK95Q-0008Ib-R7 for xcon@ietf.org; Fri, 17 Mar 2006 02:09:24 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK95Q-0003bo-Gq for xcon@ietf.org; Fri, 17 Mar 2006 02:09:24 -0500 Received: from [192.168.0.102] (ppp-70-249-144-46.dsl.rcsntx.swbell.net [70.249.144.46]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2H79Kni054455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Mar 2006 01:09:21 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441A609B.8060606@nostrum.com> Date: Fri, 17 Mar 2006 01:09:15 -0600 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: Henning Schulzrinne Subject: Re: Why Size Really Can Matter (was Re: [XCON] Conference Control) References: <45730E094814E44488F789C1CDED27AE03118907@gbnewp0758m.eu.ubiquity.net> <43DA4377.5020900@cs.columbia.edu> <441866AA.9080504@estacado.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.144.46 is authenticated by a trusted mechanism) X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Chris Boulton , Adam Roach , xcon@ietf.org, ajohnston@tello.com 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 [not as chair] Henning Schulzrinne wrote: > At least in my view of the SOAPy proposals, we would not convey the > whole conference state with each request, but rather just the > parameter you want to change, as in > > 80 > > for changing volume for channel 17 to 80. Excellent. That's more the nature of the conversation I wanted to have: considering that size *does* matter, and discussing whether that points towards a single solution, or whether any of the other proposals can meet the requirement with the proper adjustments. There's a slight problem with your example, though. Things like volume adjustments will be performed on the template part of the conference object. Considering audio attenuation to be a primitive of the conference control protocol goes against everything we've done in the model to date. Because templates can be defined after the conference control protocol has been carved in stone, the conference control protocol needs to have the ability to adjust arbitrary other things. To give a more concrete (if somewhat silly) example, consider that a template in the future may have not just volume controls on every audio channel, but also controls that allow users to select from a number of voice distortion filters. The goal is that such a template can be defined without having to back and add a "change voice distortion setting" primitive to the conference control protocol. Unfortunately, this makes your example something more like: 80 Not a killer, but certainly nowhere near as concise anymore. The thing that CSCP does that I think is novel is that it allows concise, direct access to any changeable element using a unique integer. The decision to use BFCP as a transport was simply because it would already be implemented in both clients and servers. The same approach can be applied to any encoding to reduce the size of messages; if you combine this with a concerted effort to make the remainder of the messages small, then I think you have a perfectly acceptable solution: 80 On the other hand, if a request that simply says "ping" ends up as large as this: Then I believe we need to go back to the drawing board. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 08:10:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEim-0005N7-HX; Fri, 17 Mar 2006 08:10:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEil-0005JL-4d for xcon@ietf.org; Fri, 17 Mar 2006 08:10:23 -0500 Received: from smtp1.wanadoo.co.uk ([193.252.22.158] helo=smtp1.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKEik-0006BO-7w for xcon@ietf.org; Fri, 17 Mar 2006 08:10:23 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3002.me.freeserve.com (SMTP Server) with ESMTP id C21861C0014A; Fri, 17 Mar 2006 14:10:21 +0100 (CET) Received: from RW (user-4144.l6.c2.dsl.pol.co.uk [84.66.112.48]) by mwinf3002.me.freeserve.com (SMTP Server) with SMTP id 238D61C00143; Fri, 17 Mar 2006 14:10:21 +0100 (CET) X-ME-UUID: 20060317131021145.238D61C00143@mwinf3002.me.freeserve.com Message-ID: <00e201c649c4$262cb680$0600a8c0@RW> From: "Pete Cordell" To: "XCON-IETF" , "Henning Schulzrinne" References: Subject: Re: [XCON] On encodings Date: Fri, 17 Mar 2006 13:09:45 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00DA_01C649C4.0FA447C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d 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 This is a multi-part message in MIME format. ------=_NextPart_000_00DA_01C649C4.0FA447C0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit As mentioned in the other post, this is interesting analysis, so I thought I'd try to add a bit more detail to it. I've compared XML encodings with long tag names with a Megaco like encoding (in this case Lumas*) and a binary encoding (Lumas again). *To justify the choice of Lumas encoding here, the original Lumas was an attempt to formalise the Megaco text encoding so that it could work for both text and binary. So Lumas has a lot in common with Megaco encoding. Indeed, change "context = 123 { ..." to "context = { 123 ..." and you're there! Note that although Megaco is a text encoding (one of them anyway!), it probably has more similarities in terms of message length with a binary encoding than XML encoding. This is because in a number of cases Megaco has no tag, or short tag. Tagging is obviously a big issue. To get an idea of the length of typical XML tags I grepped (well Perled really) out the element and attribute names defined in the CPCP draft. When doing this I got an average tag length of 12.7 characters. I noted that many of the names were of the form "a-long-tag-name", so I derived short tag names by taking the first letter of each sub-word. The average of this was 2.08 characters. (I've attached the Perl code used so that you can replicate my analysis if desired.) As noted in the other mail, XSD does not lend itself to designing XML with small tags. If everything is called X (or similar) the XSD doesn't describe the message very well. So, although you can define an XSD with small tags, I think in practice you wouldn't! (Aside: This is why Lumas allows for specifying a long descriptive name in the message definition, and specifying a short name for tagging.) For the binary encoding I used Lumas's binary rules. This uses variable length tag and length fields similar to how UTF-8 is variable length. As UTF-8 is commonly part of XML I can't see that this is an issue. So here's the results I came up with: Bool: XML - Typical name: 5(<>) + 2*12(tag) + 1(data) = 30 XML - Short name: 5(<>) + 2 * 2(tag) + 1(data) = 10 Lumas - Text Long Name: 2(note 1) + 12(tag) + 1(data) = 15 Lumas - Text short name: 2(note 1) + 2(tag) + 1(data) = 5 Lumas - Text untagged: 1(note 2) + 1(data) = 2 Lumas binary: 2(tag+len) + 0(data note 3) = 2 Ratio XML Long/Lumas long: 2 Ratio XML long/Lumas short: 6 Ratio XML short/Lumas short: 2 Ratio XML long/binary: 15 Ratio XML short/binary: 15 16 bit int: XML - Typical name: 5(<>) + 2*12(tag) + 5(data) = 34 XML - Short name: 5(<>) + 2 * 2(tag) + 5(data) = 14 Lumas - Text Long Name: 2(note 1) + 12(tag) + 5(data) = 19 Lumas - Text short name: 2(note 1) + 2(tag) + 5(data) = 9 Lumas - Text untagged: 1(note 2) + 5(data) = 6 Lumas binary: 2(tag+len) + 2(data) = 4 Ratio XML Long/Lumas long: 1.78 Ratio XML long/Lumas short: 3.7 Ratio XML short/Lumas short: 1.5 Ratio XML long/binary: 8.5 Ratio XML short/binary: 3.5 32 bit int: XML - Typical name: 5(<>) + 2*12(tag) + 10(data) = 39 XML - Short name: 5(<>) + 2 * 2(tag) + 10(data) = 19 Lumas - Text Long Name: 2(note 1) + 12(tag) + 10(data) = 24 Lumas - Text short name: 2(note 1) + 2(tag) + 10(data) = 14 Lumas - Text untagged: 1(note 2) + 10(data) = 11 Lumas binary: 2(tag+len) + 4(data) = 6 Ratio XML Long/Lumas long: 1.6 Ratio XML long/Lumas short: 2.7 Ratio XML short/Lumas short: 1.3 Ratio XML long/binary: 6.5 Ratio XML short/binary: 3.1 string: http://example.com/conference/on (length = 32) XML - Typical name: 5(<>) + 2*12(tag) + 32(data) = 61 XML - Short name: 5(<>) + 2 * 2(tag) + 32(data) = 41 Lumas - Text Long Name: 2(note 1) + 12(tag) + 2(quoting) + 32(data) = 48 Lumas - Text short name: 2(note 1) + 2(tag) + 2(quoting) + 32(data) = 38 Lumas - Text untagged: 1(note 2) + 2(quoting) + 32(data) = 35 Lumas binary: 2(tag+len) + 32(data) = 34 Ratio XML Long/Lumas long: 1.27 Ratio XML long/Lumas short: 1.6 Ratio XML short/Lumas short: 1.07 Ratio XML long/binary: 1.79 Ratio XML short/binary: 1.2 string: Sally (length = 5) XML - Typical name: 5(<>) + 2*12(tag) + 5(data) = 34 XML - Short name: 5(<>) + 2 * 2(tag) + 5(data) = 14 Lumas - Text Long Name: 2(note 1) + 12(tag) + 2(quoting) + 5(data) = 21 Lumas - Text short name: 2(note 1) + 2(tag) + 2(quoting) + 5(data) = 11 Lumas - Text untagged: 1(note 2) + 5(data) = 6 Lumas binary: 2(tag+len) + 5(data) = 7 Ratio XML Long/Lumas long: 1.6 Ratio XML long/Lumas short: 3.0 Ratio XML short/Lumas short: 1.27 Ratio XML long/binary: 4.8 Ratio XML short/binary: 2 note 1: Lumas needs an = sign and a minimum of 1 white space char to separate values. note 2: Lumas needs a minimum of 1 white space char to separate values. note 3: The Lumas binary encoding encodes a bool into 2 bytes using a special length code. Of course the overall message saving depends on how often each of these types comes up. To me the analysis shows that a binary encoding is typically very much shorter than a typical XML encoding (with long tag names etc.). BUT: Most of this gain is realised by using a Megaco like text encoding. (This is captured by the XML long/Lumas short ratio.) As this is what Lumas offers, rather than inventing yet another message encoding method, I would say that the debate should be between an XML encoding and a Lumas text encoding rather than between an XML encoding and a binary encoding! Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= ----- Original Message ----- From: "Henning Schulzrinne" To: "XCON-IETF" Sent: Friday, March 17, 2006 4:19 AM Subject: [XCON] On encodings > Since we're on the perennially fun topic of protocol encodings, maybe we > can get past the stereotypes and try to do an engineering comparison, or > at least an attempt at an approximation. Roughly speaking, an XML element > is equivalent in functionality to a TLV object: it contains a label > (element tag and the 'type' field), length or delimiter fields to figure > out the boundaries, and the actual data (value). ASN.1 BER is close > enough to TLV for this apples- to-pears comparison. > > For TLV, you have a type value of 16 to 32 bits, depending on the > predictions on the need to extend the protocol. For XML, you have , thus, 4 bytes plus whatever length you make the tag from 'X' to > 'WeLikeToPutTheWholeRFCIntoTheTagSoThatTheImplementerDoesntHaveToReadThe > RFC'. > > For length, this is already counted above for XML; for TLV, it would > presumably be again 16 or 32 bits. > > Thus, the basic overhead is fairly similar if you choose small element > names. Since numeric labels aren't self-describing at all, this only > seems like a fair comparison. > > The big difference is in the datatypes. Clearly, if you have long binary > opaque data, base64 encoding typical for XML costs you about 30%. > > Integers and floats are trickier: Unless you believe in ASN.1-style > variable-length encoding, it is quite possible that in many practical > cases, XML integers will be shorter since TLV always has to allocate the > maximum range, presumably 32 bits for integers and 32 (single precision) > or 64 bits for floats. You can build custom fixed-point types in binary > encodings, but they are a pain to get right (All kinds of funny things > happen because of signed vs. unsigned issues, for example. Java > programmers will hate you if you try this...) > > Strings are obviously the same size in either TLV or XML, except for the > use of delimiters (such as ") or length fields, but that's a wash at > roughly 2 bytes each. > > The one big difference for XML is the namespace declaration. The impact > of that depends on the number of namespaces and the size of the overall > document. This is also hard to compare since they give you proprietary > extensions without the kludges like vendor IDs that binary protocols have > to go through (unless they choose similar Java- style or domain-style > tags). Indeed, for namespace-style extensions that aren't IANA > registered, TLV is usually a pain. You end up with either per-TLV long > labels or re-invent the XML-style indirection approach. > > This is a rough comparison, but it indicates that for the same > functionality, the cost isn't all that different. I'm guessing that for > protocols that have a common application mix of text and mostly- integer > numeric values, that we're talking about 10 to 30%. > > You do pay a price for very long tags, but only if you can't use gzip- > style compression, which essentially does the text-to-code translation > automatically and without penalty. > > I'm not comparing other textual, non-XML approaches here. Frankly, I > don't think they have a chance in the market place and the size > difference for the ones I have seen isn't all that large. > > A separate issue is the functionality. This is left as an exercise for > another post. > > Henning > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > ------=_NextPart_000_00DA_01C649C4.0FA447C0 Content-Type: application/octet-stream; name="get-xsd-names.pl" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="get-xsd-names.pl" #!/usr/bin/perl if( open( FIN, 'draft-ietf-xcon-cpcp-01.txt' ) ) { my $mode = 'out'; while( ) { $mode = 'in' if / From: "Pete Cordell" To: "XCON-IETF" , "Henning Schulzrinne" References: Subject: Re: [XCON] On encodings - observations Date: Fri, 17 Mar 2006 12:39:59 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) 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 This is interesting analysis, so I thought I'd try to add a bit more detail to it. I've got some minor observations on the original post here, and some more detailed analysis in a separate post. ----- Original Message From: "Henning Schulzrinne" > For XML, you have > , thus, 4 bytes plus whatever length you make the tag Should be e.g. 5 bytes. > Thus, the basic overhead is fairly similar if you choose small element > names. Since numeric labels aren't self-describing at all, this only > seems like a fair comparison. My observation on this is that XSD does not lend itself to designing XML with small tags. If everything is called X (or similar) the XSD doesn't describe the message very well. So, although you can define an XSD with small tags, I think in practice you wouldn't! (Aside: This is why Lumas allows for specifying a long descriptive name in the message definition, and specifying a short name for tagging.) > Integers and floats are trickier: Unless you believe in ASN.1-style > variable-length encoding, it is quite possible that in many practical > cases, XML integers will be shorter since TLV always has to allocate the > maximum range, This depends significantly on the distribution of the numbers within the range. If you have a 16 bit number, only the numbers 0-9 will be shorter than the binary encoding (not that I'm pushing binary, as you will see. Just trying to get the facts straight.) This is 0.01% of the time _if_ the numbers are evenly distributed. If they are evenly distributed (which is a big assumption) text will be longer in 98% of the cases. For 32 bit values, text will be longer in 99.999% of the cases. (again, distribution is a big issue here.) > You do pay a price for very long tags, but only if you can't use gzip- > style compression, which essentially does the text-to-code translation > automatically and without penalty. gzip isn't free. It costs on small devices and servers handling a lots of connections. Hence I don't think you can say it is without penalty. Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 08:14:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEmJ-0008D5-FQ; Fri, 17 Mar 2006 08:14:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEmI-0008Cd-EP for xcon@ietf.org; Fri, 17 Mar 2006 08:14:02 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKEmI-0006Mc-3G for xcon@ietf.org; Fri, 17 Mar 2006 08:14:02 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FKElv-0003Up-Jp; Fri, 17 Mar 2006 07:13:39 -0600 From: "Brian Rosen" To: "'Adam Roach'" , "'Henning Schulzrinne'" Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control) Date: Fri, 17 Mar 2006 08:13:39 -0500 Message-ID: <2ce601c649c4$9d49e080$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.2670 Thread-Index: AcZJkbtpyeMqgK0URx23D9/Z577+3wAMbUrA In-Reply-To: <441A609B.8060606@nostrum.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.5 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: 'Chris Boulton' , 'Adam Roach' , xcon@ietf.org, ajohnston@tello.com X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Right. Generally, binary encoded and text encoded protocols are not much different in size. We showed that with Megaco. HOW you express protocol actions is the thing that matters. I think the integer idea has merit, and could be applied to any of the protocols. It means that you want a "set/get" primitive, and a naming convention. For most of the mixer controls, that's about as close to ideal as you can get, and would also work for any element in a template that has a simple value. That covers a lot of ground. Compression clearly can help also. If you are sliding a slider, then even if you have a large piece of prolog, that would get compressed after the first time you sent it into some smaller number of bits. If we do have compression, I agree we need to design it into the protocol from the get-go. Brian -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: Friday, March 17, 2006 2:09 AM To: Henning Schulzrinne Cc: Chris Boulton; Adam Roach; xcon@ietf.org; ajohnston@tello.com Subject: Re: Why Size Really Can Matter (was Re: [XCON] Conference Control) [not as chair] Henning Schulzrinne wrote: > At least in my view of the SOAPy proposals, we would not convey the > whole conference state with each request, but rather just the > parameter you want to change, as in > > 80 > > for changing volume for channel 17 to 80. Excellent. That's more the nature of the conversation I wanted to have: considering that size *does* matter, and discussing whether that points towards a single solution, or whether any of the other proposals can meet the requirement with the proper adjustments. There's a slight problem with your example, though. Things like volume adjustments will be performed on the template part of the conference object. Considering audio attenuation to be a primitive of the conference control protocol goes against everything we've done in the model to date. Because templates can be defined after the conference control protocol has been carved in stone, the conference control protocol needs to have the ability to adjust arbitrary other things. To give a more concrete (if somewhat silly) example, consider that a template in the future may have not just volume controls on every audio channel, but also controls that allow users to select from a number of voice distortion filters. The goal is that such a template can be defined without having to back and add a "change voice distortion setting" primitive to the conference control protocol. Unfortunately, this makes your example something more like: 80 Not a killer, but certainly nowhere near as concise anymore. The thing that CSCP does that I think is novel is that it allows concise, direct access to any changeable element using a unique integer. The decision to use BFCP as a transport was simply because it would already be implemented in both clients and servers. The same approach can be applied to any encoding to reduce the size of messages; if you combine this with a concerted effort to make the remainder of the messages small, then I think you have a perfectly acceptable solution: 80 On the other hand, if a request that simply says "ping" ends up as large as this: Then I believe we need to go back to the drawing board. /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 Fri Mar 17 08:37:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKF8m-000759-6q; Fri, 17 Mar 2006 08:37:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKF8l-000754-2I for xcon@ietf.org; Fri, 17 Mar 2006 08:37:15 -0500 Received: from smtp1.wanadoo.co.uk ([193.252.22.158] helo=smtp1.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKF8j-0006wt-Hp for xcon@ietf.org; Fri, 17 Mar 2006 08:37:15 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3011.me.freeserve.com (SMTP Server) with ESMTP id ED6011C0008D; Fri, 17 Mar 2006 14:37:12 +0100 (CET) Received: from RW (user-4144.l6.c2.dsl.pol.co.uk [84.66.112.48]) by mwinf3011.me.freeserve.com (SMTP Server) with SMTP id 9744D1C00082; Fri, 17 Mar 2006 14:37:12 +0100 (CET) X-ME-UUID: 20060317133712619.9744D1C00082@mwinf3011.me.freeserve.com Message-ID: <011201c649c7$e69fcdf0$0600a8c0@RW> From: "Pete Cordell" To: "Adam Roach" References: <45730E094814E44488F789C1CDED27AE03118969@gbnewp0758m.eu.ubiquity.net><100301c63ded$50544000$b100a8c0@RW> <4415F10A.8030807@nostrum.com> Subject: Re: [XCON] Encoding: Binary, Text, or Both and Lumas Date: Fri, 17 Mar 2006 13:37:11 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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 Adam, Thanks for the feedback. However, I think you've mis-understood where Lumas fits in. It is essentially a alternative for XSD and does not compete with the likes of CCCP, CPCP etc. Rather these protocols could use Lumas instead of XSD if they wished. Lumas is related to the encoding debate, which still seems very active from what I can see. Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= ----- Original Message ----- From: "Adam Roach" To: "Pete Cordell" Cc: Sent: Monday, March 13, 2006 10:24 PM Subject: Re: [XCON] Encoding: Binary, Text, or Both and Lumas > [as chair] > > While the Developer in me thinks Lumas looks really cool and would be a > barrel of monkeys to play around with, the Working Group Chair in me > requires me to exclude it from consideration. After floundering in this > area for a while, we had a deadline a few months ago on new proposals > for the conference manipulation protocol. > > Consequently, we cannot take on additional candidates at this time. The > protocol will be selected from the set of CCCP, CSCP, or some variant on > the SOAP proposals. > > /a > > Pete Cordell wrote: > >> I just noticed that Chris's email mentioned that one of the points for >> debate was whether the XCON 'protocol' should be Binary, Text, or Both. >> I just wanted to mention that, as well as a text encoding, Lumas also has >> binary encoding rules. >> >> As already mentioned, there is already code to convert a Lumas definition >> into ABNF, and conceivably code could be written to convert Lumas into >> ASCII-art style drawings similar to that used in BFCP. >> >> Hence, by using a higher level of abstraction like Lumas you can make >> such details as text vs. binary vs. ABNF vs. ASCII-art an implementation >> detail! >> >> As before, more info on Lumas is at: http://www.tech-know-ware.com/lumas >> >> Regards, >> >> Pete. >> >> P.S. Further to my previous e-mail, to give you another idea of how a >> standard Lumas text message might look compared to other encodings, I've >> dug out a file I created a long time back that compares an old SIP >> message encoded using 'ABNF', Lumas and XML. Obviously in the latter 2 >> cases there are a number of ways that the encoding could have been done, >> so they should be considered for guidance only! Note also that in the >> case of Lumas and XML, line breaks have no significance so the line >> breaks shown are effectively pretty-print issues. Additionally, if I was >> doing a Lumas encoding of SIP I would have used shorter tag/header names >> more along the lines of SDP, but again, that's an implementation issue. >> >> ----------------- 'ABNF' --------------------- >> >> INVITE sip:watson@boston.bell-tel.com SIP/2.0 >> Via: SIP/2.0/UDP kton.bell-tel.com >> From: A. Bell >> To: T. Watson >> Call-ID: 3298420296@kton.bell-tel.com >> CSeq: 1 INVITE >> Subject: Mr. Watson, come here. >> Content-Type: application/sdp >> Content-Length: 111 >> >> v=0 >> o=bell 53655765 2353687637 IN IP4 128.3.4.5 >> s=Mr. Watson, come here. >> c=IN IP4 kton.bell-tel.com >> m=audio 3456 RTP/AVP 0 3 4 5 >> >> --------------- LUMAS ------------------------ >> >> INVITE={sip:watson@boston.bell-tel.com SIP/2.0 >> Via={SIP/2.0/UDP kton.bell-tel.com} >> From={sip:a.g.bell@bell-tel.com "A. Bell"} >> To={sip:watson@bell-tel.com "T. Watson"} >> Call-ID=3298420296@kton.bell-tel.com >> CSeq={1 INVITE } >> Subject="Mr. Watson, come here." >> Content-Type=application/sdp >> } >> SDP={ >> v=0 >> o={bell 53655765 2353687637 IN=IP4=128.3.4.5} >> s="Mr. Watson, come here." >> c={IN=IP4=kton.bell-tel.com} >> m={audio 3456 RTP=AVP 0,3,4,5} >> } >> >> >> --------------- XML ---------------------- >> >> >> >> >> >> >> 3298420296@kton.bell-tel.com >> >> Mr. Watson, come here. >> >> >> >> > > addrtype="IP4" address="128.3.4.5"/> >> Mr. Watson, come here. >> >> >> 0345 >> >> >> -- >> ============================================= >> Pete Cordell >> Tech-Know-Ware Ltd >> for XML to C++ data binding visit >> http://www.tech-know-ware.com/lmx >> (or http://www.xml2cpp.com) >> ============================================= >> >> >> >> _______________________________________________ >> 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 Fri Mar 17 10:23:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGnl-0002Kw-8f; Fri, 17 Mar 2006 10:23:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGnk-00029Y-65 for xcon@ietf.org; Fri, 17 Mar 2006 10:23:40 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKGni-0002Fe-TZ for xcon@ietf.org; Fri, 17 Mar 2006 10:23:40 -0500 Received: from [192.168.0.41] (pool-141-153-201-232.mad.east.verizon.net [141.153.201.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k2HFNbG9008603 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 17 Mar 2006 10:23:38 -0500 (EST) In-Reply-To: <00e101c649c4$25dee4a0$0600a8c0@RW> References: <00e101c649c4$25dee4a0$0600a8c0@RW> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00AE848E-2C82-433B-81D7-EFFB4A914558@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [XCON] On encodings - observations Date: Fri, 17 Mar 2006 10:23:38 -0500 To: "Pete Cordell" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org > This depends significantly on the distribution of the numbers > within the range. If you have a 16 bit number, only the numbers > 0-9 will be shorter than the Certainly. In most cases of interest here, numbers tend to be small, with exceptions. > binary encoding (not that I'm pushing binary, as you will see. Just > trying to get the facts straight.) This is 0.01% of the time _if_ > the numbers are evenly distributed. If they are evenly distributed > (which is a big assumption) text will be longer in 98% of the > cases. For 32 bit values, text will be longer in 99.999% of the > cases. (again, distribution is a big issue here.) > >> You do pay a price for very long tags, but only if you can't use >> gzip- style compression, which essentially does the text-to-code >> translation automatically and without penalty. > > gzip isn't free. It costs on small devices and servers handling a > lots of connections. Hence I don't think you can say it is without > penalty. > Sure. Let's design systems that work on vacuum-tube computers. This is getting silly - the rest of the world does just fine with TLS and three-tier web service architectures, and we worry about gzip overhead on a server that handles echo cancellation and video transcoding. Maybe there is a corollary here to nethead vs. bellhead: namely those who have last programmed on a large scale around 1980 vs. the rest of the world that actually worries about programmer productivity and fitting into the computing infrastructure of the 21st century. Henning _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 10:34:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGxw-0000dl-0v; Fri, 17 Mar 2006 10:34:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGxv-0000dg-A2 for xcon@ietf.org; Fri, 17 Mar 2006 10:34:11 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKGxt-0002Zm-Q8 for xcon@ietf.org; Fri, 17 Mar 2006 10:34:11 -0500 Received: from [192.168.0.41] (pool-141-153-201-232.mad.east.verizon.net [141.153.201.232]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k2HFY7X9009693 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 17 Mar 2006 10:34:08 -0500 (EST) In-Reply-To: <00e201c649c4$262cb680$0600a8c0@RW> References: <00e201c649c4$262cb680$0600a8c0@RW> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <418386E8-A755-47D2-87DC-C0324B7854C8@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [XCON] On encodings Date: Fri, 17 Mar 2006 10:33:56 -0500 To: "Pete Cordell" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: XCON-IETF 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 Pete, Thanks for the summary. I'll just add that having the IETF, in a small niche of its portfolio, go out and invent a new text encoding that nobody else uses and is likely to use (sorry...) seems just plain hubris. We're no longer in the world of one-off systems where we build every system from scratch as if the only tool in our tool kit was a C compiler (I suspect some people here would actually prefer assembler...). Every new encoding means new libraries, means new possibilities for buffer overflows, new porting for every language from C to C# to PHP to Java to Perl to Ruby, new training, new debugging tools and new interoperability testing. I can choose among dozens of XML and SOAP libraries, maintained by the largest IT corporations on the planet if that's my choice, and a corresponding number of tools, from open source to XMLspy and kin. Why in the world would a sane developer create their own new niche encoding when the rest of their system is going to be built using modern software tools and will already have to support XML anyway? I'm afraid I'm not going to be spending time on Lumas analysis, I'm sorry to say. The IETF is a tiny part of the software universe and needs to learn to play nice with the 99.9% of the developers that don't show up at IETF meetings. Henning On Mar 17, 2006, at 8:09 AM, Pete Cordell wrote: > As mentioned in the other post, this is interesting analysis, so I > thought I'd try to add a bit more detail to it. > > I've compared XML encodings with long tag names with a Megaco like > encoding (in this case Lumas*) and a binary encoding (Lumas again). > > *To justify the choice of Lumas encoding here, the original Lumas > was an attempt to formalise the Megaco text encoding so that it > could work for both text and binary. So Lumas has a lot in common > with Megaco encoding. Indeed, change "context = 123 { ..." to > "context = { 123 ..." and you're there! > > Note that although Megaco is a text encoding (one of them anyway!), > it probably has more similarities in terms of message length with a > binary encoding than XML encoding. This is because in a number of > cases Megaco has no tag, or short tag. > > Tagging is obviously a big issue. To get an idea of the length of > typical XML tags I grepped (well Perled really) out the element and > attribute names defined in the CPCP draft. When doing this I got > an average tag length of 12.7 characters. I noted that many of the > names were of the form "a-long-tag-name", so I derived short tag > names by taking the first letter of each sub-word. The average of > this was 2.08 characters. (I've attached the Perl code used so > that you can replicate my analysis if desired.) > > As noted in the other mail, XSD does not lend itself to designing > XML with small tags. If everything is called X (or similar) the > XSD doesn't describe the message very well. So, although you can > define an XSD with small tags, I think in practice you wouldn't! > (Aside: This is why Lumas allows for specifying a long descriptive > name in the message definition, and specifying a short name for > tagging.) > > > For the binary encoding I used Lumas's binary rules. This uses > variable length tag and length fields similar to how UTF-8 is > variable length. As UTF-8 is commonly part of XML I can't see that > this is an issue. > > So here's the results I came up with: > > Bool: > XML - Typical name: 5(<>) + 2*12(tag) + 1(data) = 30 > XML - Short name: 5(<>) + 2 * 2(tag) + 1(data) = 10 > Lumas - Text Long Name: 2(note 1) + 12(tag) + 1(data) = 15 > Lumas - Text short name: 2(note 1) + 2(tag) + 1(data) = 5 > Lumas - Text untagged: 1(note 2) + 1(data) = 2 > Lumas binary: 2(tag+len) + 0(data note 3) = 2 > Ratio XML Long/Lumas long: 2 > Ratio XML long/Lumas short: 6 > Ratio XML short/Lumas short: 2 > Ratio XML long/binary: 15 > Ratio XML short/binary: 15 > > 16 bit int: > XML - Typical name: 5(<>) + 2*12(tag) + 5(data) = 34 > XML - Short name: 5(<>) + 2 * 2(tag) + 5(data) = 14 > Lumas - Text Long Name: 2(note 1) + 12(tag) + 5(data) = 19 > Lumas - Text short name: 2(note 1) + 2(tag) + 5(data) = 9 > Lumas - Text untagged: 1(note 2) + 5(data) = 6 > Lumas binary: 2(tag+len) + 2(data) = 4 > Ratio XML Long/Lumas long: 1.78 > Ratio XML long/Lumas short: 3.7 > Ratio XML short/Lumas short: 1.5 > Ratio XML long/binary: 8.5 > Ratio XML short/binary: 3.5 > > 32 bit int: > XML - Typical name: 5(<>) + 2*12(tag) + 10(data) = 39 > XML - Short name: 5(<>) + 2 * 2(tag) + 10(data) = 19 > Lumas - Text Long Name: 2(note 1) + 12(tag) + 10(data) = 24 > Lumas - Text short name: 2(note 1) + 2(tag) + 10(data) = 14 > Lumas - Text untagged: 1(note 2) + 10(data) = 11 > Lumas binary: 2(tag+len) + 4(data) = 6 > Ratio XML Long/Lumas long: 1.6 > Ratio XML long/Lumas short: 2.7 > Ratio XML short/Lumas short: 1.3 > Ratio XML long/binary: 6.5 > Ratio XML short/binary: 3.1 > > string: http://example.com/conference/on (length = 32) > XML - Typical name: 5(<>) + 2*12(tag) + 32(data) = 61 > XML - Short name: 5(<>) + 2 * 2(tag) + 32(data) = 41 > Lumas - Text Long Name: 2(note 1) + 12(tag) + 2(quoting) + 32(data) > = 48 > Lumas - Text short name: 2(note 1) + 2(tag) + 2(quoting) + 32(data) > = 38 > Lumas - Text untagged: 1(note 2) + 2(quoting) + 32(data) = 35 > Lumas binary: 2(tag+len) + 32(data) = 34 > Ratio XML Long/Lumas long: 1.27 > Ratio XML long/Lumas short: 1.6 > Ratio XML short/Lumas short: 1.07 > Ratio XML long/binary: 1.79 > Ratio XML short/binary: 1.2 > > string: Sally (length = 5) > XML - Typical name: 5(<>) + 2*12(tag) + 5(data) = 34 > XML - Short name: 5(<>) + 2 * 2(tag) + 5(data) = 14 > Lumas - Text Long Name: 2(note 1) + 12(tag) + 2(quoting) + 5(data) > = 21 > Lumas - Text short name: 2(note 1) + 2(tag) + 2(quoting) + 5(data) > = 11 > Lumas - Text untagged: 1(note 2) + 5(data) = 6 > Lumas binary: 2(tag+len) + 5(data) = 7 > Ratio XML Long/Lumas long: 1.6 > Ratio XML long/Lumas short: 3.0 > Ratio XML short/Lumas short: 1.27 > Ratio XML long/binary: 4.8 > Ratio XML short/binary: 2 > > note 1: Lumas needs an = sign and a minimum of 1 white space char > to separate values. > > note 2: Lumas needs a minimum of 1 white space char to separate > values. > > note 3: The Lumas binary encoding encodes a bool into 2 bytes using > a special length code. > > Of course the overall message saving depends on how often each of > these types comes up. > > To me the analysis shows that a binary encoding is typically very > much shorter than a typical XML encoding (with long tag names etc.). > > BUT: Most of this gain is realised by using a Megaco like text > encoding. (This is captured by the XML long/Lumas short ratio.) As > this is what Lumas offers, rather than inventing yet another > message encoding method, I would say that the debate should be > between an XML encoding and a Lumas text encoding rather than > between an XML encoding and a binary encoding! > > Pete. > -- > ============================================= > Pete Cordell > Tech-Know-Ware Ltd > for XML to C++ data binding visit > http://www.tech-know-ware.com/lmx > (or http://www.xml2cpp.com) > ============================================= > > ----- Original Message ----- From: "Henning Schulzrinne" > > To: "XCON-IETF" > Sent: Friday, March 17, 2006 4:19 AM > Subject: [XCON] On encodings > > >> Since we're on the perennially fun topic of protocol encodings, >> maybe we can get past the stereotypes and try to do an >> engineering comparison, or at least an attempt at an >> approximation. Roughly speaking, an XML element is equivalent in >> functionality to a TLV object: it contains a label (element tag >> and the 'type' field), length or delimiter fields to figure out >> the boundaries, and the actual data (value). ASN.1 BER is close >> enough to TLV for this apples- to-pears comparison. >> >> For TLV, you have a type value of 16 to 32 bits, depending on the >> predictions on the need to extend the protocol. For XML, you have >> , thus, 4 bytes plus whatever length you make the tag >> from 'X' to >> 'WeLikeToPutTheWholeRFCIntoTheTagSoThatTheImplementerDoesntHaveToRead >> The RFC'. >> >> For length, this is already counted above for XML; for TLV, it >> would presumably be again 16 or 32 bits. >> >> Thus, the basic overhead is fairly similar if you choose small >> element names. Since numeric labels aren't self-describing at >> all, this only seems like a fair comparison. >> >> The big difference is in the datatypes. Clearly, if you have long >> binary opaque data, base64 encoding typical for XML costs you >> about 30%. >> >> Integers and floats are trickier: Unless you believe in ASN.1- >> style variable-length encoding, it is quite possible that in many >> practical cases, XML integers will be shorter since TLV always has >> to allocate the maximum range, presumably 32 bits for integers >> and 32 (single precision) or 64 bits for floats. You can build >> custom fixed-point types in binary encodings, but they are a pain >> to get right (All kinds of funny things happen because of signed >> vs. unsigned issues, for example. Java programmers will hate you >> if you try this...) >> >> Strings are obviously the same size in either TLV or XML, except >> for the use of delimiters (such as ") or length fields, but >> that's a wash at roughly 2 bytes each. >> >> The one big difference for XML is the namespace declaration. The >> impact of that depends on the number of namespaces and the size >> of the overall document. This is also hard to compare since they >> give you proprietary extensions without the kludges like vendor >> IDs that binary protocols have to go through (unless they choose >> similar Java- style or domain-style tags). Indeed, for namespace- >> style extensions that aren't IANA registered, TLV is usually a >> pain. You end up with either per-TLV long labels or re-invent the >> XML-style indirection approach. >> >> This is a rough comparison, but it indicates that for the same >> functionality, the cost isn't all that different. I'm guessing >> that for protocols that have a common application mix of text and >> mostly- integer numeric values, that we're talking about 10 to 30%. >> >> You do pay a price for very long tags, but only if you can't use >> gzip- style compression, which essentially does the text-to-code >> translation automatically and without penalty. >> >> I'm not comparing other textual, non-XML approaches here. Frankly, >> I don't think they have a chance in the market place and the size >> difference for the ones I have seen isn't all that large. >> >> A separate issue is the functionality. This is left as an >> exercise for another post. >> >> Henning >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon >> _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 10:54:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHI2-0008CH-RY; Fri, 17 Mar 2006 10:54:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHI1-0008C8-Pw for xcon@ietf.org; Fri, 17 Mar 2006 10:54:57 -0500 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 1FKHI1-0003G1-OY for xcon@ietf.org; Fri, 17 Mar 2006 10:54:57 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FKHGB-0000En-JF for xcon@ietf.org; Fri, 17 Mar 2006 10:53:05 -0500 Received: from [192.168.0.102] (ppp-70-249-144-46.dsl.rcsntx.swbell.net [70.249.144.46]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2HFqwOv079411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Mar 2006 09:52:59 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441ADB54.7000500@nostrum.com> Date: Fri, 17 Mar 2006 09:52:52 -0600 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: Henning Schulzrinne Subject: Re: [XCON] On encodings - observations References: <00e101c649c4$25dee4a0$0600a8c0@RW> <00AE848E-2C82-433B-81D7-EFFB4A914558@cs.columbia.edu> In-Reply-To: <00AE848E-2C82-433B-81D7-EFFB4A914558@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.144.46 is authenticated by a trusted mechanism) X-Spam-Score: -2.0 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Pete Cordell , XCON-IETF 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 Henning Schulzrinne wrote: > Sure. Let's design systems that work on vacuum-tube computers. This > is getting silly - the rest of the world does just fine with TLS and > three-tier web service architectures, and we worry about gzip > overhead on a server that handles echo cancellation and video > transcoding. Mobile phones. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 11:35:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHvA-0004kJ-P0; Fri, 17 Mar 2006 11:35:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHv9-0004k9-SF for xcon@ietf.org; Fri, 17 Mar 2006 11:35:23 -0500 Received: from smtp2.wanadoo.co.uk ([193.252.22.157] helo=smtp2.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKHv8-0004tX-FG for xcon@ietf.org; Fri, 17 Mar 2006 11:35:23 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3106.me.freeserve.com (SMTP Server) with ESMTP id 0FDF61C0008D; Fri, 17 Mar 2006 17:35:22 +0100 (CET) Received: from RW (user-4144.l6.c2.dsl.pol.co.uk [84.66.112.48]) by mwinf3106.me.freeserve.com (SMTP Server) with SMTP id C0CB21C00089; Fri, 17 Mar 2006 17:35:21 +0100 (CET) X-ME-UUID: 20060317163521789.C0CB21C00089@mwinf3106.me.freeserve.com Message-ID: <001101c649e0$c9a3b950$0600a8c0@RW> From: "Pete Cordell" To: "Henning Schulzrinne" References: <00e101c649c4$25dee4a0$0600a8c0@RW> <00AE848E-2C82-433B-81D7-EFFB4A914558@cs.columbia.edu> Subject: Re: [XCON] On encodings - observations Date: Fri, 17 Mar 2006 16:35:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: XCON-IETF 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: "Henning Schulzrinne" >>> You do pay a price for very long tags, but only if you can't use gzip- >>> style compression, which essentially does the text-to-code translation >>> automatically and without penalty. >> >> gzip isn't free. It costs on small devices and servers handling a lots >> of connections. Hence I don't think you can say it is without penalty. > > Sure. Let's design systems that work on vacuum-tube computers. This is > getting silly - the rest of the world does just fine with TLS and > three-tier web service architectures, The majority is without TLS so this is bogus. > and we worry about gzip overhead on a server that handles echo > cancellation and video transcoding. Not necessarily on the same hardware. > Maybe there is a corollary here to nethead vs. bellhead: namely those who > have last programmed on a large scale around 1980 vs. the rest of the > world that actually worries about programmer productivity and fitting > into the computing infrastructure of the 21st century. Are you talking about yourself here? Someone proposing XML + SOAP + TLS + gzip + whatever else they can wrap things into doesn't sound like someone who is worried by programmer productivity to me. Sounds like design with PowerPoint to me! Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 11:35:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHvA-0004kc-Vc; Fri, 17 Mar 2006 11:35:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHv9-0004kE-To for xcon@ietf.org; Fri, 17 Mar 2006 11:35:23 -0500 Received: from smtp2.wanadoo.co.uk ([193.252.22.157] helo=smtp2.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKHv8-0004tW-FG for xcon@ietf.org; Fri, 17 Mar 2006 11:35:23 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3106.me.freeserve.com (SMTP Server) with ESMTP id A55241C0008C; Fri, 17 Mar 2006 17:35:21 +0100 (CET) Received: from RW (user-4144.l6.c2.dsl.pol.co.uk [84.66.112.48]) by mwinf3106.me.freeserve.com (SMTP Server) with SMTP id 5B7EA1C00089; Fri, 17 Mar 2006 17:35:21 +0100 (CET) X-ME-UUID: 20060317163521374.5B7EA1C00089@mwinf3106.me.freeserve.com Message-ID: <001001c649e0$c963a310$0600a8c0@RW> From: "Pete Cordell" To: "Henning Schulzrinne" References: <00e201c649c4$262cb680$0600a8c0@RW> <418386E8-A755-47D2-87DC-C0324B7854C8@cs.columbia.edu> Subject: Re: [XCON] On encodings Date: Fri, 17 Mar 2006 16:32:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: XCON-IETF 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: "Henning Schulzrinne" > Thanks for the summary. I'll just add that having the IETF, in a small > niche of its portfolio, go out and invent a new text encoding that nobody > else uses and is likely to use (sorry...) seems just plain hubris. We're > no longer in the world of one-off systems where we build every system > from scratch as if the only tool in our tool kit was a C compiler (I > suspect some people here would actually prefer assembler...). > > Every new encoding means new libraries, means new possibilities for > buffer overflows, new porting for every language from C to C# to PHP to > Java to Perl to Ruby, new training, new debugging tools and new > interoperability testing. I can choose among dozens of XML and SOAP > libraries, maintained by the largest IT corporations on the planet if > that's my choice, and a corresponding number of tools, from open source > to XMLspy and kin. Why in the world would a sane developer create their > own new niche encoding when the rest of their system is going to be built > using modern software tools and will already have to support XML anyway? > > I'm afraid I'm not going to be spending time on Lumas analysis, I'm sorry > to say. The IETF is a tiny part of the software universe and needs to > learn to play nice with the 99.9% of the developers that don't show up at > IETF meetings. But people still seem to be happy to invent new binary encodings such as BFCP, AVPs, and new ABNF grammars such as MRCP that have all the problems that you mention above. Why is that? People are even pushing JSON, when they have access to all the XML tools that you mention (http://en.wikipedia.org/wiki/JSON). This is used extensively by the likes of Google and Yahoo even though they have all the resources to run XML services. Like you, I would like the encoding debate to go away as well. Your approach is to pretend that there's no problem. My approach is to design a system that has the high-level design benefits of XSD, the debuggability of a text protocol, and the compactness of a binary protocol. With Lumas there would be nothing to debate, and we could get on with more interesting things. It seems I also have more faith in the development capabilities of developers. If Microsoft (and Borland) can knock out C# then they're not going to be bothered by Lumas. Heck they can get the C and Perl versions from my web site now. Don't get me wrong. XML is great. But it is not the be all and end all. In programming I use C++ for some things, Perl for other things, PHP/SQL for yet more things, C# for other other things. It depends on the problem I'm tackling. Why shouldn't I have the same choices for message definition? Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= . _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 11:51:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIAK-0000uf-TD; Fri, 17 Mar 2006 11:51:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIAJ-0000uU-82 for xcon@ietf.org; Fri, 17 Mar 2006 11:51:03 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKIAH-0005Df-OY for xcon@ietf.org; Fri, 17 Mar 2006 11:51:03 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 17 Mar 2006 08:51:00 -0800 Received: from tuk-hub-01.redmond.corp.microsoft.com ([157.54.70.27]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 08:50:28 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 08:50:28 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 08:50:27 -0800 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] On encodings Date: Fri, 17 Mar 2006 08:50:26 -0800 Message-ID: In-Reply-To: <001001c649e0$c963a310$0600a8c0@RW> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] On encodings thread-index: AcZJ4O43PpBItYcFSAK55t/xtiQX2QAAZWkg From: "Sean Olson" To: "Pete Cordell" , "Henning Schulzrinne" X-OriginalArrivalTime: 17 Mar 2006 16:50:27.0838 (UTC) FILETIME=[E4E669E0:01C649E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: XCON-IETF 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 To be fair, JSON is pushed because of its ubiquitous support in Javascript-enabled browsers. LUMAS doesn't have the same appeal because it would be yet another new encoding. XML is not perfect and not something I would try to use to solve all problems. Yet, it's use in the conferencing event package, presence, and other SIP/SIMPLE/SIPPING protocols makes it an attractive candidate for re-use.=20 -----Original Message----- From: Pete Cordell [mailto:pete@tech-know-ware.com]=20 Sent: Friday, March 17, 2006 8:32 AM To: Henning Schulzrinne Cc: XCON-IETF Subject: Re: [XCON] On encodings ----- Original Message From: "Henning Schulzrinne" > Thanks for the summary. I'll just add that having the IETF, in a =20 > small niche of its portfolio, go out and invent a new text encoding =20 > that nobody else uses and is likely to use (sorry...) seems just =20 > plain hubris. We're no longer in the world of one-off systems where =20 > we build every system from scratch as if the only tool in our tool =20 > kit was a C compiler (I suspect some people here would actually prefer assembler...). > > Every new encoding means new libraries, means new possibilities for=20 > buffer overflows, new porting for every language from C to C# to PHP =20 > to Java to Perl to Ruby, new training, new debugging tools and new=20 > interoperability testing. I can choose among dozens of XML and SOAP=20 > libraries, maintained by the largest IT corporations on the planet if=20 > that's my choice, and a corresponding number of tools, from open =20 > source to XMLspy and kin. Why in the world would a sane developer =20 > create their own new niche encoding when the rest of their system is =20 > going to be built using modern software tools and will already have to support XML anyway? > > I'm afraid I'm not going to be spending time on Lumas analysis, I'm =20 > sorry to say. The IETF is a tiny part of the software universe and =20 > needs to learn to play nice with the 99.9% of the developers that =20 > don't show up at IETF meetings. But people still seem to be happy to invent new binary encodings such as BFCP, AVPs, and new ABNF grammars such as MRCP that have all the problems that you mention above. Why is that? People are even pushing JSON, when they have access to all the XML tools that you mention (http://en.wikipedia.org/wiki/JSON). This is used extensively by the likes of Google and Yahoo even though they have all the resources to run XML services. Like you, I would like the encoding debate to go away as well. Your approach is to pretend that there's no problem. My approach is to design a system that has the high-level design benefits of XSD, the debuggability of a text protocol, and the compactness of a binary protocol. With Lumas there would be nothing to debate, and we could get on with more interesting things. It seems I also have more faith in the development capabilities of developers. If Microsoft (and Borland) can knock out C# then they're not going to be bothered by Lumas. Heck they can get the C and Perl versions from my web site now. Don't get me wrong. XML is great. But it is not the be all and end all.=20 In programming I use C++ for some things, Perl for other things, PHP/SQL for yet more things, C# for other other things. It depends on the problem I'm tackling. Why shouldn't I have the same choices for message definition? Pete. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D .=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 12:07:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIQ8-0005Ni-Ih; Fri, 17 Mar 2006 12:07:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIQ6-0005M2-TP for xcon@ietf.org; Fri, 17 Mar 2006 12:07:22 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKIQ5-0005zQ-My for xcon@ietf.org; Fri, 17 Mar 2006 12:07:22 -0500 Received: from lion.cs.columbia.edu (IDENT:Sj9lEq5WWwBZEJqpJdtA4BVWiVEgxvbS@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2HH7LOa023093 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 17 Mar 2006 12:07:21 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k2HH7KjN028472 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Mar 2006 12:07:20 -0500 Message-ID: <441AECC3.6060508@cs.columbia.edu> Date: Fri, 17 Mar 2006 12:07:15 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Adam Roach Subject: Re: [XCON] On encodings - observations References: <00e101c649c4$25dee4a0$0600a8c0@RW> <00AE848E-2C82-433B-81D7-EFFB4A914558@cs.columbia.edu> <441ADB54.7000500@nostrum.com> In-Reply-To: <441ADB54.7000500@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Pete Cordell , XCON-IETF 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 Right. Mobile phones have processors running at several hundred MHz, i.e., roughly equivalent to desktop processors in the late 90s. I don't think they'll break a sweat encoding 200 bytes in gzip. Adam Roach wrote: > Henning Schulzrinne wrote: > >> Sure. Let's design systems that work on vacuum-tube computers. This >> is getting silly - the rest of the world does just fine with TLS and >> three-tier web service architectures, and we worry about gzip >> overhead on a server that handles echo cancellation and video >> transcoding. > > > Mobile phones. > > /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 12:34:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIq2-0000M2-3s; Fri, 17 Mar 2006 12:34:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIq1-0000Lx-2e for xcon@ietf.org; Fri, 17 Mar 2006 12:34:09 -0500 Received: from smtp2.wanadoo.co.uk ([193.252.22.157] helo=smtp2.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKIpz-0006tw-Ph for xcon@ietf.org; Fri, 17 Mar 2006 12:34:09 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3103.me.freeserve.com (SMTP Server) with ESMTP id C9ECA1C0008A; Fri, 17 Mar 2006 18:34:06 +0100 (CET) Received: from RW (user-4144.l6.c2.dsl.pol.co.uk [84.66.112.48]) by mwinf3103.me.freeserve.com (SMTP Server) with SMTP id 890EC1C0008C; Fri, 17 Mar 2006 18:34:06 +0100 (CET) X-ME-UUID: 20060317173406561.890EC1C0008C@mwinf3103.me.freeserve.com Message-ID: <004501c649e8$fe7b4690$0600a8c0@RW> From: "Pete Cordell" To: "Sean Olson" References: Subject: Re: [XCON] On encodings Date: Fri, 17 Mar 2006 17:34:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: XCON-IETF 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: "Sean Olson" > To be fair, JSON is pushed because of its ubiquitous support in > Javascript-enabled browsers. LUMAS doesn't have the same appeal because > it would be yet another new encoding. XML is not perfect and not > something I would try to use to solve all problems. Yet, it's use in the > conferencing event package, presence, and other SIP/SIMPLE/SIPPING > protocols makes it an attractive candidate for re-use. My position is that if message size is not a problem, then you might as well use XML, for all the reasons that Henning mentions. However, I'm hearing that there are worries about message size etc., and if that is the case, let's not invent another application specific message encoding, but adopt a more general one that enhances the programmers tool chest and can be used in other applications. I mentioned JSON as an example of a precedent where a community well versed in XML has considered adopting an alternative approach in some cases. Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 13:23:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJbT-0005ok-TY; Fri, 17 Mar 2006 13:23:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJbS-0005oO-9Q for xcon@ietf.org; Fri, 17 Mar 2006 13:23:10 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKJbQ-0000Nq-TU for xcon@ietf.org; Fri, 17 Mar 2006 13:23:10 -0500 Received: from mail1.microsoft.com ([157.54.63.55]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 17 Mar 2006 10:23:08 -0800 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 10:22:58 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 10:22:58 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 10:22:58 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 10:22:57 -0800 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] On encodings Date: Fri, 17 Mar 2006 10:22:55 -0800 Message-ID: In-Reply-To: <004501c649e8$fe7b4690$0600a8c0@RW> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] On encodings thread-index: AcZJ6QQk3RNe/h76R0Kzd5Xm/UjDaAABpn+A From: "Sean Olson" To: "Pete Cordell" X-OriginalArrivalTime: 17 Mar 2006 18:22:57.0392 (UTC) FILETIME=[D0B12700:01C649EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org The reason JSON was chosen was to re-use an existing toolset inside common browsers (Javascript). You'll notice that a brand new binary encoding was not chosen in this context (I'm not saying this is a perfect analogy for XCON)=20 -----Original Message----- From: Pete Cordell [mailto:pete@tech-know-ware.com]=20 Sent: Friday, March 17, 2006 9:34 AM To: Sean Olson Cc: XCON-IETF Subject: Re: [XCON] On encodings ----- Original Message From: "Sean Olson" > To be fair, JSON is pushed because of its ubiquitous support in=20 > Javascript-enabled browsers. LUMAS doesn't have the same appeal=20 > because it would be yet another new encoding. XML is not perfect and=20 > not something I would try to use to solve all problems. Yet, it's use=20 > in the conferencing event package, presence, and other=20 > SIP/SIMPLE/SIPPING protocols makes it an attractive candidate for re-use. My position is that if message size is not a problem, then you might as well use XML, for all the reasons that Henning mentions. However, I'm hearing that there are worries about message size etc., and if that is the case, let's not invent another application specific message encoding, but adopt a more general one that enhances the programmers tool chest and can be used in other applications. I mentioned JSON as an example of a precedent where a community well versed in XML has considered adopting an alternative approach in some cases. Pete. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 13:23:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJcD-0005yD-5q; Fri, 17 Mar 2006 13:23:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJcC-0005y3-I6 for xcon@ietf.org; Fri, 17 Mar 2006 13:23:56 -0500 Received: from smtp2.wanadoo.co.uk ([193.252.22.157] helo=smtp2.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKJcC-0000Pb-5e for xcon@ietf.org; Fri, 17 Mar 2006 13:23:56 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3116.me.freeserve.com (SMTP Server) with ESMTP id 7D39F3400091; Fri, 17 Mar 2006 19:23:55 +0100 (CET) Received: from RW (user-4144.l6.c2.dsl.pol.co.uk [84.66.112.48]) by mwinf3116.me.freeserve.com (SMTP Server) with SMTP id 34B433400085; Fri, 17 Mar 2006 19:23:55 +0100 (CET) X-ME-UUID: 20060317182355215.34B433400085@mwinf3116.me.freeserve.com Message-ID: <006601c649ef$f3d323f0$0600a8c0@RW> From: "Pete Cordell" To: "Henning Schulzrinne" , "Adam Roach" References: <00e101c649c4$25dee4a0$0600a8c0@RW> <00AE848E-2C82-433B-81D7-EFFB4A914558@cs.columbia.edu> <441ADB54.7000500@nostrum.com> <441AECC3.6060508@cs.columbia.edu> Subject: Re: [XCON] On encodings - observations Date: Fri, 17 Mar 2006 18:23:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: XCON-IETF 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 for one need more numbers to be able to make a judgement on this. Does anybody have an idea of: - how many messages are likely to be sent to/from a client in an active conference? (is it messages per second, or seconds per message?) - does the messaging load for the client increase with conference size, or does it stay flat? - How many clients is a server expected to interface to at one time? Thanks, Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= ----- Original Message ----- From: "Henning Schulzrinne" To: "Adam Roach" Cc: "Pete Cordell" ; "XCON-IETF" Sent: Friday, March 17, 2006 5:07 PM Subject: Re: [XCON] On encodings - observations > Right. Mobile phones have processors running at several hundred MHz, i.e., > roughly equivalent to desktop processors in the late 90s. I don't think > they'll break a sweat encoding 200 bytes in gzip. > > Adam Roach wrote: >> Henning Schulzrinne wrote: >> >>> Sure. Let's design systems that work on vacuum-tube computers. This is >>> getting silly - the rest of the world does just fine with TLS and >>> three-tier web service architectures, and we worry about gzip overhead >>> on a server that handles echo cancellation and video transcoding. >> >> >> Mobile phones. >> >> /a > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 13:33:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJlh-0001Np-MX; Fri, 17 Mar 2006 13:33:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJlg-000172-4c for xcon@ietf.org; Fri, 17 Mar 2006 13:33:44 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKJle-0000Zp-ST for xcon@ietf.org; Fri, 17 Mar 2006 13:33:44 -0500 Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2HIXfNb088118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Mar 2006 12:33:41 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441B0176.8050200@nostrum.com> Date: Fri, 17 Mar 2006 12:35:34 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell Subject: Re: [XCON] On encodings References: <004501c649e8$fe7b4690$0600a8c0@RW> In-Reply-To: <004501c649e8$fe7b4690$0600a8c0@RW> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 08170828343bcf1325e4a0fb4584481c Cc: XCON-IETF 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 [not as chair] Pete Cordell wrote: > My position is that if message size is not a problem, then you might > as well use XML, for all the reasons that Henning mentions. However, > I'm hearing that there are worries about message size etc., and if > that is the case, let's not invent another application specific > message encoding... CSCP encoding is BFCP, which is both likely to be implemented in conferencing systems and in the RFC editor's queue. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 13:53:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKK4W-0005Or-Ue; Fri, 17 Mar 2006 13:53:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKK4V-0005Ok-O5 for xcon@ietf.org; Fri, 17 Mar 2006 13:53:11 -0500 Received: from smtp2.wanadoo.co.uk ([193.252.22.157] helo=smtp2.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKK4U-000178-FB for xcon@ietf.org; Fri, 17 Mar 2006 13:53:11 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3107.me.freeserve.com (SMTP Server) with ESMTP id B9EAC4800096; Fri, 17 Mar 2006 19:53:09 +0100 (CET) Received: from RW (user-4144.l6.c2.dsl.pol.co.uk [84.66.112.48]) by mwinf3107.me.freeserve.com (SMTP Server) with SMTP id 7B2C64800094; Fri, 17 Mar 2006 19:53:09 +0100 (CET) X-ME-UUID: 20060317185309504.7B2C64800094@mwinf3107.me.freeserve.com Message-ID: <007301c649f4$09661250$0600a8c0@RW> From: "Pete Cordell" To: "Sean Olson" References: Subject: Re: [XCON] On encodings Date: Fri, 17 Mar 2006 18:53:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org > The reason JSON was chosen was to re-use an existing toolset inside > common browsers (Javascript). You'll notice that a brand new binary > encoding was not chosen in this context (I'm not saying this is a > perfect analogy for XCON) And I'm not pushing binary either. Quite the opposite. Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 17 14:12:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKNM-0006Gi-7A; Fri, 17 Mar 2006 14:12:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKNL-0006Gd-RU for xcon@ietf.org; Fri, 17 Mar 2006 14:12:39 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKKNJ-000220-IX for xcon@ietf.org; Fri, 17 Mar 2006 14:12:39 -0500 Received: from [172.17.2.251] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2HJCaWd090299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Mar 2006 13:12:37 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441B0A95.3050108@nostrum.com> Date: Fri, 17 Mar 2006 13:14:29 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: XCON-IETF Subject: Re: [XCON] On encodings - observations References: <00e101c649c4$25dee4a0$0600a8c0@RW> <00AE848E-2C82-433B-81D7-EFFB4A914558@cs.columbia.edu> <441ADB54.7000500@nostrum.com> <441AECC3.6060508@cs.columbia.edu> In-Reply-To: <441AECC3.6060508@cs.columbia.edu> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 [not as chair] Henning Schulzrinne wrote: > Right. Mobile phones have processors running at several hundred MHz, > i.e., roughly equivalent to desktop processors in the late 90s. I > don't think they'll break a sweat encoding 200 bytes in gzip. Your assertion is not completely well founded: many of the phones sold today are running in the tens of MHz, not hundreds. Even for smart phones, it's not unusual to get ahold of terminals based on 33 MHz DragonBall VZ processors. (If you like, I'll ask a few questions during the XCON meeting next week and probably find a dozen or so people in the meeting actually in possession of one). I have run tests on these specific processors using Deflate and 1000-byte messages. The resultant compression time is on the order of 300 - 500 ms. For smaller messages -- say, 200 to 300 bytes or so -- you're looking at about 100 ms to compress such messages. For messages in that size range, you'd be hard pressed to make up 100ms of latency by sending fewer bits. When I did my analysis of this topic, my conclusions were: on processors at this speed, and using the network data speeds we discussed before, using Deflate compression is pretty much a wash (in terms of latency) for messages of any size. The amount of time spent compressing a message was always nearly equal the amount of time you saved in transmission. There are some much lighter-weight, *patented* compression algorithms (e.g. v.44) that are orders of magnitude faster, but I'm not certain we want to mandate a patented compression algorithm for all users of the conference control protocol. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Mar 20 17:25:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSp0-0002c1-H8; Mon, 20 Mar 2006 17:25:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSoz-0002bw-3S for xcon@ietf.org; Mon, 20 Mar 2006 17:25:53 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLSox-0006rI-Fe for xcon@ietf.org; Mon, 20 Mar 2006 17:25:52 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2KMPoKu056021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Mar 2006 16:25:51 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441F2BEE.9080807@nostrum.com> Date: Mon, 20 Mar 2006 16:25:50 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: XCON-IETF X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [XCON] Minute Volunteers? 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 To expedite things (and I think we may need all our time) for the meeting today: who is willing to take minutes for today's meeting? /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 10:33:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLir1-0008UL-Np; Tue, 21 Mar 2006 10:33:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLir0-0008TW-Sv for xcon@ietf.org; Tue, 21 Mar 2006 10:33:02 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLiqz-0004Bb-Ki for xcon@ietf.org; Tue, 21 Mar 2006 10:33:02 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2LFX07V026995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Mar 2006 09:33:01 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <44201CAC.9090908@nostrum.com> Date: Tue, 21 Mar 2006 09:33:00 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: XCON-IETF X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [XCON] Meeting Materials 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] The materials from the XCON meeting have been uploaded to the IETF proceedings page: https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=65 The materials include the slides prepared for BFCP connection establishment, which we didn't discuss during the session. Interested parties are invited to comment on the issues presented in that set of slides. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 14:03:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLm8o-0003HN-3F; Tue, 21 Mar 2006 14:03:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLm8n-0003HI-6n for xcon@ietf.org; Tue, 21 Mar 2006 14:03:37 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLm8j-00049U-US for xcon@ietf.org; Tue, 21 Mar 2006 14:03:37 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2LJ3Vo2039341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Mar 2006 13:03:32 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <44204E01.40009@nostrum.com> Date: Tue, 21 Mar 2006 13:03:29 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcon@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [XCON] Ad-hoc meeting tomorrow 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 Our ad-hoc meeting has been scheduled for tomorrow, Wednesday, March 22nd, from 1510 to 1710. (This overlaps slightly with the plenary). The room that has been reserved for us is Sapphire. I encourage anyone who will be attending to summarize their opinions on the list before the meeting. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 15:04:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLn5b-00045N-8F; Tue, 21 Mar 2006 15:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLn5Z-00045I-QX for xcon@ietf.org; Tue, 21 Mar 2006 15:04:21 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLn5Y-0006bA-Ix for xcon@ietf.org; Tue, 21 Mar 2006 15:04:21 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2LK4JaB042672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Mar 2006 14:04:20 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <44205C3F.1070409@nostrum.com> Date: Tue, 21 Mar 2006 14:04:15 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcon@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [XCON] Data Model Working Group Item Adoption 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 During the XCON face to face meeting on March 20, 2006, the participants present agreed unanimously to adopt draft-novo-xcon-common-data-model-01.txt to satisfy the Data Model milestone delivery for the working group. This message brings the decision to the list for discussion. Any objections to this decision should be raised within the next week. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 15:07:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLn8Q-0005mx-EE; Tue, 21 Mar 2006 15:07:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLn8P-0005l7-5f for xcon@ietf.org; Tue, 21 Mar 2006 15:07:17 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLn8N-0006eW-Sw for xcon@ietf.org; Tue, 21 Mar 2006 15:07:17 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2LK7FSP042943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Mar 2006 14:07:15 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <44205CF1.8040405@nostrum.com> Date: Tue, 21 Mar 2006 14:07:13 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcon@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [XCON] Multiple Protocols: Consensus 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 During the XCON face to face meeting on March 20, 2006, the participants present agreed that the protocol used to manipulate the conference state should have only one binding, and not several. The consensus of the people present was very strong. This message brings the decision to the list for discussion. Any objections to this decision should be raised within the next week. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 15:30:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnUj-0002cS-Nt; Tue, 21 Mar 2006 15:30:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnUh-0002cN-UE for xcon@ietf.org; Tue, 21 Mar 2006 15:30:19 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnUg-0007as-Fa for xcon@ietf.org; Tue, 21 Mar 2006 15:30:19 -0500 Received: from mail3.microsoft.com ([157.54.66.7]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 21 Mar 2006 12:30:17 -0800 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 12:30:17 -0800 Received: from tuk-hub-02.redmond.corp.microsoft.com ([157.54.70.28]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 12:30:17 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 12:30:16 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 12:30:13 -0800 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] Multiple Protocols: Consensus Date: Tue, 21 Mar 2006 12:30:14 -0800 Message-ID: <65F27F597EB1E44384BA802189D334C60A87F1@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <44205CF1.8040405@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Multiple Protocols: Consensus Thread-Index: AcZNIzsCZ87bV22TQnmZrhgLk7QGhwAAu5ZQ From: "Sean Olson" To: "Adam Roach" , X-OriginalArrivalTime: 21 Mar 2006 20:30:13.0148 (UTC) FILETIME=[419C0DC0:01C64D26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 am part of that consensus and just wanted to clarify one thing. You mean 1 protocol and 1 binding, right?=20 -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, March 21, 2006 12:07 PM To: xcon@ietf.org Subject: [XCON] Multiple Protocols: Consensus During the XCON face to face meeting on March 20, 2006, the participants present agreed that the protocol used to manipulate the conference state should have only one binding, and not several. The consensus of the people present was very strong. This message brings the decision to the list for discussion. Any objections to this decision should be raised within the next week. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 15:33:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnXu-0004MR-KR; Tue, 21 Mar 2006 15:33:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnXt-0004MM-1X for xcon@ietf.org; Tue, 21 Mar 2006 15:33:37 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnXr-0007hD-Om for xcon@ietf.org; Tue, 21 Mar 2006 15:33:37 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2LKXVq9044453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 14:33:32 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4420631A.6090307@nostrum.com> Date: Tue, 21 Mar 2006 14:33:30 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson Subject: Re: [XCON] Multiple Protocols: Consensus References: <65F27F597EB1E44384BA802189D334C60A87F1@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <65F27F597EB1E44384BA802189D334C60A87F1@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 That is my interpretation of the discussion we had and the question we asked. Thank you for putting it more clearly than I did. /a Sean Olson wrote: >I am part of that consensus and just wanted to clarify one thing. You >mean 1 protocol and 1 binding, right? > >-----Original Message----- >From: Adam Roach [mailto:adam@nostrum.com] >Sent: Tuesday, March 21, 2006 12:07 PM >To: xcon@ietf.org >Subject: [XCON] Multiple Protocols: Consensus > >During the XCON face to face meeting on March 20, 2006, the participants >present agreed that the protocol used to manipulate the conference state >should have only one binding, and not several. The consensus of the >people present was very strong. > >This message brings the decision to the list for discussion. Any >objections to this decision should be raised within the next week. > >/a > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 17:35:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpSF-0008MP-4j; Tue, 21 Mar 2006 17:35:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpSD-0008MH-6Z for xcon@ietf.org; Tue, 21 Mar 2006 17:35:53 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpSC-0007gW-0M for xcon@ietf.org; Tue, 21 Mar 2006 17:35:53 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FLpS2-0003mO-SX for xcon@ietf.org; Tue, 21 Mar 2006 16:35:43 -0600 From: "Brian Rosen" To: Date: Tue, 21 Mar 2006 17:35:50 -0500 Message-ID: <016301c64d37$cfeb9260$73818182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZNN6jn0vEpPIr3TmqG6N3zitDVVQAABdiQ X-PopBeforeSMTPSenders: br@brianrosen.net 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 - [0 0] / [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: 8abaac9e10c826e8252866cbe6766464 Subject: [XCON] Verbs and Nouns X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I think the purpose of the BoF is to decide on the verbs and nouns. My = list is: Verb Create/Delete Item Nouns Conference Sidebar ?Floor? Set/Get Value=20 Nouns ConfState MediaPolicy SecurityPolicy ?Floor Control Policy? Controls =09 Add/Delete member of list Nouns Dial Out Refer Allowed Participants Allowed Floor Holders Allowed Floor Moderators Sidebar It=E2=80=99s a start =E2=98=BA: =20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 17:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLphz-00087G-Sx; Tue, 21 Mar 2006 17:52:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLphy-00086x-8s for xcon@ietf.org; Tue, 21 Mar 2006 17:52:10 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLphx-00084N-0H for xcon@ietf.org; Tue, 21 Mar 2006 17:52:10 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2LMq88n052635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Mar 2006 16:52:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <44208396.3010802@nostrum.com> Date: Tue, 21 Mar 2006 16:52:06 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcon@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [XCON] Talking Points 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] To prompt discussion, some of the points that were raised last night include: * Semantic versus syntactic operations. This ties into: * Do new templates include new operations that are added to the conference control protocol? Also, one proposal about the topics to discuss tomorrow include the specific operations that the conference control protocol should include. A union of the operations in the current drafts yields the following list: * Create Conference based on specified blueprint * Create Conference based on implied blueprint * Modify/Delete/Get Conference * Add/Modify/Delete/Get User * Modify User Roles * Add/Modify/Delete/Get Endpoint * Add/Modify/Delete/Get Endpoint Media * Add/Modify/Delete/Get Media Groups * Add/Modify/Delete Sidebar * Add/Modify/Delete/Get Role * Add User To Sidebar * Delete User From Sidebar * Move User Between Sidebars * Add/Modify/Delete/Get XML element * Set/Get/Delete XML attribute * Get Templates * Get Blueprints * Get Active Conferences * Cancel * Ping * Options Looking at the proposed common conference schema, we should be thinking about modifying the conference description, the host information, the conference state, the security mechanism, the users, the sidebars, and the template. Although it isn't yet completed, I think we have enough information in the schema to have an intelligent conversation around how these operations can be applied to the fixed conference portion. That does, of course, leave the issue of what we need to do in order to change the template part. I don't have anything constructive to say on this topic, and trust that others here can attempt to fill in the gaps. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 18:13:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLq2W-0005R0-Tn; Tue, 21 Mar 2006 18:13:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLq2V-0005QP-8N for xcon@ietf.org; Tue, 21 Mar 2006 18:13:23 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLq2U-0000H5-0y for xcon@ietf.org; Tue, 21 Mar 2006 18:13:23 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FLq2L-0007QX-7F; Tue, 21 Mar 2006 17:13:13 -0600 From: "Brian Rosen" To: "'Adam Roach'" , Subject: RE: [XCON] Talking Points Date: Tue, 21 Mar 2006 18:13:24 -0500 Message-ID: <017901c64d3d$1050ea80$73818182@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.2670 Thread-Index: AcZNOhRCSr2ATwqRQGWRPOnb1cDCnAAANDbQ In-Reply-To: <44208396.3010802@nostrum.com> X-PopBeforeSMTPSenders: br@brianrosen.net 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 - [0 0] / [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: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Using my verb/noun list: * Create Conference based on specified blueprint Create(Conference) * Create Conference based on implied blueprint Create(Conference) * Modify/Delete/Get Conference Delete(Conference). Maybe I need a get/modify but I don't think so * Add/Modify/Delete/Get User AddListItem(Participant), DeleteListItem(Participant). May need a modify, but I don't think so * Modify User Roles Is this AddListItem(AllowedRoles)? I'd need a new noun for List * Add/Modify/Delete/Get Endpoint I'm not sure exactly what this is, but may need another noun for endpoint * Add/Modify/Delete/Get Endpoint Media I'm pretty sure this is not xcon state * Add/Modify/Delete/Get Media Groups I'm pretty sure this is not xcon state * Add/Modify/Delete Sidebar Create(Sidebar), Delete(Sidebar) not sure you need a modify Generally I think you have a very simplistic create, and then use set/get to change values in the object the create made for you * Add/Modify/Delete/Get Role Need a noun, maybe Set(Role), but is this actually conference state? * Add User To Sidebar AddListItem(Sidebar) * Delete User From Sidebar DeleteListItem(Sidebar) * Move User Between Sidebars Delete then add. Doesn't have to be a transaction I think * Add/Modify/Delete/Get XML element Set/Get(one of my list of nouns) * Set/Get/Delete XML attribute Dunno what you mean * Get Templates Aha, need a noun for set/get "focus" * Get Blueprints Get(focus) * Get Active Conferences Get(focus) * Cancel Cancel what? * Ping Ping on the conf control channel? Some no-op * Options Dunno what you mean _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 18:23:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqCM-0006bn-IM; Tue, 21 Mar 2006 18:23:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqCK-0006bi-Ip for xcon@ietf.org; Tue, 21 Mar 2006 18:23:32 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLqCJ-0000dL-AY for xcon@ietf.org; Tue, 21 Mar 2006 18:23:32 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2LNNU5L054312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 17:23:30 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <44208AF0.4090108@nostrum.com> Date: Tue, 21 Mar 2006 17:23:28 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [XCON] Talking Points References: <017901c64d3d$1050ea80$73818182@cis.neustar.com> In-Reply-To: <017901c64d3d$1050ea80$73818182@cis.neustar.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 As clarification, what I posted was a straight union of the operations from all four proposals, not what I thought was a good set of operations. This isn't likely to make sense without some paring. However, at least *some* one thought that each of the operations was a good idea. Brian Rosen wrote: > * Add/Modify/Delete/Get XML element >Set/Get(one of my list of nouns) > * Set/Get/Delete XML attribute >Dunno what you mean > > Consider the construct: In XML, "foo" is the element, and "bar" is an attribute of that element. See the CSCP draft for more information. > * Cancel >Cancel what? > > See the CCCP draft for more information. > * Ping >Ping on the conf control channel? Some no-op > > See the CCCP draft for more information. > * Options >Dunno what you mean > > See the COMP draft for more information. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 18:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqLt-0002UR-VX; Tue, 21 Mar 2006 18:33:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqLs-0002Ql-6g for xcon@ietf.org; Tue, 21 Mar 2006 18:33:24 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLqLq-00013l-IL for xcon@ietf.org; Tue, 21 Mar 2006 18:33:24 -0500 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 21 Mar 2006 15:33:21 -0800 Received: from tuk-hub-01.redmond.corp.microsoft.com ([157.54.70.27]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 15:33:12 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 15:33:11 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 15:33:08 -0800 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] Talking Points Date: Tue, 21 Mar 2006 15:33:14 -0800 Message-ID: <65F27F597EB1E44384BA802189D334C611EE6D@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <44208AF0.4090108@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Talking Points Thread-Index: AcZNPpwIMcdgYGJNTEC3cBqT/0vmRQAAKKug From: "Sean Olson" To: "Adam Roach" , X-OriginalArrivalTime: 21 Mar 2006 23:33:08.0531 (UTC) FILETIME=[CF729830:01C64D3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 The CCCP ping is a liveness check similar to the ill-fated SIP PING discussions. It specifically checks for application-level liveness of the conference state at the Focus. There are some interesting failover cases that could benefit from this --- there may also be much better or simpler solutions. I'm fine with cutting this from the initial list of operations. The CCCP cancel command is similar to a SIP CANCEL which we thought might be useful to terminate long commands (addUser for example). In retrospect, we might want to cut this operation for now until we have a better handle on the other operations. -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, March 21, 2006 3:23 PM To: br@brianrosen.net Cc: xcon@ietf.org Subject: Re: [XCON] Talking Points As clarification, what I posted was a straight union of the operations from all four proposals, not what I thought was a good set of operations. This isn't likely to make sense without some paring. However, at least *some* one thought that each of the operations was a good idea. Brian Rosen wrote: > * Add/Modify/Delete/Get XML element Set/Get(one of my list of=20 >nouns) > * Set/Get/Delete XML attribute >Dunno what you mean > =20 > Consider the construct: In XML, "foo" is the element, and "bar" is an attribute of that element. See the CSCP draft for more information. > * Cancel >Cancel what? > =20 > See the CCCP draft for more information. > * Ping >Ping on the conf control channel? Some no-op > =20 > See the CCCP draft for more information. > * Options >Dunno what you mean > =20 > See the COMP draft for more information. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 20:42:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsMc-00032p-3m; Tue, 21 Mar 2006 20:42:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsMa-00032k-PF for xcon@ietf.org; Tue, 21 Mar 2006 20:42:16 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLsMZ-0006FV-An for xcon@ietf.org; Tue, 21 Mar 2006 20:42:16 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2M1ekvu031364; Wed, 22 Mar 2006 03:40:49 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 03:41:52 +0200 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 19:41:49 -0600 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] Talking Points Date: Tue, 21 Mar 2006 19:41:48 -0600 Message-ID: <815E2AF6A087FF45A68EF2F310ADE111015C8179@daebe102.NOE.Nokia.com> In-Reply-To: <44208396.3010802@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Talking Points Thread-Index: AcZNOkFBs1XDoUndSKKF5dvgVu4UKgAFaPDA From: To: , X-OriginalArrivalTime: 22 Mar 2006 01:41:49.0342 (UTC) FILETIME=[C968DBE0:01C64D51] X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Adam Roach [mailto:adam@nostrum.com]=20 >Sent: Tuesday, March 21, 2006 4:52 PM >To: xcon@ietf.org >Subject: [XCON] Talking Points > >[as chair] > >To prompt discussion, some of the points that were raised last night >include: > > * Semantic versus syntactic operations. This ties into: > * Do new templates include new operations that are added to the > conference control protocol? > How do you get a new template ? Does defining a new control called "foo" constitutes a new template OR defining new XML elements which provide a different functionality constitues a new template. According the the framework draft, if your server supports a new type of control ( a control according to the template draft is something like mute, pause etc) then you don't need to have a new template and your terminal would try its best to support this control based on the control type and its default values. If you go on this lines then I guess having syntactic operations would make sense so as not to update the protocol (meaning trying to standardize the new functionality in the protocol). Also if you are going to create new templates (by defining new elements in the templates), I guess then we need to standardize this templates and add it to template repositry. In this case too, syntactic protocol would be the best choice.=20 Umesh=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 21 21:37:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLtDq-0002OG-2Y; Tue, 21 Mar 2006 21:37:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLtDo-0002OB-ID for xcon@ietf.org; Tue, 21 Mar 2006 21:37:16 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLtDm-0008Qv-UF for xcon@ietf.org; Tue, 21 Mar 2006 21:37:16 -0500 Received: from rly26b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly26b.srv.mailcontrol.com (MailControl) with ESMTP id k2M2bDMC010351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Mar 2006 02:37:13 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly26b.srv.mailcontrol.com (MailControl) id k2M2bBkw010297 for xcon@ietf.org; Wed, 22 Mar 2006 02:37:11 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly26b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k2M2bAdc010279; Wed, 22 Mar 2006 02:37:11 +0000 (GMT) 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] Talking Points Date: Wed, 22 Mar 2006 02:37:10 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE04E78C87@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Talking Points Thread-Index: AcZNOhRCSr2ATwqRQGWRPOnb1cDCnAAANDbQAAeWc0A= From: "Chris Boulton" To: , "Adam Roach" , X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.66.1.136 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 AddListItem(Participant), DeleteListItem(Participant). May need a modify, but I don't think so Brian - I guess this all depends on how you define a participant. If the participant has tied properties that might change during a conference then a modify might be needed. Chris. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 21 March 2006 23:13 To: 'Adam Roach'; xcon@ietf.org Subject: RE: [XCON] Talking Points Using my verb/noun list: * Create Conference based on specified blueprint Create(Conference) * Create Conference based on implied blueprint Create(Conference) * Modify/Delete/Get Conference Delete(Conference). Maybe I need a get/modify but I don't think so * Add/Modify/Delete/Get User AddListItem(Participant), DeleteListItem(Participant). May need a modify, but I don't think so * Modify User Roles Is this AddListItem(AllowedRoles)? I'd need a new noun for List * Add/Modify/Delete/Get Endpoint I'm not sure exactly what this is, but may need another noun for endpoint * Add/Modify/Delete/Get Endpoint Media I'm pretty sure this is not xcon state * Add/Modify/Delete/Get Media Groups I'm pretty sure this is not xcon state * Add/Modify/Delete Sidebar Create(Sidebar), Delete(Sidebar) not sure you need a modify Generally I think you have a very simplistic create, and then use=20 set/get to change values in the object the create made for you * Add/Modify/Delete/Get Role Need a noun, maybe Set(Role), but is this actually conference state? * Add User To Sidebar AddListItem(Sidebar) * Delete User From Sidebar DeleteListItem(Sidebar) * Move User Between Sidebars Delete then add. Doesn't have to be a transaction I think * Add/Modify/Delete/Get XML element Set/Get(one of my list of nouns) * Set/Get/Delete XML attribute Dunno what you mean * Get Templates Aha, need a noun for set/get "focus" * Get Blueprints Get(focus) * Get Active Conferences Get(focus) * Cancel Cancel what? * Ping Ping on the conf control channel? Some no-op * Options Dunno what you mean _______________________________________________ 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 Tue Mar 21 21:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLtSO-0004wg-7P; Tue, 21 Mar 2006 21:52:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLtSN-0004wb-82 for xcon@ietf.org; Tue, 21 Mar 2006 21:52:19 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLtSL-0000Mp-Q7 for xcon@ietf.org; Tue, 21 Mar 2006 21:52:19 -0500 Received: from rly21b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly21b.srv.mailcontrol.com (MailControl) with ESMTP id k2M2qGQK006763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Mar 2006 02:52:16 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly21b.srv.mailcontrol.com (MailControl) id k2M2pWUM005730 for xcon@ietf.org; Wed, 22 Mar 2006 02:51:32 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly21b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k2M2pVtU005680; Wed, 22 Mar 2006 02:51:32 +0000 (GMT) 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] Multiple Protocols: Consensus Date: Wed, 22 Mar 2006 02:51:31 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE04E78C88@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Multiple Protocols: Consensus Thread-Index: AcZNIzsCZ87bV22TQnmZrhgLk7QGhwAAu5ZQAA1I/rA= From: "Chris Boulton" To: "Sean Olson" , "Adam Roach" , X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.66.1.131 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Being the person who started the 'multiple' thread on the XCON list I must admit that after listening to folks talk in the meeting I agree that a single Protocol/Binding would be appropriate. Chris. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: 21 March 2006 20:30 To: Adam Roach; xcon@ietf.org Subject: RE: [XCON] Multiple Protocols: Consensus I am part of that consensus and just wanted to clarify one thing. You mean 1 protocol and 1 binding, right?=20 -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, March 21, 2006 12:07 PM To: xcon@ietf.org Subject: [XCON] Multiple Protocols: Consensus During the XCON face to face meeting on March 20, 2006, the participants present agreed that the protocol used to manipulate the conference state should have only one binding, and not several. The consensus of the people present was very strong. This message brings the decision to the list for discussion. Any objections to this decision should be raised within the next week. /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 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 Mar 22 01:12:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLwZv-0002hV-OZ; Wed, 22 Mar 2006 01:12:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLwZu-0002hQ-Iq for xcon@ietf.org; Wed, 22 Mar 2006 01:12:18 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLwZs-0007pG-7H for xcon@ietf.org; Wed, 22 Mar 2006 01:12:18 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FLwZh-0006mF-FF; Wed, 22 Mar 2006 00:12:05 -0600 From: "Brian Rosen" To: "'Chris Boulton'" , "'Adam Roach'" , Subject: RE: [XCON] Talking Points Date: Wed, 22 Mar 2006 01:12:05 -0500 Message-ID: <023101c64d77$8d841b50$73818182@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.2670 Thread-Index: AcZNOhRCSr2ATwqRQGWRPOnb1cDCnAAANDbQAAeWc0AAB4TVEA== In-Reply-To: <45730E094814E44488F789C1CDED27AE04E78C87@gbnewp0758m.eu.ubiquity.net> X-PopBeforeSMTPSenders: br@brianrosen.net 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 - [0 0] / [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: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I'm thinking that the operation to add or delete someone to a list is just that. If that someone has some kind of state that can be modified, then the add/delete returns a handle and the set/get is used to change the state. Would that work for you? -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net] Sent: Tuesday, March 21, 2006 9:37 PM To: br@brianrosen.net; Adam Roach; xcon@ietf.org Subject: RE: [XCON] Talking Points AddListItem(Participant), DeleteListItem(Participant). May need a modify, but I don't think so Brian - I guess this all depends on how you define a participant. If the participant has tied properties that might change during a conference then a modify might be needed. Chris. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: 21 March 2006 23:13 To: 'Adam Roach'; xcon@ietf.org Subject: RE: [XCON] Talking Points Using my verb/noun list: * Create Conference based on specified blueprint Create(Conference) * Create Conference based on implied blueprint Create(Conference) * Modify/Delete/Get Conference Delete(Conference). Maybe I need a get/modify but I don't think so * Add/Modify/Delete/Get User AddListItem(Participant), DeleteListItem(Participant). May need a modify, but I don't think so * Modify User Roles Is this AddListItem(AllowedRoles)? I'd need a new noun for List * Add/Modify/Delete/Get Endpoint I'm not sure exactly what this is, but may need another noun for endpoint * Add/Modify/Delete/Get Endpoint Media I'm pretty sure this is not xcon state * Add/Modify/Delete/Get Media Groups I'm pretty sure this is not xcon state * Add/Modify/Delete Sidebar Create(Sidebar), Delete(Sidebar) not sure you need a modify Generally I think you have a very simplistic create, and then use set/get to change values in the object the create made for you * Add/Modify/Delete/Get Role Need a noun, maybe Set(Role), but is this actually conference state? * Add User To Sidebar AddListItem(Sidebar) * Delete User From Sidebar DeleteListItem(Sidebar) * Move User Between Sidebars Delete then add. Doesn't have to be a transaction I think * Add/Modify/Delete/Get XML element Set/Get(one of my list of nouns) * Set/Get/Delete XML attribute Dunno what you mean * Get Templates Aha, need a noun for set/get "focus" * Get Blueprints Get(focus) * Get Active Conferences Get(focus) * Cancel Cancel what? * Ping Ping on the conf control channel? Some no-op * Options Dunno what you mean _______________________________________________ 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 From xcon-bounces@ietf.org Wed Mar 22 08:54:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3n4-0000pf-6J; Wed, 22 Mar 2006 08:54:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3n2-0000pY-Uz for xcon@ietf.org; Wed, 22 Mar 2006 08:54:21 -0500 Received: from [212.179.41.2] (helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3n2-0008Oj-HE for xcon@ietf.org; Wed, 22 Mar 2006 08:54:20 -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] Talking Points Date: Wed, 22 Mar 2006 15:54:17 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C0357221B@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Talking Points Thread-Index: AcZNOhRCSr2ATwqRQGWRPOnb1cDCnAAANDbQAAeWc0AAB4TVEAAQGvww From: "Even, Roni" To: , "Chris Boulton" , "Adam Roach" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 Brian, Hi, The modify conference is needed for modifying parameters before the conference starts. The get may be needed to get the conference information after it is finished for CDR (we need charging) Roni Even > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 8:12 AM > To: 'Chris Boulton'; 'Adam Roach'; xcon@ietf.org > Subject: RE: [XCON] Talking Points >=20 > I'm thinking that the operation to add or delete someone to a list is just > that. If that someone has some kind of state that can be modified, then > the > add/delete returns a handle and the set/get is used to change the state. >=20 > Would that work for you? >=20 > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: Tuesday, March 21, 2006 9:37 PM > To: br@brianrosen.net; Adam Roach; xcon@ietf.org > Subject: RE: [XCON] Talking Points >=20 > AddListItem(Participant), DeleteListItem(Participant). May need a > modify, but I don't think so >=20 > Brian - I guess this all depends on how you define a participant. If > the participant has tied properties that might change during a > conference then a modify might be needed. >=20 > Chris. >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 21 March 2006 23:13 > To: 'Adam Roach'; xcon@ietf.org > Subject: RE: [XCON] Talking Points >=20 > Using my verb/noun list: >=20 > * Create Conference based on specified blueprint > Create(Conference) > * Create Conference based on implied blueprint > Create(Conference) > * Modify/Delete/Get Conference > Delete(Conference). Maybe I need a get/modify but I don't think so > * Add/Modify/Delete/Get User > AddListItem(Participant), DeleteListItem(Participant). May need a > modify, > but I don't think so > * Modify User Roles > Is this AddListItem(AllowedRoles)? I'd need a new noun for List > * Add/Modify/Delete/Get Endpoint > I'm not sure exactly what this is, but may need another noun for > endpoint > * Add/Modify/Delete/Get Endpoint Media > I'm pretty sure this is not xcon state > * Add/Modify/Delete/Get Media Groups > I'm pretty sure this is not xcon state > * Add/Modify/Delete Sidebar > Create(Sidebar), Delete(Sidebar) not sure you need a modify > Generally I think you have a very simplistic create, and then use > set/get to change values in the object the create made for you > * Add/Modify/Delete/Get Role > Need a noun, maybe Set(Role), but is this actually conference state? > * Add User To Sidebar > AddListItem(Sidebar) > * Delete User From Sidebar > DeleteListItem(Sidebar) > * Move User Between Sidebars > Delete then add. Doesn't have to be a transaction I think > * Add/Modify/Delete/Get XML element > Set/Get(one of my list of nouns) > * Set/Get/Delete XML attribute > Dunno what you mean > * Get Templates > Aha, need a noun for set/get "focus" > * Get Blueprints > Get(focus) > * Get Active Conferences > Get(focus) >=20 > * Cancel > Cancel what? > * Ping > Ping on the conf control channel? Some no-op > * Options > Dunno what you mean >=20 >=20 >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 > 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. >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Mar 22 09:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM4Jg-0004eI-5K; Wed, 22 Mar 2006 09:28:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM4Jf-0004eD-6R for xcon@ietf.org; Wed, 22 Mar 2006 09:28:03 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM4Je-0001hY-Oi for xcon@ietf.org; Wed, 22 Mar 2006 09:28:03 -0500 Received: from BROSENLT41XP ([204.96.113.139]) by server (8.12.8/8.12.8) with SMTP id k2MD0b2w008142; Wed, 22 Mar 2006 08:00:47 -0500 From: "Brian Rosen" To: "'Even, Roni'" , "'Chris Boulton'" , "'Adam Roach'" , Subject: RE: [XCON] Talking Points Date: Wed, 22 Mar 2006 02:10:45 -0500 Message-ID: <02e601c64d7f$cb546950$73818182@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.2670 Thread-Index: AcZNOhRCSr2ATwqRQGWRPOnb1cDCnAAANDbQAAeWc0AAB4TVEAAQGvwwAA4uVUA= In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C0357221B@IsrExch01.israel.polycom.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org All of the parameters I can think of that you "modify" are just values somewhere in the object. The Set/Get verb can set them to any value that is acceptable at any time. Creating a new item in a list is not a set/get, it's a different operation. Brian -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Wednesday, March 22, 2006 8:54 AM To: br@brianrosen.net; Chris Boulton; Adam Roach; xcon@ietf.org Subject: RE: [XCON] Talking Points Brian, Hi, The modify conference is needed for modifying parameters before the conference starts. The get may be needed to get the conference information after it is finished for CDR (we need charging) Roni Even > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 8:12 AM > To: 'Chris Boulton'; 'Adam Roach'; xcon@ietf.org > Subject: RE: [XCON] Talking Points > > I'm thinking that the operation to add or delete someone to a list is just > that. If that someone has some kind of state that can be modified, then > the > add/delete returns a handle and the set/get is used to change the state. > > Would that work for you? > > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: Tuesday, March 21, 2006 9:37 PM > To: br@brianrosen.net; Adam Roach; xcon@ietf.org > Subject: RE: [XCON] Talking Points > > AddListItem(Participant), DeleteListItem(Participant). May need a > modify, but I don't think so > > Brian - I guess this all depends on how you define a participant. If > the participant has tied properties that might change during a > conference then a modify might be needed. > > Chris. > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 21 March 2006 23:13 > To: 'Adam Roach'; xcon@ietf.org > Subject: RE: [XCON] Talking Points > > Using my verb/noun list: > > * Create Conference based on specified blueprint > Create(Conference) > * Create Conference based on implied blueprint > Create(Conference) > * Modify/Delete/Get Conference > Delete(Conference). Maybe I need a get/modify but I don't think so > * Add/Modify/Delete/Get User > AddListItem(Participant), DeleteListItem(Participant). May need a > modify, > but I don't think so > * Modify User Roles > Is this AddListItem(AllowedRoles)? I'd need a new noun for List > * Add/Modify/Delete/Get Endpoint > I'm not sure exactly what this is, but may need another noun for > endpoint > * Add/Modify/Delete/Get Endpoint Media > I'm pretty sure this is not xcon state > * Add/Modify/Delete/Get Media Groups > I'm pretty sure this is not xcon state > * Add/Modify/Delete Sidebar > Create(Sidebar), Delete(Sidebar) not sure you need a modify > Generally I think you have a very simplistic create, and then use > set/get to change values in the object the create made for you > * Add/Modify/Delete/Get Role > Need a noun, maybe Set(Role), but is this actually conference state? > * Add User To Sidebar > AddListItem(Sidebar) > * Delete User From Sidebar > DeleteListItem(Sidebar) > * Move User Between Sidebars > Delete then add. Doesn't have to be a transaction I think > * Add/Modify/Delete/Get XML element > Set/Get(one of my list of nouns) > * Set/Get/Delete XML attribute > Dunno what you mean > * Get Templates > Aha, need a noun for set/get "focus" > * Get Blueprints > Get(focus) > * Get Active Conferences > Get(focus) > > * Cancel > Cancel what? > * Ping > Ping on the conf control channel? Some no-op > * Options > Dunno what you mean > > > > > _______________________________________________ > 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 Mar 22 10:15:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM53B-00075b-QX; Wed, 22 Mar 2006 10:15:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM53A-00074W-67 for xcon@ietf.org; Wed, 22 Mar 2006 10:15:04 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM539-00038N-Ip for xcon@ietf.org; Wed, 22 Mar 2006 10:15:04 -0500 Received: from rly24b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly24b.srv.mailcontrol.com (MailControl) with ESMTP id k2MFEqiF007700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Mar 2006 15:14:52 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly24b.srv.mailcontrol.com (MailControl) id k2MFENqJ006448 for xcon@ietf.org; Wed, 22 Mar 2006 15:14:23 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly24b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k2MFE6wv005924; Wed, 22 Mar 2006 15:14:23 +0000 (GMT) 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] Talking Points Date: Wed, 22 Mar 2006 15:14:05 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE03118999@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Talking Points Thread-Index: AcZNOhRCSr2ATwqRQGWRPOnb1cDCnAAANDbQAAeWc0AAB4TVEAASlPGA From: "Chris Boulton" To: , "Adam Roach" , X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.66.1.134 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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'm thinking that the operation to add or delete someone to a list is just that. If that someone has some kind of state that can be modified, then the add/delete returns a handle and the set/get is used to change the state. Would that work for you? [Chris Boulton] This seems fine to me but I will continue to knock this around. I guess I was mainly considering the impact on how the dynamic (template) part is manipulated. I am assuming by the same mechanism of using the handle returned by the 'add' operation. I would hope that the handle being returned would be either directly/or derived for the xcon URI currently defined in the XCON framework appendix. This is intended to provide such a unique reference to a conference instance. Chris. -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: Tuesday, March 21, 2006 9:37 PM To: br@brianrosen.net; Adam Roach; xcon@ietf.org Subject: RE: [XCON] Talking Points AddListItem(Participant), DeleteListItem(Participant). May need a modify, but I don't think so Brian - I guess this all depends on how you define a participant. If the participant has tied properties that might change during a conference then a modify might be needed. Chris. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 21 March 2006 23:13 To: 'Adam Roach'; xcon@ietf.org Subject: RE: [XCON] Talking Points Using my verb/noun list: * Create Conference based on specified blueprint Create(Conference) * Create Conference based on implied blueprint Create(Conference) * Modify/Delete/Get Conference Delete(Conference). Maybe I need a get/modify but I don't think so * Add/Modify/Delete/Get User AddListItem(Participant), DeleteListItem(Participant). May need a modify, but I don't think so * Modify User Roles Is this AddListItem(AllowedRoles)? I'd need a new noun for List * Add/Modify/Delete/Get Endpoint I'm not sure exactly what this is, but may need another noun for endpoint * Add/Modify/Delete/Get Endpoint Media I'm pretty sure this is not xcon state * Add/Modify/Delete/Get Media Groups I'm pretty sure this is not xcon state * Add/Modify/Delete Sidebar Create(Sidebar), Delete(Sidebar) not sure you need a modify Generally I think you have a very simplistic create, and then use=20 set/get to change values in the object the create made for you * Add/Modify/Delete/Get Role Need a noun, maybe Set(Role), but is this actually conference state? * Add User To Sidebar AddListItem(Sidebar) * Delete User From Sidebar DeleteListItem(Sidebar) * Move User Between Sidebars Delete then add. Doesn't have to be a transaction I think * Add/Modify/Delete/Get XML element Set/Get(one of my list of nouns) * Set/Get/Delete XML attribute Dunno what you mean * Get Templates Aha, need a noun for set/get "focus" * Get Blueprints Get(focus) * Get Active Conferences Get(focus) * Cancel Cancel what? * Ping Ping on the conf control channel? Some no-op * Options Dunno what you mean _______________________________________________ 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 From xcon-bounces@ietf.org Wed Mar 22 10:27:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5Fa-0007jH-QR; Wed, 22 Mar 2006 10:27:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5FZ-0007jB-Jn for xcon@ietf.org; Wed, 22 Mar 2006 10:27:53 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5FZ-0003fJ-92 for xcon@ietf.org; Wed, 22 Mar 2006 10:27:53 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FM5FK-0006Um-D7; Wed, 22 Mar 2006 09:27:39 -0600 From: "Brian Rosen" To: "'Chris Boulton'" , "'Adam Roach'" , Subject: RE: [XCON] Talking Points Date: Wed, 22 Mar 2006 10:27:41 -0500 Message-ID: <030a01c64dc5$2ae9cfa0$73818182@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.2670 Thread-Index: AcZNOhRCSr2ATwqRQGWRPOnb1cDCnAAANDbQAAeWc0AAB4TVEAASlPGAAACm0CA= In-Reply-To: <45730E094814E44488F789C1CDED27AE03118999@gbnewp0758m.eu.ubiquity.net> X-PopBeforeSMTPSenders: br@brianrosen.net 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 - [0 0] / [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: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Yeah, that's pretty much what I'm thinking. If the template has a construct like ... 100 That is, there is an array of volume sliders, indexed by user, then Add(user,...) might return 3, and then there would be a In-Reply-To: <45730E094814E44488F789C1CDED27AE04E78C87@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Talking Points Thread-Index: AcZNOhRCSr2ATwqRQGWRPOnb1cDCnAAANDbQAAeWc0AAHzNfUA== From: "Sean Olson" To: "Chris Boulton" , , "Adam Roach" , X-OriginalArrivalTime: 22 Mar 2006 17:29:04.0522 (UTC) FILETIME=[1DD116A0:01C64DD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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'm not sure I understand why you need to explicitly call out the list data structure for the participant .... Isn't this self-described by the data model?=20 -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: Tuesday, March 21, 2006 6:37 PM To: br@brianrosen.net; Adam Roach; xcon@ietf.org Subject: RE: [XCON] Talking Points AddListItem(Participant), DeleteListItem(Participant). May need a modify, but I don't think so Brian - I guess this all depends on how you define a participant. If the participant has tied properties that might change during a conference then a modify might be needed. Chris. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: 21 March 2006 23:13 To: 'Adam Roach'; xcon@ietf.org Subject: RE: [XCON] Talking Points Using my verb/noun list: * Create Conference based on specified blueprint Create(Conference) * Create Conference based on implied blueprint Create(Conference) * Modify/Delete/Get Conference Delete(Conference). Maybe I need a get/modify but I don't think so * Add/Modify/Delete/Get User AddListItem(Participant), DeleteListItem(Participant). May need a modify, but I don't think so * Modify User Roles Is this AddListItem(AllowedRoles)? I'd need a new noun for List * Add/Modify/Delete/Get Endpoint I'm not sure exactly what this is, but may need another noun for endpoint * Add/Modify/Delete/Get Endpoint Media I'm pretty sure this is not xcon state * Add/Modify/Delete/Get Media Groups I'm pretty sure this is not xcon state * Add/Modify/Delete Sidebar Create(Sidebar), Delete(Sidebar) not sure you need a modify Generally I think you have a very simplistic create, and then use=20 set/get to change values in the object the create made for you * Add/Modify/Delete/Get Role Need a noun, maybe Set(Role), but is this actually conference state? * Add User To Sidebar AddListItem(Sidebar) * Delete User From Sidebar DeleteListItem(Sidebar) * Move User Between Sidebars Delete then add. Doesn't have to be a transaction I think * Add/Modify/Delete/Get XML element Set/Get(one of my list of nouns) * Set/Get/Delete XML attribute Dunno what you mean * Get Templates Aha, need a noun for set/get "focus" * Get Blueprints Get(focus) * Get Active Conferences Get(focus) * Cancel Cancel what? * Ping Ping on the conf control channel? Some no-op * Options Dunno what you mean _______________________________________________ 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 Mar 22 12:34:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7ER-0002us-U8; Wed, 22 Mar 2006 12:34:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7EQ-0002uO-WC for xcon@ietf.org; Wed, 22 Mar 2006 12:34:51 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7EQ-0000rF-KO for xcon@ietf.org; Wed, 22 Mar 2006 12:34:50 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2MHYmoN014199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2006 11:34:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <44218AB7.6090705@nostrum.com> Date: Wed, 22 Mar 2006 11:34:47 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson Subject: Re: [XCON] Talking Points References: <65F27F597EB1E44384BA802189D334C611F044@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <65F27F597EB1E44384BA802189D334C611F044@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Chris Boulton , 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 Probably not... you have multiple lists to which users can be added. Or did I misunderstand your question? /a Sean Olson wrote: >I'm not sure I understand why you need to explicitly call out the list >data structure for the participant .... Isn't this self-described by the >data model? > >-----Original Message----- >From: Chris Boulton [mailto:cboulton@ubiquity.net] >Sent: Tuesday, March 21, 2006 6:37 PM >To: br@brianrosen.net; Adam Roach; xcon@ietf.org >Subject: RE: [XCON] Talking Points > >AddListItem(Participant), DeleteListItem(Participant). May need a >modify, but I don't think so > >Brian - I guess this all depends on how you define a participant. If >the participant has tied properties that might change during a >conference then a modify might be needed. > >Chris. > > >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: 21 March 2006 23:13 >To: 'Adam Roach'; xcon@ietf.org >Subject: RE: [XCON] Talking Points > >Using my verb/noun list: > > * Create Conference based on specified blueprint >Create(Conference) > * Create Conference based on implied blueprint >Create(Conference) > * Modify/Delete/Get Conference >Delete(Conference). Maybe I need a get/modify but I don't think so > * Add/Modify/Delete/Get User >AddListItem(Participant), DeleteListItem(Participant). May need a >modify, but I don't think so > * Modify User Roles >Is this AddListItem(AllowedRoles)? I'd need a new noun for List > * Add/Modify/Delete/Get Endpoint >I'm not sure exactly what this is, but may need another noun for >endpoint > * Add/Modify/Delete/Get Endpoint Media I'm pretty sure this is not >xcon state > * Add/Modify/Delete/Get Media Groups I'm pretty sure this is not >xcon state > * Add/Modify/Delete Sidebar >Create(Sidebar), Delete(Sidebar) not sure you need a modify > Generally I think you have a very simplistic create, and then use > set/get to change values in the object the create made for you > * Add/Modify/Delete/Get Role >Need a noun, maybe Set(Role), but is this actually conference state? > * Add User To Sidebar >AddListItem(Sidebar) > * Delete User From Sidebar >DeleteListItem(Sidebar) > * Move User Between Sidebars >Delete then add. Doesn't have to be a transaction I think > * Add/Modify/Delete/Get XML element >Set/Get(one of my list of nouns) > * Set/Get/Delete XML attribute >Dunno what you mean > * Get Templates >Aha, need a noun for set/get "focus" > * Get Blueprints >Get(focus) > * Get Active Conferences >Get(focus) > > * Cancel >Cancel what? > * Ping >Ping on the conf control channel? Some no-op > * Options >Dunno what you mean > > > > >_______________________________________________ >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 Mar 22 14:31:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM93c-0007J9-BB; Wed, 22 Mar 2006 14:31:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM93b-0007J4-6j for xcon@ietf.org; Wed, 22 Mar 2006 14:31:47 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM93a-0006a1-SA for xcon@ietf.org; Wed, 22 Mar 2006 14:31:47 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FM93K-0005AQ-7s; Wed, 22 Mar 2006 13:31:31 -0600 From: "Brian Rosen" To: "'Sean Olson'" , "'Chris Boulton'" , "'Adam Roach'" , Subject: RE: [XCON] Talking Points Date: Wed, 22 Mar 2006 14:31:31 -0500 Message-ID: <03a501c64de7$3bd114a0$73818182@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.2670 Thread-Index: AcZNOhRCSr2ATwqRQGWRPOnb1cDCnAAANDbQAAeWc0AAHzNfUAAALKQw In-Reply-To: <65F27F597EB1E44384BA802189D334C611F044@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> X-PopBeforeSMTPSenders: br@brianrosen.net 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 - [0 0] / [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: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org User is a little bit of a special case here, because the protocol doesn't actually provide a method to directly create one. It indirectly creates them by users responding to actions resulting from using dial out, dial in/refer mechanisms. In the end, however, a new user would be added to the list of users, and would have some kind of index that would be used for, as in the example, a user volume control. A better example is the dial out list. You explicitly add/delete an item on that list. You don't have to create the volume control entry explicitly; when a new user is added, by the focus, it effectively adds a new volume control to the volume control list. So we don't need to AddListElement(Volume); it's done implicitly. You can immediately Set(Volume(user)) (ignore syntax) Brian -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Wednesday, March 22, 2006 12:29 PM To: Chris Boulton; br@brianrosen.net; Adam Roach; xcon@ietf.org Subject: RE: [XCON] Talking Points I'm not sure I understand why you need to explicitly call out the list data structure for the participant .... Isn't this self-described by the data model? -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net] Sent: Tuesday, March 21, 2006 6:37 PM To: br@brianrosen.net; Adam Roach; xcon@ietf.org Subject: RE: [XCON] Talking Points AddListItem(Participant), DeleteListItem(Participant). May need a modify, but I don't think so Brian - I guess this all depends on how you define a participant. If the participant has tied properties that might change during a conference then a modify might be needed. Chris. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: 21 March 2006 23:13 To: 'Adam Roach'; xcon@ietf.org Subject: RE: [XCON] Talking Points Using my verb/noun list: * Create Conference based on specified blueprint Create(Conference) * Create Conference based on implied blueprint Create(Conference) * Modify/Delete/Get Conference Delete(Conference). Maybe I need a get/modify but I don't think so * Add/Modify/Delete/Get User AddListItem(Participant), DeleteListItem(Participant). May need a modify, but I don't think so * Modify User Roles Is this AddListItem(AllowedRoles)? I'd need a new noun for List * Add/Modify/Delete/Get Endpoint I'm not sure exactly what this is, but may need another noun for endpoint * Add/Modify/Delete/Get Endpoint Media I'm pretty sure this is not xcon state * Add/Modify/Delete/Get Media Groups I'm pretty sure this is not xcon state * Add/Modify/Delete Sidebar Create(Sidebar), Delete(Sidebar) not sure you need a modify Generally I think you have a very simplistic create, and then use set/get to change values in the object the create made for you * Add/Modify/Delete/Get Role Need a noun, maybe Set(Role), but is this actually conference state? * Add User To Sidebar AddListItem(Sidebar) * Delete User From Sidebar DeleteListItem(Sidebar) * Move User Between Sidebars Delete then add. Doesn't have to be a transaction I think * Add/Modify/Delete/Get XML element Set/Get(one of my list of nouns) * Set/Get/Delete XML attribute Dunno what you mean * Get Templates Aha, need a noun for set/get "focus" * Get Blueprints Get(focus) * Get Active Conferences Get(focus) * Cancel Cancel what? * Ping Ping on the conf control channel? Some no-op * Options Dunno what you mean _______________________________________________ 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 Mar 22 15:07:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9cU-0004tM-0A; Wed, 22 Mar 2006 15:07:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9cS-0004tH-FX for xcon@ietf.org; Wed, 22 Mar 2006 15:07:48 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9cR-0008BR-My for xcon@ietf.org; Wed, 22 Mar 2006 15:07:48 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D8262CF7; Wed, 22 Mar 2006 21:07:46 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 21:07:46 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 21:07:46 +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] Talking Points Date: Wed, 22 Mar 2006 21:07:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Talking Points Thread-Index: AcZNPpwIMcdgYGJNTEC3cBqT/0vmRQAAKKugACqK99A= From: "Oscar Novo \(JO/LMF\)" To: "Sean Olson" , "Adam Roach" , X-OriginalArrivalTime: 22 Mar 2006 20:07:46.0149 (UTC) FILETIME=[49261150:01C64DEC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 I would like to remind you that the CSCP is an extension of the BFCP. So, CSCP can re-used some operations already defined in BFCP, for instance, the "Hello" operation defined in the BFCP that checks the liveness of the focus. As well, I would like to remind you that the CSCP is following the same general protocol requirements that the Floor Control Protocol defined in RFC 4376. For instance, REQ-GEN-1: "Bandwidth and terminal limitations SHOULD be taken into account in order to ensure that floor control can be efficiently used in mobile environments." =20 =20 -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: 21. maaliskuuta 2006 17:33 To: Adam Roach; br@brianrosen.net Cc: xcon@ietf.org Subject: RE: [XCON] Talking Points The CCCP ping is a liveness check similar to the ill-fated SIP PING discussions. It specifically checks for application-level liveness of the conference state at the Focus. There are some interesting failover cases that could benefit from this --- there may also be much better or simpler solutions. I'm fine with cutting this from the initial list of operations. The CCCP cancel command is similar to a SIP CANCEL which we thought might be useful to terminate long commands (addUser for example). In retrospect, we might want to cut this operation for now until we have a better handle on the other operations. -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: Tuesday, March 21, 2006 3:23 PM To: br@brianrosen.net Cc: xcon@ietf.org Subject: Re: [XCON] Talking Points As clarification, what I posted was a straight union of the operations from all four proposals, not what I thought was a good set of operations. This isn't likely to make sense without some paring. However, at least *some* one thought that each of the operations was a good idea. Brian Rosen wrote: > * Add/Modify/Delete/Get XML element Set/Get(one of my list of >nouns) > * Set/Get/Delete XML attribute >Dunno what you mean > =20 > Consider the construct: In XML, "foo" is the element, and "bar" is an attribute of that element. See the CSCP draft for more information. > * Cancel >Cancel what? > =20 > See the CCCP draft for more information. > * Ping >Ping on the conf control channel? Some no-op > =20 > See the CCCP draft for more information. > * Options >Dunno what you mean > =20 > See the COMP draft for more information. /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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 24 11:19:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMp0z-0006rU-QN; Fri, 24 Mar 2006 11:19:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMp0y-0006gb-EW for xcon@ietf.org; Fri, 24 Mar 2006 11:19:52 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMp0w-0006vJ-4X for xcon@ietf.org; Fri, 24 Mar 2006 11:19:52 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2OGJnuI039413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Mar 2006 10:19:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <44241C21.8070804@nostrum.com> Date: Fri, 24 Mar 2006 10:19:45 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcon@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [XCON] Minutes Posted 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] The minutes from the ad-hoc meeting are now posted on the IETF materials page: https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=65 /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Mar 24 12:15:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMptG-0005CS-6o; Fri, 24 Mar 2006 12:15:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMptF-0005B5-3s for xcon@ietf.org; Fri, 24 Mar 2006 12:15:57 -0500 Received: from webmail.unina.it ([192.132.34.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMptD-0002Vz-KF for xcon@ietf.org; Fri, 24 Mar 2006 12:15:57 -0500 Received: from webmail.unina.it (localhost [127.0.0.1]) by webmail.unina.it (8.12.11/8.12.11) with ESMTP id k2OHeAKP021356; Fri, 24 Mar 2006 18:40:10 +0100 Received: (from nobody@localhost) by webmail.unina.it (8.12.11/8.12.11/Submit) id k2OHeAa9021355; Fri, 24 Mar 2006 18:40:10 +0100 X-Authentication-Warning: webmail.unina.it: nobody set sender to spromano@unina.it using -f Received: from DHCP-Wired-66-174.ietf65.org (DHCP-Wired-66-174.ietf65.org [130.129.66.174]) by webmail.unina.it (IMP) with HTTP for ; Fri, 24 Mar 2006 18:40:10 +0100 Message-ID: <1143222010.44242efa80976@webmail.unina.it> Date: Fri, 24 Mar 2006 18:40:10 +0100 From: Simon Pietro Romano To: Adam Roach Subject: Re: [XCON] Minutes Posted References: <44241C21.8070804@nostrum.com> In-Reply-To: <44241C21.8070804@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 130.129.66.174 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by webmail.unina.it id k2OHeAKP021356 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 all, for the seek of completeness: > ??:Mentioned existing standard WSRF from OASIS. SOAP would be nice one > to use. Should take a look. "??" was Simon Romano, and the WSRF framework I was mentioning is at http://docs.oasis-open.org/wsrf/ Hope this helps. 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~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ Scrive Adam Roach : > [as chair] >=20 > The minutes from the ad-hoc meeting are now posted on the IETF material= s > page: >=20 > https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=3D= 65 >=20 > /a >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 > --=20 > Il messaggio e' stato analizzato alla ricerca di virus o > contenuti pericolosi da MailScanner, ed e' > risultato non infetto. >=20 >=20 ---------------------------------------------------------------- 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 Mar 27 07:29:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNqqy-0000UC-WB; Mon, 27 Mar 2006 07:29:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNqqx-0000T4-QP for xcon@ietf.org; Mon, 27 Mar 2006 07:29:47 -0500 Received: from prix.tandberg.no ([194.196.35.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNqqw-0004RX-B5 for xcon@ietf.org; Mon, 27 Mar 2006 07:29:47 -0500 Received: from 47mail.eu.tandberg.int (47mail.eu.tandberg.int [10.0.0.25]) by prix.tandberg.no (8.12.10/8.12.10) with ESMTP id k2RCTjY0004365 for ; Mon, 27 Mar 2006 14:29:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Mar 2006 14:29:38 +0200 Message-ID: <01C679F7AECF2B47B489F735B7EE4900D723A0@47mail.eu.tandberg.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Moving users between conferences Thread-Index: AcZRmh1VMHsf2eroSECiQyIxY47qPg== From: "Geir Arne Sandbakken" To: "XCON-IETF" X-Scanned-By: MIMEDefang 2.45 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: [XCON] Moving users between conferences 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="===============0555843902==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0555843902== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6519A.2179C8B1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6519A.2179C8B1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Moving users between sidebars has been proposed, but it would be nice to extend this for moving users between conferences as well. Having a "move" verb would be preferable, as a "delete user" followed by "add user" can have the side effect of disconnecting the user from the conference. =20 Two use cases: 1. Waiting room: You call a waiting room where someone controls when you can join a specific conference. =20 2. Help service: An administrator can move a user to another conference to help out with typical media problems, debugging or other issues. Then move the user back when it has been resolved. =20 Geir Arne ------_=_NextPart_001_01C6519A.2179C8B1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Moving users between sidebars has been proposed, but = it would be nice to extend this for moving users between conferences as = well.  Having a “move” verb would be preferable, as a “delete = user” followed by “add user” can have the side effect of disconnecting the = user from the conference.

 

Two use cases:

1. Waiting room:  You call a waiting room where = someone controls when you can join a specific conference.  =

2. Help service:  An administrator can move a = user to another conference to help out with typical media problems, debugging or = other issues.  Then move the user back when it has been = resolved.

 

Geir Arne

------_=_NextPart_001_01C6519A.2179C8B1-- --===============0555843902== 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 --===============0555843902==-- From xcon-bounces@ietf.org Mon Mar 27 10:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtSz-0001p0-7u; Mon, 27 Mar 2006 10:17:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtSy-0001ov-Dq for xcon@ietf.org; Mon, 27 Mar 2006 10:17:12 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtSv-0002UT-OC for xcon@ietf.org; Mon, 27 Mar 2006 10:17:12 -0500 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 27 Mar 2006 07:17:08 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 07:17:07 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 07:17:07 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 07:17:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Moving users between conferences Date: Mon, 27 Mar 2006 07:17:06 -0800 Message-ID: <65F27F597EB1E44384BA802189D334C61CFA88@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <01C679F7AECF2B47B489F735B7EE4900D723A0@47mail.eu.tandberg.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Moving users between conferences Thread-Index: AcZRmh1VMHsf2eroSECiQyIxY47qPgAF1aUQ From: "Sean Olson" To: "Geir Arne Sandbakken" , "XCON-IETF" X-OriginalArrivalTime: 27 Mar 2006 15:17:07.0477 (UTC) FILETIME=[82F4A450:01C651B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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: , Content-Type: multipart/mixed; boundary="===============2027015988==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============2027015988== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C651B1.7E62C63D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C651B1.7E62C63D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I don't see why those two use cases could not be handled by a sidebar. ________________________________ From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net]=20 Sent: Monday, March 27, 2006 4:30 AM To: XCON-IETF Subject: [XCON] Moving users between conferences Moving users between sidebars has been proposed, but it would be nice to extend this for moving users between conferences as well. Having a "move" verb would be preferable, as a "delete user" followed by "add user" can have the side effect of disconnecting the user from the conference. =20 Two use cases: 1. Waiting room: You call a waiting room where someone controls when you can join a specific conference. =20 2. Help service: An administrator can move a user to another conference to help out with typical media problems, debugging or other issues. Then move the user back when it has been resolved. =20 Geir Arne ------_=_NextPart_001_01C651B1.7E62C63D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I don't see why those two use cases could not = be handled by=20 a sidebar.

From: Geir Arne Sandbakken=20 [mailto:geir.sandbakken@tandberg.net]
Sent: Monday, March 27, = 2006=20 4:30 AM
To: XCON-IETF
Subject: [XCON] Moving users = between=20 conferences

Moving users between = sidebars has=20 been proposed, but it would be nice to extend this for moving users = between=20 conferences as well.  Having a “move” verb would be = preferable, as a=20 “delete user” followed by “add user” can have = the side effect of disconnecting=20 the user from the conference.

 

Two use=20 cases:

1. Waiting room:  You = call a=20 waiting room where someone controls when you can join a specific=20 conference. 

2. Help service:  An=20 administrator can move a user to another conference to help out with = typical=20 media problems, debugging or other issues.  Then move the user back = when it=20 has been resolved.

 

Geir=20 Arne

------_=_NextPart_001_01C651B1.7E62C63D-- --===============2027015988== 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 --===============2027015988==-- From xcon-bounces@ietf.org Mon Mar 27 10:23:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtZE-0005V4-Hk; Mon, 27 Mar 2006 10:23:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtZC-0005Uu-T1 for xcon@ietf.org; Mon, 27 Mar 2006 10:23:38 -0500 Received: from [212.179.41.2] (helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtZC-0002s3-8A for xcon@ietf.org; Mon, 27 Mar 2006 10:23:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Moving users between conferences Date: Mon, 27 Mar 2006 17:23:36 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03632241@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Moving users between conferences Thread-Index: AcZRmh1VMHsf2eroSECiQyIxY47qPgAF1aUQAAAMe5A= From: "Even, Roni" To: "Sean Olson" , "Geir Arne Sandbakken" , "XCON-IETF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb 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: , Content-Type: multipart/mixed; boundary="===============1897548190==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1897548190== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C651B2.6AFD82E9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C651B2.6AFD82E9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sean, Sidebar is a child of a conference which is not the case here. For the first case there is no conference yet. I agree that the second can be based on sidebar. I think that I agree with Geir that there is a need to move participants between conferences and not only from a conference to side bar and back Roni =20 ________________________________ From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: Monday, March 27, 2006 5:17 PM To: Geir Arne Sandbakken; XCON-IETF Subject: RE: [XCON] Moving users between conferences =20 I don't see why those two use cases could not be handled by a sidebar. =20 ________________________________ From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net]=20 Sent: Monday, March 27, 2006 4:30 AM To: XCON-IETF Subject: [XCON] Moving users between conferences Moving users between sidebars has been proposed, but it would be nice to extend this for moving users between conferences as well. Having a "move" verb would be preferable, as a "delete user" followed by "add user" can have the side effect of disconnecting the user from the conference. =20 Two use cases: 1. Waiting room: You call a waiting room where someone controls when you can join a specific conference. =20 2. Help service: An administrator can move a user to another conference to help out with typical media problems, debugging or other issues. Then move the user back when it has been resolved. =20 Geir Arne ------_=_NextPart_001_01C651B2.6AFD82E9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sean,

Sidebar is a child of a conference = which is not the case here. For the first case there is no conference yet. I = agree that the second can be based on sidebar.

I think that I agree with Geir that = there is a need to move participants between conferences and not only from a conference to side bar and back

Roni

 

From: Sean = Olson [mailto:Sean.Olson@microsoft.com]
Sent: Monday, March 27, = 2006 5:17 PM
To: Geir Arne Sandbakken; XCON-IETF
Subject: RE: [XCON] = Moving users between conferences

 

I don't see why those two use cases = could not be handled by a sidebar.

 

From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net]
Sent: Monday, March 27, = 2006 4:30 AM
To: XCON-IETF
Subject: [XCON] Moving = users between conferences

Moving users between sidebars has been proposed, but = it would be nice to extend this for moving users between conferences as = well.  Having a “move” verb would be preferable, as a = “delete user” followed by “add user” can have the side effect = of disconnecting the user from the conference.

 

Two use cases:

1. Waiting room:  You call a waiting room where = someone controls when you can join a specific conference.  =

2. Help service:  An administrator can move a = user to another conference to help out with typical media problems, debugging or = other issues.  Then move the user back when it has been = resolved.

 

Geir Arne

------_=_NextPart_001_01C651B2.6AFD82E9-- --===============1897548190== 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 --===============1897548190==-- From xcon-bounces@ietf.org Mon Mar 27 11:10:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuI6-0005mm-4e; Mon, 27 Mar 2006 11:10:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuI4-0005mb-Mz for xcon@ietf.org; Mon, 27 Mar 2006 11:10:00 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNuI4-0004pc-0h for xcon@ietf.org; Mon, 27 Mar 2006 11:10:00 -0500 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 27 Mar 2006 08:09:59 -0800 Received: from tuk-hub-01.redmond.corp.microsoft.com ([157.54.70.27]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 08:09:59 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 08:09:58 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 08:09:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Moving users between conferences Date: Mon, 27 Mar 2006 08:09:56 -0800 Message-ID: <65F27F597EB1E44384BA802189D334C61CFAA3@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C03632241@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Moving users between conferences Thread-Index: AcZRmh1VMHsf2eroSECiQyIxY47qPgAF1aUQAAAMe5AAAbnv8A== From: "Sean Olson" To: "Even, Roni" , "Geir Arne Sandbakken" , "XCON-IETF" X-OriginalArrivalTime: 27 Mar 2006 16:09:50.0431 (UTC) FILETIME=[E0391EF0:01C651B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 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: , Content-Type: multipart/mixed; boundary="===============0156077585==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0156077585== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C651B8.DFB40778" This is a multi-part message in MIME format. ------_=_NextPart_001_01C651B8.DFB40778 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I would not implement the first as a separate conference, but that is something that we could discuss more when we define the sidebar operations. I can see the value of defining a move user between conferences operation, though I'm a bit skeptical of the architecture to enable such an operation. I guess I'd like to see a high level call flow for how this would work. ________________________________ From: Even, Roni [mailto:roni.even@polycom.co.il]=20 Sent: Monday, March 27, 2006 7:24 AM To: Sean Olson; Geir Arne Sandbakken; XCON-IETF Subject: RE: [XCON] Moving users between conferences Sean, Sidebar is a child of a conference which is not the case here. For the first case there is no conference yet. I agree that the second can be based on sidebar. I think that I agree with Geir that there is a need to move participants between conferences and not only from a conference to side bar and back Roni =20 ________________________________ From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: Monday, March 27, 2006 5:17 PM To: Geir Arne Sandbakken; XCON-IETF Subject: RE: [XCON] Moving users between conferences =20 I don't see why those two use cases could not be handled by a sidebar. =20 ________________________________ From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net]=20 Sent: Monday, March 27, 2006 4:30 AM To: XCON-IETF Subject: [XCON] Moving users between conferences Moving users between sidebars has been proposed, but it would be nice to extend this for moving users between conferences as well. Having a "move" verb would be preferable, as a "delete user" followed by "add user" can have the side effect of disconnecting the user from the conference. =20 Two use cases: 1. Waiting room: You call a waiting room where someone controls when you can join a specific conference. =20 2. Help service: An administrator can move a user to another conference to help out with typical media problems, debugging or other issues. Then move the user back when it has been resolved. =20 Geir Arne ------_=_NextPart_001_01C651B8.DFB40778 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I would not implement the first as a separate = conference, but that is something that we could discuss more when we = define the=20 sidebar operations. I can see the value of defining a move user between=20 conferences operation, though I'm a bit skeptical of the architecture to = enable=20 such an operation. I guess I'd like to see a high level call flow for = how this=20 would work.

From: Even, Roni=20 [mailto:roni.even@polycom.co.il]
Sent: Monday, March 27, 2006 = 7:24=20 AM
To: Sean Olson; Geir Arne Sandbakken; = XCON-IETF
Subject:=20 RE: [XCON] Moving users between conferences

Sean,

Sidebar is a = child of a=20 conference which is not the case here. For the first case there is no = conference=20 yet. I agree that the second can be based on=20 sidebar.

I think that = I agree=20 with Geir that there is a need to move participants between conferences = and not=20 only from a conference to side bar and back

Roni

 

From: Sean=20 Olson [mailto:Sean.Olson@microsoft.com]
Sent: Monday, March 27, 2006 5:17 = PM
To: Geir Arne = Sandbakken;=20 XCON-IETF
Subject: = RE: [XCON]=20 Moving users between conferences

 

I don't see = why those=20 two use cases could not be handled by a = sidebar.

 

From: Geir Arne=20 Sandbakken [mailto:geir.sandbakken@tandberg.net]
Sent: Monday, March 27, 2006 4:30 = AM
To: = XCON-IETF
Subject: [XCON] Moving users = between=20 conferences

Moving users between = sidebars has=20 been proposed, but it would be nice to extend this for moving users = between=20 conferences as well.  Having a “move” verb would be = preferable, as a=20 “delete user” followed by “add user” can have = the side effect of disconnecting=20 the user from the conference.

 

Two use=20 cases:

1. Waiting room:  You = call a=20 waiting room where someone controls when you can join a specific=20 conference. 

2. Help service:  An=20 administrator can move a user to another conference to help out with = typical=20 media problems, debugging or other issues.  Then move the user back = when it=20 has been resolved.

 

Geir=20 Arne

------_=_NextPart_001_01C651B8.DFB40778-- --===============0156077585== 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 --===============0156077585==-- From xcon-bounces@ietf.org Mon Mar 27 11:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuWV-0007MX-Um; Mon, 27 Mar 2006 11:24:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuWV-0007MS-0j for xcon@ietf.org; Mon, 27 Mar 2006 11:24:55 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNuWU-0005dP-Fc for xcon@ietf.org; Mon, 27 Mar 2006 11:24:54 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FNuWI-0006S0-3S; Mon, 27 Mar 2006 10:24:42 -0600 From: "Brian Rosen" To: "'Sean Olson'" , "'Even, Roni'" , "'Geir Arne Sandbakken'" , "'XCON-IETF'" Subject: RE: [XCON] Moving users between conferences Date: Mon, 27 Mar 2006 11:24:29 -0500 Message-ID: <0b6f01c651ba$ee99edb0$73818182@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZRmh1VMHsf2eroSECiQyIxY47qPgAF1aUQAAAMe5AAAbnv8AAAaqAA In-Reply-To: <65F27F597EB1E44384BA802189D334C61CFAA3@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> X-PopBeforeSMTPSenders: br@brianrosen.net 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: 3643ee1fccf5d6cf2af25f27d28abb29 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1756146478==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1756146478== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B70_01C65191.05C3E5B0" This is a multi-part message in MIME format. ------=_NextPart_000_0B70_01C65191.05C3E5B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm with you that the first two are probably sidebars, although the waiting room may not be; depends on exactly what the wait room is. If you get to it with a generic wait room URI, then you select a conference (somehow) and then you are placed in the conference, then it's move-between-conferences. If you get to it with the real conference URI, but you are "seated" in the wait room for some reason, then it's a sidebar. I am also a bit skeptical of move-between-conferences. Is this not a "Refer/Replaces" operation; changing the URI of the conference? If it's not, then you have the weird situation where the call state is to one conference, with a URI, but you are actually in another conference, with a different URI. If, for some reason, the UAC decided it needed to create a new dialog, it's not with the same URI as the original. That sounds pretty weird to me. Brian _____ From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Monday, March 27, 2006 11:10 AM To: Even, Roni; Geir Arne Sandbakken; XCON-IETF Subject: RE: [XCON] Moving users between conferences I would not implement the first as a separate conference, but that is something that we could discuss more when we define the sidebar operations. I can see the value of defining a move user between conferences operation, though I'm a bit skeptical of the architecture to enable such an operation. I guess I'd like to see a high level call flow for how this would work. _____ From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Monday, March 27, 2006 7:24 AM To: Sean Olson; Geir Arne Sandbakken; XCON-IETF Subject: RE: [XCON] Moving users between conferences Sean, Sidebar is a child of a conference which is not the case here. For the first case there is no conference yet. I agree that the second can be based on sidebar. I think that I agree with Geir that there is a need to move participants between conferences and not only from a conference to side bar and back Roni _____ From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Monday, March 27, 2006 5:17 PM To: Geir Arne Sandbakken; XCON-IETF Subject: RE: [XCON] Moving users between conferences I don't see why those two use cases could not be handled by a sidebar. _____ From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net] Sent: Monday, March 27, 2006 4:30 AM To: XCON-IETF Subject: [XCON] Moving users between conferences Moving users between sidebars has been proposed, but it would be nice to extend this for moving users between conferences as well. Having a "move" verb would be preferable, as a "delete user" followed by "add user" can have the side effect of disconnecting the user from the conference. Two use cases: 1. Waiting room: You call a waiting room where someone controls when you can join a specific conference. 2. Help service: An administrator can move a user to another conference to help out with typical media problems, debugging or other issues. Then move the user back when it has been resolved. Geir Arne ------=_NextPart_000_0B70_01C65191.05C3E5B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m with you that the first = two are probably sidebars, although the waiting room may not be; depends on exactly what = the wait room is.  If you get to it with a generic wait room URI, then = you select a conference (somehow) and then you are placed in the conference, = then it’s move-between-conferences.  If you get to it with the = real conference URI, but you are “seated” in the wait room for = some reason, then it’s a sidebar.

 

I am also a bit skeptical of move-between-conferences.  Is this not a = “Refer/Replaces” operation; changing the URI of the conference?  If it’s not, = then you have the weird situation where the call state is to one conference, = with a URI, but you are actually in another conference, with a different URI. =  If, for some reason, the UAC decided it needed to create a new dialog, = it’s not with the same URI as the original.  That sounds pretty weird to = me.

 

Brian

 

From: Sean = Olson [mailto:Sean.Olson@microsoft.com]
Sent: Monday, March 27, = 2006 11:10 AM
To: Even, Roni; Geir Arne Sandbakken; XCON-IETF
Subject: RE: [XCON] = Moving users between conferences

 

I would not implement the first as = a separate conference, but that is something that we could discuss more = when we define the sidebar operations. I can see the value of defining a move = user between conferences operation, though I'm a bit skeptical of the = architecture to enable such an operation. I guess I'd like to see a high level call = flow for how this would work.

 

From: Even, Roni [mailto:roni.even@polycom.co.il]
Sent: Monday, March 27, = 2006 7:24 AM
To: Sean Olson; Geir Arne Sandbakken; XCON-IETF
Subject: RE: [XCON] = Moving users between conferences

Sean,

Sidebar is a child of a conference = which is not the case here. For the first case there is no conference yet. I = agree that the second can be based on sidebar.

I think that I agree with Geir that = there is a need to move participants between conferences and not only from a conference to side bar and back

Roni

 

From: Sean = Olson [mailto:Sean.Olson@microsoft.com]
Sent: Monday, March 27, = 2006 5:17 PM
To: Geir Arne Sandbakken; XCON-IETF
Subject: RE: [XCON] = Moving users between conferences

 

I don't see why those two use cases = could not be handled by a sidebar.

 

From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net]
Sent: Monday, March 27, = 2006 4:30 AM
To: XCON-IETF
Subject: [XCON] Moving = users between conferences

Moving users between sidebars has been proposed, but = it would be nice to extend this for moving users between conferences as = well.  Having a “move” verb would be preferable, as a = “delete user” followed by “add user” can have the side effect = of disconnecting the user from the conference.

 

Two use cases:

1. Waiting room:  You call a waiting room where = someone controls when you can join a specific conference.  =

2. Help service:  An administrator can move a = user to another conference to help out with typical media problems, debugging or = other issues.  Then move the user back when it has been = resolved.

 

Geir Arne

------=_NextPart_000_0B70_01C65191.05C3E5B0-- --===============1756146478== 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 --===============1756146478==-- From xcon-bounces@ietf.org Mon Mar 27 13:21:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwLX-0003Sm-S7; Mon, 27 Mar 2006 13:21:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwLW-0003Sh-Bx for xcon@ietf.org; Mon, 27 Mar 2006 13:21:42 -0500 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 1FNwLW-0002Xi-7x for xcon@ietf.org; Mon, 27 Mar 2006 13:21:42 -0500 Received: from prix.tandberg.no ([194.196.35.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FNwLU-0001Wi-Q1 for xcon@ietf.org; Mon, 27 Mar 2006 13:21:42 -0500 Received: from 47mail.eu.tandberg.int (47mail.eu.tandberg.int [10.0.0.25]) by prix.tandberg.no (8.12.10/8.12.10) with ESMTP id k2RILXY0029546; Mon, 27 Mar 2006 20:21:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Moving users between conferences Date: Mon, 27 Mar 2006 20:21:32 +0200 Message-ID: <01C679F7AECF2B47B489F735B7EE4900E2F6CC@47mail.eu.tandberg.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Moving users between conferences Thread-Index: AcZRmh1VMHsf2eroSECiQyIxY47qPgAF1aUQAAAMe5AAAbnv8AAAaqAAAAG/KCA= From: "Geir Arne Sandbakken" To: , "Sean Olson" , "Even, Roni" , "XCON-IETF" X-Scanned-By: MIMEDefang 2.45 X-Spam-Score: -2.6 (--) X-Scan-Signature: dae47ebd0d959deee2d6f67621ddb2e3 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: , Content-Type: multipart/mixed; boundary="===============0068974009==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0068974009== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C651CB.46D17079" This is a multi-part message in MIME format. ------_=_NextPart_001_01C651CB.46D17079 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Use case 1 has a generic waiting room URI, where someone helps you into the right conference at the right time. Like many "in person" waiting rooms. If SIP was the call protocol, I would probably refresh the dialog. =20 If you are just waiting for the conference moderator to arrive before the conference can start, you may not even need a sidebar. The media mixer could just show everybody audio, video or text explaining why you wait. More like a mixer state. =20 Use case 2 can be solved by a sidebar as long as the sidebar is not limited by the original conference objects properties. The limitations of the original conference object may be the cause of the user's problems in the first place. =20 Geir Arne =20 ________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 27. mars 2006 18:24 To: 'Sean Olson'; 'Even, Roni'; Geir Arne Sandbakken; 'XCON-IETF' Subject: RE: [XCON] Moving users between conferences =20 I'm with you that the first two are probably sidebars, although the waiting room may not be; depends on exactly what the wait room is. If you get to it with a generic wait room URI, then you select a conference (somehow) and then you are placed in the conference, then it's move-between-conferences. If you get to it with the real conference URI, but you are "seated" in the wait room for some reason, then it's a sidebar. =20 I am also a bit skeptical of move-between-conferences. Is this not a "Refer/Replaces" operation; changing the URI of the conference? If it's not, then you have the weird situation where the call state is to one conference, with a URI, but you are actually in another conference, with a different URI. If, for some reason, the UAC decided it needed to create a new dialog, it's not with the same URI as the original. That sounds pretty weird to me. =20 Brian =20 ________________________________ From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: Monday, March 27, 2006 11:10 AM To: Even, Roni; Geir Arne Sandbakken; XCON-IETF Subject: RE: [XCON] Moving users between conferences =20 I would not implement the first as a separate conference, but that is something that we could discuss more when we define the sidebar operations. I can see the value of defining a move user between conferences operation, though I'm a bit skeptical of the architecture to enable such an operation. I guess I'd like to see a high level call flow for how this would work. =20 ________________________________ From: Even, Roni [mailto:roni.even@polycom.co.il]=20 Sent: Monday, March 27, 2006 7:24 AM To: Sean Olson; Geir Arne Sandbakken; XCON-IETF Subject: RE: [XCON] Moving users between conferences Sean, Sidebar is a child of a conference which is not the case here. For the first case there is no conference yet. I agree that the second can be based on sidebar. I think that I agree with Geir that there is a need to move participants between conferences and not only from a conference to side bar and back Roni =20 ________________________________ From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: Monday, March 27, 2006 5:17 PM To: Geir Arne Sandbakken; XCON-IETF Subject: RE: [XCON] Moving users between conferences =20 I don't see why those two use cases could not be handled by a sidebar. =20 ________________________________ From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net]=20 Sent: Monday, March 27, 2006 4:30 AM To: XCON-IETF Subject: [XCON] Moving users between conferences Moving users between sidebars has been proposed, but it would be nice to extend this for moving users between conferences as well. Having a "move" verb would be preferable, as a "delete user" followed by "add user" can have the side effect of disconnecting the user from the conference. =20 Two use cases: 1. Waiting room: You call a waiting room where someone controls when you can join a specific conference. =20 2. Help service: An administrator can move a user to another conference to help out with typical media problems, debugging or other issues. Then move the user back when it has been resolved. =20 Geir Arne ------_=_NextPart_001_01C651CB.46D17079 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Use case 1 has a generic waiting = room URI, where someone helps you into the right conference at the right time. =  Like many “in person” waiting rooms.  If SIP was the call = protocol, I would probably refresh the dialog.

 

If you are just waiting for the = conference moderator to arrive before the conference can start, you may not even = need a sidebar.  The media mixer could just show everybody audio, video or = text explaining why you wait.  More like a mixer = state.

 

Use case 2 can be solved by a = sidebar as long as the sidebar is not limited by the original conference objects properties. The limitations of the original conference object may be the = cause of the user’s problems in the first = place.

 

Geir = Arne

 

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: 27. mars 2006 = 18:24
To: 'Sean Olson'; 'Even, = Roni'; Geir Arne Sandbakken; 'XCON-IETF'
Subject: RE: [XCON] = Moving users between conferences

 

I’m with you that the first = two are probably sidebars, although the waiting room may not be; depends on = exactly what the wait room is.  If you get to it with a generic wait room = URI, then you select a conference (somehow) and then you are placed in the conference, then it’s move-between-conferences.  If you get = to it with the real conference URI, but you are “seated” in the = wait room for some reason, then it’s a sidebar.

 

I am also a bit skeptical of move-between-conferences.  Is this not a = “Refer/Replaces” operation; changing the URI of the conference?  If it’s not, = then you have the weird situation where the call state is to one conference, = with a URI, but you are actually in another conference, with a different URI.  If, for some reason, the UAC decided it needed to create a new = dialog, it’s not with the same URI as the original.  That sounds = pretty weird to me.

 

Brian

 

From: Sean = Olson [mailto:Sean.Olson@microsoft.com]
Sent: Monday, March 27, = 2006 11:10 AM
To: Even, Roni; Geir Arne Sandbakken; XCON-IETF
Subject: RE: [XCON] = Moving users between conferences

 

I would not implement the first as = a separate conference, but that is something that we could discuss more = when we define the sidebar operations. I can see the value of defining a move = user between conferences operation, though I'm a bit skeptical of the = architecture to enable such an operation. I guess I'd like to see a high level call = flow for how this would work.

 

From: Even, Roni [mailto:roni.even@polycom.co.il]
Sent: Monday, March 27, = 2006 7:24 AM
To: Sean Olson; Geir Arne Sandbakken; XCON-IETF
Subject: RE: [XCON] = Moving users between conferences

Sean,

Sidebar is a child of a conference = which is not the case here. For the first case there is no conference yet. I = agree that the second can be based on sidebar.

I think that I agree with Geir that = there is a need to move participants between conferences and not only from a conference to side bar and back

Roni

 

From: Sean = Olson [mailto:Sean.Olson@microsoft.com]
Sent: Monday, March 27, = 2006 5:17 PM
To: Geir Arne Sandbakken; XCON-IETF
Subject: RE: [XCON] = Moving users between conferences

 

I don't see why those two use cases = could not be handled by a sidebar.

 

From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net]
Sent: Monday, March 27, = 2006 4:30 AM
To: XCON-IETF
Subject: [XCON] Moving = users between conferences

Moving users between sidebars has been proposed, but = it would be nice to extend this for moving users between conferences as = well.  Having a “move” verb would be preferable, as a = “delete user” followed by “add user” can have the side effect = of disconnecting the user from the conference.

 

Two use cases:

1. Waiting room:  You call a waiting room where = someone controls when you can join a specific conference.  =

2. Help service:  An administrator can move a = user to another conference to help out with typical media problems, debugging or = other issues.  Then move the user back when it has been = resolved.

 

Geir Arne

------_=_NextPart_001_01C651CB.46D17079-- --===============0068974009== 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 --===============0068974009==-- From xcon-bounces@ietf.org Mon Mar 27 15:34:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNyPg-0000Hp-2L; Mon, 27 Mar 2006 15:34:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNyPf-0000Hk-7o for xcon@ietf.org; Mon, 27 Mar 2006 15:34:07 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNyPd-0007yJ-Vk for xcon@ietf.org; Mon, 27 Mar 2006 15:34:07 -0500 Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2RKY4bh096939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Mar 2006 14:34:05 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <44284C34.2090404@nostrum.com> Date: Mon, 27 Mar 2006 14:33:56 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Pietro Romano Subject: Re: [XCON] Minutes Posted References: <44241C21.8070804@nostrum.com> <1143222010.44242efa80976@webmail.unina.it> In-Reply-To: <1143222010.44242efa80976@webmail.unina.it> X-Enigmail-Version: 0.93.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: 9466e0365fc95844abaf7c3f15a05c7d 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 Thanks. The minutes have been updated. /a Simon Pietro Romano wrote: >Hi all, > >for the seek of completeness: > > > >>??:Mentioned existing standard WSRF from OASIS. SOAP would be nice one >> to use. Should take a look. >> >> > >"??" was Simon Romano, and the WSRF framework I was mentioning is at > >http://docs.oasis-open.org/wsrf/ > >Hope this helps. > >Cheers, > >Simon > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Mar 28 09:25:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOF82-00010T-IJ; Tue, 28 Mar 2006 09:25:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOF80-00010F-UV for xcon@ietf.org; Tue, 28 Mar 2006 09:25:00 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOF7z-0005Ev-EH for xcon@ietf.org; Tue, 28 Mar 2006 09:25:00 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id A0DC0194479 for ; Tue, 28 Mar 2006 16:24:58 +0200 (CEST) Received: from [192.168.1.15] ([192.168.1.15]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 16:23:14 +0200 In-Reply-To: <65F27F597EB1E44384BA802189D334C61CFA88@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> References: <65F27F597EB1E44384BA802189D334C61CFA88@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <6396ac09ad454f44fe668b85bee1affc@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [XCON] Moving users between conferences Date: Tue, 28 Mar 2006 16:24:25 +0200 To: "Sean Olson" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 28 Mar 2006 14:23:14.0622 (UTC) FILETIME=[266FDDE0:01C65273] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: XCON-IETF 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 Which is the sidebar and which is the main conference? Is the waiting=20 room the main conference and the rest are sidebars? I don't think so.=20 This to me looks like separate conferences where the user is=20 referred/transferred to another conference by an administrator (or key=20= participant or whatever the terminology is today :) ) Hisham On Mar 27, 2006, at 5:17 PM, Sean Olson wrote: > I don't see why those two use cases could not be handled by a sidebar. > > From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net] > Sent: Monday, March 27, 2006 4:30 AM > To: XCON-IETF > Subject: [XCON] Moving users between conferences > > Moving users between sidebars has been proposed, but it would be nice=20= > to extend this for moving users between conferences as well. =A0Having = a=20 > =93move=94 verb would be preferable, as a =93delete user=94 followed = by =93add=20 > user=94 can have the side effect of disconnecting the user from the=20 > conference. > =A0 > Two use cases: > 1. Waiting room:=A0 You call a waiting room where someone controls = when=20 > you can join a specific conference.=A0 > 2. Help service: =A0An administrator can move a user to another=20 > conference to help out with typical media problems, debugging or other=20= > issues.=A0 Then move the user back when it has been resolved. > =A0 > Geir Arne_______________________________________________ > 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 Mar 28 12:50:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOILJ-0000zc-1U; Tue, 28 Mar 2006 12:50:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOILH-0000zX-Qh for xcon@ietf.org; Tue, 28 Mar 2006 12:50:55 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOILG-0005io-Gx for xcon@ietf.org; Tue, 28 Mar 2006 12:50:55 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FOIL8-00079C-BB; Tue, 28 Mar 2006 11:50:46 -0600 From: "Brian Rosen" To: "'Hisham Khartabil'" , "'Sean Olson'" Subject: RE: [XCON] Moving users between conferences Date: Tue, 28 Mar 2006 12:50:48 -0500 Message-ID: <021801c65290$279e4590$b9201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZSc2XXj0/41691Sfi14rAYKqJsmwAHGR8w In-Reply-To: <6396ac09ad454f44fe668b85bee1affc@telio.no> X-PopBeforeSMTPSenders: br@brianrosen.net 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: f60d0f7806b0c40781eee6b9cd0b2135 Cc: 'XCON-IETF' X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org If you send an Invite to the main conference and everyone is kept in the waiting room, then it is the main conference, and you don't need any sidebar, and you don't need any "Move" operation. If only some people = are waiting (say, for authorization), then the waiting room is a sidebar of = the main conference. If you Invite to a waiting room, and then have to move to a conference, = as I said in a previous message, I think you need a REFER/Replaces to the = actual conference or things get too complicated to keep straight. Brian -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Tuesday, March 28, 2006 9:24 AM To: Sean Olson Cc: XCON-IETF Subject: Re: [XCON] Moving users between conferences Which is the sidebar and which is the main conference? Is the waiting=20 room the main conference and the rest are sidebars? I don't think so.=20 This to me looks like separate conferences where the user is=20 referred/transferred to another conference by an administrator (or key=20 participant or whatever the terminology is today :) ) Hisham On Mar 27, 2006, at 5:17 PM, Sean Olson wrote: > I don't see why those two use cases could not be handled by a sidebar. > > From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net] > Sent: Monday, March 27, 2006 4:30 AM > To: XCON-IETF > Subject: [XCON] Moving users between conferences > > Moving users between sidebars has been proposed, but it would be nice=20 > to extend this for moving users between conferences as well. =A0Having = a=20 > =93move=94 verb would be preferable, as a =93delete user=94 followed = by =93add=20 > user=94 can have the side effect of disconnecting the user from the=20 > conference. > =A0 > Two use cases: > 1. Waiting room:=A0 You call a waiting room where someone controls = when=20 > you can join a specific conference.=A0 > 2. Help service: =A0An administrator can move a user to another=20 > conference to help out with typical media problems, debugging or other = > issues.=A0 Then move the user back when it has been resolved. > =A0 > Geir Arne_______________________________________________ > 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 Tue Mar 28 13:03:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOIXJ-0007Qs-Gp; Tue, 28 Mar 2006 13:03:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOIXI-0007Qn-4s for xcon@ietf.org; Tue, 28 Mar 2006 13:03:20 -0500 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 1FOHvK-0004V2-Cl for xcon@ietf.org; Tue, 28 Mar 2006 12:24:06 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FOHgm-0003Jx-Ok for xcon@ietf.org; Tue, 28 Mar 2006 12:09:06 -0500 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 28 Mar 2006 09:09:03 -0800 Received: from tuk-hub-01.redmond.corp.microsoft.com ([157.54.70.27]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 09:09:03 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 09:09:02 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 09:09:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Moving users between conferences Date: Tue, 28 Mar 2006 09:09:01 -0800 Message-ID: <65F27F597EB1E44384BA802189D334C61D028B@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6396ac09ad454f44fe668b85bee1affc@telio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Moving users between conferences Thread-Index: AcZSc2Nku8JMoOmyQRGoDX/vXf7ibAAFqmjA From: "Sean Olson" To: "Hisham Khartabil" X-OriginalArrivalTime: 28 Mar 2006 17:09:02.0398 (UTC) FILETIME=[4FC605E0:01C6528A] X-Spam-Score: -2.6 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org The waiting room would obviously be a sidebar of the main conference. = This has benefits from the point of view of resource management, = permissions, isolation, etc. =20 -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Tuesday, March 28, 2006 6:24 AM To: Sean Olson Cc: XCON-IETF; Geir Arne Sandbakken Subject: Re: [XCON] Moving users between conferences Which is the sidebar and which is the main conference? Is the waiting = room the main conference and the rest are sidebars? I don't think so.=20 This to me looks like separate conferences where the user is = referred/transferred to another conference by an administrator (or key = participant or whatever the terminology is today :) ) Hisham On Mar 27, 2006, at 5:17 PM, Sean Olson wrote: > I don't see why those two use cases could not be handled by a sidebar. > > From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net] > Sent: Monday, March 27, 2006 4:30 AM > To: XCON-IETF > Subject: [XCON] Moving users between conferences > > Moving users between sidebars has been proposed, but it would be nice=20 > to extend this for moving users between conferences as well. =A0Having = a=20 > "move" verb would be preferable, as a "delete user" followed by "add=20 > user" can have the side effect of disconnecting the user from the=20 > conference. > =A0 > Two use cases: > 1. Waiting room:=A0 You call a waiting room where someone controls = when=20 > you can join a specific conference. > 2. Help service: =A0An administrator can move a user to another=20 > conference to help out with typical media problems, debugging or other = > issues.=A0 Then move the user back when it has been resolved. > =A0 > Geir Arne_______________________________________________ > 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 Mar 29 02:53:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVUz-0006cY-G8; Wed, 29 Mar 2006 02:53:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVUy-0006cB-8B for xcon@ietf.org; Wed, 29 Mar 2006 02:53:48 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOVUr-000786-Md for xcon@ietf.org; Wed, 29 Mar 2006 02:53:48 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id ED60C19446E for ; Wed, 29 Mar 2006 09:53:40 +0200 (CEST) Received: from [192.168.1.18] ([192.168.1.18]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Mar 2006 09:51:56 +0200 In-Reply-To: <65F27F597EB1E44384BA802189D334C61D028B@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> References: <65F27F597EB1E44384BA802189D334C61D028B@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7d250de7b35d69447249e108e53cf3cb@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [XCON] Moving users between conferences Date: Wed, 29 Mar 2006 09:53:09 +0200 To: "Sean Olson" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 29 Mar 2006 07:51:56.0002 (UTC) FILETIME=[A6808420:01C65305] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org The waiting room is a sidebar of multiple conferences? Now I'm confused=20= how that would work :) Hisham On Mar 28, 2006, at 7:09 PM, Sean Olson wrote: > The waiting room would obviously be a sidebar of the main conference.=20= > This has benefits from the point of view of resource management,=20 > permissions, isolation, etc. > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Tuesday, March 28, 2006 6:24 AM > To: Sean Olson > Cc: XCON-IETF; Geir Arne Sandbakken > Subject: Re: [XCON] Moving users between conferences > > Which is the sidebar and which is the main conference? Is the waiting=20= > room the main conference and the rest are sidebars? I don't think so. > This to me looks like separate conferences where the user is=20 > referred/transferred to another conference by an administrator (or key=20= > participant or whatever the terminology is today :) ) > > Hisham > > On Mar 27, 2006, at 5:17 PM, Sean Olson wrote: > >> I don't see why those two use cases could not be handled by a = sidebar. >> >> From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net] >> Sent: Monday, March 27, 2006 4:30 AM >> To: XCON-IETF >> Subject: [XCON] Moving users between conferences >> >> Moving users between sidebars has been proposed, but it would be nice >> to extend this for moving users between conferences as well. =A0Having = a >> "move" verb would be preferable, as a "delete user" followed by "add >> user" can have the side effect of disconnecting the user from the >> conference. >> =A0 >> Two use cases: >> 1. Waiting room:=A0 You call a waiting room where someone controls = when >> you can join a specific conference. >> 2. Help service: =A0An administrator can move a user to another >> conference to help out with typical media problems, debugging or = other >> issues.=A0 Then move the user back when it has been resolved. >> =A0 >> Geir Arne_______________________________________________ >> 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 Mar 29 05:20:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOXms-0002Te-4j; Wed, 29 Mar 2006 05:20:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOXmp-0002TU-VF for xcon@ietf.org; Wed, 29 Mar 2006 05:20:23 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOXmn-0005nb-R1 for xcon@ietf.org; Wed, 29 Mar 2006 05:20:23 -0500 Received: from rly08b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly08b.srv.mailcontrol.com (MailControl) with ESMTP id k2TAKFP9019647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Mar 2006 11:20:19 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly08b.srv.mailcontrol.com (MailControl) id k2TAJo7b018917 for xcon@ietf.org; Wed, 29 Mar 2006 11:19:50 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly08b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k2TAJljv018858; Wed, 29 Mar 2006 11:19:50 +0100 (BST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Moving users between conferences Date: Wed, 29 Mar 2006 11:19:47 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE031189A6@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Moving users between conferences Thread-Index: AcZRmh1VMHsf2eroSECiQyIxY47qPgAF1aUQAAAMe5AAAbnv8AAAaqAAAFfUi+A= From: "Chris Boulton" To: , "Sean Olson" , "Even, Roni" , "Geir Arne Sandbakken" , "XCON-IETF" X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.66.1.118 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b157e6e8a3799aef911c0bc37fc93a6 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: , Content-Type: multipart/mixed; boundary="===============1835801098==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1835801098== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6531A.4E948B40" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6531A.4E948B40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are we maybe delving a little too deeply into implementation specific operations? This just seems to me to be managing varying conference/sidebar instances + as Brian has already pointed out - managing the SIP dialogs using the appropriate SIP signaling. I always imagined that the protocol would reside at the Conference instance level - anything higher seems to be out of scope (unless I have miss-understood requirements). =20 Chris. =20 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 27 March 2006 17:24 To: 'Sean Olson'; 'Even, Roni'; 'Geir Arne Sandbakken'; 'XCON-IETF' Subject: RE: [XCON] Moving users between conferences =20 I'm with you that the first two are probably sidebars, although the waiting room may not be; depends on exactly what the wait room is. If you get to it with a generic wait room URI, then you select a conference (somehow) and then you are placed in the conference, then it's move-between-conferences. If you get to it with the real conference URI, but you are "seated" in the wait room for some reason, then it's a sidebar. =20 I am also a bit skeptical of move-between-conferences. Is this not a "Refer/Replaces" operation; changing the URI of the conference? If it's not, then you have the weird situation where the call state is to one conference, with a URI, but you are actually in another conference, with a different URI. If, for some reason, the UAC decided it needed to create a new dialog, it's not with the same URI as the original. That sounds pretty weird to me. =20 Brian =20 _____=20=20 From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: Monday, March 27, 2006 11:10 AM To: Even, Roni; Geir Arne Sandbakken; XCON-IETF Subject: RE: [XCON] Moving users between conferences =20 I would not implement the first as a separate conference, but that is something that we could discuss more when we define the sidebar operations. I can see the value of defining a move user between conferences operation, though I'm a bit skeptical of the architecture to enable such an operation. I guess I'd like to see a high level call flow for how this would work. =20 _____=20=20 From: Even, Roni [mailto:roni.even@polycom.co.il]=20 Sent: Monday, March 27, 2006 7:24 AM To: Sean Olson; Geir Arne Sandbakken; XCON-IETF Subject: RE: [XCON] Moving users between conferences Sean, Sidebar is a child of a conference which is not the case here. For the first case there is no conference yet. I agree that the second can be based on sidebar. I think that I agree with Geir that there is a need to move participants between conferences and not only from a conference to side bar and back Roni =20 _____=20=20 From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: Monday, March 27, 2006 5:17 PM To: Geir Arne Sandbakken; XCON-IETF Subject: RE: [XCON] Moving users between conferences =20 I don't see why those two use cases could not be handled by a sidebar. =20 _____=20=20 From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net]=20 Sent: Monday, March 27, 2006 4:30 AM To: XCON-IETF Subject: [XCON] Moving users between conferences Moving users between sidebars has been proposed, but it would be nice to extend this for moving users between conferences as well. Having a "move" verb would be preferable, as a "delete user" followed by "add user" can have the side effect of disconnecting the user from the conference. =20 Two use cases: 1. Waiting room: You call a waiting room where someone controls when you can join a specific conference.=20=20 2. Help service: An administrator can move a user to another conference to help out with typical media problems, debugging or other issues. Then move the user back when it has been resolved. =20 Geir Arne 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_01C6531A.4E948B40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are we maybe delving a little too deep= ly into implementation specific operations?  This just seems to me to be managing varying conference/sidebar instances + as Brian has already pointed out – managing the SIP dialogs using the appropriate SIP signaling.&n= bsp; I always imagined that the protocol would reside at the Conference instance level – anything higher seems to be out of scope (unless I have miss-understood requirements).

 

Chris.

 

 

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: 27 March 2006 17:24
To: 'Sean Olson'; 'Even, Ron= i'; 'Geir Arne Sandbakken'; 'XCON-IETF'
Subject: RE: [XCON] Moving u= sers between conferences

 

= I’m with you that the first two are probably sidebars, although the waiting room may not be; depends on exactly what the wait room is.  If you get to it with a generic wait room URI, then you select a conference (somehow) and th= en you are placed in the conference, then it’s move-between-conferences.  If you get to it with the real conference URI, but you are “sea= ted” in the wait room for some reason, then it’s a sidebar.<= /p>

=  

= I am also a bit skeptical of move-between-conferences.  Is this not a “Refer/Replaces” operation; changing the URI of the conference?  If it’s not, then you have the weird situation where the call state is to one conference, with a URI, but you are actually in another conference, with a different URI.  If, for some reason, the UAC decided it needed to create a new dialog, it’s not with the same URI = as the original.  That sounds pretty weird to me.

=  

= Brian

=  

From:= = Sean Olson [mailto:Sean.Olson@microsoft.com]
Sent: Monday, March 27, 2006= 11:10 AM
To: Even, Roni; Geir Arne Sandbakken; XCON-IETF
Subject: RE: [XCON] Moving u= sers between conferences

 

= I would not implement the first as a separate conference, but that is something tha= t we could discuss more when we define the sidebar operations. I can see the val= ue of defining a move user between conferences operation, though I'm a bit skeptical of the architecture to enable such an operation. I guess I'd like= to see a high level call flow for how this would work.

 

From: Even, Roni [mailto:roni.even@polycom.co.il]
Sent: Monday, March 27, 2006= 7:24 AM
To: Sean Olson; Geir Arne Sandbakken; XCON-IETF
Subject: RE: [XCON] Moving u= sers between conferences

= Sean,

= Sidebar is a child of a conference which is not the case here. For the first case t= here is no conference yet. I agree that the second can be based on sidebar.

= I think that I agree with Geir that there is a need to move participants between conferences and not only from a conference to side bar and back

= Roni

=  

From:= = Sean Olson [mailto:Sean.Olson@microsoft.com]
Sent: Monday, March 27, 2006= 5:17 PM
To: Geir Arne Sandbakken; XCON-IETF
Subject: RE: [XCON] Moving u= sers between conferences

 

= I don't see why those two use cases could not be handled by a sidebar.

 

From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.net]
Sent: Monday, March 27, 2006= 4:30 AM
To: XCON-IETF
Subject: [XCON] Moving users between conferences

Moving users between sidebars = has been proposed, but it would be nice to extend this for moving users between conferences as well.  Having a “move” verb would be preferable, as a “delete user” followed by “add user̶= 1; can have the side effect of disconnecting the user from the conference.

 

Two use cases:

1. Waiting room:  You cal= l a waiting room where someone controls when you can join a specific conference. 

2. Help service:  An administrator can move a user to another conference to help out with typica= l media problems, debugging or other issues.  Then move the user back when it = has been resolved.

 

Geir Arne



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_01C6531A.4E948B40-- --===============1835801098== 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 --===============1835801098==-- X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NWGGL159; Wed, 2 Jul 2003 10:16:18 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h62EDZXm011343; Wed, 2 Jul 2003 10:13:40 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h62EFh26007341; Wed, 2 Jul 2003 09:15:44 -0500 Received: from radvpost.radvision.com (radvmail.radvision.com [12.44.63.10]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h62EFe25007338 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 2 Jul 2003 09:15:41 -0500 Received: from radvpost.RADVISION.com [192.168.216.29] by radvpost.radvision.com with XWall v3.26 ; Wed, 2 Jul 2003 10:14:24 -0400 Received: by radvpost.RADVISION.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jul 2003 10:14:24 -0400 Message-ID: From: Orit Levin To: "'Eunsook Kim'" , hisham.khartabil@nokia.com, petri.koskelainen@nokia.com Subject: RE: [XCON] Conference Policy Control -comments on draft-koskelai nen-xcon-xcap-cpcp-usage-00 Date: Wed, 2 Jul 2003 10:14:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset=windows-1252; format=flowed Cc: xcon@softarmor.com, Markus.Isomaki@nokia.com X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Content-transfer-encoding: 8bit My responses are inline. Orit. > -----Original Message----- > From: Eunsook Kim [mailto:eunah@etri.re.kr] > Sent: Wednesday, July 02, 2003 1:57 AM > To: hisham.khartabil@nokia.com; petri.koskelainen@nokia.com > Cc: xcon@softarmor.com; Markus.Isomaki@nokia.com > Subject: Re: [XCON] Conference Policy Control -comments on draft- > koskelainen-xcon-xcap-cpcp-usage-00 > ...skip > > Second, I have a few questions on your document as following: > > 1. Your document is mentioning that CPS lets Focus know the Dial-out List, > and then Focus send INVITE to the members in the list, > and CPS also have the FOCUS to send BYE when there is a BLOCKED > member. > However, there is no explanation of HOW the CPS carries the > information to the Focus. > I know they are logical entities, but I don't think CPS and Focus are > always configutated in local system. > So, I think they need a way to communicate each other. > Is this the out of scope of the XCON work? Or, do you remain this work > as future work? > According to the Conference Design team discussions, the communications between CPS and the focus is out of scope of XCON and is a matter of implementation. > 2. I think we need a field for describing media (or codec) information > when a client requests a conference creation. > I DON'T mean the negotiation of media. The preference of the client > should be considered, I think. > Is the "Conference-media-policy" which is not yet defined for this > purpose? I agree very much. Please, also see http://www.ietf.org/internet-drafts/draft-levin-xcon-cpcp-00.txt. Specifically: ... TBD by MPCP ... and "Functions and Issues Still to be Addressed": Coordination between CPCP and Media Policy Control Protocol (MPCP) hasn't been addressed yet. Some of the operations will require joined execution of CPCP and MPCP primitives in a single "atomic" operation. > > 3. This can be minor in the moment, but .......; > You defined "Conference-URI", the sub-element of "Conference" as a > required element, and > "SIP-URI", the sub-element of the "Conference-URI" is also defined as > a required element. > However, the conferencing framework document ,and also your document > are describing > CPS can create the conference URI. In addition, your document mentions > the conference URI can be > SIP, SIPS, or TEL URI. > Based on the describtions, I think it is definitely needed to define, > but should not be defined as a required one. > Right. The CPCP is orthogonal to the signaling protocol(s) to be used between the focus and its participants. The Conference-URI definition and the CPCP mechanism should support participation of users, which run different signaling protocols, in the same conference. > > I'll appreciate your response. > > Sincerely, > Eunah > > ----- Original Message ----- > From: > To: ; > Cc: ; ; > ; > Sent: Tuesday, July 01, 2003 10:35 PM > Subject: RE: [XCON] Conference Policy Control -comments on draft- > koskelainen-xcon-xcap-cpcp-usage-00 > > > > Hi Eunah, > > > > Thanks for the comments and corrections. Your modifications will be > taken into consideration. > > > > We actually have not put the schema into a validator yet due to time > constraints, but will do as soon as possible. We felt that the XML > validity is not a big issue now, but the community accepting the idea was. > > > > Anyhow, the next version will hopefully have a valid XML schema. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext Eunsook Kim [mailto:eunah@pec.etri.re.kr] > > > Sent: Tuesday, July 01, 2003 3:23 PM > > > To: Koskelainen Petri (NRC/Tampere); Khartabil Hisham (NMP/Helsinki) > > > Cc: xiaotaow@cs.columbia.edu; Isomaki Markus (NRC/Helsinki); > > > jhyiee@etri.re.kr; xcon@softarmor.com > > > Subject: Re: [XCON] Conference Policy Control -comments on > > > draft-koskelainen-xcon-xcap-cpcp-usage-00 > > > > > > > > > Hi Petri, and Hisham > > > > > > I went over XCAP and the related documents and admit that it > > > gives simple and light method to manipulate conference policy. :-) > > > I also have looked over your document and the defined XML > > > schema, and found a lot of syntax errors and several schema > > > validation errors. > > > I tried to correct them, and attach the schema file, which I > > > get the successful validation message by running it into the XMLSPY. > > > Currently, I changed or added some of definition to get a > > > valid schema. > > > I tried to read your intention as possible as I can, but > > > please let me know if the corrections doesn't carry well on > > > your intention. > > > > > > ----------------- > > > The brief note of the errors is as following: > > > > > > 1. Namespace should be defined for 'conference-policy' in > > > order to reuse types and elements defined in the document. > > > > > > [[Syntax errors]] > > > > > > 2. Comment type should be instead > > > > > > 3. There are many cases where definitions are unappropriately > > > ended. I cannot list all of them here; give an example: > > > > > > > > > > > > > > > > > > > > > > > > 4.And, there are some mismatched or missed or redundant end tags. > > > ex) > > > > > > > > > > > name="SIP-URI" type="xsd:anyURI" use="required"/> > > > .......... > > > (some elements) > > > > > > > > > > > > > > > > > > [[Unvalid Schema Definition Errors]] > > > > > > 5. You use [use="required"] severral times in definition of > > > elements, which is not appropriate. minOccurs="1" can be > > > used, instead. > > > > > > 6. in your definition) > > > > > > > > value="TLS" type="xsd:boolean" default="false"/> > > > > > value="S-MIME" type="xsd:boolean" default="false"/> > > > > > > > > > > > > I got an error indicating unappropriate use of "value" in > > > attribute; > > > I got the validation error in the following definition. I > > > defined the type of Security-mechanism, and reuse it for the > > > definition. > > > Please let me know if it is different from your intention. > > > Then, I'll correct it as your intention. > > > > > > > > > 7. > > > > > > > > > > > > > > > > > > > > type="xsd:string"/> > > > > > > > > > I got an error indicating wrong use of "restrction" > > > based enumeration value in a complexType. > > > I tried to define the type of Authorixation-type for the > > > enumeration values. > > > > > > > > > 8. > > > > > > > > > > > name="ACL-target-URI" type="xsd:anyURI" use="required" minOccurs="1" > > > > > > MaxOccurs="unbounded"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Over the definition, the closed tag of "ACL-target-URI" > > > element followed by MaxOccurs="unbounded" is not correct here, right? > > > I guess you'd like to make ACL-target-URI have an > > > attribute, am I correct? > > > Anyway, I got an error indicating unappropriate use of > > > attribute here, so I changed "ACL" element to the form of > > > "PCL" and "DL" in this moment, but it is not your intention, > > > please let me know. > > > > > > ------------------ > > > > > > I hope this will be helpful. > > > > > > Sincerely, > > > Eunah > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: petri.koskelainen@nokia.com > > > > To: eunah@pec.etri.re.kr ; hisham.khartabil@nokia.com > > > > Cc: xiaotaow@cs.columbia.edu ; Markus.Isomaki@nokia.com ; > > > jhyiee@etri.re.kr > > > > Sent: Friday, June 27, 2003 10:51 PM > > > > Subject: RE: [XCON] Conference Policy Control > > > > > > > > > > > > Hi Eunah, > > > > > > > > Thanks for the input. CPCP is very different from floor > > > control so we don't need to have same protocol > > > > for these (besides, XCAP is already used for presence-list > > > manipulation which is similar to conf policy manipulation etc). > > > > > > > > If you can provide input to CPCP (e.g. what parameters > > > should be included in the policy, or finding errors in XML Schema) > > > > that would be highly appreciated. > > > > > > > > Thanks, > > > > Petri > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: ext Eunsook Kim [mailto:eunah@pec.etri.re.kr] > > > >>Sent: 27 June, 2003 16:44 > > > >>To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri (NRC/Tampere) > > > >>Cc: xiaotaow@cs.columbia.edu; Isomaki Markus (NRC/Helsinki); JongHwa > > > >>Subject: Re: [XCON] Conference Policy Control > > > >> > > > >> > > > >>Hisham, > > > >> > > > >>Thanks a lot for your response. > > > >> > > > >>I've chosen SOAP for acessing server elements of conference > > > policy control, because it is a well-known standardized protocol. > > > >>Besides, I believe there is a close relationship between > > > conference policy and floor controls, and I think that it > > > would be good for the two >>mechanisms to use the same protocol. > > > >>As you know, Xioatao and Petri have already proposed a > > > floor control draft using SOAP, > > > >>so, I've prototyped a few basic functions of policy control > > > using SOAP, and wrote my draft. > > > >>However, SOAP is just one of the methods to allow client to > > > access policy server information, and > > > >>I'm willing to do it by using XCAP, too > > > >> > > > >>I think, the main focus of this work is not if it should > > > be SOAP or XCAP. > > > >>In my opinion, it is more important to design well-formed > > > schema for policy control operations which can be > > > standardized, and I think the >>conference design team has > > > been doing very good job in this point of view. And, as the > > > one who is very interested in and working on this area, >>I'm > > > very happy to hear the XCON bof announcement, and I'll be > > > very happy if I can help or contribute some parts on the > > > works of design team. > > > >> > > > >>I'll go over all the XCON drafts again, and I would like to > > > discuss on this topic with you more in the mailing list, if > > > you'd like to. > > > >> > > > >>I appreciate your response again. > > > >> > > > >>Yours faithfully, Eunah > > > >> > > > >> > > > >> > > > >>>----- Original Message ----- > > > >>>From: hisham.khartabil@nokia.com > > > >>>To: eunah@pec.etri.re.kr ; petri.koskelainen@nokia.com > > > >>>Cc: xiaotaow@cs.columbia.edu ; Markus.Isomaki@nokia.com > > > >>>Sent: Friday, June 27, 2003 3:24 PM > > > >>>Subject: RE: [XCON] Conference Policy Control > > > >>> > > > >>> > > > >>>Eunah, > > > >>> > > > >>>We appreciate your enthusiasm about the conferencing work. > > > >>> > > > >>>Your proposal so makes use of SOAP as a solution. To be > > > honest, our interest in SOAP as a solution for conference > > > policy protocol is very >>>minimal. That's why we chose XCAP, > > > its simple and much lighter to implement than SOAP. > > > >>> > > > >>>If you feel that your proposal is the superior one, please > > > feel free to involve yourself in the soon newly formed IETF > > > working group, named >>>XCON, specifically designed to > > > produce such conferencing protocols. The conferencing work so > > > far has been done in a closed design team >>>where the XCAP > > > has so far been well accepted as the conference policy solution. > > > >>> > > > >>>Much appreciated, > > > >>>Hisham > > > > > > > > > > > > > > > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NWGGL1Z2; Wed, 2 Jul 2003 09:57:29 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h62DsnXm011277; Wed, 2 Jul 2003 09:54:51 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h62Duw26007204; Wed, 2 Jul 2003 08:56:59 -0500 Received: from radvpost.radvision.com (radvmail.radvision.com [12.44.63.10]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h62Dut25007201 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 2 Jul 2003 08:56:57 -0500 Received: from radvpost.radvision.com [192.168.216.29] by radvpost.radvision.com with XWall v3.26 ; Wed, 2 Jul 2003 09:55:38 -0400 Received: by radvpost.RADVISION.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jul 2003 09:55:38 -0400 Message-ID: From: Orit Levin To: xcon@softarmor.com Date: Wed, 2 Jul 2003 09:55:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset=windows-1252; format=flowed Subject: [XCON] Control vs. Description protocol X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Content-transfer-encoding: 8bit Hi! I would like to bring to the discussion my concern about designing the CPCP as a protocol around editing files (that describe the conferences). In my opinion the CPCP needs to be a CONTROL protocol in addition to being just a "Conference Description Protocol". Below are some of the arguments to support this point of view: 2. CPCP is a protocol to be designed MOSTLY for the benefit of the end users. (Operators may have other, not necessarily standard, means.) As a result, a user must be able to get/modify/etc. his own view of the conference or his position in the conference without being (necessarily) exposed to the general conference view. 1. Each communication with the CPS needs to be short and effective. Non-default conference creation is the only exception, may be. Even so, means should be defined to make it as effective as possible: such as using conference profiles. What would be your thoughts? Orit Levin Chief Architect RADVISION Phone: +1.201.6896330 Video: +1.201.6896430 > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, July 02, 2003 2:48 AM > To: eunah@etri.re.kr; petri.koskelainen@nokia.com > Cc: xcon@softarmor.com; Markus.Isomaki@nokia.com > Subject: RE: [XCON] Conference Policy Control -comments on draft- > koskelainen-xcon-xcap-cpcp-usage-00 > > > > > -----Original Message----- > > From: ext Eunsook Kim [mailto:eunah@etri.re.kr] > > Sent: Wednesday, July 02, 2003 8:57 AM > > To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri (NRC/Tampere) > > Cc: xiaotaow@cs.columbia.edu; Isomaki Markus (NRC/Helsinki); > > jhyiee@etri.re.kr; xcon@softarmor.com > > Subject: Re: [XCON] Conference Policy Control -comments on > > draft-koskelainen-xcon-xcap-cpcp-usage-00 > > > > > > Hi Hisham, > > > > First of all, I'd like to say that I've been also thinking > > the importance of your document is the idea in this momont. > > I don't think I misunderstand this point. > > I did the validation work because I think a valid schema > > would increase the readibility. > > (Because of the not-wellformed schema, I had some trouble > > when I tried to look over > > if the schema was well delivering your idea. So, I did the > > validation work, first.) > > > > Second, I have a few questions on your document as following: > > > > 1. Your document is mentioning that CPS lets Focus know the > > Dial-out List, and then Focus send INVITE to the members in the list, > > and CPS also have the FOCUS to send BYE when there is a > > BLOCKED member. > > However, there is no explanation of HOW the CPS carries > > the information to the Focus. > > I know they are logical entities, but I don't think CPS > > and Focus are always configutated in local system. > > So, I think they need a way to communicate each other. > > Is this the out of scope of the XCON work? Or, do you > > remain this work as future work? > > It was deliberately left out. I guess this is a questions for the chairs > to answer. > > > > > 2. I think we need a field for describing media (or codec) > > information when a client requests a conference creation. > > I DON'T mean the negotiation of media. The preference of > > the client should be considered, I think. > > Is the "Conference-media-policy" which is not yet defined > > for this purpose? > > The dialog and media negotiation is between the CPS (focus) and the > participants. Why would the creator care what codecs the other > participants use between them and the focus? > > In any case, you can read more about media policy in this draft (although > I don't think codec preference is part of it: > > http://www.ietf.org/internet-drafts/draft-mahy-xcon-media-policy-control- > 00.txt > > The author has been looking into XCAP for this as well. > > > > > > > 3. This can be minor in the moment, but .......; > > You defined "Conference-URI", the sub-element of > > "Conference" as a required element, and > > "SIP-URI", the sub-element of the "Conference-URI" is > > also defined as a required element. > > However, the conferencing framework document ,and also > > your document are describing > > CPS can create the conference URI. In addition, your > > document mentions the conference URI can be > > SIP, SIPS, or TEL URI. > > Based on the describtions, I think it is definitely > > needed to define, but should not be defined as a required one. > > It is required since without it, the conference cannot be addressed. The > creator includes it, even though empty, as a way of indicating that it > deliberately left it out for the server to fill in (not a mistake). Maybe > others have a better answer. > > Thanks for the interest in this work > > Regards, > Hisham > > > > > > I'll appreciate your response. > > > > Sincerely, > > Eunah > > > > ----- Original Message ----- > > From: > > To: ; > > Cc: ; ; > > ; > > Sent: Tuesday, July 01, 2003 10:35 PM > > Subject: RE: [XCON] Conference Policy Control -comments on > > draft-koskelainen-xcon-xcap-cpcp-usage-00 > > > > > > > Hi Eunah, > > > > > > Thanks for the comments and corrections. Your modifications > > will be taken into consideration. > > > > > > We actually have not put the schema into a validator yet > > due to time constraints, but will do as soon as possible. We > > felt that the XML validity is not a big issue now, but the > > community accepting the idea was. > > > > > > Anyhow, the next version will hopefully have a valid XML schema. > > > > > > Regards, > > > Hisham > > > > > > > -----Original Message----- > > > > From: ext Eunsook Kim [mailto:eunah@pec.etri.re.kr] > > > > Sent: Tuesday, July 01, 2003 3:23 PM > > > > To: Koskelainen Petri (NRC/Tampere); Khartabil Hisham > > (NMP/Helsinki) > > > > Cc: xiaotaow@cs.columbia.edu; Isomaki Markus (NRC/Helsinki); > > > > jhyiee@etri.re.kr; xcon@softarmor.com > > > > Subject: Re: [XCON] Conference Policy Control -comments on > > > > draft-koskelainen-xcon-xcap-cpcp-usage-00 > > > > > > > > > > > > Hi Petri, and Hisham > > > > > > > > I went over XCAP and the related documents and admit that it > > > > gives simple and light method to manipulate conference policy. :-) > > > > I also have looked over your document and the defined XML > > > > schema, and found a lot of syntax errors and several schema > > > > validation errors. > > > > I tried to correct them, and attach the schema file, which I > > > > get the successful validation message by running it into > > the XMLSPY. > > > > Currently, I changed or added some of definition to get a > > > > valid schema. > > > > I tried to read your intention as possible as I can, but > > > > please let me know if the corrections doesn't carry well on > > > > your intention. > > > > > > > > ----------------- > > > > The brief note of the errors is as following: > > > > > > > > 1. Namespace should be defined for 'conference-policy' in > > > > order to reuse types and elements defined in the document. > > > > > > > > [[Syntax errors]] > > > > > > > > 2. Comment type should be instead > > > > > > > > 3. There are many cases where definitions are unappropriately > > > > ended. I cannot list all of them here; give an example: > > > > > > > > > > > > > > > > > value="invisible"/> > > > > > > > > > > > > > > > > 4.And, there are some mismatched or missed or redundant end tags. > > > > ex) > > > > > > > > > > > > > > > name="SIP-URI" type="xsd:anyURI" use="required"/> > > > > .......... > > > > (some elements) > > > > > > > > > > > > > > > > > > > > > > > > [[Unvalid Schema Definition Errors]] > > > > > > > > 5. You use [use="required"] severral times in definition of > > > > elements, which is not appropriate. minOccurs="1" can be > > > > used, instead. > > > > > > > > 6. in your definition) > name="Security-mechanism"> > > > > > > > > > > > value="TLS" type="xsd:boolean" default="false"/> > > > > > > > value="S-MIME" type="xsd:boolean" default="false"/> > > > > > > > > > > > > > > > > I got an error indicating unappropriate use of "value" in > > > > attribute; > > > > I got the validation error in the following definition. I > > > > defined the type of Security-mechanism, and reuse it for the > > > > definition. > > > > Please let me know if it is different from your intention. > > > > Then, I'll correct it as your intention. > > > > > > > > > > > > 7. > > > > > > > > > > > > > > > > > > > > > > > > > > > type="xsd:string"/> > > > > > > > > > > > > I got an error indicating wrong use of "restrction" > > > > based enumeration value in a complexType. > > > > I tried to define the type of Authorixation-type for the > > > > enumeration values. > > > > > > > > > > > > 8. > > > > > > > > > > > > > > > name="ACL-target-URI" type="xsd:anyURI" use="required" > > minOccurs="1" > > > > > > > > MaxOccurs="unbounded"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Over the definition, the closed tag of "ACL-target-URI" > > > > element followed by MaxOccurs="unbounded" is not correct > > here, right? > > > > I guess you'd like to make ACL-target-URI have an > > > > attribute, am I correct? > > > > Anyway, I got an error indicating unappropriate use of > > > > attribute here, so I changed "ACL" element to the form of > > > > "PCL" and "DL" in this moment, but it is not your intention, > > > > please let me know. > > > > > > > > ------------------ > > > > > > > > I hope this will be helpful. > > > > > > > > Sincerely, > > > > Eunah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: petri.koskelainen@nokia.com > > > > > To: eunah@pec.etri.re.kr ; hisham.khartabil@nokia.com > > > > > Cc: xiaotaow@cs.columbia.edu ; Markus.Isomaki@nokia.com ; > > > > jhyiee@etri.re.kr > > > > > Sent: Friday, June 27, 2003 10:51 PM > > > > > Subject: RE: [XCON] Conference Policy Control > > > > > > > > > > > > > > > Hi Eunah, > > > > > > > > > > Thanks for the input. CPCP is very different from floor > > > > control so we don't need to have same protocol > > > > > for these (besides, XCAP is already used for presence-list > > > > manipulation which is similar to conf policy manipulation etc). > > > > > > > > > > If you can provide input to CPCP (e.g. what parameters > > > > should be included in the policy, or finding errors in > > XML Schema) > > > > > that would be highly appreciated. > > > > > > > > > > Thanks, > > > > > Petri > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > > > >>From: ext Eunsook Kim [mailto:eunah@pec.etri.re.kr] > > > > >>Sent: 27 June, 2003 16:44 > > > > >>To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri > > (NRC/Tampere) > > > > >>Cc: xiaotaow@cs.columbia.edu; Isomaki Markus > > (NRC/Helsinki); JongHwa > > > > >>Subject: Re: [XCON] Conference Policy Control > > > > >> > > > > >> > > > > >>Hisham, > > > > >> > > > > >>Thanks a lot for your response. > > > > >> > > > > >>I've chosen SOAP for acessing server elements of conference > > > > policy control, because it is a well-known standardized > > protocol. > > > > >>Besides, I believe there is a close relationship between > > > > conference policy and floor controls, and I think that it > > > > would be good for the two >>mechanisms to use the same protocol. > > > > >>As you know, Xioatao and Petri have already proposed a > > > > floor control draft using SOAP, > > > > >>so, I've prototyped a few basic functions of policy control > > > > using SOAP, and wrote my draft. > > > > >>However, SOAP is just one of the methods to allow client to > > > > access policy server information, and > > > > >>I'm willing to do it by using XCAP, too > > > > >> > > > > >>I think, the main focus of this work is not if it should > > > > be SOAP or XCAP. > > > > >>In my opinion, it is more important to design well-formed > > > > schema for policy control operations which can be > > > > standardized, and I think the >>conference design team has > > > > been doing very good job in this point of view. And, as the > > > > one who is very interested in and working on this area, >>I'm > > > > very happy to hear the XCON bof announcement, and I'll be > > > > very happy if I can help or contribute some parts on the > > > > works of design team. > > > > >> > > > > >>I'll go over all the XCON drafts again, and I would like to > > > > discuss on this topic with you more in the mailing list, if > > > > you'd like to. > > > > >> > > > > >>I appreciate your response again. > > > > >> > > > > >>Yours faithfully, Eunah > > > > >> > > > > >> > > > > >> > > > > >>>----- Original Message ----- > > > > >>>From: hisham.khartabil@nokia.com > > > > >>>To: eunah@pec.etri.re.kr ; petri.koskelainen@nokia.com > > > > >>>Cc: xiaotaow@cs.columbia.edu ; Markus.Isomaki@nokia.com > > > > >>>Sent: Friday, June 27, 2003 3:24 PM > > > > >>>Subject: RE: [XCON] Conference Policy Control > > > > >>> > > > > >>> > > > > >>>Eunah, > > > > >>> > > > > >>>We appreciate your enthusiasm about the conferencing work. > > > > >>> > > > > >>>Your proposal so makes use of SOAP as a solution. To be > > > > honest, our interest in SOAP as a solution for conference > > > > policy protocol is very >>>minimal. That's why we chose XCAP, > > > > its simple and much lighter to implement than SOAP. > > > > >>> > > > > >>>If you feel that your proposal is the superior one, please > > > > feel free to involve yourself in the soon newly formed IETF > > > > working group, named >>>XCON, specifically designed to > > > > produce such conferencing protocols. The conferencing work so > > > > far has been done in a closed design team >>>where the XCAP > > > > has so far been well accepted as the conference policy solution. > > > > >>> > > > > >>>Much appreciated, > > > > >>>Hisham > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQ281; Wed, 16 Jul 2003 08:06:50 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6GC492D012046; Wed, 16 Jul 2003 08:04:09 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GC6D2o003124; Wed, 16 Jul 2003 07:06:14 -0500 Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GAZa2m002701 for ; Wed, 16 Jul 2003 05:35:37 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6GAZXnx010998 for ; Wed, 16 Jul 2003 12:35:33 +0200 Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6GAZWrd284626 for ; Wed, 16 Jul 2003 12:35:33 +0200 To: xcon@softarmor.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" Date: Wed, 16 Jul 2003 13:35:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/07/2003 13:35:33, Serialize complete at 16/07/2003 13:35:33 X-Mailman-Approved-At: Wed, 16 Jul 2003 07:06:11 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.2 Subject: [XCON] (no subject) X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Content-transfer-encoding: 8bit SUBSCRIBE _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQCC8; Mon, 14 Jul 2003 11:10:29 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EF7k2D001709; Mon, 14 Jul 2003 11:07:47 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EF9x26002435; Mon, 14 Jul 2003 10:10:00 -0500 Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6EF9l2E002356 for ; Mon, 14 Jul 2003 10:09:51 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1859; Mon, 14 Jul 2003 11:08:46 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Date: Mon, 14 Jul 2003 11:09:48 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6559@zoe.office.snowshore.com> Thread-Topic: Comments on draft-koskelainen-xcon-floor-control-req-00 Thread-Index: AcNKE4V1qPBQMY9WSLmw5GC1wajTzQ== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6EF9l2E002356 Subject: [XCON] Comments on draft-koskelainen-xcon-floor-control-req-00 X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com REQ-10 should also be able to set no floor control REQ-11 has media implications, like a whisper to the speaker "you lose" or (apologies to Rohan) "QUACK" REQ-12 redundant; REQ-4 covers this REQ-18 irrelevant; anyone can construct a gateway or alternative access for non-aware UA's. This doesn't impact the protocol, as you can't do anything about it. _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQCC7; Mon, 14 Jul 2003 11:10:29 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EF7skG001970; Mon, 14 Jul 2003 11:07:55 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EF9v26002421; Mon, 14 Jul 2003 10:09:58 -0500 Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6EF9l2C002356 for ; Mon, 14 Jul 2003 10:09:50 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1859; Mon, 14 Jul 2003 11:08:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Date: Mon, 14 Jul 2003 11:09:48 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6558@zoe.office.snowshore.com> Thread-Topic: Comments on draft-evan-xcon-conference-scenarios-00 Thread-Index: AcNKEwB7JjrMpp1URyKmwWSLW9FNEg== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6EF9l2C002356 Subject: [XCON] Comments on draft-evan-xcon-conference-scenarios-00 X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com 2. Conference Scenarios What is meant by the UA providing DTMF tones. Does this mean "provide DTMF tones", e.g., generate in-band tone? What about compressed codecs? Does this mean "RFC2833"? If so, the data is going to the wrong place. Does this mean "KPML"? If so, it is bending the use of KPML into the IVR realm, which KPML is explicitly not suited for. 2.1 Ad-hoc conference What is a "number" in SIP? This paragraph refers to calling and called number. Do you mean Request-URI and a From or Contact URI? 3.5 Advanced conference features Is it likely that participants will be manipulating the mix directly? See my rant on who might do what with whom. 4.1 Video mixing scenarios Are there any protocol issues here? By definition, an application creates the web page and it deals with the POST. Who needs a protocol? Certainly not the user agent. 4.3 Conference Sidebar scenario Will the user really set the main mix gain? Will they specify it in dB, 1-10, 1-100? What about AGC? Isn't the behavior of moving someone into the sidebar application-specific? It should be. Some just dump people in, others announce them to the sidebar, others do a tone. I don't think we should be standardizing (or creating protocols that enable) only one way of doing it. By the way, specifying all of the options presented in this scenario virtually requires at least a 2D GUI. See 4.1. 4.5 Presentation and QA session The scenario states the panel members are identified. Note that often, all listeners are identified to the panel members but not to each other, until (optionally) they get the floor ("now speaking..."). _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQCC6; Mon, 14 Jul 2003 11:10:26 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EF7h2D001704; Mon, 14 Jul 2003 11:07:44 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EF9t26002407; Mon, 14 Jul 2003 10:09:56 -0500 Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6EF9l2A002356 for ; Mon, 14 Jul 2003 10:09:49 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1859; Mon, 14 Jul 2003 11:08:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Date: Mon, 14 Jul 2003 11:09:47 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6556@zoe.office.snowshore.com> Thread-Topic: Media Policy in Conferencing Framework Thread-Index: AcNKESWg+GpIRh61QMiQcWwNVGRpFw== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6EF9l2A002356 Subject: [XCON] Media Policy in Conferencing Framework X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com [on XCON list, even though a SIPPING draft] draft-ietf-sipping-conferencing-framework-00 spends many pages on media aspects of conference policy and on media policy itself. First question: what requirements in the requirements document (draft-ietf-sipping-conferencing-requirements-00) do these sections tie back to? For example, section 4.6, Conference Policy, is the *definition* of a conferencing application. I don't think we're ready to say that conferencing applications are obsolete. I doubt Polycom, Radvision, Ubiquity, Spectel, or Voyant would agree. Conferencing applications are extremely difficult to develop. Much of the intellectual challenge is in the user interface. Getting rid of packaged conference applications so end users can create arbitrarily complex media plumbing and manipulation is not likely to succeed. Let's compare this to another user language, CPL. The primitives and model of CPL are oriented around the user's experience, and it is in the user's terms. The exposition of conference policy and media policy are in the terms of a conference platform developer. While one can argue about whether Joe Six-Pack will write their own CPL scripts, one could expect a real third-party CPL market happening. I cannot ever envision Joe Six-Pack writing their own conferencing application. Moreover, I cannot envision anyone getting economic returns from building, e.g., only the user interface on top of half of a conferencing application (unless the bridge manufacturers are planning on giving away their stuff, which isn't very likely). Section 5.10 describes very convoluted procedures for replumbing the conference to play an announcement. Most application developers just want to say, "play a prompt to leg X". They don't want to say, "reconfigure the mixer to be one user smaller, disconnect X, allocate a player, connect the player to X, start the player, when the player is done, disconnect X from the player, deallocate the player, reconfigure the mixer to be one user larger, and reconnect X." On another topic, I don't see floor control being related at all to mixing topology. That presupposes the policy being done by plumbing instead of having the client simply say what it wants to do. Likewise, who would decide to change conference modes on the fly without a vendor-supplied application (section 6.4)? This really comes to my key point. Who is the consumer of this protocol? By "consumer", I mean who will write the client and who will write the server? If they are not by different people, there isn't much value for standardization. For that matter, plumbing and media manipulation do not meet the guideline proposed in draft-ietf-sipping-cc-framework-02, that the primitives be participant-oriented, not media relationship-oriented. _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQCCY; Mon, 14 Jul 2003 11:10:24 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EF7mkG001965; Mon, 14 Jul 2003 11:07:50 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EF9r26002384; Mon, 14 Jul 2003 10:09:53 -0500 Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6EF9l26002356 for ; Mon, 14 Jul 2003 10:09:48 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1859; Mon, 14 Jul 2003 11:08:43 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Date: Mon, 14 Jul 2003 11:09:47 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6554@zoe.office.snowshore.com> Thread-Topic: evolving aspects on draft-ietf-sipping-conferencing-requirements-00 Thread-Index: AcNKBM7TOo6nneuwTuuebfrRIq6eWQ== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6EF9l26002356 Subject: [XCON] evolving aspects on draft-ietf-sipping-conferencing-requirements-00 X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com [on XCON list, even though a SIPPING draft] 3.5.1 REQ-3 What "evolving aspects" are we thinking of here? _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQCCX; Mon, 14 Jul 2003 11:10:22 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EF7X2D001700; Mon, 14 Jul 2003 11:07:39 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EF9m26002359; Mon, 14 Jul 2003 10:09:48 -0500 Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6EF9l24002356 for ; Mon, 14 Jul 2003 10:09:47 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1859; Mon, 14 Jul 2003 11:08:42 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Date: Mon, 14 Jul 2003 11:09:46 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6553@zoe.office.snowshore.com> Thread-Topic: Sidebars Thread-Index: AcNKBGaWFaQ/NKzoTr2qkU2LtuXXZw== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6EF9l24002356 Subject: [XCON] Sidebars X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com [on XCON list, even though a SIPPING draft] I still don't get the motivation, use case, or reasoning for REQ-7,8,9 (sidebars) in draft-ietf-sipping-conferencing-requirements-00. Why aren't sidebars different dialogs? _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQB5F; Mon, 14 Jul 2003 09:55:03 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EDqTkG001513; Mon, 14 Jul 2003 09:52:30 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EDsY26001945; Mon, 14 Jul 2003 08:54:36 -0500 Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EDsX24001941 for ; Mon, 14 Jul 2003 08:54:33 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HI00032KP0ZQX@firewall.wcom.com> for xcon@softarmor.com; Mon, 14 Jul 2003 13:48:35 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HI000201P0Y64@pmismtp01.wcomnet.com> for xcon@softarmor.com; Mon, 14 Jul 2003 13:48:35 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.153.90]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HI0001MCP0X2P@pmismtp01.wcomnet.com> for xcon@softarmor.com; Mon, 14 Jul 2003 13:48:34 +0000 (GMT) Date: Mon, 14 Jul 2003 08:48:34 -0500 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: xcon@softarmor.com Message-id: <5.2.1.1.0.20030714084426.0219d008@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [XCON] XCON BOF Tomorrow X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Content-transfer-encoding: 8bit All, Hope that everyone who is at the IETF this week will be attending the XCON BOF (July 15 from 1700-1800 in Hall F2). We will post the presentations, feedback, and the minutes from the BOF on this list in the coming days. Thanks, Alan Johnston MCI _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQPX7S; Thu, 10 Jul 2003 07:59:26 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6ABusIP017385; Thu, 10 Jul 2003 07:56:54 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6ABx226031572; Thu, 10 Jul 2003 06:59:03 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6ABwv25031569 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Thu, 10 Jul 2003 06:58:59 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6ABwta01259 for ; Thu, 10 Jul 2003 14:58:55 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 10 Jul 2003 14:58:55 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 14:58:55 +0300 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Jul 2003 14:58:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Date: Thu, 10 Jul 2003 14:58:54 +0300 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF510107FA42@esebe021.ntc.nokia.com> Thread-Topic: 3GPP Requirements on CPCP Thread-Index: AcNG2qMc9lep8+6GQHWfeLNKuKn4HA== From: georg.mayer@nokia.com To: xcon@softarmor.com X-OriginalArrivalTime: 10 Jul 2003 11:58:55.0081 (UTC) FILETIME=[A32AC590:01C346DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6ABwv25031569 Subject: [XCON] 3GPP Requirements on CPCP X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Hello, initially I planned to have a short presentation at the Vienna meeting on 3GPP requirements on CPCP, but unfortunately it seems that there is no time slot neither in SIPPING nor XCON which allows going into technical discussions during this meeting. So I decided to make my comments on the mailing list. As you know in 3GPP we are planning to adopt the SIP conferencing solution for the IMS (IP Multimedia Subsystem). During the last (CN1 WG) meeting we had some discussions on CPCP and decided that we will also adopt this solution, although some delegates had some concerns. I therefore got the task to collect requirements on CPCP, what I did. As always, the resources in wireless devices are a sacred thing and therefore the main concern was, that CPCP will introduce a whole new protocol and notation, that needs to be implemented "just" for CPCP. Therefore the main issues are: 1) that CPCP makes use of an notation mechanism that is already used within the IMS / SIP protocol. We think that XML is the way forward here. 2) that CPCP makes use of a protocol that is already used in state-of-the-art wireless devices. As SIP is not an option here, we very much favour HTTP, as this is implemented in every new mobile phone model. As the 3GPP architecture sees the protocols for any sort of application specific data manipulation over the same (Ut) interface, we also favour the approach to harmonize the data manipulation solutions as much as possible. I am aware that CPCP is more than just data manipulation, nevertheless there are very similar concepts in e.g. Presence DM and CPCP. As the IMS will also include (SIMPLE based) Presence and Presence Data Manipulation, we also see the need 3) that CPCP and Presence Data Manipulation solution must be aligned, in order to re-use as much functionality as possible. This is also important, as we see lots of services in the future, which will also require Data Manipulation via the Ut interface - we want these solutions harmonized if possible. The XCAP proposal as currently discussed in SIMPLE seems to be the right way forward here. Finally there is a need that the UE gets aware of the CPCP server. This might be outside of the scope of XCON, maybe more related to SIPPING, but as it is related to this issue, I would like to see it also listed: 4) There must be a way for the UE to get aware of the address of a CPCP server (or any other server which allows the UE to perform data manipulation). If the group agrees, I would reformulate these requirements into "requirements language", so that they can be added to CPCP requirements draft (draft-koskelainen-xcon-cpcp-reqs-00.txt). Thank you and best regards Georg _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQ2P2; Wed, 16 Jul 2003 04:17:46 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6G8FDkG012658; Wed, 16 Jul 2003 04:15:13 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6G8Go2o001246; Wed, 16 Jul 2003 03:16:52 -0500 Received: from txdwillis (tx-dwillis.ietf57.telekom.at [81.160.167.175]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6G8CW2m001186 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 16 Jul 2003 03:12:39 -0500 From: "Dean Willis" To: georg.mayer@nokia.com, xcon@softarmor.com Date: Wed, 16 Jul 2003 03:12:23 -0500 Message-ID: <000001c34b72$017f22d0$afa7a051@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <147748D63CC6B5449BC5E49FB5F8FF510107FA84@esebe021.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailman-Approved-At: Wed, 16 Jul 2003 03:16:48 -0500 Subject: [XCON] RE: Wireless Systems do not flee XML X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Georg said: > Dean made a statement during the XCON BOF that the wireless > guys (to which I count myself) do not want XML as it would > use to much bandwidth. That is in fact not true - there were > requirements expressed that XML is the preferred solution for > coding e.g. CPCP, as this would allow us XML also for XCON > purposes and we would not need to implement the next encoder > in our devices. This was actually a requirement that clearly > came out from the last 3G CN1 meeting. I was specifically worried about XML for floor management in a conference. Within the "other" mobile community (3GPP2 -- CDMA) everybody that I've talked is of the belief that the floor control messages for PoC (push talk over cellular) will need to be down in the 20-30 byte range (including headers after ROHC) to work optimally with CDMA2000. This allows them to transmit in a single short data burst. XML for configuration and other non-real-time data seems to be ok. -- Dean _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQG1H; Tue, 15 Jul 2003 12:56:32 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6FGro2D007906; Tue, 15 Jul 2003 12:53:51 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6FGti26009234; Tue, 15 Jul 2003 11:55:44 -0500 Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6FGth24009231 for ; Tue, 15 Jul 2003 11:55:43 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HI200GEIS5JFM@firewall.wcom.com> for xcon@softarmor.com; Tue, 15 Jul 2003 16:51:19 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HI200M01S50DZ@pmismtp01.wcomnet.com> for xcon@softarmor.com; Tue, 15 Jul 2003 16:51:19 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.105.5]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HI200LNLS51EQ@pmismtp01.wcomnet.com> for xcon@softarmor.com; Tue, 15 Jul 2003 16:51:02 +0000 (GMT) Date: Tue, 15 Jul 2003 11:51:00 -0500 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: xcon@softarmor.com Message-id: <5.2.1.1.0.20030715113735.0219c558@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [XCON] XCON BOF Presentation X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Content-transfer-encoding: 8bit All, Thanks to everyone who attended today's BOF - I think it went very well. The presentation is available at: http://ee.wustl.edu/~alan/xcon/xcon.ppt Minutes will be available shortly. Thanks, Alan Johnston MCI _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQF9Z; Tue, 15 Jul 2003 11:58:27 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6FFtpkG008583; Tue, 15 Jul 2003 11:55:54 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6FFvF26008944; Tue, 15 Jul 2003 10:57:16 -0500 Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6FFvB25008941 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Tue, 15 Jul 2003 10:57:13 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6FFv9k28324 for ; Tue, 15 Jul 2003 18:57:10 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jul 2003 18:57:09 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 18:57:09 +0300 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 15 Jul 2003 18:57:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Date: Tue, 15 Jul 2003 18:57:08 +0300 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF510107FA84@esebe021.ntc.nokia.com> Thread-Topic: [XCON] Media Policy in Conferencing Framework Thread-Index: AcNKNYnRokZ2hlsOSFW+flPzbXcJ+AAs6GHg From: georg.mayer@nokia.com To: dwillis@dynamicsoft.com, xcon@softarmor.com X-OriginalArrivalTime: 15 Jul 2003 15:57:09.0158 (UTC) FILETIME=[BF2A9460:01C34AE9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6FFvB25008941 Subject: [XCON] Wireless Systems do not flee XML X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Hi Dean et al, Dean made a statement during the XCON BOF that the wireless guys (to which I count myself) do not want XML as it would use to much bandwidth. That is in fact not true - there were requirements expressed that XML is the preferred solution for coding e.g. CPCP, as this would allow us XML also for XCON purposes and we would not need to implement the next encoder in our devices. This was actually a requirement that clearly came out from the last 3G CN1 meeting. The only thing that we also wanted to discuss is the possiblity and the hows and whens for compressing CPCP / XCAP specific information. Best regards, let's go to the social Georg _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQCDH; Mon, 14 Jul 2003 11:11:29 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EF8k2D001724; Mon, 14 Jul 2003 11:08:46 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EFA226002453; Mon, 14 Jul 2003 10:10:02 -0500 Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6EF9l2G002356 for ; Mon, 14 Jul 2003 10:09:51 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1859; Mon, 14 Jul 2003 11:08:46 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Date: Mon, 14 Jul 2003 11:09:48 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F655A@zoe.office.snowshore.com> Thread-Topic: Comments on draft-even-xcon-media-policy-requirements-00 Thread-Index: AcNKFIq/RumqHJwNSZW4tGJi/dT1LA== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6EF9l2G002356 Subject: [XCON] Comments on draft-even-xcon-media-policy-requirements-00 X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com The architecture section (4) states, "The focus uses the media policy to determine the proper configuration of the mixers." Does this fall within the proposed charter? REQ-GP1 What is the use case for endpoints arbitrarily specifying plumbing? REQ-GP3 What is the use case here? Are we really saying that it is has to be possible to add a leg to the mix? If so, say so. REQ-GP8 I don't understand this at all. Can we restate it? REQ-GP9 Is the idea to mix the user's media separately or differently? For example, the user's Camera 1 (room) is always shown while Camera 2 (face) is only shown while speaking? 6.2 Is "overlapping windows" a client display issue or a mixing issue, or are there independent windows? REQ-V1 What is the value to a *protocol* to talk about layout? REQ-V2 Isn't this the definition of a video conferencing application? Who will issue the media policy requests to change things? REQ-V3 Is this for the whole conference or an individual user? REQ-V4 Is this for the whole conference or an individual user? _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQCDA; Mon, 14 Jul 2003 11:10:48 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EF852D001715; Mon, 14 Jul 2003 11:08:06 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EF9s26002396; Mon, 14 Jul 2003 10:09:54 -0500 Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6EF9l28002356 for ; Mon, 14 Jul 2003 10:09:48 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1859; Mon, 14 Jul 2003 11:08:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Date: Mon, 14 Jul 2003 11:09:47 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6555@zoe.office.snowshore.com> Thread-Topic: Comments on draft-ietf-sipping-cc-conferencing-01 Thread-Index: AcNKEJ2OQIxlGGSnSKiO7F4Iz8RIXA== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6EF9l28002356 Subject: [XCON] Comments on draft-ietf-sipping-cc-conferencing-01 X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com [on XCON list, even though a SIPPING draft] Section 3.4: I'm hesitant to say a conference aware UA SHOULD subscribe to conference state. That's really an application decision. One might suggest it, e.g., "the UA can subscribe to the conference state." A similar sentiment goes for the following paragraph. Why would or why would not a UA want to display information gleaned from SIP? In any event, it is not a protocol issue, so it doesn't really merit a MAY (or SHOULD). Section 4.2: How else, in the SIP world, would a focus bring a user agent into the conference other than by INVITE? Maybe the SHOULD here is the inclusion of the ;isfocus parameter. That said, why is it not MUST? Section 4.3: Having the scars of Early Media from netann, I would suggest not going down the path of IVR interactions before session establishment completes. There are a lot of ugly corner cases to think of and work around. I would drop the paragraph. Section 4.6: Same as 4.2, but with REFER. Is the SHOULD that REFER is preferred to a new INVITE or that ;isfocus SHOULD be in the contact. If the former, this is the SIPPING work group, the only thing we can spec is SIP stuff, and thus this is redundant. If it is the latter, then is there a reason including ;isfocus is not mandatory? _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQCC0; Mon, 14 Jul 2003 11:10:36 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EF81kG001974; Mon, 14 Jul 2003 11:08:02 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EFA926002480; Mon, 14 Jul 2003 10:10:10 -0500 Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6EF9l2K002356 for ; Mon, 14 Jul 2003 10:09:53 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1859; Mon, 14 Jul 2003 11:08:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Date: Mon, 14 Jul 2003 11:09:49 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F655C@zoe.office.snowshore.com> Thread-Topic: Comments on draft-koskelainen-xcon-xcap-cpcp-usage-00 Thread-Index: AcNKGHf0+rgWJXG8RTOv/SSX63egqg== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6EF9l2K002356 Subject: [XCON] Comments on draft-koskelainen-xcon-xcap-cpcp-usage-00 X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Second paragraph of the introduction: What issues do the alternative approaches have? Who makes a conference application without a user interface? Who needs this interoperability? From what element to what element? Section 6 Open Issue - ad-hoc becomes CPCP Is this at all a realistic scenario? By definition, ad-hoc is at the user's phone. The user owns her phone. She can do whatever she wants with it. There is no protocol issue inside a single box. 10. Structure of a Conference Policy document Is there ANY reason for such a document NOT to be valid? This MUST be a MUST :-) The SHOULD is on the implementation: the server SHOULD validate the document, but it doesn't have to if it is too lazy. Why is
a mandatory element? Are all conferences dial-out? 11.3 element Of course we need times, we have EVERYTHING else here :-( This whole section recreates iCal. Let's use iCal. 11.4 element The text should enumerate the algorithm for dealing with conflicting rules here. I would offer "most-specified" wins. 11.5 The text should say that one might want to encrypt SIP bodies for end-to-end security. 11.6
Sensible outdialling is a very hard problem. Retries are easy -- what about failure status, current call attempt status, short retries on busy, abandoning on vacant, long retries on no answer, etc. This sounds like application logic, not markup. 11.7 Why not do wildcarding in the domain part? It is just regex processing. XCAP CPCP is so large already, such that if there was an increase in processing required (which I doubt), it is dwarfed by everything else going on. The document should point out a denial of service attack, that of filling the ACL table. This indicates strong authentication and authorization should be part of the protocol. 13. Authorization Policies, last open issue (visibility of information) These issues are identical to presence information. How did they solve this problem? Examples Open issue on "expel for time period": Too complex and no value. Application can use its own timer and turn the person in "timeout" back on when appropriate. That way the application can use maximally complex timeout algorithms without impacting the policy server. _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQCC9; Mon, 14 Jul 2003 11:10:35 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EF7q2D001712; Mon, 14 Jul 2003 11:07:53 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EFA726002469; Mon, 14 Jul 2003 10:10:08 -0500 Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6EF9l2I002356 for ; Mon, 14 Jul 2003 10:09:52 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1859; Mon, 14 Jul 2003 11:08:47 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Date: Mon, 14 Jul 2003 11:09:48 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F655B@zoe.office.snowshore.com> Thread-Topic: Comments on draft-koskelainen-xcon-cpcp-reqs-00 Thread-Index: AcNKFdMn5OAUJW+1R6ieK023LW26Pg== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6EF9l2I002356 Subject: [XCON] Comments on draft-koskelainen-xcon-cpcp-reqs-00 X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com General: There are a lot of references to passwords in the document. I would suggest also considering certificates. Language such as "appropriate authentication" can dodge this issue. REQ-B8 open issue Yes, it is absolutely of value to specify maximum conference size, as that information allows for (1) guaranteed availability and (2) algorithm selection. REQ-C3 open issue If we consider media encryption to be a yes/no or strength question, it is a CPCP thing. E.g., if you cannot encrypt the stream, don't establish a session. Specifying the keys is a key distribution issue, which is again an "appropriate authentication and distribution" issue. For example, there is no key distribution with public keys. I would list REQ-E3 before REQ-E2. I would also add that the protocol will not allow conflicting ACL definitions for fully-qualified targets. REQ-E4 Hidden and anonymous users are two different things. I would split the requirement. REQ-CP-1 Given REQ-CP-2, doesn't the protocol have to be reliable? That bumps REQ-CP-1 to MUST strength. _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NWGGLCPK; Tue, 1 Jul 2003 14:37:19 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h61IYGY8007598; Tue, 1 Jul 2003 14:34:40 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h61Did25031078; Tue, 1 Jul 2003 08:44:39 -0500 Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h61DZB25030741 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Tue, 1 Jul 2003 08:35:14 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h61DZA925451 for ; Tue, 1 Jul 2003 16:35:10 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Jul 2003 16:35:09 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Jul 2003 16:35:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252; format=flowed Subject: RE: [XCON] Conference Policy Control -comments on draft-koskelainen-xcon-xcap-cpcp-usage-00 Date: Tue, 1 Jul 2003 16:35:04 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E84@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Conference Policy Control -comments on draft-koskelainen-xcon-xcap-cpcp-usage-00 Thread-Index: AcM/0WPHi9I3pQhFTQqSYSCgzYGpMAAA6U8w From: hisham.khartabil@nokia.com To: eunah@pec.etri.re.kr, petri.koskelainen@nokia.com X-OriginalArrivalTime: 01 Jul 2003 13:35:08.0776 (UTC) FILETIME=[96D6F680:01C33FD5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h61DZB25030741 X-Mailman-Approved-At: Tue, 01 Jul 2003 08:44:14 -0500 Cc: xcon@softarmor.com, Markus.Isomaki@nokia.com X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Hi Eunah, Thanks for the comments and corrections. Your modifications will be taken into consideration. We actually have not put the schema into a validator yet due to time constraints, but will do as soon as possible. We felt that the XML validity is not a big issue now, but the community accepting the idea was. Anyhow, the next version will hopefully have a valid XML schema. Regards, Hisham > -----Original Message----- > From: ext Eunsook Kim [mailto:eunah@pec.etri.re.kr] > Sent: Tuesday, July 01, 2003 3:23 PM > To: Koskelainen Petri (NRC/Tampere); Khartabil Hisham (NMP/Helsinki) > Cc: xiaotaow@cs.columbia.edu; Isomaki Markus (NRC/Helsinki); > jhyiee@etri.re.kr; xcon@softarmor.com > Subject: Re: [XCON] Conference Policy Control -comments on > draft-koskelainen-xcon-xcap-cpcp-usage-00 > > > Hi Petri, and Hisham > > I went over XCAP and the related documents and admit that it > gives simple and light method to manipulate conference policy. :-) > I also have looked over your document and the defined XML > schema, and found a lot of syntax errors and several schema > validation errors. > I tried to correct them, and attach the schema file, which I > get the successful validation message by running it into the XMLSPY. > Currently, I changed or added some of definition to get a > valid schema. > I tried to read your intention as possible as I can, but > please let me know if the corrections doesn't carry well on > your intention. > > ----------------- > The brief note of the errors is as following: > > 1. Namespace should be defined for 'conference-policy' in > order to reuse types and elements defined in the document. > > [[Syntax errors]] > > 2. Comment type should be instead > > 3. There are many cases where definitions are unappropriately > ended. I cannot list all of them here; give an example: > > > > > > > > 4.And, there are some mismatched or missed or redundant end tags. > ex) > > > name="SIP-URI" type="xsd:anyURI" use="required"/> > .......... > (some elements) > > > > > > [[Unvalid Schema Definition Errors]] > > 5. You use [use="required"] severral times in definition of > elements, which is not appropriate. minOccurs="1" can be > used, instead. > > 6. in your definition) > > value="TLS" type="xsd:boolean" default="false"/> > value="S-MIME" type="xsd:boolean" default="false"/> > > > > I got an error indicating unappropriate use of "value" in > attribute; > I got the validation error in the following definition. I > defined the type of Security-mechanism, and reuse it for the > definition. > Please let me know if it is different from your intention. > Then, I'll correct it as your intention. > > > 7. > > > > > > type="xsd:string"/> > > > I got an error indicating wrong use of "restrction" > based enumeration value in a complexType. > I tried to define the type of Authorixation-type for the > enumeration values. > > > 8. > > > name="ACL-target-URI" type="xsd:anyURI" use="required" minOccurs="1" > > MaxOccurs="unbounded"/> > > > > > > > > > > > Over the definition, the closed tag of "ACL-target-URI" > element followed by MaxOccurs="unbounded" is not correct here, right? > I guess you'd like to make ACL-target-URI have an > attribute, am I correct? > Anyway, I got an error indicating unappropriate use of > attribute here, so I changed "ACL" element to the form of > "PCL" and "DL" in this moment, but it is not your intention, > please let me know. > > ------------------ > > I hope this will be helpful. > > Sincerely, > Eunah > > > > > > > > > > ----- Original Message ----- > > From: petri.koskelainen@nokia.com > > To: eunah@pec.etri.re.kr ; hisham.khartabil@nokia.com > > Cc: xiaotaow@cs.columbia.edu ; Markus.Isomaki@nokia.com ; > jhyiee@etri.re.kr > > Sent: Friday, June 27, 2003 10:51 PM > > Subject: RE: [XCON] Conference Policy Control > > > > > > Hi Eunah, > > > > Thanks for the input. CPCP is very different from floor > control so we don't need to have same protocol > > for these (besides, XCAP is already used for presence-list > manipulation which is similar to conf policy manipulation etc). > > > > If you can provide input to CPCP (e.g. what parameters > should be included in the policy, or finding errors in XML Schema) > > that would be highly appreciated. > > > > Thanks, > > Petri > > > > > > > >>-----Original Message----- > >>From: ext Eunsook Kim [mailto:eunah@pec.etri.re.kr] > >>Sent: 27 June, 2003 16:44 > >>To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri (NRC/Tampere) > >>Cc: xiaotaow@cs.columbia.edu; Isomaki Markus (NRC/Helsinki); JongHwa > >>Subject: Re: [XCON] Conference Policy Control > >> > >> > >>Hisham, > >> > >>Thanks a lot for your response. > >> > >>I've chosen SOAP for acessing server elements of conference > policy control, because it is a well-known standardized protocol. > >>Besides, I believe there is a close relationship between > conference policy and floor controls, and I think that it > would be good for the two >>mechanisms to use the same protocol. > >>As you know, Xioatao and Petri have already proposed a > floor control draft using SOAP, > >>so, I've prototyped a few basic functions of policy control > using SOAP, and wrote my draft. > >>However, SOAP is just one of the methods to allow client to > access policy server information, and > >>I'm willing to do it by using XCAP, too > >> > >>I think, the main focus of this work is not if it should > be SOAP or XCAP. > >>In my opinion, it is more important to design well-formed > schema for policy control operations which can be > standardized, and I think the >>conference design team has > been doing very good job in this point of view. And, as the > one who is very interested in and working on this area, >>I'm > very happy to hear the XCON bof announcement, and I'll be > very happy if I can help or contribute some parts on the > works of design team. > >> > >>I'll go over all the XCON drafts again, and I would like to > discuss on this topic with you more in the mailing list, if > you'd like to. > >> > >>I appreciate your response again. > >> > >>Yours faithfully, Eunah > >> > >> > >> > >>>----- Original Message ----- > >>>From: hisham.khartabil@nokia.com > >>>To: eunah@pec.etri.re.kr ; petri.koskelainen@nokia.com > >>>Cc: xiaotaow@cs.columbia.edu ; Markus.Isomaki@nokia.com > >>>Sent: Friday, June 27, 2003 3:24 PM > >>>Subject: RE: [XCON] Conference Policy Control > >>> > >>> > >>>Eunah, > >>> > >>>We appreciate your enthusiasm about the conferencing work. > >>> > >>>Your proposal so makes use of SOAP as a solution. To be > honest, our interest in SOAP as a solution for conference > policy protocol is very >>>minimal. That's why we chose XCAP, > its simple and much lighter to implement than SOAP. > >>> > >>>If you feel that your proposal is the superior one, please > feel free to involve yourself in the soon newly formed IETF > working group, named >>>XCON, specifically designed to > produce such conferencing protocols. The conferencing work so > far has been done in a closed design team >>>where the XCAP > has so far been well accepted as the conference policy solution. > >>> > >>>Much appreciated, > >>>Hisham > > > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon