Re: [XCON] apps-team review of draft-ietf-xcon-ccmp-13

Robert Sparks <rjsparks@nostrum.com> Tue, 17 May 2011 14:16 UTC

Return-Path: <rjsparks@nostrum.com>
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 <rjsparks@nostrum.com>
In-Reply-To: <f5br57zt3s2.fsf@calexico.inf.ed.ac.uk>
Date: Tue, 17 May 2011 09:16:10 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <B44A4EAE-7245-4552-A373-CE36D452A165@nostrum.com>
References: <f5br57zt3s2.fsf@calexico.inf.ed.ac.uk>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
X-Mailer: Apple Mail (2.1084)
Received-SPF: pass (nostrum.com: 173.57.91.217 is authenticated by a trusted mechanism)
Cc: Henning Schulzrinne <hgs+xcon@cs.columbia.edu>, Alan Johnston <alan.b.johnston@gmail.com>, apps-discuss@ietf.org, xcon@ietf.org, Richard Barnes <barnes@bbn.com>, "iesg@ietf.org IESG" <iesg@ietf.org>
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 <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=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).
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 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?
> 
> 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. . .
> 
> 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.)
> 
> 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.
> 
> 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
>                    <xcon:floor-request-handling>confirm
>                      </xcon:floor-request-handling>
> 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.
> 
> A similar problem occurs in the response in 6.3
> (floor-request-handling)
> 
> 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:
> 
>   <?xml version="1.0" encoding="UTF-8"?>
>   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> 	      targetNamespace="http://example.com/ccmp-extension-schema.xsd"
> 	      xmlns="http://example.com/ccmp-extension-schema.xsd">
> 
>     <xs:element name="confSummary" type="conf-summary-type"/>
> 
>     <xs:complexType name="conf-summary-type">
>       <xs:sequence>
> 	 <xs:element name="title" type="xs:string"/>
> 	 <xs:element name="status" type="xs:string"/>
> 	 <xs:element name="public" type="xs:boolean"/>
> 	 <xs:element name="media" type="xs:string"/>
>       </xs:sequence>
>     </xs:complexType>
> 
>   </xs:schema>
> 
> Or, better, the example _and_ the schema should be changed to read as
> follows:
> 
>   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>    <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info"
> 	   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">
>      <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	  xsi:type="ccmp:ccmp-extended-response-message-type">
> 	  <confUserID>xcon-userid:Alice@example.com</confUserID>
> 	  <confObjID>xcon:8977794@example.com</confObjID>
> 	  <operation>retrieve</operation>
> 
> 
> 	  <response-code>200</response-code>
> 	  <response-string>success</response-string>
> 	  <ccmp:extendedResponse>
> 	     <extensionName>confSummaryRequest</extensionName>
> 	     <example:confSummary>
> 		 <title> Alice's conference </title>
> 		 <status> active </status>
> 		 <public> true </public>
> 		 <media> audio </media>
> 	     </example:confSummary>
> 	  </ccmp:extendedResponse>
>      </ccmpResponse>
>    </ccmp:ccmpResponse>
> 
>    <?xml version="1.0" encoding="UTF-8"?>
>    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> 	       targetNamespace="http://example.com/ccmp-extension"
> 	       xmlns="http://example.com/ccmp-extension">
> 
>      <xs:element name="confSummary" type="conf-summary-type"/>
> 
>      <xs:complexType name="conf-summary-type">
> 	<xs:sequence>
> 	  <xs:element name="title" type="xs:string"/>
> 	  <xs:element name="status" type="xs:string"/>
> 	  <xs:element name="public" type="xs:boolean"/>
> 	  <xs:element name="media" type="xs:string"/>
> 	</xs:sequence>
>      </xs:complexType>
> 
>    </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" in the
> schema docuemnt given in section 11.
> 
> 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.
> 
> Nits: One more proofreading pass over the first three sections would
> be a good idea. . .
> 
> 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]