IETF Logo Mail Archive

Re: [XCON] AD review: draft-ietf-xcon-ccmp-10

Robert Sparks <rjsparks@nostrum.com> Wed, 26 January 2011 18:34 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523AF3A6826 for <xcon@core3.amsl.com>; Wed, 26 Jan 2011 10:34:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.557
X-Spam-Level:
X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wfmeXQT-mXC for <xcon@core3.amsl.com>; Wed, 26 Jan 2011 10:34:00 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 497433A6862 for <xcon@ietf.org>; Wed, 26 Jan 2011 10:33:59 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0QIawvp027125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Jan 2011 12:36:58 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary="Apple-Mail-154--67763053"
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <4D406699.30002@unina.it>
Date: Wed, 26 Jan 2011 12:36:56 -0600
Message-Id: <83193E1C-4584-4B1C-B024-0BD574BF8FF5@nostrum.com>
References: <DE53D7D6-7FC6-445F-8500-FDE234681FA3@nostrum.com> <AANLkTinXKV-eCmpuDWUfm0ZGX6c4+YNxoF95G84gUSzc@mail.gmail.com> <CF9B2EC3-015C-42A8-A031-FE24EDB6583A@nostrum.com> <AANLkTi=kVZaD8jLPKKR-LVATkDgyqFEy-YS2=+kEbkAV@mail.gmail.com> <4D00EEE1.7030703@unina.it> <AANLkTi=wQYn_KV2eqHm6jcR-_Jq5KuQKEdAjk4jS=Pg=@mail.gmail.com> <4D069BB4.9090904@unina.it> <AANLkTik0Ff3EqqwsapSKCDNkeCYc1E7s-kYuGO5ky9b1@mail.gmail.com> <4D087FEC.5060301@unina.it> <AANLkTin+Ah5zT83=i2U0P485DyB_-OSbspkLzcp1dmpP@mail.gmail.com> <9D8B8B72-72B5-4821-86C2-5CB1214AAEB6@nostrum.com> <4D406699.30002@unina.it>
To: Simon Pietro Romano <spromano@unina.it>
X-Mailer: Apple Mail (2.1082)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: xcon@ietf.org
Subject: Re: [XCON] AD review: draft-ietf-xcon-ccmp-10
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 26 Jan 2011 18:34:01 -0000

On Jan 26, 2011, at 12:23 PM, Simon Pietro Romano wrote:

> Hi Robert,
> 
> see our answers in-line ([spromano]).
> 
<snip>

> 
>> 5) Please take care to avoid implementer confusion about quotes around the string being substituted.
> 
> [spromano] Do you mean we have to make it explicit that the server substitutes just the content inside the quotes? 

Yes, and I'm not necessarily asking for more text. Just make sure the existing text can't be read ambiguously, and that
the examples are not misleading. 

<snip>

> 
>> 
>> So coming back to point 4, assume the following stanza beginnings occur in different documents. What strings would you expect the server to substitute
>> in place of the placeholder in each case, and what would the server do next? What part of the spec actually tells an implementation to do what you expected?
>> 
>> A)             <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com">
> [spromano] <userInfo entity="xcon-userid:pippo@example.com">
> 
>> B)            <userInfo entity="xcon-userid:AUTO_GENERATE_1">
> 
> [spromano] e.g.: <userInfo entity="xcon-userid:pluto@whatever.com">
> 
>> C)            <userInfo entity="AUTO_GENERATE_1">
> 
> [spromano] e.g.: <userInfo entity="xcon-userid:paperino@whatever.com">
> 
>> D)            <userinfo entity="xcon-userid:AUTO_GENERATE_1@AUTO_GENERATE_2">
> 
> [spromano] as above, e.g.: <userInfo entity="xcon-userid:topolino@whatever.com">

For A-D, I don't believe the existing text tells an implementation what kind of string it should have created. Do you think that's covered already?

>> E)            <userinfo AUTO_GENERATE_1>
> 
> [spromano] Error! 404 Bad Request
> 
>> F)            <userinfo entity="xcon-userid:fooAUTO_GENERATE_1bar@example.com">
> 
> [spromano] e.g.: <userInfo entity="xcon-userid:fooPaperinobar@example.com">
> 
> Basically, I tend to think that all of the above examples, except example E) (which, as said, generates a 400 "Bad Request" response), are OK. AUTO_GENERATE_n should actually always be 'inside' the value part of an attribute/element in the provided XML excerpt. It should also be a RESERVED string, in all cases which might generate conflict situations, as per section 4.1 (last paragraph) of the CCMP draft (mandatory fields in the data model for which a value has not been set by the server as yet). Obviously, nothing should prevent a client from using such a string wherever it is not possible to generate any conflicts (e.g. in the <display-text>, which is not a mandatory field in the data model). This should also clarify the next point (see below). 
> 
>> 
>> What text constrains where AUTO_GENERATE_n can appear? I suspect we don't want the server looking to replace it in an xmlns: declaration...
> 
> [spromano] Sure we don't! I would stick to the above definition of AUTO_GENERATE_n. What do you think?

That seems like a reasonable approach. The details on how you capture it in the document will be important.


> 
> Thank you once again for your precious feedback.
> 
> Cheers,
> 
> Simon
>

v2.23.0 | Report a Bug | By Email