From mailman-bounces@core3.amsl.com Fri Feb 1 06:37:55 2008 Return-Path: X-Original-To: ietfarch-xcon-archive@core3.amsl.com Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A38028E8DD for ; Fri, 1 Feb 2008 06:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-Ab4RHzUY3K for ; Fri, 1 Feb 2008 06:37:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5E532A3FAE for ; Fri, 1 Feb 2008 06:12:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: xcon-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:08:34 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/xcon/xcon-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:38:05 2008 Return-Path: X-Original-To: ietfarch-xcon-archive@core3.amsl.com Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763CC293080 for ; Fri, 1 Feb 2008 06:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpltHzqV02PY for ; Fri, 1 Feb 2008 06:38:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 013812A3F77 for ; Fri, 1 Feb 2008 06:12:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: xcon-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:08:33 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/xcon/xcon-archive%40megatron.ietf.org From xcon-bounces@ietf.org Mon Feb 11 13:22:13 2008 Return-Path: X-Original-To: ietfarch-xcon-archive@core3.amsl.com Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D07528C3C8; Mon, 11 Feb 2008 13:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.903 X-Spam-Level: X-Spam-Status: No, score=-2.903 tagged_above=-999 required=5 tests=[AWL=-2.466, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdWrrSCf9CTJ; Mon, 11 Feb 2008 13:22:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2AC28C29F; Mon, 11 Feb 2008 13:22:12 -0800 (PST) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DE1228C29F for ; Mon, 11 Feb 2008 13:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOBxB+iHLfCM for ; Mon, 11 Feb 2008 13:22:10 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BCE1328C296 for ; Mon, 11 Feb 2008 13:22:09 -0800 (PST) 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 m1BLJT927602; Mon, 11 Feb 2008 21:19:30 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Feb 2008 15:21:01 -0600 Message-ID: In-Reply-To: <4BF43B706DBF0D4486F805D8DA0F34AB08730153@zcp4hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on: http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-08 Thread-Index: AchdFcvb2HMPsY1LR6i81QH8SxrhSQMtYY7AACit/zAAAgqzAA== References: <4BF43B706DBF0D4486F805D8DA0F34AB0840AEBC@zcp4hxm0.corp.nortel.com> <4BF43B706DBF0D4486F805D8DA0F34AB08730153@zcp4hxm0.corp.nortel.com> From: "Mary Barnes" To: "Oscar Novo" Cc: Pierre Tane , XCON-IETF Subject: [XCON] Comments on: http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-08 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Hi Oscar, We (including my colleague Pierre Tane, whose cc'ed) reviewed the document and have a few comments on the -08 version, with a few comments relating to changes introduced in the -07 (Sx/Py means Section x, Page y). Overall, the document is in good shape and is almost done. I've divided the comments into comments/issues versus nits, with the nits at the end: Comments/issues: ---------------- 1) Floor control. The document seems to mandate BFCP as the floor control protocol, however, per the XCON FW, BFCP is just one possible choice for the floor control protocol. The following areas are ones we noted need changes to reflect this (there may be others): - S4.5.1/p1 it states "The is a 32-bit BFCP conference identifier defined in [RFC4582] section 5.1." That whole section needs to be changed to something like the following and noting that the schema would also be impacted: OLD: The is a 32-bit BFCP conference identifier defined in [RFC4582] section 5.1. that identifies the BFCP conference the message belongs to. This identifier represents a conference instance within floor control. When created within the conferencing system, the 'conference-ID' has a 1:1 mapping to the unique conference object Identifier (XCON-URI). NEW: The represents a conference instance within floor control. When created within the conferencing system, the 'conference-ID' can be represented by the unique conference object Identifier (XCON-URI). When BFCP serves as the floor control protocol, the is a 32-bit BFCP conference identifier defined in [RFC4582] section 5.1 and there is a 1:1 mapping to the XCON-URI. - S4.5.2 The SIP + BFCP parameters should be options when the FCP is actually BFCP to retain flexibility for other FCPs to be bound to a XCON conferencing server. - S4.5.4., the third sentence needs rewording, along with the description of the : OLD: The 'id' attribute corresponds to the floor-id identifier defined in [RFC4582] section 5.2.2. NEW: In the case of BFCP [RFC4582], the 'id' attribute corresponds to the floor-id identifier defined in [RFC4582] section 5.2.2. OLD: : The optional indicates the 'User ID' of the moderator. The 'User ID' is a BFCP identifier defined in [RFC4582] section 5.1. It MUST be set if the element is set to "Moderator-controlled" value. Note that [RFC4582] refers to the moderator role as a 'floor chair'. NEW: : The optional indicates the 'User ID' of the moderator. It MUST be set if the element is set to "Moderator-controlled" value. When the floor is created within the conferencing system, the XCON-User identifier MAY be used as the moderator-id. In the case of BFCP as the floor control protocol, the is defined in [RFC4582] section 5.1. Note that [RFC4582] refers to the moderator role as a 'floor chair'. 2) XCON-URI - S.9.3. My understanding is that you need more detail in this section per RFC 4395 (Guidelines and Registration Schemas for URIs): e.g., Encoding considerations, Interoperatbility, security, contact, author, references etc. 3) XCON_USERID. 3a) General nit: Can we consistently name these identifiers with either "-" or "_". I am forever having to look at what they're called in the document (and I realize this is a nit you inherited)? 3b) S.4.6.5, p24. The schema for the XCON_USERID seems to be a cut and paste error from the XCON-URI or I'm really confused (i.e., the type is defined using a "conf-object-id"). In the past (i.e., when we had a lot of this text in the XCON FW and a separate document), the XCON_USERID was just a unique identifier and not a URI itself. It was used by the conferencing system to map to other user identifiers , but not necessarily other URIs - e.g., BFCP User ID which is an integer and in the past the SIP example was the digest name and not the SIP URI. So, I'm wondering if we really need to register a URI schema? Another concern is that the FW has the concept of a specific user having multiple XCON_USERIDs within a given conferencing system to accommodate different roles. As well, users that aren't actively part of a conference (and may have no other signaling identifier) also need Conference User Identifiers to be assigned. The current definition in section 4.6.5 states that "the element ... describes a single participant in a conference", but the XCON framework provides a far broader definition, since we allow users to manipulate the conference using non-signaling means. Some of the subsequent text is fine, I'm just wondering if it wouldn't be useful to introduce the XCON_USERID earlier in the document (e.g., section 3), since its use is broader than that element in the data model. Some of this gets to the "persistence" discussion we had, since this user information would need to be maintained by a conferencing system outside the scope of active conferences or any conference object for that matter. 3c) S4.6.3/p23 Why is there a mandatory e-mail address for a user? It seems rather odd to put such a stress on e-mail where a phone number or any other sorts of identifier may be valid means of addressing a user. 3d) S.9.4. Related to 3b), if a new URI schema is defined, per my comment on S.9.3, there is additional detail required in this section. 4) S4.6.5.3/p24 The framework introduces both the concept of anonymous and the idea of a hidden participant. It's not clear to me we have everything we need to accomplish the latter. Is that the intent of the value of 'private' versus the 'semi-private'? In other words, can we also say that a 'private' user would not even appear as an "anonymous" participant if another participant were to query the user list? Or, is the current text saying, for example, that a moderator that has higher permissions would be able to see the names of all the other participants, but the average user would not? If so, then perhaps we need three levels for the and have a 'hidden' value meaning that the user isn't visible to anyone in the conference. Or, do we want to suggest that a combination of 'private' and a "role" of "observer" would result in a 'hidden' participant? Nits: ------- 1) S1/P4 Figure 1 There is a mistake as the schema which is otherwise quite generic is mentioning "Binary Floor Control Protocol" where it shall say "Floor Control Protocol" as BFCP (RFC4582) is but one of the alternatives for a Floor Control Protocol as mentioned in S1/P3 in the paragraph that describes Figure 1. S3.3.1/P8 "Conference URI Definition" The XCON-URI gets referred to as Conference Object Identifier throughout section 3, it would be better for consistency for section 3.3.1 to be explicitly named "Conference Object URI Definition". 2) S4.1/p12 Change "this" to "these" and "notification" to "notifications" per the following: OLD: Note that the element does not have the attributes 'state' and 'version' defined in [RFC4575] for this element because this attribute only applies to notifications mechanism. NEW: Note that the element does not have the attributes 'state' and 'version' defined in [RFC4575] for this element because these attributes only apply to notification mechanisms. 3) S4.2.1/p13 Second sentence in the following needs clarification: OLD: The element indicates the predominant language that is expected to be employed within a conference. This element is not enforcing the language of the conference, only informs to the participants about the desirable language that they should used in the conference. Participants are free to switch to other languages if they like. NEW: The element indicates the predominant language that is expected to be employed within a conference. This element is not enforcing the language of the conference, but only informs the participants about the desirable language that they should use in the conference. Participants are free to switch to other languages if they like. _______________________________________________ XCON mailing list XCON@ietf.org http://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Feb 15 09:30:19 2008 Return-Path: X-Original-To: ietfarch-xcon-archive@core3.amsl.com Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00CA73A68D3; Fri, 15 Feb 2008 09:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4sgj1CoyEmR; Fri, 15 Feb 2008 09:30:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13EAD28D1EE; Fri, 15 Feb 2008 09:30:18 -0800 (PST) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA3F328D23A for ; Fri, 15 Feb 2008 09:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7ka2f+gfYyx for ; Fri, 15 Feb 2008 09:30:16 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2EB2128D19B for ; Fri, 15 Feb 2008 09:30:14 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D2BAB20423; Fri, 15 Feb 2008 18:31:33 +0100 (CET) X-AuditID: c1b4fb3e-a99fdbb000000b15-62-47b5cc751144 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B65FA20271; Fri, 15 Feb 2008 18:31:33 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 18:31:33 +0100 Received: from [131.160.126.36] ([131.160.126.36]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 18:31:32 +0100 Message-ID: <47B5CC74.2060609@ericsson.com> Date: Fri, 15 Feb 2008 19:31:32 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Even, Roni" References: <144ED8561CE90C41A3E5908EDECE315C054C1721@IsrExch01.israel.polycom.com> <47A0CAB6.6080003@ericsson.com> In-Reply-To: <47A0CAB6.6080003@ericsson.com> X-OriginalArrivalTime: 15 Feb 2008 17:31:32.0913 (UTC) FILETIME=[9B5C0210:01C86FF8] X-Brightmail-Tracker: AAAAAA== Cc: XCON Subject: Re: [XCON] Partial notifications for the XCON event package X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Hi Roni, I never got an answer from my email below. In any case, I have talked to Oscar, and he is OK with defining a new MIME type. I will edit the draft accordingly. I will be submitting the draft before the 00 cut-off. Cheers, Gonzalo Gonzalo Camarillo wrote: > Hi Roni, > > I am not arguing either way. I just want to understand the issues > involved before we make a decision. Can you elaborate on the size > problem you hint at below? What is the actual problem you have in mind? > > Thanks, > > Gonzalo > > Even, Roni wrote: >> Gonzalo, >> It is not only a bandwidth problem. It is also a size problem (big >> conferences). So why not keep the two different MIME types as in the >> current draft >> Roni >> >>> -----Original Message----- >>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>> Sent: Wednesday, January 30, 2008 7:12 PM >>> To: Even, Roni >>> Cc: Oscar Novo; XCON >>> Subject: Re: [XCON] Partial notifications for the XCON event package >>> >>> Hi Roni, >>> >>> the problem with reusing the old MIME type for full XCON notifications >>> is that a server may send notifications with a set of XML elements the >>> legacy client will not understand (i.e., the new elements defined by the >>> XCON data model). The client will ignore them and everything will work >>> fine. However, bandwidth will be wasted because all those new elements >>> will be transmitted to simply be ignored at their destination. Do you >>> see any other problem in addition to this bandwidth problem? >>> >>> Thanks, >>> >>> Gonzalo >>> >>> Even, Roni wrote: >>>> Gonzalo, >>>> The concern was that the server needs to allow SIPPING client >>>> supporting >>> the current event package and XCON client supporting the new data >>> structure to receive notifications. >>>> The full notification will be different for the two cases since there >>> are different data models. So my view is that you need two different >>> types >>> enabling to request full notification for SIPPING and for XCON users >>>> >>>> Roni >>>> >>>>> -----Original Message----- >>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>> Sent: Wednesday, January 30, 2008 7:00 PM >>>>> To: Oscar Novo >>>>> Cc: XCON >>>>> Subject: Re: [XCON] Partial notifications for the XCON event package >>>>> >>>>> Hi, >>>>> >>>>> the current event package draft has a whole section explaining why a >>> new >>>>> MIME type is needed. The reason it gives is the presence of state >>>>> attributes in new elements. However, if we do not define new state >>>>> attributes by use xml patch operations instead, we could reuse the old >>>>> MIME type, as you suggest. Of course, we would need to define a new >>>>> one >>>>> for partial notifications based on xml patch operations. >>>>> >>>>> Does anybody else have an opinion on this issue? >>>>> >>>>> Cheers, >>>>> >>>>> Gonzalo >>>>> >>>>> >>>>> Oscar Novo wrote: >>>>>> Yes, I believe we should use the same MIME type as in RFC4575 and a >>>>>> different MIME type for the 'xml patch operation' option. >>>>>> >>>>>> Oscar >>>>>> >>>>>>> what do you exactly mean by "100% backward compatible"? Do you mean >>>>> that >>>>>>> we should be using the same MIME type as in RFC 4575? >>>>>>> >>>>>>> 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 > _______________________________________________ XCON mailing list XCON@ietf.org http://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Feb 15 23:49:36 2008 Return-Path: X-Original-To: ietfarch-xcon-archive@core3.amsl.com Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B76528C0DC; Fri, 15 Feb 2008 23:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nY-Ncy5F91H1; Fri, 15 Feb 2008 23:49:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AEF33A692E; Fri, 15 Feb 2008 23:49:34 -0800 (PST) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991F03A68CA for ; Fri, 15 Feb 2008 23:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7v2POvIiH9Zb for ; Fri, 15 Feb 2008 23:49:31 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id ABA8E3A6945 for ; Fri, 15 Feb 2008 23:49:26 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A739021375; Sat, 16 Feb 2008 08:49:24 +0100 (CET) X-AuditID: c1b4fb3e-aa1febb000000b15-59-47b695847b55 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8B987212F6; Sat, 16 Feb 2008 08:49:24 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 08:49:24 +0100 Received: from [131.160.126.26] ([131.160.126.26]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 08:49:24 +0100 Message-ID: <47B69584.5050704@ericsson.com> Date: Sat, 16 Feb 2008 09:49:24 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: XCON References: <144ED8561CE90C41A3E5908EDECE315C054C1721@IsrExch01.israel.polycom.com> <47A0CAB6.6080003@ericsson.com> <47B5CC74.2060609@ericsson.com> In-Reply-To: <47B5CC74.2060609@ericsson.com> X-OriginalArrivalTime: 16 Feb 2008 07:49:24.0171 (UTC) FILETIME=[729EB1B0:01C87070] X-Brightmail-Tracker: AAAAAA== Cc: "Even, Roni" Subject: Re: [XCON] Partial notifications for the XCON event package X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Folks, I have just submitted a new version of the event package draft. Until it appears in the archives (00 submissions of WG items require chair approval), you can fetch it from: http://www.ietf.org/proceedings/staging/draft-ietf-xcon-event-package-00.txt Cheers, Gonzalo Gonzalo Camarillo wrote: > Hi Roni, > > I never got an answer from my email below. In any case, I have talked to > Oscar, and he is OK with defining a new MIME type. I will edit the draft > accordingly. I will be submitting the draft before the 00 cut-off. > > Cheers, > > Gonzalo > > Gonzalo Camarillo wrote: >> Hi Roni, >> >> I am not arguing either way. I just want to understand the issues >> involved before we make a decision. Can you elaborate on the size >> problem you hint at below? What is the actual problem you have in mind? >> >> Thanks, >> >> Gonzalo >> >> Even, Roni wrote: >>> Gonzalo, >>> It is not only a bandwidth problem. It is also a size problem (big >>> conferences). So why not keep the two different MIME types as in the >>> current draft >>> Roni >>> >>>> -----Original Message----- >>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>> Sent: Wednesday, January 30, 2008 7:12 PM >>>> To: Even, Roni >>>> Cc: Oscar Novo; XCON >>>> Subject: Re: [XCON] Partial notifications for the XCON event package >>>> >>>> Hi Roni, >>>> >>>> the problem with reusing the old MIME type for full XCON notifications >>>> is that a server may send notifications with a set of XML elements the >>>> legacy client will not understand (i.e., the new elements defined by the >>>> XCON data model). The client will ignore them and everything will work >>>> fine. However, bandwidth will be wasted because all those new elements >>>> will be transmitted to simply be ignored at their destination. Do you >>>> see any other problem in addition to this bandwidth problem? >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> Even, Roni wrote: >>>>> Gonzalo, >>>>> The concern was that the server needs to allow SIPPING client >>>>> supporting >>>> the current event package and XCON client supporting the new data >>>> structure to receive notifications. >>>>> The full notification will be different for the two cases since there >>>> are different data models. So my view is that you need two different >>>> types >>>> enabling to request full notification for SIPPING and for XCON users >>>>> Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>>> Sent: Wednesday, January 30, 2008 7:00 PM >>>>>> To: Oscar Novo >>>>>> Cc: XCON >>>>>> Subject: Re: [XCON] Partial notifications for the XCON event package >>>>>> >>>>>> Hi, >>>>>> >>>>>> the current event package draft has a whole section explaining why a >>>> new >>>>>> MIME type is needed. The reason it gives is the presence of state >>>>>> attributes in new elements. However, if we do not define new state >>>>>> attributes by use xml patch operations instead, we could reuse the old >>>>>> MIME type, as you suggest. Of course, we would need to define a new >>>>>> one >>>>>> for partial notifications based on xml patch operations. >>>>>> >>>>>> Does anybody else have an opinion on this issue? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> >>>>>> Oscar Novo wrote: >>>>>>> Yes, I believe we should use the same MIME type as in RFC4575 and a >>>>>>> different MIME type for the 'xml patch operation' option. >>>>>>> >>>>>>> Oscar >>>>>>> >>>>>>>> what do you exactly mean by "100% backward compatible"? Do you mean >>>>>> that >>>>>>>> we should be using the same MIME type as in RFC 4575? >>>>>>>> >>>>>>>> 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 >> > > _______________________________________________ > XCON mailing list > XCON@ietf.org > http://www.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org http://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Feb 18 11:40:12 2008 Return-Path: X-Original-To: ietfarch-xcon-archive@core3.amsl.com Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83EE128C5AA; Mon, 18 Feb 2008 11:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nrjLIBJ-pDk; Mon, 18 Feb 2008 11:40:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0FF728C5AC; Mon, 18 Feb 2008 11:39:25 -0800 (PST) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17A428C599 for ; Mon, 18 Feb 2008 11:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CguLlTGLEDJ for ; Mon, 18 Feb 2008 11:39:23 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 07C593A6D72 for ; Mon, 18 Feb 2008 11:36:46 -0800 (PST) Received: from sparc108.santera.com (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m1IJaYKw076132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 13:36:34 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <47B9DE45.7030803@nostrum.com> Date: Mon, 18 Feb 2008 13:36:37 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gonzalo Camarillo References: <47974D37.3070508@ericsson.com> <47A04B9F.2000005@ericsson.com> <1201692445.6497.11.camel@oscar630.nomadiclab.com> <47A05FEA.2010607@ericsson.com> <1201697000.6497.36.camel@oscar630.nomadiclab.com> <47A0AD06.6090905@ericsson.com> In-Reply-To: <47A0AD06.6090905@ericsson.com> Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.92/5869/Mon Feb 18 11:42:54 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: XCON Subject: Re: [XCON] Partial notifications for the XCON event package X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org On 1/30/08 10:59 AM, Gonzalo Camarillo wrote: > the current event package draft has a whole section explaining why a > new MIME type is needed. The reason it gives is the presence of state > attributes in new elements. However, if we do not define new state > attributes by use xml patch operations instead, we could reuse the old > MIME type, as you suggest. Of course, we would need to define a new > one for partial notifications based on xml patch operations. > > Does anybody else have an opinion on this issue? Sorry for the slow response on this topic -- the document landed in the right place, but I wanted to remind everyone that one of the key reasons we're using a new MIME type is because the apps-area MIME experts suggested that such a change is warranted due to our moving from Schema to Relax NG. If we decide to open the question again, we'll need to make sure the proper apps people are involved in the conversation. /a _______________________________________________ XCON mailing list XCON@ietf.org http://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Feb 18 11:48:10 2008 Return-Path: X-Original-To: ietfarch-xcon-archive@core3.amsl.com Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336B73A6824; Mon, 18 Feb 2008 11:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rx8UzVy6+DFN; Mon, 18 Feb 2008 11:48:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E5D3A6D85; Mon, 18 Feb 2008 11:45:34 -0800 (PST) X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 033E728C69B; Mon, 18 Feb 2008 11:45:06 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080218194507.033E728C69B@core3.amsl.com> Date: Mon, 18 Feb 2008 11:45:06 -0800 (PST) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-event-package-00.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org 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 Event Package Data Format Extension for Centralized Conferencing (XCON) Author(s) : G. Camarillo, et al. Filename : draft-ietf-xcon-event-package-00.txt Pages : 14 Date : 2008-02-15 This document specifies the notification mechanism for XCON (centralized conferencing). This mechanism reuses the SIP (Session Initiation Protocol) event package for conference state. Additionally, the notification mechanism includes support for the XCON data model and for partial notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-event-package-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-ietf-xcon-event-package-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-ietf-xcon-event-package-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. --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: <2008-02-18114045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-event-package-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-event-package-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-18114045.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 http://www.ietf.org/mailman/listinfo/xcon --NextPart-- From xcon-bounces@ietf.org Mon Feb 18 12:39:52 2008 Return-Path: X-Original-To: ietfarch-xcon-archive@core3.amsl.com Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1807528C6A9; Mon, 18 Feb 2008 12:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.968 X-Spam-Level: X-Spam-Status: No, score=-0.968 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw7fbuK5zm+X; Mon, 18 Feb 2008 12:39:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0870B3A6D7D; Mon, 18 Feb 2008 12:38:32 -0800 (PST) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E733A6D74 for ; Mon, 18 Feb 2008 12:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8skHM3HY7GHi for ; Mon, 18 Feb 2008 12:38:30 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D220E28C4AA for ; Mon, 18 Feb 2008 12:36:04 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2E1C1212C8; Mon, 18 Feb 2008 21:36:01 +0100 (CET) X-AuditID: c1b4fb3e-aa1febb000000b15-d3-47b9ec3119f1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 257BD210CA; Mon, 18 Feb 2008 21:36:01 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 21:34:36 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 21:34:36 +0100 Received: from [131.160.126.51] (rvi2-126-51.lmf.ericsson.se [131.160.126.51]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 824F82403; Mon, 18 Feb 2008 22:34:36 +0200 (EET) Message-ID: <47B9EBDC.4040103@ericsson.com> Date: Mon, 18 Feb 2008 22:34:36 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Adam Roach References: <47974D37.3070508@ericsson.com> <47A04B9F.2000005@ericsson.com> <1201692445.6497.11.camel@oscar630.nomadiclab.com> <47A05FEA.2010607@ericsson.com> <1201697000.6497.36.camel@oscar630.nomadiclab.com> <47A0AD06.6090905@ericsson.com> <47B9DE45.7030803@nostrum.com> In-Reply-To: <47B9DE45.7030803@nostrum.com> X-OriginalArrivalTime: 18 Feb 2008 20:34:36.0501 (UTC) FILETIME=[AD53C850:01C8726D] X-Brightmail-Tracker: AAAAAA== Cc: XCON Subject: Re: [XCON] Partial notifications for the XCON event package X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Hi Adam, the current draft (00) defines such a new MIME type. So, we should be OK. Cheers, Gonzalo Adam Roach wrote: > On 1/30/08 10:59 AM, Gonzalo Camarillo wrote: >> the current event package draft has a whole section explaining why a >> new MIME type is needed. The reason it gives is the presence of state >> attributes in new elements. However, if we do not define new state >> attributes by use xml patch operations instead, we could reuse the old >> MIME type, as you suggest. Of course, we would need to define a new >> one for partial notifications based on xml patch operations. >> >> Does anybody else have an opinion on this issue? > > Sorry for the slow response on this topic -- the document landed in the > right place, but I wanted to remind everyone that one of the key reasons > we're using a new MIME type is because the apps-area MIME experts > suggested that such a change is warranted due to our moving from Schema > to Relax NG. If we decide to open the question again, we'll need to make > sure the proper apps people are involved in the conversation. > > /a _______________________________________________ XCON mailing list XCON@ietf.org http://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Feb 22 06:33:02 2008 Return-Path: X-Original-To: ietfarch-xcon-archive@core3.amsl.com Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7543A6CA7; Fri, 22 Feb 2008 06:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_35=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWFIkmAWIn59; Fri, 22 Feb 2008 06:33:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F6928C1D4; Fri, 22 Feb 2008 06:32:55 -0800 (PST) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4303D3A68B5 for ; Fri, 22 Feb 2008 06:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LPixYz7B7EN for ; Fri, 22 Feb 2008 06:32:53 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 034433A6C6A for ; Fri, 22 Feb 2008 06:31:49 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E64BF20B05; Fri, 22 Feb 2008 15:31:43 +0100 (CET) X-AuditID: c1b4fb3c-b00bfbb000007e19-95-47bedccf1a91 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C3682209F4; Fri, 22 Feb 2008 15:31:43 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 15:31:43 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 15:31:43 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1EEE22461; Fri, 22 Feb 2008 16:31:43 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A4DF04DC65; Fri, 22 Feb 2008 16:31:42 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 38E624DC64; Fri, 22 Feb 2008 16:31:42 +0200 (EET) From: Oscar Novo To: Mary Barnes In-Reply-To: References: <4BF43B706DBF0D4486F805D8DA0F34AB0840AEBC@zcp4hxm0.corp.nortel.com> <4BF43B706DBF0D4486F805D8DA0F34AB08730153@zcp4hxm0.corp.nortel.com> Date: Fri, 22 Feb 2008 16:33:04 +0200 Message-Id: <1203690784.6853.32.camel@oscar630.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 22 Feb 2008 14:31:43.0181 (UTC) FILETIME=[A511CFD0:01C8755F] X-Brightmail-Tracker: AAAAAA== Cc: Pierre Tane , XCON-IETF Subject: Re: [XCON] Comments on: http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-08 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Hello Mary and Pierre, Thanks for your comments. Some answer in line as [ON]. I'll try to submit a new version of the draft with your comments in brief. Regards, Oscar On Mon, 2008-02-11 at 15:21 -0600, Mary Barnes wrote: > Hi Oscar, > > We (including my colleague Pierre Tane, whose cc'ed) reviewed the > document and have a few comments on the -08 version, with a few > comments relating to changes introduced in the -07 (Sx/Py means Section > x, Page y). > > Overall, the document is in good shape and is almost done. > > I've divided the comments into comments/issues versus nits, with the > nits at the end: > > Comments/issues: > ---------------- > > 1) Floor control. The document seems to mandate BFCP as the floor > control protocol, however, per the XCON FW, BFCP is just one possible > choice for the floor control protocol. The following areas are ones we > noted need changes to reflect this (there may be others): > > - S4.5.1/p1 it states "The is a 32-bit BFCP conference > identifier defined in [RFC4582] section 5.1." That whole section needs > to be changed to something like the following and noting that the schema > would also be impacted: > OLD: > The is a 32-bit BFCP conference identifier defined in > [RFC4582] section 5.1. that identifies the BFCP conference the > message belongs to. This identifier represents a conference instance > within floor control. When created within the conferencing system, > the 'conference-ID' has a 1:1 mapping to the unique conference object > Identifier (XCON-URI). > NEW: > The represents a conference instance > within floor control. When created within the conferencing system, > the 'conference-ID' can be represented by the unique conference > object > Identifier (XCON-URI). When BFCP serves as the floor control > protocol, > the is a 32-bit BFCP conference identifier defined in > [RFC4582] section 5.1 and there is a 1:1 mapping to the XCON-URI. > [ON] Right, I'll fix that in the new version. > - S4.5.2 The SIP + BFCP parameters should be options when the FCP is > actually BFCP to retain flexibility for other FCPs to be bound to a XCON > conferencing server. > [ON] Well, this section specifies all the different methods a conference participant can subscribe to a FCP nowadays but this section states in the last paragraph that additional connection mechanism can be defined in the future and can be added to the data model. > - S4.5.4., the third sentence needs rewording, along with the > description of the : > > OLD: > The 'id' attribute corresponds to the floor-id identifier defined in > [RFC4582] > section 5.2.2. > NEW: > In the case of BFCP [RFC4582], the 'id' attribute corresponds to the > floor-id > identifier defined in [RFC4582] section 5.2.2. > > OLD: > : The optional indicates the 'User > ID' of the moderator. The 'User ID' is a BFCP identifier defined > in [RFC4582] section 5.1. It MUST be set if the element > is set to "Moderator-controlled" value. Note that > [RFC4582] refers to the moderator role as a 'floor chair'. > > NEW: > : The optional indicates the 'User > ID' of the moderator. It MUST be set if the element > is set to "Moderator-controlled" value. > When the floor is created within the conferencing system, the > XCON-User identifier > MAY be used as the moderator-id. In the case of BFCP as the floor > control > protocol, the is defined in [RFC4582] section 5.1. > Note that > [RFC4582] refers to the moderator role as a 'floor chair'. > > [ON] Thanks, I'll fix that. > > 2) XCON-URI > - S.9.3. My understanding is that you need more detail in this section > per RFC 4395 (Guidelines and Registration Schemas for URIs): e.g., > Encoding considerations, Interoperatbility, security, contact, author, > references etc. > > [ON] I'll introduce a bit more of information: contact, specification, subject, author... > 3) XCON_USERID. > 3a) General nit: Can we consistently name these identifiers with either > "-" or "_". I am forever having to look at what they're called in the > document (and I realize this is a nit you inherited)? [ON] I'll name both of them as "-" to be more consistent. > > > 3b) S.4.6.5, p24. The schema for the XCON_USERID seems to be a cut and > paste error from the XCON-URI or I'm really confused (i.e., the type is > defined using a "conf-object-id"). [ON] Yes, it's a cut&paste error > In the past (i.e., when we had a lot > of this text in the XCON FW and a separate document), the XCON_USERID > was just a unique identifier and not a URI itself. It was used by the > conferencing system to map to other user identifiers , but not > necessarily other URIs - e.g., BFCP User ID which is an integer and in > the past the SIP example was the digest name and not the SIP URI. So, > I'm wondering if we really need to register a URI schema? > [ON] The XCON_USERID still is used to map other user identifiers in the conference and it can be use to identify one user inside a conference. > Another concern is that the FW has the concept of a specific user having > multiple XCON_USERIDs within a given conferencing system to accommodate > different roles. > As well, users that aren't actively part of a > conference (and may have no other signaling identifier) also need > Conference User Identifiers to be assigned. The current definition in > section 4.6.5 states that "the element ... describes a single > participant in a conference", but the XCON framework provides a far > broader definition, since we allow users to manipulate the conference > using non-signaling means. Some of the subsequent text is fine, I'm > just wondering if it wouldn't be useful to introduce the XCON_USERID > earlier in the document (e.g., section 3), since its use is broader than > that element in the data model. > [ON] In the use case of a participant with multiple XCON_USERIDs different element with different XCON_USERIDs should be defined. Note as well one of the sentence in the section: "It should be noted that a conferencing system is free to structure such relationships as required and this information is just included as a guideline that can be used." > Some of this gets to the "persistence" discussion we had, since this > user information would need to be maintained by a conferencing system > outside the scope of active conferences or any conference object for > that matter. > > > 3c) S4.6.3/p23 Why is there a mandatory e-mail address for a user? It > seems rather odd to put such a stress on e-mail where a phone number or > any other sorts of identifier may be valid means of addressing a user. > [ON] This part of text is talking about chatroom systems and we think is important to have the email information of the user joining a chatroom. Note as well that the e-mail address is an optional element, not mandatory and that is possible to extend the schema in the future with more elements. > 3d) S.9.4. Related to 3b), if a new URI schema is defined, per my > comment on S.9.3, there is additional detail required in this section. > [ON] I'll add some more information in this section too. > 4) S4.6.5.3/p24 > > The framework introduces both the concept of anonymous and the idea of a > hidden participant. It's not clear to me we have everything we need to > accomplish the latter. Is that the intent of the value of 'private' > versus the 'semi-private'? In other words, can we also say that a > 'private' user would not even appear as an "anonymous" participant if > another participant were to query the user list? Or, is the current > text saying, for example, that a moderator that has higher permissions > would be able to see the names of all the other participants, but the > average user would not? If so, then perhaps we need three levels for > the and have a 'hidden' value meaning that the user > isn't visible to anyone in the conference. Or, do we want to suggest > that a combination of 'private' and a "role" of "observer" would result > in a 'hidden' participant? > [ON] I'll add a 'hidden' value to the element. > > Nits: > ------- [ON] Thanks for the nits. I'll fix all of them in the new version of the draft. > 1) S1/P4 Figure 1 > There is a mistake as the schema which is otherwise quite > generic is mentioning "Binary Floor Control Protocol" where it shall say > "Floor Control Protocol" as BFCP (RFC4582) is but one of the > alternatives for a Floor Control Protocol as mentioned in S1/P3 in the > paragraph that describes Figure 1. > > > S3.3.1/P8 "Conference URI Definition" > The XCON-URI gets referred to as Conference Object Identifier throughout > section 3, it would be better for consistency for section 3.3.1 to be > explicitly named "Conference Object URI Definition". > > 2) S4.1/p12 Change "this" to "these" and "notification" to > "notifications" per the following: > OLD: > Note that the element does not have the attributes > 'state' and 'version' defined in [RFC4575] for this element because > this attribute only applies to notifications mechanism. > NEW: > Note that the element does not have the attributes > 'state' and 'version' defined in [RFC4575] for this element because > these attributes only apply to notification mechanisms. > > 3) S4.2.1/p13 Second sentence in the following needs clarification: > OLD: > The element indicates the predominant language that is > expected to be employed within a conference. This element is not > enforcing the language of the conference, only informs to the > participants about the desirable language that they should used in > the conference. Participants are free to switch to other languages > if they like. > NEW: > The element indicates the predominant language that is > expected to be employed within a conference. This element is not > enforcing the language of the conference, but only informs the > participants about the desirable language that they should use in > the conference. Participants are free to switch to other languages > if they like. > > > _______________________________________________ XCON mailing list XCON@ietf.org http://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Feb 22 12:11:46 2008 Return-Path: X-Original-To: ietfarch-xcon-archive@core3.amsl.com Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46173A6B08; Fri, 22 Feb 2008 12:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN5qzPHXH65Z; Fri, 22 Feb 2008 12:11:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3244028CBF9; Fri, 22 Feb 2008 12:07:09 -0800 (PST) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C0428CBF0 for ; Fri, 22 Feb 2008 12:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfGlqBzU1Gpz for ; Fri, 22 Feb 2008 12:07:07 -0800 (PST) Received: from mailhost2.aepona.com (mailhost1.aepona.com [194.46.24.5]) by core3.amsl.com (Postfix) with ESMTP id 69ABA28C5F0 for ; Fri, 22 Feb 2008 12:04:08 -0800 (PST) Received: from exim by mailhost2.aepona.com with local (Exim 4.52) id 1JSe7m-0005ln-Qx for xcon@ietf.org; Fri, 22 Feb 2008 20:04:02 +0000 From: David.Monahan@aepona.com To: xcon@ietf.org In-Reply-To: Auto-Submitted: auto-replied Message-Id: Date: Fri, 22 Feb 2008 20:04:02 +0000 Subject: [XCON] Out-of-office-reply: XCON Digest, Vol 45, Issue 6 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org I will be out of the office until 3 March 2008. I will read your email on my return. _______________________________________________ XCON mailing list XCON@ietf.org http://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Feb 25 01:45:10 2008 Return-Path: X-Original-To: ietfarch-xcon-archive@core3.amsl.com Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330EC28C2C6; Mon, 25 Feb 2008 01:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p403+3XLucCp; Mon, 25 Feb 2008 01:45:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CEC23A697D; Mon, 25 Feb 2008 01:45:05 -0800 (PST) X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0EC553A6A03; Mon, 25 Feb 2008 01:45:02 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225094502.0EC553A6A03@core3.amsl.com> Date: Mon, 25 Feb 2008 01:45:02 -0800 (PST) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-09.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org 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-09.txt Pages : 72 Date : 2008-02-25 This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-09.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-09.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-09.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: <2008-02-25013217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-common-data-model-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-common-data-model-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25013217.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 http://www.ietf.org/mailman/listinfo/xcon --NextPart-- From xcon-bounces@ietf.org Tue Feb 26 08:12:56 2008 Return-Path: X-Original-To: ietfarch-xcon-archive@core3.amsl.com Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DDA428C3A1; Tue, 26 Feb 2008 08:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l2iu+1efZSe; Tue, 26 Feb 2008 08:12:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550F528C32C; Tue, 26 Feb 2008 08:12:54 -0800 (PST) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F36113A6C44 for ; Tue, 26 Feb 2008 08:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBigmk9Aj88g for ; Tue, 26 Feb 2008 08:12:51 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 7018E3A6C74 for ; Tue, 26 Feb 2008 08:12:06 -0800 (PST) Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m1QGBwIs018921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Feb 2008 10:11:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <47C43A4F.40201@nostrum.com> Date: Tue, 26 Feb 2008 10:11:59 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: XCON-IETF References: <479519B7.7080600@nostrum.com> In-Reply-To: <479519B7.7080600@nostrum.com> Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.92.1/6003/Tue Feb 26 05:34:31 2008 on shaman.nostrum.com X-Virus-Status: Clean Subject: [XCON] Last Call: Agenda Requests X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org [as chair] We need to have our preliminary agenda available by tomorrow. If you plan to talk about a document and have not yet told me or Alan, please respond before midnight EST today. (Mary, Chris, Gonzalo: I have received your requests). Thanks. /a _______________________________________________ XCON mailing list XCON@ietf.org http://www.ietf.org/mailman/listinfo/xcon