From xcon-bounces@ietf.org Mon Apr 02 02:34:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYG7A-0004lN-Qi; Mon, 02 Apr 2007 02:34:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYG78-0004kN-S0; Mon, 02 Apr 2007 02:34:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYG71-0002YE-5b; Mon, 02 Apr 2007 02:34:02 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6BB5F213A1; Mon, 2 Apr 2007 08:33:42 +0200 (CEST) X-AuditID: c1b4fb3e-ad1e9bb0000061ca-b3-4610a3c6819d Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4B2562122C; Mon, 2 Apr 2007 08:33:42 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 08:33:41 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 08:33:41 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1915A2358; Mon, 2 Apr 2007 09:33:41 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8AD034DB21; Mon, 2 Apr 2007 09:33:40 +0300 (EEST) Received: from localhost.localdomain (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id ECC804DA97; Mon, 2 Apr 2007 09:33:39 +0300 (EEST) Subject: Re: [XCON] Chat and Instant Messaging in XCON From: Salvatore Loreto To: Paul Kyzivat In-Reply-To: <460D4B96.5000107@cisco.com> References: <460A860E.3010008@unina.it> <460D4B96.5000107@cisco.com> Content-Type: text/plain Date: Mon, 02 Apr 2007 09:33:49 +0300 Message-Id: <1175495629.3453.29.camel@n95.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 02 Apr 2007 06:33:41.0191 (UTC) FILETIME=[DA9AF570:01C774F0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: xcon@ietf.org, simple@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi all, I am forwarding this mail also to the simple mailing list, because chatting is something in between this two WGs. I was just wondering how should be possible to register a Nick Name not only restrictedly to the duration of a conference/chat, but register it *permanently*, so this nick will be always associated to the same user and only to him. Of course this permanent registration should be limited on a conference server base or instead have a larger validity, for example on a nicknaming services provider base. /sal On Fri, 2007-03-30 at 13:40 -0400, Paul Kyzivat wrote: > > Lorenzo Miniero wrote: > > > 2) Of course, chat and IM mean nicknames... should them be unique in the > > whole conferencing system or in a specific conference instance only? I > > tend to prefer the first option, but since the "key" to identify an user > > will be its XCON userid, this could be not mandatory (even if > > recommended...) and mostly fall in 'social' and security matters. > > Besides, in case we choose to have IM gateway functionality, potential > > conflicts and alignment problems on nicknames could arise which should > > be addressed. > > I think nicknames would best be handled by simply getting an AOR from a > suitable "nickname provider". You could actually register with this > provider, or it could simply retarget requests to some other AOR you > own. If need be you could bundle this with an anonymizer or use a > separate anonymizer as well. > > There could be some advantages to collocating such a provider with a > conference server, but thats just an implementation issue. > > Paul > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon On Wed, 2007-03-28 at 17:13 +0200, Lorenzo Miniero wrote: > Dear all, > > even though this may be premature, considering the current status and > slowness of the ongoing work here in XCON, I'd like to start some seeds > of discussion upon a sentitive matter: chat and instant messaging. > As far as I remember from previous discussions, in fact, it was > specified that this would have fallen in XCON duties and nowhere else. > > > That said, starting from some discussions I had with some people on the > matter and from the issues which arose there, I have some questions I'd > like to know your opinion about. > > > 1) Being XCON a CSP agnostic framework, does this apply to IM protocols > too? i.e., will we envisage a gateway functionality for IM protocols as > we do for CSP? We've only talked about MSRP so far, but I'm thinking to > protocols as IRC, XMPP, etc. as well. > > 2) Of course, chat and IM mean nicknames... should them be unique in the > whole conferencing system or in a specific conference instance only? I > tend to prefer the first option, but since the "key" to identify an user > will be its XCON userid, this could be not mandatory (even if > recommended...) and mostly fall in 'social' and security matters. > Besides, in case we choose to have IM gateway functionality, potential > conflicts and alignment problems on nicknames could arise which should > be addressed. > > 3) Should nicknames appear in the base data model, or in subsequent > extensions? And in both cases, how? Considering the gateway case, a > mapping among nicknames in different IM protocols could naturally come > from there, as happens for CSP URIs. > > 4) Will XCON file transfer functionality fall in IM field (since almost > all such protocols envisage it), or will we address it in other ways? > > > That's all. As I said at the beginning, these questions are intended to > be only seeds for a hopefully soon-to-start wider discussion upon IM in > XCON. I'm looking forward to hear your comments and opinions about these > matters. > > Regards, > Lorenzo > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Apr 04 10:56:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6uB-0007b0-Jv; Wed, 04 Apr 2007 10:56:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6uA-0007aa-95; Wed, 04 Apr 2007 10:56:10 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZ6u8-000839-QX; Wed, 04 Apr 2007 10:56:10 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZ6tn-0000n2-8a; Wed, 04 Apr 2007 09:55:48 -0500 From: "Brian Rosen" To: "'Salvatore Loreto'" , "'Paul Kyzivat'" Subject: RE: [XCON] Chat and Instant Messaging in XCON Date: Wed, 4 Apr 2007 10:56:00 -0400 Message-ID: <1e1c01c776c9$5eaba600$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1175495629.3453.29.camel@n95.nomadiclab.com> Thread-Index: Acd08GUSq/BKui4vS/eTUJqu0B5n5gB2C85w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: xcon@ietf.org, simple@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Please see: http://tools.ietf.org/html/draft-niemi-simple-chat-06 There was some discussion of nicknames in the past. There is some discussion happening with the authors of this work on that subject now. Brian > -----Original Message----- > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > Sent: Monday, April 02, 2007 2:34 AM > To: Paul Kyzivat > Cc: xcon@ietf.org; simple@ietf.org > Subject: Re: [XCON] Chat and Instant Messaging in XCON > > Hi all, > > I am forwarding this mail also to the simple mailing list, because > chatting is something in between this two WGs. > > I was just wondering how should be possible to register a Nick Name not > only restrictedly to the duration of a conference/chat, but register it > *permanently*, so this nick will be always associated to the same user > and only to him. > > Of course this permanent registration should be limited on a conference > server base or instead have a larger validity, for example on a > nicknaming services provider base. > > > /sal > > > On Fri, 2007-03-30 at 13:40 -0400, Paul Kyzivat wrote: > > > > Lorenzo Miniero wrote: > > > > > 2) Of course, chat and IM mean nicknames... should them be unique in > the > > > whole conferencing system or in a specific conference instance only? I > > > tend to prefer the first option, but since the "key" to identify an > user > > > will be its XCON userid, this could be not mandatory (even if > > > recommended...) and mostly fall in 'social' and security matters. > > > Besides, in case we choose to have IM gateway functionality, potential > > > conflicts and alignment problems on nicknames could arise which should > > > be addressed. > > > > I think nicknames would best be handled by simply getting an AOR from a > > suitable "nickname provider". You could actually register with this > > provider, or it could simply retarget requests to some other AOR you > > own. If need be you could bundle this with an anonymizer or use a > > separate anonymizer as well. > > > > There could be some advantages to collocating such a provider with a > > conference server, but thats just an implementation issue. > > > > Paul > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > On Wed, 2007-03-28 at 17:13 +0200, Lorenzo Miniero wrote: > > Dear all, > > > > even though this may be premature, considering the current status and > > slowness of the ongoing work here in XCON, I'd like to start some seeds > > of discussion upon a sentitive matter: chat and instant messaging. > > As far as I remember from previous discussions, in fact, it was > > specified that this would have fallen in XCON duties and nowhere else. > > > > > > That said, starting from some discussions I had with some people on the > > matter and from the issues which arose there, I have some questions I'd > > like to know your opinion about. > > > > > > 1) Being XCON a CSP agnostic framework, does this apply to IM protocols > > too? i.e., will we envisage a gateway functionality for IM protocols as > > we do for CSP? We've only talked about MSRP so far, but I'm thinking to > > protocols as IRC, XMPP, etc. as well. > > > > 2) Of course, chat and IM mean nicknames... should them be unique in the > > whole conferencing system or in a specific conference instance only? I > > tend to prefer the first option, but since the "key" to identify an user > > will be its XCON userid, this could be not mandatory (even if > > recommended...) and mostly fall in 'social' and security matters. > > Besides, in case we choose to have IM gateway functionality, potential > > conflicts and alignment problems on nicknames could arise which should > > be addressed. > > > > 3) Should nicknames appear in the base data model, or in subsequent > > extensions? And in both cases, how? Considering the gateway case, a > > mapping among nicknames in different IM protocols could naturally come > > from there, as happens for CSP URIs. > > > > 4) Will XCON file transfer functionality fall in IM field (since almost > > all such protocols envisage it), or will we address it in other ways? > > > > > > That's all. As I said at the beginning, these questions are intended to > > be only seeds for a hopefully soon-to-start wider discussion upon IM in > > XCON. I'm looking forward to hear your comments and opinions about these > > matters. > > > > Regards, > > Lorenzo > > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Apr 04 11:07:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ74x-0002MY-A3; Wed, 04 Apr 2007 11:07:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ74v-0002MS-Vu for xcon@ietf.org; Wed, 04 Apr 2007 11:07:18 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZ74r-00011t-Cr for xcon@ietf.org; Wed, 04 Apr 2007 11:07:17 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZ74T-00068K-7X; Wed, 04 Apr 2007 10:06:54 -0500 From: "Brian Rosen" To: "'Oscar Novo \(JO/LMF\)'" , "'Pete Cordell'" , Subject: RE: [XCON] WG Issues with XML Schema Date: Wed, 4 Apr 2007 11:07:03 -0400 Message-ID: <1e2301c776ca$eb91f0f0$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdsiQ9KlUZKwtADQfim52Qttk2B5AAA42lQAo98mHA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org To me, this is the one that matters. In the IETF, we're always extending things. The contortions needed to extend an XSD and keep it valid are complex. Brian > -----Original Message----- > From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com] > Sent: Thursday, March 22, 2007 10:30 AM > To: Pete Cordell; xcon@ietf.org > Subject: RE: [XCON] WG Issues with XML Schema > > Actually, one of the problems we had was with the extensibility of the > schema. Here you have an email from Jari Urpalainen explaining the > issue: > > http://www1.ietf.org/mail-archive/web/xcon/current/msg01527.html > > Other important problems of XML Schema are number 7 (very critical > one!), 2 and 6. > > Hope this information will help you! > > Oscar > > > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: 22. maaliskuuta 2007 15:50 > To: Oscar Novo (JO/LMF); xcon@ietf.org > Subject: Re: [XCON] WG Issues with XML Schema > > Many thanks for this Oscar. If I try and summarise each of James' > points, I'd be interested know which are, say, the top 4 that you (or > any one else on the list) were most affected by that led you to move > away from XSD (I hope the focussed input can be of use to the schema > working group): > > 1. XSD requires significant expertise with things like the merging of > wildcards in attribute groups being counter-intuitive. > > 2. The XSD spec is hard to understand and not amenable to being easily > referred to. > > 3. XSD does not have a formal theoretical basis behind it (whereas RNG > does). > > 4. XSD does not have co-constraints, e.g. you can't make element X and > attribute Y mutually exclusive. > > 5. The xs:all (analogous to rng's interleave) feature is too weak. > > 6. XSD's datatypes are not flexible/open enough (and yet saddled with > things like gMonthDay). > > 7. An XSD schema can validate seemingly bogus things such as > when the schema never actually mentions a bogus element (I hope he's > wrong about this!). > > 8. Implicitly defined attributes such as xsi:schemaLocation and xsi:type > conflict with your ability to define the grammer you want. > > 9. Allowing the specification of default and fixed values is > problematic. > > And if I can add a few of my own issues: > > 10. The rules for wildcards (xs:any) conflicting with element names can > make versioning of a schema from V1 to V2 problematic. > > 11. Enumerations are not readily extensible. > > 12. There's no modularity in the schema definitions such that schema B > can precisely add extensions to a core schema A. > > Many, many thanks, > > Pete. > -- > ============================================= > Pete Cordell > Tech-Know-Ware Ltd > for XML to C++ data binding visit > http://www.tech-know-ware.com/lmx/ > http://www.codalogic.com/lmx/ > ============================================= > > ----- Original Message ----- > From: "Oscar Novo (JO/LMF)" > To: "Pete Cordell" ; > Sent: Thursday, March 22, 2007 12:03 PM > Subject: RE: [XCON] WG Issues with XML Schema > > > Hi Pete, > > I suggest you to read the following e-mail from James Clark: > > http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html > > He's the designer of TREX. RELAX NG is based on TREX and RELAX. > I think in this e-mail he explains very well the motivations inside the > IETF to move towards RELAX NG. > > Cheers, > > Oscar > > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: 20. maaliskuuta 2007 19:01 > To: xcon@ietf.org > Subject: [XCON] WG Issues with XML Schema > > I hope this isn't a mis-use of this list, but..... > > As you may know, W3C XML Schema is in the process of being extended to > version 1.1. I know that XCON started out using XML Schema, but has > since moved more towards Relax-NG. > > I'm hoping that those making that change of direction will share with me > their motivation for making that decision. My intention would be, if > appropriate, to share any gathered opinions with the XSD 1.1 working > group (probably in some summarized form). (BTW - Just to be clear, I'm > not on the > WG.) > > For example, is XML schema just too difficult to learn? Is the > versioning and extensibility of elements, attributes and enumerations > too restricted? > Were there constraints on your syntax that you couldn't (readily) > express using schema? What else? > > My motivation for doing this is that I feel that the usage scenarios for > XCON, SIP and other similar IETF style protocols are very different from > the sorts of use-cases that the majority of the W3C members are familiar > with, and hence the requirements are under represented. There's a > chance that by giving me feedback, XSD 1.1 will do a better job of > meeting the needs of working groups in the IETF. > > I'm interested to hearing from anybody involved in schema work, whether > it be in XCON, SIP, SIPPING, AVT, some other IETF group, or for private > purposes. However, I'm only posting this message to the XCON list in > the hope this will capture most of the feedback (the membership of the > previously mentioned groups is probably much the same anyway). > > Depending on what you think is appropriate, you can either reply to the > list, or direct to me. > > Many, many thanks for you help in trying to make XSD 1.1. better! > > Pete. > -- > ============================================= > Pete Cordell > Tech-Know-Ware Ltd > for XML to C++ data binding visit > http://www.tech-know-ware.com/lmx/ > http://www.codalogic.com/lmx/ > ============================================= > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 09 20:24:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb49V-0006gs-9U; Mon, 09 Apr 2007 20:24:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb49T-0006gh-8P for xcon@ietf.org; Mon, 09 Apr 2007 20:24:03 -0400 Received: from jess.glam.ac.uk ([193.63.147.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb49R-0002tP-84 for xcon@ietf.org; Mon, 09 Apr 2007 20:24:03 -0400 Received: from mailserv1.isd.glam.ac.uk ([192.168.244.1]) by jess.glam.ac.uk with esmtp (Exim 3.35 #1) id 1Hb3y7-00022f-00 for xcon@ietf.org; Tue, 10 Apr 2007 01:12:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Apr 2007 01:23:57 +0100 Message-ID: <0BA7EE4D4646E0409D458D347C508B78034ED244@MAILSERV1.uni.glam.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CFP NGMAST - International Conference and Exhibition on NEXT GENERATION MOBILE APPLICATIONS, SERVICES and TECHNOLOGIES Thread-Index: Acd7BoeaQGidENBkSPqmpachRfUGSg== From: "Balakrishna C \(AT\)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7b1e34d2462e88c1c4311f8189331c59 Subject: [XCON] CFP NGMAST - International Conference and Exhibition on NEXT GENERATION MOBILE APPLICATIONS, SERVICES and TECHNOLOGIES X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2107339996==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============2107339996== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77B06.88E7072C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77B06.88E7072C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ************ Apology for Multiple copies ******************** ********** Paper Submission Deadline 30th April **************** =20 Call for Papers / Call for tutorials / Call for exhibitors =20 International Conference and Exhibition on=20 NEXT GENERATION MOBILE APPLICATIONS, SERVICES and TECHNOLOGIES=20 (NGMAST 2007) =20 Building Bridges in the Mobile World=20 12-14 September 2007=20 Cardiff, Wales, UK=20 =20 URL: http://www.ngmast.com/ =20 =20 Industrial Sponsors: NOKIA, Ubiquity Software, Cantata, Microsoft, BT, Orange Technical Co-sponsors: IEEE UKRI Computer, Ofcom, ECMS. BCS-HCI, EC COST290 =20 Proceedings to be published by IEEE CS Press Programme includes 5 World leading keynote talks from major industries and regulatory bodies. =20 The inaugural NGMAST07 Conference will focus on all novel aspects of application, service development, and technology within the Mobile and Wireless Communications community.=20 It aims to bring together a wide spectrum of international experts from the fields of research, business and policy, to facilitate a creative forum for the promotion of collaboration and knowledge transfer.=20 In particular it will facilitate a dialogue between Government, major industry players, SMEs, and academia to help create pathways for the development of common goals in a convergent network environment.=20 =20 Opportunities and activities=20 The three day conference programme will combine keynote speakers from both industry and academia with a multi-track technical programme. There will be opportunities to attend interactive, high quality, peer reviewed sessions which will provide detailed insights from forward thinkers working in the themes of the conference. =20 =20 Additionally there will be an exhibition for both international business and niche market SMEs to display their latest products and services and to undertake a range of networking opportunities. =20 =20 Conference themes include but not limited to:=20 =20 Next Generation Mobile Services=20 =20 * IMS service architecture=20 * Fixed-Mobile Convergence and IMS=20 * Next Generations Service Management and delivery=20 * Software System design for Mobile services=20 * Multimedia and Multicast services=20 * Peer-to-Peer Services=20 * Client-Server based services=20 * Innovative services on IMS Application Servers=20 * Location-based services=20 * Context/Content-aware services=20 * Security services=20 * IMS Billing, Accounting and Charging=20 =20 Next Generation Mobile Applications=20 =20 * SIP-based applications on IMS=20 * Mobile TV and multicast applications=20 * Mobile peer-to-peer (P2P) applications=20 * Machine-to-Machine (M2M) applications=20 * Real-time multimedia applications=20 * Mobile gaming =20 * High-speed data applications on mobile networks=20 * Secure Mobile banking applications=20 * Mobile GIS applications=20 * Mobile health care and medical applications=20 * Home automation and monitoring applications=20 * M-commerce=20 * M-learning=20 * M-entertainment=20 * Mobile applications user interface and design =20 * Mobile Search engines=20 =20 Next Generation Mobile Technologies. =20 * Next generation access technologies=20 * Fixed-Mobile Convergence and IMS=20 * Mobile Broadband technologies=20 * Mobile Vehicular technologies=20 * Adaptation techniques for next generation networks and services=20 * Inter-operability and optimization issues=20 * End-to-End quality of service=20 * Resource Allocation and Management strategies=20 * Ambient and pervasive networking=20 * Energy conservation technologies=20 =20 Standardization and Ethical issues for beyond 3G =20 =20 * Beyond 3G and Society=20 * Next Generations Network Management and Operation strategy=20 =20 Organisation Committee http://www.ngmast.com =20 =20 =20 ------_=_NextPart_001_01C77B06.88E7072C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

************ Apology for Multiple copies ********************

********** Paper Submission Deadline = 30th April ****************

 

Call for Papers / Call for tutorials / Call = for exhibitors

 

International Conference and Exhibition on =

NEXT GENERATION MOBILE APPLICATIONS, SERVICES and TECHNOLOGIES

(NGMAST 2007)

 

Building Bridges in the Mobile World

12-14 September 2007 =

Cardiff, Wales, UK

 

URL: http://www.ngmast.com/=

 

Industrial Sponsors: NOKIA, Ubiquity = Software, Cantata, Microsoft, BT, Orange

Technical Co-sponsors: IEEE UKRI Computer, = Ofcom, ECMS. BCS-HCI, EC COST290

 

Proceedings to be published by IEEE CS = Press

Programme includes 5 World leading keynote = talks from major industries and regulatory bodies.

 

The inaugural NGMAST07 Conference will focus = on all novel aspects of application, service development, and technology within = the Mobile and = Wireless Communications community.

It aims to bring together a wide spectrum of international experts from the fields of research, business and policy, = to facilitate a creative forum for the promotion of collaboration and = knowledge transfer.

In particular it will facilitate a dialogue = between Government, major industry players, SMEs, and academia to help create = pathways for the development of common goals in a convergent network environment. =

 

Opportunities and activities =

The three day conference programme will = combine keynote speakers from both industry and academia with a multi-track = technical programme. There will be opportunities to attend interactive, high = quality, peer reviewed sessions which will provide detailed insights from forward thinkers working in the themes of the conference.  =

 

Additionally there will be an exhibition for = both international business and niche market SMEs to display their latest = products and services and to undertake a range of networking opportunities.  =

 

Conference themes include but not limited to: =

 

Next Generation Mobile Services

 

• IMS service architecture =

• Fixed-Mobile Convergence and IMS =

• Next Generations Service Management = and delivery

• Software System design for Mobile services

• Multimedia and Multicast services =

• Peer-to-Peer Services =

• Client-Server based services =

• Innovative services on IMS = Application Servers

• Location-based services =

• Context/Content-aware services =

• Security services =

• IMS Billing, Accounting and Charging =

 

Next Generation Mobile Applications

 

• SIP-based applications on IMS =

• Mobile TV and multicast applications =

• Mobile peer-to-peer (P2P) = applications

• Machine-to-Machine (M2M) applications =

• Real-time multimedia applications =

• Mobile gaming  =

• High-speed data applications on = mobile networks

• Secure Mobile banking applications

• Mobile GIS applications =

• Mobile health care and medical = applications

• Home automation and monitoring = applications

• M-commerce =

• M-learning =

• M-entertainment =

• Mobile applications user interface = and design 

• Mobile Search engines =

 

Next Generation Mobile Technologies.

 

• Next generation access technologies =

• Fixed-Mobile Convergence and IMS =

• Mobile Broadband technologies =

• Mobile Vehicular technologies =

• Adaptation techniques for next = generation networks and services

• Inter-operability and optimization = issues

• End-to-End quality of service =

• Resource Allocation and Management = strategies

• Ambient and pervasive networking =

• Energy conservation technologies =

 

Standardization and Ethical issues for beyond = 3G 

 

• Beyond 3G and Society =

• Next Generations Network Management = and Operation strategy

 

Organisation = Committee

http://www.ngmast.com

 

 

------_=_NextPart_001_01C77B06.88E7072C-- --===============2107339996== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============2107339996==-- From xcon-bounces@ietf.org Tue Apr 10 07:30:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEYU-0006bY-VX; Tue, 10 Apr 2007 07:30:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEYU-0006bG-16 for xcon@ietf.org; Tue, 10 Apr 2007 07:30:34 -0400 Received: from smtp2.wanadoo.co.uk ([193.252.22.157] helo=smtp2.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbEYQ-0002xw-7o for xcon@ietf.org; Tue, 10 Apr 2007 07:30:34 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3113.me.freeserve.com (SMTP Server) with ESMTP id 7509C5C00086; Tue, 10 Apr 2007 13:30:29 +0200 (CEST) Received: from Codalogic (user-54433ea2.lns5-c7.dsl.pol.co.uk [84.67.62.162]) by mwinf3113.me.freeserve.com (SMTP Server) with SMTP id D25E25C00082; Tue, 10 Apr 2007 13:30:28 +0200 (CEST) X-ME-UUID: 20070410113028861.D25E25C00082@mwinf3113.me.freeserve.com Message-ID: <00c001c77b63$a00bdfe0$2400a8c0@Codalogic> From: "Pete Cordell" To: "Brian Rosen" , "'Oscar Novo (JO/LMF)'" , References: <1e2301c776ca$eb91f0f0$81238182@cis.neustar.com> Subject: Re: [XCON] WG Issues with XML Schema Date: Tue, 10 Apr 2007 11:55:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Brian, Thanks for your reply (I didn't reply earlier in case it solicited some further discussion.) This is an area being looked at in XSD 1.1. With the current drafted text, it would be possible to specify something like: With existing XSD 1.0 rules the wildcard would conflict with the 'foo' element. The current XSD 1.1 text says that if a wildcard conflicts with an element declaration, then the element declaration wins. Hence the above is OK. One slight oddity is that the following instance would be valid: 123 456 Here, the first instance of matches the element declaration, and the second instance matches the wildcard. Personally I don't think this is the right way to do things, and am trying to convince them of that. There's also an example (based on peoples' names) where you couldn't go from (in v1): to: in a subsequent version (i.e. add a declaration for a name element, and another wildcard), because the two wildcards would conflict. Instead you would have to do: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEYU-0006bY-VX; Tue, 10 Apr 2007 07:30:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEYU-0006bG-16 for xcon@ietf.org; Tue, 10 Apr 2007 07:30:34 -0400 Received: from smtp2.wanadoo.co.uk ([193.252.22.157] helo=smtp2.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbEYQ-0002xw-7o for xcon@ietf.org; Tue, 10 Apr 2007 07:30:34 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3113.me.freeserve.com (SMTP Server) with ESMTP id 7509C5C00086; Tue, 10 Apr 2007 13:30:29 +0200 (CEST) Received: from Codalogic (user-54433ea2.lns5-c7.dsl.pol.co.uk [84.67.62.162]) by mwinf3113.me.freeserve.com (SMTP Server) with SMTP id D25E25C00082; Tue, 10 Apr 2007 13:30:28 +0200 (CEST) X-ME-UUID: 20070410113028861.D25E25C00082@mwinf3113.me.freeserve.com Message-ID: <00c001c77b63$a00bdfe0$2400a8c0@Codalogic> From: "Pete Cordell" To: "Brian Rosen" , "'Oscar Novo (JO/LMF)'" , References: <1e2301c776ca$eb91f0f0$81238182@cis.neustar.com> Subject: Re: [XCON] WG Issues with XML Schema Date: Tue, 10 Apr 2007 11:55:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Brian, Thanks for your reply (I didn't reply earlier in case it solicited some further discussion.) This is an area being looked at in XSD 1.1. With the current drafted text, it would be possible to specify something like: With existing XSD 1.0 rules the wildcard would conflict with the 'foo' element. The current XSD 1.1 text says that if a wildcard conflicts with an element declaration, then the element declaration wins. Hence the above is OK. One slight oddity is that the following instance would be valid: 123 456 Here, the first instance of matches the element declaration, and the second instance matches the wildcard. Personally I don't think this is the right way to do things, and am trying to convince them of that. There's also an example (based on peoples' names) where you couldn't go from (in v1): to: in a subsequent version (i.e. add a declaration for a name element, and another wildcard), because the two wildcards would conflict. Instead you would have to do: (i.e. add an optional sequence in which the name became mandatory, hence separating the wildcards.) This seems messy to me, and I'd like to encourage them to permit the middle option (first extended example). There's more examples at: http://www.w3.org/TR/xmlschema-guide2versioning/ So in summary, there is movement here. But I think the usage scenarios that the IETF has for schema is under represented in the schema working group (for example, I suggested an xs:anyEnumeration facet to make extensible enumerations, rather than having to use the trick, but got no takers.). Therefore, I think it would be well worth some members of the IETF looking at what the W3C is doing and possibly sending them a liaison statement outlining the sorts of features they would find helpful in a new version of XML schema. I believe there is an XML users group in the IETF. Maybe this is something they could do. Thanks again for your comments, Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx/ http://www.codalogic.com/lmx/ ============================================= ----- Original Message ----- From: "Brian Rosen" To: "'Oscar Novo (JO/LMF)'" ; "'Pete Cordell'" ; Sent: Wednesday, April 04, 2007 4:07 PM Subject: RE: [XCON] WG Issues with XML Schema > To me, this is the one that matters. > > In the IETF, we're always extending things. The contortions needed to > extend an XSD and keep it valid are complex. > > Brian > >> -----Original Message----- >> From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com] >> Sent: Thursday, March 22, 2007 10:30 AM >> To: Pete Cordell; xcon@ietf.org >> Subject: RE: [XCON] WG Issues with XML Schema >> >> Actually, one of the problems we had was with the extensibility of the >> schema. Here you have an email from Jari Urpalainen explaining the >> issue: >> >> http://www1.ietf.org/mail-archive/web/xcon/current/msg01527.html >> >> Other important problems of XML Schema are number 7 (very critical >> one!), 2 and 6. >> >> Hope this information will help you! >> >> Oscar >> >> >> -----Original Message----- >> From: Pete Cordell [mailto:pete@tech-know-ware.com] >> Sent: 22. maaliskuuta 2007 15:50 >> To: Oscar Novo (JO/LMF); xcon@ietf.org >> Subject: Re: [XCON] WG Issues with XML Schema >> >> Many thanks for this Oscar. If I try and summarise each of James' >> points, I'd be interested know which are, say, the top 4 that you (or >> any one else on the list) were most affected by that led you to move >> away from XSD (I hope the focussed input can be of use to the schema >> working group): >> >> 1. XSD requires significant expertise with things like the merging of >> wildcards in attribute groups being counter-intuitive. >> >> 2. The XSD spec is hard to understand and not amenable to being easily >> referred to. >> >> 3. XSD does not have a formal theoretical basis behind it (whereas RNG >> does). >> >> 4. XSD does not have co-constraints, e.g. you can't make element X and >> attribute Y mutually exclusive. >> >> 5. The xs:all (analogous to rng's interleave) feature is too weak. >> >> 6. XSD's datatypes are not flexible/open enough (and yet saddled with >> things like gMonthDay). >> >> 7. An XSD schema can validate seemingly bogus things such as >> when the schema never actually mentions a bogus element (I hope he's >> wrong about this!). >> >> 8. Implicitly defined attributes such as xsi:schemaLocation and xsi:type >> conflict with your ability to define the grammer you want. >> >> 9. Allowing the specification of default and fixed values is >> problematic. >> >> minOccurs="0" maxOccurs="unbounded"/> (i.e. add an optional sequence in which the name became mandatory, hence separating the wildcards.) This seems messy to me, and I'd like to encourage them to permit the middle option (first extended example). There's more examples at: http://www.w3.org/TR/xmlschema-guide2versioning/ So in summary, there is movement here. But I think the usage scenarios that the IETF has for schema is under represented in the schema working group (for example, I suggested an xs:anyEnumeration facet to make extensible enumerations, rather than having to use the trick, but got no takers.). Therefore, I think it would be well worth some members of the IETF looking at what the W3C is doing and possibly sending them a liaison statement outlining the sorts of features they would find helpful in a new version of XML schema. I believe there is an XML users group in the IETF. Maybe this is something they could do. Thanks again for your comments, Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx/ http://www.codalogic.com/lmx/ ============================================= ----- Original Message ----- From: "Brian Rosen" To: "'Oscar Novo (JO/LMF)'" ; "'Pete Cordell'" ; Sent: Wednesday, April 04, 2007 4:07 PM Subject: RE: [XCON] WG Issues with XML Schema > To me, this is the one that matters. > > In the IETF, we're always extending things. The contortions needed to > extend an XSD and keep it valid are complex. > > Brian > >> -----Original Message----- >> From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com] >> Sent: Thursday, March 22, 2007 10:30 AM >> To: Pete Cordell; xcon@ietf.org >> Subject: RE: [XCON] WG Issues with XML Schema >> >> Actually, one of the problems we had was with the extensibility of the >> schema. Here you have an email from Jari Urpalainen explaining the >> issue: >> >> http://www1.ietf.org/mail-archive/web/xcon/current/msg01527.html >> >> Other important problems of XML Schema are number 7 (very critical >> one!), 2 and 6. >> >> Hope this information will help you! >> >> Oscar >> >> >> -----Original Message----- >> From: Pete Cordell [mailto:pete@tech-know-ware.com] >> Sent: 22. maaliskuuta 2007 15:50 >> To: Oscar Novo (JO/LMF); xcon@ietf.org >> Subject: Re: [XCON] WG Issues with XML Schema >> >> Many thanks for this Oscar. If I try and summarise each of James' >> points, I'd be interested know which are, say, the top 4 that you (or >> any one else on the list) were most affected by that led you to move >> away from XSD (I hope the focussed input can be of use to the schema >> working group): >> >> 1. XSD requires significant expertise with things like the merging of >> wildcards in attribute groups being counter-intuitive. >> >> 2. The XSD spec is hard to understand and not amenable to being easily >> referred to. >> >> 3. XSD does not have a formal theoretical basis behind it (whereas RNG >> does). >> >> 4. XSD does not have co-constraints, e.g. you can't make element X and >> attribute Y mutually exclusive. >> >> 5. The xs:all (analogous to rng's interleave) feature is too weak. >> >> 6. XSD's datatypes are not flexible/open enough (and yet saddled with >> things like gMonthDay). >> >> 7. An XSD schema can validate seemingly bogus things such as >> when the schema never actually mentions a bogus element (I hope he's >> wrong about this!). >> >> 8. Implicitly defined attributes such as xsi:schemaLocation and xsi:type >> conflict with your ability to define the grammer you want. >> >> 9. Allowing the specification of default and fixed values is >> problematic. >> >> And if I can add a few of my own issues: >> >> 10. The rules for wildcards (xs:any) conflicting with element names can >> make versioning of a schema from V1 to V2 problematic. >> >> 11. Enumerations are not readily extensible. >> >> 12. There's no modularity in the schema definitions such that schema B >> can precisely add extensions to a core schema A. >> >> Many, many thanks, >> >> Pete. >> -- >> ============================================= >> Pete Cordell >> Tech-Know-Ware Ltd >> for XML to C++ data binding visit >> http://www.tech-know-ware.com/lmx/ >> http://www.codalogic.com/lmx/ >> ============================================= >> >> ----- Original Message ----- >> From: "Oscar Novo (JO/LMF)" >> To: "Pete Cordell" ; >> Sent: Thursday, March 22, 2007 12:03 PM >> Subject: RE: [XCON] WG Issues with XML Schema >> >> >> Hi Pete, >> >> I suggest you to read the following e-mail from James Clark: >> >> http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html >> >> He's the designer of TREX. RELAX NG is based on TREX and RELAX. >> I think in this e-mail he explains very well the motivations inside the >> IETF to move towards RELAX NG. >> >> Cheers, >> >> Oscar >> >> -----Original Message----- >> From: Pete Cordell [mailto:pete@tech-know-ware.com] >> Sent: 20. maaliskuuta 2007 19:01 >> To: xcon@ietf.org >> Subject: [XCON] WG Issues with XML Schema >> >> I hope this isn't a mis-use of this list, but..... >> >> As you may know, W3C XML Schema is in the process of being extended to >> version 1.1. I know that XCON started out using XML Schema, but has >> since moved more towards Relax-NG. >> >> I'm hoping that those making that change of direction will share with me >> their motivation for making that decision. My intention would be, if >> appropriate, to share any gathered opinions with the XSD 1.1 working >> group (probably in some summarized form). (BTW - Just to be clear, I'm >> not on the >> WG.) >> >> For example, is XML schema just too difficult to learn? Is the >> versioning and extensibility of elements, attributes and enumerations >> too restricted? >> Were there constraints on your syntax that you couldn't (readily) >> express using schema? What else? >> >> My motivation for doing this is that I feel that the usage scenarios for >> XCON, SIP and other similar IETF style protocols are very different from >> the sorts of use-cases that the majority of the W3C members are familiar >> with, and hence the requirements are under represented. There's a >> chance that by giving me feedback, XSD 1.1 will do a better job of >> meeting the needs of working groups in the IETF. >> >> I'm interested to hearing from anybody involved in schema work, whether >> it be in XCON, SIP, SIPPING, AVT, some other IETF group, or for private >> purposes. However, I'm only posting this message to the XCON list in >> the hope this will capture most of the feedback (the membership of the >> previously mentioned groups is probably much the same anyway). >> >> Depending on what you think is appropriate, you can either reply to the >> list, or direct to me. >> >> Many, many thanks for you help in trying to make XSD 1.1. better! >> >> Pete. >> -- >> ============================================= >> Pete Cordell >> Tech-Know-Ware Ltd >> for XML to C++ data binding visit >> http://www.tech-know-ware.com/lmx/ >> http://www.codalogic.com/lmx/ >> ============================================= >> >> >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon >> >> >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > ___________________________And if I can add a few of my own issues: >> >> 10. The rules for wildcards (xs:any) conflicting with element names can >> make versioning of a schema from V1 to V2 problematic. >> >> 11. Enumerations are not readily extensible. >> >> 12. There's no modularity in the schema definitions such that schema B >> can precisely add extensions to a core schema A. >> >> Many, many thanks, >> >> Pete. >> -- >> ============================================= >> Pete Cordell >> Tech-Know-Ware Ltd >> for XML to C++ data binding visit >> http://www.tech-know-ware.com/lmx/ >> http://www.codalogic.com/lmx/ >> ============================================= >> >> ----- Original Message ----- >> From: "Oscar Novo (JO/LMF)" >> To: "Pete Cordell" ; >> Sent: Thursday, March 22, 2007 12:03 PM >> Subject: RE: [XCON] WG Issues with XML Schema >> >> >> Hi Pete, >> >> I suggest you to read the following e-mail from James Clark: >> >> http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html >> >> He's the designer of TREX. RELAX NG is based on TREX and RELAX. >> I think in this e-mail he explains very well the motivations inside the >> IETF to move towards RELAX NG. >> >> Cheers, >> >> Oscar >> >> -----Original Message----- >> From: Pete Cordell [mailto:pete@tech-know-ware.com] >> Sent: 20. maaliskuuta 2007 19:01 >> To: xcon@ietf.org >> Subject: [XCON] WG Issues with XML Schema >> >> I hope this isn't a mis-use of this list, but..... >> >> As you may know, W3C XML Schema is in the process of being extended to >> version 1.1. I know that XCON started out using XML Schema, but has >> since moved more towards Relax-NG. >> >> I'm hoping that those making that change of direction will share with me >> their motivation for making that decision. My intention would be, if >> appropriate, to share any gathered opinions with the XSD 1.1 working >> group (probably in some summarized form). (BTW - Just to be clear, I'm >> not on the >> WG.) >> >> For example, is XML schema just too difficult to learn? Is the >> versioning and extensibility of elements, attributes and enumerations >> too restricted? >> Were there constraints on your syntax that you couldn't (readily) >> express using schema? What else? >> >> My motivation for doing this is that I feel that the usage scenarios for >> XCON, SIP and other similar IETF style protocols are very different from >> the sorts of use-cases that the majority of the W3C members are familiar >> with, and hence the requirements are under represented. There's a >> chance that by giving me feedback, XSD 1.1 will do a better job of >> meeting the needs of working groups in the IETF. >> >> I'm interested to hearing from anybody involved in schema work, whether >> it be in XCON, SIP, SIPPING, AVT, some other IETF group, or for private >> purposes. However, I'm only posting this message to the XCON list in >> the hope this will capture most of the feedback (the membership of the >> previously mentioned groups is probably much the same anyway). >> >> Depending on what you think is appropriate, you can either reply to the >> list, or direct to me. >> >> Many, many thanks for you help in trying to make XSD 1.1. better! >> >> Pete. >> -- >> ============================================= >> Pete Cordell >> Tech-Know-Ware Ltd >> for XML to C++ data binding visit >> http://www.tech-know-ware.com/lmx/ >> http://www.codalogic.com/lmx/ >> ============================================= >> >> >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon >> >> >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Apr 10 07:30:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEYX-0006by-Ag; Tue, 10 Apr 2007 07:30:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEYW-0006bt-0D for xcon@ietf.org; Tue, 10 Apr 2007 07:30:36 -0400 Received: from smtp2.wanadoo.co.uk ([193.252.22.157] helo=smtp2.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbEYQ-0002y0-9m for xcon@ietf.org; Tue, 10 Apr 2007 07:30:35 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3113.me.freeserve.com (SMTP Server) with ESMTP id EA0455C00088; Tue, 10 Apr 2007 13:30:29 +0200 (CEST) Received: from Codalogic (user-54433ea2.lns5-c7.dsl.pol.co.uk [84.67.62.162]) by mwinf3113.me.freeserve.com (SMTP Server) with SMTP id 91E145C00082; Tue, 10 Apr 2007 13:30:29 +0200 (CEST) X-ME-UUID: 20070410113029597.91E145C00082@mwinf3113.me.freeserve.com Message-ID: <00c101c77b63$a07269e0$2400a8c0@Codalogic> From: "Pete Cordell" To: "Oscar Novo (JO/LMF)" , References: <002701c76c89$14ed8be0$c900a8c0@Codalogic> Subject: Re: [XCON] WG Issues with XML Schema Date: Tue, 10 Apr 2007 12:30:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org In order to give something back to the group (whether you want it or not!) I thought I'd summarize the sorts of things that might change in XSD1.1 with respect to the issues listed below: ----- Original Message ----- From: "Pete Cordell" > Many thanks for this Oscar. If I try and summarise each of James' points, > I'd be interested know which are, say, the top 4 that you (or any one else > on the list) were most affected by that led you to move away from XSD (I > hope the focussed input can be of use to the schema working group): > > 1. XSD requires significant expertise with things like the merging of > wildcards in attribute groups being counter-intuitive. I don't think this will change. > 2. The XSD spec is hard to understand and not amenable to being easily > referred to. It is a stated aim of the requirements to make the spec easier to understand. However, I only expect it to change by a few percent, rather than the order of magnitude it perhaps needs! > 3. XSD does not have a formal theoretical basis behind it (whereas RNG > does). Personally I'm not bothered by this. However, there is more theoretical basis for some of the constructs. > 4. XSD does not have co-constraints, e.g. you can't make element X and > attribute Y mutually exclusive. This is being looked at. Elements and types etc. may allow XPath style constraints to be specified (assertions). Depending on what is finally decided, this could be very powerful (and very hard to implement!). > 5. The xs:all (analogous to rng's interleave) feature is too weak. This should be addressed. The maxOccurs on an xs:all member could be any number (rather than being restricted to 0 or 1). I still don't think it will be possib____________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Apr 10 07:30:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEYX-0006by-Ag; Tue, 10 Apr 2007 07:30:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEYW-0006bt-0D for xcon@ietf.org; Tue, 10 Apr 2007 07:30:36 -0400 Received: from smtp2.wanadoo.co.uk ([193.252.22.157] helo=smtp2.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbEYQ-0002y0-9m for xcon@ietf.org; Tue, 10 Apr 2007 07:30:35 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3113.me.freeserve.com (SMTP Server) with ESMTP id EA0455C00088; Tue, 10 Apr 2007 13:30:29 +0200 (CEST) Received: from Codalogic (user-54433ea2.lns5-c7.dsl.pol.co.uk [84.67.62.162]) by mwinf3113.me.freeserve.com (SMTP Server) with SMTP id 91E145C00082; Tue, 10 Apr 2007 13:30:29 +0200 (CEST) X-ME-UUID: 20070410113029597.91E145C00082@mwinf3113.me.freeserve.com Message-ID: <00c101c77b63$a07269e0$2400a8c0@Codalogic> From: "Pete Cordell" To: "Oscar Novo (JO/LMF)" , References: <002701c76c89$14ed8be0$c900a8c0@Codalogic> Subject: Re: [XCON] WG Issues with XML Schema Date: Tue, 10 Apr 2007 12:30:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org In order to give something back to the group (whether you want it or not!) I thought I'd summarize the sorts of things that might change in XSD1.1 with respect to the issues listed below: ----- Original Message ----- From: "Pete Cordell" > Many thanks for this Oscar. If I try and summarise each of James' points, > I'd be interested know which are, say, the top 4 that you (or any one else > on the list) were most affected by that led you to move away from XSD (I > hope the focussed input can be of use to the schema working group): > > 1. XSD requires significant expertise with things like the merging of > wildcards in attribute groups being counter-intuitive. I don't think this will change. > 2. The XSD spec is hard to understand and not amenable to being easily > referred to. It is a stated aim of the requirements to make the spec easier to understand. However, I only expect it to change by a few percent, rather than the order of magnitude it perhaps needs! > 3. XSD does not have a formal theoretical basis behind it (whereas RNG > does). Personally I'm not bothered by this. However, there is more theoretical basis for some of the constructs. > 4. XSD does not have co-constraints, e.g. you can't make element X and > attribute Y mutually exclusive. This is being looked at. Elements and types etc. may allow XPath style constraints to be specified (assertions). Depending on what is finally decided, this could be very powerful (and very hard to implement!). > 5. The xs:all (analogous to rng's interleave) feature is too weak. This should be addressed. The maxOccurs on an xs:all member could be any number (rather than being restricted to 0 or 1). I still don't think it will be possible to have an xs:all within an xs:sequence/xs:choice though. > 6. XSD's datatypes are not flexible/open enough (and yet saddled with > things like gMonthDay). No change > 7. An XSD schema can validate seemingly bogus things such as when > the schema never actually mentions a bogus element (I hope he's wrong > about this!). If you specify strict validation, this should not be a problem. > 8. Implicitly defined attributes such as xsi:schemaLocation and xsi:type > conflict with your ability to define the grammer you want. No change > 9. Allowing the specification of default and fixed values is problematic. No change > And if I can add a few of my own issues: > > 10. The rules for wildcards (xs:any) conflicting with element names can > make versioning of a schema from V1 to V2 problematic. Addressed in previous e-mail. > 11. Enumerations are not readily extensible. As mentioned in other e-mail, I tried proposing xs:anyEnumeration, but most people seem to see versionable schemas as a major problem rather than a major benefit! > 12. There's no modularity in the schema definitions such that schema B can > precisely add extensions to a core schema A. I quickly jotted down a proposal to address this (http://www.tech-know-ware.com/lmx/download/named-wildcards.pdf), but I think it is, sadly, way, way, way beyond what they are currently considering. > Many, many thanks, BTW - currently I'm only making comments on the W3C's xmlschema-dev@w3.org mailing list (http://lists.w3.org/Archives/Public/xmlschema-dev/). This is an open list, so if you would like to make your own comments, feel free to do so. Thanks again, Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx/ http://www.codalogic.com/lmx/ ============================================= > ----- Original Message ----- > From: "Oscar Novo (JO/LMF)" > To: "Pete Cordell" ; > Sent: Thursday, March 22, 2007 12:03 PM > Subject: RE: [XCON] WG Issues with XML Schema > > > Hi Pete, > > I suggest you to read the following e-mail from James Clark: > > http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html > > He's the designer of TREX. RELAX NG is based on TREX and RELAX. > I think in this e-mail he explains very well the motivations inside the > IETF to move towards RELAX NG. > > Cheers, > > Oscar > > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: 20. maaliskuuta 2007 19:01 > To: xcon@ietf.org > Subject: [XCON] WG Issues with XML Schema > > I hope this isn't a mis-use of this list, but..... > > As you may know, W3C XML Schema is in the process of being extended to > version 1.1. I know that XCON started out using XML Schema, but has > since moved more towards Relax-NG. > > I'm hoping that those making that change of direction will share with me > their motivation for making that decision. My intention would be, if > appropriate, to share any gathered opinions with the XSD 1.1 working > group (probably in some summarized form). (BTW - Just to be clear, I'm > not on the > WG.) > > For example, is XML schema just too difficult to learn? Is the > versioning and extensibility of elements, attributes and enumerations > too restricted? > Were there constraints on your syntax that you couldn't (readily) > express using schema? What else? > > My motivation for doing this is that I feel that the usage scenarios for > XCON, SIP and other similar IETF style protocols are very different from > the sorts of use-cases that the majority of the W3C members are familiar > with, and hence the requirements are under represented. There's a > chance that by giving me feedback, XSD 1.1 will do a better job of > meeting the needs of working groups in the IETF. > > I'm interested to hearing from anybody involved in schema work, whether > it be in XCON, SIP, SIPPING, AVT, some other IETF group, or for private > purposes. However, I'm only posting this mele to have an xs:all within an xs:sequence/xs:choice though. > 6. XSD's datatypes are not flexible/open enough (and yet saddled with > things like gMonthDay). No change > 7. An XSD schema can validate seemingly bogus things such as when > the schema never actually mentions a bogus element (I hope he's wrong > about this!). If you specify strict validation, this should not be a problem. > 8. Implicitly defined attributes such as xsi:schemaLocation and xsi:type > conflict with your ability to define the grammer you want. No change > 9. Allowing the specification of default and fixed values is problematic. No change > And if I can add a few of my own issues: > > 10. The rules for wildcards (xs:any) conflicting with element names can > make versioning of a schema from V1 to V2 problematic. Addressed in previous e-mail. > 11. Enumerations are not readily extensible. As mentioned in other e-mail, I tried proposing xs:anyEnumeration, but most people seem to see versionable schemas as a major problem rather than a major benefit! > 12. There's no modularity in the schema definitions such that schema B can > precisely add extensions to a core schema A. I quickly jotted down a proposal to address this (http://www.tech-know-ware.com/lmx/download/named-wildcards.pdf), but I think it is, sadly, way, way, way beyond what they are currently considering. > Many, many thanks, BTW - currently I'm only making comments on the W3C's xmlschema-dev@w3.org mailing list (http://lists.w3.org/Archives/Public/xmlschema-dev/). This is an open list, so if you would like to make your own comments, feel free to do so. Thanks again, Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx/ http://www.codalogic.com/lmx/ ============================================= > ----- Original Message ----- > From: "Oscar Novo (JO/LMF)" > To: "Pete Cordell" ; > Sent: Thursday, March 22, 2007 12:03 PM > Subject: RE: [XCON] WG Issues with XML Schema > > > Hi Pete, > > I suggest you to read the following e-mail from James Clark: > > http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html > > He's the designer of TREX. RELAX NG is based on TREX and RELAX. > I think in this e-mail he explains very well the motivations inside the > IETF to move towards RELAX NG. > > Cheers, > > Oscar > > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: 20. maaliskuuta 2007 19:01 > To: xcon@ietf.org > Subject: [XCON] WG Issues with XML Schema > > I hope this isn't a mis-use of this list, but..... > > As you may know, W3C XML Schema is in the process of being extended to > version 1.1. I know that XCON started out using XML Schema, but has > since moved more towards Relax-NG. > > I'm hoping that those making that change of direction will share with me > their motivation for making that decision. My intention would be, if > appropriate, to share any gathered opinions with the XSD 1.1 working > group (probably in some summarized form). (BTW - Just to be clear, I'm > not on the > WG.) > > For example, is XML schema just too difficult to learn? Is the > versioning and extensibility of elements, attributes and enumerations > too restricted? > Were there constraints on your syntax that you couldn't (readily) > express using schema? What else? > > My motivation for doing this is that I feel that the usage scenarios for > XCON, SIP and other similar IETF style protocols are very different from > the sorts of use-cases that the majority of the W3C members are familiar > with, and hence the requirements are under represented. There's a > chance that by giving me feedback, XSD 1.1 will do a better job of > meeting the needs of working groups in the IETF. > > I'm interested to hearing from anybody involved in schema work, whether > it be in XCON, SIP, SIPPING, AVT, some other IETF group, or for private > purposes. However, I'm only posting this message to the XCON list in > the hope this will capture most of the feedback (the membership of the > previously mentioned groups is probably much the same anyway). > > Depending on what you think is appropriate, you can either reply to the > list, or direct to me. > > Many, many thanks for you help in trying to make XSD 1.1. better! Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx/ http://www.codalogic.com/lmx/ ============================================= _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon ssage to the XCON list in > the hope this will capture most of the feedback (the membership of the > previously mentioned groups is probably much the same anyway). > > Depending on what you think is appropriate, you can either reply to the > list, or direct to me. > > Many, many thanks for you help in trying to make XSD 1.1. better! Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx/ http://www.codalogic.com/lmx/ ============================================= _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 16 14:54:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWLh-0000li-GU; Mon, 16 Apr 2007 14:54:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWLf-0000lL-W4; Mon, 16 Apr 2007 14:54:47 -0400 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdWLf-0004HJ-9P; Mon, 16 Apr 2007 14:54:47 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGL00KA0TVWRK@lhrga01-in.huawei.com>; Mon, 16 Apr 2007 19:55:09 +0100 (BST) Received: from jys3105093470ty ([62.159.183.141]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGL00INLTVSKM@lhrga01-in.huawei.com>; Mon, 16 Apr 2007 19:55:08 +0100 (BST) Date: Mon, 16 Apr 2007 20:55:27 +0300 From: Linyi Tian In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D226B30AD@namail5.corp.adobe.com> To: 'Henry Sinnreich' , sipping@ietf.org Message-id: <000501c78050$6c5de3e0$8b010a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: Acd+BRGvg5j3Onq2SFOXOU2/y8iMmwAKt1wAAB9++ZAAaEZKIA== X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: xcon@ietf.org Subject: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Dear Henry Thank you very much for your comments. Some responses below: In the mobile environment user may not desire to access the web site to create conf info for a conference especially when it is in ad hoc manner. So the assumption is that it is boring for user to create an ad hoc conference using two operations. This draft respects the same consideration like 'some environments have tough requirements regarding conference establishment time' in another I-D for uri list conferencing. In case of user only wants very simple conference information and policy, such as subject and maximum numbers of participants, to be provided for an ad hoc conference via only one operation. The SIP invite could be used to convey it to create a conference fulfilling this requirement. Best Regards, Linyi -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Saturday, April 14, 2007 7:07 PM To: Linyi Tian; sipping@ietf.org Cc: xcon@ietf.org Subject: RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt How would this compare with providing the conference info and policy over a web page is now the 'standard procedure'? Or is the assumption that there is no web and we live in a voice-only world? >'some environments have tough requirements regarding conference > establishment time' Why is this a SIP issue? What about users having predefined access to their conference service by IT or by contract and just telling the participants to dial in? Thanks, Henry -----Original Message----- From: Linyi Tian [mailto:tianlinyi@huawei.com] Sent: Friday, April 13, 2007 6:01 PM To: sipping@ietf.org Cc: xcon@ietf.org Subject: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Dear all We just submitted an I-D to IETF regarding conference. Please kindly review and feel free to give us any comments. Thank you in advance. Abstract & Requirements Anaylyze This specification defines a mechanism that allows a UAC to provide a conference server with the initial conference information and policy using an INVITE-contained conference info. some environments have tough requirements regarding conference establishment time. This is true especially when a user wants to create a conference in ad hoc manner. In addition user may only want very simple conference information and policy, for example the subject and maximum numbers of participants, to be provided for an ad hoc conference via only one operation. In this case they rarely desire to manipulate the conference policy during the conference. In current art there is no mechanism for new participants to be aware of the conference information they are being invited to. It causes difficulty for them to decide whether to accept this invitation which may not fall into their interest. Best Regards, Linyi -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Saturday, April 14, 2007 3:50 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-linyi-sipping-invite-with-conf-info-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Initiation Protocol (SIP) INVITE with Conference Info Author(s) : L. Tian, Q. Sun Filename : draft-linyi-sipping-invite-with-conf-info-00.txt Pages : 24 Date : 2007-4-13 This specification defines a mechanism that allows a UAC to provide a conference server with the initial conference information and policy using an INVITE-contained conference info. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-linyi-sipping-invite-with-conf -info-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-linyi-sipping-invite-with-conf-info-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-linyi-sipping-invite-with-conf-info-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Apr 18 04:26:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He5V7-0002iO-Rp; Wed, 18 Apr 2007 04:26:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He5V2-0002hk-5J; Wed, 18 Apr 2007 04:26:48 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He5Uz-0003pH-79; Wed, 18 Apr 2007 04:26:48 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 859DF21267; Wed, 18 Apr 2007 10:26:44 +0200 (CEST) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-fe-4625d644634d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 62EF421133; Wed, 18 Apr 2007 10:26:44 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 10:26:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Date: Wed, 18 Apr 2007 10:26:10 +0200 Message-ID: In-Reply-To: <000501c78050$6c5de3e0$8b010a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Thread-Index: Acd+BRGvg5j3Onq2SFOXOU2/y8iMmwAKt1wAAB9++ZAAaEZKIABPskUw References: <24CCCC428EFEA2469BF046DB3C7A8D226B30AD@namail5.corp.adobe.com> <000501c78050$6c5de3e0$8b010a0a@china.huawei.com> From: "Oscar Novo \(JO/LMF\)" To: "Linyi Tian" , "Henry Sinnreich" , X-OriginalArrivalTime: 18 Apr 2007 08:26:44.0148 (UTC) FILETIME=[4C2C0F40:01C78193] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Linyi, In the future, XCON WG will work in a protocol to create and manipulate the conference information in a server. The use of that protocol may be completely transparent for the mobile users. So, mobile users could create ad hoc conferences in an easy way. I think one important use cases to be describe in your draft would be when the number of URIs in the URI-List exceeds the number specified in element send by the UAC. Regards, Oscar -----Original Message----- From: Linyi Tian [mailto:tianlinyi@huawei.com]=20 Sent: 16. huhtikuuta 2007 20:55 To: 'Henry Sinnreich'; sipping@ietf.org Cc: xcon@ietf.org Subject: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Dear Henry Thank you very much for your comments. Some responses below: In the mobile environment user may not desire to access the web site to create conf info for a conference especially when it is in ad hoc manner. So the assumption is that it is boring for user to create an ad hoc conference using two operations.=20 This draft respects the same consideration like 'some environments have tough requirements regarding conference establishment time' in another I-D for uri list conferencing. In case of user only wants very simple conference information and policy, such as subject and maximum numbers of participants, to be provided for an ad hoc conference via only one operation. The SIP invite could be used to convey it to create a conference fulfilling this requirement. Best Regards, Linyi -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Saturday, April 14, 2007 7:07 PM To: Linyi Tian; sipping@ietf.org Cc: xcon@ietf.org Subject: RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt How would this compare with providing the conference info and policy over a web page is now the 'standard procedure'? Or is the assumption that there is no web and we live in a voice-only world? >'some environments have tough requirements regarding conference =20 >establishment time' Why is this a SIP issue? What about users having predefined access to their conference service by IT or by contract and just telling the participants to dial in? Thanks, Henry -----Original Message----- From: Linyi Tian [mailto:tianlinyi@huawei.com] Sent: Friday, April 13, 2007 6:01 PM To: sipping@ietf.org Cc: xcon@ietf.org Subject: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Dear all We just submitted an I-D to IETF regarding conference. Please kindly review and feel free to give us any comments. Thank you in advance.=20 Abstract & Requirements Anaylyze This specification defines a mechanism that allows a UAC to provide a conference server with the initial conference information and policy using an INVITE-contained conference info. some environments have tough requirements regarding conference establishment time. This is true especially when a user wants to create a conference in ad hoc manner. In addition user may only want very simple conference information and policy, for example the subject and maximum numbers of participants, to be provided for an ad hoc conference via only one operation. In this case they rarely desire to manipulate the conference policy during the conference. In current art there is no mechanism for new participants to be aware of the conference information they are being invited to. It causes difficulty for them to decide whether to accept this invitation which may not fall into their interest. Best Regards, Linyi -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Saturday, April 14, 2007 3:50 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-linyi-sipping-invite-with-conf-info-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Initiation Protocol (SIP) INVITE with Conference Info Author(s) : L. Tian, Q. Sun Filename : draft-linyi-sipping-invite-with-conf-info-00.txt Pages : 24 Date : 2007-4-13 =09 This specification defines a mechanism that allows a UAC to provide a conference server with the initial conference information and policy using an INVITE-contained conference info. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-linyi-sipping-invite-with-conf -info-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-linyi-sipping-invite-with-conf-info-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-linyi-sipping-invite-with-conf-info-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Apr 18 10:38:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBIn-0007Bk-4c; Wed, 18 Apr 2007 10:38:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBIk-0007Ay-FV; Wed, 18 Apr 2007 10:38:30 -0400 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBIi-0008DE-Sv; Wed, 18 Apr 2007 10:38:30 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGP00J0M7CVJI@lhrga01-in.huawei.com>; Wed, 18 Apr 2007 15:38:55 +0100 (BST) Received: from jys3105093470ty ([62.159.183.141]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGP001377CPO4@lhrga01-in.huawei.com>; Wed, 18 Apr 2007 15:38:55 +0100 (BST) Date: Wed, 18 Apr 2007 16:39:12 +0300 From: Linyi Tian Subject: RE: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt In-reply-to: To: "'Oscar Novo (JO/LMF)'" , 'Henry Sinnreich' , sipping@ietf.org Message-id: <006901c781be$f3609170$8b010a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: Acd+BRGvg5j3Onq2SFOXOU2/y8iMmwAKt1wAAB9++ZAAaEZKIABPskUwAAwdJ/A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi, Oscar You are very much appreciated for the information and suggestion! Yes, we are aware of the work ongoing in XCON. However we do not know when this protocol will be completed. There is much work to do with my guess. Maybe somebody can not wait, e.g. OMA is very interested in XCAP solution for pre-defined group communications. For ad-hoc conference, XCAP may not be suitable, but this draft will work well. In addition to that, there is still no way to provide ad-hoc conference with conference information or policy in OMA. But we see some requirements within some ongoing work in other organizations. This I-D tries to provide the facility. It can be treated as a supplementary solution for existing arts which may particularly address some cases in a simple way. Regarding maximum counts of participants, actually I have following sentence related in section 5: The UAC MUST ensure the number of URIs in the URI-List will not exceed the number specified in element if it presents. Does it satisfy what you need? If not, could you give me some further explanation? If something needs to be changed, I can add them in the next version. Again, much appreciated for your comments! Thank you! Best Regards, Linyi -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com] Sent: Wednesday, April 18, 2007 11:26 AM To: Linyi Tian; Henry Sinnreich; sipping@ietf.org Cc: xcon@ietf.org Subject: RE: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Hi Linyi, In the future, XCON WG will work in a protocol to create and manipulate the conference information in a server. The use of that protocol may be completely transparent for the mobile users. So, mobile users could create ad hoc conferences in an easy way. I think one important use cases to be describe in your draft would be when the number of URIs in the URI-List exceeds the number specified in element send by the UAC. Regards, Oscar -----Original Message----- From: Linyi Tian [mailto:tianlinyi@huawei.com] Sent: 16. huhtikuuta 2007 20:55 To: 'Henry Sinnreich'; sipping@ietf.org Cc: xcon@ietf.org Subject: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Dear Henry Thank you very much for your comments. Some responses below: In the mobile environment user may not desire to access the web site to create conf info for a conference especially when it is in ad hoc manner. So the assumption is that it is boring for user to create an ad hoc conference using two operations. This draft respects the same consideration like 'some environments have tough requirements regarding conference establishment time' in another I-D for uri list conferencing. In case of user only wants very simple conference information and policy, such as subject and maximum numbers of participants, to be provided for an ad hoc conference via only one operation. The SIP invite could be used to convey it to create a conference fulfilling this requirement. Best Regards, Linyi -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Saturday, April 14, 2007 7:07 PM To: Linyi Tian; sipping@ietf.org Cc: xcon@ietf.org Subject: RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt How would this compare with providing the conference info and policy over a web page is now the 'standard procedure'? Or is the assumption that there is no web and we live in a voice-only world? >'some environments have tough requirements regarding conference >establishment time' Why is this a SIP issue? What about users having predefined access to their conference service by IT or by contract and just telling the participants to dial in? Thanks, Henry -----Original Message----- From: Linyi Tian [mailto:tianlinyi@huawei.com] Sent: Friday, April 13, 2007 6:01 PM To: sipping@ietf.org Cc: xcon@ietf.org Subject: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Dear all We just submitted an I-D to IETF regarding conference. Please kindly review and feel free to give us any comments. Thank you in advance. Abstract & Requirements Anaylyze This specification defines a mechanism that allows a UAC to provide a conference server with the initial conference information and policy using an INVITE-contained conference info. some environments have tough requirements regarding conference establishment time. This is true especially when a user wants to create a conference in ad hoc manner. In addition user may only want very simple conference information and policy, for example the subject and maximum numbers of participants, to be provided for an ad hoc conference via only one operation. In this case they rarely desire to manipulate the conference policy during the conference. In current art there is no mechanism for new participants to be aware of the conference information they are being invited to. It causes difficulty for them to decide whether to accept this invitation which may not fall into their interest. Best Regards, Linyi -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Saturday, April 14, 2007 3:50 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-linyi-sipping-invite-with-conf-info-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Initiation Protocol (SIP) INVITE with Conference Info Author(s) : L. Tian, Q. Sun Filename : draft-linyi-sipping-invite-with-conf-info-00.txt Pages : 24 Date : 2007-4-13 This specification defines a mechanism that allows a UAC to provide a conference server with the initial conference information and policy using an INVITE-contained conference info. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-linyi-sipping-invite-with-conf -info-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-linyi-sipping-invite-with-conf-info-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-linyi-sipping-invite-with-conf-info-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Apr 18 15:50:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeGAr-00088w-I9; Wed, 18 Apr 2007 15:50:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeGAj-00086A-8y; Wed, 18 Apr 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HeGAi-0003mR-PZ; Wed, 18 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B3C4817643; Wed, 18 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HeGAE-0002EM-Fs; Wed, 18 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 18 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-common-data-model-05.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Conference Information Data Model for Centralized Conferencing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-05.txt Pages : 68 Date : 2007-4-18 This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference object, which can be manipulated using a conference control protocol, at a conference server represents a particular instantiation of this data model. The conference information data model defined in this document is an extension of (and thus, compatible with) the model 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-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-common-data-model-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-common-data-model-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-18115617.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-common-data-model-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-common-data-model-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-18115617.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --NextPart-- From xcon-bounces@ietf.org Thu Apr 19 04:16:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeRof-0000xs-Ew; Thu, 19 Apr 2007 04:16:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeRnC-0008If-Dx for xcon@ietf.org; Thu, 19 Apr 2007 04:15:02 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeRbn-0000YV-Vg for xcon@ietf.org; Thu, 19 Apr 2007 04:03:16 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5DD71209AA for ; Thu, 19 Apr 2007 10:03:15 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-44-462722430cdb Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 492832067F for ; Thu, 19 Apr 2007 10:03:15 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 10:03:15 +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: Thu, 19 Apr 2007 10:02:41 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of the Conference Information Data Model for Centralized Conferencing Thread-Index: AceB8syO9Vrug2KjQdO0g/4jJeVlpAAZH55A References: From: "Oscar Novo \(JO/LMF\)" To: X-OriginalArrivalTime: 19 Apr 2007 08:03:15.0208 (UTC) FILETIME=[2ECAA080:01C78259] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [XCON] New version of the Conference Information Data Model for Centralized Conferencing X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hello everybody, A new version of the data model I-D is available in:=20 http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-05 .txt These are the changes of version 05 in relation to version 4: - We have removed the policy from the draft. - We have partially included the information of the "A Universal Resource Identifier (URI) for Centralized Conferencing" draft in the data model and we have created the IANA registration. =20 - We have partially included the information of the "A User Identifier for Centralized Conferencing (XCON)" draft in the data model and we have created the IANA registration. =20 - We have changed the status of the draft from Informational to Standard. - Few modifications in the RELAX NG Schema - Few modifications in the XML example Comments are welcome! Regards, Oscar Novo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Apr 19 05:05:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeSaM-00015g-8M; Thu, 19 Apr 2007 05:05:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeSaJ-00015I-Es; Thu, 19 Apr 2007 05:05:47 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeSaI-00082A-Pb; Thu, 19 Apr 2007 05:05:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Apr 2007 12:06:00 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C047C20EF@IsrExch01.israel.polycom.com> In-Reply-To: <019001c77e30$6f3c9600$0364a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Thread-Index: Acd+BRGvg5j3Onq2SFOXOU2/y8iMmwAKt1wAAQfxWcA= From: "Even, Roni" To: "Linyi Tian" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: xcon@ietf.org Subject: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0945395394==" Errors-To: xcon-bounces@ietf.org --===============0945395394== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGlueWksDQoNCkkgcmVhZCB0aGUgZHJhZnQgYW5kIGhhdmUgc29tZSBjb21tZW50cyBhYm91dCB0 aGlzIGRpcmVjdGlvbi4NCg0KDQoxLiBJdCBpcyBhbiBhZHZhbnRhZ2UgaW4gbGV0dGluZyB0aGUg aW52aXRlZSBrbm93IHRoZSBzdWJqZWN0IG9mIHRoZSBjb25mZXJlbmNlIGJ1dCB0aGlzIGlzIHRy dWUgYWxzbyBmb3IgYSBwb2ludCB0byBwb2ludCBjYWxsLiBUaGlzIGlzIG5vdCB1bmlxdWUgdG8g Y29uZmVyZW5jZS4NCg0KMi4gbGV0dGluZyB0aGUgaW52aXRlZSBrbm93IHdobyB0aGUgb3RoZXIg cGFydGljaXBhbnRzIGluIHRoZSBjb25mZXJlbmNlIGFuZCB0aGUgY29uZmVyZW5jZSBpbmZvcm1h dGlvbiBpcyBiZXR0ZXIgc2VydmVkIGJ5IHRoZSBldmVudCBwYWNrYWdlLg0KDQozLiBUaGUgaXNz dWUgaW4gdGhlIFVSSSBsaXN0IHdhcyB0byByZXBsYWNlIG11bHRpcGxlIHJlZmVycyB3aXRoIG9u IG1lc3NhZ2UgZm9yIGludml0aW5nIHBhcnRpY2lwYW50cywgdGhpcyB3YXMgcGFydCBvZiBhIGdl bmVyYWwgbWVjaGFuaXNtLiBUaGUgaXNzdWUgb2YgZGVmaW5pbmcgdGhlIGNvbmZlcmVuY2UgcGFy YW1ldGVycyBhbmQgY29udHJvbGxpbmcgdGhlIGNvbmZlcmVuY2Ugd2FzIG5vdCBjb25zaWRlcmVk IGluIHNjb3BlIGZvciB0aGlzIHdvcmsuDQoNCjQuICJJbiBjdXJyZW50IGFydCB0aGVyZSBpcyBu byBtZWNoYW5pc20gZm9yIG5ldyBwYXJ0aWNpcGFudHMgdG8gYmUgYXdhcmUgb2YgdGhlIGNvbmZl cmVuY2UgaW5mb3JtYXRpb24gdGhleSBhcmUgYmVpbmcgaW52aXRlZCB0by4iIFRoaXMgaXMgd2hh dCB0aGUgY29uZmVyZW5jZSBldmVudCBwYWNrYWdlIGlzIHVzZWQgZm9yLiBXaGVuIHlvdSBnZXQg YW4gSW52aXRlIHdpdGggaXNmb2N1cyB5b3UgY2FuIHN1YnNjcmliZSB0byB0aGUgY29uZmVyZW5j ZSBldmVudCBwYWNrYWdlIGFuZCBnZXQgbm90aWZpY2F0aW9uIGJlZm9yZSBqb2luaW5nLg0KDQo1 LiBSRVEgMSBpcyBjb3ZlcmVkIGJ5IFhDT04gd2hpbGUgUkVRIDIgaXMgY292ZXJlZCBieSB0aGUg ZXZlbnQgcGFja2FnZS4NCg0KNi4gU2VjdGlvbiA0LjEuMiBhZGRzIGRhdGEgZnJvbSB0aGUgWENP TiBkYXRhIG1vZGVsIGluY2x1ZGluZyB0aGUgc3RhcnQgdGltZSB5ZXQgdGhlIHJlcXVpcmVtZW50 cyB0YWxrIGFib3V0IGFkLWhvYyBjb25mZXJlbmNlcy4gDQoNCjcuIFVzaW5nIHRoaXMgbWV0aG9k IGZvciBjb250cm9sbGluZyB0aGUgY29uZmVyZW5jZSBieSBzZW5kaW5nIHJlLUludml0ZSB3aWxs IGNhdXNlIGEgbG90IG9mIHRyYWZmaWMgdGhyb3VnaCB0aGUgcHJveGllcyBpbiB0aGUgbWlkZGxl IGFuZCB0aGF0IGlzIHdoeSBYQ09OIGlzIHRoZSB3YXkgdG8gZG8gaXQuDQoNCg0KVG8gc3VtbWFy aXplIC0gSSBjYW4gc2VlIHNvbWUgdmFsdWUgaW4gYmVpbmcgYWJsZSB0byBzZW5kIHNvbWUgaW5m b3JtYXRpb24gdG8gdGhlIGNvbmZlcmVuY2UgZmFjdG9yeSBmb3IgdGhlIGFkLWhvYyBjYXNlLiBU aGUgaW5mb3JtYXRpb24gd2lsbCBpbmNsdWRlIHRoZSByZXF1aXJlZCBtZWRpYSBhbmQgdXNlciBj b3VudCBidXQgdGhpcyBkcmFmdCBoYXMgYSB3aWRlciBzY29wZS4NCg0KUm9uaSBFdmVuIA0KDQoN Cg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGlueWkgVGlhbiBb bWFpbHRvOnRpYW5saW55aUBodWF3ZWkuY29tXQ0KPiBTZW50OiBTYXR1cmRheSwgQXByaWwgMTQs IDIwMDcgNDowMSBBTQ0KPiBUbzogc2lwcGluZ0BpZXRmLm9yZw0KPiBDYzogeGNvbkBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBbU2lwcGluZ10gRllJOiBJLURBQ1RJT046ZHJhZnQtbGlueWktc2lwcGlu Zy1pbnZpdGUtd2l0aC1jb25mLQ0KPiBpbmZvLTAwLnR4dA0KPiANCj4gRGVhciBhbGwNCj4gDQo+ IFdlIGp1c3Qgc3VibWl0dGVkIGFuIEktRCB0byBJRVRGIHJlZ2FyZGluZyBjb25mZXJlbmNlLiBQ bGVhc2Uga2luZGx5DQo+IHJldmlldyBhbmQgZmVlbCBmcmVlIHRvIGdpdmUgdXMgYW55IGNvbW1l bnRzLiBUaGFuayB5b3UgaW4gYWR2YW5jZS4NCj4gDQo+IEFic3RyYWN0ICYgUmVxdWlyZW1lbnRz IEFuYXlseXplDQo+ICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgbWVjaGFuaXNtIHRo YXQgYWxsb3dzIGEgVUFDIHRvIHByb3ZpZGUgYQ0KPiAgICBjb25mZXJlbmNlIHNlcnZlciB3aXRo IHRoZSBpbml0aWFsIGNvbmZlcmVuY2UgaW5mb3JtYXRpb24gYW5kIHBvbGljeQ0KPiAgICB1c2lu ZyBhbiBJTlZJVEUtY29udGFpbmVkIGNvbmZlcmVuY2UgaW5mby4NCj4gDQo+ICAgIHNvbWUgZW52 aXJvbm1lbnRzIGhhdmUgdG91Z2ggcmVxdWlyZW1lbnRzIHJlZ2FyZGluZyBjb25mZXJlbmNlDQo+ ICAgIGVzdGFibGlzaG1lbnQgdGltZS4gIFRoaXMgaXMgdHJ1ZSBlc3BlY2lhbGx5IHdoZW4gYSB1 c2VyIHdhbnRzIHRvDQo+ICAgIGNyZWF0ZSBhIGNvbmZlcmVuY2UgaW4gYWQgaG9jIG1hbm5lci4g IEluIGFkZGl0aW9uIHVzZXIgbWF5IG9ubHkgd2FudA0KPiAgICB2ZXJ5IHNpbXBsZSBjb25mZXJl bmNlIGluZm9ybWF0aW9uIGFuZCBwb2xpY3ksIGZvciBleGFtcGxlIHRoZQ0KPiAgICBzdWJqZWN0 IGFuZCBtYXhpbXVtIG51bWJlcnMgb2YgcGFydGljaXBhbnRzLCB0byBiZSBwcm92aWRlZCBmb3Ig YW4gYWQNCj4gICAgaG9jIGNvbmZlcmVuY2UgdmlhIG9ubHkgb25lIG9wZXJhdGlvbi4gIEluIHRo aXMgY2FzZSB0aGV5IHJhcmVseQ0KPiAgICBkZXNpcmUgdG8gbWFuaXB1bGF0ZSB0aGUgY29uZmVy ZW5jZSBwb2xpY3kgZHVyaW5nIHRoZSBjb25mZXJlbmNlLg0KPiANCj4gICAgSW4gY3VycmVudCBh cnQgdGhlcmUgaXMgbm8gbWVjaGFuaXNtIGZvciBuZXcgcGFydGljaXBhbnRzIHRvIGJlIGF3YXJl DQo+ICAgIG9mIHRoZSBjb25mZXJlbmNlIGluZm9ybWF0aW9uIHRoZXkgYXJlIGJlaW5nIGludml0 ZWQgdG8uICBJdCBjYXVzZXMNCj4gICAgZGlmZmljdWx0eSBmb3IgdGhlbSB0byBkZWNpZGUgd2hl dGhlciB0byBhY2NlcHQgdGhpcyBpbnZpdGF0aW9uIHdoaWNoDQo+ICAgIG1heSBub3QgZmFsbCBp bnRvIHRoZWlyIGludGVyZXN0Lg0KPiANCj4gQmVzdCBSZWdhcmRzLA0KPiBMaW55aQ0KPiANCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSW50ZXJuZXQtRHJhZnRzQGlldGYu b3JnIFttYWlsdG86SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBTYXR1cmRheSwg QXByaWwgMTQsIDIwMDcgMzo1MCBBTQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IFN1 YmplY3Q6IEktRCBBQ1RJT046ZHJhZnQtbGlueWktc2lwcGluZy1pbnZpdGUtd2l0aC1jb25mLWlu Zm8tMDAudHh0DQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuDQo+IA0KPiANCj4gCVRp dGxlCQk6IFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBJTlZJVEUgd2l0aA0KPiBD b25mZXJlbmNlIEluZm8NCj4gCUF1dGhvcihzKQk6IEwuIFRpYW4sIFEuIFN1bg0KPiAJRmlsZW5h bWUJOiBkcmFmdC1saW55aS1zaXBwaW5nLWludml0ZS13aXRoLWNvbmYtaW5mby0wMC50eHQNCj4g CVBhZ2VzCQk6IDI0DQo+IAlEYXRlCQk6IDIwMDctNC0xMw0KPiANCj4gDQo+ICAgIFRoaXMgc3Bl Y2lmaWNhdGlvbiBkZWZpbmVzIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIGEgVUFDIHRvIHByb3Zp ZGUgYQ0KPiAgICBjb25mZXJlbmNlIHNlcnZlciB3aXRoIHRoZSBpbml0aWFsIGNvbmZlcmVuY2Ug aW5mb3JtYXRpb24gYW5kIHBvbGljeQ0KPiAgICB1c2luZyBhbiBJTlZJVEUtY29udGFpbmVkIGNv bmZlcmVuY2UgaW5mby4NCj4gDQo+IA0KPiANCj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJh ZnQgaXM6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpbnlp LXNpcHBpbmctaW52aXRlLXdpdGgtY29uZi0NCj4gaW5mby0wMC50eHQNCj4gDQo+IFRvIHJlbW92 ZSB5b3Vyc2VsZiBmcm9tIHRoZSBJLUQgQW5ub3VuY2VtZW50IGxpc3QsIHNlbmQgYSBtZXNzYWdl IHRvDQo+IGktZC1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnIHdpdGggdGhlIHdvcmQgdW5zdWJz Y3JpYmUgaW4gdGhlIGJvZHkgb2YNCj4gdGhlIG1lc3NhZ2UuDQo+IFlvdSBjYW4gYWxzbyB2aXNp dCBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9JLUQtYW5ub3VuY2UNCj4g dG8gY2hhbmdlIHlvdXIgc3Vic2NyaXB0aW9uIHNldHRpbmdzLg0KPiANCj4gSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQLiBMb2dpbiB3aXRoIHRoZQ0K PiB1c2VybmFtZSAiYW5vbnltb3VzIiBhbmQgYSBwYXNzd29yZCBvZiB5b3VyIGUtbWFpbCBhZGRy ZXNzLiBBZnRlcg0KPiBsb2dnaW5nIGluLCB0eXBlICJjZCBpbnRlcm5ldC1kcmFmdHMiIGFuZCB0 aGVuDQo+ICJnZXQgZHJhZnQtbGlueWktc2lwcGluZy1pbnZpdGUtd2l0aC1jb25mLWluZm8tMDAu dHh0Ii4NCj4gDQo+IEEgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMgY2FuIGJl IGZvdW5kIGluDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4gDQo+IEludGVybmV0LURyYWZ0 cyBjYW4gYWxzbyBiZSBvYnRhaW5lZCBieSBlLW1haWwuDQo+IA0KPiBTZW5kIGEgbWVzc2FnZSB0 bzoNCj4gCW1haWxzZXJ2QGlldGYub3JnLg0KPiBJbiB0aGUgYm9keSB0eXBlOg0KPiAJIkZJTEUg L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saW55aS1zaXBwaW5nLWludml0ZS13aXRoLWNvbmYtaW5m by0NCj4gMDAudHh0Ii4NCj4gDQo+IE5PVEU6CVRoZSBtYWlsIHNlcnZlciBhdCBpZXRmLm9yZyBj YW4gcmV0dXJuIHRoZSBkb2N1bWVudCBpbg0KPiAJTUlNRS1lbmNvZGVkIGZvcm0gYnkgdXNpbmcg dGhlICJtcGFjayIgdXRpbGl0eS4gIFRvIHVzZSB0aGlzDQo+IAlmZWF0dXJlLCBpbnNlcnQgdGhl IGNvbW1hbmQgIkVOQ09ESU5HIG1pbWUiIGJlZm9yZSB0aGUgIkZJTEUiDQo+IAljb21tYW5kLiAg VG8gZGVjb2RlIHRoZSByZXNwb25zZShzKSwgeW91IHdpbGwgbmVlZCAibXVucGFjayIgb3INCj4g CWEgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXIuICBEaWZmZXJlbnQgTUlNRS1jb21wbGlhbnQg bWFpbCByZWFkZXJzDQo+IAlleGhpYml0IGRpZmZlcmVudCBiZWhhdmlvciwgZXNwZWNpYWxseSB3 aGVuIGRlYWxpbmcgd2l0aA0KPiAJIm11bHRpcGFydCIgTUlNRSBtZXNzYWdlcyAoaS5lLiBkb2N1 bWVudHMgd2hpY2ggaGF2ZSBiZWVuIHNwbGl0DQo+IAl1cCBpbnRvIG11bHRpcGxlIG1lc3NhZ2Vz KSwgc28gY2hlY2sgeW91ciBsb2NhbCBkb2N1bWVudGF0aW9uIG9uDQo+IAlob3cgdG8gbWFuaXB1 bGF0ZSB0aGVzZSBtZXNzYWdlcy4NCj4gDQo+IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwg ZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFkZXINCj4gaW1wbGVtZW50YXRpb24gdG8g YXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUNCj4gSW50ZXJu ZXQtRHJhZnQuDQo= --===============0945395394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0945395394==-- From xcon-bounces@ietf.org Thu Apr 19 05:59:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeTPu-00019H-Jv; Thu, 19 Apr 2007 05:59:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeTPs-00018q-3v; Thu, 19 Apr 2007 05:59:04 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeTPr-0005Fh-4Z; Thu, 19 Apr 2007 05:59:04 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 845472094E; Thu, 19 Apr 2007 11:59:02 +0200 (CEST) X-AuditID: c1b4fb3c-aacefbb0000073d5-8c-46273d662ee0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6399320502; Thu, 19 Apr 2007 11:59:02 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 11:59:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Date: Thu, 19 Apr 2007 11:58:24 +0200 Message-ID: In-Reply-To: <006901c781be$f3609170$8b010a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Thread-Index: Acd+BRGvg5j3Onq2SFOXOU2/y8iMmwAKt1wAAB9++ZAAaEZKIABPskUwAAwdJ/AAJ1F3YA== References: <006901c781be$f3609170$8b010a0a@china.huawei.com> From: "Oscar Novo \(JO/LMF\)" To: "Linyi Tian" , X-OriginalArrivalTime: 19 Apr 2007 09:59:01.0727 (UTC) FILETIME=[5B3D4EF0:01C78269] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Linyi, I guess the XCON WG will start working on the conference control protocol in a few IETF but my impression is that we'll need long time to complete this protocol. So, your supplementary solution could be fine before we don't define anything in XCON. =20 Regarding the possible inconsistency between the URI-List and the maximum number of users, I think it would be useful to described the server behaviour in this case. At least, I can think in two different solutions for that use case: - The server REJECTS the INVITE and sends an error to the UAC. - The server ACCEPTS the INVITE and changes the maximum user number of the conference to the number of URIs in the URI-List. =20 Cheers, Oscar -----Original Message----- From: Linyi Tian [mailto:tianlinyi@huawei.com]=20 Sent: 18. huhtikuuta 2007 16:39 To: Oscar Novo (JO/LMF); 'Henry Sinnreich'; sipping@ietf.org Cc: xcon@ietf.org Subject: RE: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Hi, Oscar You are very much appreciated for the information and suggestion! Yes, we are aware of the work ongoing in XCON. However we do not know when this protocol will be completed. There is much work to do with my guess. Maybe somebody can not wait, e.g. OMA is very interested in XCAP solution for pre-defined group communications. For ad-hoc conference, XCAP may not be suitable, but this draft will work well. In addition to that, there is still no way to provide ad-hoc conference with conference information or policy in OMA. But we see some requirements within some ongoing work in other organizations. This I-D tries to provide the facility. It can be treated as a supplementary solution for existing arts which may particularly address some cases in a simple way. Regarding maximum counts of participants, actually I have following sentence related in section 5: The UAC MUST ensure the number of URIs in the URI-List will not exceed the number specified in element if it presents. Does it satisfy what you need? If not, could you give me some further explanation? If something needs to be changed, I can add them in the next version. Again, much appreciated for your comments! Thank you! Best Regards, Linyi -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com] Sent: Wednesday, April 18, 2007 11:26 AM To: Linyi Tian; Henry Sinnreich; sipping@ietf.org Cc: xcon@ietf.org Subject: RE: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Hi Linyi, In the future, XCON WG will work in a protocol to create and manipulate the conference information in a server. The use of that protocol may be completely transparent for the mobile users. So, mobile users could create ad hoc conferences in an easy way. I think one important use cases to be describe in your draft would be when the number of URIs in the URI-List exceeds the number specified in element send by the UAC. Regards, Oscar -----Original Message----- From: Linyi Tian [mailto:tianlinyi@huawei.com] Sent: 16. huhtikuuta 2007 20:55 To: 'Henry Sinnreich'; sipping@ietf.org Cc: xcon@ietf.org Subject: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Dear Henry Thank you very much for your comments. Some responses below: In the mobile environment user may not desire to access the web site to create conf info for a conference especially when it is in ad hoc manner. So the assumption is that it is boring for user to create an ad hoc conference using two operations.=20 This draft respects the same consideration like 'some environments have tough requirements regarding conference establishment time' in another I-D for uri list conferencing. In case of user only wants very simple conference information and policy, such as subject and maximum numbers of participants, to be provided for an ad hoc conference via only one operation. The SIP invite could be used to convey it to create a conference fulfilling this requirement. Best Regards, Linyi -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Saturday, April 14, 2007 7:07 PM To: Linyi Tian; sipping@ietf.org Cc: xcon@ietf.org Subject: RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt How would this compare with providing the conference info and policy over a web page is now the 'standard procedure'? Or is the assumption that there is no web and we live in a voice-only world? >'some environments have tough requirements regarding conference=20 >establishment time' Why is this a SIP issue? What about users having predefined access to their conference service by IT or by contract and just telling the participants to dial in? Thanks, Henry -----Original Message----- From: Linyi Tian [mailto:tianlinyi@huawei.com] Sent: Friday, April 13, 2007 6:01 PM To: sipping@ietf.org Cc: xcon@ietf.org Subject: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Dear all We just submitted an I-D to IETF regarding conference. Please kindly review and feel free to give us any comments. Thank you in advance.=20 Abstract & Requirements Anaylyze This specification defines a mechanism that allows a UAC to provide a conference server with the initial conference information and policy using an INVITE-contained conference info. some environments have tough requirements regarding conference establishment time. This is true especially when a user wants to create a conference in ad hoc manner. In addition user may only want very simple conference information and policy, for example the subject and maximum numbers of participants, to be provided for an ad hoc conference via only one operation. In this case they rarely desire to manipulate the conference policy during the conference. In current art there is no mechanism for new participants to be aware of the conference information they are being invited to. It causes difficulty for them to decide whether to accept this invitation which may not fall into their interest. Best Regards, Linyi -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Saturday, April 14, 2007 3:50 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-linyi-sipping-invite-with-conf-info-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Initiation Protocol (SIP) INVITE with Conference Info Author(s) : L. Tian, Q. Sun Filename : draft-linyi-sipping-invite-with-conf-info-00.txt Pages : 24 Date : 2007-4-13 =09 This specification defines a mechanism that allows a UAC to provide a conference server with the initial conference information and policy using an INVITE-contained conference info. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-linyi-sipping-invite-with-conf -info-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-linyi-sipping-invite-with-conf-info-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-linyi-sipping-invite-with-conf-info-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Apr 19 06:59:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeUMB-0003hh-NL; Thu, 19 Apr 2007 06:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeUM9-0003hF-Hn; Thu, 19 Apr 2007 06:59:17 -0400 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeUM8-0000Pj-PK; Thu, 19 Apr 2007 06:59:17 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGQ00A5VRVGV0@lhrga01-in.huawei.com>; Thu, 19 Apr 2007 11:59:41 +0100 (BST) Received: from jys3105093470ty ([62.159.183.141]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGQ00IUSRVCET@lhrga01-in.huawei.com>; Thu, 19 Apr 2007 11:59:40 +0100 (BST) Date: Thu, 19 Apr 2007 13:00:00 +0300 From: Linyi Tian Subject: RE: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt In-reply-to: To: "'Oscar Novo (JO/LMF)'" , sipping@ietf.org Message-id: <012601c78269$7e966170$8b010a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: Acd+BRGvg5j3Onq2SFOXOU2/y8iMmwAKt1wAAB9++ZAAaEZKIABPskUwAAwdJ/AAJ1F3YAADbMMw X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Dear Oscar Thank you very much for your valuable comments. I will reflect them in next revision. By the way, I was noticed that the I-D draft-ietf-xcon-common-data-model-05 was submitted to IETF. It affects our draft. So I need to dig into it and reflect the changes as well. Best Regards, Linyi -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com] Sent: Thursday, April 19, 2007 12:58 PM To: Linyi Tian; sipping@ietf.org Cc: xcon@ietf.org Subject: RE: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Hi Linyi, I guess the XCON WG will start working on the conference control protocol in a few IETF but my impression is that we'll need long time to complete this protocol. So, your supplementary solution could be fine before we don't define anything in XCON. Regarding the possible inconsistency between the URI-List and the maximum number of users, I think it would be useful to described the server behaviour in this case. At least, I can think in two different solutions for that use case: - The server REJECTS the INVITE and sends an error to the UAC. - The server ACCEPTS the INVITE and changes the maximum user number of the conference to the number of URIs in the URI-List. Cheers, Oscar -----Original Message----- From: Linyi Tian [mailto:tianlinyi@huawei.com] Sent: 18. huhtikuuta 2007 16:39 To: Oscar Novo (JO/LMF); 'Henry Sinnreich'; sipping@ietf.org Cc: xcon@ietf.org Subject: RE: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Hi, Oscar You are very much appreciated for the information and suggestion! Yes, we are aware of the work ongoing in XCON. However we do not know when this protocol will be completed. There is much work to do with my guess. Maybe somebody can not wait, e.g. OMA is very interested in XCAP solution for pre-defined group communications. For ad-hoc conference, XCAP may not be suitable, but this draft will work well. In addition to that, there is still no way to provide ad-hoc conference with conference information or policy in OMA. But we see some requirements within some ongoing work in other organizations. This I-D tries to provide the facility. It can be treated as a supplementary solution for existing arts which may particularly address some cases in a simple way. Regarding maximum counts of participants, actually I have following sentence related in section 5: The UAC MUST ensure the number of URIs in the URI-List will not exceed the number specified in element if it presents. Does it satisfy what you need? If not, could you give me some further explanation? If something needs to be changed, I can add them in the next version. Again, much appreciated for your comments! Thank you! Best Regards, Linyi -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com] Sent: Wednesday, April 18, 2007 11:26 AM To: Linyi Tian; Henry Sinnreich; sipping@ietf.org Cc: xcon@ietf.org Subject: RE: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Hi Linyi, In the future, XCON WG will work in a protocol to create and manipulate the conference information in a server. The use of that protocol may be completely transparent for the mobile users. So, mobile users could create ad hoc conferences in an easy way. I think one important use cases to be describe in your draft would be when the number of URIs in the URI-List exceeds the number specified in element send by the UAC. Regards, Oscar -----Original Message----- From: Linyi Tian [mailto:tianlinyi@huawei.com] Sent: 16. huhtikuuta 2007 20:55 To: 'Henry Sinnreich'; sipping@ietf.org Cc: xcon@ietf.org Subject: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Dear Henry Thank you very much for your comments. Some responses below: In the mobile environment user may not desire to access the web site to create conf info for a conference especially when it is in ad hoc manner. So the assumption is that it is boring for user to create an ad hoc conference using two operations. This draft respects the same consideration like 'some environments have tough requirements regarding conference establishment time' in another I-D for uri list conferencing. In case of user only wants very simple conference information and policy, such as subject and maximum numbers of participants, to be provided for an ad hoc conference via only one operation. The SIP invite could be used to convey it to create a conference fulfilling this requirement. Best Regards, Linyi -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Saturday, April 14, 2007 7:07 PM To: Linyi Tian; sipping@ietf.org Cc: xcon@ietf.org Subject: RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt How would this compare with providing the conference info and policy over a web page is now the 'standard procedure'? Or is the assumption that there is no web and we live in a voice-only world? >'some environments have tough requirements regarding conference >establishment time' Why is this a SIP issue? What about users having predefined access to their conference service by IT or by contract and just telling the participants to dial in? Thanks, Henry -----Original Message----- From: Linyi Tian [mailto:tianlinyi@huawei.com] Sent: Friday, April 13, 2007 6:01 PM To: sipping@ietf.org Cc: xcon@ietf.org Subject: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Dear all We just submitted an I-D to IETF regarding conference. Please kindly review and feel free to give us any comments. Thank you in advance. Abstract & Requirements Anaylyze This specification defines a mechanism that allows a UAC to provide a conference server with the initial conference information and policy using an INVITE-contained conference info. some environments have tough requirements regarding conference establishment time. This is true especially when a user wants to create a conference in ad hoc manner. In addition user may only want very simple conference information and policy, for example the subject and maximum numbers of participants, to be provided for an ad hoc conference via only one operation. In this case they rarely desire to manipulate the conference policy during the conference. In current art there is no mechanism for new participants to be aware of the conference information they are being invited to. It causes difficulty for them to decide whether to accept this invitation which may not fall into their interest. Best Regards, Linyi -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Saturday, April 14, 2007 3:50 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-linyi-sipping-invite-with-conf-info-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Initiation Protocol (SIP) INVITE with Conference Info Author(s) : L. Tian, Q. Sun Filename : draft-linyi-sipping-invite-with-conf-info-00.txt Pages : 24 Date : 2007-4-13 This specification defines a mechanism that allows a UAC to provide a conference server with the initial conference information and policy using an INVITE-contained conference info. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-linyi-sipping-invite-with-conf -info-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-linyi-sipping-invite-with-conf-info-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-linyi-sipping-invite-with-conf-info-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Apr 19 14:50:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hebic-00024f-5r; Thu, 19 Apr 2007 14:50:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hebia-00023n-5i; Thu, 19 Apr 2007 14:50:56 -0400 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HebiZ-00062p-Ct; Thu, 19 Apr 2007 14:50:56 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGR00AWJDPI2D@lhrga01-in.huawei.com>; Thu, 19 Apr 2007 19:51:19 +0100 (BST) Received: from jys3105093470ty ([62.159.183.141]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGR00EJYDPAUQ@lhrga01-in.huawei.com>; Thu, 19 Apr 2007 19:51:18 +0100 (BST) Date: Thu, 19 Apr 2007 20:51:33 +0300 From: Linyi Tian In-reply-to: <144ED8561CE90C41A3E5908EDECE315C047C20EF@IsrExch01.israel.polycom.com> To: "'Even, Roni'" , sipping@ietf.org Message-id: <000001c782ab$5e662740$8b010a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: Acd+BRGvg5j3Onq2SFOXOU2/y8iMmwAKt1wAAQfxWcAAFtkvIA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: xcon@ietf.org Subject: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Dear Roni Even Thank your for your kind review and feedback. Some responses inline with mark [Linyi]:) Best Regards, Linyi -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Thursday, April 19, 2007 12:06 PM To: Linyi Tian; sipping@ietf.org Cc: xcon@ietf.org Subject: RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt Linyi, I read the draft and have some comments about this direction. Linyi, I read the draft and have some comments about this direction. 1. It is an advantage in letting the invitee know the subject of the conference but this is true also for a point to point call. This is not unique to conference. [Linyi Tian] Good point! Do you mean that we need to use this mechanism for point to point scenario? 2. letting the invitee know who the other participants in the conference and the conference information is better served by the event package. [Linyi Tian] Actually I guess in ad hoc manner the mechanism in this draft is more efficient. 3. The issue in the URI list was to replace multiple refers with on message for inviting participants, this was part of a general mechanism. The issue of defining the conference parameters and controlling the conference was not considered in scope for this work. [Linyi Tian] Yes, that's true. But our draft does not have any intention to affect the URI-List work. Actually the mechanism in our draft can be used together with URI list. We just gave the example to address different scenarios: 1. without URI list; 2. with URI list. So when URI-List the conference server needs to perform more actions in addition to those defined in URI-List work. 4. "In current art there is no mechanism for new participants to be aware of the conference information they are being invited to." This is what the conference event package is used for. When you get an Invite with isfocus you can subscribe to the conference event package and get notification before joining. [Linyi Tian] Good catch! I guess the sentence I wrote is not quite precise. I will modify it. 5. REQ 1 is covered by XCON while REQ 2 is covered by the event package. [Linyi Tian] According to the comments you mentioned, I will update REQs to better reflect our intention. 6. Section 4.1.2 adds data from the XCON data model including the start time yet the requirements talk about ad-hoc conferences. [Linyi Tian] Good catch. That is a mistake. Anyway I need to change something in next revision since that draft was updated. 7. Using this method for controlling the conference by sending re-Invite will cause a lot of traffic through the proxies in the middle and that is why XCON is the way to do it. [Linyi Tian] Yes. What is stated in the draft is there is no semantics defined for re-INVITE. Actually it is recommended not using re-INVITE for controlling the conference in this draft. I can make it clearer. To summarize - I can see some value in being able to send some information to the conference factory for the ad-hoc case. The information will include the required media and user count but this draft has a wider scope. [Linyi Tian] I think in addition to subject and user count, we may find other information which could be useful as well. For example, for search purpose, which provides complementary information such as URI for presentations:) Roni Even > -----Original Message----- > From: Linyi Tian [mailto:tianlinyi@huawei.com] > Sent: Saturday, April 14, 2007 4:01 AM > To: sipping@ietf.org > Cc: xcon@ietf.org > Subject: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf- > info-00.txt > > Dear all > > We just submitted an I-D to IETF regarding conference. Please kindly > review and feel free to give us any comments. Thank you in advance. > > Abstract & Requirements Anaylyze > This specification defines a mechanism that allows a UAC to provide a > conference server with the initial conference information and policy > using an INVITE-contained conference info. > > some environments have tough requirements regarding conference > establishment time. This is true especially when a user wants to > create a conference in ad hoc manner. In addition user may only want > very simple conference information and policy, for example the > subject and maximum numbers of participants, to be provided for an ad > hoc conference via only one operation. In this case they rarely > desire to manipulate the conference policy during the conference. > > In current art there is no mechanism for new participants to be aware > of the conference information they are being invited to. It causes > difficulty for them to decide whether to accept this invitation which > may not fall into their interest. > > Best Regards, > Linyi > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Saturday, April 14, 2007 3:50 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-linyi-sipping-invite-with-conf-info-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Session Initiation Protocol (SIP) INVITE with > Conference Info > Author(s) : L. Tian, Q. Sun > Filename : draft-linyi-sipping-invite-with-conf-info-00.txt > Pages : 24 > Date : 2007-4-13 > > > This specification defines a mechanism that allows a UAC to provide a > conference server with the initial conference information and policy > using an INVITE-contained conference info. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-linyi-sipping-invite-with-conf- > info-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-linyi-sipping-invite-with-conf-info-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-linyi-sipping-invite-with-conf-info- > 00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Apr 20 04:46:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heokq-0002bi-VF; Fri, 20 Apr 2007 04:46:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heokq-0002bd-N4 for xcon@ietf.org; Fri, 20 Apr 2007 04:46:08 -0400 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heokp-0007hZ-9m for xcon@ietf.org; Fri, 20 Apr 2007 04:46:08 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGS00B1FGDLM2@lhrga01-in.huawei.com> for xcon@ietf.org; Fri, 20 Apr 2007 09:46:33 +0100 (BST) Received: from jys3105093470ty ([62.159.183.141]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGS00HGAGDGX2@lhrga01-in.huawei.com> for xcon@ietf.org; Fri, 20 Apr 2007 09:46:33 +0100 (BST) Date: Fri, 20 Apr 2007 10:46:49 +0300 From: Linyi Tian Subject: RE: [XCON] New version of the Conference Information Data Model forCentralized Conferencing In-reply-to: To: "'Oscar Novo (JO/LMF)'" , xcon@ietf.org Message-id: <002c01c78320$0dc2a280$8b010a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AceB8syO9Vrug2KjQdO0g/4jJeVlpAAZH55AADIX1iA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Dear Oscar and et al, OMA has developed a Shared Group XDMS specification which defines a common group definition including membership and policy that can be used by all OMA enablers (e.g. PoC and IM). I find some useful elements defined in that specification (e.g. age-restrictions, and partial session-active-policy) are not covered by XCON data model, could we add them into the data model to address different marketing needs? If you are fine with this idea, I may provide you some detail information Best Regards, Linyi -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com] Sent: Thursday, April 19, 2007 11:03 AM To: xcon@ietf.org Subject: [XCON] New version of the Conference Information Data Model forCentralized Conferencing Hello everybody, A new version of the data model I-D is available in: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-05 .txt These are the changes of version 05 in relation to version 4: - We have removed the policy from the draft. - We have partially included the information of the "A Universal Resource Identifier (URI) for Centralized Conferencing" draft in the data model and we have created the IANA registration. - We have partially included the information of the "A User Identifier for Centralized Conferencing (XCON)" draft in the data model and we have created the IANA registration. - We have changed the status of the draft from Informational to Standard. - Few modifications in the RELAX NG Schema - Few modifications in the XML example Comments are welcome! Regards, Oscar Novo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Apr 20 04:56:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heotl-0004XK-8h; Fri, 20 Apr 2007 04:55:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heotj-0004TC-Vt for xcon@ietf.org; Fri, 20 Apr 2007 04:55:20 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heor0-00021B-Is for xcon@ietf.org; Fri, 20 Apr 2007 04:52:33 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9E33F204E8; Fri, 20 Apr 2007 10:52:29 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-39-46287f4d67d3 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9020420074; Fri, 20 Apr 2007 10:52:29 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 10:52:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] New version of the Conference Information Data Model forCentralized Conferencing Date: Fri, 20 Apr 2007 10:51:54 +0200 Message-ID: In-Reply-To: <002c01c78320$0dc2a280$8b010a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] New version of the Conference Information Data Model forCentralized Conferencing Thread-Index: AceB8syO9Vrug2KjQdO0g/4jJeVlpAAZH55AADIX1iAAAj/zcA== References: <002c01c78320$0dc2a280$8b010a0a@china.huawei.com> From: "Oscar Novo \(JO/LMF\)" To: "Linyi Tian" , X-OriginalArrivalTime: 20 Apr 2007 08:52:29.0452 (UTC) FILETIME=[3A123CC0:01C78329] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Linyi, Actually in the last IETF meeting we agree on defining the policy of the data model in a separate document. However, it would be nice if you can provide more detail information about these OMA specification to the WG. Cheers, Oscar =20 =20 -----Original Message----- From: Linyi Tian [mailto:tianlinyi@huawei.com]=20 Sent: 20. huhtikuuta 2007 10:47 To: Oscar Novo (JO/LMF); xcon@ietf.org Subject: RE: [XCON] New version of the Conference Information Data Model forCentralized Conferencing Dear Oscar and et al, OMA has developed a Shared Group XDMS specification which defines a common group definition including membership and policy that can be used by all OMA enablers (e.g. PoC and IM). I find some useful elements defined in that specification (e.g. age-restrictions, and partial session-active-policy) are not covered by XCON data model, could we add them into the data model to address different marketing needs? If you are fine with this idea, I may provide you some detail information Best Regards, Linyi -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com] Sent: Thursday, April 19, 2007 11:03 AM To: xcon@ietf.org Subject: [XCON] New version of the Conference Information Data Model forCentralized Conferencing Hello everybody, A new version of the data model I-D is available in:=20 http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-05 .txt These are the changes of version 05 in relation to version 4: - We have removed the policy from the draft. - We have partially included the information of the "A Universal Resource Identifier (URI) for Centralized Conferencing" draft in the data model and we have created the IANA registration. =20 - We have partially included the information of the "A User Identifier for Centralized Conferencing (XCON)" draft in the data model and we have created the IANA registration. =20 - We have changed the status of the draft from Informational to Standard. - Few modifications in the RELAX NG Schema - Few modifications in the XML example Comments are welcome! Regards, Oscar Novo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Apr 24 08:38:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKIA-0005qD-K9; Tue, 24 Apr 2007 08:38:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKI9-0005gS-Lt for xcon@ietf.org; Tue, 24 Apr 2007 08:38:45 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgKI6-0004o2-K5 for xcon@ietf.org; Tue, 24 Apr 2007 08:38:45 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 053332131F; Tue, 24 Apr 2007 14:38:42 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-54-462dfa51cb34 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EFA17205AC; Tue, 24 Apr 2007 14:38:41 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 14:38:41 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 14:38:41 +0200 Received: from [131.160.36.33] (E000FB0F665DD.lmf.ericsson.se [131.160.36.33]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2F9422711; Tue, 24 Apr 2007 15:38:41 +0300 (EEST) Message-ID: <462DFA50.4080000@ericsson.com> Date: Tue, 24 Apr 2007 15:38:40 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: XCON Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2007 12:38:41.0426 (UTC) FILETIME=[7D401F20:01C7866D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [XCON] Comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi, a few comments on the XCON framework. The title of the framework, the abstract, and several sections, state that this document defines a data model for centralized conferencing. This is confusing because the framework does not actually define the data model; the data model draft does. Therefore, I would suggest that the framework clearly states that the definition of the data model is in the data model draft. The document has a section (Section 2) that references RFC 2119 but then does not use normative language. If the idea is to have an informational framework, that section can be removed. The 1st paragraph of Section 5 states that the common conference information type is extensible for including multiple sub-type. What exactly does that mean? Extensions to the data model will continue using the same media type. The 2nd paragraph of Section 5.2 says that policies are not explicitly defined within the data model, but rather are reflected in the system realization. Given that policies will be studied after the data model is completed, I would avoid talking to much about policies until we have a clear view on how they will be implemented. Section 7.1 describes the cloning tree. Part of that concept is the cloning of policies. Again, since policies are for further study, I would avoid talking too much about them at this point. In fact, this cloning tree concept will probably need to be further described in the policies draft to be written in the future. Nits: Page 5, 3rd paragraph. OLD: A Binary Floor Control Protocol (BFCP)... NEW: A floor control protocol (e.g., BFCP)... Figure 1: spacing problem on the right-most vertical line (which is made of dots). Figure 2: the same type of spacing problem. Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Apr 25 09:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghhl-0002rK-PH; Wed, 25 Apr 2007 09:38:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghhk-0002rE-Ir for xcon@ietf.org; Wed, 25 Apr 2007 09:38:44 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hghhj-0001k7-IN for xcon@ietf.org; Wed, 25 Apr 2007 09:38:44 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CCDD720AAE; Wed, 25 Apr 2007 15:38:42 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-f6-462f59e202a0 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A9369203CB; Wed, 25 Apr 2007 15:38:42 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 15:38:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Apr 2007 15:38:04 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceHPwmeREeU/PqhQJ2OLBJG23H9yw== From: "Oscar Novo \(JO/LMF\)" To: X-OriginalArrivalTime: 25 Apr 2007 13:38:42.0534 (UTC) FILETIME=[0A175860:01C7873F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.5 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: cboulton@ubiquitysoftware.com Subject: [XCON] More comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0554349971==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0554349971== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7873E.F3290F68" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7873E.F3290F68 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And here a bit more comments on the framework: -The framework defines the data model as a "common conference information". When we had the templates this concept was right but now I think this concept is not correct. I propose to change the name to "Conference Information Data Model" as is defined in the data model draft. - I think section 5.1 is a bit messy. It still have concepts about the templates. I have re-written a bit that section to adapted it to the data model idea:=20 "There is a core set of data in the conference system that is utilized in any conference, independent of the specific conference media nature (e.g., the mixing algorithms performed, the advanced floor control applied, etc.). This core set of data contains the definitions representing the conference object capabilities, membership, roles, call signaling and media status relevant to different stages of the conference life-cycle. This core set of data is represented using the conference information data model type defined in [17]. =20 New centralized conferencing specifications can extend the conference information data model type as defined in [17] and introduce additional data elements to be used within the conference information data model type." - In the 'conferencing scenario realizations' section when a user "Alice" creates a sidebar conference. Is "Alice" included in the sidebar conference as a user? Reading the text looks like "Alice" is included in the sidebar but checking the figures looks like she is not part of the sidebar conference.=20 - I'm a bit confuse with the use case explain in section 9.6 'Whispering or Private Messages'. As I understood whispering is a participant who send a one-way message to a single participant. RFC 4597 defines whispers or private messages as follow: "A participant can send a one-way message (text, audio, or even some other media) to another participant that is immediately rendered. This differs from a sidebar in that it is immediate and creates no long-lived session." The framework is defining whispering in a different way: "one participant sends a message to multiple participants using sidebars". For me, that definition is not connect to 'whispering or private messages' but instead to 'sidebars'.=20 As well, the use case defined in 9.6 is very confused. Why do we need to create a sidebar and a conference ID to send a single private message to a user? It doesn't make any sense for me. If the participant knows the userID, he could send the whispering message straight to his friend without create any sidebar, conferenceID or notification message. - Section 9.9 'Observing and Coaching'. Is it necesary to create a sidebar for observing a conference? Couldn't be the observer in the conference a 'hidden' participant? As far as you notify the other participant that the conference is recorded or observed by a third party I guess it's OK, right? - I think the intended status of the framework should be Standard track, no informational as it is now.=20 - The user identifier and the XCON identifier are defined now in the data model. The references to those draft should be removed from the Framework or should reference to the data model instead.=20 Nits: In some places you are using "signaling" in other "signalling". Figure 2: Change "Common conference information type" for "Conference Information Data Model type" Figure 10: It's missing the clients usernames "Carol" and "Bob". Figure 13: When Alice creates the sidebar only includes one "confUserID". She should include at least "Bob", "Ethel" and "Carol" user ID. Figure 16: No sidebars are created in this uses case. So, "Active Sidebar Conference" should be change in the picture to "Active Conference". Change in the text: Cbject -> Object Identifer-> Identifier "And the the conference object is updated" -> "And the conference object is updated" "Object identifier as as shown in Figure 11" -> "Object identifier as shown in Figure 11" "can be handled by by supervisor adding" -> "can be handled by supervisor adding" Cheers, Oscar Novo ------_=_NextPart_001_01C7873E.F3290F68 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable More comments on draft-ietf-xcon-framework-07.txt

And here a bit more comments on the = framework:

-The framework defines the data model = as a "common conference information". When we had the = templates this concept was right but now I think this concept is not = correct. I propose to change the name to "Conference Information = Data Model" as is defined in the data model draft.

- I think section 5.1 is a bit messy. = It still have concepts about the templates. I have re-written a bit that = section to adapted it to the data model idea:

 "There is a core set of data = in the conference system that is utilized in any conference, independent = of the specific conference media nature (e.g., the mixing algorithms = performed, the advanced floor control applied, etc.). This core set of = data contains the definitions representing the conference object = capabilities, membership, roles, call signaling and media status = relevant to different stages of the conference life-cycle.  This = core set of data is represented using the conference information data = model type defined in [17]. 


New centralized conferencing = specifications can extend the conference information data model type as = defined in [17] and introduce additional data elements to be used within = the conference information data model type."

- In the 'conferencing scenario = realizations' section when a user "Alice" creates a sidebar = conference. Is "Alice" included in the sidebar conference as a = user? Reading the text looks like "Alice" is included in the = sidebar but checking the figures looks like she is not part of the = sidebar conference.

- I'm a bit confuse with the use case = explain in section 9.6 'Whispering or Private Messages'. As I understood = whispering is a participant who send a one-way message to a single = participant. RFC 4597 defines whispers or private messages as = follow:

"A participant can send a one-way = message (text, audio, or even some other media) to another participant = that is immediately rendered.  This differs from a sidebar in that = it is immediate and creates no long-lived session."

The framework is defining whispering in = a different way: "one participant sends a message to multiple = participants using sidebars". For me, that definition is not = connect to 'whispering or private messages' but instead to 'sidebars'. =

As well, the use case defined in 9.6 is = very confused. Why do we need to create a sidebar and a conference ID to = send a single private message to a user? It doesn't make any sense for = me. If the participant knows the userID, he could send the whispering = message straight to his friend without create any sidebar, conferenceID = or notification message.

- Section 9.9 'Observing and Coaching'. = Is it necesary to create a sidebar for observing a conference? Couldn't = be the observer in the conference a 'hidden' participant? As far as you = notify the other participant that the conference is recorded or observed = by a third party I guess it's OK, right?

- I think the intended status of the = framework should be Standard track, no informational as it is now. =
- The user identifier and the XCON = identifier are defined now in the data model. The references to those = draft should be removed from the Framework or should reference to the = data model instead.

Nits:

In some places you are using = "signaling" in other "signalling".

Figure 2: Change "Common = conference information type" for "Conference Information Data = Model type"
Figure 10: It's missing the clients = usernames "Carol" and "Bob".
Figure 13: When Alice creates the = sidebar only includes one "confUserID". She should include at = least "Bob", "Ethel" and "Carol" user = ID.

Figure 16: No sidebars are created in = this uses case. So, "Active Sidebar Conference" should be = change in the picture to "Active Conference".


Change in the text:

Cbject -> Object
Identifer-> Identifier
"And the the conference object is = updated" -> "And the conference object is = updated"
"Object identifier as as shown in = Figure 11" -> "Object identifier as shown in Figure = 11"
"can be handled by by supervisor = adding" -> "can be handled by supervisor = adding"

Cheers,

Oscar Novo

------_=_NextPart_001_01C7873E.F3290F68-- --===============0554349971== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0554349971==-- From xcon-bounces@ietf.org Wed Apr 25 16:10:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgnpJ-0007pC-CY; Wed, 25 Apr 2007 16:10:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgnZm-0002eX-MV for xcon@ietf.org; Wed, 25 Apr 2007 15:54:55 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgnZg-0003NV-UU for xcon@ietf.org; Wed, 25 Apr 2007 15:54:54 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l3PJre417794; Wed, 25 Apr 2007 19:53:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Apr 2007 14:54:14 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceHPwmeREeU/PqhQJ2OLBJG23H9ywALOemw From: "Mary Barnes" To: "Oscar Novo \(JO/LMF\)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d188b91ff79eaa1be2a0e9635461d9a Cc: cboulton@ubiquitysoftware.com Subject: [XCON] RE: More comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2140082528==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============2140082528== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78773.803EF398" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78773.803EF398 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Oscar, =20 Thanks for your comments. My responses are below [MB]. =20 =20 Mary=20 -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Wednesday, April 25, 2007 8:38 AM To: xcon@ietf.org Cc: Barnes, Mary (RICH2:AR00); cboulton@ubiquitysoftware.com Subject: More comments on draft-ietf-xcon-framework-07.txt =09 =09 And here a bit more comments on the framework:=20 -The framework defines the data model as a "common conference information". When we had the templates this concept was right but now I think this concept is not correct. I propose to change the name to "Conference Information Data Model" as is defined in the data model draft.=20 [MB] Given we're post-WGLC, I'd prefer to have additional feedback before making this change as I think the Common Conference Information is a general enough concept and I think that change impacts a whole lot of text and I'd be concerned that I'd break more than I might fix with that change. [/MB] - I think section 5.1 is a bit messy. It still have concepts about the templates. I have re-written a bit that section to adapted it to the data model idea: =20 [MB] I don't think 5.1 has template concepts at all - I removed all of those in the -04 to -05 bunch of changes in Sept. 2006. What that section does have is the idea of basic conferencing with the event package defined in RFC 4575 per the reference and then it goes on to describe why we've done the data model draft in XCON to support the enhanced conferencing. This gets back to the point we've discussed in the past of ensuring that a system based on the XCON FW can also support clients that only support RFC 4575 and not the XCON data model. [/MB] "There is a core set of data in the conference system that is utilized in any conference, independent of the specific conference media nature (e.g., the mixing algorithms performed, the advanced floor control applied, etc.). This core set of data contains the definitions representing the conference object capabilities, membership, roles, call signaling and media status relevant to different stages of the conference life-cycle. This core set of data is represented using the conference information data model type defined in [17]. =20 New centralized conferencing specifications can extend the conference information data model type as defined in [17] and introduce additional data elements to be used within the conference information data model type." - In the 'conferencing scenario realizations' section when a user "Alice" creates a sidebar conference. Is "Alice" included in the sidebar conference as a user? Reading the text looks like "Alice" is included in the sidebar but checking the figures looks like she is not part of the sidebar conference. =20 [MB] I'm not sure which figure you're referring to. In Figures 12 and 13, I guess we could debate whether "Alice" should show up in the Reservation, but "Alice" is shown in the "Active Sidebar Conference" in both Figures. Is that the figures you're referring to? [/MB]=20 - I'm a bit confuse with the use case explain in section 9.6 'Whispering or Private Messages'. As I understood whispering is a participant who send a one-way message to a single participant. RFC 4597 defines whispers or private messages as follow: "A participant can send a one-way message (text, audio, or even some other media) to another participant that is immediately rendered. This differs from a sidebar in that it is immediate and creates no long-lived session." The framework is defining whispering in a different way: "one participant sends a message to multiple participants using sidebars". For me, that definition is not connect to 'whispering or private messages' but instead to 'sidebars'. =20 [MB] No, I don't think the framework really defines the whispering in a different way - it does further refine that definition in the context of the fraamework. We define "whisper" in section 4 as: "A whisper involves a one-time media input to a specific participant(s) within a specific conference instance, accomplished using a sidebar. An example of a whisper would be an announcement injected only to the conference chair or to a new participant joining a conference." =09 So, I think that's consistent with the definition in 4597 in that, per the example, the sidebar is immediately removed after delivering that onetime media. =20 As background, the definition was added in the -05, with other text added to the document on whisper added in the -03 based on WG discussions. I'd have to dig to find those threads, but am reluctant to re-open past discussions without additional input from others in the WG. [/MB] As well, the use case defined in 9.6 is very confused. Why do we need to create a sidebar and a conference ID to send a single private message to a user? It doesn't make any sense for me. If the participant knows the userID, he could send the whispering message straight to his friend without create any sidebar, conferenceID or notification message. [MB] This use case was added in the -05 version based on input from a WG member and is consistent with the WG consensus on the definition of whisper (which is based on a sidebar) and as I'm recalling we did have this long, long debate. [/MB] - Section 9.9 'Observing and Coaching'. Is it necesary to create a sidebar for observing a conference? Couldn't be the observer in the conference a 'hidden' participant? As far as you notify the other participant that the conference is recorded or observed by a third party I guess it's OK, right?=20 [MB] And, that's exactly what the text says - you can accomplish the observing functionality by just having the supervisor as a hidden participant, which is what the first two paragraphs of that section discuss. It then describes that to take that functionality one step further to handle the coaching: " Taking the supervisor capability one step further introduces a scenario whereby the agent can hear the supervisor, as well as the customer. The customer can still only hear the agent. This scenario would involve the creation of a sidebar involving the agent and the supervisor. " [/MB]=20 - I think the intended status of the framework should be Standard track, no informational as it is now. =20 [MB] Agreed, per previous email discussions - I'll make that change with other nits and add that categorization to the header. [/MB] =09 - The user identifier and the XCON identifier are defined now in the data model. The references to those draft should be removed from the Framework or should reference to the data model instead.=20 [MB] Agreed per discussions at IETF-68. Nits: =20 [MB] Thanks - I'll take care of these on the next update. =20 In some places you are using "signaling" in other "signalling".=20 Figure 2: Change "Common conference information type" for "Conference Information Data Model type"=20 Figure 10: It's missing the clients usernames "Carol" and "Bob". Figure 13: When Alice creates the sidebar only includes one "confUserID". She should include at least "Bob", "Ethel" and "Carol" user ID. Figure 16: No sidebars are created in this uses case. So, "Active Sidebar Conference" should be change in the picture to "Active Conference". Change in the text:=20 Cbject -> Object=20 Identifer-> Identifier=20 "And the the conference object is updated" -> "And the conference object is updated"=20 "Object identifier as as shown in Figure 11" -> "Object identifier as shown in Figure 11"=20 "can be handled by by supervisor adding" -> "can be handled by supervisor adding"=20 Cheers,=20 Oscar Novo=20 ------_=_NextPart_001_01C78773.803EF398 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Oscar,
 
Thanks=20 for your comments. My responses are below [MB].  =
 
Mary=20
-----Original Message-----
From: = Oscar Novo=20 (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: Wednesday, = April=20 25, 2007 8:38 AM
To: xcon@ietf.org
Cc: Barnes, = Mary=20 (RICH2:AR00); cboulton@ubiquitysoftware.com
Subject: More = comments=20 on draft-ietf-xcon-framework-07.txt

And here a bit more comments on the=20 framework:

-The framework defines the data = model as a=20 "common conference information". When we had the templates this = concept was=20 right but now I think this concept is not correct. I propose to change = the=20 name to "Conference Information Data Model" as is defined in the data = model=20 draft. 

[MB] Given we're post-WGLC, I'd prefer to have = additional=20 feedback before making this change as I think the Common Conference=20 Information is a general enough concept and I think that change = impacts a=20 whole lot of text and I'd be concerned that I'd break more than I = might fix=20 with that change. [/MB]

- I think section 5.1 is a bit = messy. It=20 still have concepts about the templates. I have re-written a bit that = section=20 to adapted it to the data model idea:  

[MB]  I don't think=20 5.1 has template concepts at all - I removed all of = those in=20 the -04 to -05 bunch of changes in Sept. 2006.   What that = section does=20 have is the idea of basic conferencing with the event package defined = in RFC=20 4575 per the reference and then it goes on to describe why we've done = the data=20 model draft in XCON to support the enhanced conferencing. This gets = back to=20 the point we've discussed in the past of ensuring that a system based = on the=20 XCON FW can also support clients that only support RFC 4575 and not = the XCON=20 data model. [/MB]

  "There is a core set of = data in=20 the conference system that is utilized in any conference, independent = of the=20 specific conference media nature (e.g., the mixing algorithms = performed, the=20 advanced floor control applied, etc.). This core set of data contains = the=20 definitions representing the conference object capabilities, = membership,=20 roles, call signaling and media status relevant to different stages of = the=20 conference life-cycle.  This core set of data is represented = using the=20 conference information data model type defined in [17]. =20


New centralized conferencing = specifications can=20 extend the conference information data model type as defined in [17] = and=20 introduce additional data elements to be used within the conference=20 information data model type."

- In the 'conferencing scenario = realizations'=20 section when a user "Alice" creates a sidebar conference. Is "Alice" = included=20 in the sidebar conference as a user? Reading the text looks like = "Alice" is=20 included in the sidebar but checking the figures looks like she is not = part of=20 the sidebar conference.  

[MB]  I'm not sure = which figure=20 you're referring to.  In Figures 12 and 13, I guess we could = debate=20 whether "Alice" should show up in the Reservation, but "Alice" is = shown=20 in the "Active Sidebar Conference" in both Figures. Is that the = figures you're=20 referring to? [/MB] 

- I'm a=20 bit confuse with the use case explain in section 9.6 'Whispering or = Private=20 Messages'. As I understood whispering is a participant who send a = one-way=20 message to a single participant. RFC 4597 defines whispers or private = messages=20 as follow:

"A participant can send a one-way = message (text,=20 audio, or even some other media) to another participant that is = immediately=20 rendered.  This differs from a sidebar in that it is immediate = and=20 creates no long-lived session."

The framework is defining = whispering in a=20 different way: "one participant sends a message to multiple = participants using=20 sidebars". For me, that definition is not connect to 'whispering or = private=20 messages' but instead to 'sidebars'.  

[MB] No, I don't think the framework really defines = the=20 whispering in a different way - it does further refine that definition = in=20 the context of the fraamework. We define "whisper" in section 4=20 as:

      "A whisper involves a = one-time=20 media input to a specific
      = participant(s)=20 within a specific conference instance,=20 accomplished
      using a sidebar.  = An=20 example of a whisper would be an=20 announcement
      injected only to the = conference=20 chair or to a new participant
      = joining a=20 conference."

So, I think that's consistent with the definition in = 4597 in=20 that, per the example, the sidebar is immediately removed after = delivering=20 that onetime media. 

As background, the definition was added in the -05, = with other=20 text added to the document on whisper added in the -03 based on WG=20 discussions. I'd have to dig to find those threads, but am reluctant = to=20 re-open past discussions without additional input from others in the = WG.=20  [/MB]

As well, the use case defined in = 9.6 is very=20 confused. Why do we need to create a sidebar and a conference ID to = send a=20 single private message to a user? It doesn't make any sense for me. If = the=20 participant knows the userID, he could send the whispering message = straight to=20 his friend without create any sidebar, conferenceID or notification=20 message. 

[MB] This use case was added in the -05 = version based=20 on input from a WG member and is consistent with the WG consensus on = the=20 definition of whisper (which is based on a sidebar) and as I'm = recalling we=20 did have this long, long debate. [/MB]

 -=20 Section 9.9 'Observing and Coaching'. Is it necesary to create a = sidebar for=20 observing a conference? Couldn't be the observer in the conference a = 'hidden'=20 participant? As far as you notify the other participant that the = conference is=20 recorded or observed by a third party I guess it's OK, right? 

[MB] And, that's exactly what the text = says - you=20 can accomplish the observing functionality by just having the = supervisor=20 as a hidden participant, which is what the first two paragraphs = of that=20 section discuss. It then describes that to take that functionality one = step=20 further to handle the coaching:

  " Taking the supervisor capability one step further = introduces=20 a
   scenario whereby the agent can hear the supervisor, = as well=20 as the
   customer.  The customer can still only = hear the=20 agent.  This scenario
   would involve the creation = of a=20 sidebar involving the agent and the
  =20 supervisor. "

[/MB] 

- I think the intended status of = the=20 framework should be Standard track, no informational as it is = now.  

[MB]=20 Agreed, per previous email discussions - I'll make that change with = other nits=20 and add that categorization to the header. =  [/MB]


-=20 The user identifier and the XCON identifier are defined now in the = data model.=20 The references to those draft should be removed from the Framework or = should=20 reference to the data model instead. 

[MB] Agreed per discussions at = IETF-68.

Nits:  

[MB]=20 Thanks - I'll take care of these on the next update.=20  

In some places you are using = "signaling" in other=20 "signalling".

Figure 2: Change "Common conference = information=20 type" for "Conference Information Data Model type"
Figure 10: It's missing the clients usernames "Carol" and = "Bob".=20
Figure 13: When Alice creates the = sidebar only=20 includes one "confUserID". She should include at least "Bob", "Ethel" = and=20 "Carol" user ID.

Figure 16: No sidebars are created in = this uses=20 case. So, "Active Sidebar Conference" should be change in the picture = to=20 "Active Conference".


Change in the text:

Cbject -> Object
Identifer-> Identifier
"And the=20 the conference object is updated" -> "And the conference object is=20 updated"
"Object identifier as = as shown in=20 Figure 11" -> "Object identifier as shown in Figure 11" =
"can be handled by by supervisor adding" -> = "can be=20 handled by supervisor adding"

Cheers,

Oscar Novo =

------_=_NextPart_001_01C78773.803EF398-- --===============2140082528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============2140082528==-- From xcon-bounces@ietf.org Wed Apr 25 16:18:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgnwq-0001yF-CQ; Wed, 25 Apr 2007 16:18:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgnwp-0001yA-UB for xcon@ietf.org; Wed, 25 Apr 2007 16:18:43 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgnwo-00081v-NW for xcon@ietf.org; Wed, 25 Apr 2007 16:18:43 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3PKIb428983 for ; Wed, 25 Apr 2007 20:18:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Apr 2007 15:18:22 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Removing Policies from the framework document (and data model) Thread-Index: AceHdt7m69Dg17aDTjqzxcht5Vo1QQ== From: "Mary Barnes" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Subject: [XCON] Removing Policies from the framework document (and data model) X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1709984486==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1709984486== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78776.DF001F08" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78776.DF001F08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There had been a thread on "Policies in the data model" prior to IETF-68 and we discussed that point at the meeting: http://www3.ietf.org/proceedings/07mar/minutes/xcon.htm But, there was no clear conclusion, although it did seem most folks were in favor of completing the data model without the policy information. However, some of us thought we needed some basic information such as read/write access (and roles).=20 Per the recent discussion and suggestion on updates to the framework, it has been suggested to remove the references to policy. I can easily see how the text in section 5 can be generalized - I'm proposing to get rid of section 5.2 altogether and merge 5.1 text with 5 and just have a general statement on policy.=20 However, there is the fundamental concept in the "cloning tree" model whereby the child is created as either being independent of the parent and thus subject to the parent's policies or independent. I think that's an important concept that we've had in the framework for quite some time. The context in which policies are discussed is around read/write access restrictions. In my mind, I think this requires the basic concept of the read/write access to be a requirement on implementation of the data model, although not necessarily something that is an explicit part of the data model. This view is consistent with the existing text in the framework document. =20 In short, I'm proposing we remove the explicit text suggesting that policies are part of the data model, but keep the text that discusses the read/write access such as the following from section 5.2:=20 "Conference policies collectively refers to a set of rights, permissions and limitations pertaining to operations being performed on a certain conference object. The set of rights describes the read/write access privileges for the conference object as a whole. This access would usually be granted and defined in terms of giving the read-only or read-write access to clients with certain roles in the conference. As such, the policies represented by the set of rights are reflected in the system realization (Section 7) and not part of a more general policy framework or model."=20 And, then reword the last two paragraphs as follows: "A policy framework and model for centralized conferencing, including a mechanism for=20 defining the permissions and limitations, is an item for future study." Regards, Mary ------_=_NextPart_001_01C78776.DF001F08 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Removing Policies from the framework document (and data = model)

There had been a thread on = "Policies in the data model" prior to IETF-68 and we discussed = that point at the meeting: http://www3.ietf.org/proceedings/07mar/minutes/xcon.htm

But, there was no clear conclusion, = although it did seem most folks were in favor of completing the data = model without the policy information.  However,  some of us = thought we needed some basic information such as read/write access (and = roles).

Per the recent discussion and = suggestion on updates to the framework, it has been suggested to remove = the references to policy.  I can easily see how the text in section = 5 can be generalized - I'm proposing to get rid of section 5.2 = altogether and merge 5.1 text with 5 and just have a general statement = on policy.

However, there is the fundamental = concept in the "cloning tree" model whereby the child is = created as either being independent of the parent and thus subject to = the parent's policies or independent. I think that's an important = concept that we've had in the framework for quite some time.  The = context in which policies are discussed is around read/write access = restrictions. In my mind, I think this requires the basic concept of the = read/write access to be a requirement on implementation of the data = model, although not necessarily something that is an explicit part of = the data model.  This view is consistent with the existing text in = the framework document. 

In short, I'm proposing we remove the = explicit text suggesting that policies are part of the data model, but = keep the text that discusses the read/write access such as the following = from section 5.2:

  "Conference policies = collectively refers to a set of rights,
   permissions and = limitations pertaining to operations being performed
   on a certain conference = object.

   The set of rights = describes the read/write access privileges for the
   conference object as a = whole.  This access would usually be granted
   and defined in terms of = giving the read-only or read-write access to
   clients with certain = roles in the conference.  As such, the policies
   represented by the set of = rights are reflected in the system realization
   (Section 7) and not part = of a more general policy framework or model."

And, then reword the last two = paragraphs as follows:

   "A policy framework = and model for centralized conferencing, including a mechanism for =
    defining the = permissions and  limitations,  is an item for future = study."

Regards,
Mary

------_=_NextPart_001_01C78776.DF001F08-- --===============1709984486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============1709984486==-- From xcon-bounces@ietf.org Wed Apr 25 16:20:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgnyr-000659-Dn; Wed, 25 Apr 2007 16:20:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgnZM-0002Qt-K5 for xcon@ietf.org; Wed, 25 Apr 2007 15:54:29 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgnZF-0003EY-0s for xcon@ietf.org; Wed, 25 Apr 2007 15:54:28 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l3PJrb417786; Wed, 25 Apr 2007 19:53:38 GMT 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: Wed, 25 Apr 2007 14:54:02 -0500 Message-ID: In-Reply-To: <462DFA50.4080000@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceGbX/I3u+pY8rARlmnn/lG3DIDfQAO3UwQ From: "Mary Barnes" To: "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: xcon@ietf.org Subject: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Gonzalo, Thanks for your comments - responses are embedded below [MB]. Mary -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Tuesday, April 24, 2007 7:39 AM To: XCON Cc: Barnes, Mary (RICH2:AR00) Subject: Comments on draft-ietf-xcon-framework-07.txt Hi, a few comments on the XCON framework. The title of the framework, the abstract, and several sections, state=20 that this document defines a data model for centralized conferencing.=20 This is confusing because the framework does not actually define the=20 data model; the data model draft does. Therefore, I would suggest that=20 the framework clearly states that the definition of the data model is in the data model draft. The document has a section (Section 2) that references RFC 2119 but then does not use normative language. If the idea is to have an informational framework, that section can be removed. The 1st paragraph of Section 5 states that the common conference=20 information type is extensible for including multiple sub-type. What=20 exactly does that mean? Extensions to the data model will continue using the same media type. [MB] Good catch. That is a leftover from the removal of the template concepts. I think it should just read: "The common conference information type is extensible." [/MB] The 2nd paragraph of Section 5.2 says that policies are not explicitly=20 defined within the data model, but rather are reflected in the system=20 realization. Given that policies will be studied after the data model is completed, I would avoid talking to much about policies until we have a=20 clear view on how they will be implemented. [MB] I agree that much of that section no longer fits based on the discussion from IETF-68 (and this also impacts the last paragraph of section 5). Did we ever take that point to the mailing list as a conclusion or does anyone have any concerns about removing this whole section and munging section 5.1 into section 5 and having only a general statement about policy? I'll take this item as an issue to the mailing list, as I don't think many people are going to read it here :) [/MB] Section 7.1 describes the cloning tree. Part of that concept is the=20 cloning of policies. Again, since policies are for further study, I=20 would avoid talking too much about them at this point. In fact, this=20 cloning tree concept will probably need to be further described in the=20 policies draft to be written in the future. [MB] I still think we need this parent enforceable concept here, no matter how we implement the policies. I think this is one of the reasons why I was one of the ones that did not want to remove all the policy data from the data model (i.e., I think some of the basic read/write and allowed sort of stuff may be necessary). Again, I'll take this point as part of the discussion of the issue to the list. [/MB] Nits: [MB] I'll fix these in the -08. [/MB] Page 5, 3rd paragraph. OLD: A Binary Floor Control Protocol (BFCP)... NEW: A floor control protocol (e.g., BFCP)... Figure 1: spacing problem on the right-most vertical line (which is made of dots). Figure 2: the same type of spacing problem. Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Apr 26 03:10:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgy7I-0002dk-Vl; Thu, 26 Apr 2007 03:10:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgy7H-0002df-Ps for xcon@ietf.org; Thu, 26 Apr 2007 03:10:11 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgy7G-0007PI-MQ for xcon@ietf.org; Thu, 26 Apr 2007 03:10:11 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0A8C420B35; Thu, 26 Apr 2007 09:10:10 +0200 (CEST) X-AuditID: c1b4fb3c-ac51ebb0000073d5-60-463050514d8e Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DFE592063E; Thu, 26 Apr 2007 09:10:09 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 09:10:09 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 09:10:09 +0200 Received: from [131.160.36.5] (E000FB0F665DD.lmf.ericsson.se [131.160.36.5]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3FEBC2333; Thu, 26 Apr 2007 10:10:09 +0300 (EEST) Message-ID: <46305051.6020606@ericsson.com> Date: Thu, 26 Apr 2007 10:10:09 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 07:10:09.0569 (UTC) FILETIME=[ECE4F110:01C787D1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: xcon@ietf.org Subject: [XCON] Re: Comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Mary, OK. Let's discuss the policy stuff separately at some point. By the way, you did not given any answer to the first two comments of the email (the draft says that it defines a data model and it references RFC 2119). Cheers, Gonzalo Mary Barnes wrote: > Hi Gonzalo, > > Thanks for your comments - responses are embedded below [MB]. > > Mary > > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Tuesday, April 24, 2007 7:39 AM > To: XCON > Cc: Barnes, Mary (RICH2:AR00) > Subject: Comments on draft-ietf-xcon-framework-07.txt > > > Hi, > > a few comments on the XCON framework. > > The title of the framework, the abstract, and several sections, state > that this document defines a data model for centralized conferencing. > This is confusing because the framework does not actually define the > data model; the data model draft does. Therefore, I would suggest that > the framework clearly states that the definition of the data model is in > > the data model draft. > > The document has a section (Section 2) that references RFC 2119 but then > > does not use normative language. If the idea is to have an informational > > framework, that section can be removed. > > The 1st paragraph of Section 5 states that the common conference > information type is extensible for including multiple sub-type. What > exactly does that mean? Extensions to the data model will continue using > > the same media type. > > [MB] Good catch. That is a leftover from the removal of the template > concepts. I think it should just read: "The common conference > information type is extensible." [/MB] > > The 2nd paragraph of Section 5.2 says that policies are not explicitly > defined within the data model, but rather are reflected in the system > realization. Given that policies will be studied after the data model is > > completed, I would avoid talking to much about policies until we have a > clear view on how they will be implemented. > > [MB] I agree that much of that section no longer fits based on the > discussion from IETF-68 (and this also impacts the last paragraph of > section 5). > > Did we ever take that point to the mailing list as a conclusion or does > anyone have any concerns about removing this whole section and munging > section 5.1 into section 5 and having only a general statement about > policy? I'll take this item as an issue to the mailing list, as I don't > think many people are going to read it here :) [/MB] > > > Section 7.1 describes the cloning tree. Part of that concept is the > cloning of policies. Again, since policies are for further study, I > would avoid talking too much about them at this point. In fact, this > cloning tree concept will probably need to be further described in the > policies draft to be written in the future. > > [MB] I still think we need this parent enforceable concept here, no > matter how we implement the policies. I think this is one of the > reasons why I was one of the ones that did not want to remove all the > policy data from the data model (i.e., I think some of the basic > read/write and allowed sort of stuff may be necessary). Again, I'll > take this point as part of the discussion of the issue to the list. > [/MB] > > > Nits: > > [MB] I'll fix these in the -08. [/MB] > > Page 5, 3rd paragraph. > OLD: > A Binary Floor Control Protocol (BFCP)... > > NEW: > A floor control protocol (e.g., BFCP)... > > Figure 1: spacing problem on the right-most vertical line (which is made > > of dots). > > Figure 2: the same type of spacing problem. > > > Cheers, > > Gonzalo > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Apr 26 07:21:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh22v-0007EH-7j; Thu, 26 Apr 2007 07:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh22t-0007E9-Db; Thu, 26 Apr 2007 07:21:55 -0400 Received: from mail.unina.it ([192.132.34.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh22p-0006Lr-F9; Thu, 26 Apr 2007 07:21:55 -0400 Received: from [143.225.229.193] ([143.225.229.193]) by mail.unina.it (8.13.7/8.13.7) with ESMTP id l3QBOFet002667; Thu, 26 Apr 2007 13:24:16 +0200 Message-ID: <46308B11.4090407@unina.it> Date: Thu, 26 Apr 2007 13:20:49 +0200 From: Lorenzo Miniero User-Agent: Mozilla Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: SIMPLE Mailing List Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.unina.it id l3QBOFet002667 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: XCON Mailing List Subject: [XCON] Open source MSRP implementation X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Dear all, just a brief post to notify all the interested readers that we at=20 University of Naples recently released a prototype, open source,=20 implementation of the Message Session Relay Protocol (MSRP) written in C. The library has only been released a few days ago, and so at the moment=20 only provides some very basic functionality, such as: * endpoint-to-endpoint sessions; * "switching"-mode (to enable conference rooms), where each conference=20 room is seen as an endpoint by all participants. Only text can be sent, i.e. no MIME encoding of data, CPIM and the like. Chunking is envisaged but not working yet. Besides, no relaying=20 functionality is provided, though we're working on it. We're currently using this library to provide some chatroom=20 functionality in Confiance, our prototype implementation of the XCON=20 framework (which is why I'm forwarding this mail to the XCON mailing=20 list too), and though still very basic, the library does its work. If you're interested in having a look at the library you can get it on=20 its Sourceforge project page: http://sourceforge.net/projects/libmsrp/ which also contains a couple of sample applications to test the=20 currently provided functionality. In a few days we'll update the Confiance project as well=20 (http://confiance.sf.net/), which will envisage the integration of the=20 MSRP functionality in both client and server sides. MSRP sessions in the=20 framework are negotiated within SIP/SDP as described in the draft. We'd really appreciate some feedback upon the current status of the=20 work, and suggestions on future work to be done of course. Regards, Lorenzo --=20 Lorenzo Miniero, Junior Researcher Dipartimento di Informatica e Sistemistica Universit=C3=A0 degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) Phone: +390817683821 - Fax: +390817683816 Email: lorenzo.miniero@unina.it _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Apr 26 08:59:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3Yz-0006iG-Il; Thu, 26 Apr 2007 08:59:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3Yw-0006i9-VX for xcon@ietf.org; Thu, 26 Apr 2007 08:59:07 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh3Yw-0007et-Iw for xcon@ietf.org; Thu, 26 Apr 2007 08:59:06 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3QCx3i07299; Thu, 26 Apr 2007 12:59:04 GMT 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, 26 Apr 2007 07:59:03 -0500 Message-ID: In-Reply-To: <46305051.6020606@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceH0fJCia6VqSwyT36az0a/O2z6TAALwqcw From: "Mary Barnes" To: "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: xcon@ietf.org Subject: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Sorry, I did miss the first couple points. I've embedded the responses below [MB]. =20 Thanks, Mary -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Thursday, April 26, 2007 2:10 AM To: Barnes, Mary (RICH2:AR00) Cc: xcon@ietf.org Subject: Re: Comments on draft-ietf-xcon-framework-07.txt Hi Mary, OK. Let's discuss the policy stuff separately at some point. By the way, you did not given any answer to the first two comments of=20 the email (the draft says that it defines a data model and it references RFC 2119). Cheers, Gonzalo Mary Barnes wrote: > Hi Gonzalo, >=20 > Thanks for your comments - responses are embedded below [MB]. >=20 > Mary >=20 >=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Tuesday, April 24, 2007 7:39 AM > To: XCON > Cc: Barnes, Mary (RICH2:AR00) > Subject: Comments on draft-ietf-xcon-framework-07.txt >=20 >=20 > Hi, >=20 > a few comments on the XCON framework. >=20 > The title of the framework, the abstract, and several sections, state=20 > that this document defines a data model for centralized conferencing.=20 > This is confusing because the framework does not actually define the=20 > data model; the data model draft does. Therefore, I would suggest that > the framework clearly states that the definition of the data model is in >=20 > the data model draft. [MB] Obviously, the title and other references to a data model predate the data model draft. This document does present the data model at a high level as I think that's necessary to provide an idea of what the conference object contains. I'm wondering if it wouldn't be okay to just qualify the reference to data model as "high level data model" in the abstract and introduction. Then, the next reference to data model (other than definitions) is in section 5, where we do include the reference to the data model document. [/MB] >=20 > The document has a section (Section 2) that references RFC 2119 but then >=20 > does not use normative language. If the idea is to have an informational >=20 > framework, that section can be removed. [MB] There are actually lots of MUSTS and some SHOULDS in this document but they're not all caps. I can go in and add the caps. [/MB] >=20 > The 1st paragraph of Section 5 states that the common conference=20 > information type is extensible for including multiple sub-type. What=20 > exactly does that mean? Extensions to the data model will continue using >=20 > the same media type. >=20 > [MB] Good catch. That is a leftover from the removal of the template > concepts. I think it should just read: "The common conference > information type is extensible." [/MB] >=20 > The 2nd paragraph of Section 5.2 says that policies are not explicitly > defined within the data model, but rather are reflected in the system=20 > realization. Given that policies will be studied after the data model is >=20 > completed, I would avoid talking to much about policies until we have a=20 > clear view on how they will be implemented. >=20 > [MB] I agree that much of that section no longer fits based on the > discussion from IETF-68 (and this also impacts the last paragraph of > section 5). >=20 > Did we ever take that point to the mailing list as a conclusion or does > anyone have any concerns about removing this whole section and munging > section 5.1 into section 5 and having only a general statement about > policy? I'll take this item as an issue to the mailing list, as I don't > think many people are going to read it here :) [/MB] >=20 >=20 > Section 7.1 describes the cloning tree. Part of that concept is the=20 > cloning of policies. Again, since policies are for further study, I=20 > would avoid talking too much about them at this point. In fact, this=20 > cloning tree concept will probably need to be further described in the > policies draft to be written in the future. >=20 > [MB] I still think we need this parent enforceable concept here, no > matter how we implement the policies. I think this is one of the > reasons why I was one of the ones that did not want to remove all the > policy data from the data model (i.e., I think some of the basic > read/write and allowed sort of stuff may be necessary). Again, I'll > take this point as part of the discussion of the issue to the list. > [/MB] >=20 >=20 > Nits: >=20 > [MB] I'll fix these in the -08. [/MB] >=20 > Page 5, 3rd paragraph. > OLD: > A Binary Floor Control Protocol (BFCP)... >=20 > NEW: > A floor control protocol (e.g., BFCP)... >=20 > Figure 1: spacing problem on the right-most vertical line (which is made >=20 > of dots). >=20 > Figure 2: the same type of spacing problem. >=20 >=20 > Cheers, >=20 > Gonzalo >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sun Apr 29 05:53:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi65y-0005OJ-3q; Sun, 29 Apr 2007 05:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi65w-0005OE-TX for xcon@ietf.org; Sun, 29 Apr 2007 05:53:28 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hi65u-0004ol-TS for xcon@ietf.org; Sun, 29 Apr 2007 05:53:28 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 33A84210DC; Sun, 29 Apr 2007 11:53:26 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-95-46346b16fb54 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1FC3A210CD; Sun, 29 Apr 2007 11:53:26 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Apr 2007 11:53:25 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Apr 2007 11:53:25 +0200 Received: from [131.160.126.25] (rvi2-126-25.lmf.ericsson.se [131.160.126.25]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4459F23F6; Sun, 29 Apr 2007 12:53:25 +0300 (EEST) Message-ID: <46346B14.9040105@ericsson.com> Date: Sun, 29 Apr 2007 12:53:24 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Apr 2007 09:53:25.0623 (UTC) FILETIME=[3B096870:01C78A44] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: xcon@ietf.org Subject: [XCON] Re: Comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Mary, > [MB] Obviously, the title and other references to a data model predate > the data model draft. This document does present the data model at a > high level as I think that's necessary to provide an idea of what the > conference object contains. I'm wondering if it wouldn't be okay to just > qualify the reference to data model as "high level data model" in the > abstract and introduction. Then, the next reference to data model (other > than definitions) is in section 5, where we do include the reference to > the data model document. [/MB] I agree the framework should introduce the data model and maybe describe it at a high level. However, the framework should not state that it defines the data model. That would be confusing. The same way, the framework talks about floor control and BFCP but does not claim to define BFCP. Therefore, I would suggest that the framework clearly explains that the data model is defined elsewhere. > [MB] There are actually lots of MUSTS and some SHOULDS in this document > but they're not all caps. I can go in and add the caps. [/MB] Is our intention to have an informational framework or a standards-track framework? What type of MUSTs and SHOULDs do you have in mind? Thanks, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sun Apr 29 06:01:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi6E3-0001kk-QM; Sun, 29 Apr 2007 06:01:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi6E1-0001iY-KP for xcon@ietf.org; Sun, 29 Apr 2007 06:01:49 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hi6Dz-0000On-Re for xcon@ietf.org; Sun, 29 Apr 2007 06:01:49 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5372C210FA; Sun, 29 Apr 2007 12:01:47 +0200 (CEST) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-40-46346d0b64e9 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 332C5203B6; Sun, 29 Apr 2007 12:01:47 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Apr 2007 12:01:47 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Apr 2007 12:01:46 +0200 Received: from [131.160.126.25] (rvi2-126-25.lmf.ericsson.se [131.160.126.25]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EFE0C23F6; Sun, 29 Apr 2007 13:01:45 +0300 (EEST) Message-ID: <46346D09.6030909@ericsson.com> Date: Sun, 29 Apr 2007 13:01:45 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mary Barnes Subject: Re: [XCON] Removing Policies from the framework document (and data model) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Apr 2007 10:01:46.0356 (UTC) FILETIME=[657F3340:01C78A45] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi, the arguments given in our last face-to-face meeting to remove all policy-related stuff from the data model at this point were: 1) if we specify something now, when, at a later point, we study the problem carefully, what we do now may influence what we can do in the future. It would be better to be able to work on the problem without this type of restrictions. 2) defining two ways to define policies may lead to conflicts and collisions. We would need extra rules (and, thus, extra complexity) to resolve such conflicts. Therefore, I would prefer if we worked on policies afterwards and did not include any policy-related mechanism at this point. Cheers, Gonzalo Mary Barnes wrote: > There had been a thread on "Policies in the data model" prior to IETF-68 > and we discussed that point at the meeting: > _http://www3.ietf.org/proceedings/07mar/minutes/xcon.htm_ > > But, there was no clear conclusion, although it did seem most folks were > in favor of completing the data model without the policy information. > However, some of us thought we needed some basic information such as > read/write access (and roles). > > Per the recent discussion and suggestion on updates to the framework, it > has been suggested to remove the references to policy. I can easily see > how the text in section 5 can be generalized - I'm proposing to get rid > of section 5.2 altogether and merge 5.1 text with 5 and just have a > general statement on policy. > > However, there is the fundamental concept in the "cloning tree" model > whereby the child is created as either being independent of the parent > and thus subject to the parent's policies or independent. I think that's > an important concept that we've had in the framework for quite some > time. The context in which policies are discussed is around read/write > access restrictions. In my mind, I think this requires the basic concept > of the read/write access to be a requirement on implementation of the > data model, although not necessarily something that is an explicit part > of the data model. This view is consistent with the existing text in > the framework document. > > In short, I'm proposing we remove the explicit text suggesting that > policies are part of the data model, but keep the text that discusses > the read/write access such as the following from section 5.2: > > "Conference policies collectively refers to a set of rights, > permissions and limitations pertaining to operations being performed > on a certain conference object. > > The set of rights describes the read/write access privileges for the > conference object as a whole. This access would usually be granted > and defined in terms of giving the read-only or read-write access to > clients with certain roles in the conference. As such, the policies > represented by the set of rights are reflected in the system realization > (Section 7) and not part of a more general policy framework or model." > > And, then reword the last two paragraphs as follows: > > "A policy framework and model for centralized conferencing, including > a mechanism for > defining the permissions and limitations, is an item for future > study." > > Regards, > Mary > > > ------------------------------------------------------------------------ > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 30 03:57:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiQlD-0008PV-0T; Mon, 30 Apr 2007 03:57:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiQlB-0008PN-VZ for xcon@ietf.org; Mon, 30 Apr 2007 03:57:25 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiQlA-0005pl-Ci for xcon@ietf.org; Mon, 30 Apr 2007 03:57:25 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3C9EC21214; Mon, 30 Apr 2007 09:57:23 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-3c-4635a163e00e Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0EEB620118; Mon, 30 Apr 2007 09:57:23 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 09:57:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Apr 2007 09:56:40 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceHPwmeREeU/PqhQJ2OLBJG23H9ywALOemwAOICnhA= References: From: "Oscar Novo \(JO/LMF\)" To: "Mary Barnes" , X-OriginalArrivalTime: 30 Apr 2007 07:57:22.0948 (UTC) FILETIME=[2F5F4440:01C78AFD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: eee8f8a810071652260f5b6c3a710e46 Cc: cboulton@ubiquitysoftware.com Subject: [XCON] RE: More comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1562544240==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1562544240== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78AFD.163135D2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78AFD.163135D2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mary,=20 =20 I have just a coupled of comments. =20 - I still think the replacement of the "common conference information" for "conference information data model" is important. Now, this concept is only defined in the framework and it can be very confusing for the readers. I don't think the substitution of this term will impact the whole text. In the framework you have this term only in 20 places, mainly in the 'terminology' and the 'centralized conferencing data model' section. =20 - Regarding section 5.1 there is some text not clear and very confuse, for instance:=20 "The data model defined in [17] would be the basis for conferencing systems supporting enhanced conferencing features.The additional information defined in [17] provides the details of the specific media mixing details, the associated client roles and the available floor controls".=20 The data model doesn't define any additional information. That was defined in the template document. That's why I said that section still have some concepts about the templates. =20 Regards, =20 Oscar ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: 25. huhtikuuta 2007 22:54 To: Oscar Novo (JO/LMF); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt Hi Oscar, =20 Thanks for your comments. My responses are below [MB]. =20 =20 Mary=20 -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Wednesday, April 25, 2007 8:38 AM To: xcon@ietf.org Cc: Barnes, Mary (RICH2:AR00); cboulton@ubiquitysoftware.com Subject: More comments on draft-ietf-xcon-framework-07.txt =09 =09 And here a bit more comments on the framework:=20 -The framework defines the data model as a "common conference information". When we had the templates this concept was right but now I think this concept is not correct. I propose to change the name to "Conference Information Data Model" as is defined in the data model draft.=20 [MB] Given we're post-WGLC, I'd prefer to have additional feedback before making this change as I think the Common Conference Information is a general enough concept and I think that change impacts a whole lot of text and I'd be concerned that I'd break more than I might fix with that change. [/MB] - I think section 5.1 is a bit messy. It still have concepts about the templates. I have re-written a bit that section to adapted it to the data model idea: =20 [MB] I don't think 5.1 has template concepts at all - I removed all of those in the -04 to -05 bunch of changes in Sept. 2006. What that section does have is the idea of basic conferencing with the event package defined in RFC 4575 per the reference and then it goes on to describe why we've done the data model draft in XCON to support the enhanced conferencing. This gets back to the point we've discussed in the past of ensuring that a system based on the XCON FW can also support clients that only support RFC 4575 and not the XCON data model. [/MB] "There is a core set of data in the conference system that is utilized in any conference, independent of the specific conference media nature (e.g., the mixing algorithms performed, the advanced floor control applied, etc.). This core set of data contains the definitions representing the conference object capabilities, membership, roles, call signaling and media status relevant to different stages of the conference life-cycle. This core set of data is represented using the conference information data model type defined in [17]. =20 New centralized conferencing specifications can extend the conference information data model type as defined in [17] and introduce additional data elements to be used within the conference information data model type." - In the 'conferencing scenario realizations' section when a user "Alice" creates a sidebar conference. Is "Alice" included in the sidebar conference as a user? Reading the text looks like "Alice" is included in the sidebar but checking the figures looks like she is not part of the sidebar conference. =20 [MB] I'm not sure which figure you're referring to. In Figures 12 and 13, I guess we could debate whether "Alice" should show up in the Reservation, but "Alice" is shown in the "Active Sidebar Conference" in both Figures. Is that the figures you're referring to? [/MB]=20 - I'm a bit confuse with the use case explain in section 9.6 'Whispering or Private Messages'. As I understood whispering is a participant who send a one-way message to a single participant. RFC 4597 defines whispers or private messages as follow: "A participant can send a one-way message (text, audio, or even some other media) to another participant that is immediately rendered. This differs from a sidebar in that it is immediate and creates no long-lived session." The framework is defining whispering in a different way: "one participant sends a message to multiple participants using sidebars". For me, that definition is not connect to 'whispering or private messages' but instead to 'sidebars'. =20 [MB] No, I don't think the framework really defines the whispering in a different way - it does further refine that definition in the context of the fraamework. We define "whisper" in section 4 as: "A whisper involves a one-time media input to a specific participant(s) within a specific conference instance, accomplished using a sidebar. An example of a whisper would be an announcement injected only to the conference chair or to a new participant joining a conference." =09 So, I think that's consistent with the definition in 4597 in that, per the example, the sidebar is immediately removed after delivering that onetime media. =20 As background, the definition was added in the -05, with other text added to the document on whisper added in the -03 based on WG discussions. I'd have to dig to find those threads, but am reluctant to re-open past discussions without additional input from others in the WG. [/MB] As well, the use case defined in 9.6 is very confused. Why do we need to create a sidebar and a conference ID to send a single private message to a user? It doesn't make any sense for me. If the participant knows the userID, he could send the whispering message straight to his friend without create any sidebar, conferenceID or notification message. [MB] This use case was added in the -05 version based on input from a WG member and is consistent with the WG consensus on the definition of whisper (which is based on a sidebar) and as I'm recalling we did have this long, long debate. [/MB] - Section 9.9 'Observing and Coaching'. Is it necesary to create a sidebar for observing a conference? Couldn't be the observer in the conference a 'hidden' participant? As far as you notify the other participant that the conference is recorded or observed by a third party I guess it's OK, right?=20 [MB] And, that's exactly what the text says - you can accomplish the observing functionality by just having the supervisor as a hidden participant, which is what the first two paragraphs of that section discuss. It then describes that to take that functionality one step further to handle the coaching: " Taking the supervisor capability one step further introduces a scenario whereby the agent can hear the supervisor, as well as the customer. The customer can still only hear the agent. This scenario would involve the creation of a sidebar involving the agent and the supervisor. " [/MB]=20 - I think the intended status of the framework should be Standard track, no informational as it is now. =20 [MB] Agreed, per previous email discussions - I'll make that change with other nits and add that categorization to the header. [/MB] =09 - The user identifier and the XCON identifier are defined now in the data model. The references to those draft should be removed from the Framework or should reference to the data model instead.=20 [MB] Agreed per discussions at IETF-68. Nits: =20 [MB] Thanks - I'll take care of these on the next update. =20 In some places you are using "signaling" in other "signalling".=20 Figure 2: Change "Common conference information type" for "Conference Information Data Model type"=20 Figure 10: It's missing the clients usernames "Carol" and "Bob". Figure 13: When Alice creates the sidebar only includes one "confUserID". She should include at least "Bob", "Ethel" and "Carol" user ID. Figure 16: No sidebars are created in this uses case. So, "Active Sidebar Conference" should be change in the picture to "Active Conference". Change in the text:=20 Cbject -> Object=20 Identifer-> Identifier=20 "And the the conference object is updated" -> "And the conference object is updated"=20 "Object identifier as as shown in Figure 11" -> "Object identifier as shown in Figure 11"=20 "can be handled by by supervisor adding" -> "can be handled by supervisor adding"=20 Cheers,=20 Oscar Novo=20 ------_=_NextPart_001_01C78AFD.163135D2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Mary,
 
I have=20 just a coupled of comments.
 
- I=20 still think the replacement of the "common conference information" for=20 "conference information data model" is important. Now, this concept is = only=20 defined in the framework and it can be very confusing for the readers. I = don't=20 think the substitution of this term will impact the whole text. In the = framework=20 you have this term only in 20 places, mainly in the = 'terminology' and the=20 'centralized conferencing data model' section.
 
- Regarding section 5.1 there is some text not clear and = very=20 confuse, for instance:
"The=20 data model defined in [17] would be the basis for conferencing systems supporting = enhanced=20 conferencing features.The additional = information=20 defined in [17]=20 provides the details of the specific media mixing details, the = associated client=20 roles and the available floor controls".
The data model doesn't define any additional information. That = was=20 defined in the template document. That's why I said = that section=20 still have some concepts about the templates.
 
Regards,
 
Oscar

From: Mary Barnes=20 [mailto:mary.barnes@nortel.com]
Sent: 25. huhtikuuta 2007=20 22:54
To: Oscar Novo (JO/LMF); xcon@ietf.org
Cc:=20 cboulton@ubiquitysoftware.com
Subject: RE: More comments on=20 draft-ietf-xcon-framework-07.txt

Hi=20 Oscar,
 
Thanks=20 for your comments. My responses are below [MB].  =
 
Mary=20
-----Original Message-----
From: = Oscar Novo=20 (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: Wednesday, = April=20 25, 2007 8:38 AM
To: xcon@ietf.org
Cc: Barnes, = Mary=20 (RICH2:AR00); cboulton@ubiquitysoftware.com
Subject: More = comments=20 on draft-ietf-xcon-framework-07.txt

And here a bit more comments on the=20 framework:

-The framework defines the data = model as a=20 "common conference information". When we had the templates this = concept was=20 right but now I think this concept is not correct. I propose to change = the=20 name to "Conference Information Data Model" as is defined in the data = model=20 draft. 

[MB] Given we're post-WGLC, I'd prefer to have = additional=20 feedback before making this change as I think the Common Conference=20 Information is a general enough concept and I think that change = impacts a=20 whole lot of text and I'd be concerned that I'd break more than I = might fix=20 with that change. [/MB]

- I think section 5.1 is a bit = messy. It=20 still have concepts about the templates. I have re-written a bit that = section=20 to adapted it to the data model idea:  

[MB]  I don't think=20 5.1 has template concepts at all - I removed all of = those in=20 the -04 to -05 bunch of changes in Sept. 2006.   What that = section does=20 have is the idea of basic conferencing with the event package defined = in RFC=20 4575 per the reference and then it goes on to describe why we've done = the data=20 model draft in XCON to support the enhanced conferencing. This gets = back to=20 the point we've discussed in the past of ensuring that a system based = on the=20 XCON FW can also support clients that only support RFC 4575 and not = the XCON=20 data model. [/MB]

  "There is a core set of = data in=20 the conference system that is utilized in any conference, independent = of the=20 specific conference media nature (e.g., the mixing algorithms = performed, the=20 advanced floor control applied, etc.). This core set of data contains = the=20 definitions representing the conference object capabilities, = membership,=20 roles, call signaling and media status relevant to different stages of = the=20 conference life-cycle.  This core set of data is represented = using the=20 conference information data model type defined in [17]. =20


New centralized conferencing = specifications can=20 extend the conference information data model type as defined in [17] = and=20 introduce additional data elements to be used within the conference=20 information data model type."

- In the 'conferencing scenario = realizations'=20 section when a user "Alice" creates a sidebar conference. Is "Alice" = included=20 in the sidebar conference as a user? Reading the text looks like = "Alice" is=20 included in the sidebar but checking the figures looks like she is not = part of=20 the sidebar conference.  

[MB]  I'm not sure = which figure=20 you're referring to.  In Figures 12 and 13, I guess we could = debate=20 whether "Alice" should show up in the Reservation, but "Alice" is = shown=20 in the "Active Sidebar Conference" in both Figures. Is that the = figures you're=20 referring to? [/MB] 

- I'm a=20 bit confuse with the use case explain in section 9.6 'Whispering or = Private=20 Messages'. As I understood whispering is a participant who send a = one-way=20 message to a single participant. RFC 4597 defines whispers or private = messages=20 as follow:

"A participant can send a one-way = message (text,=20 audio, or even some other media) to another participant that is = immediately=20 rendered.  This differs from a sidebar in that it is immediate = and=20 creates no long-lived session."

The framework is defining = whispering in a=20 different way: "one participant sends a message to multiple = participants using=20 sidebars". For me, that definition is not connect to 'whispering or = private=20 messages' but instead to 'sidebars'.  

[MB] No, I don't think the framework really defines = the=20 whispering in a different way - it does further refine that definition = in=20 the context of the fraamework. We define "whisper" in section 4=20 as:

      "A whisper involves a = one-time=20 media input to a specific
      = participant(s)=20 within a specific conference instance,=20 accomplished
      using a sidebar.  = An=20 example of a whisper would be an=20 announcement
      injected only to the = conference=20 chair or to a new participant
      = joining a=20 conference."

So, I think that's consistent with the definition in = 4597 in=20 that, per the example, the sidebar is immediately removed after = delivering=20 that onetime media. 

As background, the definition was added in the -05, = with other=20 text added to the document on whisper added in the -03 based on WG=20 discussions. I'd have to dig to find those threads, but am reluctant = to=20 re-open past discussions without additional input from others in the = WG.=20  [/MB]

As well, the use case defined in = 9.6 is very=20 confused. Why do we need to create a sidebar and a conference ID to = send a=20 single private message to a user? It doesn't make any sense for me. If = the=20 participant knows the userID, he could send the whispering message = straight to=20 his friend without create any sidebar, conferenceID or notification=20 message. 

[MB] This use case was added in the -05 = version based=20 on input from a WG member and is consistent with the WG consensus on = the=20 definition of whisper (which is based on a sidebar) and as I'm = recalling we=20 did have this long, long debate. [/MB]

 -=20 Section 9.9 'Observing and Coaching'. Is it necesary to create a = sidebar for=20 observing a conference? Couldn't be the observer in the conference a = 'hidden'=20 participant? As far as you notify the other participant that the = conference is=20 recorded or observed by a third party I guess it's OK, right? 

[MB] And, that's exactly what the text = says - you=20 can accomplish the observing functionality by just having the = supervisor=20 as a hidden participant, which is what the first two paragraphs = of that=20 section discuss. It then describes that to take that functionality one = step=20 further to handle the coaching:

  " Taking the supervisor capability one step further = introduces=20 a
   scenario whereby the agent can hear the supervisor, = as well=20 as the
   customer.  The customer can still only = hear the=20 agent.  This scenario
   would involve the creation = of a=20 sidebar involving the agent and the
  =20 supervisor. "

[/MB] 

- I think the intended status of = the=20 framework should be Standard track, no informational as it is = now.  

[MB]=20 Agreed, per previous email discussions - I'll make that change with = other nits=20 and add that categorization to the header. =  [/MB]


-=20 The user identifier and the XCON identifier are defined now in the = data model.=20 The references to those draft should be removed from the Framework or = should=20 reference to the data model instead. 

[MB] Agreed per discussions at = IETF-68.

Nits:  

[MB]=20 Thanks - I'll take care of these on the next update.=20  

In some places you are using = "signaling" in other=20 "signalling".

Figure 2: Change "Common conference = information=20 type" for "Conference Information Data Model type"
Figure 10: It's missing the clients usernames "Carol" and = "Bob".=20
Figure 13: When Alice creates the = sidebar only=20 includes one "confUserID". She should include at least "Bob", "Ethel" = and=20 "Carol" user ID.

Figure 16: No sidebars are created in = this uses=20 case. So, "Active Sidebar Conference" should be change in the picture = to=20 "Active Conference".


Change in the text:

Cbject -> Object
Identifer-> Identifier
"And the=20 the conference object is updated" -> "And the conference object is=20 updated"
"Object identifier as = as shown in=20 Figure 11" -> "Object identifier as shown in Figure 11" =
"can be handled by by supervisor adding" -> = "can be=20 handled by supervisor adding"

Cheers,

Oscar Novo =

------_=_NextPart_001_01C78AFD.163135D2-- --===============1562544240== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============1562544240==-- From xcon-bounces@ietf.org Mon Apr 30 07:37:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUC3-0003iC-0S; Mon, 30 Apr 2007 07:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUC1-0003TX-Jj for xcon@ietf.org; Mon, 30 Apr 2007 07:37:21 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiUC0-0003Rv-Jo for xcon@ietf.org; Mon, 30 Apr 2007 07:37:21 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3UBaoY20472; Mon, 30 Apr 2007 11:36:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Apr 2007 06:36:49 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceHPwmeREeU/PqhQJ2OLBJG23H9ywALOemwAOICnhAACayuQA== From: "Mary Barnes" To: "Oscar Novo \(JO/LMF\)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: afbb91703506ab43c817903f0dd6f23d Cc: cboulton@ubiquitysoftware.com Subject: [XCON] RE: More comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0513051524==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0513051524== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78B1B.D7749AEA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78B1B.D7749AEA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Oscar, =20 Responses embedded below [MB]. =20 Thanks, Mary=20 =09 -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Monday, April 30, 2007 2:57 AM To: Barnes, Mary (RICH2:AR00); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt =09 =09 Hi Mary,=20 =20 I have just a coupled of comments. =20 - I still think the replacement of the "common conference information" for "conference information data model" is important. Now, this concept is only defined in the framework and it can be very confusing for the readers. I don't think the substitution of this term will impact the whole text. In the framework you have this term only in 20 places, mainly in the 'terminology' and the 'centralized conferencing data model' section.=20 [MB] I do understand how the term "common" has lost its original context since we no longer have the templates, thus there's only one set of information. But, a global replacement won't work quite right, at least in terms of the basic definition, where the "common conference information" is defined as:=20 " The common conference information is the data type (i.e., the XML schema) for a conference object". =20 How about we just drop the phrase "common" and refer to it as "Conference Information"? [/MB] =20 - Regarding section 5.1 there is some text not clear and very confuse, for instance:=20 "The data model defined in [17] would be the basis for conferencing systems supporting enhanced conferencing features.The additional information defined in [17] provides the details of the specific media mixing details, the associated client roles and the available floor controls".=20 The data model doesn't define any additional information. That was defined in the template document. That's why I said that section still have some concepts about the templates.=20 [MB] Okay, now I see your specific concern. Would it be clearer and less confusing if we just drop "additional" from that sentence? [/MB]=20 =20 Regards, =20 Oscar ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: 25. huhtikuuta 2007 22:54 To: Oscar Novo (JO/LMF); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt =09 =09 Hi Oscar, =20 Thanks for your comments. My responses are below [MB]. =20 =20 Mary=20 -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Wednesday, April 25, 2007 8:38 AM To: xcon@ietf.org Cc: Barnes, Mary (RICH2:AR00); cboulton@ubiquitysoftware.com Subject: More comments on draft-ietf-xcon-framework-07.txt =09 =09 And here a bit more comments on the framework:=20 -The framework defines the data model as a "common conference information". When we had the templates this concept was right but now I think this concept is not correct. I propose to change the name to "Conference Information Data Model" as is defined in the data model draft.=20 [MB] Given we're post-WGLC, I'd prefer to have additional feedback before making this change as I think the Common Conference Information is a general enough concept and I think that change impacts a whole lot of text and I'd be concerned that I'd break more than I might fix with that change. [/MB] - I think section 5.1 is a bit messy. It still have concepts about the templates. I have re-written a bit that section to adapted it to the data model idea: =20 [MB] I don't think 5.1 has template concepts at all - I removed all of those in the -04 to -05 bunch of changes in Sept. 2006. What that section does have is the idea of basic conferencing with the event package defined in RFC 4575 per the reference and then it goes on to describe why we've done the data model draft in XCON to support the enhanced conferencing. This gets back to the point we've discussed in the past of ensuring that a system based on the XCON FW can also support clients that only support RFC 4575 and not the XCON data model. [/MB] "There is a core set of data in the conference system that is utilized in any conference, independent of the specific conference media nature (e.g., the mixing algorithms performed, the advanced floor control applied, etc.). This core set of data contains the definitions representing the conference object capabilities, membership, roles, call signaling and media status relevant to different stages of the conference life-cycle. This core set of data is represented using the conference information data model type defined in [17]. =20 New centralized conferencing specifications can extend the conference information data model type as defined in [17] and introduce additional data elements to be used within the conference information data model type." - In the 'conferencing scenario realizations' section when a user "Alice" creates a sidebar conference. Is "Alice" included in the sidebar conference as a user? Reading the text looks like "Alice" is included in the sidebar but checking the figures looks like she is not part of the sidebar conference. =20 [MB] I'm not sure which figure you're referring to. In Figures 12 and 13, I guess we could debate whether "Alice" should show up in the Reservation, but "Alice" is shown in the "Active Sidebar Conference" in both Figures. Is that the figures you're referring to? [/MB]=20 - I'm a bit confuse with the use case explain in section 9.6 'Whispering or Private Messages'. As I understood whispering is a participant who send a one-way message to a single participant. RFC 4597 defines whispers or private messages as follow: "A participant can send a one-way message (text, audio, or even some other media) to another participant that is immediately rendered. This differs from a sidebar in that it is immediate and creates no long-lived session." The framework is defining whispering in a different way: "one participant sends a message to multiple participants using sidebars". For me, that definition is not connect to 'whispering or private messages' but instead to 'sidebars'. =20 [MB] No, I don't think the framework really defines the whispering in a different way - it does further refine that definition in the context of the fraamework. We define "whisper" in section 4 as: "A whisper involves a one-time media input to a specific participant(s) within a specific conference instance, accomplished using a sidebar. An example of a whisper would be an announcement injected only to the conference chair or to a new participant joining a conference." =09 So, I think that's consistent with the definition in 4597 in that, per the example, the sidebar is immediately removed after delivering that onetime media. =20 As background, the definition was added in the -05, with other text added to the document on whisper added in the -03 based on WG discussions. I'd have to dig to find those threads, but am reluctant to re-open past discussions without additional input from others in the WG. [/MB] As well, the use case defined in 9.6 is very confused. Why do we need to create a sidebar and a conference ID to send a single private message to a user? It doesn't make any sense for me. If the participant knows the userID, he could send the whispering message straight to his friend without create any sidebar, conferenceID or notification message.=20 [MB] This use case was added in the -05 version based on input from a WG member and is consistent with the WG consensus on the definition of whisper (which is based on a sidebar) and as I'm recalling we did have this long, long debate. [/MB] - Section 9.9 'Observing and Coaching'. Is it necesary to create a sidebar for observing a conference? Couldn't be the observer in the conference a 'hidden' participant? As far as you notify the other participant that the conference is recorded or observed by a third party I guess it's OK, right?=20 [MB] And, that's exactly what the text says - you can accomplish the observing functionality by just having the supervisor as a hidden participant, which is what the first two paragraphs of that section discuss. It then describes that to take that functionality one step further to handle the coaching: " Taking the supervisor capability one step further introduces a scenario whereby the agent can hear the supervisor, as well as the customer. The customer can still only hear the agent. This scenario would involve the creation of a sidebar involving the agent and the supervisor. " [/MB]=20 - I think the intended status of the framework should be Standard track, no informational as it is now. =20 [MB] Agreed, per previous email discussions - I'll make that change with other nits and add that categorization to the header. [/MB] =09 - The user identifier and the XCON identifier are defined now in the data model. The references to those draft should be removed from the Framework or should reference to the data model instead.=20 [MB] Agreed per discussions at IETF-68. Nits: =20 [MB] Thanks - I'll take care of these on the next update. =20 In some places you are using "signaling" in other "signalling".=20 Figure 2: Change "Common conference information type" for "Conference Information Data Model type"=20 Figure 10: It's missing the clients usernames "Carol" and "Bob".=20 Figure 13: When Alice creates the sidebar only includes one "confUserID". She should include at least "Bob", "Ethel" and "Carol" user ID. Figure 16: No sidebars are created in this uses case. So, "Active Sidebar Conference" should be change in the picture to "Active Conference". Change in the text:=20 Cbject -> Object=20 Identifer-> Identifier=20 "And the the conference object is updated" -> "And the conference object is updated"=20 "Object identifier as as shown in Figure 11" -> "Object identifier as shown in Figure 11"=20 "can be handled by by supervisor adding" -> "can be handled by supervisor adding"=20 Cheers,=20 Oscar Novo=20 ------_=_NextPart_001_01C78B1B.D7749AEA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Oscar,
 
Responses embedded below = [MB].
 
Thanks,
Mary =
-----Original Message-----
From: = Oscar Novo=20 (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: Monday, = April 30,=20 2007 2:57 AM
To: Barnes, Mary (RICH2:AR00);=20 xcon@ietf.org
Cc: = cboulton@ubiquitysoftware.com
Subject:=20 RE: More comments on = draft-ietf-xcon-framework-07.txt

Hi=20 Mary,
 
I=20 have just a coupled of comments.
 
- I still think the replacement of the "common conference = information"=20 for "conference information data model" is important. Now, this = concept is=20 only defined in the framework and it can be very confusing for the = readers. I=20 don't think the substitution of this term will impact the whole text. = In the=20 framework you have this term only in 20 places, mainly in the=20 'terminology' and the 'centralized conferencing data=20 model' section. 
[MB] I do understand = how the term=20 "common" has lost its original context since we no longer have the = templates,=20 thus there's only one set of information. But, a global = replacement won't=20 work quite right, at least in terms of the basic definition, = where=20 the "common conference information" is defined as:=20
   " The=20 common
      conference information is the = data=20 type (i.e., the XML schema) for
      a = conference=20 object". 
How about we just drop the = phrase=20 "common" and refer to it as "Conference=20 Information"?
[/MB]
 
- Regarding section 5.1 there is some text not clear and = very=20 confuse, for instance:
"The data model defined in [17] would be the basis for = conferencing=20 systems supporting enhanced conferencing features.The additional information defined in [17] provides the details = of the specific=20 media mixing details, the associated client roles and the available = floor=20 controls".
The data model doesn't define any additional information. = That was=20 defined in the template document. That's why I said that = section still=20 have some concepts about the templates. 
[MB] Okay, now I see your = specific=20 concern.  Would it be clearer and less confusing if we just = drop=20 "additional" from that sentence? =20 [/MB] 
 
Regards,
 
Oscar

From: Mary Barnes=20 [mailto:mary.barnes@nortel.com]
Sent: 25. huhtikuuta 2007=20 22:54
To: Oscar Novo (JO/LMF); xcon@ietf.org
Cc:=20 cboulton@ubiquitysoftware.com
Subject: RE: More comments on=20 draft-ietf-xcon-framework-07.txt

Hi=20 Oscar,
 
Thanks for your comments. My responses are below [MB]. =20
 
Mary=20
-----Original Message-----
From: = Oscar Novo=20 (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: = Wednesday, April=20 25, 2007 8:38 AM
To: xcon@ietf.org
Cc: Barnes, = Mary=20 (RICH2:AR00); cboulton@ubiquitysoftware.com
Subject: More = comments=20 on draft-ietf-xcon-framework-07.txt

And here a bit more comments on the=20 framework:

-The framework defines the data = model as a=20 "common conference information". When we had the templates this = concept was=20 right but now I think this concept is not correct. I propose to = change the=20 name to "Conference Information Data Model" as is defined in the = data model=20 draft. 

[MB] Given we're post-WGLC, I'd prefer to have = additional=20 feedback before making this change as I think the Common Conference=20 Information is a general enough concept and I think that change = impacts a=20 whole lot of text and I'd be concerned that I'd break more than I = might fix=20 with that change. [/MB]

- I think section 5.1 is a bit = messy. It=20 still have concepts about the templates. I have re-written a bit = that=20 section to adapted it to the data model idea:  

[MB]  I don't think=20 5.1 has template concepts at all - I removed all of = those in=20 the -04 to -05 bunch of changes in Sept. 2006.   What that = section does=20 have is the idea of basic conferencing with the event package = defined in RFC=20 4575 per the reference and then it goes on to describe why we've = done the=20 data model draft in XCON to support the enhanced conferencing. This = gets=20 back to the point we've discussed in the past of ensuring that a = system=20 based on the XCON FW can also support clients that only support RFC = 4575 and=20 not the XCON data model. [/MB]

  "There is a core set = of data in=20 the conference system that is utilized in any conference, = independent of the=20 specific conference media nature (e.g., the mixing algorithms = performed, the=20 advanced floor control applied, etc.). This core set of data = contains the=20 definitions representing the conference object capabilities, = membership,=20 roles, call signaling and media status relevant to different stages = of the=20 conference life-cycle.  This core set of data is represented = using the=20 conference information data model type defined in [17]. =20


New centralized conferencing = specifications can=20 extend the conference information data model type as defined in [17] = and=20 introduce additional data elements to be used within the conference=20 information data model type."

- In the 'conferencing scenario = realizations' section when a user "Alice" creates a sidebar = conference. Is=20 "Alice" included in the sidebar conference as a user? Reading the = text looks=20 like "Alice" is included in the sidebar but checking the figures = looks like=20 she is not part of the sidebar conference.  

[MB]  I'm not sure = which=20 figure you're referring to.  In Figures 12 and 13, I guess we = could=20 debate whether "Alice" should show up in the Reservation, = but "Alice"=20 is shown in the "Active Sidebar Conference" in both Figures. Is that = the=20 figures you're referring to? = [/MB] 

- I'm=20 a bit confuse with the use case explain in section 9.6 'Whispering = or=20 Private Messages'. As I understood whispering is a participant who = send a=20 one-way message to a single participant. RFC 4597 defines whispers = or=20 private messages as follow:

"A participant can send a one-way = message (text,=20 audio, or even some other media) to another participant that is = immediately=20 rendered.  This differs from a sidebar in that it is immediate = and=20 creates no long-lived session."

The framework is defining = whispering in a=20 different way: "one participant sends a message to multiple = participants=20 using sidebars". For me, that definition is not connect to = 'whispering or=20 private messages' but instead to 'sidebars'.  

[MB] No, I don't think the framework really defines = the=20 whispering in a different way - it does further refine that = definition in=20 the context of the fraamework. We define "whisper" in section 4 = as:

      "A whisper involves a = one-time=20 media input to a specific
      = participant(s)=20 within a specific conference instance,=20 accomplished
      using a = sidebar.  An=20 example of a whisper would be an=20 announcement
      injected only to the=20 conference chair or to a new = participant
     =20 joining a conference."

So, I think that's consistent with the definition in = 4597 in=20 that, per the example, the sidebar is immediately removed after = delivering=20 that onetime media. 

As background, the definition was added in the -05, = with other=20 text added to the document on whisper added in the -03 based on WG=20 discussions. I'd have to dig to find those threads, but am reluctant = to=20 re-open past discussions without additional input from others in the = WG.=20  [/MB]

As well, the use case defined = in 9.6 is=20 very confused. Why do we need to create a sidebar and a conference = ID to=20 send a single private message to a user? It doesn't make any sense = for me.=20 If the participant knows the userID, he could send the whispering = message=20 straight to his friend without create any sidebar, conferenceID or=20 notification message. 

[MB] This use case was added in the -05 = version=20 based on input from a WG member and is consistent with the WG = consensus on=20 the definition of whisper (which is based on a sidebar) and as I'm = recalling=20 we did have this long, long debate. = [/MB]

 - Section 9.9 'Observing and = Coaching'. Is it necesary to create a sidebar for observing a = conference?=20 Couldn't be the observer in the conference a 'hidden' participant? = As far as=20 you notify the other participant that the conference is recorded or = observed=20 by a third party I guess it's OK, right? 

[MB] And, that's exactly what the text = says -=20 you can accomplish the observing functionality by just having = the=20 supervisor as a hidden participant, which is what the first two = paragraphs of that section discuss. It then describes that to take = that=20 functionality one step further to handle the=20 coaching:

  " Taking the supervisor capability one step further = introduces a
   scenario whereby the agent can hear the = supervisor, as well as the
   customer.  The = customer can=20 still only hear the agent.  This scenario
   would = involve=20 the creation of a sidebar involving the agent and = the
  =20 supervisor. "

[/MB] 

- I think the intended status = of the=20 framework should be Standard track, no informational as it is=20 now.  

[MB]=20 Agreed, per previous email discussions - I'll make that change with = other=20 nits and add that categorization to the header.=20  [/MB]


-=20 The user identifier and the XCON identifier are defined now in the = data=20 model. The references to those draft should be removed from the = Framework or=20 should reference to the data model instead. 

[MB] Agreed per discussions at=20 IETF-68.

Nits:  

[MB]=20 Thanks - I'll take care of these on the next update.=20  

In some places you are using = "signaling" in other=20 "signalling".

Figure 2: Change "Common conference = information=20 type" for "Conference Information Data Model type"
Figure 10: It's missing the clients usernames = "Carol" and=20 "Bob".
Figure 13: When Alice = creates the=20 sidebar only includes one "confUserID". She should include at least = "Bob",=20 "Ethel" and "Carol" user ID.

Figure 16: No sidebars are created in = this uses=20 case. So, "Active Sidebar Conference" should be change in the = picture to=20 "Active Conference".


Change in the text:

Cbject -> Object
Identifer-> Identifier
"And the=20 the conference object is updated" -> "And the conference object = is=20 updated"
"Object identifier = as as shown=20 in Figure 11" -> "Object identifier as shown in Figure 11" =
"can be handled by by supervisor = adding" ->=20 "can be handled by supervisor adding"

Cheers,

Oscar Novo=20

------_=_NextPart_001_01C78B1B.D7749AEA-- --===============0513051524== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0513051524==-- From xcon-bounces@ietf.org Mon Apr 30 07:55:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUTY-0007PJ-Kd; Mon, 30 Apr 2007 07:55:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUTX-0007GS-JW for xcon@ietf.org; Mon, 30 Apr 2007 07:55:27 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiUTX-00087c-Aw for xcon@ietf.org; Mon, 30 Apr 2007 07:55:27 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3UBtOJ18047; Mon, 30 Apr 2007 11:55:24 GMT 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: Mon, 30 Apr 2007 06:54:54 -0500 Message-ID: In-Reply-To: <46346B14.9040105@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceKRD6gH8F6+I50TG+ksFkrEFamVgA17CDA From: "Mary Barnes" To: "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: xcon@ietf.org Subject: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Gonzalo, > [MB] Obviously, the title and other references to a data model predate > the data model draft. This document does present the data model at a > high level as I think that's necessary to provide an idea of what the > conference object contains. I'm wondering if it wouldn't be okay to just > qualify the reference to data model as "high level data model" in the > abstract and introduction. Then, the next reference to data model (other > than definitions) is in section 5, where we do include the reference to > the data model document. [/MB] I agree the framework should introduce the data model and maybe describe it at a high level. However, the framework should not state that it=20 defines the data model. That would be confusing. The same way, the=20 framework talks about floor control and BFCP but does not claim to=20 define BFCP. Therefore, I would suggest that the framework clearly=20 explains that the data model is defined elsewhere. [MB] I think I need to be more explicit here. I'm proposing to change the text in the abstract as follows: OLD: The Centralized Conferencing Framework defines logical entities=20 and naming conventions, along with a conferencing data model.=20 NEW:=20 The Centralized Conferencing Framework defines logical entities=20 and naming conventions and introduces a high level conferencing data model.=20 and then mirroring that same change in the Introduction.=20 I think it could also be made more clear by renaming Section 5 from:=20 "Centralized Conferencing Data Model" to "Centralized Conferencing Data" since as you suggest, this section isn't really defining a data model, but rather describing the context for the conference object.=20 And, then we can change the first sentence in that section as follows: OLD: The centralized conference data model is logically represented by the conference object. NEW:=20 The centralized conference data is logically represented by the conference object. Note: that last sentence of the that first paragraph is already proposed to be removed based on Oscar's comments.=20 [/MB] > [MB] There are actually lots of MUSTS and some SHOULDS in this document > but they're not all caps. I can go in and add the caps. [/MB] Is our intention to have an informational framework or a standards-track framework? What type of MUSTs and SHOULDs do you have in mind? [MB] Per the response to Oscar and per the WG charter, this doc should be Proposed Standard and I'll include that when I make the next revision and update the template. There are musts (and shoulds) right now that aren't caps, such as:=20 - Section 7.3: "Any desired changes must be targeted towards the active conference. " - Section 8.4: " This conference object ID must be included in all floor control messages. " - Section 11: "The protocols used for manipulation and retrieval of confidential information MUST support a confidentiality and integrity mechanism." Certainly, there's not alot, but I still think it's worthwhile to keep the reference to 2119. [/MB] Thanks, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 30 08:37:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiV81-0007Us-A8; Mon, 30 Apr 2007 08:37:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiV7z-0007Tz-B7 for xcon@ietf.org; Mon, 30 Apr 2007 08:37:15 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiV7x-00023P-Bo for xcon@ietf.org; Mon, 30 Apr 2007 08:37:15 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4F05121038; Mon, 30 Apr 2007 14:37:12 +0200 (CEST) X-AuditID: c1b4fb3e-b01efbb0000061ca-f3-4635e2f86a91 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 442F9204D9; Mon, 30 Apr 2007 14:37:12 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 14:37:12 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 14:37:11 +0200 Received: from [131.160.36.11] (E000FB0F665DD.lmf.ericsson.se [131.160.36.11]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 99D772333; Mon, 30 Apr 2007 15:37:11 +0300 (EEST) Message-ID: <4635E2F7.1080702@ericsson.com> Date: Mon, 30 Apr 2007 15:37:11 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2007 12:37:11.0715 (UTC) FILETIME=[4641CF30:01C78B24] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: xcon@ietf.org Subject: [XCON] Re: Comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Mary, > [MB] I think I need to be more explicit here. I'm proposing to change > the text in the abstract as follows: the changes you suggest sound sensible. > > [MB] There are actually lots of MUSTS and some SHOULDS in this > document > > but they're not all caps. I can go in and add the caps. [/MB] > > Is our intention to have an informational framework or a standards-track > > framework? What type of MUSTs and SHOULDs do you have in mind? > > [MB] Per the response to Oscar and per the WG charter, this doc should > be Proposed Standard and I'll include that when I make the next revision > and update the template. There are musts (and shoulds) right now that > aren't caps, such as: > - Section 7.3: "Any desired changes must be targeted towards the active > conference. " Section 7.3 describes an example and, thus, should not have normative statements. > - Section 8.4: " This conference object ID must be included in all > floor control messages. " This type of statement belongs to the floor control protocol specification. > - Section 11: "The protocols used for > manipulation and retrieval of confidential information MUST support a > confidentiality and integrity mechanism." I do not think we need normative statements for this type of security stuff. The documents defining the individual parts (e.g., floor control, conference control) will take care of that. The framework document is useful to know how all those pieces fit together. > Certainly, there's not alot, but I still think it's worthwhile to keep > the reference to 2119. > [/MB] If the normative statements we are going to be adding are all like the ones above, I would suggest making the framework an informational RFC. Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 30 11:57:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYFY-0003cL-Ut; Mon, 30 Apr 2007 11:57:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYFY-0003cE-7T for xcon@ietf.org; Mon, 30 Apr 2007 11:57:16 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYFW-0004NC-SK for xcon@ietf.org; Mon, 30 Apr 2007 11:57:16 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3UFvCY25894; Mon, 30 Apr 2007 15:57:12 GMT 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: Mon, 30 Apr 2007 10:56:56 -0500 Message-ID: In-Reply-To: <4635E2F7.1080702@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceLJElyIZLQ4sP2RqqM9a1VO+0FWwAG50JQ From: "Mary Barnes" To: "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: xcon@ietf.org Subject: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Gonzalo, I don't have any issue with changing this to informational, although, having the musts, shoulds all being in examples highlights perhaps the need to have a call flow BCP type document. I'll let the chairs let us know one way or the other.=20 Thanks, Mary -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Monday, April 30, 2007 7:37 AM To: Barnes, Mary (RICH2:AR00) Cc: xcon@ietf.org Subject: Re: Comments on draft-ietf-xcon-framework-07.txt Hi Mary, > [MB] I think I need to be more explicit here. I'm proposing to change > the text in the abstract as follows: the changes you suggest sound sensible. > > [MB] There are actually lots of MUSTS and some SHOULDS in this > document > > but they're not all caps. I can go in and add the caps. [/MB] >=20 > Is our intention to have an informational framework or a standards-track >=20 > framework? What type of MUSTs and SHOULDs do you have in mind? >=20 > [MB] Per the response to Oscar and per the WG charter, this doc should > be Proposed Standard and I'll include that when I make the next revision > and update the template. There are musts (and shoulds) right now that > aren't caps, such as: > - Section 7.3: "Any desired changes must be targeted towards the active > conference. " Section 7.3 describes an example and, thus, should not have normative=20 statements. > - Section 8.4: " This conference object ID must be included in all > floor control messages. " This type of statement belongs to the floor control protocol specification. > - Section 11: "The protocols used for > manipulation and retrieval of confidential information MUST support a > confidentiality and integrity mechanism." I do not think we need normative statements for this type of security=20 stuff. The documents defining the individual parts (e.g., floor control, conference control) will take care of that. The framework document is=20 useful to know how all those pieces fit together. > Certainly, there's not alot, but I still think it's worthwhile to keep > the reference to 2119. > [/MB] If the normative statements we are going to be adding are all like the=20 ones above, I would suggest making the framework an informational RFC. Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 30 12:33:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYov-0000EI-Vz; Mon, 30 Apr 2007 12:33:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYou-0000Bc-1V for xcon@ietf.org; Mon, 30 Apr 2007 12:33:48 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYot-0001Sa-MS for xcon@ietf.org; Mon, 30 Apr 2007 12:33:48 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3UGXiI28609; Mon, 30 Apr 2007 16:33:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Removing Policies from the framework document (and data model) Date: Mon, 30 Apr 2007 11:33:41 -0500 Message-ID: In-Reply-To: <46346D09.6030909@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Removing Policies from the framework document (and data model) Thread-Index: AceKRWi+vpl5xnQKQTecvJ+CjxK9GQA/oYnQ From: "Mary Barnes" To: "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I don't at all have a problem with the decision to remove policies from the data model and not include any mechanisms at this time.=20 But, I still think we need to talk about policies in the context of the framework (and in particular the read/write and how the child may or may not also inherit policy properties from the parent). I think there are implied requirements on the policy solution in the framework and I don't want to lose the context of those. And, given the other thread proposing that the framework is informational, there would be nothing normative in this text. =20 And, it should be clear that the policy mechanism is not defined in this document and will be defined in another document, either as part of the protocol document or a separate document. For the record, I am opposed to this WG deciding at this time to work on a separate policy document. I think the work plan of completing the data model and then working out the details of the Conference Control Protocol should be worked, as I think the policy may be dependent upon the protocol choice.=20 The text I need to remove from the framework would be around policy information being an integral part of the data model. I think the general consensus seems to be that they are not. Folks, please speak up now if you disagree with this point. I'll proposed the detailed text changes in a separate email in case folks what to debate this general topic further. And, it would be good for some other voices to chime in with opinions.=20 Mary -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Sunday, April 29, 2007 5:02 AM To: Barnes, Mary (RICH2:AR00) Cc: xcon@ietf.org Subject: Re: [XCON] Removing Policies from the framework document (and data model) Hi, the arguments given in our last face-to-face meeting to remove all=20 policy-related stuff from the data model at this point were: 1) if we specify something now, when, at a later point, we study the=20 problem carefully, what we do now may influence what we can do in the=20 future. It would be better to be able to work on the problem without=20 this type of restrictions. 2) defining two ways to define policies may lead to conflicts and=20 collisions. We would need extra rules (and, thus, extra complexity) to=20 resolve such conflicts. Therefore, I would prefer if we worked on policies afterwards and did=20 not include any policy-related mechanism at this point. Cheers, Gonzalo Mary Barnes wrote: > There had been a thread on "Policies in the data model" prior to IETF-68=20 > and we discussed that point at the meeting:=20 > _http://www3.ietf.org/proceedings/07mar/minutes/xcon.htm_ >=20 > But, there was no clear conclusion, although it did seem most folks were=20 > in favor of completing the data model without the policy information. > However, some of us thought we needed some basic information such as=20 > read/write access (and roles). >=20 > Per the recent discussion and suggestion on updates to the framework, it=20 > has been suggested to remove the references to policy. I can easily see=20 > how the text in section 5 can be generalized - I'm proposing to get rid=20 > of section 5.2 altogether and merge 5.1 text with 5 and just have a=20 > general statement on policy. >=20 > However, there is the fundamental concept in the "cloning tree" model=20 > whereby the child is created as either being independent of the parent > and thus subject to the parent's policies or independent. I think that's=20 > an important concept that we've had in the framework for quite some=20 > time. The context in which policies are discussed is around read/write=20 > access restrictions. In my mind, I think this requires the basic concept=20 > of the read/write access to be a requirement on implementation of the=20 > data model, although not necessarily something that is an explicit part=20 > of the data model. This view is consistent with the existing text in=20 > the framework document.=20 >=20 > In short, I'm proposing we remove the explicit text suggesting that=20 > policies are part of the data model, but keep the text that discusses=20 > the read/write access such as the following from section 5.2: >=20 > "Conference policies collectively refers to a set of rights, > permissions and limitations pertaining to operations being performed > on a certain conference object. >=20 > The set of rights describes the read/write access privileges for the > conference object as a whole. This access would usually be granted > and defined in terms of giving the read-only or read-write access to > clients with certain roles in the conference. As such, the policies > represented by the set of rights are reflected in the system realization > (Section 7) and not part of a more general policy framework or model." >=20 > And, then reword the last two paragraphs as follows: >=20 > "A policy framework and model for centralized conferencing, including=20 > a mechanism for > defining the permissions and limitations, is an item for future=20 > study." >=20 > Regards, > Mary >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 30 12:42:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYx5-0004kW-Ls; Mon, 30 Apr 2007 12:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYx3-0004kP-SK for xcon@ietf.org; Mon, 30 Apr 2007 12:42:13 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYx1-0002TR-Vu for xcon@ietf.org; Mon, 30 Apr 2007 12:42:13 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5F23220413; Mon, 30 Apr 2007 18:42:11 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-5d-46361c632c79 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4DB812006B; Mon, 30 Apr 2007 18:42:11 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 18:42:11 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 18:42:11 +0200 Received: from [131.160.126.187] (rvi2-126-187.lmf.ericsson.se [131.160.126.187]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BC6B323F6; Mon, 30 Apr 2007 19:42:10 +0300 (EEST) Message-ID: <46361C62.2000605@ericsson.com> Date: Mon, 30 Apr 2007 19:42:10 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2007 16:42:11.0136 (UTC) FILETIME=[7FCB7400:01C78B46] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: xcon@ietf.org Subject: [XCON] Re: Comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi, sure, getting guidance from the chairs on the intended status would be great. > I don't have any issue with changing this to informational, although, > having the musts, shoulds all being in examples highlights perhaps the > need to have a call flow BCP type document. The protocol specs (e.g., SIP, BFCP) already specify the interactions between nodes in the context of those protocols. A BCP along the lines you describe would be useful if the interactions between different protocols would be particularly complicated (e.g., which SIP message to send when a conference is terminated through the conference control protocol). However, I do not think the inter-protocol interactions we are dealing with in XCON are complicated enough to grant yet another specification. Or do you have a few scenarios in mind that may be difficult to understand for an implementer without a document with examples? Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 30 12:56:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZB4-0005kE-DY; Mon, 30 Apr 2007 12:56:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZB4-0005k9-53 for xcon@ietf.org; Mon, 30 Apr 2007 12:56:42 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiZB2-0005CF-Sl for xcon@ietf.org; Mon, 30 Apr 2007 12:56:42 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3UGucJ18300; Mon, 30 Apr 2007 16:56:38 GMT 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: Mon, 30 Apr 2007 11:56:36 -0500 Message-ID: In-Reply-To: <46361C62.2000605@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceLRooUK1GwftjDRtSCE2mi3bZU9QAAbtUQ From: "Mary Barnes" To: "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: xcon@ietf.org Subject: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I don't think we need a BCP right now for the flows, but once we decide the Conference Control Protocol, I think a BCP with flows (e.g., taking some of the examples in the framework down to another level of detail) would be very useful.=20 Mary -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Monday, April 30, 2007 11:42 AM To: Barnes, Mary (RICH2:AR00) Cc: xcon@ietf.org Subject: Re: Comments on draft-ietf-xcon-framework-07.txt Hi, sure, getting guidance from the chairs on the intended status would be=20 great. > I don't have any issue with changing this to informational, although, > having the musts, shoulds all being in examples highlights perhaps the > need to have a call flow BCP type document. The protocol specs (e.g., SIP, BFCP) already specify the interactions=20 between nodes in the context of those protocols. A BCP along the lines=20 you describe would be useful if the interactions between different=20 protocols would be particularly complicated (e.g., which SIP message to=20 send when a conference is terminated through the conference control=20 protocol). However, I do not think the inter-protocol interactions we=20 are dealing with in XCON are complicated enough to grant yet another=20 specification. Or do you have a few scenarios in mind that may be=20 difficult to understand for an implementer without a document with examples? Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 30 12:59:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZDy-0007Km-TZ; Mon, 30 Apr 2007 12:59:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZDx-0007Kh-Q1 for xcon@ietf.org; Mon, 30 Apr 2007 12:59:41 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiZDv-0005cN-2P for xcon@ietf.org; Mon, 30 Apr 2007 12:59:41 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7EB2B2013F; Mon, 30 Apr 2007 18:59:38 +0200 (CEST) X-AuditID: c1b4fb3e-b1a1dbb0000061ca-e3-4636207ad95c Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 640CB20063; Mon, 30 Apr 2007 18:59:38 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 18:59:38 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 18:59:37 +0200 Received: from [131.160.126.187] (rvi2-126-187.lmf.ericsson.se [131.160.126.187]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 81F9823F6; Mon, 30 Apr 2007 19:59:37 +0300 (EEST) Message-ID: <46362078.4060800@ericsson.com> Date: Mon, 30 Apr 2007 19:59:36 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mary Barnes Subject: Re: [XCON] Removing Policies from the framework document (and data model) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2007 16:59:37.0926 (UTC) FILETIME=[EFBAEE60:01C78B48] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Mary, > But, I still think we need to talk about policies in the context of the > framework (and in particular the read/write and how the child may or may > not also inherit policy properties from the parent). I think there are > implied requirements on the policy solution in the framework and I don't > want to lose the context of those. And, given the other thread > proposing that the framework is informational, there would be nothing > normative in this text. sure, we can talk about that in the framework... but if we do that, I would suggest delaying the publication of the framework until we have a clear idea on how policies will be specified. Talking about read/write and inheritance without knowing how policies are going to be implemented seems a little risky to me. > And, it should be clear that the policy mechanism is not defined in this > document and will be defined in another document, either as part of the > protocol document or a separate document. For the record, I am opposed > to this WG deciding at this time to work on a separate policy document. > I think the work plan of completing the data model and then working out > the details of the Conference Control Protocol should be worked, as I > think the policy may be dependent upon the protocol choice. I am afraid I do not fully understand the work plan you propose in the paragraph above. Could you please clarify it for me? > The text I need to remove from the framework would be around policy > information being an integral part of the data model. I think the > general consensus seems to be that they are not. Folks, please speak up > now if you disagree with this point. I believe we have consensus on working on the policy issues in a different Internet Draft. However, such an internet draft may very well define policy elements that are an extension of the data model. In that case, policies would indeed be part of the data model (they would actually be an extension of the data model). If by "integral part" you mean that they are defined as part of the data model and not as an extension, then I agree with your statement. > I'll proposed the detailed text changes in a separate email in case > folks what to debate this general topic further. And, it would be good > for some other voices to chime in with opinions. Yes, it would be great to hear different opinions. Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 30 13:23:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZaa-0003Wl-CJ; Mon, 30 Apr 2007 13:23:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZaY-0003Wg-Ue for xcon@ietf.org; Mon, 30 Apr 2007 13:23:02 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiZaY-0000VW-KW for xcon@ietf.org; Mon, 30 Apr 2007 13:23:02 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3UHMxJ06460; Mon, 30 Apr 2007 17:23:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Removing Policies from the framework document (and data model) Date: Mon, 30 Apr 2007 12:22:59 -0500 Message-ID: In-Reply-To: <46362078.4060800@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Removing Policies from the framework document (and data model) Thread-Index: AceLSPIr89zhQYXZR0ykaHyFaOxgXwAAGT9g From: "Mary Barnes" To: "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org More comments embedded below [MB]. Mary -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Monday, April 30, 2007 12:00 PM To: Barnes, Mary (RICH2:AR00) Cc: xcon@ietf.org Subject: Re: [XCON] Removing Policies from the framework document (and data model) Hi Mary, > But, I still think we need to talk about policies in the context of the > framework (and in particular the read/write and how the child may or may > not also inherit policy properties from the parent). I think there are > implied requirements on the policy solution in the framework and I don't > want to lose the context of those. And, given the other thread > proposing that the framework is informational, there would be nothing > normative in this text. sure, we can talk about that in the framework... but if we do that, I=20 would suggest delaying the publication of the framework until we have a=20 clear idea on how policies will be specified. Talking about read/write=20 and inheritance without knowing how policies are going to be implemented seems a little risky to me. [MB] I do not think we need to delay the framework. I don't think that the idea of the child inheriting policy is so much a policy issue as it is a system implementation issue. The inheritance concept was a basic approach that we agreed long ago - the mechanisms to achieve that aren't specified, but the idea is an important concept for describing how one might design a conferencing system to support these various protocols. The whole idea of the framework is to provide a context for describing the protocols. I honestly think the text remains at an abstract enough level that it's not going to limit an implementation, but rather guide it. I think it would be really good if this group could agree that they agree on these basic concepts before moving forward, but it really matters not to me if we want to keep the framework within the WG until all the protocol work is done. But, I didn't think that was the direction the chairs intended us to go. =20 I'm actually very happy to start talking about how we can very easily implement policies based on XACML. And, I feel quite comfortable in saying that the high level concepts in the framework don't seem to cause any problems if that is selected.=20 [/MB] > And, it should be clear that the policy mechanism is not defined in this > document and will be defined in another document, either as part of the > protocol document or a separate document. For the record, I am opposed > to this WG deciding at this time to work on a separate policy document. > I think the work plan of completing the data model and then working out > the details of the Conference Control Protocol should be worked, as I > think the policy may be dependent upon the protocol choice.=20 I am afraid I do not fully understand the work plan you propose in the=20 paragraph above. Could you please clarify it for me? [MB] My concern is that the group will rathole if we decide to go off and define a policy control framework for the data model before we agree the protocol for the conference control based on that data model. I think once the group can agree a conference control protocol, the policy approach might well be a straightforward choice of selecting something that's already been developed.=20 [/MB] > The text I need to remove from the framework would be around policy > information being an integral part of the data model. I think the > general consensus seems to be that they are not. Folks, please speak up > now if you disagree with this point. I believe we have consensus on working on the policy issues in a=20 different Internet Draft. However, such an internet draft may very well=20 define policy elements that are an extension of the data model. In that=20 case, policies would indeed be part of the data model (they would=20 actually be an extension of the data model). [MB] I think we had consensus to not work on policy in the data model and to not work on policy in the framework. However, my point above, I think it's pre-mature for this group to start working a policy model. Per the point above, I understood the work plan for this working group to be to work on the protocol once we completed the data model. [/MB] If by "integral part" you mean that they are defined as part of the data model and not as an extension, then I agree with your statement. [MB] Yes, on this one point, we agree. [/MB] > I'll proposed the detailed text changes in a separate email in case > folks what to debate this general topic further. And, it would be good > for some other voices to chime in with opinions.=20 Yes, it would be great to hear different opinions. Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 30 13:28:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZfb-0006qh-AD; Mon, 30 Apr 2007 13:28:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZfa-0006pX-7H for xcon@ietf.org; Mon, 30 Apr 2007 13:28:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiZfZ-0001YI-Fi for xcon@ietf.org; Mon, 30 Apr 2007 13:28:14 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7DC002022A; Mon, 30 Apr 2007 19:28:12 +0200 (CEST) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-ec-4636272c6405 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 626362008D; Mon, 30 Apr 2007 19:28:12 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 19:28:12 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 19:28:11 +0200 Received: from [131.160.126.187] (rvi2-126-187.lmf.ericsson.se [131.160.126.187]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B9B9723F6; Mon, 30 Apr 2007 20:28:11 +0300 (EEST) Message-ID: <4636272B.6060803@ericsson.com> Date: Mon, 30 Apr 2007 20:28:11 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mary Barnes Subject: Re: [XCON] Removing Policies from the framework document (and data model) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2007 17:28:12.0096 (UTC) FILETIME=[ED748400:01C78B4C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Mary, I am OK with letting the chairs decide whether or not we should delay the publication of the framework. I am also OK with starting working on the control protocol as soon as the data model is WGLCed. Cheers, Gonzalo Mary Barnes wrote: > More comments embedded below [MB]. > > Mary > > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Monday, April 30, 2007 12:00 PM > To: Barnes, Mary (RICH2:AR00) > Cc: xcon@ietf.org > Subject: Re: [XCON] Removing Policies from the framework document (and > data model) > > > Hi Mary, > > > But, I still think we need to talk about policies in the context of > the > > framework (and in particular the read/write and how the child may or > may > > not also inherit policy properties from the parent). I think there > are > > implied requirements on the policy solution in the framework and I > don't > > want to lose the context of those. And, given the other thread > > proposing that the framework is informational, there would be nothing > > normative in this text. > > sure, we can talk about that in the framework... but if we do that, I > would suggest delaying the publication of the framework until we have a > clear idea on how policies will be specified. Talking about read/write > and inheritance without knowing how policies are going to be implemented > > seems a little risky to me. > > [MB] I do not think we need to delay the framework. I don't think that > the idea of the child inheriting policy is so much a policy issue as it > is a system implementation issue. The inheritance concept was a basic > approach that we agreed long ago - the mechanisms to achieve that aren't > specified, but the idea is an important concept for describing how one > might design a conferencing system to support these various protocols. > The whole idea of the framework is to provide a context for describing > the protocols. I honestly think the text remains at an abstract enough > level that it's not going to limit an implementation, but rather guide > it. I think it would be really good if this group could agree that they > agree on these basic concepts before moving forward, but it really > matters not to me if we want to keep the framework within the WG until > all the protocol work is done. But, I didn't think that was the > direction the chairs intended us to go. > > I'm actually very happy to start talking about how we > can very easily implement policies based on XACML. And, I feel quite > comfortable in saying that the high level concepts in the framework > don't seem to cause any problems if that is selected. > > [/MB] > > > And, it should be clear that the policy mechanism is not defined in > this > > document and will be defined in another document, either as part of > the > > protocol document or a separate document. For the record, I am > opposed > > to this WG deciding at this time to work on a separate policy > document. > > I think the work plan of completing the data model and then working > out > > the details of the Conference Control Protocol should be worked, as I > > think the policy may be dependent upon the protocol choice. > > I am afraid I do not fully understand the work plan you propose in the > paragraph above. Could you please clarify it for me? > [MB] My concern is that the group will rathole if we decide to go off > and define a policy control framework for the data model before we agree > the protocol for the conference control based on that data model. I > think once the group can agree a conference control protocol, the policy > approach might well be a straightforward choice of selecting something > that's already been developed. > [/MB] > > > > The text I need to remove from the framework would be around policy > > information being an integral part of the data model. I think the > > general consensus seems to be that they are not. Folks, please speak > up > > now if you disagree with this point. > > I believe we have consensus on working on the policy issues in a > different Internet Draft. However, such an internet draft may very well > define policy elements that are an extension of the data model. In that > case, policies would indeed be part of the data model (they would > actually be an extension of the data model). > [MB] I think we had consensus to not work on policy in the data model > and to not work on policy in the framework. However, my point above, I > think it's pre-mature for this group to start working a policy model. > Per the point above, I understood the work plan for this working group > to be to work on the protocol once we completed the data model. > [/MB] > > If by "integral part" you mean that they are defined as part of the data > > model and not as an extension, then I agree with your statement. > [MB] Yes, on this one point, we agree. [/MB] > > > I'll proposed the detailed text changes in a separate email in case > > folks what to debate this general topic further. And, it would be good > > for some other voices to chime in with opinions. > > Yes, it would be great to hear different opinions. > > Cheers, > > Gonzalo > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Apr 30 15:26:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HibW7-0006nY-OK; Mon, 30 Apr 2007 15:26:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HibW6-0006nS-LI for xcon@ietf.org; Mon, 30 Apr 2007 15:26:34 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HibW6-0007vo-3E for xcon@ietf.org; Mon, 30 Apr 2007 15:26:34 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3UJQWI18774 for ; Mon, 30 Apr 2007 19:26:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Apr 2007 14:26:31 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detailed FW changes to remove references to policy in data model Thread-Index: AceLXXTawrqFtIdLQWG+Zx70XijwvQ== From: "Mary Barnes" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Subject: [XCON] Detailed FW changes to remove references to policy in data model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0371074542==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0371074542== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78B5D.74E60A8E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78B5D.74E60A8E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Per the email thread on "Removing policies from the framework document (and data model)" earlier today,=20 the following are the detailed changes I would propose to the framework to remove the references to policy being an integral part of the data model, but keeping the concept of policy in informational terms for discussion within the framework document: Section 5:=20 OLD:=20 "The centralized conferencing data model defined in this framework has no strict separation between conference membership, conference media information and the related policies. The policies are an integral part of the data model and are realized by local, system level boundaries associated with specific data elements, such as the membership, and by the ranges and limitations on other data elements. Additional policy considerations for a system realization based on this data model are discussed in Section 5.2. The integration of the data in this model meets the requirement of many conference control operations to enable synchronized access to the integral conference policies, to the conference state as a whole, and for receiving notifications about changes to either using the same interface." NEW:=20 "Along with the basic data model as defined in [17], the realization of this framework requires=20 a policy infrastructure. The policies required by this framework to manage and=20 control access to the data include local, system level boundaries associated with specific data elements, such as the membership, and by the ranges and limitations of other data elements.=20 Additional policy considerations for a system realization based on this data model are discussed in Section 5.2." =20 Section 5.2: OLD:=20 Conference policies collectively refers to a set of rights, permissions and limitations pertaining to operations being performed on a certain conference object. The set of rights describes the read/write access privileges for the conference object as a whole. This access would usually be granted and defined in terms of giving the read-only or read-write access to clients with certain roles in the conference. As such, the policies represented by the set of rights aren't explicitly defined within the data model, but rather are reflected in the system realization (Section 7). The permissions and limits, however, are specified as an integral part of the conference object type, with data objects containing the allowed ranges for other data objects (e.g., maximum number of participants) and lists of clients allowed to perform certain operations on a conference object. For example, the "allowed-users- list" of participants is consulted to decide who is allowed to join. The entries in the list can specify the identity of an individual user (joe@example.com), a role, a domain (*@example.com), etc. For further details, refer to the detailed data model [17]. A more general rule mechanism, beyond the functionality provided by the permissions and limits, is an item for future study. NEW:=20 Conference policies collectively refers to a set of rights, permissions and limitations pertaining to operations being performed on a certain conference object. The set of rights describes the read/write access privileges for the conference object as a whole. This access would usually be granted and defined in terms of giving the read-only or read-write access to clients with certain roles in the conference. Managing this access=20 would require a conferencing system have access to basic policy information=20 to make the decisions, but doesn't necessarily require an explicit representation in the policy model. As such, for this framework document, the policies=20 represented by the set of rights are reflected in the system realization (Section 7). The permissions and limits require explicit policy mechanisms and are outside the scope of the data model [17] and this framework document.=20 Section 7: OLD: As discussed in Section 5.2, there are conference policies implicit in and derivable from the data in the conference objects and there are also policies applying to the conference objects as a whole. In the examples in this section, these latter policies are shown logically associated with the conference objects, however, it is an implementation specific mechanism as to how these policies are managed and applied to the conference objects. NEW:=20 As discussed in Section 5.2, there are conference policies applicable to specific=20 data in the conference objects and there are also policies applying to the conference objects as a whole. In the examples in this section, the policies are shown logically associated with the conference objects, however, it is an implementation specific mechanism and out of scope for this framework document,=20 as to how these policies are managed and applied to the conference objects. Mary H. Barnes mary.barnes@nortel.com ------_=_NextPart_001_01C78B5D.74E60A8E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Detailed FW changes to remove references to policy in data = model

Per the email thread on "Removing = policies from the framework document (and data model)" earlier = today,
the following are the detailed changes = I would propose to the framework to remove the references to policy = being an integral part of the data model, but keeping the concept of = policy in informational terms for discussion within the framework = document:

Section 5:
OLD:
  "The centralized = conferencing data model defined in this framework has
   no strict separation = between conference membership, conference media
   information and the = related policies.  The policies are an integral
   part of the data model = and are realized by local, system level
   boundaries associated = with specific data elements, such as the
   membership, and by the = ranges and limitations on other data elements.
   Additional policy = considerations for a system realization based on
   this data model are = discussed in Section 5.2.  The integration of the
   data in this model meets = the requirement of many conference control
   operations to enable = synchronized access to the integral conference
   policies, to the = conference state as a whole, and for receiving
   notifications about = changes to either using the same interface."

NEW:
  "Along with the basic data = model as defined in [17], the realization of this framework requires =
   a policy = infrastructure.  The policies required by this framework to manage = and
   control access to the = data include local, system level boundaries associated with = specific
   data elements, such as = the membership, and by the ranges and limitations of other data = elements.
   Additional policy = considerations for a system realization based on
   this data model are = discussed in Section 5.2." 

Section 5.2:
OLD:
   Conference policies = collectively refers to a set of rights,
   permissions and = limitations pertaining to operations being performed
   on a certain conference = object.

   The set of rights = describes the read/write access privileges for the
   conference object as a = whole.  This access would usually be granted
   and defined in terms of = giving the read-only or read-write access to
   clients with certain = roles in the conference.  As such, the policies
   represented by the set of = rights aren't explicitly defined within the
   data model, but rather = are reflected in the system realization
   (Section 7).

   The permissions and = limits, however, are specified as an integral
   part of the conference = object type, with data objects containing the
   allowed ranges for other = data objects (e.g., maximum number of
   participants) and lists = of clients allowed to perform certain
   operations on a = conference object.  For example, the "allowed-users-
   list" of = participants is consulted to decide who is allowed to join.
   The entries in the list = can specify the identity of an individual
   user (joe@example.com), a = role, a domain (*@example.com), etc.  For
   further details, refer to = the detailed data model [17].

   A more general rule = mechanism, beyond the functionality provided by
   the permissions and = limits, is an item for future study.

NEW:
   Conference policies = collectively refers to a set of rights,
   permissions and = limitations pertaining to operations being performed
   on a certain conference = object.

   The set of rights = describes the read/write access privileges for the
   conference object as a = whole.  This access would usually be granted
   and defined in terms of = giving the read-only or read-write access to
   clients with certain = roles in the conference.  Managing this access
   would require a = conferencing  system have access to basic policy information =
   to make the decisions, = but doesn't necessarily require an explicit representation
   in the policy = model.  As such, for this framework document, the policies
   represented by the set of = rights are reflected in the system realization (Section 7).

   The permissions and limits = require explicit policy mechanisms
   and are outside the scope = of the data model [17] and this framework document.

Section 7:
OLD:
   As discussed in Section = 5.2, there are conference policies implicit
   in and derivable from the = data in the conference objects and there
   are also policies = applying to the conference objects as a whole.  In
   the examples in this = section, these latter policies are shown
   logically associated with = the conference objects, however, it is an
   implementation specific = mechanism as to how these policies are
   managed and applied to = the conference objects.

NEW:
   As discussed in Section = 5.2, there are conference policies applicable to specific
   data in the conference = objects and there
   are also policies = applying to the conference objects as a whole.  In
   the examples in this = section, the policies are shown
   logically associated with = the conference objects, however, it is an
   implementation specific = mechanism and out of scope for this framework document,
   as to how these policies = are managed and applied to the conference objects.


Mary H. Barnes
mary.barnes@nortel.com

------_=_NextPart_001_01C78B5D.74E60A8E-- --===============0371074542== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0371074542==-- From xcon-bounces@ietf.org Mon Apr 30 22:15:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hihu5-000378-Q5; Mon, 30 Apr 2007 22:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hihu5-000373-4t for xcon@ietf.org; Mon, 30 Apr 2007 22:15:45 -0400 Received: from mail44.opentransfer.com ([76.162.254.44]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hihu4-0006ge-On for xcon@ietf.org; Mon, 30 Apr 2007 22:15:45 -0400 Received: (qmail 23924 invoked by uid 399); 1 May 2007 02:15:43 -0000 Received: from unknown (HELO ?192.168.0.40?) (24.107.197.43) by mail44.opentransfer.com with SMTP; 1 May 2007 02:15:43 -0000 Message-ID: <4636A2CC.8080802@sipstation.com> Date: Mon, 30 Apr 2007 21:15:40 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Mary Barnes Subject: Re: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Gonzalo Camarillo , xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Our working group charter lists the framework as a PS, not informational, and we did discuss it in Prague and agree to do that. I do recall that in the SIPPING conferencing work, we ended up making the conference framework document informational and the cc-conferencing a BCP. We could do something similar as Mary points out below. A question - does the working group believe that implementors can just read BFCP, the common data model, the event package extension, and the future conference control protocol documents and be able to implement without reading the framework? If so, that suggests the framework can be informational. If not, if there is significant overall detail in the framework, then we should not make it informational for the sake of implementors. Thanks, Alan Mary Barnes wrote: > I don't think we need a BCP right now for the flows, but once we decide > the Conference Control Protocol, I think a BCP with flows (e.g., taking > some of the examples in the framework down to another level of detail) > would be very useful. > > Mary > > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Monday, April 30, 2007 11:42 AM > To: Barnes, Mary (RICH2:AR00) > Cc: xcon@ietf.org > Subject: Re: Comments on draft-ietf-xcon-framework-07.txt > > > Hi, > > sure, getting guidance from the chairs on the intended status would be > great. > > >> I don't have any issue with changing this to informational, although, >> having the musts, shoulds all being in examples highlights perhaps the >> need to have a call flow BCP type document. >> > > The protocol specs (e.g., SIP, BFCP) already specify the interactions > between nodes in the context of those protocols. A BCP along the lines > you describe would be useful if the interactions between different > protocols would be particularly complicated (e.g., which SIP message to > send when a conference is terminated through the conference control > protocol). However, I do not think the inter-protocol interactions we > are dealing with in XCON are complicated enough to grant yet another > specification. Or do you have a few scenarios in mind that may be > difficult to understand for an implementer without a document with > examples? > > Cheers, > > Gonzalo > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon