From Internet-Drafts@ietf.org Tue Feb 1 06:45:05 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD4B3A6C11; Tue, 1 Feb 2011 06:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 OU1WJHv4jTbG; Tue, 1 Feb 2011 06:45:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8EDA3A6D4F; Tue, 1 Feb 2011 06:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110201144502.31392.11046.idtracker@localhost> Date: Tue, 01 Feb 2011 06:45:02 -0800 Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-23.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 14:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Conference Information Data Model for Centralized Conferencing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-23.txt Pages : 95 Date : 2011-02-01 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-23.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-common-data-model-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-01064419.I-D@ietf.org> --NextPart-- From oscar.novo@ericsson.com Tue Feb 1 06:58:45 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B43013A6C09 for ; Tue, 1 Feb 2011 06:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbGTN3G4X5TW for ; Tue, 1 Feb 2011 06:58:45 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A52183A6D84 for ; Tue, 1 Feb 2011 06:58:44 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-ee-4d48206936b0 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7F.E1.13987.960284D4; Tue, 1 Feb 2011 16:02:01 +0100 (CET) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.2.69]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 1 Feb 2011 16:02:00 +0100 From: Oscar Novo To: "xcon@ietf.org" Date: Tue, 1 Feb 2011 16:01:59 +0100 Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-common-data-model-23.txt Thread-Index: AcvCHxU4Rtdz8ra8T9WqN9p20LFWyQAAIpJQ Message-ID: <58E207308662A748A4AC1ECB4E885614052C78FF9E@ESESSCMS0355.eemea.ericsson.se> References: <20110201144502.31392.11046.idtracker@localhost> In-Reply-To: <20110201144502.31392.11046.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo Subject: Re: [XCON] I-D Action:draft-ietf-xcon-common-data-model-23.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 14:58:45 -0000 Hello, A new version of the data model addressing all the comments from the AD has= been submitted. Cheers, Oscar -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Int= ernet-Drafts@ietf.org Sent: 1. helmikuuta 2011 16:45 To: i-d-announce@ietf.org Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-23.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Centralized Conferencing Working Group of = the IETF. Title : Conference Information Data Model for Centralized Confer= encing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-23.txt Pages : 95 Date : 2011-02-01 This document defines an Extensible Markup Language (XML)-based conference = information data model for centralized conferencing (XCON). A conference i= nformation data model is designed to convey information about the conferenc= e and about participation in the conference. The conference information da= ta model defined in this document constitutes an extension of the data form= at specified in the Session Initiation Protocol (SIP) Event Package for Con= ference State. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-23.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. From mary.ietf.barnes@gmail.com Mon Feb 14 10:24:46 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D834C3A6D4D for ; Mon, 14 Feb 2011 10:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 1doAO14rRDcP for ; Mon, 14 Feb 2011 10:24:45 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 634EA3A6AB3 for ; Mon, 14 Feb 2011 10:24:45 -0800 (PST) Received: by yxt33 with SMTP id 33so2456090yxt.31 for ; Mon, 14 Feb 2011 10:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=Win8s3Xn5WQ6wLESxTOXX6JeQCUazurWfePRBQG5xM8=; b=M4H1pPGROSwubPlk5i2ayFDf+Tf9g7XNT6NiYc8n2VOvp8L6hGxeqtT/tjw8CzSQ9B m8grg7bGA5giGlX5kMZM5Ox/n6Pfc3dogjBtFpYYJ5vQgBZ7uOIh84VKtE2mnFthMCC5 PuxOoliXwS5KoyD16gF8qdGz2qisgHChqTXZk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=m/j+hPrnK18yiAVSLkRQbZJRtNHlvrT2laKBNOWuWMObSJbi+59hQkBOlTIxKAoAxJ pzbuiTEzAA6dXPa2GxuYnP4b0EtODTzNo+ozh6rEyBJfLc7pZ7RAarpiKt1b9vn3RUP6 gcZj6AhjF8umPVPtffghMKM3zR/jc6vx+1bOE= MIME-Version: 1.0 Received: by 10.236.103.180 with SMTP id f40mr1904970yhg.0.1297707906988; Mon, 14 Feb 2011 10:25:06 -0800 (PST) Received: by 10.236.95.35 with HTTP; Mon, 14 Feb 2011 10:25:06 -0800 (PST) Date: Mon, 14 Feb 2011 12:25:06 -0600 Message-ID: From: Mary Barnes To: Robert Sparks Content-Type: multipart/alternative; boundary=0023543a2748d1877b049c422a0f Cc: xcon@ietf.org Subject: [XCON] AD review: draft-ietf-xcon-ccmp-11 - AUTO_GENERATE_X behavior X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 18:24:47 -0000 --0023543a2748d1877b049c422a0f Content-Type: text/plain; charset=ISO-8859-1 Hi folks, Per the discussion threads: http://www.ietf.org/mail-archive/web/xcon/current/msg02492.html http://www.ietf.org/mail-archive/web/xcon/current/msg02493.html I propose to make the following changes with regards to the normative behavior for AUTO_GENERATE_X, as currently described in the last paragraph in section 4.1. I'll also make some editorial changes to the text in section 4 to more accurately describe what is in section 4.1 and 4.2. OLD: To solve this kind of issues, the CCMP fill all mandatory data model fields, for which no value is available at the client at the time the request is constructed, with fake values in the form of wildcard strings (e.g. AUTO_GENERATE_X, with X being an incremental index initialized to a value of 1). Upon reception of the mentioned kinds of requests, the server will: (i) generate the proper identifier(s); (ii) produce a response in which the received fake identifier(s) carried in the request has (have) been replaced by the newly created one(s). With this approach we maintain compatibility with the data model requirements, at the same time allowing for client-initiated manipulation of conference objects at the server's side (which is, by the way, one of the main goals for which the CCMP protocol has been conceived at the outset). NEW: To solve this issue, the CCMP client fills all mandatory data model fields, for which no value is available at the time the request is constructed, with fake values in the form of a wildcard string, AUTO_GENERATE_X (all uppercase), with X being a unique numeric index for each data model field for which the value is unknown. This form of wildcard string is chosen, rather than the use of random unique strings (e.g, FOO_BAR_LA) or non-numeric values for X, to simplify processing at the server. The values of AUTO_GENERATE_X are only unique within the context of the specific request. The fake AUTO_GENERATE_X values MUST be within the value part of an attribute/element (e.g., ). When the server receives requests containing values in the form of AUTO_GENERATE_X, the server does the following: (i) Generates the proper identifier for each instance of AUTO_GENERATE_X in the document. If an instance of AUTO_GENERATE_X is not within the value part of the attribute/element, the server MUST respond with an error of 400 Bad Request. In cases where AUTO_GENERATE_X appears only in the user part of a URI (i.e., in the case of XCON-USERIDs or XCON-URIs), the server needs to ensure that the domain name is one that is within the server's domain of responsibility. If the domain name is NOT within the server's domain of responsibility, then the server MUST return a 500 Server Internal Error. The server MUST replace each instance of a specific wildcard field (e.g., AUTO_GENERATE_1) with the same identifier. The identifiers MUST be unique for each instance of AUTO_GENERATE_X within the same XML document received in the request - e.g., the value that replaces AUTO_GENERATE_1 MUST NOT be the same as the value that replaces AUTO_GENERATE_2. Note that the values that replace the instances of AUTO_GENERATE_X are not the same across all conference objects - e.g., different values can be used to replace AUTO_GENERATE_1 in two different documents. (ii) Sends a response in which all values of AUTO_GENERATE_X received in the request has (have) been replaced by the newly created one(s). With this approach compatibility with the data model requirements is maintained, while allowing for client-initiated manipulation of conference objects at the server's side which is one of the main goals of the CCMP protocol. Please let me know ASAP if this is not okay. Thanks, Mary. > > --0023543a2748d1877b049c422a0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi folks,

Per the discussion threads: =A0

I propose to make the following changes with regards to= the normative behavior for =A0AUTO_GENERATE_X, as currently described in t= he last paragraph in section 4.1. =A0I'll also make=A0
some e= ditorial changes to the text in section 4 to more accurately describe what = is in section 4.1 and 4.2.

OLD:
=A0=A0 =A0 =A0 =A0 =A0To solve this kind= of issues,=A0
=A0=A0 =A0 =A0 =A0 =A0 the CCMP fill all mandatory= data model fields, for which no value is=A0
=A0=A0 =A0 =A0 =A0 = =A0 available at the client at the time the request is constructed, with fa= ke values=A0
=A0=A0 =A0 =A0 =A0 =A0 in the form of wildcard strings (e.g. AUTO_GENE= RATE_X, with X being an incremental
=A0=A0 =A0 =A0 =A0 =A0 =A0ind= ex initialized to a value of 1). Upon reception of the mentioned kinds of r= equests,=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0the server will: (i) genera= te the proper identifier(s); (ii)=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0produce a response in which the received fak= e identifier(s) carried in the=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0reque= st has (have) been replaced by the newly created one(s).=A0
=A0= =A0 =A0 =A0 =A0 =A0 =A0With this approach we maintain compatibility with th= e data model requirements,=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0at the same time allowing for client-initiat= ed manipulation of conference objects=A0
=A0=A0 =A0 =A0 =A0 =A0 = =A0at the server's side (which is, by the way, one of the main goals fo= r which the CCMP=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0protocol has been conceived at the outset).
=

NEW:
=A0=A0 =A0 =A0 =A0 =A0=A0To solve this i= ssue, =A0the CCMP client fills all mandatory data model fields,=A0
=A0=A0 =A0 =A0 =A0 =A0 for which no value is=A0available at the time the = request is constructed, with fake values=A0
=A0=A0 =A0 =A0 =A0 =A0 in the form of a wildcard string, AUTO_GENERATE= _X (all uppercase),=A0
=A0=A0 =A0 =A0 =A0 =A0 with X being a uniq= ue=A0numeric index for each data model field for which the value is
=A0=A0 =A0 =A0 =A0 =A0 unknown. =A0This form of wildcard string is chose= n, rather than the use=A0
=A0=A0 =A0 =A0 =A0 =A0 of random unique strings (e.g, FOO_BAR_LA) or n= on-numeric values for X,
=A0=A0 =A0 =A0 =A0 =A0 to simplify proce= ssing at the=A0server. =A0The values of AUTO_GENERATE_X
=A0=A0 = =A0 =A0 =A0 =A0 are only unique within the=A0context of the specific reques= t. =A0The fake AUTO_GENERATE_X
=A0=A0 =A0 =A0 =A0 =A0 values MUST be within the value part of an attr= ibute/element (e.g., <userinfo entity=3D
=A0=A0 =A0 =A0 =A0 = =A0 "xcon= -userid:AUTO_GENERATE_1@example.com">). =A0 =A0
=A0=A0 =A0 =A0 =A0 =A0
=A0=A0 =A0 =A0 =A0 =A0 =A0When the se= rver receives requests=A0containing values in the form of AUTO_GENERATE_X,= =A0
=A0=A0 =A0 =A0 =A0 =A0 =A0the=A0server does the following:
=A0=A0 =A0 =A0 =A0 =A0 =A0=A0(i) =A0Generates the proper identifier= for each instance of=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0AUTO_GENERATE_X in the document.= =A0 If an instance of AUTO_GENERATE_X=A0
=A0=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0is not within the value part of the attribute/element, =A0th= e server MUST=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0respond wi= th an error of 400 Bad Request. =A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In cases where AUTO_GENERATE_X a= ppears only in the user part of=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0a URI (i.e., in the case of XCON-USERIDs or XCON-URIs), the server= =A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0needs to ensure that th= e domain name is one that is within the server's domain=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of responsibility. =A0If the dom= ain name is NOT within the server's domain of
=A0=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0responsibility, then the server MUST return a 500 Se= rver Internal Error.=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The= server MUST replace each instance of a specific=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wildcard field =A0(e.g., AUTO_GE= NERATE_1)
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0with the same i= dentifier. =A0The identifiers MUST be unique
=A0=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0for each instance of AUTO_GENERATE_X within the same
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XML document received in the req= uest - e.g., the value
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that= replaces AUTO_GENERATE_1 MUST NOT be the same as the value
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that replaces AUTO_GENERATE_2. =A0 Note = that the values
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that replace the instances of AU= TO_GENERATE_X are not the
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0s= ame across all conference objects - e.g., different values can=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be used to replace AUTO_GENERATE_1 i= n two different=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0documents. =A0=A0
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0=A0 =A0=A0
=A0=A0 =A0 = =A0 =A0 =A0 =A0(ii) =A0Sends=A0a response in which all values of AUTO_GENER= ATE_X received in=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the=A0req= uest has (have) been replaced by the newly created one(s).=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0
=A0=A0 =A0 =A0 =A0 =A0 =A0With th= is approach compatibility with the data model requirements is maintained,= =A0
=A0=A0 =A0 =A0 =A0 =A0 =A0while allowing for client-initiated= manipulation of conference objects=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0at the server's side =A0which is one of = the main goals of the CCMP protocol.
=A0=A0 =A0 =A0 =A0 =A0 =A0= =A0=A0

Please let me know ASAP if this is not= okay.

Thanks,
Mary.

--0023543a2748d1877b049c422a0f-- From spromano@unina.it Tue Feb 15 02:16:12 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6E53A6E81 for ; Tue, 15 Feb 2011 02:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 aKqm99LxBeOp for ; Tue, 15 Feb 2011 02:16:10 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by core3.amsl.com (Postfix) with ESMTP id C97703A6E79 for ; Tue, 15 Feb 2011 02:16:09 -0800 (PST) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id p1FAGPPL016809 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Feb 2011 11:16:26 +0100 Message-ID: <4D5A5278.7020505@unina.it> Date: Tue, 15 Feb 2011 11:16:24 +0100 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030307070305060602020501" Cc: xcon@ietf.org Subject: Re: [XCON] AD review: draft-ietf-xcon-ccmp-11 - AUTO_GENERATE_X behavior X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 10:16:12 -0000 This is a multi-part message in MIME format. --------------030307070305060602020501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Mary, I believe this is an excellent summary of the discussions we had so far on the list. Simon Il 14/02/2011 19:25, Mary Barnes ha scritto: > Hi folks, > > Per the discussion threads: > http://www.ietf.org/mail-archive/web/xcon/current/msg02492.html > http://www.ietf.org/mail-archive/web/xcon/current/msg02493.html > > I propose to make the following changes with regards to the normative > behavior for AUTO_GENERATE_X, as currently described in the last > paragraph in section 4.1. I'll also make > some editorial changes to the text in section 4 to more accurately > describe what is in section 4.1 and 4.2. > > OLD: > To solve this kind of issues, > the CCMP fill all mandatory data model fields, for which no > value is > available at the client at the time the request is > constructed, with fake values > in the form of wildcard strings (e.g. AUTO_GENERATE_X, with > X being an incremental > index initialized to a value of 1). Upon reception of the > mentioned kinds of requests, > the server will: (i) generate the proper identifier(s); (ii) > produce a response in which the received fake > identifier(s) carried in the > request has (have) been replaced by the newly created one(s). > With this approach we maintain compatibility with the data > model requirements, > at the same time allowing for client-initiated > manipulation of conference objects > at the server's side (which is, by the way, one of the > main goals for which the CCMP > protocol has been conceived at the outset). > > NEW: > To solve this issue, the CCMP client fills all mandatory > data model fields, > for which no value is available at the time the request is > constructed, with fake values > in the form of a wildcard string, AUTO_GENERATE_X (all > uppercase), > with X being a unique numeric index for each data model > field for which the value is > unknown. This form of wildcard string is chosen, rather > than the use > of random unique strings (e.g, FOO_BAR_LA) or non-numeric > values for X, > to simplify processing at the server. The values of > AUTO_GENERATE_X > are only unique within the context of the specific request. > The fake AUTO_GENERATE_X > values MUST be within the value part of an > attribute/element (e.g., "xcon-userid:AUTO_GENERATE_1@example.com > ">). > When the server receives requests containing values in the > form of AUTO_GENERATE_X, > the server does the following: > (i) Generates the proper identifier for each instance of > AUTO_GENERATE_X in the document. If an instance of > AUTO_GENERATE_X > is not within the value part of the > attribute/element, the server MUST > respond with an error of 400 Bad Request. > In cases where AUTO_GENERATE_X appears only in the > user part of > a URI (i.e., in the case of XCON-USERIDs or > XCON-URIs), the server > needs to ensure that the domain name is one that is > within the server's domain > of responsibility. If the domain name is NOT within > the server's domain of > responsibility, then the server MUST return a 500 > Server Internal Error. > The server MUST replace each instance of a specific > wildcard field (e.g., AUTO_GENERATE_1) > with the same identifier. The identifiers MUST be > unique > for each instance of AUTO_GENERATE_X within the same > XML document received in the request - e.g., the value > that replaces AUTO_GENERATE_1 MUST NOT be the same > as the value > that replaces AUTO_GENERATE_2. Note that the values > that replace the instances of AUTO_GENERATE_X are > not the > same across all conference objects - e.g., different > values can > be used to replace AUTO_GENERATE_1 in two different > documents. > (ii) Sends a response in which all values of > AUTO_GENERATE_X received in > the request has (have) been replaced by the newly > created one(s). > With this approach compatibility with the data model > requirements is maintained, > while allowing for client-initiated manipulation of > conference objects > at the server's side which is one of the main goals of > the CCMP protocol. > > Please let me know ASAP if this is not okay. > > Thanks, > Mary. > > -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --------------030307070305060602020501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mary,

I believe this is an excellent summary of the discussions we had so far on the list.

Simon

Il 14/02/2011 19:25, Mary Barnes ha scritto:
Hi folks,

Per the discussion threads:  

I propose to make the following changes with regards to the normative behavior for  AUTO_GENERATE_X, as currently described in the last paragraph in section 4.1.  I'll also make 
some editorial changes to the text in section 4 to more accurately describe what is in section 4.1 and 4.2.

OLD:
          To solve this kind of issues, 
           the CCMP fill all mandatory data model fields, for which no value is 
           available at the client at the time the request is constructed, with fake values 
           in the form of wildcard strings (e.g. AUTO_GENERATE_X, with X being an incremental
            index initialized to a value of 1). Upon reception of the mentioned kinds of requests, 
            the server will: (i) generate the proper identifier(s); (ii) 
            produce a response in which the received fake identifier(s) carried in the 
            request has (have) been replaced by the newly created one(s). 
            With this approach we maintain compatibility with the data model requirements, 
            at the same time allowing for client-initiated manipulation of conference objects 
            at the server's side (which is, by the way, one of the main goals for which the CCMP 
            protocol has been conceived at the outset).

NEW:
           To solve this issue,  the CCMP client fills all mandatory data model fields, 
           for which no value is available at the time the request is constructed, with fake values 
           in the form of a wildcard string, AUTO_GENERATE_X (all uppercase), 
           with X being a unique numeric index for each data model field for which the value is
           unknown.  This form of wildcard string is chosen, rather than the use 
           of random unique strings (e.g, FOO_BAR_LA) or non-numeric values for X,
           to simplify processing at the server.  The values of AUTO_GENERATE_X
           are only unique within the context of the specific request.  The fake AUTO_GENERATE_X
           values MUST be within the value part of an attribute/element (e.g., <userinfo entity=
           "xcon-userid:AUTO_GENERATE_1@example.com">).    
          
            When the server receives requests containing values in the form of AUTO_GENERATE_X, 
            the server does the following:
             (i)  Generates the proper identifier for each instance of 
                  AUTO_GENERATE_X in the document.   If an instance of AUTO_GENERATE_X 
                  is not within the value part of the attribute/element,  the server MUST 
                  respond with an error of 400 Bad Request.  
                  In cases where AUTO_GENERATE_X appears only in the user part of 
                  a URI (i.e., in the case of XCON-USERIDs or XCON-URIs), the server 
                  needs to ensure that the domain name is one that is within the server's domain 
                  of responsibility.  If the domain name is NOT within the server's domain of
                  responsibility, then the server MUST return a 500 Server Internal Error. 
                  The server MUST replace each instance of a specific 
                  wildcard field  (e.g., AUTO_GENERATE_1)
                  with the same identifier.  The identifiers MUST be unique
                  for each instance of AUTO_GENERATE_X within the same
                  XML document received in the request - e.g., the value
                  that replaces AUTO_GENERATE_1 MUST NOT be the same as the value
                  that replaces AUTO_GENERATE_2.   Note that the values
                  that replace the instances of AUTO_GENERATE_X are not the
                  same across all conference objects - e.g., different values can 
                  be used to replace AUTO_GENERATE_1 in two different 
                  documents.   
                        
            (ii)  Sends a response in which all values of AUTO_GENERATE_X received in 
                 the request has (have) been replaced by the newly created one(s). 
            
            With this approach compatibility with the data model requirements is maintained, 
            while allowing for client-initiated manipulation of conference objects 
            at the server's side  which is one of the main goals of the CCMP protocol.
              

Please let me know ASAP if this is not okay.

Thanks,
Mary.


-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/
--------------030307070305060602020501-- From rjsparks@nostrum.com Tue Feb 15 06:26:48 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE013A6C94 for ; Tue, 15 Feb 2011 06:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 KKl+BltnrDKk for ; Tue, 15 Feb 2011 06:26:44 -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 B02393A6D47 for ; Tue, 15 Feb 2011 06:26:43 -0800 (PST) Received: from [192.168.2.105] (pool-173-57-105-99.dllstx.fios.verizon.net [173.57.105.99]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p1FER50j095586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Feb 2011 08:27:06 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-36--502237708 From: Robert Sparks In-Reply-To: Date: Tue, 15 Feb 2011 08:27:05 -0600 Message-Id: <1149FEBF-C9D9-45CE-849C-56F5CBD965D6@nostrum.com> References: To: Mary Barnes X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 173.57.105.99 is authenticated by a trusted mechanism) Cc: xcon@ietf.org Subject: Re: [XCON] AD review: draft-ietf-xcon-ccmp-11 - AUTO_GENERATE_X behavior X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 14:26:48 -0000 --Apple-Mail-36--502237708 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This looks good to me. RjS On Feb 14, 2011, at 12:25 PM, Mary Barnes wrote: > Hi folks, >=20 > Per the discussion threads: =20 > http://www.ietf.org/mail-archive/web/xcon/current/msg02492.html > http://www.ietf.org/mail-archive/web/xcon/current/msg02493.html >=20 > I propose to make the following changes with regards to the normative = behavior for AUTO_GENERATE_X, as currently described in the last = paragraph in section 4.1. I'll also make=20 > some editorial changes to the text in section 4 to more accurately = describe what is in section 4.1 and 4.2. >=20 > OLD: > To solve this kind of issues,=20 > the CCMP fill all mandatory data model fields, for which no = value is=20 > available at the client at the time the request is = constructed, with fake values=20 > in the form of wildcard strings (e.g. AUTO_GENERATE_X, with = X being an incremental > index initialized to a value of 1). Upon reception of the = mentioned kinds of requests,=20 > the server will: (i) generate the proper identifier(s); = (ii)=20 > produce a response in which the received fake = identifier(s) carried in the=20 > request has (have) been replaced by the newly created = one(s).=20 > With this approach we maintain compatibility with the data = model requirements,=20 > at the same time allowing for client-initiated = manipulation of conference objects=20 > at the server's side (which is, by the way, one of the = main goals for which the CCMP=20 > protocol has been conceived at the outset). >=20 > NEW: > To solve this issue, the CCMP client fills all mandatory = data model fields,=20 > for which no value is available at the time the request is = constructed, with fake values=20 > in the form of a wildcard string, AUTO_GENERATE_X (all = uppercase),=20 > with X being a unique numeric index for each data model = field for which the value is > unknown. This form of wildcard string is chosen, rather = than the use=20 > of random unique strings (e.g, FOO_BAR_LA) or non-numeric = values for X, > to simplify processing at the server. The values of = AUTO_GENERATE_X > are only unique within the context of the specific request. = The fake AUTO_GENERATE_X > values MUST be within the value part of an = attribute/element (e.g., "xcon-userid:AUTO_GENERATE_1@example.com">). =20 > =20 > When the server receives requests containing values in the = form of AUTO_GENERATE_X,=20 > the server does the following: > (i) Generates the proper identifier for each instance of=20= > AUTO_GENERATE_X in the document. If an instance of = AUTO_GENERATE_X=20 > is not within the value part of the = attribute/element, the server MUST=20 > respond with an error of 400 Bad Request. =20 > In cases where AUTO_GENERATE_X appears only in the = user part of=20 > a URI (i.e., in the case of XCON-USERIDs or = XCON-URIs), the server=20 > needs to ensure that the domain name is one that is = within the server's domain=20 > of responsibility. If the domain name is NOT within = the server's domain of > responsibility, then the server MUST return a 500 = Server Internal Error.=20 > The server MUST replace each instance of a specific=20= > wildcard field (e.g., AUTO_GENERATE_1) > with the same identifier. The identifiers MUST be = unique > for each instance of AUTO_GENERATE_X within the same > XML document received in the request - e.g., the = value > that replaces AUTO_GENERATE_1 MUST NOT be the same = as the value > that replaces AUTO_GENERATE_2. Note that the = values > that replace the instances of AUTO_GENERATE_X are = not the > same across all conference objects - e.g., different = values can=20 > be used to replace AUTO_GENERATE_1 in two different=20= > documents. =20 > =20 > (ii) Sends a response in which all values of = AUTO_GENERATE_X received in=20 > the request has (have) been replaced by the newly = created one(s).=20 > =20 > With this approach compatibility with the data model = requirements is maintained,=20 > while allowing for client-initiated manipulation of = conference objects=20 > at the server's side which is one of the main goals of = the CCMP protocol. > =20 >=20 > Please let me know ASAP if this is not okay. >=20 > Thanks, > Mary. >=20 --Apple-Mail-36--502237708 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii This looks good to me.

RjS

On Feb 14, 2011, at 12:25 PM, Mary Barnes wrote:

Hi folks,

Per the discussion threads:  

I propose to make the following changes with regards to the normative behavior for  AUTO_GENERATE_X, as currently described in the last paragraph in section 4.1.  I'll also make 
some editorial changes to the text in section 4 to more accurately describe what is in section 4.1 and 4.2.

OLD:
          To solve this kind of issues, 
           the CCMP fill all mandatory data model fields, for which no value is 
           available at the client at the time the request is constructed, with fake values 
           in the form of wildcard strings (e.g. AUTO_GENERATE_X, with X being an incremental
            index initialized to a value of 1). Upon reception of the mentioned kinds of requests, 
            the server will: (i) generate the proper identifier(s); (ii) 
            produce a response in which the received fake identifier(s) carried in the 
            request has (have) been replaced by the newly created one(s). 
            With this approach we maintain compatibility with the data model requirements, 
            at the same time allowing for client-initiated manipulation of conference objects 
            at the server's side (which is, by the way, one of the main goals for which the CCMP 
            protocol has been conceived at the outset).

NEW:
           To solve this issue,  the CCMP client fills all mandatory data model fields, 
           for which no value is available at the time the request is constructed, with fake values 
           in the form of a wildcard string, AUTO_GENERATE_X (all uppercase), 
           with X being a unique numeric index for each data model field for which the value is
           unknown.  This form of wildcard string is chosen, rather than the use 
           of random unique strings (e.g, FOO_BAR_LA) or non-numeric values for X,
           to simplify processing at the server.  The values of AUTO_GENERATE_X
           are only unique within the context of the specific request.  The fake AUTO_GENERATE_X
           values MUST be within the value part of an attribute/element (e.g., <userinfo entity=
           "xcon-userid:AUTO_GENERATE_1@example.com">).    
          
            When the server receives requests containing values in the form of AUTO_GENERATE_X, 
            the server does the following:
             (i)  Generates the proper identifier for each instance of 
                  AUTO_GENERATE_X in the document.   If an instance of AUTO_GENERATE_X 
                  is not within the value part of the attribute/element,  the server MUST 
                  respond with an error of 400 Bad Request.  
                  In cases where AUTO_GENERATE_X appears only in the user part of 
                  a URI (i.e., in the case of XCON-USERIDs or XCON-URIs), the server 
                  needs to ensure that the domain name is one that is within the server's domain 
                  of responsibility.  If the domain name is NOT within the server's domain of
                  responsibility, then the server MUST return a 500 Server Internal Error. 
                  The server MUST replace each instance of a specific 
                  wildcard field  (e.g., AUTO_GENERATE_1)
                  with the same identifier.  The identifiers MUST be unique
                  for each instance of AUTO_GENERATE_X within the same
                  XML document received in the request - e.g., the value
                  that replaces AUTO_GENERATE_1 MUST NOT be the same as the value
                  that replaces AUTO_GENERATE_2.   Note that the values
                  that replace the instances of AUTO_GENERATE_X are not the
                  same across all conference objects - e.g., different values can 
                  be used to replace AUTO_GENERATE_1 in two different 
                  documents.   
                        
            (ii)  Sends a response in which all values of AUTO_GENERATE_X received in 
                 the request has (have) been replaced by the newly created one(s). 
            
            With this approach compatibility with the data model requirements is maintained, 
            while allowing for client-initiated manipulation of conference objects 
            at the server's side  which is one of the main goals of the CCMP protocol.
              

Please let me know ASAP if this is not okay.

Thanks,
Mary.


--Apple-Mail-36--502237708-- From shenqiwei@ebupt.com Tue Feb 15 06:34:20 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F54C3A6C41 for ; Tue, 15 Feb 2011 06:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 YS9lckPj5I92 for ; Tue, 15 Feb 2011 06:34:19 -0800 (PST) Received: from smtp.263xmail.com (smtp.263xmail.com [211.150.67.11]) by core3.amsl.com (Postfix) with ESMTP id DDFEE3A6D21 for ; Tue, 15 Feb 2011 06:34:18 -0800 (PST) Received: from smtp9.263xmail.com (smtp9 [127.0.0.1]) by smtp9.263xmail.com (Postfix) with ESMTP id DCD26F33A for ; Tue, 15 Feb 2011 22:34:28 +0800 (CST) X-ABS-CHECKED: 1 X-KSVirus-check: 0 Received: from [192.168.0.8] (smtp9 [127.0.0.1]) by smtp9.263xmail.com (Postfix) with ESMTP id 7972D457 for ; Tue, 15 Feb 2011 22:34:28 +0800 (CST) X-SENDER-IP: 211.150.67.11 X-LOGIN-NAME: shenqiwei@ebupt.com X-ATTACHMENT-NUM: 0 X-SENDER: shenqiwei@ebupt.com Received: from [192.168.0.8] (smtp.263xmail.com [211.150.67.11]) by smtp9.263xmail.com (Postfix) whith ESMTP id 20481YEUYU0; Tue, 15 Feb 2011 22:34:28 +0800 (CST) From: Shen Qiwei Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (8C148) Message-Id: Date: Tue, 15 Feb 2011 22:34:29 +0800 To: "XCON@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 8C148) Subject: [XCON] Deregister X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 14:34:20 -0000 BRs, Shen Qiwei From spromano@unina.it Wed Feb 16 05:55:57 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70003A6CAD for ; Wed, 16 Feb 2011 05:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 VQDUC1xFrEPx for ; Wed, 16 Feb 2011 05:55:56 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by core3.amsl.com (Postfix) with ESMTP id A4C293A6956 for ; Wed, 16 Feb 2011 05:55:55 -0800 (PST) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id p1GDuDrp000819 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 16 Feb 2011 14:56:13 +0100 Message-ID: <4D5BD779.8020802@unina.it> Date: Wed, 16 Feb 2011 14:56:09 +0100 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Reissner, Peter E (Peter)" References: <6369CB70BFD88942B9705AC1E639A33822093F7176@DC-US1MBEX4.global.avaya.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000303010002010407060606" Cc: "draft-ietf-xcon-ccmp@tools.ietf.org" , xcon@ietf.org Subject: Re: [XCON] Mail regarding draft-ietf-xcon-ccmp X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 13:55:57 -0000 This is a multi-part message in MIME format. --------------000303010002010407060606 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Peter, thank you for your comments. Please, see in-line ([spromano]) my responses. > Dear authors of draft-ietf-xcon-ccmp version 11, > > Here is an error I’ve found and a suggestion I have. > > ·Page 97 > > The lines in the schema file > > > minOccurs="1" maxOccurs="4"/> > > need to be changed to > > > minOccurs="1" maxOccurs="4"/> > [spromano] Right! We modified this a while ago, but we forgot to update it in the current version of the draft. Thank you for pointing this out. > > For optionsRequest, the format of this message type is a diversion > from the rest of the CCMP schema in that it does not have an > optionsRequest element. This makes it harder to implement in a > server because it becomes a special case. Using tools like JAXB > will result in no optionsRequest class code being generated. > [spromano] We discussed this internally when we introduced the optionsRequest message. We opted for avoiding in this particular case the approach based on specializing the request, since for this kind of message the request itself would be empty in most cases. Please notice that we nonetheless included an element in the schema, to allow for potential customizations of the message. I also have to say that we encountered no particular issue when implementing the CCMP (by leveraging JAXB) with the current schema. Did you have a different experience with regard to this point? This said, your proposal is a feasible one; I'm not personally against it if we decide to modify the schema. Cheers, Simon > Perhaps you could change > > > > > > > > > > > > > > To > > > > > > > > > > > > > > > > > > > > > > > > > type="optionsRequestType" /> > > > > > > > minOccurs="0" maxOccurs="unbounded"/> > > > > > > > > Regards, > > *Peter Reissner* > > Unified Communications R&D - VCFS Team - Avaya, Belleville, Ontario > > (Phone (613) 961-2282 > > Express/personal FAX: (613) 961-2339 mailbox 2282# > > /*reissner@avaya.com* /*//* > > -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --------------000303010002010407060606 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Peter,

thank you for your comments. Please, see in-line ([spromano]) my responses.

Dear authors of    draft-ietf-xcon-ccmp  version 11,

 

Here is an error I’ve found and a suggestion I have.

 

·         Page 97

The lines in the schema file

<xs:element name="operation" type="operation-type"

                    minOccurs="1" maxOccurs="4"/>

 

need to be changed to

 

<xs:element name="operation" type="operationType"

                    minOccurs="1" maxOccurs="4"/>

[spromano] Right! We modified this a while ago, but we forgot to update it in the current version of the draft. Thank you for pointing this out.

 For optionsRequest, the format of this message type is a diversion from the rest of the CCMP schema in that it does not have an optionsRequest element.  This makes it harder to implement in a server because it becomes a special case. Using tools like JAXB will result in no optionsRequest class code being generated.


[spromano] We discussed this internally  when we introduced the optionsRequest message. We opted for avoiding in this particular case the approach based on specializing the request, since for this kind of message the request itself would be empty in most cases. Please notice that we nonetheless included an <any> element in the schema, to allow for potential customizations of the message. I also have to say that we encountered no particular issue when implementing the CCMP (by leveraging JAXB) with the current schema. Did you have a different experience with regard to this point?
This said, your proposal is a feasible one; I'm not personally against it if we decide to modify the schema.

Cheers,

Simon

 

Perhaps you could change

   <!-- optionsRequest -->

 

   <xs:complexType name="ccmp-options-request-message-type">

           <xs:complexContent>

                   <xs:extension base="tns:ccmp-request-message-type"/>

           </xs:complexContent>

   </xs:complexType>

 

To

 

   <!-- optionsRequest -->

 

   <xs:complexType name="ccmp-options-request-message-type">

           <xs:complexContent>

               <xs:extension base="tns: ccmp-request-message-type ">

                       <xs:sequence>

                               <xs:element ref="optionsRequest"/>

                       </xs:sequence>

               </xs:extension>

          </xs:complexContent>

   </xs:complexType>

 

   <!-- optionsRequestType -->

 

   <xs:element name="optionsRequest"

                  type="optionsRequestType" />

 

   <xs:complexType name="optionsRequestType">

        <xs:sequence>

                <xs:any namespace="##other" processContents="lax"

                minOccurs="0" maxOccurs="unbounded"/>

        </xs:sequence>

        <xs:anyAttribute namespace="##any" processContents="lax"/>

   </xs:complexType>

 

Regards,

 

Peter Reissner 

Unified Communications R&D - VCFS Team - Avaya, Belleville, Ontario

( Phone (613) 961-2282

Express/personal FAX: (613) 961-2339 mailbox 2282#

reissner@avaya.com 

 



-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/
--------------000303010002010407060606-- From Internet-Drafts@ietf.org Wed Feb 16 10:45:02 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD0E3A6EFF; Wed, 16 Feb 2011 10:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 di+HfhiFYvod; Wed, 16 Feb 2011 10:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA033A6EF6; Wed, 16 Feb 2011 10:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110216184501.17240.14684.idtracker@localhost> Date: Wed, 16 Feb 2011 10:45:01 -0800 Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-12.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 18:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Centralized Conferencing Manipulation Protocol Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-ccmp-12.txt Pages : 111 Date : 2011-02-16 The Centralized Conferencing Manipulation Protocol (CCMP) allows an XCON conferencing system client to create, retrieve, change, and delete objects that describe a centralized conference. CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a state-less, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-ccmp-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-16103350.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Feb 16 10:45:03 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732843A6EFD; Wed, 16 Feb 2011 10:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Y+ofYTFethvk; Wed, 16 Feb 2011 10:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D6C3A6EFB; Wed, 16 Feb 2011 10:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110216184502.17240.92531.idtracker@localhost> Date: Wed, 16 Feb 2011 10:45:02 -0800 Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-examples-08.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 18:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-examples-08.txt Pages : 83 Date : 2011-02-16 This document provides detailed call flows for the scenarios documented in the Centralized Conferencing (XCON) Framework and the XCON Scenarios. The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP). The objective is to provide a base reference for both protocol researchers and developers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-examples-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-examples-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-16103657.I-D@ietf.org> --NextPart-- From mary.ietf.barnes@gmail.com Wed Feb 16 11:18:59 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B063A6D4D for ; Wed, 16 Feb 2011 11:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 9eWmqlaUJcDj for ; Wed, 16 Feb 2011 11:18:58 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id CE28D3A6D33 for ; Wed, 16 Feb 2011 11:18:57 -0800 (PST) Received: by gwb20 with SMTP id 20so834296gwb.31 for ; Wed, 16 Feb 2011 11:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=Do1TEkwLTEgwZnvAHYMymshYH6XAAnt8wShd4zXyvlE=; b=TwnlbrpCRmlURqirLrHVlfosaqFagfLYUHSs9QHuUhh4KDQUzLTqTCvHBUpAG64BS4 NhsSr1pzucDmZduRXHihnm97UNYUzdqh0qeEwYGQ5oVQBjthtCDBbTMaCkAYoho7vQTu KiGYGwE5eo/zj0tPARFBHwPkltuxp0Qp4Kl1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=tQBwH4uuzfXeCF0MnLqmthh2z66+Ta4xVgwheKMJ+LZuevT2+w7AJRmIwdFk03lWy3 trDqQoj4k+zTjKbumacvR5yZWZNe9Pizz8vH0BSko+u6VZ7spRT/u6++3H1SdWsb49q1 vvO4vZKzZiqrJZPO/QwL47tIbDkx/bnrF/UtU= MIME-Version: 1.0 Received: by 10.236.109.168 with SMTP id s28mr1723320yhg.74.1297883966417; Wed, 16 Feb 2011 11:19:26 -0800 (PST) Received: by 10.236.95.35 with HTTP; Wed, 16 Feb 2011 11:19:26 -0800 (PST) Date: Wed, 16 Feb 2011 13:19:26 -0600 Message-ID: From: Mary Barnes To: Robert Sparks Content-Type: multipart/alternative; boundary=0023547c8b43c73316049c6b28e2 Cc: xcon@ietf.org, xcon-chairs@tools.ietf.org Subject: [XCON] Updated draft-ietf-xcon-ccmp-12.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 19:18:59 -0000 --0023547c8b43c73316049c6b28e2 Content-Type: text/plain; charset=ISO-8859-1 Hi Robert and WG, The document has been updated to complete the changes related to issues highlighted during the AD review. Normative text has been added to describe the use of the AUTO_GENERATE_X as a wildcard string in cases where mandatory elements are not yet known by the client per mailing list: http://www.ietf.org/mail-archive/web/xcon/current/msg02499.html While making those changes, the structure of sections 4 and 4.1 were modified, as section 4.1 contained far more than just the Protocol Operations. So, 2 new sections were added to remove the versioning and the alignment of CCMP with the data model in the case of unknown elements through the use of the AUTO_GENERATE_X. That should make it more readable and easier to find the latter two aspects which are really important for the implementation of CCMP. In addition, the following editorial changes were made: 1) Removed the changes section since it was incomplete (all the changes have been summarized on the mailing list). 2) Editorial nits from Keith: http://www.ietf.org/mail-archive/web/xcon/current/msg02476.html 3) operation-type -> operationType in the schema (offline comment from Peter Reissner) A diff is available here: http://trac.tools.ietf.org/wg/xcon/draft-ietf-xcon-ccmp/draft-ietf-xcon-ccmp-12-from-11.diff.html Regards, Mary. ---------- Forwarded message ---------- From: Date: Wed, Feb 16, 2011 at 12:45 PM Subject: I-D Action:draft-ietf-xcon-ccmp-12.txt To: i-d-announce@ietf.org Cc: xcon@ietf.org 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 : Centralized Conferencing Manipulation Protocol Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-ccmp-12.txt Pages : 111 Date : 2011-02-16 The Centralized Conferencing Manipulation Protocol (CCMP) allows an XCON conferencing system client to create, retrieve, change, and delete objects that describe a centralized conference. CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a state-less, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --0023547c8b43c73316049c6b28e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Robert and WG,

The document has been updated to = complete the changes related to issues highlighted during the AD review. = =A0Normative text has been added to describe the=A0use of the AUTO_GENERATE= _X as a wildcard string in cases where mandatory elements are not yet known= by the client per mailing list: =A0 =A0 http://www.ietf.org/mail-archive/= web/xcon/current/msg02499.html =A0
While making those changes, the structure of sections 4 and 4.1 were m= odified, as section 4.1 contained far more than just the Protocol Operation= s. So, 2 new sections were added to remove the versioning and the alignment= of CCMP with the data model in the case of unknown elements through the us= e of the AUTO_GENERATE_X. =A0That should make it more readable and easier t= o find the latter two aspects which are really important for the implementa= tion of CCMP.=A0

In addition, the following editorial changes were made:=
1) Removed the changes section since it was incomplete (all the = changes have been summarized on the mailing list).
3) operation-type -> operationType in the schema =A0(offline commen= t from Peter Reissner)

A diff is available here:
http://trac.tools.ietf.org/wg/x= con/draft-ietf-xcon-ccmp/draft-ietf-xcon-ccmp-12-from-11.diff.html

Regards,
Mary.=A0

---------- Forwarded message ----------
From: <Internet-Drafts@ietf.org>
Date: Wed, Feb 16, 2011 at 12:45 PM
Subject: I-D Action:draft-ietf-xcon-= ccmp-12.txt
To: i-d-announce@ie= tf.org
Cc: xcon@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
This draft is a work item of the Centralized Conferencing Working Group of = the IETF.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Centralized Conferencing Manipu= lation Protocol
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Barnes, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-xcon-ccmp-12.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 111
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-16

The Centralized Conferencing Manipulation Protocol (CCMP) allows an
XCON conferencing system client to create, retrieve, change, and
delete objects that describe a centralized conference. =A0CCMP is a
means to control basic and advanced conference features such as
conference state and capabilities, participants, relative roles, and
details. =A0CCMP is a state-less, XML-based, client server protocol
that carries, in its request and response messages, conference
information in the form of XML documents and fragments conforming to
the centralized conferencing data model schema.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp= -12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--0023547c8b43c73316049c6b28e2-- From mary.ietf.barnes@gmail.com Wed Feb 16 11:19:52 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67BF73A6D5F for ; Wed, 16 Feb 2011 11:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 nPavYGbgoUfn for ; Wed, 16 Feb 2011 11:19:50 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 380043A6D50 for ; Wed, 16 Feb 2011 11:19:50 -0800 (PST) Received: by gyd12 with SMTP id 12so829692gyd.31 for ; Wed, 16 Feb 2011 11:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4fiYcC8FYp087NmHt0sypkM9FAhJ7EQff5+SWBvLFOw=; b=kK7uew0U+vGpyUYoHZnxzU+1SkxVie5H1cOhTA22q5jUQJR5XQKzOO54VAeOV1bfYn amHGG3PJxMtmx9oDgHpB2CuV/Ra0NCY4UeLeA/cTJlZpAlD2/eI4sMZXkv7748osegsr YHiD7YO1MEPnXEhlnda8sabHmbA4cF1tegMPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qm/odebOom9LME37ASi5zyRHfW4NFEfe7l2sOXBqxkkKN8AnpJVeuoRtauAbFkZ/gC 1QAssT/9lFvwQY0VDVt99NQhRnldVlIw8Jcbdm+tCNMcQ1XZC7xyzBPa0vKJ4CjBTgAC I2A6UG+fP6ilGir73prfI8GuVsXkGmDR3UCD8= MIME-Version: 1.0 Received: by 10.236.108.43 with SMTP id p31mr1630994yhg.22.1297884018900; Wed, 16 Feb 2011 11:20:18 -0800 (PST) Received: by 10.236.95.35 with HTTP; Wed, 16 Feb 2011 11:20:18 -0800 (PST) In-Reply-To: <20110216184502.17240.92531.idtracker@localhost> References: <20110216184502.17240.92531.idtracker@localhost> Date: Wed, 16 Feb 2011 13:20:18 -0600 Message-ID: From: Mary Barnes To: Robert Sparks Content-Type: multipart/alternative; boundary=90e6ba4fbe2ee8000a049c6b2bbf Cc: xcon@ietf.org, xcon-chairs@tools.ietf.org Subject: Re: [XCON] I-D Action:draft-ietf-xcon-examples-08.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 19:19:52 -0000 --90e6ba4fbe2ee8000a049c6b2bbf Content-Type: text/plain; charset=ISO-8859-1 The only changes to this document were to correct the use of AUTO_GENERATE_X in some of the examples. Regards, Mary. On Wed, Feb 16, 2011 at 12:45 PM, wrote: > 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 : Centralized Conferencing Manipulation Protocol > (CCMP) Call Flow Examples > Author(s) : M. Barnes, et al. > Filename : draft-ietf-xcon-examples-08.txt > Pages : 83 > Date : 2011-02-16 > > This document provides detailed call flows for the scenarios > documented in the Centralized Conferencing (XCON) Framework and the > XCON Scenarios. The call flows document the use of the interface > between a conference control client and a conference control server > using the Centralized Conferencing Manipulation Protocol (CCMP). The > objective is to provide a base reference for both protocol > researchers and developers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-xcon-examples-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > --90e6ba4fbe2ee8000a049c6b2bbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The only changes to this document were to correct the use of AUTO_GENERATE_= X in some of the examples.=A0

Regards,
Mary.
On Wed, Feb 16, 2011 at 12:45 PM, <Internet-Drafts@= ietf.org> wrote:
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.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Centralized Conferencing Manipu= lation Protocol (CCMP) Call Flow Examples
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Barnes, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-xcon-examples-08.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 83
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-16

This document provides detailed call flows for the scenarios
documented in the Centralized Conferencing (XCON) Framework and the
XCON Scenarios. =A0The call flows document the use of the interface
between a conference control client and a conference control server
using the Centralized Conferencing Manipulation Protocol (CCMP). =A0The
objective is to provide a base reference for both protocol
researchers and developers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-= examples-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--90e6ba4fbe2ee8000a049c6b2bbf-- From rjsparks@nostrum.com Fri Feb 18 14:21:02 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DBB3A6DE8 for ; Fri, 18 Feb 2011 14:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Kxp-XmDqqJ2X for ; Fri, 18 Feb 2011 14:21:01 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id 4A7843A6E7D for ; Fri, 18 Feb 2011 14:21:01 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p1IMKKM9042742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 18 Feb 2011 16:20:20 -0600 (CST) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Feb 2011 16:20:20 -0600 Message-Id: To: xcon@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [XCON] IETF LC requested on draft-ietf-xcon-ccmp, draft-ietf-xcon-common-data-model, and draft-ietf-xcon-examples X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 22:21:02 -0000 Watch for announcement of the the IETF LC on ccmp, common-data-model, = and examples shortly. RjS= From iesg-secretary@ietf.org Fri Feb 18 14:34:49 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354AF3A6DE8; Fri, 18 Feb 2011 14:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5vwXsoPs5Hvd; Fri, 18 Feb 2011 14:34:48 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B733A6D71; Fri, 18 Feb 2011 14:34:48 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110218223448.15711.10845.idtracker@localhost> Date: Fri, 18 Feb 2011 14:34:48 -0800 Cc: xcon@ietf.org Subject: [XCON] Last Call: (Conference Information Data Model for Centralized Conferencing (XCON)) to Proposed Standard X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 22:34:49 -0000 The IESG has received a request from the Centralized Conferencing WG (xcon) to consider the following document: - 'Conference Information Data Model for Centralized Conferencing (XCON)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-xcon-common-data-model/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-xcon-common-data-model/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Fri Feb 18 14:36:23 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1AE43A6D71; Fri, 18 Feb 2011 14:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ZwAV6Faoctox; Fri, 18 Feb 2011 14:36:23 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECEE63A6E4D; Fri, 18 Feb 2011 14:36:22 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110218223622.15783.95652.idtracker@localhost> Date: Fri, 18 Feb 2011 14:36:22 -0800 Cc: xcon@ietf.org Subject: [XCON] Last Call: (Centralized Conferencing Manipulation Protocol) to Proposed Standard X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 22:36:23 -0000 The IESG has received a request from the Centralized Conferencing WG (xcon) to consider the following document: - 'Centralized Conferencing Manipulation Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-xcon-ccmp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-xcon-ccmp/ The following IPR Declarations may be related to this I-D: /ipr/472/ From iesg-secretary@ietf.org Fri Feb 18 14:37:33 2011 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CAD13A6FA5; Fri, 18 Feb 2011 14:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 H3a01lSgVPxQ; Fri, 18 Feb 2011 14:37:32 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD113A6D71; Fri, 18 Feb 2011 14:37:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110218223732.16291.49053.idtracker@localhost> Date: Fri, 18 Feb 2011 14:37:32 -0800 Cc: xcon@ietf.org Subject: [XCON] Last Call: (Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples) to Informational RFC X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 22:37:33 -0000 The IESG has received a request from the Centralized Conferencing WG (xcon) to consider the following document: - 'Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-xcon-examples/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-xcon-examples/ No IPR declarations have been submitted directly on this I-D.