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

[Mary Barnes <[e-mail]>]

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:[e-mail]">).

            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.

>
>