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

From: Mary Barnes <[email-masked]>
Date: Mon, 14 Feb 2011 12:25:06 -0600

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:[email-masked]">).

            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.

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 15 Feb 2011 11:16:24 +0100

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:
> 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:
>            the CCMP fill all mandatory data model fields, for which no 
> value is
>            available at the client at the time the request is 
>            in the form of wildcard strings (e.g. AUTO_GENERATE_X, with 
> X being an incremental
>             produce a response in which the received fake 
> identifier(s) carried in the
>             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
>            To solve this issue,  the CCMP client fills all mandatory 
> data model fields,
>            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,
>            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:[email-masked] 
> <mailto:[email-masked]>">).
>             When the server receives requests containing values in the 
> form of AUTO_GENERATE_X,
>                   is not within the value part of the 
> attribute/element,  the server MUST
>                   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.
>                   that replaces AUTO_GENERATE_1 MUST NOT be the same 
> as the value
>             (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).
>             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.
>

-- 
                             _\\|//_
                             ( 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: [email-masked]
           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~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Robert Sparks <[email-masked]>
Date: Tue, 15 Feb 2011 08:27:05 -0600

This looks good to me.

RjS

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

> 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:
>            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, 
>             produce a response in which the received fake identifier(s) carried in the 
>             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 
>            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=
>             When the server receives requests containing values in the form of AUTO_GENERATE_X, 
>                   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 
>                   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. 
>                   that replaces AUTO_GENERATE_1 MUST NOT be the same as the value
>                   same across all conference objects - e.g., different values can 
>             (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.
>               
>