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

[Mary Barnes <[e-mail]>]

Hi Simon,

Responses inline below [MB3].

Thanks,
Mary.

On Mon, Dec 13, 2010 at 4:18 PM, Simon Pietro Romano <[e-mail]>wrote;wrote:

>  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]
>
[MB3] Okay - I will add text. [/MB3]

>
>
>   * *
>> *[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]
>

[MB3] So, I see the point that you need to have something in the attribute
and that there needs to be a way to ensure it doesn't conflict with a value
that might collide with a valid value.  But, I cannot see the need for the
unique increment - i.e, why won't a fixed "dummy" value work (e.g.,
dummy-user@domain, where the domain is the domain of the conf server)?  The
requesting user knows that they are adding a specific user to the conference
and other information associated with that user is unique.  Unless the
suggestion is that using the increment makes it easier for the client. But,
I can't see that the information is useful to the conferencing server since
it will just see an identifier with a specific string and then it knows that
it needs to create one for that user. Unless you are suggesting that the
conferencing server is then ensuring they are unique for a specific user and
returns an error if not?

Also, the definition of the XCON-USERID needs to be updated in either case:
     "The "confUserID" parameter is REQUIRED in
      the CCMP request and response messages with the exception of the
      case of a user who has no XCON-USERID and who wants to enter, via
      CCMP, a conference whose identifier is known.  In such case, a
      side-effect of the request is that the user is provided with an
      appropriate XCON-USERID.

So, I'm assuming the AUTO_GENERATE_X is used in the case described above?

Either way, whether there's an increment or not, we do need to add alot more
text around this mechanism.
[/MB3]




> 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~~~~~~~~~~~~~~~~~~~~~~~~~
>                           \ (    (   )
>                            \_)    ) /
>                                  (_/
>
>
>