From Internet-Drafts@ietf.org Thu May 5 11:15:02 2011 Return-Path: X-Original-To: xcon@ietfa.amsl.com Delivered-To: xcon@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE15E0688; Thu, 5 May 2011 11:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDIg2UMOamQV; Thu, 5 May 2011 11:15:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F2AE079C; Thu, 5 May 2011 11:15:02 -0700 (PDT) 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.53 Message-ID: <20110505181502.4115.1547.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 11:15:02 -0700 Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-common-data-model-27.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 18:15: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 : Conference Information Data Model for Centralized Conferencing (XCON) Author(s) : O. Novo, et al Filename : draft-ietf-xcon-common-data-model-27.txt Pages : 96 Date : 2011-04-27 [RFC5239] defines the idea of a centralized conferencing (XCON) as an association of participants with a central focus. The state of a conference is represented by a conference object. This document defines an Extensible Markup Language (XML)-based conference information data model to be used for conference objects. 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 [RFC4575]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-27.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-27.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-05110005.I-D@ietf.org> --NextPart-- From internet-drafts@ietf.org Mon May 9 10:38:30 2011 Return-Path: X-Original-To: xcon@ietfa.amsl.com Delivered-To: xcon@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1717FE0875; Mon, 9 May 2011 10:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dbm-zuKdWdMD; Mon, 9 May 2011 10:38:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08037E06EC; Mon, 9 May 2011 10:38:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110509173829.21460.84414.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 10:38:29 -0700 Cc: xcon@ietf.org Subject: [XCON] I-D Action: draft-ietf-xcon-ccmp-13.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:38:30 -0000 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 Grou= p of the IETF. Title : Centralized Conferencing Manipulation Protocol Author(s) : Mary Barnes Chris Boulton Simon Pietro Romano Henning Schulzrinne Filename : draft-ietf-xcon-ccmp-13.txt Pages : 114 Date : 2011-05-09 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-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-13.txt From mary.ietf.barnes@gmail.com Mon May 9 10:52:44 2011 Return-Path: X-Original-To: xcon@ietfa.amsl.com Delivered-To: xcon@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0A3E0883 for ; Mon, 9 May 2011 10:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.148 X-Spam-Level: X-Spam-Status: No, score=-103.148 tagged_above=-999 required=5 tests=[AWL=0.450, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaxy63B3I-lk for ; Mon, 9 May 2011 10:52:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 34CA5E082D for ; Mon, 9 May 2011 10:52:43 -0700 (PDT) Received: by vxg33 with SMTP id 33so329282vxg.31 for ; Mon, 09 May 2011 10:52:42 -0700 (PDT) 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=WC5l+/hB2HUAJmYZrJ2vuRtQffZ/MaxmcHD4aI1CllI=; b=j3sFzUDeEDAps4NWeh+KMafmB6jg7RAf6Z5GJ9a25KXTkebTED+sgCD44/v10MKbrc cCtELleAC3/4qgRdp0I6UPGqBZoDw8yJcfw6scl6s8hcqhggmhQOmm7ryHc47mSt6QNl 8gZmCOZoqXaGdq9M01/A8gVVTzrADvCbnmSuQ= 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=q0Kd3Qnxu0VtBPV+yVjceAUEcnF4HdVaoqsedVmtQ5xUMyNz60IrZZRU9as0PX5QCt DF8D7zqajqwh+kvwz0ZGt/PUANeRfitmZ03Hg6nDsynUlNSzAlt+LVIMcjXgsDNoYUd+ K3119kap6Xc6z8k3xe9huvE1C//YaWOZSeG+Y= MIME-Version: 1.0 Received: by 10.52.97.10 with SMTP id dw10mr1871180vdb.23.1304963562568; Mon, 09 May 2011 10:52:42 -0700 (PDT) Received: by 10.52.160.132 with HTTP; Mon, 9 May 2011 10:52:42 -0700 (PDT) In-Reply-To: <20110509173829.21460.84414.idtracker@ietfa.amsl.com> References: <20110509173829.21460.84414.idtracker@ietfa.amsl.com> Date: Mon, 9 May 2011 12:52:42 -0500 Message-ID: From: Mary Barnes To: xcon@ietf.org Content-Type: multipart/alternative; boundary=20cf307d01ee977aa704a2db811c Cc: Stephen Kent , xcon-chairs@tools.ietf.org, Brian E Carpenter Subject: Re: [XCON] I-D Action: draft-ietf-xcon-ccmp-13.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:52:44 -0000 --20cf307d01ee977aa704a2db811c Content-Type: text/plain; charset=ISO-8859-1 Hi folks, We have updated the document based on IETF Last call comments, including security and general area reviews. A summary of the changes is as follows: 1) Added a new response code, per email discussion 2) Updates to security section based on Stephen Kent's secdir review 3) Reformatting of IANA section for CCMP messages and response codes 4) Few other changes - editorial, clarifications, etc. Please review the diff and let us know ASAP if you have any concerns with the changes. Thanks, Mary. On Mon, May 9, 2011 at 12:38 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 > Author(s) : Mary Barnes > Chris Boulton > Simon Pietro Romano > Henning Schulzrinne > Filename : draft-ietf-xcon-ccmp-13.txt > Pages : 114 > Date : 2011-05-09 > > 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-13.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-13.txt > _______________________________________________ > 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 > --20cf307d01ee977aa704a2db811c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

We have updated the document based on IETF Las= t call comments, including security and general area reviews. =A0

A summary of the changes is as follows:
1) Added = a new response code, per email discussion
2) Updates to security section based on Stephen Kent's secdir revi= ew
3) Reformatting of IANA section for CCMP messages and response= codes
4) Few other changes - editorial, clarifications, etc.=A0<= /div>

Please review the diff and let us know ASAP if you have= any concerns with the changes.

Thanks,
= Mary.=A0

On Mon, May 9, 2011 at 12:38 PM,= <interne= t-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 Centr= alized 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 : Mary Barnes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Chris Boulton
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Simon Pietro Romano
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Henning Schulzrinne
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-xcon-ccmp-13.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 114
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-09

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


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

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-1= 3.txt
_______________________________________________
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

--20cf307d01ee977aa704a2db811c-- From rjsparks@nostrum.com Tue May 17 07:16:38 2011 Return-Path: X-Original-To: xcon@ietfa.amsl.com Delivered-To: xcon@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11306E06A7; Tue, 17 May 2011 07:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.4 X-Spam-Level: X-Spam-Status: No, score=-101.4 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_93=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQS1HACp7lJc; Tue, 17 May 2011 07:16:36 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA37E0665; Tue, 17 May 2011 07:16:36 -0700 (PDT) Received: from [192.168.2.105] (pool-173-57-91-217.dllstx.fios.verizon.net [173.57.91.217]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4HEGA3E054289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 May 2011 09:16:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: Date: Tue, 17 May 2011 09:16:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Henry S. Thompson" X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 173.57.91.217 is authenticated by a trusted mechanism) Cc: Henning Schulzrinne , Alan Johnston , apps-discuss@ietf.org, xcon@ietf.org, Richard Barnes , "iesg@ietf.org IESG" Subject: Re: [XCON] apps-team review of draft-ietf-xcon-ccmp-13 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 14:16:38 -0000 Adding the XCON WG list On May 16, 2011, at 4:04 AM, Henry S. Thompson wrote: > I have been selected as the Applications Area Review Team reviewer for > this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). >=20 > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. >=20 > Document: draft-ietf-xcon-ccmp-13 >=20 > Title: Centralized Conferencing Manipulation Protocol >=20 > Reviewer: Henry S. Thompson >=20 > Review Date: 2011-05-13 >=20 > Summary: This draft is almost ready for publication as a Proposed > Standard but has a few issues that should be fixed before publication >=20 > Major Issues:=20 >=20 > 4.2 Data Management >=20 > 1) The approach to detecting competing updates and their consequences > specified here seems unnecessarily complex. Was the alternative of > including version numbers in _update_ messages (so that the server > could reject any update whose target version had been superseded) > considered and rejected? If so, perhaps a brief explanation of why > it was rejected might be helful at this point. >=20 > 2) In a related point, the statement at the end of this section that > "a client subscribed to . . . notifications . . . will always have > the most up-to-date version" is clearly false, in-so-far as it > implies that such a client is guaranteed success for any update, as > there is clearly a race condition here. >=20 > 4.3 Data Model Compliance >=20 > 1) Again this approach seems unnecessarily complex -- why does the > data model have to constrain the initiation of a conference in this > way. why not simply have messages which request new conference or > new user IDs? >=20 > 2) I'm also confused by the fact that _elements_ described here as > "mandatory" are not required by the schema. Specifically in 5.1 we > will see that the 'confUserID' and 'confObjID' elements, which > correspond precisely to XCON-USERID and XCON-URI which are > described here as mandatory, appear in message type definitions as > minOccurs=3D"0", i.e. as optional. If they are optional, why is the > above gensym complexity needed? If they are not optional, why > doesn't the schema say so? >=20 > 3) It is unusual to refer to aspects of a data model with words such > as 'element' and 'attribute', which are better reserved for use > with respect to _XML serializations_ of data model instances. Ah, > I see by looking at draft-ietf-xcon-common-data-model that the XCON > data model is defined as an XML document. It's undoubtedly too > late to do anything about that, but confounding data models and XML > serializations is usually considered to be a mistake. . . >=20 > 11. XML Schema >=20 > An http URI should be provided where this schema document can be found > on its own, and an update policy for it (or, preferably, _two_ URIs, > one for exactly this schema document, and one which will be updated if > this document is revised or superseded). (Likewise for DataModel.xsd > and rfc4575.xsd.) >=20 > 12.5 CCMP Protocol Registry >=20 > Why are these registries needed? No role is specified for them > anywhere in the body of the document. Registries are not free, and if > all the information in the registry is also in the published schemas > it's not at all clear what purpose they will serve. >=20 > Minor Issues:=20 >=20 > 6.2. Alice gets detailed information about a specific blueprint >=20 > The blueprintResponse message is not schema-valid per ccmp.xsd. On > lines 32 and 33 of the example read > confirm > > The problem really lies in DataModel.xsd -- whereas (correctly) > ccmp.xsd uses xs:token as the base type for enumerated types, > DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string, > and the string value of the above element is "confirm > ", which is not one of the allowed values. The > example should be corrected, or, for preference, the schema in > draft-ietf-xcon-common-data-model should be changed to use xs:token as > the base type for join-handling-type and all other enumerated types. >=20 > A similar problem occurs in the response in 6.3 > (floor-request-handling) >=20 > 6.9 Alice exploits a CCMP server extension >=20 > For compatibility with the actual response given, the extension schema > document should have a target namespace, as follows: >=20 > > = targetNamespace=3D"http://example.com/ccmp-extension-schema.xsd" > xmlns=3D"http://example.com/ccmp-extension-schema.xsd"> >=20 > >=20 > > > > > > > > >=20 > >=20 > Or, better, the example _and_ the schema should be changed to read as > follows: >=20 > > xmlns:ccmp=3D"urn:ietf:params:xml:ns:xcon:ccmp" > xmlns:xcon=3D"urn:ietf:params:xml:ns:xcon-conference-info" > xmlns:example=3D"http://example.com/ccmp-extension"> > xsi:type=3D"ccmp:ccmp-extended-response-message-type"> > xcon-userid:Alice@example.com > xcon:8977794@example.com > retrieve >=20 >=20 > 200 > success > > confSummaryRequest > > Alice's conference > active > true > audio > > > > >=20 > > targetNamespace=3D"http://example.com/ccmp-extension" > xmlns=3D"http://example.com/ccmp-extension"> >=20 > >=20 > > > > > > > > >=20 > >=20 > Otherwise I've checked all the schemas for conformance and the > examples for schema-validity. >=20 > 12.2 XML Schema Registration >=20 > Should include pointers to the RFCs which include the text of the > schema documents named as "DataModel.xsd" and "rfc4575.xsd" in the > schema docuemnt given in section 11. >=20 > 12.3 Media Type Registration >=20 > It seems unlikely that the proposed extension of 'ccmpxml' will see > much use---4 characters seems to be the practical limit for > extensions. >=20 > Nits: One more proofreading pass over the first three sections would > be a good idea. . . >=20 > ht > --=20 > Henry S. Thompson, School of Informatics, University of = Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 = 650-4440 > Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is = forged spam] From mary.ietf.barnes@gmail.com Mon May 23 11:57:54 2011 Return-Path: X-Original-To: xcon@ietfa.amsl.com Delivered-To: xcon@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFB4E06AB; Mon, 23 May 2011 11:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+Syylq3mkSr; Mon, 23 May 2011 11:57:52 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 897DBE06A5; Mon, 23 May 2011 11:57:51 -0700 (PDT) Received: by vxg33 with SMTP id 33so5195053vxg.31 for ; Mon, 23 May 2011 11:57:51 -0700 (PDT) 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=Vl7lqRdBB2D0aBlrzA9jY/Q+EIqimhaJqrbe5qysKDU=; b=OtMi5eqL5SlZPyNHLtY1VKkJM27yG2l+FaXOnTvcw/hCrWnI1gMBRHdvfErXotdffn VQWJ6EA3p7nZOON8+RJp61pYrHUTKpO1fH6uyQnexmGeH+D6MO1UShIO/zEQOfjkogpq rlPu/8REuuA6xDi9eIzl2seezbaU2MyoHhqQM= 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=P2QXOrLoLLrGPRnYIVlQUwKWInSBLjqIyczpIx7XM9L2X6R7VERHxmpQg92yTdeoqc j0GtQhNU6xmDtWpwVuL3Yq2QP6BjKyJZCayuE8RaHIbE3bq78QKDCtsp3mQ1kQJA7Fcr UdzF2Qw/A82YKhfIzSRDEv62RuPPo8a8fd6m0= MIME-Version: 1.0 Received: by 10.52.110.234 with SMTP id id10mr3962231vdb.303.1306177070779; Mon, 23 May 2011 11:57:50 -0700 (PDT) Received: by 10.52.160.132 with HTTP; Mon, 23 May 2011 11:57:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 May 2011 13:57:50 -0500 Message-ID: From: Mary Barnes To: "Henry S. Thompson" Content-Type: multipart/alternative; boundary=bcaec548a2e9514f4104a3f60cc7 Cc: Alan Johnston , apps-discuss@ietf.org, xcon@ietf.org, Richard Barnes , iesg@ietf.org, Henning Schulzrinne Subject: Re: [XCON] apps-team review of draft-ietf-xcon-ccmp-13 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 18:57:54 -0000 --bcaec548a2e9514f4104a3f60cc7 Content-Type: text/plain; charset=ISO-8859-1 Hi Henry, Thank you for your detailed review. Responses are inline below [MB]. Regards, Mary. On Mon, May 16, 2011 at 4:04 AM, Henry S. Thompson wrote: > I have been selected as the Applications Area Review Team reviewer for > this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-xcon-ccmp-13 > > Title: Centralized Conferencing Manipulation Protocol > > Reviewer: Henry S. Thompson > > Review Date: 2011-05-13 > > Summary: This draft is almost ready for publication as a Proposed > Standard but has a few issues that should be fixed before publication > > Major Issues: > > 4.2 Data Management > > 1) The approach to detecting competing updates and their consequences > specified here seems unnecessarily complex. Was the alternative of > including version numbers in _update_ messages (so that the server > could reject any update whose target version had been superseded) > considered and rejected? If so, perhaps a brief explanation of why > it was rejected might be helful at this point. > [MB] The alternative was considered, however, with the XCON model, the server is the only entity that "centralizes" information (in this case, the available conference objects). A client might not have the very last version of a conference object, due to the potential for concurrent operations amongst independent client participants. However, an operation can still succeed if there is no overlap amongst the data that is manipulated. Thus, the server-side mechanism is what guarantees coherence in the data stored. We can add some more text around that. Perhaps, prefacing the paragraph with a statement about the model. [/MB] > > 2) In a related point, the statement at the end of this section that > "a client subscribed to . . . notifications . . . will always have > the most up-to-date version" is clearly false, in-so-far as it > implies that such a client is guaranteed success for any update, as > there is clearly a race condition here. > [MB] Yes, I can see that it's really not properly stated. The statement is intending to say that the client will "get" the most up-to-date version with the next notification - i.e., there is a way to recover in the case that the update was either on an earlier version or no response received. [/MB] > > 4.3 Data Model Compliance > > 1) Again this approach seems unnecessarily complex -- why does the > data model have to constrain the initiation of a conference in this > way. why not simply have messages which request new conference or > new user IDs? > [MB] We do have messages for a new conference and new user IDs. The intent here, was to eliminate the step of requesting those and thus have multiple operations as a result of one request. We can add text around that. [/MB] > > 2) I'm also confused by the fact that _elements_ described here as > "mandatory" are not required by the schema. Specifically in 5.1 we > will see that the 'confUserID' and 'confObjID' elements, which > correspond precisely to XCON-USERID and XCON-URI which are > described here as mandatory, appear in message type definitions as > minOccurs="0", i.e. as optional. If they are optional, why is the > above gensym complexity needed? If they are not optional, why > doesn't the schema say so? > [MB] This is a common practice from what I have seen. This is because the base request type is being reused, thus the elements are not mandatory for each operation that uses the request type. So, the expectation is that it's mandatory for the protocol for specific operations, but not mandatory in the schema for all operations. There may also be confusion in that the mandatory elements being referenced are those in the *body* of the CCMP messages (the elements as defined in the data model document) as opposed to the IDs in the *header* of the CCMP messages defined in this document (confUserID and confObjID). Perhaps this clarification would help? OLD: Since the XML documents carried in the CCMP need to be compliant with the XCON data model... NEW: Since the XML documents carried in the body of CCMP requests/responses need to be compliant with the XCON data model..." [/MB] > > 3) It is unusual to refer to aspects of a data model with words such > as 'element' and 'attribute', which are better reserved for use > with respect to _XML serializations_ of data model instances. Ah, > I see by looking at draft-ietf-xcon-common-data-model that the XCON > data model is defined as an XML document. It's undoubtedly too > late to do anything about that, but confounding data models and XML > serializations is usually considered to be a mistake. . . > [MB] Can you characterize in what sense it is a mistake and what problems it might cause? Or is it purely a nomenclature issue that is inaccurate? I agree that resolving this concern would impact the data model. [/MB] > > 11. XML Schema > > An http URI should be provided where this schema document can be found > on its own, and an update policy for it (or, preferably, _two_ URIs, > one for exactly this schema document, and one which will be updated if > this document is revised or superseded). (Likewise for DataModel.xsd > and rfc4575.xsd.) > [MB] Agreed. [/MB] > > 12.5 CCMP Protocol Registry > > Why are these registries needed? No role is specified for them > anywhere in the body of the document. Registries are not free, and if > all the information in the registry is also in the published schemas > it's not at all clear what purpose they will serve. > [MB] We define the registries as the protocol is extensible and does require specification. The registries also allow a reference to the appropriate document that defines the normative behavior for the new operations and new error codes. This is a standard procedure for RAI area protocols - c.f., HELD (RFC 5985), SIP (RFC 3261), Registry for SIP header field parameters (RFC 3698)... I will note that we don't typically add a reference in the document that we are defining the IANA registries. Is there a particular place you suggest we add such a reference? [/MB] > Minor Issues: > > 6.2. Alice gets detailed information about a specific blueprint > > The blueprintResponse message is not schema-valid per ccmp.xsd. On > lines 32 and 33 of the example read > confirm > > The problem really lies in DataModel.xsd -- whereas (correctly) > ccmp.xsd uses xs:token as the base type for enumerated types, > DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string, > and the string value of the above element is "confirm > ", which is not one of the allowed values. The > example should be corrected, or, for preference, the schema in > draft-ietf-xcon-common-data-model should be changed to use xs:token as > the base type for join-handling-type and all other enumerated types. > > [MB] Agree that the schema in the data model draft could be improved, by changing definitions of the enumberated types. Did you send the authors of that document this comment? Or has that been covered by another apps-team review? "confirm" is one of the allowed tokens in the element (at least in the latest version -- 27 -- of the data model draft.): The "newline" character was introduced for proper formatting of the document, but we agree that is not allowed per the definition above (). So, we should remove the newline. This change likely needs to be done elsewhere in the document. [/MB] A similar problem occurs in the response in 6.3 (floor-request-handling) [MB] Yep. [/MB] > > 6.9 Alice exploits a CCMP server extension > > For compatibility with the actual response given, the extension schema > document should have a target namespace, as follows: > > > targetNamespace="http://example.com/ccmp-extension-schema.xsd > " > xmlns="http://example.com/ccmp-extension-schema.xsd"> > > > > > > > > > > > > > > > Or, better, the example _and_ the schema should be changed to read as > follows: > [MB] Yes, the suggested change below is better. [/MB] > > > xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" > xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" > xmlns:example="http://example.com/ccmp-extension"> > xsi:type="ccmp:ccmp-extended-response-message-type"> > xcon-userid:Alice@example.com > xcon:8977794@example.com > retrieve > > > 200 > success > > confSummaryRequest > > Alice's conference > active > true > audio > > > > > > > targetNamespace="http://example.com/ccmp-extension" > xmlns="http://example.com/ccmp-extension"> > > > > > > > > > > > > > > > Otherwise I've checked all the schemas for conformance and the > examples for schema-validity. > > 12.2 XML Schema Registration > > Should include pointers to the RFCs which include the text of the > schema documents named as "DataModel.xsd" and "rfc4575.xsd" in the > schema docuemnt given in section 11. > [MB] Okay. [/MB] > > 12.3 Media Type Registration > > It seems unlikely that the proposed extension of 'ccmpxml' will see > much use---4 characters seems to be the practical limit for > extensions. > [MB] How about 'ccmp'? > > Nits: One more proofreading pass over the first three sections would > be a good idea. . . > [MB] I'll give it a go, but it appears that it's section 3 that needs some tidying. [/MB] > > ht > -- > Henry S. Thompson, School of Informatics, University of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is forged > spam] > --bcaec548a2e9514f4104a3f60cc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Henry,=A0

Thank you for your detailed review. =A0Resp= onses are inline below [MB].

Regards,
Ma= ry.

On Mon, May 16, 2011 at 4:04 AM, Henr= y S. Thompson <ht@inf.ed.ac.uk> wrote:
I have been selected as the Applications Are= a Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review= -team).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-xcon-ccmp-13

Title: Centralized Conferencing Manipulation Protocol

Reviewer: Henry S. Thompson

Review Date: 2011-05-13

Summary: This draft is almost ready for publication as a Proposed
Standard but has a few issues that should be fixed before publication

Major Issues:

4.2 Data Management

1) The approach to detecting competing updates and their consequences
=A0 specified here seems unnecessarily complex. =A0Was the alternative of<= br> =A0 including version numbers in _update_ messages (so that the server
=A0 could reject any update whose target version had been superseded)
=A0 considered and rejected? =A0If so, perhaps a brief explanation of why<= br> =A0 it was rejected might be helful at this point.
[M= B] =A0=A0The alternative was c= onsidered, however, with the XCON model, the server is the only entity that= "centralizes" information (in this case, the available conferenc= e objects). A client might not have the very last version of a conference o= bject, due to the potential for concurrent operations amongst independent c= lient participants. However, an operation can still succeed if there is no = overlap amongst the data that is manipulated. =A0Thus, the server-side mech= anism is what guarantees coherence in the data stored. =A0We can add some m= ore text around that. =A0Perhaps, prefacing the paragraph with a statement = about the model. [/MB]

2) In a related point, the statement at the end of this section that
=A0 "a client subscribed to . . . notifications . . . will always hav= e
=A0 the most up-to-date version" is clearly false, in-so-far as it =A0 implies that such a client is guaranteed success for any update, as =A0 there is clearly a race condition here.
[MB] Yes,= I can see that it's really not properly stated. The statement is inten= ding to say that the client will "get" the most up-to-date versio= n with the next notification - i.e., there is a way to recover in the case = that the update was either on an earlier version or no response received. = =A0[/MB]=A0

4.3 Data Model Compliance

1) Again this approach seems unnecessarily complex -- why does the
=A0 data model have to constrain the initiation of a conference in this =A0 way. =A0why not simply have messages which request new conference or =A0 new user IDs?
[MB] We do have messages for a new = conference and new user IDs. The intent here, was to eliminate the step of = requesting those and thus have multiple operations as a result of one reque= st. =A0We can add text around that. [/MB]=A0

2) I'm also confused by the fact that _elements_ described here as
=A0 "mandatory" are not required by the schema. =A0Specifically = in 5.1 we
=A0 will see that the 'confUserID' and 'confObjID' element= s, which
=A0 correspond precisely to XCON-USERID and XCON-URI which are
=A0 described here as mandatory, appear in message type definitions as
=A0 minOccurs=3D"0", i.e. as optional. =A0If they are optional, = why is the
=A0 above gensym complexity needed? =A0If they are not optional, why
=A0 doesn't the schema say so?
[MB] This is a com= mon practice from what I have seen. This is because the base request type i= s being reused, thus the elements are not mandatory for each operation that= uses the request type. =A0So, the expectation is that it's mandatory f= or the protocol for specific operations, but not mandatory in the schema fo= r all operations. =A0=A0

There may also be confusion in that the mandatory eleme= nts being referenced are those in the *body* of the CCMP messages (the elem= ents as defined in the data model document) as opposed to the IDs in the *h= eader* of the CCMP messages defined in this document (confUserID and confObjID). =A0

Perhaps this clarification would help?=A0
OLD:
=A0Since the XML documents carried in the= CCMP need to be compliant with the XCON data model...
NEW:
=A0Since= the XML documents carried in the body of CCMP requests/responses need to b= e compliant with the XCON data model..."

=A0[/MB]=A0

3) It is unusual to refer to aspects of a data model with words such
=A0 as 'element' and 'attribute', which are better reserve= d for use
=A0 with respect to _XML serializations_ of data model instances. =A0Ah, =A0 I see by looking at draft-ietf-xcon-common-data-model that the XCON =A0 data model is defined as an XML document. =A0It's undoubtedly too<= br> =A0 late to do anything about that, but confounding data models and XML =A0 serializations is usually considered to be a mistake. . .
[MB] Can you characterize in what sense it is a mistake and what p= roblems it might cause? =A0Or is it purely a nomenclature =A0issue that is = inaccurate? =A0I agree that resolving this concern would impact the data mo= del. [/MB]

11. XML Schema

An http URI should be provided where this schema document can be found
on its own, and an update policy for it (or, preferably, _two_ URIs,
one for exactly this schema document, and one which will be updated if
this document is revised or superseded). =A0(Likewise for DataModel.xsd
and rfc4575.xsd.)
[MB] Agreed. [/MB]=A0

12.5 CCMP Protocol Registry

Why are these registries needed? =A0No role is specified for them
anywhere in the body of the document. Registries are not free, and if
all the information in the registry is also in the published schemas
it's not at all clear what purpose they will serve.
[MB] We define the registries as the protocol is extensible and does requ= ire specification. =A0The registries also allow a reference to the appropri= ate document that defines the normative behavior for the new operations and= new error codes. =A0This is a standard procedure for RAI area protocols - = c.f., HELD (RFC 5985), SIP (RFC 3261), Registry for SIP header field parame= ters (RFC 3698)...
I will note that we don't typically add a reference in the documen= t that we are defining the IANA registries. =A0Is there a particular place = you suggest we add such a reference?=A0
[/MB]
Minor Issues:

6.2. Alice gets detailed information about a specific blueprint

The blueprintResponse message is not schema-valid per ccmp.xsd. =A0On
lines 32 and 33 of the example read
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<xcon:floor-request-handling>= confirm
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</xcon:floor-request-handlin= g>
The problem really lies in DataModel.xsd -- whereas (correctly)
ccmp.xsd uses xs:token as the base type for enumerated types,
DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string,
and the string value of the above element is "confirm
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0", which is not one of the= allowed values. =A0The
example should be corrected, or, for preference, the schema in
draft-ietf-xcon-common-data-model should be changed to use xs:token as
the base type for join-handling-type and all other enumerated types.
[MB]=A0
=A0Agree that the schema in the data model draft could be improved, = by changing definitions of the enumberated types. =A0Did you send the autho= rs of that document this comment? =A0Or has that been covered by another ap= ps-team review? =A0

"confirm" is one of the= allowed tokens in the <xcon:floor-request-handling> element (at leas= t in the latest version -- 27 -- of the =A0data model draft.):
<xs:simpleType name=3D"floor=
-request-handling-type">
      <xs:restriction base=3D"xs:string">
        <xs:pattern value=3D"block"/>
        <xs:pattern value=3D"confirm"/>
        <xs:pattern value=3D".+"/>
      </xs:restriction>
</xs:simpleType>

The =
"newline" character was introduced for proper formatting of the d=
ocument, but we agree that is  not allowed per the definition above (<xs=
:pattern value=3D".+"/>). So, we should remove the newline. Th=
is change likely needs to be done elsewhere in the document.=20
[/MB]=A0


A similar problem o= ccurs in the response in 6.3
(floor-request-handling)
<= span class=3D"Apple-style-span" style=3D"border-collapse: separate; font-fa= mily: arial; font-size: small; ">[MB] Yep. [/MB]

6.9 Alice exploits a CCMP server extension

For compatibility with the actual response given, the extension schema
document should have a target namespace, as follows:

=A0 <?xml version=3D"1.0" encoding=3D"UTF-8"?> =A0 <xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
=A0 =A0 =A0 =A0 =A0 =A0 =A0targetNamespace=3D"http://example.com/ccmp= -extension-schema.xsd"
=A0 =A0 =A0 =A0 =A0 =A0 =A0xmlns=3D"http://example.com/ccmp-extension= -schema.xsd">

=A0 =A0 <xs:element name=3D"confSummary" type=3D"conf-su= mmary-type"/>

=A0 =A0 <xs:complexType name=3D"conf-summary-type">
=A0 =A0 =A0 <xs:sequence>
=A0 =A0 =A0 =A0 <xs:element name=3D"title" type=3D"xs:st= ring"/>
=A0 =A0 =A0 =A0 <xs:element name=3D"status" type=3D"xs:s= tring"/>
=A0 =A0 =A0 =A0 <xs:element name=3D"public" type=3D"xs:b= oolean"/>
=A0 =A0 =A0 =A0 <xs:element name=3D"media" type=3D"xs:st= ring"/>
=A0 =A0 =A0 </xs:sequence>
=A0 =A0 </xs:complexType>

=A0 </xs:schema>

Or, better, the example _and_ the schema should be changed to read as
follows:
[MB] Yes, the suggested change below is bette= r. [/MB]=A0

=A0 <?xml version=3D"1.0" encoding=3D"UTF-8" standa= lone=3D"yes"?>
=A0 =A0<ccmp:ccmpResponse xmlns:info=3D"urn:ietf:params:xml:ns:con= ference-info"
=A0 =A0 =A0 =A0 =A0 xmlns:ccmp=3D"urn:ietf:params:xml:ns:xcon:ccmp&qu= ot;
=A0 =A0 =A0 =A0 =A0 xmlns:xcon=3D"urn:ietf:params:xml:ns:xcon-confere= nce-info"
=A0 =A0 =A0 =A0 =A0 xmlns:example=3D"http://example.com/ccmp-extension"= >
=A0 =A0 =A0<ccmpResponse xmlns:xsi=3D"http://www.w3.org/2001/XMLSchem= a-instance"
=A0 =A0 =A0 =A0 =A0xsi:type=3D"ccmp:ccmp-extended-response-message-ty= pe">
=A0 =A0 =A0 =A0 =A0<confUserID>xcon-userid:Alice@example.com</confU= serID>
=A0 =A0 =A0 =A0 =A0<confObjID>xcon:8977794@example.com</confObjID> =A0 =A0 =A0 =A0 =A0<operation>retrieve</operation>


=A0 =A0 =A0 =A0 =A0<response-code>200</response-code>
=A0 =A0 =A0 =A0 =A0<response-string>success</response-string><= br> =A0 =A0 =A0 =A0 =A0<ccmp:extendedResponse>
=A0 =A0 =A0 =A0 =A0 =A0 <extensionName>confSummaryRequest</extens= ionName>
=A0 =A0 =A0 =A0 =A0 =A0 <example:confSummary>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <title> Alice's conference </= title>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <status> active </status>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <public> true </public>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <media> audio </media>
=A0 =A0 =A0 =A0 =A0 =A0 </example:confSummary>
=A0 =A0 =A0 =A0 =A0</ccmp:extendedResponse>
=A0 =A0 =A0</ccmpResponse>
=A0 =A0</ccmp:ccmpResponse>

=A0 =A0<?xml version=3D"1.0" encoding=3D"UTF-8"?>= ;
=A0 =A0<xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 targetNamespace=3D"http://example.com/ccmp-extension= "
=A0 =A0 =A0 =A0 =A0 =A0 =A0 xmlns=3D"http://example.com/ccmp-extension"= >

=A0 =A0 =A0<xs:element name=3D"confSummary" type=3D"conf= -summary-type"/>

=A0 =A0 =A0<xs:complexType name=3D"conf-summary-type">
=A0 =A0 =A0 =A0<xs:sequence>
=A0 =A0 =A0 =A0 =A0<xs:element name=3D"title" type=3D"xs= :string"/>
=A0 =A0 =A0 =A0 =A0<xs:element name=3D"status" type=3D"x= s:string"/>
=A0 =A0 =A0 =A0 =A0<xs:element name=3D"public" type=3D"x= s:boolean"/>
=A0 =A0 =A0 =A0 =A0<xs:element name=3D"media" type=3D"xs= :string"/>
=A0 =A0 =A0 =A0</xs:sequence>
=A0 =A0 =A0</xs:complexType>

=A0 =A0</xs:schema>

Otherwise I've checked all the schemas for conformance and the
examples for schema-validity.

12.2 XML Schema Registration

Should include pointers to the RFCs which include the text of the
schema documents named as "DataModel.xsd" and "rfc4575.xsd&q= uot; in the
schema docuemnt given in section 11.
[MB] Okay. [/MB]= =A0

12.3 Media Type Registration

It seems unlikely that the proposed extension of 'ccmpxml' will see=
much use---4 characters seems to be the practical limit for
extensions.
[MB] How about 'ccmp'? =A0

Nits: One more proofreading pass over the first three sections would
be a good idea. . .
[MB] I'll give it a go, but it= appears that it's section 3 that needs some tidying. [/MB]=A0

ht
--
=A0 =A0 =A0 Henry S. Thompson, School of Informatics, University of Edinbu= rgh
=A0 =A0 =A010 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650= -4440
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 URL: http://www.ltg.ed.ac.uk/~ht/
=A0[mail from me _always_ has a .sig like this -- mail without it is forged= spam]

--bcaec548a2e9514f4104a3f60cc7-- From mary.ietf.barnes@gmail.com Mon May 23 11:59:28 2011 Return-Path: X-Original-To: xcon@ietfa.amsl.com Delivered-To: xcon@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D652DE06D1; Mon, 23 May 2011 11:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjNAxPAWpBWu; Mon, 23 May 2011 11:59:27 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADF0E06AB; Mon, 23 May 2011 11:59:26 -0700 (PDT) Received: by vxg33 with SMTP id 33so5196316vxg.31 for ; Mon, 23 May 2011 11:59:26 -0700 (PDT) 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=8CnjjX8xsrxwUJ871/ag5b79cO1bkpe0czS6d+sndN8=; b=QGa+pr4hiTeXsBCoo4n+ScBsViwtRPbBjgXhHE4BmuG+jZFeR2hVFEkAIEFx24hS06 IchX7p+A6gnpP0Pludq9aDe4ew9lTv1HoMC/vkHK8o643PskGKWsovj1M4Odldb/dp00 Gnp8Z86Xai/Um6y7ZEqSUE7SGNU1MhNsLUoxc= 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=DX8ENW8BvePIWbgGO3B4WC+kAj8TNzT/V60/N1k+QyWJ3beTOsz/0b/2k7vQu3/alx fHwNo+5+p5pXWnKQ4Bug4xLc8+3IGMK3Tzwaz26RIkzK1iyE3X7VmSK6HSmE+lU3boa4 TFFRIVVul/Ijhix9ji7EYK8k/MZH2hMVm8PI8= MIME-Version: 1.0 Received: by 10.52.97.10 with SMTP id dw10mr276529vdb.23.1306177165912; Mon, 23 May 2011 11:59:25 -0700 (PDT) Received: by 10.52.160.132 with HTTP; Mon, 23 May 2011 11:59:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 May 2011 13:59:25 -0500 Message-ID: From: Mary Barnes To: "Henry S. Thompson" Content-Type: multipart/alternative; boundary=20cf307d01eefceb6c04a3f6119f Cc: Alan Johnston , apps-discuss@ietf.org, xcon@ietf.org, iesg@ietf.org, Henning Schulzrinne Subject: Re: [XCON] apps-team review of draft-ietf-xcon-ccmp-13 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 18:59:29 -0000 --20cf307d01eefceb6c04a3f6119f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm resending as Richard Barnes (XCON WG co-chair) email was incorrect and = I want to make sure he's included in any follow-up. On Mon, May 23, 2011 at 1:57 PM, Mary Barnes wr= ote: > Hi Henry, > > Thank you for your detailed review. Responses are inline below [MB]. > > Regards, > Mary. > > On Mon, May 16, 2011 at 4:04 AM, Henry S. Thompson wrote= : > >> I have been selected as the Applications Area Review Team reviewer for >> this draft (for background on apps-review, please see >> http://www.apps.ietf.org/content/applications-area-review-team). >> >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-xcon-ccmp-13 >> >> Title: Centralized Conferencing Manipulation Protocol >> >> Reviewer: Henry S. Thompson >> >> Review Date: 2011-05-13 >> >> Summary: This draft is almost ready for publication as a Proposed >> Standard but has a few issues that should be fixed before publication >> >> Major Issues: >> >> 4.2 Data Management >> >> 1) The approach to detecting competing updates and their consequences >> specified here seems unnecessarily complex. Was the alternative of >> including version numbers in _update_ messages (so that the server >> could reject any update whose target version had been superseded) >> considered and rejected? If so, perhaps a brief explanation of why >> it was rejected might be helful at this point. >> > [MB] The alternative was considered, however, with the XCON model, the > server is the only entity that "centralizes" information (in this case, t= he > available conference objects). A client might not have the very last vers= ion > of a conference object, due to the potential for concurrent operations > amongst independent client participants. However, an operation can still > succeed if there is no overlap amongst the data that is manipulated. Thu= s, > the server-side mechanism is what guarantees coherence in the data stored= . > We can add some more text around that. Perhaps, prefacing the paragraph > with a statement about the model. [/MB] > >> >> 2) In a related point, the statement at the end of this section that >> "a client subscribed to . . . notifications . . . will always have >> the most up-to-date version" is clearly false, in-so-far as it >> implies that such a client is guaranteed success for any update, as >> there is clearly a race condition here. >> > [MB] Yes, I can see that it's really not properly stated. The statement i= s > intending to say that the client will "get" the most up-to-date version w= ith > the next notification - i.e., there is a way to recover in the case that = the > update was either on an earlier version or no response received. [/MB] > >> >> 4.3 Data Model Compliance >> >> 1) Again this approach seems unnecessarily complex -- why does the >> data model have to constrain the initiation of a conference in this >> way. why not simply have messages which request new conference or >> new user IDs? >> > [MB] We do have messages for a new conference and new user IDs. The inten= t > here, was to eliminate the step of requesting those and thus have multipl= e > operations as a result of one request. We can add text around that. [/MB= ] > >> >> 2) I'm also confused by the fact that _elements_ described here as >> "mandatory" are not required by the schema. Specifically in 5.1 we >> will see that the 'confUserID' and 'confObjID' elements, which >> correspond precisely to XCON-USERID and XCON-URI which are >> described here as mandatory, appear in message type definitions as >> minOccurs=3D"0", i.e. as optional. If they are optional, why is the >> above gensym complexity needed? If they are not optional, why >> doesn't the schema say so? >> > [MB] This is a common practice from what I have seen. This is because the > base request type is being reused, thus the elements are not mandatory fo= r > each operation that uses the request type. So, the expectation is that i= t's > mandatory for the protocol for specific operations, but not mandatory in = the > schema for all operations. > > There may also be confusion in that the mandatory elements being referenc= ed > are those in the *body* of the CCMP messages (the elements as defined in = the > data model document) as opposed to the IDs in the *header* of the CCMP > messages defined in this document (confUserID and confObjID). > > Perhaps this clarification would help? > OLD: > Since the XML documents carried in the CCMP need to be compliant with th= e > XCON data model... > NEW: > Since the XML documents carried in the body of CCMP requests/responses > need to be compliant with the XCON data model..." > > [/MB] > >> >> 3) It is unusual to refer to aspects of a data model with words such >> as 'element' and 'attribute', which are better reserved for use >> with respect to _XML serializations_ of data model instances. Ah, >> I see by looking at draft-ietf-xcon-common-data-model that the XCON >> data model is defined as an XML document. It's undoubtedly too >> late to do anything about that, but confounding data models and XML >> serializations is usually considered to be a mistake. . . >> > [MB] Can you characterize in what sense it is a mistake and what problems > it might cause? Or is it purely a nomenclature issue that is inaccurate= ? > I agree that resolving this concern would impact the data model. [/MB] > >> >> 11. XML Schema >> >> An http URI should be provided where this schema document can be found >> on its own, and an update policy for it (or, preferably, _two_ URIs, >> one for exactly this schema document, and one which will be updated if >> this document is revised or superseded). (Likewise for DataModel.xsd >> and rfc4575.xsd.) >> > [MB] Agreed. [/MB] > >> >> 12.5 CCMP Protocol Registry >> >> Why are these registries needed? No role is specified for them >> anywhere in the body of the document. Registries are not free, and if >> all the information in the registry is also in the published schemas >> it's not at all clear what purpose they will serve. >> > [MB] We define the registries as the protocol is extensible and does > require specification. The registries also allow a reference to the > appropriate document that defines the normative behavior for the new > operations and new error codes. This is a standard procedure for RAI are= a > protocols - c.f., HELD (RFC 5985), SIP (RFC 3261), Registry for SIP heade= r > field parameters (RFC 3698)... > I will note that we don't typically add a reference in the document that = we > are defining the IANA registries. Is there a particular place you sugges= t > we add such a reference? > [/MB] > >> Minor Issues: >> >> >> 6.2. Alice gets detailed information about a specific blueprint >> >> The blueprintResponse message is not schema-valid per ccmp.xsd. On >> lines 32 and 33 of the example read >> confirm >> >> The problem really lies in DataModel.xsd -- whereas (correctly) >> ccmp.xsd uses xs:token as the base type for enumerated types, >> DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string, >> and the string value of the above element is "confirm >> ", which is not one of the allowed values. The >> example should be corrected, or, for preference, the schema in >> draft-ietf-xcon-common-data-model should be changed to use xs:token as >> the base type for join-handling-type and all other enumerated types. >> >> [MB] > Agree that the schema in the data model draft could be improved, by > changing definitions of the enumberated types. Did you send the authors = of > that document this comment? Or has that been covered by another apps-tea= m > review? > > "confirm" is one of the allowed tokens in the > element (at least in the latest version -- 27 -- of the data model draft= .): > > > > > > > > > > The "newline" character was introduced for proper formatting of the docum= ent, but we agree that is not allowed per the definition above (). So, we should remove the newline. This change likely nee= ds to be done elsewhere in the document. > > [/MB] > > > A similar problem occurs in the response in 6.3 > (floor-request-handling) > [MB] Yep. [/MB] > >> >> 6.9 Alice exploits a CCMP server extension >> >> For compatibility with the actual response given, the extension schema >> document should have a target namespace, as follows: >> >> >> > targetNamespace=3D" >> http://example.com/ccmp-extension-schema.xsd" >> xmlns=3D"http://example.com/ccmp-extension-schema.xsd"> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Or, better, the example _and_ the schema should be changed to read as >> follows: >> > [MB] Yes, the suggested change below is better. [/MB] > >> >> >> > xmlns:ccmp=3D"urn:ietf:params:xml:ns:xcon:ccmp" >> xmlns:xcon=3D"urn:ietf:params:xml:ns:xcon-conference-info" >> xmlns:example=3D"http://example.com/ccmp-extension"> >> > xsi:type=3D"ccmp:ccmp-extended-response-message-type"> >> xcon-userid:Alice@example.com >> xcon:8977794@example.com >> retrieve >> >> >> 200 >> success >> >> confSummaryRequest >> >> Alice's conference >> active >> true >> audio >> >> >> >> >> >> >> > targetNamespace=3D"http://example.com/ccmp-extension" >> xmlns=3D"http://example.com/ccmp-extension"> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Otherwise I've checked all the schemas for conformance and the >> examples for schema-validity. >> >> 12.2 XML Schema Registration >> >> Should include pointers to the RFCs which include the text of the >> schema documents named as "DataModel.xsd" and "rfc4575.xsd" in the >> schema docuemnt given in section 11. >> > [MB] Okay. [/MB] > >> >> 12.3 Media Type Registration >> >> It seems unlikely that the proposed extension of 'ccmpxml' will see >> much use---4 characters seems to be the practical limit for >> extensions. >> > [MB] How about 'ccmp'? > >> >> Nits: One more proofreading pass over the first three sections would >> be a good idea. . . >> > [MB] I'll give it a go, but it appears that it's section 3 that needs som= e > tidying. [/MB] > >> >> ht >> -- >> Henry S. Thompson, School of Informatics, University of Edinburgh >> 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-444= 0 >> Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk >> URL: http://www.ltg.ed.ac.uk/~ht/ >> [mail from me _always_ has a .sig like this -- mail without it is forge= d >> spam] >> > > --20cf307d01eefceb6c04a3f6119f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm resending as Richard Barnes (XCON WG co-chair) email was incorrect = and I want to make sure he's included in any follow-up.

On Mon, May 23, 2011 at 1:57 PM, Mary Barnes <mary.ietf.barnes= @gmail.com> wrote:
Hi Henry,=A0

Thank you for your detailed review. =A0Responses are inline below [M= B].

Regards,
Mary.

On Mon, May 16, 2011 at 4:04 AM, Henry S. Thomp= son <ht@inf.ed.ac.uk> wrote:
I have been selected as the Applications Are= a Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review= -team).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-xcon-ccmp-13

Title: Centralized Conferencing Manipulation Protocol

Reviewer: Henry S. Thompson

Review Date: 2011-05-13

Summary: This draft is almost ready for publication as a Proposed
Standard but has a few issues that should be fixed before publication

Major Issues:

4.2 Data Management

1) The approach to detecting competing updates and their consequences
=A0 specified here seems unnecessarily complex. =A0Was the alternative of<= br> =A0 including version numbers in _update_ messages (so that the server
=A0 could reject any update whose target version had been superseded)
=A0 considered and rejected? =A0If so, perhaps a brief explanation of why<= br> =A0 it was rejected might be helful at this point.
<= div>[MB] =A0=A0The alternative was considered, however, with the= XCON model, the server is the only entity that "centralizes" inf= ormation (in this case, the available conference objects). A client might n= ot have the very last version of a conference object, due to the potential = for concurrent operations amongst independent client participants. However,= an operation can still succeed if there is no overlap amongst the data tha= t is manipulated. =A0Thus, the server-side mechanism is what guarantees coh= erence in the data stored. =A0We can add some more text around that. =A0Per= haps, prefacing the paragraph with a statement about the model. [/MB]

2) In a related point, the statement at the end of this section that
=A0 "a client subscribed to . . . notifications . . . will always hav= e
=A0 the most up-to-date version" is clearly false, in-so-far as it =A0 implies that such a client is guaranteed success for any update, as =A0 there is clearly a race condition here.
[MB] Yes, I can see that it's really not properly stated= . The statement is intending to say that the client will "get" th= e most up-to-date version with the next notification - i.e., there is a way= to recover in the case that the update was either on an earlier version or= no response received. =A0[/MB]=A0

4.3 Data Model Compliance

1) Again this approach seems unnecessarily complex -- why does the
=A0 data model have to constrain the initiation of a conference in this =A0 way. =A0why not simply have messages which request new conference or =A0 new user IDs?
[MB] We do = have messages for a new conference and new user IDs. The intent here, was t= o eliminate the step of requesting those and thus have multiple operations = as a result of one request. =A0We can add text around that. [/MB]=A0

2) I'm also confused by the fact that _elements_ described here as
=A0 "mandatory" are not required by the schema. =A0Specifically = in 5.1 we
=A0 will see that the 'confUserID' and 'confObjID' element= s, which
=A0 correspond precisely to XCON-USERID and XCON-URI which are
=A0 described here as mandatory, appear in message type definitions as
=A0 minOccurs=3D"0", i.e. as optional. =A0If they are optional, = why is the
=A0 above gensym complexity needed? =A0If they are not optional, why
=A0 doesn't the schema say so?
[MB] This is a common practice from what I have seen. This is because= the base request type is being reused, thus the elements are not mandatory= for each operation that uses the request type. =A0So, the expectation is t= hat it's mandatory for the protocol for specific operations, but not ma= ndatory in the schema for all operations. =A0=A0

There may also be confusion in that the mandatory= elements being referenced are those in the *body* of the CCMP messages (th= e elements as defined in the data model document) as opposed to the IDs in = the *header* of the CCMP messages defined in this document (conf= UserID and confObjID). =A0

Perhaps this clarification would help?=A0
OLD:
=A0Since the XML documents carried in the CCMP need to be compliant with th= e XCON data model...
NEW:
=A0Since the XML documen= ts carried in the body of CCMP requests/responses need to be compliant with= the XCON data model..."

=A0[/MB]=A0

3) It is unusual to refer to aspects of a data model with words such
=A0 as 'element' and 'attribute', which are better reserve= d for use
=A0 with respect to _XML serializations_ of data model instances. =A0Ah, =A0 I see by looking at draft-ietf-xcon-common-data-model that the XCON =A0 data model is defined as an XML document. =A0It's undoubtedly too<= br> =A0 late to do anything about that, but confounding data models and XML =A0 serializations is usually considered to be a mistake. . .
[MB] Can you characterize in what sense it is a mistake and = what problems it might cause? =A0Or is it purely a nomenclature =A0issue th= at is inaccurate? =A0I agree that resolving this concern would impact the d= ata model. [/MB]

11. XML Schema

An http URI should be provided where this schema document can be found
on its own, and an update policy for it (or, preferably, _two_ URIs,
one for exactly this schema document, and one which will be updated if
this document is revised or superseded). =A0(Likewise for DataModel.xsd
and rfc4575.xsd.)
[MB] Agreed. [/MB]=A0

12.5 CCMP Protocol Registry

Why are these registries needed? =A0No role is specified for them
anywhere in the body of the document. Registries are not free, and if
all the information in the registry is also in the published schemas
it's not at all clear what purpose they will serve.
[MB] We define the registries as the protocol is = extensible and does require specification. =A0The registries also allow a r= eference to the appropriate document that defines the normative behavior fo= r the new operations and new error codes. =A0This is a standard procedure f= or RAI area protocols - c.f., HELD (RFC 5985), SIP (RFC 3261), Registry for= SIP header field parameters (RFC 3698)...
I will note that we don't typically add a reference in the documen= t that we are defining the IANA registries. =A0Is there a particular place = you suggest we add such a reference?=A0
[/MB]
Minor Issues:


6.2. Alice gets detailed information about a specific blueprint

The blueprintResponse message is not schema-valid per ccmp.xsd. =A0On
lines 32 and 33 of the example read
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<xcon:floor-request-handling>= confirm
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</xcon:floor-request-handlin= g>
The problem really lies in DataModel.xsd -- whereas (correctly)
ccmp.xsd uses xs:token as the base type for enumerated types,
DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string,
and the string value of the above element is "confirm
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0", which is not one of the= allowed values. =A0The
example should be corrected, or, for preference, the schema in
draft-ietf-xcon-common-data-model should be changed to use xs:token as
the base type for join-handling-type and all other enumerated types.
[MB]=A0
=A0Agree that the sch= ema in the data model draft could be improved, by changing definitions of t= he enumberated types. =A0Did you send the authors of that document this com= ment? =A0Or has that been covered by another apps-team review? =A0

"confirm" is one= of the allowed tokens in the <xcon:floor-request-handling> element (= at least in the latest version -- 27 -- of the =A0data model draft.):
<xs:simpleType nam=
e=3D"floor-request-handling-type">
      <xs:restriction base=3D"xs:string">
        <xs:pattern value=3D"block"/>
        <xs:pattern value=3D"confirm"/>
        <xs:pattern value=3D".+"/>
      </xs:restriction>
</xs:simpleType>


The "newline" c=
haracter was introduced for proper formatting of the document, but we agree=
 that is  not allowed per the definition above (<xs:pattern value=3D&quo=
t;.+"/>). So, we should remove the newline. This change likely need=
s to be done elsewhere in the document.=20
[/MB]=A0


A similar problem occurs in the response in 6.3
(f= loor-request-handling)
[MB] Yep. [/MB]

6.9 Alice exploits a CCMP server extension

For compatibility with the actual response given, the extension schema
document should have a target namespace, as follows:

=A0 <?xml version=3D"1.0" encoding=3D"UTF-8"?> =A0 <xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
=A0 =A0 =A0 =A0 =A0 =A0 =A0targetNamespace=3D"http://example.com/ccmp= -extension-schema.xsd"
=A0 =A0 =A0 =A0 =A0 =A0 =A0xmlns=3D"http://example.com/ccmp-extension= -schema.xsd">

=A0 =A0 <xs:element name=3D"confSummary" type=3D"conf-su= mmary-type"/>

=A0 =A0 <xs:complexType name=3D"conf-summary-type">
=A0 =A0 =A0 <xs:sequence>
=A0 =A0 =A0 =A0 <xs:element name=3D"title" type=3D"xs:st= ring"/>
=A0 =A0 =A0 =A0 <xs:element name=3D"status" type=3D"xs:s= tring"/>
=A0 =A0 =A0 =A0 <xs:element name=3D"public" type=3D"xs:b= oolean"/>
=A0 =A0 =A0 =A0 <xs:element name=3D"media" type=3D"xs:st= ring"/>
=A0 =A0 =A0 </xs:sequence>
=A0 =A0 </xs:complexType>

=A0 </xs:schema>

Or, better, the example _and_ the schema should be changed to read as
follows:
[MB] Yes, the suggested change below is= better. [/MB]=A0

=A0 <?xml version=3D"1.0" encoding=3D"UTF-8" standa= lone=3D"yes"?>
=A0 =A0<ccmp:ccmpResponse xmlns:info=3D"urn:ietf:params:xml:ns:con= ference-info"
=A0 =A0 =A0 =A0 =A0 xmlns:ccmp=3D"urn:ietf:params:xml:ns:xcon:ccmp&qu= ot;
=A0 =A0 =A0 =A0 =A0 xmlns:xcon=3D"urn:ietf:params:xml:ns:xcon-confere= nce-info"
=A0 =A0 =A0 =A0 =A0 xmlns:example=3D"http://example.com/ccmp-extension"= >
=A0 =A0 =A0<ccmpResponse xmlns:xsi=3D"http://www.w3.org/2001/XMLSchem= a-instance"
=A0 =A0 =A0 =A0 =A0xsi:type=3D"ccmp:ccmp-extended-response-message-ty= pe">
=A0 =A0 =A0 =A0 =A0<confUserID>xcon-userid:Alice@example.com</confU= serID>
=A0 =A0 =A0 =A0 =A0<confObjID>xcon:8977794@example.com</confObjID> =A0 =A0 =A0 =A0 =A0<operation>retrieve</operation>


=A0 =A0 =A0 =A0 =A0<response-code>200</response-code>
=A0 =A0 =A0 =A0 =A0<response-string>success</response-string><= br> =A0 =A0 =A0 =A0 =A0<ccmp:extendedResponse>
=A0 =A0 =A0 =A0 =A0 =A0 <extensionName>confSummaryRequest</extens= ionName>
=A0 =A0 =A0 =A0 =A0 =A0 <example:confSummary>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <title> Alice's conference </= title>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <status> active </status>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <public> true </public>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <media> audio </media>
=A0 =A0 =A0 =A0 =A0 =A0 </example:confSummary>
=A0 =A0 =A0 =A0 =A0</ccmp:extendedResponse>
=A0 =A0 =A0</ccmpResponse>
=A0 =A0</ccmp:ccmpResponse>

=A0 =A0<?xml version=3D"1.0" encoding=3D"UTF-8"?>= ;
=A0 =A0<xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 targetNamespace=3D"http://example.com/ccmp-extension= "
=A0 =A0 =A0 =A0 =A0 =A0 =A0 xmlns=3D"http://example.com/ccmp-extension"= >

=A0 =A0 =A0<xs:element name=3D"confSummary" type=3D"conf= -summary-type"/>

=A0 =A0 =A0<xs:complexType name=3D"conf-summary-type">
=A0 =A0 =A0 =A0<xs:sequence>
=A0 =A0 =A0 =A0 =A0<xs:element name=3D"title" type=3D"xs= :string"/>
=A0 =A0 =A0 =A0 =A0<xs:element name=3D"status" type=3D"x= s:string"/>
=A0 =A0 =A0 =A0 =A0<xs:element name=3D"public" type=3D"x= s:boolean"/>
=A0 =A0 =A0 =A0 =A0<xs:element name=3D"media" type=3D"xs= :string"/>
=A0 =A0 =A0 =A0</xs:sequence>
=A0 =A0 =A0</xs:complexType>

=A0 =A0</xs:schema>

Otherwise I've checked all the schemas for conformance and the
examples for schema-validity.

12.2 XML Schema Registration

Should include pointers to the RFCs which include the text of the
schema documents named as "DataModel.xsd" and "rfc4575.xsd&q= uot; in the
schema docuemnt given in section 11.
[MB] = Okay. [/MB]=A0

12.3 Media Type Registration

It seems unlikely that the proposed extension of 'ccmpxml' will see=
much use---4 characters seems to be the practical limit for
extensions.
[MB] How about 'ccmp'? =A0

Nits: One more proofreading pass over the first three sections would
be a good idea. . .
[MB] I'll give it a go, = but it appears that it's section 3 that needs some tidying. [/MB]=A0

ht
--
=A0 =A0 =A0 Henry S. Thompson, School of Informatics, University of Edinbu= rgh
=A0 =A0 =A010 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650= -4440
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 URL: http://www.ltg.ed.ac.uk/~ht/
=A0[mail from me _always_ has a .sig like this -- mail without it is forged= spam]


--20cf307d01eefceb6c04a3f6119f-- From stpeter@stpeter.im Wed May 25 13:14:49 2011 Return-Path: X-Original-To: xcon@ietfa.amsl.com Delivered-To: xcon@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFF31300B6 for ; Wed, 25 May 2011 13:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTJs9Pb4Pgwv for ; Wed, 25 May 2011 13:14:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5AF130085 for ; Wed, 25 May 2011 13:14:48 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C8C0E40046 for ; Wed, 25 May 2011 14:14:46 -0600 (MDT) Message-ID: <4DDD6334.8010205@stpeter.im> Date: Wed, 25 May 2011 14:14:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "xcon@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060001030308060506080906" Subject: [XCON] FYI: work of interest at OASIS X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:14:49 -0000 This is a cryptographically signed message in MIME format. --------------ms060001030308060506080906 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This work at OASIS might be of interest to folks in the XCON WG. (Given the scope, it might also be of interest to WGs and lists such as CALSIFY, CLUE, SIMPLE, VCARD, and XMPP, but XCON seems most relevant.) /psa ------ Forwarded Message From: Chet Ensign Date: Thu, 19 May 2011 14:37:45 -0700 To: , , Subject: [icom] 30-day Public Review for Integrated Collaboration Object Model for Interoperable Collaboration Services Version 1.0, Committee Specification Draft 01 The OASIS Integrated Collaboration Object Model for Interoperable Collaboration Services (ICOM) TC [1] members have recently approved a Committee Specification Draft (CSD) and submitted this specification for 30-day public review: Integrated Collaboration Object Model (ICOM) for Interoperable Collaboration Services Version 1.0 Committee Specification Draft 01 / Public Review Draft 01 16 March 2011 Specification Overview: The Integrated Collaboration Object Model (ICOM) for Interoperable Collaboration Services standard defines a framework for integrating a bro= ad range of domain models for collaboration activities in an integrated and interoperable collaboration environment. The framework is intended to ena= ble seamless transitions across collaboration activities. For example, applications can aggregate conversation threads in email with other conversations on the same topic in instant message, over the phone or via= real-time conferencing, by discussion threads in community forum, weblog = or micro blog, and activity stream of participants from all channels. ICOM encompasses and improves on a range of models which are part of existing standards and technologies. The framework lowers the barrier for independ= ent software vendors and open source communities to integrate collaboration services and to create collaboration tools that offer seamless user experience for diverse collaboration activities with minimal context switching. Public Review Period: The public review starts today, 19 May 2011 and ends 18 June 2011. This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for= the sake of improving the interoperability and quality of its technical work. URIs: The prose specification document and related files are available her= e: Editable Source (Authoritative): http://docs.oasis-open.org/icom/icom-ics/v1.0/csprd01/icom-ics-v1.0-csprd= 01. doc HTML: http://docs.oasis-open.org/icom/icom-ics/v1.0/csprd01/icom-ics-v1.0-csprd= 01. html PDF: http://docs.oasis-open.org/icom/icom-ics/v1.0/csprd01/icom-ics-v1.0-csprd= 01. pdf Other specification artifacts: Additional information about the specification and the OASIS OASIS Integrated Collaboration Object Model for Interoperable Collaboration Services TC may be found at the TC's public home page: http://www.oasis-open.org/committees/icom/ Comments may be submitted to the TC by any person through the use of= the OASIS TC Comment Facility which can be located via the button labeled= "Send A Comment" at the top of the TC public home, or directly at: http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=3Dicom Comments submitted by TC non-members for this work and for other wor= k of this TC are publicly archived and can be viewed at: http://lists.oasis-open.org/archives/icom-comment/ All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of 'Integrated Collaboration Object Model (ICOM) = for Interoperable Collaboration Services Version 1.0', we call your attention= to the OASIS IPR Policy [2] applicable especially [3] to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license right= s that read on an approved OASIS specification. OASIS invites any persons w= ho know of any such claims to disclose these if they may be essential to the= implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Additional references: [1] OASIS Integrated Collaboration Object Model for Interoperable Collaboration Services TC http://www.oasis-open.org/committees/icom/ [2] http://www.oasis-open.org/who/intellectualproperty.php [3] http://www.oasis-open.org/committees/icom/ipr.php http://www.oasis-open.org/who/intellectualproperty.php#s10.2.3 RF on Limited Terms Mode IPR Mode /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn: http://linkd.in/OASISopen Twitter: http://twitter.com/OASISopen Facebook: http://facebook.com/oasis.open --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ------ End of Forwarded Message --------------ms060001030308060506080906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUy NTIwMTQ0NFowIwYJKoZIhvcNAQkEMRYEFPJ7ZBeUaQtbOWIWdjUr+lAqsY0RMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBdudxnBh6Vvg5YYVIS/T7pZoMoATsDx1ly1HdEW9K/iYqopRC0oeJEl4ry hG2oGu2hHwToHhMke4n5TNz38FXlBjdlKF+kuq+iWRLdTpnOS/qJWh79j3RFObsjhrzcH1TX cu2EKAZ7Qr2pakin9uHVKOIPIYQWLfKxrJnwAATGt4tFXErE3oSk3cUkA1F1gISHNfpGxp0/ u5vR4qnR3KJb1jnoTSimsXIEIB68URECPzh2t81YTm3kkwFdTMYAG/+/o1i9OrMxMDJdamyL z57ixO8RcOuuUY5uyjEdGmLO+c67FDRZD0Qr8CuxwlKW4AZKLm/Kvv4MJNOsGhoTLScfAAAA AAAA --------------ms060001030308060506080906-- From internet-drafts@ietf.org Fri May 27 05:35:10 2011 Return-Path: X-Original-To: xcon@ietfa.amsl.com Delivered-To: xcon@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA4FE07C9; Fri, 27 May 2011 05:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfCZG5V-T-A8; Fri, 27 May 2011 05:35:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CB7E0671; Fri, 27 May 2011 05:35:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110527123507.15425.66153.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2011 05:35:07 -0700 Cc: xcon@ietf.org Subject: [XCON] I-D Action: draft-ietf-xcon-common-data-model-28.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 12:35:11 -0000 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 Grou= p of the IETF. Title : Conference Information Data Model for Centralized Confer= encing (XCON) Author(s) : Oscar Novo Gonzalo Camarillo David P. Morgan Jari Urpalainen Filename : draft-ietf-xcon-common-data-model-28.txt Pages : 96 Date : 2011-05-27 RFC5239 defines the idea of a centralized conferencing (XCON) as an association of participants with a central focus. The state of a conference is represented by a conference object. This document defines an Extensible Markup Language (XML)-based conference information data model to be used for conference objects. 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-28.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-28.txt