Re: [XCON] AD review: draft-ietf-xcon-ccmp-11 - AUTO_GENERATE_X behavior

Simon Pietro Romano <spromano@unina.it> Tue, 15 February 2011 10:16 UTC

Return-Path: <spromano@unina.it>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6E53A6E81 for <xcon@core3.amsl.com>; Tue, 15 Feb 2011 02:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.718
X-Spam-Level:
X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKqm99LxBeOp for <xcon@core3.amsl.com>; Tue, 15 Feb 2011 02:16:10 -0800 (PST)
Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by core3.amsl.com (Postfix) with ESMTP id C97703A6E79 for <xcon@ietf.org>; Tue, 15 Feb 2011 02:16:09 -0800 (PST)
Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id p1FAGPPL016809 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Feb 2011 11:16:26 +0100
Message-ID: <4D5A5278.7020505@unina.it>
Date: Tue, 15 Feb 2011 11:16:24 +0100
From: Simon Pietro Romano <spromano@unina.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Mary Barnes <mary.ietf.barnes@gmail.com>
References: <AANLkTikz+5dFSjPuQPobcBf8bhzosUWmA8xYJ5p262xk@mail.gmail.com>
In-Reply-To: <AANLkTikz+5dFSjPuQPobcBf8bhzosUWmA8xYJ5p262xk@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------030307070305060602020501"
Cc: xcon@ietf.org
Subject: Re: [XCON] AD review: draft-ietf-xcon-ccmp-11 - AUTO_GENERATE_X behavior
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <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: Tue, 15 Feb 2011 10:16:12 -0000

Hi Mary,

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

Simon

Il 14/02/2011 19:25, Mary Barnes ha scritto:
> Hi folks,
>
> Per the discussion threads:
> http://www.ietf.org/mail-archive/web/xcon/current/msg02492.html
> http://www.ietf.org/mail-archive/web/xcon/current/msg02493.html
>
> I propose to make the following changes with regards to the normative 
> behavior for  AUTO_GENERATE_X, as currently described in the last 
> paragraph in section 4.1.  I'll also make
> some editorial changes to the text in section 4 to more accurately 
> describe what is in section 4.1 and 4.2.
>
> OLD:
>           To solve this kind of issues,
>            the CCMP fill all mandatory data model fields, for which no 
> value is
>            available at the client at the time the request is 
> constructed, with fake values
>            in the form of wildcard strings (e.g. AUTO_GENERATE_X, with 
> X being an incremental
>             index initialized to a value of 1). Upon reception of the 
> mentioned kinds of requests,
>             the server will: (i) generate the proper identifier(s); (ii)
>             produce a response in which the received fake 
> identifier(s) carried in the
>             request has (have) been replaced by the newly created one(s).
>             With this approach we maintain compatibility with the data 
> model requirements,
>             at the same time allowing for client-initiated 
> manipulation of conference objects
>             at the server's side (which is, by the way, one of the 
> main goals for which the CCMP
>             protocol has been conceived at the outset).
>
> NEW:
>            To solve this issue,  the CCMP client fills all mandatory 
> data model fields,
>            for which no value is available at the time the request is 
> constructed, with fake values
>            in the form of a wildcard string, AUTO_GENERATE_X (all 
> uppercase),
>            with X being a unique numeric index for each data model 
> field for which the value is
>            unknown.  This form of wildcard string is chosen, rather 
> than the use
>            of random unique strings (e.g, FOO_BAR_LA) or non-numeric 
> values for X,
>            to simplify processing at the server.  The values of 
> AUTO_GENERATE_X
>            are only unique within the context of the specific request. 
>  The fake AUTO_GENERATE_X
>            values MUST be within the value part of an 
> attribute/element (e.g., <userinfo entity=
>            "xcon-userid:AUTO_GENERATE_1@example.com 
> <mailto:xcon-userid%3AAUTO_GENERATE_1@example.com>">).
>             When the server receives requests containing values in the 
> form of AUTO_GENERATE_X,
>             the server does the following:
>              (i)  Generates the proper identifier for each instance of
>                   AUTO_GENERATE_X in the document.   If an instance of 
> AUTO_GENERATE_X
>                   is not within the value part of the 
> attribute/element,  the server MUST
>                   respond with an error of 400 Bad Request.
>                   In cases where AUTO_GENERATE_X appears only in the 
> user part of
>                   a URI (i.e., in the case of XCON-USERIDs or 
> XCON-URIs), the server
>                   needs to ensure that the domain name is one that is 
> within the server's domain
>                   of responsibility.  If the domain name is NOT within 
> the server's domain of
>                   responsibility, then the server MUST return a 500 
> Server Internal Error.
>                   The server MUST replace each instance of a specific
>                   wildcard field  (e.g., AUTO_GENERATE_1)
>                   with the same identifier.  The identifiers MUST be 
> unique
>                   for each instance of AUTO_GENERATE_X within the same
>                   XML document received in the request - e.g., the value
>                   that replaces AUTO_GENERATE_1 MUST NOT be the same 
> as the value
>                   that replaces AUTO_GENERATE_2.   Note that the values
>                   that replace the instances of AUTO_GENERATE_X are 
> not the
>                   same across all conference objects - e.g., different 
> values can
>                   be used to replace AUTO_GENERATE_1 in two different
>                   documents.
>             (ii)  Sends a response in which all values of 
> AUTO_GENERATE_X received in
>                  the request has (have) been replaced by the newly 
> created one(s).
>             With this approach compatibility with the data model 
> requirements is maintained,
>             while allowing for client-initiated manipulation of 
> conference objects
>             at the server's side  which is one of the main goals of 
> the CCMP protocol.
>
> Please let me know ASAP if this is not okay.
>
> Thanks,
> Mary.
>
>

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

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/