From mary.barnes@nortel.com Wed Apr 1 10:40:53 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F783A6B5F for ; Wed, 1 Apr 2009 10:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8t-5Rf3Noex for ; Wed, 1 Apr 2009 10:40:53 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E68B63A6B62 for ; Wed, 1 Apr 2009 10:40:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n31HfH923553; Wed, 1 Apr 2009 17:41:17 GMT 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 Date: Wed, 1 Apr 2009 12:44:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D305BCA@zrc2hxm0.corp.nortel.com> In-Reply-To: <20090331132746.zyooov5hb4kcg0o0@webmail.unina.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Additional Data in the Data Model Thread-Index: Acmx877Q/7783zTfT9K7//1TBtU1ZQA/ZkpA References: <9520E66537CC4941994C518E3E21091CC4BB3F@esealmw105.eemea.ericsson.se> <20090331132746.zyooov5hb4kcg0o0@webmail.unina.it> From: "Mary Barnes" To: , "Oscar Novo" Cc: xcon@ietf.org Subject: Re: [XCON] Additional Data in the Data Model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:40:54 -0000 I also think your proposal is fine. I had originally thought we'd want = to know in the case where the parent was cloned and labeled = "independent". But, really once we clone and don't make it dependent on = the changes to the parent, it really doesn't matter that it was = originally created by cloning.=20 Thanks, Mary.=20 -----Original Message----- From: spromano@unina.it [mailto:spromano@unina.it]=20 Sent: Tuesday, March 31, 2009 6:28 AM To: Oscar Novo Cc: xcon@ietf.org; Barnes, Mary (RICH2:AR00) Subject: Re: Additional Data in the Data Model I'm ok with the proposed modifications. Cheers, Simon Quoting Oscar Novo : > Hi guys! > > As per discussion in this mailing list and in the last IETF-74=20 > meeting, the authors of the data model are proposing to add the=20 > following elements to the data model to explicit express cloning in = the document. > The elements we're planning to add are: > > - cloning-parent: When this element is present, it indicates that the=20 > conference object is a child of a parent conference. This element=20 > contains the conference object Identifier (XCON-URI) (different from=20 > the main XCON-URI) of the parent. > - sidebar-parent; When this element is present, it indicates that the=20 > conference object represents a sidebar of another conference. This=20 > element contains the conference object Identifier (XCON-URI)=20 > (different from the main XCON-URI) of the parent. > > If nobody oppose to this modifications, we'll submit a new version of=20 > the document in brief. > > Of course, any feedback to the document or to the previous=20 > modifications are always very welcome. :) > > Cheers, > > Oscar > --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From root@core3.amsl.com Mon Apr 6 23:15:01 2009 Return-Path: X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 48B6C3A6BFB; Mon, 6 Apr 2009 23:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090407061501.48B6C3A6BFB@core3.amsl.com> Date: Mon, 6 Apr 2009 23:15:01 -0700 (PDT) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-13.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 06:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Conference Information Data Model for Centralized Conferencing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-13.txt Pages : 93 Date : 2009-04-06 This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-xcon-common-data-model-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-06230421.I-D@ietf.org> --NextPart-- From gonzalo.camarillo@ericsson.com Wed Apr 8 22:54:53 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215C93A6A33 for ; Wed, 8 Apr 2009 22:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.187 X-Spam-Level: X-Spam-Status: No, score=-5.187 tagged_above=-999 required=5 tests=[AWL=1.062, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSrj2pkOh1X1 for ; Wed, 8 Apr 2009 22:54:51 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2D0943A68F8 for ; Wed, 8 Apr 2009 22:54:51 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AF1F420EA7; Thu, 9 Apr 2009 07:55:57 +0200 (CEST) X-AuditID: c1b4fb3c-a8ee3bb000003b08-27-49dd8ded9fcb Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 92BFE20611; Thu, 9 Apr 2009 07:55:57 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 07:55:57 +0200 Received: from [131.160.126.142] ([131.160.126.142]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 07:55:57 +0200 Message-ID: <49DD8DED.3010908@ericsson.com> Date: Thu, 09 Apr 2009 08:55:57 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: XCON Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2009 05:55:57.0420 (UTC) FILETIME=[DA266AC0:01C9B8D7] X-Brightmail-Tracker: AAAAAA== Cc: xcon-chairs@tools.ietf.org Subject: [XCON] BFCP over UDP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 05:54:53 -0000 Hi, the following (expired) draft was presented in the XCON session in San Francisco: http://www.watersprings.org/pub/id/draft-sandbakken-xcon-bfcp-udp-00.txt The agreement was that given the problems TCP has with NATs (the P2PSIP WG is currently discussing the same issue) it would be a good idea to define a more NAT-friendly transport for BFCP. The proposal was to simply use UDP (this is what existing deployments do). Since BFCP messages can be rather long, we would need an applicability statement saying which types of messages cannot be used over UDP. In order to specify the new UDP-based transport we can either put together a new draft or revise the BFCP specification. I got the action point to list the things that could be fixed in a potential revised BFCP spec. These are the contents of my notes. Of course, if someone knows of more issues, please let us know: o When a user performs a third-party floor request the beneficiary of the floor is not informed when the floor is granted. This may not be a problem because endpoints using third-party floor requests probably have different means to get in synch but we may want to add some text about this. o We do not have errors for an unsupported version of the protocol or for wrong message length. We do not have a general error either. o When we get more experience on queue management from real deployments, it would be nice to explaining it further in the spec. o UserStatus UserStatus = (COMMON-HEADER) [BENEFICIARY-INFORMATION] 1*(FLOOR-REQUEST-INFORMATION) -> remove the 1 *[EXTENSION-ATTRIBUTE] o A message may need to be longer than the maximum message length supported by the protocol o A rather small number of typos As you can see, at this point there are not so many things to fix... so, the simplest way forward may be to simply specify a new UDP-based transport for BFCP. In any case, I would like to get feedback from folks operating BFCP deployments. A different alternative (the one the P2PSIP WG is looking at) would be to either use a UDP encapsulation for TCP or to specify a new transport protocol... but these alternatives may be more complex than just using UDP. Comments? Thanks, Gonzalo From Markus.Isomaki@nokia.com Thu Apr 9 01:02:17 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9EE3A6A05 for ; Thu, 9 Apr 2009 01:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzCSoGES+EDI for ; Thu, 9 Apr 2009 01:02:15 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8240F3A6AFF for ; Thu, 9 Apr 2009 01:02:11 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3982o4K025473; Thu, 9 Apr 2009 11:03:12 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Apr 2009 11:03:10 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Apr 2009 11:03:10 +0300 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 9 Apr 2009 10:03:09 +0200 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.107]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Thu, 9 Apr 2009 10:03:09 +0200 From: To: , Date: Thu, 9 Apr 2009 10:03:05 +0200 Thread-Topic: [XCON] BFCP over UDP Thread-Index: Acm41+K92zMLwuXBRjuMjrzt9VP1wwADlkqA Message-ID: References: <49DD8DED.3010908@ericsson.com> In-Reply-To: <49DD8DED.3010908@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Apr 2009 08:03:10.0272 (UTC) FILETIME=[9FAF3400:01C9B8E9] X-Nokia-AV: Clean Cc: xcon-chairs@tools.ietf.org Subject: Re: [XCON] BFCP over UDP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 08:02:17 -0000 Hi Gonzalo, The problem with TCP and NATs usually stems from the scenario where both pa= rties who want to communicate are behind a NAT. This is presumably often th= e case with P2PSIP. However, I've thought that BFCP would be typically depl= oyed in a fashion where the conference focus (or the element managing the f= loor) would be hosted in a public address. In such a case TCP definitely wo= rks much better even if the conference participant would be behind a NAT. So, does the motivation for BFCP over UDP come from the requirement that th= e conference focus (the floor "manager") would itself need to be behind a N= AT? This might be a valid requirement as such, when we think about endpoint= hosted conferences. But even in those cases TCP could still work, if we as= sume that some infra like TURN-TCP or comedia/TCP aware SBCs (which we have= discussed in SIMPLE lately) would be available. Again in P2PSIP the situat= ion is different as they can't assume that kind of infra (the peers themsel= ves need to provide it). So, I'm not sure if BFCP and P2PSIP requirements a= re identical. Unless you think about BFCP within a P2PSIP deployment. Sorry, I didn't attend the XCON session in San Francisco, this was probably= well covered there. (I agree that there are many situations where defining how to tunnel/emulat= e TCP-like transport service over UDP. So, I think the best would be if TSV= area could define one single solution and then protocols like P2PSIP, MSRP= , BFCP etc. could use it.) Markus =20 >-----Original Message----- >From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On=20 >Behalf Of ext Gonzalo Camarillo >Sent: 09 April, 2009 08:56 >To: XCON >Cc: xcon-chairs@tools.ietf.org >Subject: [XCON] BFCP over UDP > >Hi, > >the following (expired) draft was presented in the XCON session in San >Francisco: > >http://www.watersprings.org/pub/id/draft-sandbakken-xcon-bfcp-u >dp-00.txt > >The agreement was that given the problems TCP has with NATs=20 >(the P2PSIP WG is currently discussing the same issue) it=20 >would be a good idea to define a more NAT-friendly transport=20 >for BFCP. The proposal was to simply use UDP (this is what=20 >existing deployments do). > >Since BFCP messages can be rather long, we would need an=20 >applicability statement saying which types of messages cannot=20 >be used over UDP. > >In order to specify the new UDP-based transport we can either=20 >put together a new draft or revise the BFCP specification. I=20 >got the action point to list the things that could be fixed in=20 >a potential revised BFCP spec. These are the contents of my=20 >notes. Of course, if someone knows of more issues, please let us know: > >o When a user performs a third-party floor request the=20 >beneficiary of the floor is not informed when the floor is=20 >granted. This may not be a problem because endpoints using=20 >third-party floor requests probably have different means to=20 >get in synch but we may want to add some text about this. > >o We do not have errors for an unsupported version of the=20 >protocol or for wrong message length. We do not have a general=20 >error either. > >o When we get more experience on queue management from real=20 >deployments, it would be nice to explaining it further in the spec. > >o UserStatus > >UserStatus =3D (COMMON-HEADER) > [BENEFICIARY-INFORMATION] > 1*(FLOOR-REQUEST-INFORMATION) -> remove the 1 > *[EXTENSION-ATTRIBUTE] > >o A message may need to be longer than the maximum message=20 >length supported by the protocol > >o A rather small number of typos > > >As you can see, at this point there are not so many things to=20 >fix... so, the simplest way forward may be to simply specify a=20 >new UDP-based transport for BFCP. In any case, I would like to=20 >get feedback from folks operating BFCP deployments. > >A different alternative (the one the P2PSIP WG is looking at)=20 >would be to either use a UDP encapsulation for TCP or to=20 >specify a new transport protocol... but these alternatives may=20 >be more complex than just using UDP. > >Comments? > >Thanks, > >Gonzalo >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www.ietf.org/mailman/listinfo/xcon >= From duddy@avaya.com Thu Apr 9 08:27:04 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34433A6A4D for ; Thu, 9 Apr 2009 08:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59TDWdL5WwyC for ; Thu, 9 Apr 2009 08:27:03 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4CE803A69D0 for ; Thu, 9 Apr 2009 08:27:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,161,1238990400"; d="scan'208,217";a="142711848" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Apr 2009 11:28:09 -0400 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Apr 2009 11:28:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B927.C68E8D78" Date: Thu, 9 Apr 2009 16:28:03 +0100 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71CC47C9@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-xcon-common-data-model-13 Thread-Index: Acm5J8YRUihC+e4SRR2vcRfNWJtEUw== From: "Duddy, Sean (Sean)" To: Subject: [XCON] draft-ietf-xcon-common-data-model-13 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 15:27:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B927.C68E8D78 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, The XCON data model states that=20 =20 "The element contains one or more elements each defining the time information specifying a single conference occurrence." =20 Since an ICAL object can specify the complete timing information for all occurences belonging to a conference, why is this sequence of elements required?=20 =20 =20 Sean ------_=_NextPart_001_01C9B927.C68E8D78 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 folks,
    The XCON data model states that
 
"The <conference-time>
   = element=20 contains one or more <entry> elements each defining the=20 time
   information specifying a single conference=20 occurrence."
 
Since = an ICAL object=20 can specify the complete timing information for all=20 occurences
belonging to a=20 conference, why is this sequence of elements required? =
 
 
Sean
------_=_NextPart_001_01C9B927.C68E8D78-- From duddy@avaya.com Thu Apr 9 09:53:44 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3246A3A6A8C for ; Thu, 9 Apr 2009 09:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2IbN8KpBJNR for ; Thu, 9 Apr 2009 09:53:43 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id E827B3A6846 for ; Thu, 9 Apr 2009 09:53:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,161,1238990400"; d="scan'208,217";a="142721652" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Apr 2009 12:54:49 -0400 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 09 Apr 2009 12:54:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B933.DF70DD5A" Date: Thu, 9 Apr 2009 17:54:39 +0100 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71CC47E1@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-xcon-ccmp-02 Thread-Index: Acm5M98e7gETULKqSbWOTusB05xVyg== From: "Duddy, Sean (Sean)" To: Subject: [XCON] draft-ietf-xcon-ccmp-02 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:53:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B933.DF70DD5A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, How does a ccmp client request a specify media type for its conference (e.g. audio or audio+video or video only)?=20 =20 Th data model has an element but only the server has the=20 information to populate this (http://tools.ietf.org/html/rfc4575#section-5.3.4) and the definition of this element alone implies what media is available and not=20 how to request a specific media... =20 Regards Sean ------_=_NextPart_001_01C9B933.DF70DD5A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Folks,
    How does a ccmp client request a specify media type for its=20 conference
(e.g. = audio or=20 audio+video or video only)?
 
Th = data model has an=20 <available-media> element but only the server has the =
information to=20 populate this (http://tools.ie= tf.org/html/rfc4575#section-5.3.4)
and = the definition=20 of this element alone implies what media is available and not=20
how to = request a=20 specific media...
 
Regards
Sean
------_=_NextPart_001_01C9B933.DF70DD5A-- From oscar.novo@ericsson.com Mon Apr 13 22:54:20 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086323A6A59 for ; Mon, 13 Apr 2009 22:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.504 X-Spam-Level: X-Spam-Status: No, score=-5.504 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaZkjcGQ+2F2 for ; Mon, 13 Apr 2009 22:54:19 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E8B8A3A67F4 for ; Mon, 13 Apr 2009 22:54:18 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 96FBF5481FD; Tue, 14 Apr 2009 07:55:28 +0200 (CEST) X-AuditID: c1b4fb3c-ae7d2bb00000238f-ac-49e425433e42 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B61AC520028; Tue, 14 Apr 2009 07:55:15 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 07:54:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BCC5.87EC58B9" Date: Tue, 14 Apr 2009 07:54:52 +0200 Message-ID: <9520E66537CC4941994C518E3E21091CDA0B6A@esealmw105.eemea.ericsson.se> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71CC47C9@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] draft-ietf-xcon-common-data-model-13 thread-index: Acm5J8YRUihC+e4SRR2vcRfNWJtEUwDnF5xA References: <4408C6EC74CC3D42824FD68FDA8E8F71CC47C9@306900ANEX2.global.avaya.com> From: "Oscar Novo" To: "Duddy, Sean (Sean)" , X-OriginalArrivalTime: 14 Apr 2009 05:54:53.0599 (UTC) FILETIME=[882CDAF0:01C9BCC5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [XCON] draft-ietf-xcon-common-data-model-13 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 05:54:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BCC5.87EC58B9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 That's only a matter of configurability. A way to make possible to define different policies (must-join-before-offset, can-join-after-offset, ... ) for the same conference at different times. The specification of all the occurences in a single element is possible too as shown by the example in section 7. =20 Oscar =20 =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Duddy, Sean (Sean) Sent: 9. huhtikuuta 2009 18:28 To: xcon@ietf.org Subject: [XCON] draft-ietf-xcon-common-data-model-13 Hi folks, The XCON data model states that=20 =20 "The element contains one or more elements each defining the time information specifying a single conference occurrence." =20 Since an ICAL object can specify the complete timing information for all occurences belonging to a conference, why is this sequence of elements required?=20 =20 =20 Sean ------_=_NextPart_001_01C9BCC5.87EC58B9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
That's only a matter of configurability. A = way to make=20 possible to define different policies (must-join-before-offset,=20 can-join-after-offset, ... ) for the same conference at different times. =
The specification of all the occurences in a = single element=20 is possible too as shown by the example in section = 7.
 
Oscar
 
 
From:=20 xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Duddy,=20 Sean (Sean)
Sent: 9. huhtikuuta 2009 18:28
To:=20 xcon@ietf.org
Subject: [XCON]=20 draft-ietf-xcon-common-data-model-13

Hi=20 folks,
    The XCON data model states that
 
"The <conference-time>
   = element=20 contains one or more <entry> elements each defining the=20 time
   information specifying a single conference=20 occurrence."
 
Since = an ICAL object=20 can specify the complete timing information for all=20 occurences
belonging to a=20 conference, why is this sequence of elements required? =
 
 
Sean
------_=_NextPart_001_01C9BCC5.87EC58B9-- From duddy@avaya.com Tue Apr 14 02:36:55 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9507C3A67A1 for ; Tue, 14 Apr 2009 02:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzwR0WtScsWH for ; Tue, 14 Apr 2009 02:36:54 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 2988A3A677C for ; Tue, 14 Apr 2009 02:36:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238990400"; d="scan'208,217";a="158326754" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 14 Apr 2009 05:38:04 -0400 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 14 Apr 2009 05:38:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BCE4.AF3FA42B" Date: Tue, 14 Apr 2009 10:33:53 +0100 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71CC487C@306900ANEX2.global.avaya.com> In-Reply-To: <9520E66537CC4941994C518E3E21091CDA0B6A@esealmw105.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] draft-ietf-xcon-common-data-model-13 Thread-Index: Acm5J8YRUihC+e4SRR2vcRfNWJtEUwDnF5xAAAd4F2A= References: <4408C6EC74CC3D42824FD68FDA8E8F71CC47C9@306900ANEX2.global.avaya.com> <9520E66537CC4941994C518E3E21091CDA0B6A@esealmw105.eemea.ericsson.se> From: "Duddy, Sean (Sean)" To: "Oscar Novo" , Subject: Re: [XCON] draft-ietf-xcon-common-data-model-13 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 09:36:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BCE4.AF3FA42B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Oscar, ok that sounds reasonable. Should the draft be updated to include the explanation below? =20 Sean ________________________________ From: Oscar Novo [mailto:oscar.novo@ericsson.com]=20 Sent: 14 April 2009 06:55 To: Duddy, Sean (Sean); xcon@ietf.org Subject: RE: [XCON] draft-ietf-xcon-common-data-model-13 Hi, =20 That's only a matter of configurability. A way to make possible to define different policies (must-join-before-offset, can-join-after-offset, ... ) for the same conference at different times. The specification of all the occurences in a single element is possible too as shown by the example in section 7. =20 Oscar =20 =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Duddy, Sean (Sean) Sent: 9. huhtikuuta 2009 18:28 To: xcon@ietf.org Subject: [XCON] draft-ietf-xcon-common-data-model-13 Hi folks, The XCON data model states that=20 =20 "The element contains one or more elements each defining the time information specifying a single conference occurrence." =20 Since an ICAL object can specify the complete timing information for all occurences belonging to a conference, why is this sequence of elements required?=20 =20 =20 Sean ------_=_NextPart_001_01C9BCE4.AF3FA42B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Oscar,
    ok that sounds reasonable. = Should the=20 draft be updated to include the explanation = below?
 
Sean
From: = Oscar Novo=20 [mailto:oscar.novo@ericsson.com]
Sent: 14 April 2009=20 06:55
To: Duddy, Sean (Sean); xcon@ietf.org
Subject: = RE:=20 [XCON] draft-ietf-xcon-common-data-model-13

Hi,
 
That's only a matter of configurability. A = way to make=20 possible to define different policies (must-join-before-offset,=20 can-join-after-offset, ... ) for the same conference at different times. =
The specification of all the occurences in a = single element=20 is possible too as shown by the example in section = 7.
 
Oscar
 
 
From:=20 xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Duddy,=20 Sean (Sean)
Sent: 9. huhtikuuta 2009 18:28
To:=20 xcon@ietf.org
Subject: [XCON]=20 draft-ietf-xcon-common-data-model-13

Hi=20 folks,
    The XCON data model states that
 
"The <conference-time>
   = element=20 contains one or more <entry> elements each defining the=20 time
   information specifying a single conference=20 occurrence."
 
Since = an ICAL object=20 can specify the complete timing information for all=20 occurences
belonging to a=20 conference, why is this sequence of elements required? =
 
 
Sean
------_=_NextPart_001_01C9BCE4.AF3FA42B-- From oscar.novo@ericsson.com Tue Apr 14 03:39:52 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580993A6B09 for ; Tue, 14 Apr 2009 03:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6 X-Spam-Level: X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rhcusj72umV for ; Tue, 14 Apr 2009 03:39:51 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0DF0B3A6AE3 for ; Tue, 14 Apr 2009 03:39:51 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0864321740; Tue, 14 Apr 2009 12:41:01 +0200 (CEST) X-AuditID: c1b4fb3e-ae824bb0000024d5-2b-49e468378035 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 660FF21663; Tue, 14 Apr 2009 12:40:55 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 12:40:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BCED.7BE05ADD" Date: Tue, 14 Apr 2009 12:40:52 +0200 Message-ID: <9520E66537CC4941994C518E3E21091CDA1007@esealmw105.eemea.ericsson.se> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71CC487C@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] draft-ietf-xcon-common-data-model-13 thread-index: Acm5J8YRUihC+e4SRR2vcRfNWJtEUwDnF5xAAAd4F2AAAtWXcA== References: <4408C6EC74CC3D42824FD68FDA8E8F71CC47C9@306900ANEX2.global.avaya.com> <9520E66537CC4941994C518E3E21091CDA0B6A@esealmw105.eemea.ericsson.se> <4408C6EC74CC3D42824FD68FDA8E8F71CC487C@306900ANEX2.global.avaya.com> From: "Oscar Novo" To: "Duddy, Sean (Sean)" , X-OriginalArrivalTime: 14 Apr 2009 10:40:52.0878 (UTC) FILETIME=[7BE70AE0:01C9BCED] X-Brightmail-Tracker: AAAAAA== Subject: Re: [XCON] draft-ietf-xcon-common-data-model-13 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 10:39:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BCED.7BE05ADD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Yes, I'll explain a bit better that section in the previous version of the draft =20 Thanks for your comment! =20 Oscar ________________________________ From: Duddy, Sean (Sean) [mailto:duddy@avaya.com]=20 Sent: 14. huhtikuuta 2009 12:34 To: Oscar Novo; xcon@ietf.org Subject: RE: [XCON] draft-ietf-xcon-common-data-model-13 Hi Oscar, ok that sounds reasonable. Should the draft be updated to include the explanation below? =20 Sean ________________________________ From: Oscar Novo [mailto:oscar.novo@ericsson.com]=20 Sent: 14 April 2009 06:55 To: Duddy, Sean (Sean); xcon@ietf.org Subject: RE: [XCON] draft-ietf-xcon-common-data-model-13 Hi, =20 That's only a matter of configurability. A way to make possible to define different policies (must-join-before-offset, can-join-after-offset, ... ) for the same conference at different times. The specification of all the occurences in a single element is possible too as shown by the example in section 7. =20 Oscar =20 =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Duddy, Sean (Sean) Sent: 9. huhtikuuta 2009 18:28 To: xcon@ietf.org Subject: [XCON] draft-ietf-xcon-common-data-model-13 Hi folks, The XCON data model states that=20 =20 "The element contains one or more elements each defining the time information specifying a single conference occurrence." =20 Since an ICAL object can specify the complete timing information for all occurences belonging to a conference, why is this sequence of elements required?=20 =20 =20 Sean ------_=_NextPart_001_01C9BCED.7BE05ADD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Yes, I'll explain a bit better that section in = the previous=20 version of the draft
 
Thanks for your comment!
 
Oscar

From: Duddy, Sean (Sean)=20 [mailto:duddy@avaya.com]
Sent: 14. huhtikuuta 2009=20 12:34
To: Oscar Novo; xcon@ietf.org
Subject: RE: = [XCON]=20 draft-ietf-xcon-common-data-model-13

Hi Oscar,
    ok that sounds reasonable. = Should the=20 draft be updated to include the explanation = below?
 
Sean
From: = Oscar Novo=20 [mailto:oscar.novo@ericsson.com]
Sent: 14 April 2009=20 06:55
To: Duddy, Sean (Sean); xcon@ietf.org
Subject: = RE:=20 [XCON] draft-ietf-xcon-common-data-model-13

Hi,
 
That's only a matter of configurability. A = way to make=20 possible to define different policies (must-join-before-offset,=20 can-join-after-offset, ... ) for the same conference at different times. =
The specification of all the occurences in a = single element=20 is possible too as shown by the example in section = 7.
 
Oscar
 
 
From:=20 xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Duddy,=20 Sean (Sean)
Sent: 9. huhtikuuta 2009 18:28
To:=20 xcon@ietf.org
Subject: [XCON]=20 draft-ietf-xcon-common-data-model-13

Hi=20 folks,
    The XCON data model states that
 
"The <conference-time>
   = element=20 contains one or more <entry> elements each defining the=20 time
   information specifying a single conference=20 occurrence."
 
Since = an ICAL object=20 can specify the complete timing information for all=20 occurences
belonging to a=20 conference, why is this sequence of elements required? =
 
 
Sean
------_=_NextPart_001_01C9BCED.7BE05ADD-- From adam@nostrum.com Wed Apr 15 11:28:57 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0000F3A6BE9 for ; Wed, 15 Apr 2009 11:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTtaycrTyKax for ; Wed, 15 Apr 2009 11:28:56 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id DF1883A69F7 for ; Wed, 15 Apr 2009 11:28:55 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3FIU5f8083928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 13:30:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E627AD.7050304@nostrum.com> Date: Wed, 15 Apr 2009 13:30:05 -0500 From: Adam Roach User-Agent: Postbox 1.0b10 (Macintosh/2009032714) MIME-Version: 1.0 To: XCON-IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Alan Johnston Subject: [XCON] Minutes Posted / Milestones Updated X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 18:28:57 -0000 [as chair] Please review the minutes from the San Francisco face-to-face meeting, and submit any corrections or amendments you feel are appropriate to the chairs: http://www.ietf.org/proceedings/09mar/minutes/xcon.txt Based on modest support for adding a milestone to create a call-flows document, we have revised the charter to add one additional deliverable; see the final milestone here: http://www.ietf.org/html.charters/xcon-charter.html We have also rescheduled the remaining deliverables to reflect a more realistic timeframe, given the additional time taken up by the protocol changes from SOAP to REST to the current format. /a From duddy@avaya.com Thu Apr 16 02:24:06 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491353A6AE0 for ; Thu, 16 Apr 2009 02:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paEtuGCY7Ixj for ; Thu, 16 Apr 2009 02:24:05 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 29C273A6A53 for ; Thu, 16 Apr 2009 02:24:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,197,1238990400"; d="scan'208";a="158568482" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 16 Apr 2009 05:25:17 -0400 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Apr 2009 05:25:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 10:25:14 +0100 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F71CC4B40@306900ANEX2.global.avaya.com> In-Reply-To: <49E627AD.7050304@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Minutes Posted / Milestones Updated Thread-Index: Acm9+EKYdibGnabhR9GW7R8xzEOIRAAchhKg References: <49E627AD.7050304@nostrum.com> From: "Duddy, Sean (Sean)" To: "Adam Roach" , "XCON-IETF" Cc: Alan Johnston Subject: Re: [XCON] Minutes Posted / Milestones Updated X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 09:24:06 -0000 Hi Folks, Is this new callflow doc about CCMP callflows ? If yes, why is its publication date April 2010 and the ccmp August 09? I would have thought these end dates should be alligned... Here's my 2 cents about the issues highlighted in the 09Mar minutes:- Use Cases:-=20 There seems to be quiete a bit of time spent around cloning conferences and managing the behaviour of the subsequently created conferences, however I am not fully convinced of usefulness of this feature is. Typically every newly created conference will need a unique name,passcodes,user list, descriptions etc and would need to be specified by the client. Using the cloning method, this means two operations, which is not ideal. I envisage clients using blueprints as templates, i.e. they retrieve a particular template, make the relevant changes to it and then send it off in a=20 create request. I would like to see some use cases detailed for this scenario in the CCMP draft. Atomicity:- Regarding multiple users, atomicity does not apply. i.e. you can't rollback and start removing the newly added users if one user cant be added to the conference. I think for that specific use case, its best effort and typically it should be an asynchronous operation, i.e. the ccmp client should not be hung waiting on all people to get into the=20 Conference and instead it should be be notified as the users arrive into the conference.=20 Notifications:- CCMP notifications is yet to be defined/decided. I think xcon should separate the notification transport mechanism from the actual content and subscription mechanism. i.e. the content of the notfications should be no different for a ccmp client than a sip client, what is different is the transport protocol used to receive the notifications.=20 I think draft-ietf-xcon-event-package-01.txt should be changed to define the notification format for the data model and then have a separate section on how to receive these notifications via SIP. The CCMP draft then can reference this draft for the notification format and would need to specify how these notications should be received. Sean -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Adam Roach Sent: 15 April 2009 19:30 To: XCON-IETF Cc: Alan Johnston Subject: [XCON] Minutes Posted / Milestones Updated [as chair] Please review the minutes from the San Francisco face-to-face meeting, and submit any corrections or amendments you feel are appropriate to the chairs: http://www.ietf.org/proceedings/09mar/minutes/xcon.txt Based on modest support for adding a milestone to create a call-flows document, we have revised the charter to add one additional deliverable; see the final milestone here: http://www.ietf.org/html.charters/xcon-charter.html We have also rescheduled the remaining deliverables to reflect a more realistic timeframe, given the additional time taken up by the protocol changes from SOAP to REST to the current format. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From geir.sandbakken@tandberg.com Thu Apr 16 03:04:32 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAC43A6AE0 for ; Thu, 16 Apr 2009 03:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAhQ5rOHKxht for ; Thu, 16 Apr 2009 03:04:30 -0700 (PDT) Received: from mail194.messagelabs.com (mail194.messagelabs.com [85.158.140.211]) by core3.amsl.com (Postfix) with SMTP id 1EDA83A6A53 for ; Thu, 16 Apr 2009 03:04:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-8.tower-194.messagelabs.com!1239876301!27546569!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 14186 invoked from network); 16 Apr 2009 10:05:01 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-8.tower-194.messagelabs.com with SMTP; 16 Apr 2009 10:05:01 -0000 Received: from ultra.rd.tandberg.com ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 12:05:01 +0200 Received: from [10.47.19.175] (GSandbakkenT61.rd.tandberg.com [10.47.19.175]) by ultra.rd.tandberg.com (8.13.1/8.13.1) with ESMTP id n3GA4xdl027205; Thu, 16 Apr 2009 12:05:00 +0200 Message-ID: <49E702CC.2040207@tandberg.com> Date: Thu, 16 Apr 2009 12:05:00 +0200 From: Geir Arne Sandbakken User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <49DD8DED.3010908@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2009 10:05:01.0257 (UTC) FILETIME=[CE433B90:01C9BE7A] Cc: Gonzalo.Camarillo@ericsson.com, xcon-chairs@tools.ietf.org, xcon@ietf.org Subject: Re: [XCON] BFCP over UDP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 10:04:32 -0000 Markus, The are two main uses cases that lead to the deployment of BFCP over UDP. Firstly - as you mention - is when the focus resides behind a NAT. Many video conference endpoints can take the role as a focus mixing multiple calls. Also, enterprise deployments tend to place the bridges behind the corporate NATs. Secondly BFCP is utilized in vanilla p-t-p calls for presentation tokens control. Other motivations are that we want BFCP to work with ICE, and when you have taken the cost of setting up a BFCP server, client and possibly a turn resource - it is a very tempting to extend it for other uses as well. Geir Arne Markus.Isomaki@nokia.com wrote: > Hi Gonzalo, > > The problem with TCP and NATs usually stems from the scenario where both parties who want to communicate are behind a NAT. This is presumably often the case with P2PSIP. However, I've thought that BFCP would be typically deployed in a fashion where the conference focus (or the element managing the floor) would be hosted in a public address. In such a case TCP definitely works much better even if the conference participant would be behind a NAT. > > So, does the motivation for BFCP over UDP come from the requirement that the conference focus (the floor "manager") would itself need to be behind a NAT? This might be a valid requirement as such, when we think about endpoint hosted conferences. But even in those cases TCP could still work, if we assume that some infra like TURN-TCP or comedia/TCP aware SBCs (which we have discussed in SIMPLE lately) would be available. Again in P2PSIP the situation is different as they can't assume that kind of infra (the peers themselves need to provide it). So, I'm not sure if BFCP and P2PSIP requirements are identical. Unless you think about BFCP within a P2PSIP deployment. > > Sorry, I didn't attend the XCON session in San Francisco, this was probably well covered there. > > (I agree that there are many situations where defining how to tunnel/emulate TCP-like transport service over UDP. So, I think the best would be if TSV area could define one single solution and then protocols like P2PSIP, MSRP, BFCP etc. could use it.) > > Markus > > > > >> -----Original Message----- >> From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On >> Behalf Of ext Gonzalo Camarillo >> Sent: 09 April, 2009 08:56 >> To: XCON >> Cc: xcon-chairs@tools.ietf.org >> Subject: [XCON] BFCP over UDP >> >> Hi, >> >> the following (expired) draft was presented in the XCON session in San >> Francisco: >> >> http://www.watersprings.org/pub/id/draft-sandbakken-xcon-bfcp-u >> dp-00.txt >> >> The agreement was that given the problems TCP has with NATs >> (the P2PSIP WG is currently discussing the same issue) it >> would be a good idea to define a more NAT-friendly transport >> for BFCP. The proposal was to simply use UDP (this is what >> existing deployments do). >> >> Since BFCP messages can be rather long, we would need an >> applicability statement saying which types of messages cannot >> be used over UDP. >> >> In order to specify the new UDP-based transport we can either >> put together a new draft or revise the BFCP specification. I >> got the action point to list the things that could be fixed in >> a potential revised BFCP spec. These are the contents of my >> notes. Of course, if someone knows of more issues, please let us know: >> >> o When a user performs a third-party floor request the >> beneficiary of the floor is not informed when the floor is >> granted. This may not be a problem because endpoints using >> third-party floor requests probably have different means to >> get in synch but we may want to add some text about this. >> >> o We do not have errors for an unsupported version of the >> protocol or for wrong message length. We do not have a general >> error either. >> >> o When we get more experience on queue management from real >> deployments, it would be nice to explaining it further in the spec. >> >> o UserStatus >> >> UserStatus = (COMMON-HEADER) >> [BENEFICIARY-INFORMATION] >> 1*(FLOOR-REQUEST-INFORMATION) -> remove the 1 >> *[EXTENSION-ATTRIBUTE] >> >> o A message may need to be longer than the maximum message >> length supported by the protocol >> >> o A rather small number of typos >> >> >> As you can see, at this point there are not so many things to >> fix... so, the simplest way forward may be to simply specify a >> new UDP-based transport for BFCP. In any case, I would like to >> get feedback from folks operating BFCP deployments. >> >> A different alternative (the one the P2PSIP WG is looking at) >> would be to either use a UDP encapsulation for TCP or to >> specify a new transport protocol... but these alternatives may >> be more complex than just using UDP. >> >> Comments? >> >> Thanks, >> >> Gonzalo >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www.ietf.org/mailman/listinfo/xcon >> >> > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www.ietf.org/mailman/listinfo/xcon > From adam@nostrum.com Thu Apr 16 07:33:21 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FDE93A6F62 for ; Thu, 16 Apr 2009 07:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAGpzWjL2zJq for ; Thu, 16 Apr 2009 07:33:20 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 27EA43A6D4C for ; Thu, 16 Apr 2009 07:33:19 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3GEYTM1086308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 09:34:30 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E741F2.10501@nostrum.com> Date: Thu, 16 Apr 2009 09:34:26 -0500 From: Adam Roach User-Agent: Postbox 1.0b10 (Macintosh/2009032714) MIME-Version: 1.0 To: "Duddy, Sean (Sean)" References: <49E627AD.7050304@nostrum.com> <4408C6EC74CC3D42824FD68FDA8E8F71CC4B40@306900ANEX2.global.avaya.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71CC4B40@306900ANEX2.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Alan Johnston , XCON-IETF Subject: Re: [XCON] Minutes Posted / Milestones Updated X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 14:33:21 -0000 [as chair] Duddy, Sean (Sean) wrote: > Hi Folks, > Is this new callflow doc about CCMP callflows ? If yes, why is > its publication date April 2010 and > the ccmp August 09? I would have thought these end dates should be > alligned... > The logic here was that the callflows document depends on the protocol, but not the other way around (cf. RFC 3261 and RFC 3665). That said, we're happy to adjust the schedule according to working group consensus (subject to reality checks -- we may require additional people to commit to being authors before moving milestones earlier). Does anyone else want to weigh in on the timeline? > I think draft-ietf-xcon-event-package-01.txt should be changed... draft-ietf-xcon-event-package has been handed off to the IESG for publication. We could pull it back if we found a critical flaw. Retracting it for anything less would be considered unnecessarily disruptive. /a From geir.sandbakken@tandberg.com Thu Apr 16 08:33:45 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887873A6D7F for ; Thu, 16 Apr 2009 08:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljzqMWLZuT27 for ; Thu, 16 Apr 2009 08:33:43 -0700 (PDT) Received: from mail194.messagelabs.com (mail194.messagelabs.com [85.158.140.211]) by core3.amsl.com (Postfix) with SMTP id 755703A6AE8 for ; Thu, 16 Apr 2009 08:33:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-2.tower-194.messagelabs.com!1239895994!12753814!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 24199 invoked from network); 16 Apr 2009 15:33:14 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-2.tower-194.messagelabs.com with SMTP; 16 Apr 2009 15:33:14 -0000 Received: from ultra.rd.tandberg.com ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 17:33:14 +0200 Received: from [10.47.19.175] (GSandbakkenT61.rd.tandberg.com [10.47.19.175]) by ultra.rd.tandberg.com (8.13.1/8.13.1) with ESMTP id n3GFXDT1011071; Thu, 16 Apr 2009 17:33:14 +0200 Message-ID: <49E74FBA.6080600@tandberg.com> Date: Thu, 16 Apr 2009 17:33:14 +0200 From: Geir Arne Sandbakken User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Gonzalo Camarillo References: <49DD8DED.3010908@ericsson.com> In-Reply-To: <49DD8DED.3010908@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2009 15:33:14.0325 (UTC) FILETIME=[A83EF050:01C9BEA8] Cc: XCON , xcon-chairs@tools.ietf.org Subject: Re: [XCON] BFCP over UDP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 15:33:45 -0000 Gonzalo, The UDP usage draft does utilize transaction ids more and has a few extra messages to get reliable delivery. The changes are still very minor to the protocol itself and our implementation of it. IMHO having a single way of operating the protocol is better than having two different modes of operation. Also as mentioned in San Francisco it makes any intermediaries easier to implement only having to forward messages independent of transport. Can we do a bis? Geir Arne Gonzalo Camarillo wrote: > Hi, > > the following (expired) draft was presented in the XCON session in San > Francisco: > > http://www.watersprings.org/pub/id/draft-sandbakken-xcon-bfcp-udp-00.txt > > The agreement was that given the problems TCP has with NATs (the > P2PSIP WG is currently discussing the same issue) it would be a good > idea to define a more NAT-friendly transport for BFCP. The proposal > was to simply use UDP (this is what existing deployments do). > > Since BFCP messages can be rather long, we would need an applicability > statement saying which types of messages cannot be used over UDP. > > In order to specify the new UDP-based transport we can either put > together a new draft or revise the BFCP specification. I got the > action point to list the things that could be fixed in a potential > revised BFCP spec. These are the contents of my notes. Of course, if > someone knows of more issues, please let us know: > > o When a user performs a third-party floor request the beneficiary of > the floor is not informed when the floor is granted. This may not be a > problem because endpoints using third-party floor requests probably > have different means to get in synch but we may want to add some text > about this. > > o We do not have errors for an unsupported version of the protocol or > for wrong message length. We do not have a general error either. > > o When we get more experience on queue management from real > deployments, it would be nice to explaining it further in the spec. > > o UserStatus > > UserStatus = (COMMON-HEADER) > [BENEFICIARY-INFORMATION] > 1*(FLOOR-REQUEST-INFORMATION) -> remove the 1 > *[EXTENSION-ATTRIBUTE] > > o A message may need to be longer than the maximum message length > supported by the protocol > > o A rather small number of typos > > > As you can see, at this point there are not so many things to fix... > so, the simplest way forward may be to simply specify a new UDP-based > transport for BFCP. In any case, I would like to get feedback from > folks operating BFCP deployments. > > A different alternative (the one the P2PSIP WG is looking at) would be > to either use a UDP encapsulation for TCP or to specify a new > transport protocol... but these alternatives may be more complex than > just using UDP. > > Comments? > > Thanks, > > Gonzalo From bgdrums@sbcglobal.net Tue Apr 21 13:33:48 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D67CA28C3D0 for ; Tue, 21 Apr 2009 13:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT7v6rS+RA8c for ; Tue, 21 Apr 2009 13:33:48 -0700 (PDT) Received: from web83604.mail.sp1.yahoo.com (web83604.mail.sp1.yahoo.com [216.252.120.175]) by core3.amsl.com (Postfix) with SMTP id BC35428C3AB for ; Tue, 21 Apr 2009 13:33:07 -0700 (PDT) Received: (qmail 97202 invoked by uid 60001); 21 Apr 2009 20:34:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1240346064; bh=cX+nGl7WZkBnaxGian0tsdGrpFjnUdSNh1J5oagQE6I=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Mnu/1Ltc/GMcWmY1QYhtX9skUOdnwWiazfCjqGxuq7JnGzw+yxNBuzrmCKWVl3cQ99TwZKEiMlyP46Iavgcy6WiE4LdzIPJ9X4+ugogM3JAhoLCVlfX8OPaz8Yz4rj5OR3nXIQb3EDCX6eOzk4LndJvGWNrhppZB0w4N+sIpZRg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PaMfnymRkBUUXSEca7tJJ2gIOdxb0hoNegDoprtPjlX/qH5jaimj0o+SnXDWhZ5osyvDc/iI4itCOVsZDsfQZumcRgQzTQHf8RblZ+kxuyupVZElnKWchf24bSY8yf54Rz5b2AElUvw32FM2MRbNv2lCKeBwSJMkxhOTEm6t61M=; Message-ID: <734737.97173.qm@web83604.mail.sp1.yahoo.com> X-YMail-OSG: Sd8nrDAVM1ncNYI08cQ4vnUSNu.0bPzNzYSqyMnznyuloewb.fW0iGsG1y2qkzUarGgwqnMabsuwgRv4_4.Zdg0brL.lxofkbS_C4KzNgm283PWiCONF9jinOBBH19.UxDlgfdQ180_hB9w8noiFnMLY9.WCXWrGi37Ulu4mT81gC7Ncb.BVM4M9IOUoERK5MTR7GegzKsNVN3_889s0hnZz4xsPmapMBAtnAb9TJnjR_WravLB9xAcCkBq7_kkcwR.kgqdsE6toQ6M4CpFGbhjarJXLJKjpyNt0 Received: from [128.252.20.65] by web83604.mail.sp1.yahoo.com via HTTP; Tue, 21 Apr 2009 13:34:24 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Tue, 21 Apr 2009 13:34:24 -0700 (PDT) From: ZIA GHIASSI To: spromano@unina.it, Oscar Novo In-Reply-To: <9520E66537CC4941994C518E3E21091C474085@esealmw105.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1464902145-1240346064=:97173" Cc: xcon@ietf.org Subject: Re: [XCON] Cloning: Additional data in the data model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bgdrums@sbcglobal.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 20:33:48 -0000 --0-1464902145-1240346064=:97173 Content-Type: text/plain; charset=us-ascii My name is Andrew Ghiassi and I'm new to the Internet Draft subscription relpy. I've signed up for this draft becasue I find it the most interesting however I honestly don't understande where to go from here. I always receive e-mails regarding certain topics and would like to know how I can participate. some insight would be nice...thank you--Andrew --0-1464902145-1240346064=:97173 Content-Type: text/html; charset=us-ascii 

My name is Andrew Ghiassi and I'm new to the Internet Draft subscription relpy.  I've signed up for this draft becasue I find it the most interesting however I honestly don't understande where to go from here.  I always receive e-mails regarding certain topics and would like to know how I can participate. some insight would be nice...thank you--Andrew
--0-1464902145-1240346064=:97173-- From bgdrums@sbcglobal.net Wed Apr 22 23:59:41 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC6228C68C for ; Wed, 22 Apr 2009 23:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEzrhpMzlGIR for ; Wed, 22 Apr 2009 23:59:40 -0700 (PDT) Received: from web83605.mail.sp1.yahoo.com (web83605.mail.sp1.yahoo.com [216.252.120.176]) by core3.amsl.com (Postfix) with SMTP id 501AE28C696 for ; Wed, 22 Apr 2009 23:59:40 -0700 (PDT) Received: (qmail 87895 invoked by uid 60001); 23 Apr 2009 07:00:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1240470058; bh=j1R1T3i7bGNXGGY12Y3hZUyD17LhNn2zy94Cf7Xr6pw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=GsdP/1rNzIA7Big+uCUfwY750j8MHfgOjy71LoZAKmBaDzJXB6IA11kkUAX38clpMKYjhoQnS7qrhRK1g6PHn11OMncAxZOGhP6po8OjfmkzSx+TadPh/SbP+q1Q/iDcHHa15uhzK1uaarrI1surtaVfVJsdlojcFr6XfpIP0Sw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=mL3drp367/o+/luMCO8/WbFphmRzNLz07A/Wn7vWNHA29WMOLa7my2USB1+pi2AamCVswfhh+9VXuv9y5afmVribTv0C1C7mjR+KCt+9FzewaU157QuMXxnkK1aYLqO5L5rUB23YCY6oYUuvktnO6jDJq0SC/B8FK76OrXdnUxE=; Message-ID: <320924.86691.qm@web83605.mail.sp1.yahoo.com> X-YMail-OSG: IDMasTwVM1kHEtfyg9APu7CSI4WhBCkaoEOCW98iWdLhmbhOqhyxiM1mjD7BMwsumAwzEIy4pOT9bxHaLwge5tVnSBdVz8V.xBPMCyNH2f9UV5k0z6Yancr2BqfcDZwhnNJniI8Rs7FPjTGNW22SKHZgixuRcqzuOHqY1_KgSLC1vHUbzBpOH1wrxLeQC5Qyf82jfo5ICNrdPXf4y4szzRKf5gluUiS_A5bIctQMfvbD_zQMTNp4aXcIyh7nS0S3FQWQLf41J9C.YPphRZ8pRiYexImOOw8v.9xolafBHN9nmrJsc.0- Received: from [70.249.223.84] by web83605.mail.sp1.yahoo.com via HTTP; Thu, 23 Apr 2009 00:00:57 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Thu, 23 Apr 2009 00:00:57 -0700 (PDT) From: ZIA GHIASSI To: xcon@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-759313875-1240470057=:86691" Subject: [XCON] "Conference Information Data Model for Centralized Conferencing (XCON)" X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bgdrums@sbcglobal.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 06:59:41 -0000 --0-759313875-1240470057=:86691 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I just wanted to make sure that I was reading=A0"Figure=A01"=A0correctly si= nce I'm not exactly sure how to read these diagrams.=A0 This isn't the firs= t time I've seen diagrams like these in internet drafts so some insight wou= ld be helpful..To begin, it seems as though the conferencing client has con= trol over the 4 protocols: conference,floor, call signaling, and=A0notifica= tion; each which do a different task.=A0 These 4 protocols are then linked = to their respective servers which relay the information to the conference o= bject...From here is it saying that=A0each conference object contains the c= onference information data model show beneath it?=A0 If this is true then t= he conference object would contain informaion about its duration, times, ho= st info, membership, ets...Please let me know If I'm reading this correctly= ..Thank you --Andrew Ghiassi =A0 =A0=A0=A0=A0 --0-759313875-1240470057=:86691 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I just wanted to make sure that I was re= ading "Figure 1" correctly since I'm not exactly sure how to= read these diagrams.  This isn't the first time I've seen diagrams li= ke these in internet drafts so some insight would be helpful..To begin, it = seems as though the conferencing client has control over the 4 protocols: c= onference,floor, call signaling, and notification; each which do a dif= ferent task.  These 4 protocols are then linked to their respective se= rvers which relay the information to the conference object...From here is i= t saying that each conference object contains the conference informati= on data model show beneath it?  If this is true then the conference ob= ject would contain informaion about its duration, times, host info, members= hip, ets...Please let me know If I'm reading this correctly..Thank you --Andrew Ghiassi
 
    
--0-759313875-1240470057=:86691-- From mary.barnes@nortel.com Thu Apr 23 06:45:24 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115F628C6C5 for ; Thu, 23 Apr 2009 06:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtOJIzLduDM5 for ; Thu, 23 Apr 2009 06:45:23 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0B6DF3A7293 for ; Thu, 23 Apr 2009 06:41:37 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3NDg4c03042; Thu, 23 Apr 2009 13:42:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C419.5C5BDA49" Date: Thu, 23 Apr 2009 08:45:25 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D9A0706@zrc2hxm0.corp.nortel.com> In-Reply-To: <320924.86691.qm@web83605.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] "Conference Information Data Model for CentralizedConferencing (XCON)" Thread-Index: AcnD4UP8Yibo+/W9QUKKmtBdLhG8VwAOEOpQ References: <320924.86691.qm@web83605.mail.sp1.yahoo.com> From: "Mary Barnes" To: , Subject: Re: [XCON] "Conference Information Data Model for CentralizedConferencing (XCON)" X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 13:45:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C419.5C5BDA49 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, you are reading the diagram correctly. You might find it helpful to read the XCON FW (RFC 5239) if you have not already as that gives more background and description of the core functional elements, but youre interpretation is correct =20 Regards, Mary.=20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of ZIA GHIASSI Sent: Thursday, April 23, 2009 2:01 AM To: xcon@ietf.org Subject: [XCON] "Conference Information Data Model for CentralizedConferencing (XCON)" I just wanted to make sure that I was reading "Figure 1" correctly since I'm not exactly sure how to read these diagrams. This isn't the first time I've seen diagrams like these in internet drafts so some insight would be helpful..To begin, it seems as though the conferencing client has control over the 4 protocols: conference,floor, call signaling, and notification; each which do a different task. These 4 protocols are then linked to their respective servers which relay the information to the conference object...From here is it saying that each conference object contains the conference information data model show beneath it? If this is true then the conference object would contain informaion about its duration, times, host info, membership, ets...Please let me know If I'm reading this correctly..Thank you --Andrew Ghiassi =20 =20 ------_=_NextPart_001_01C9C419.5C5BDA49 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes,=20 you are reading the diagram correctly. You might find it helpful to read = the=20 XCON FW (RFC 5239) if you have not already as that gives more background = and=20 description of the core functional elements, but youre interpretation is = correct
 
Regards,
Mary.=20

From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of ZIA = GHIASSI
Sent:=20 Thursday, April 23, 2009 2:01 AM
To: = xcon@ietf.org
Subject:=20 [XCON] "Conference Information Data Model for CentralizedConferencing=20 (XCON)"

I just wanted to make sure that I was=20 reading "Figure 1" correctly since I'm not exactly = sure how=20 to read these diagrams.  This isn't the first time I've seen = diagrams=20 like these in internet drafts so some insight would be helpful..To = begin,=20 it seems as though the conferencing client has control over the 4=20 protocols: conference,floor, call signaling, = and notification; each=20 which do a different task.  These 4 protocols are then linked = to=20 their respective servers which relay the information to the = conference=20 object...From here is it saying that each conference object = contains=20 the conference information data model show beneath it?  If = this is=20 true then the conference object would contain informaion about its = duration, times, host info, membership, ets...Please let me know = If I'm=20 reading this correctly..Thank you --Andrew Ghiassi
 
=
    
------_=_NextPart_001_01C9C419.5C5BDA49-- From mary.barnes@nortel.com Fri Apr 24 12:50:16 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64CC028C304 for ; Fri, 24 Apr 2009 12:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E9cy2cUnV8c for ; Fri, 24 Apr 2009 12:50:13 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5A90428C2FC for ; Fri, 24 Apr 2009 12:50:13 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3OJpSg15098; Fri, 24 Apr 2009 19:51:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C515.EF58AFF5" Date: Fri, 24 Apr 2009 14:53:23 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DA43DAE@zrc2hxm0.corp.nortel.com> In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F71CC47E1@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] draft-ietf-xcon-ccmp-02 Thread-Index: Acm5M98e7gETULKqSbWOTusB05xVygL3dMKw References: <4408C6EC74CC3D42824FD68FDA8E8F71CC47E1@306900ANEX2.global.avaya.com> From: "Mary Barnes" To: "Duddy, Sean (Sean)" , Subject: Re: [XCON] draft-ietf-xcon-ccmp-02 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:50:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C515.EF58AFF5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sean, =20 Apologies, as I can't see that anyone ever responded to your question. Yes, the server would be the one to populate the element. Per the XCON framework this is information that would be part of the blueprint. =20 =20 There is a for each element that contains the type of media and a element in the data model that contain basic video and audio controls. For each there is a element in the data model to capture the source of media(/ for a specific endpoint. These types are all borrowed from RFC 4575, so they are not described in the xcon data-model document.=20 =20 And, there are specific media control elements for floor control. =20 =20 When a client is joining a conference, the setup of a specific media type would be negotiated between the signaling and media control client (e.g., SIP client) and the focus. And, something like the mediactrl protocol could be used, which is what is shown in the call flows document: http://tools.ietf.org/id/draft-barnes-xcon-examples-01.txt =20 Does that answer your question? =20 Regards, Mary.=20 =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Duddy, Sean (Sean) Sent: Thursday, April 09, 2009 11:55 AM To: xcon@ietf.org Subject: [XCON] draft-ietf-xcon-ccmp-02 Hi Folks, How does a ccmp client request a specify media type for its conference (e.g. audio or audio+video or video only)?=20 =20 Th data model has an element but only the server has the=20 information to populate this (http://tools.ietf.org/html/rfc4575#section-5.3.4) and the definition of this element alone implies what media is available and not=20 how to request a specific media... =20 Regards Sean ------_=_NextPart_001_01C9C515.EF58AFF5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Sean,
 
Apologies, as I can't see that anyone ever = responded to=20 your question.   Yes, the server would be the one to populate = the=20 <available-media> element. Per the XCON framework this is = information that=20 would be part of the blueprint. 
 
There=20 is a <mixer-type> for each <user> element that contains the = type of=20 media and a <controls> element in the data model that contain = basic video=20 and audio controls.  For each <endpoint> there is a=20 <media> element in the data model to capture the source of=20 media(<to-mixer>/<from-mixer>  for a specific = endpoint. =20 These types are all borrowed from RFC 4575, so they are not described in = the=20 xcon data-model document.
 
And,=20 there are specific media control elements for floor control. =20
 
When a=20 client is joining a conference, the setup of a specific media type would = be=20 negotiated between the signaling and media control client = (e.g., SIP=20 client) and the focus.  And, something like the mediactrl protocol = could be=20 used, which is what is shown in the call flows = document:
http:= //tools.ietf.org/id/draft-barnes-xcon-examples-01.txt
 
Does=20 that answer your question?
 
Regards,
Mary.=20
 
From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of Duddy, Sean=20 (Sean)
Sent: Thursday, April 09, 2009 11:55 AM
To:=20 xcon@ietf.org
Subject: [XCON]=20 draft-ietf-xcon-ccmp-02

Hi=20 Folks,
    How does a ccmp client request a specify media type for its=20 conference
(e.g. = audio or=20 audio+video or video only)?
 
Th = data model has an=20 <available-media> element but only the server has the =
information to=20 populate this (http://tools.ie= tf.org/html/rfc4575#section-5.3.4)
and = the definition=20 of this element alone implies what media is available and not=20
how to = request a=20 specific media...
 
Regards
Sean
------_=_NextPart_001_01C9C515.EF58AFF5-- From michael.p.bober@gmail.com Mon Apr 27 10:10:34 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68953A6B3B for ; Mon, 27 Apr 2009 10:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oi3+OTWQZvY3 for ; Mon, 27 Apr 2009 10:10:34 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id DD97B3A6B01 for ; Mon, 27 Apr 2009 10:10:33 -0700 (PDT) Received: by ewy24 with SMTP id 24so40042ewy.37 for ; Mon, 27 Apr 2009 10:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=W7asdA96YOc0plxO/D5zCrW2fIJPubeY4sEZH+aIFnA=; b=Qa0HDq2z5nEc9H/BIzm4yP14CRKTjTtmuz9c3EdtBL9sJAC+Wp9TyRrp29I9p39cUA spWNU+5mn8KGcz9iN2InEdkSpnTysYsufW/D8k5z+u5Pz5ZGuBEzY8bXIykm5X3jVCEw W0+KCnCyRDd67lT6u+OXH9qT1737d7ToucAxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=RGlR2rWophfWf7oX8A+CZD2ehI9I9I8NNfE2TBs/OhbbWUw6p8f8TmHD4FIA0pIMSc b45P0tI7HzaNvYlpaFrVWQOl249b54/H8DNyDzl/bXkOUL2tGJ20PXRN0BzhLUgBkXmB Pz1fLTv1vziA6ZhrBrgKbrPsb6AaeszPk3Lpo= MIME-Version: 1.0 Received: by 10.216.1.69 with SMTP id 47mr581098wec.224.1240852313764; Mon, 27 Apr 2009 10:11:53 -0700 (PDT) Date: Mon, 27 Apr 2009 12:11:53 -0500 Message-ID: From: Michael Bober To: xcon@ietf.org Content-Type: multipart/alternative; boundary=0016364d293361751804688c71a0 Cc: alan@sipstation.com Subject: [XCON] Section 8.2 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 17:17:36 -0000 --0016364d293361751804688c71a0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Section 8.2 discusses confidentiality, and it seems that encryption and end-to-end authentication provide the most protection for XCON. Since hacking has been quite newsworthy in the recent weeks, I am interested to know what kind of attack XCON would be susceptible to, if any. Michael Bober --0016364d293361751804688c71a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Section 8.2 discusses confidentiality, and it seems that encryption and
end-to-end authentication provide the most protection for XCON.  Since
hacking has been quite newsworthy in the recent weeks, I am interested to
know what kind of attack XCON would be susceptible to, if any.

Michael Bober
--0016364d293361751804688c71a0-- From michael.p.bober@gmail.com Mon Apr 27 10:38:17 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E973A6DC9 for ; Mon, 27 Apr 2009 10:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMeE1dKgZFOu for ; Mon, 27 Apr 2009 10:38:17 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id AA2E03A6C66 for ; Mon, 27 Apr 2009 10:38:16 -0700 (PDT) Received: by ewy24 with SMTP id 24so57044ewy.37 for ; Mon, 27 Apr 2009 10:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Z2pPrqANSFYw9026RSoGPMDFAdjj8BESxZyOQ8sZhTo=; b=sBuAtL96/s05J3tVPhs4dBIZ1TlEWI2HUP30fheykIqU1AXQdx7zFUkrCZWNXrbeTQ +OK4Hol8YEwfacR+aG9BK7j3K9ulF/cKutKf5A8W5tHCS58EBE4TfRTMkTh1pO5G9L/k EfQMRcZq5pyr8XpXwfkqzICq/vEyhlAxmWa0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DoNIKkS1+DDEGwxwC1IKjqGmqZYXFa6RhQHFnwILb2ABBojkWb8Splyh8Fco/AxX12 e2zexWKuF4w7JAeiP89GSkj5gQ8HYXvoHVZJOqXTyzRxugNN+pJaCR16EYc3A5xTD6b+ sCsmTHW8KyrIUY7G5up1ZlUBQ3TfWMofz+Meo= MIME-Version: 1.0 Received: by 10.216.7.133 with SMTP id 5mr612789wep.32.1240853976822; Mon, 27 Apr 2009 10:39:36 -0700 (PDT) Date: Mon, 27 Apr 2009 12:39:36 -0500 Message-ID: From: Michael Bober To: xcon@ietf.org Content-Type: multipart/alternative; boundary=0016364c7e7f81b4a404688cd411 Subject: [XCON] correction to section 8.2 question X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 17:38:17 -0000 --0016364c7e7f81b4a404688cd411 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To clarify, the following question I submitted was in refference to "draft-ietf-xcon-common-data-model-13.txt": Section 8.2 discusses confidentiality, and it seems that encryption and end-to-end authentication provide the most protection for XCON. Since hacking has been quite newsworthy in the recent weeks, I am interested to know what kind of attack XCON would be susceptible to, if any. Michael Bober --0016364c7e7f81b4a404688cd411 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
To clarify, the following qu= estion I submitted was in refference to "draft-ietf-xcon-common-data-m= odel-13.txt":
=A0
Section 8.2 discusses confid= entiality, and it seems that encryption and
end-to-end authentication pr= ovide the most protection for XCON.=A0 Since
hacking has been quite news= worthy in the recent weeks, I am interested to
know what kind of attack XCON would be susceptible to, if any.

Michael Bober

--0016364c7e7f81b4a404688cd411-- From jn8@cec.wustl.edu Mon Apr 27 10:56:41 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962703A6A7A for ; Mon, 27 Apr 2009 10:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAN-IkGbx1kP for ; Mon, 27 Apr 2009 10:56:40 -0700 (PDT) Received: from mail.cec.wustl.edu (express.cec.wustl.edu [128.252.21.16]) by core3.amsl.com (Postfix) with ESMTP id DB55F3A687D for ; Mon, 27 Apr 2009 10:56:40 -0700 (PDT) Received: from webmail.cec.wustl.edu (localhost.localdomain [127.0.0.1]) by mail.cec.wustl.edu (Postfix) with ESMTP id 39C461E808B; Mon, 27 Apr 2009 12:58:01 -0500 (CDT) Received: from 172.16.1.133 (SquirrelMail authenticated user jn8) by webmail.cec.wustl.edu with HTTP; Mon, 27 Apr 2009 12:58:01 -0500 (CDT) Message-ID: <7d40a9e921990cdff6b08f7815c2ca0c.squirrel@webmail.cec.wustl.edu> Date: Mon, 27 Apr 2009 12:58:01 -0500 (CDT) From: jn8@cec.wustl.edu To: xcon@ietf.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: alan@sipstation.com Subject: [XCON] (no subject) X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:00:10 -0000 I have a question reguarding Conference Information Data Model for Centralized Conferencing (XCON)draft-ietf-xcon-common-data-model-13.txt Internet-Draft. Section 8.2 talks a little bit about confidentiality. Is the intent of this section to allow (say any two) members of a certain confererance to maintain a private discussion in which the other members of the same conference would not be privy to? If so would the participants interested (or allowed) to join to prvate conversation be required to reauthenticate, and renegotiate encryption? Also if this capability were implemented, would there be in upper limit to number of private conversations allowed in the conferance, or a limited of the amount of nesting (e.g. private converstaions within private conversations with ...)that would be possible? Thank you, Johnathon Ney From adam.lee.person@gmail.com Mon Apr 27 13:48:15 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529E528C19F for ; Mon, 27 Apr 2009 13:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jl-cDzHw6X5 for ; Mon, 27 Apr 2009 13:48:13 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 0DBE028C1D0 for ; Mon, 27 Apr 2009 13:45:57 -0700 (PDT) Received: by bwz7 with SMTP id 7so155463bwz.37 for ; Mon, 27 Apr 2009 13:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=PkWjlMZsFh3JR/6klG14RrG5HsM38/V1waA8wTS0VYo=; b=NYQo2xkPyhrNIKwgtaIzmP3FNvOcmSSgrtNJfNesk1aoCpz9gq8ZAR3A/eGBU+iFAj GctS81QTFMgI0OS/7e4WUXLGoykCBT5l9S9HkPEEmb0W/WnEjYYdSWqFVZnrUUPdqvpH tzV61sz3CurimZ7dIf3pLrQh8qZeka6wXtc1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=EpX2cub0DfhWd+qY6F8undvrqS+Xt+Ro0BZfNJcxC6GWEp1WKIXo+OvpBJrd1t+kQL iHLHm/zO+mLq1bfSO3+pZ3ks9EWMFvIn0+58ZKViY5zVHQ3EbCxFncE0BNj7C4ssI/QM YxARZQmxRpoixEuYNxTF0LbLodKiommcT3Lc4= MIME-Version: 1.0 Received: by 10.223.117.194 with SMTP id s2mr2046796faq.83.1240865238094; Mon, 27 Apr 2009 13:47:18 -0700 (PDT) Date: Mon, 27 Apr 2009 15:47:18 -0500 Message-ID: From: Adam Harbaugh To: xcon@ietf.org Content-Type: multipart/alternative; boundary=001636c5b47ebb134a04688f73a4 Cc: alan@sipstation.com Subject: [XCON] Centralized Conferencing Manipulation Protocol X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:16:51 -0000 --001636c5b47ebb134a04688f73a4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit My question refers specifically to the implementation part of CCMP. I was wondering if all firmware on user agents would have to be updated before this protocol can be used or is this still compatible with the current version of SIP. Also, what is new about this protocol? I thought current conferencing already had the ability to modify the enviroment? --001636c5b47ebb134a04688f73a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My question refers specifically to the implementation part of CCMP.=A0= I was wondering if all firmware on user agents would have to be updated be= fore this protocol can be used or is this still compatible with the current= version of SIP.=A0 Also, what is new about this protocol?=A0 I thought cur= rent conferencing already had the ability to modify the enviroment?
--001636c5b47ebb134a04688f73a4-- From oscar.novo@ericsson.com Tue Apr 28 00:32:00 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9865F3A7079 for ; Tue, 28 Apr 2009 00:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.062 X-Spam-Level: X-Spam-Status: No, score=-6.062 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o5gF+rWqeFi for ; Tue, 28 Apr 2009 00:31:59 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 61B443A6B18 for ; Tue, 28 Apr 2009 00:31:59 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb8ae000006a07-53-49f6b13f84da Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 32.C7.27143.F31B6F94; Tue, 28 Apr 2009 09:33:19 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 09:33:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 09:33:18 +0200 Message-ID: <9520E66537CC4941994C518E3E21091CF688F1@esealmw105.eemea.ericsson.se> In-Reply-To: <7d40a9e921990cdff6b08f7815c2ca0c.squirrel@webmail.cec.wustl.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] (no subject) thread-index: AcnHYjPHd4rtItrMTdiLOzeWEmA3JwAcKMNA References: <7d40a9e921990cdff6b08f7815c2ca0c.squirrel@webmail.cec.wustl.edu> From: "Oscar Novo" To: , X-OriginalArrivalTime: 28 Apr 2009 07:33:19.0118 (UTC) FILETIME=[99EC0AE0:01C9C7D3] X-Brightmail-Tracker: AAAAAA== Cc: alan@sipstation.com Subject: Re: [XCON] (no subject) X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 07:32:00 -0000 Hello Johnathon, I think you have the answers to your question in the document "A Framework for Centralized Conferencing" (draft-ietf-xcon-framework-11). I suggest you to read Section 9.6 "Whispering or Private Messages" and section 11.1. "User Authentication and Authorization" Actually, I recommend you to go through this document to get a better understanding of the data model. Cheers, Oscar =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of jn8@cec.wustl.edu Sent: 27. huhtikuuta 2009 20:58 To: xcon@ietf.org Cc: alan@sipstation.com Subject: [XCON] (no subject) I have a question reguarding Conference Information Data Model for Centralized Conferencing (XCON)draft-ietf-xcon-common-data-model-13.txt Internet-Draft. Section 8.2 talks a little bit about confidentiality. Is the intent of this section to allow (say any two) members of a certain confererance to maintain a private discussion in which the other members of the same conference would not be privy to? If so would the participants interested (or allowed) to join to prvate conversation be required to reauthenticate, and renegotiate encryption? Also if this capability were implemented, would there be in upper limit to number of private conversations allowed in the conferance, or a limited of the amount of nesting (e.g. private converstaions within private conversations with ...)that would be possible? Thank you, Johnathon Ney _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From oscar.novo@ericsson.com Tue Apr 28 00:47:00 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83ECA3A6B10 for ; Tue, 28 Apr 2009 00:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VQgA1Hy21dK for ; Tue, 28 Apr 2009 00:46:59 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CC6453A680A for ; Tue, 28 Apr 2009 00:46:57 -0700 (PDT) X-AuditID: c1b4fb3c-b7b4bae000001105-47-49f6b4c1da61 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 85.2A.04357.1C4B6F94; Tue, 28 Apr 2009 09:48:17 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 09:48:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C7D5.B11C1513" Date: Tue, 28 Apr 2009 09:48:16 +0200 Message-ID: <9520E66537CC4941994C518E3E21091CF6894D@esealmw105.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] correction to section 8.2 question thread-index: AcnHXyUdmulckgLzRuKgIj+uMnEHbAAdL4Yw References: From: "Oscar Novo" To: "Michael Bober" , X-OriginalArrivalTime: 28 Apr 2009 07:48:17.0398 (UTC) FILETIME=[B156B160:01C9C7D5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [XCON] correction to section 8.2 question X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 07:47:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C7D5.B11C1513 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, I haven't think myself in all the possible attacks but the most important ones related to confidentiality could be: =20 - An attacker may attempt to get access to confidential information from eavesdropping. =20 - An attacker may attempt to modify the messages exchange btw the client and server (that's more related to integrity though) =20 Oscar =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Michael Bober Sent: 27. huhtikuuta 2009 20:40 To: xcon@ietf.org Subject: [XCON] correction to section 8.2 question =20 To clarify, the following question I submitted was in refference to "draft-ietf-xcon-common-data-model-13.txt": =20 Section 8.2 discusses confidentiality, and it seems that encryption and end-to-end authentication provide the most protection for XCON. Since hacking has been quite newsworthy in the recent weeks, I am interested to know what kind of attack XCON would be susceptible to, if any. Michael Bober ------_=_NextPart_001_01C9C7D5.B11C1513 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Well, I haven't think myself in all the = possible=20 attacks but the most important ones related to confidentiality could=20 be:
 
- An attacker may attempt to get access to = confidential=20 information from eavesdropping.
 
- An attacker may attempt to modify the = messages=20 exchange btw the client and server (that's more related to integrity=20 though)
 
Oscar

 
From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of Michael = Bober
Sent:=20 27. huhtikuuta 2009 20:40
To: xcon@ietf.org
Subject: = [XCON]=20 correction to section 8.2 question

 
To clarify, the following = question=20 I submitted was in refference to=20 "draft-ietf-xcon-common-data-model-13.txt":
 
Section 8.2 discusses=20 confidentiality, and it seems that encryption and
end-to-end = authentication=20 provide the most protection for XCON.  Since
hacking has been = quite=20 newsworthy in the recent weeks, I am interested to
know what kind of = attack=20 XCON would be susceptible to, if any.

Michael=20 Bober

------_=_NextPart_001_01C9C7D5.B11C1513-- From alfred.heggestad@telio.no Tue Apr 28 04:27:33 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E343C3A6C14 for ; Tue, 28 Apr 2009 04:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5zrFrembg-f for ; Tue, 28 Apr 2009 04:27:33 -0700 (PDT) Received: from hq-smtp-01.telio.no (hq-smtp-01.telio.no [82.196.203.118]) by core3.amsl.com (Postfix) with ESMTP id EFC913A6C0A for ; Tue, 28 Apr 2009 04:27:32 -0700 (PDT) Received: from [192.168.1.108] (unknown [192.168.1.108]) by hq-smtp-01.telio.no (Postfix) with ESMTP id E102E19474C for ; Tue, 28 Apr 2009 13:29:39 +0200 (CEST) Message-ID: <49F6E85A.5020306@telio.no> Date: Tue, 28 Apr 2009 13:28:26 +0200 From: "Alfred E. Heggestad" User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 28 Apr 2009 06:39:43 -0700 Subject: [XCON] BFCP over UDP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 11:27:59 -0000 Hi we are supporting this draft: http://tools.ietf.org/html/draft-sandbakken-xcon-bfcp-udp-00 we are running endpoints with BFCP/UDP in our network today, which is also working behind NAT due to SBC in network (SER+RTPproxy). it was not an option for us to run BFCP over TCP, since this is not working at all with endpoints behind NAT. I also supports Geir Arne's view on BFCP/UDP for usage with ICE. -- Alfred E. Heggestad - Telio AS phone: +47 21 96 91 42 mobile: +47 488 99 658 jabber: alfredh@jabber.org From mary.barnes@nortel.com Tue Apr 28 06:51:38 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234753A70B7 for ; Tue, 28 Apr 2009 06:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBpGiMP3T5QU for ; Tue, 28 Apr 2009 06:51:37 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 433BB3A70C7 for ; Tue, 28 Apr 2009 06:50:44 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3SDq2v05318; Tue, 28 Apr 2009 13:52:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C808.6D82DFF5" Date: Tue, 28 Apr 2009 08:54:13 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DAFD995@zrc2hxm0.corp.nortel.com> In-Reply-To: <9520E66537CC4941994C518E3E21091CF6894D@esealmw105.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] correction to section 8.2 question Thread-Index: AcnHXyUdmulckgLzRuKgIj+uMnEHbAAdL4YwAAzdKZA= References: <9520E66537CC4941994C518E3E21091CF6894D@esealmw105.eemea.ericsson.se> From: "Mary Barnes" To: "Michael Bober" , Subject: Re: [XCON] correction to section 8.2 question X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 13:51:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C808.6D82DFF5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael, =20 The XCON FW (RFC 5239) provides an overview of the potential attacks for XCON, as well as some basic security mechanisms that should be supported by a conferencing system and conferencing client.=20 =20 We will need to provide a detailed description of the security solution for the XCON protocol in the CCMP protocol document: http://tools.ietf.org/id/draft-ietf-xcon-ccmp-02.txt =20 Since the protocol is based on HTTP(S), we will be relying on some of the HTTP security mechanisms.=20 =20 We'll be updating the security section in the next revision and will take your comment into consideration and we'd appreciate additional feedback once we submit the revision. =20 Thanks, Mary.=20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Oscar Novo Sent: Tuesday, April 28, 2009 2:48 AM To: Michael Bober; xcon@ietf.org Subject: Re: [XCON] correction to section 8.2 question Well, I haven't think myself in all the possible attacks but the most important ones related to confidentiality could be: =20 - An attacker may attempt to get access to confidential information from eavesdropping. =20 - An attacker may attempt to modify the messages exchange btw the client and server (that's more related to integrity though) =20 Oscar =20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Michael Bober Sent: 27. huhtikuuta 2009 20:40 To: xcon@ietf.org Subject: [XCON] correction to section 8.2 question =20 To clarify, the following question I submitted was in refference to "draft-ietf-xcon-common-data-model-13.txt": =20 Section 8.2 discusses confidentiality, and it seems that encryption and end-to-end authentication provide the most protection for XCON. Since hacking has been quite newsworthy in the recent weeks, I am interested to know what kind of attack XCON would be susceptible to, if any. Michael Bober ------_=_NextPart_001_01C9C808.6D82DFF5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Michael,
 
The=20 XCON FW (RFC 5239)  provides an overview of the potential attacks = for XCON,=20 as well as some basic security mechanisms that should be supported by a=20 conferencing system and conferencing client.
 
We=20 will need to provide a detailed description of the security solution for = the=20 XCON protocol in the CCMP protocol document:
http://tool= s.ietf.org/id/draft-ietf-xcon-ccmp-02.txt
 
Since=20 the protocol is based on HTTP(S), we will be relying on some of the HTTP = security mechanisms.
 
We'll=20 be updating the security section in the next revision and will take your = comment=20 into consideration and we'd appreciate additional feedback once we = submit the=20 revision.
 
Thanks,
Mary.=20

From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of Oscar = Novo
Sent:=20 Tuesday, April 28, 2009 2:48 AM
To: Michael Bober;=20 xcon@ietf.org
Subject: Re: [XCON] correction to section 8.2=20 question

Well, I haven't think myself in all the = possible=20 attacks but the most important ones related to confidentiality could=20 be:
 
- An attacker may attempt to get access to = confidential=20 information from eavesdropping.
 
- An attacker may attempt to modify the = messages=20 exchange btw the client and server (that's more related to integrity=20 though)
 
Oscar

 
From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of Michael = Bober
Sent:=20 27. huhtikuuta 2009 20:40
To: xcon@ietf.org
Subject: = [XCON]=20 correction to section 8.2 question

 
To clarify, the following = question=20 I submitted was in refference to=20 "draft-ietf-xcon-common-data-model-13.txt":
 
Section 8.2 discusses=20 confidentiality, and it seems that encryption and
end-to-end = authentication=20 provide the most protection for XCON.  Since
hacking has been = quite=20 newsworthy in the recent weeks, I am interested to
know what kind of = attack=20 XCON would be susceptible to, if any.

Michael=20 Bober

------_=_NextPart_001_01C9C808.6D82DFF5-- From mary.barnes@nortel.com Tue Apr 28 08:38:49 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A903A70BA for ; Tue, 28 Apr 2009 08:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UqUKY5ajsyg for ; Tue, 28 Apr 2009 08:38:48 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2F3353A6D26 for ; Tue, 28 Apr 2009 08:38:48 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3SFe3v24159; Tue, 28 Apr 2009 15:40:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C817.96E1C2CB" Date: Tue, 28 Apr 2009 10:42:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DAFDD8B@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Centralized Conferencing Manipulation Protocol Thread-Index: AcnHfa/80wCsw9L4R7moeYAqu+eksgAmUyQg References: From: "Mary Barnes" To: "Adam Harbaugh" , Cc: alan@sipstation.com Subject: Re: [XCON] Centralized Conferencing Manipulation Protocol X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:38:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C817.96E1C2CB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A client that has not implemented CCMP (i.e., a SIP client that supports the SIP Conferencing Framework (RFC 4353) and SIP conferencing UA functionality (RFC 4579) ) can still participate in a conference that is based on the XCON FW and that also supports clients that have implemented CCMP. This is discussed in section 10 of the XCON FW (RFC 5239): =20 "User agents that only support [RFC4579] and do not support the Conferencing Control Protocol are still provided basic SIP conferencing, but cannot take advantage of any of the advanced features." =20 Mary.=20 ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Adam Harbaugh Sent: Monday, April 27, 2009 3:47 PM To: xcon@ietf.org Cc: alan@sipstation.com Subject: [XCON] Centralized Conferencing Manipulation Protocol My question refers specifically to the implementation part of CCMP. I was wondering if all firmware on user agents would have to be updated before this protocol can be used or is this still compatible with the current version of SIP. Also, what is new about this protocol? I thought current conferencing already had the ability to modify the enviroment? ------_=_NextPart_001_01C9C817.96E1C2CB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
A=20 client that has not implemented CCMP (i.e., a SIP client that = supports the=20 SIP Conferencing Framework (RFC 4353) and SIP conferencing UA=20 functionality (RFC 4579) ) can still participate in a conference = that is=20 based on the XCON FW and that also supports clients that have = implemented=20 CCMP.   This is discussed in section 10 of the XCON = FW (RFC=20 5239):
 
   "User agents that only = support=20 [RFC4579] and do not
   support the Conferencing Control = Protocol=20 are still provided basic
   SIP conferencing, but cannot = take=20 advantage of any of the advanced
   = features."
 
Mary.=20

From: xcon-bounces@ietf.org=20 [mailto:xcon-bounces@ietf.org] On Behalf Of Adam = Harbaugh
Sent:=20 Monday, April 27, 2009 3:47 PM
To: xcon@ietf.org
Cc: = alan@sipstation.com
Subject: [XCON] Centralized Conferencing=20 Manipulation Protocol

My question refers specifically to the implementation part of = CCMP.  I=20 was wondering if all firmware on user agents would have to be updated = before=20 this protocol can be used or is this still compatible with the current = version=20 of SIP.  Also, what is new about this protocol?  I thought = current=20 conferencing already had the ability to modify the=20 enviroment?
------_=_NextPart_001_01C9C817.96E1C2CB--