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

[Simon Pietro Romano <[e-mail]>]

Hi Mary,

see in-line [spromano2] for my comments.

>     /[spromano] For the sake of completeness, we must say that the
>     CCMP schema allows to have empty "optionsRequest" messages.
>     /
>
> [MB2] I had thought that at a minimum the optionsRequest message must 
> contain a confUserID as described in the paragraph after the bulleted 
> list in section 5.3.12:
>    The only parameter needed in the optionsRequest is the sender
>    confUserID, which is mirrored in the homologous parameter of the
>    corresponding optionsResponse.
>
> At a minimum we should change the word "needed" to either REQUIRED or 
> MAY.  If it's MAY, then we need to described how the message is 
> handled in the case where there isn't a confUserID.  Is one assigned, 
> etc.?
>
> Either way, we need to update the text in the paragraph following the 
> list of message types in section 5.3 to include 
> optionsRequest/optionsResponse as another message pair that doesn't 
> require an operation (along with blueprintsRequest/blueprintsResponse 
> and confsRequest/confsResponse as currently stated).
> [/MB2]
[spromano2]
I agree with you. I think we should state that an optionsRequest MUST 
carry a confUserID. In case it doesn't, the server MUST send back to the 
client a 400 (bad request) response code.
[/spromano2]

>     //
>     /[spromano] I have to admit that the point raised by Robert is an
>     important one. I believe that the wildcard identifier MUST be
>     unique for all implementations of the protocol: if the server does
>     not see an 'official' 'AUTO_GENERATE_N' identifier (with 'N'
>     properly set), it cannot understand that it (i.e. the server) has
>     to create a brand new identifier. The server might just think that
>     the received identifier is an existing one and would just go and
>     look for the associated element, thus generating an error. /By the
>     way, I checked the documents and I realized that we often put in
>     the examples just '/AUTO_GENERATE', whereas the correct example
>     wildcard should be '//AUTO_GENERATE_1'. I think we must correct
>     this, if everybody (understands and) agrees with the proposed
>     approach.
>     /
>
> [MB2]  It's not at all clear to me why there is a need for a 
> unique/"official" dummy UserID in the request to create a new UserID. 
>  The intent of the userRequest with a create operation is to create a 
> generate an "official" XCON-USERID at the conferencing server.  I did 
> not understand the intent to be that these were globally unique nor 
> that the client really cared what value it might receive, since they 
> are all managed by the conference server.  I can see in the case that 
> a conferencing client is requested to add a number of users to a 
> conference, none of whom have an XCON-USERID that it might be helpful 
> for the dummy UserID in the conference object to be unique. But, I 
> still can't see the motivation for an official schema for that. If 
> there is a normative requirement for these to have certain values, 
> then we need some sort of registry and a mechanism to configure the 
> client or for the client to retrieve appropriate values to be used. 
>  But, in that case, why not just have the client go to retrieve the 
> unique values and just skip having the conferencing server assign the 
> unique values?  Basically, it's not clear to me why the client needs 
> to ensure uniqueness for the identifiers when it's up to the 
> conferencing system to allocate.
> [/MB2]

[spromano2]
AUTO_GENERATE_X  is useful when you make modifications involving the 
creation of data model elements envisaging the presence of mandatory 
identification attributes. An example which clarifies this is associated 
with sidebars. Let's figure out that two conference participants want to 
activate a new audio stream between each other while at the same time 
keeping on participating in the main conference (xcon examples, page 
53). When applying the required modification to the sidebar conference, 
new entries are added to the available media; each such entry MUST 
(since this is mandatory in the XCON data model) have an identification 
attribute called "label". We cannot leave such attribute void because in 
such case the request would not be a valid one (syntactically speaking). 
On the other hand, we cannot fill the attribute with a randomly chosen 
value, because in such case the server would try to interpret the 
request as a modification to be applied to an already existing media 
entry: it would go and look for such entry among the existing labels 
and, once realized that no match exists, it would answer with a 
"resourceNotFound" error. The only remaining option is for the server to 
understand that the received label is a "dummy" one and create a brand 
new label value for the newly created entry. That's why we are proposing 
to adopt this AUTO_GENERATE_X workaround for the CCMP.
[/spromano2]

Cheers,
Simon

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: [phone] -- Fax: [phone]
                 e-mail: [e-mail]
           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~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/