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

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

Hi Mary,

as usual, inline ([spromano3] :-) ).

>
> [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?

[spromano3]
Actually, the idea of enumerating AUTO_GENERATE_X dummy identifiers 
derives from the presence of potential "cross references" in some CCMP 
messages. Let's take once again the sidebars example, which is by no 
doubt the trickiest one. If I want to add two different streams 
(stream_1 and stream_2) in a sidebar, and in the same message I want to 
indicate that stream_2 has to be 'recvonly', I have to be able to tell 
the first identifier (associated with stream_1) apart from the second 
(associated with stream_2). An example like this can be found in the 
XCON examples document on page 73 (sidebarsByRefRequest/update). If I 
weren't able to make such distinction inside the client's message, the 
only remaining option would be to send to the server three distinct 
messages (two of which would be 'updates'): (i) 'update', to create the 
sidebar with stream_1 and stream_2 (such message would just contain, for 
both streams, a generic AUTO_GENERATE wildcard); (ii) 'retrieve', to get 
the (actual) identifiers created by the server; (iii) 'update' (with the 
real identifier retrieved for stream_2), to specify that stream_2 has to 
be 'recvonly'.
All this just to say that both options (use AUTO_GENERATE_X or just 
AUTO_GENERATE for fake identifiers) are viable, but in our view the 
former allows for more flexibility in cases like the one described 
above. What is your feeling?
[/spromano3]

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

[spromano3]
Indeed, I'm not sure we need to modify this, since the CCMP schema does 
not *mandate* the presence of the confUserID parameter inside CCMP 
messages. Do you agree with this?
[/spromano3]

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