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

[Robert Sparks <[e-mail]>]

This is heading in the right direction, but I think the server's behavior will still be underspecified
(if I've missed where these are already covered, please add pointers to to where they're covered to the text you propose below).

1) It needs to be clear whether or not the server looks for these using a case-sensitive comparison
2) It needs to be explicit that
     - the server will substitute the same string for every instance of AUTO_GENERATE_1 in a given document (similar for _2, _3, etc.)
     - the server will substitute different strings for AUTO_GENERATE_1 and AUTO_GENERATE_n for any n other than 1.
    -  there's no requirement for the server to substitute the same string for AUTO_GENERATE_1 in two different documents, even from the same client.
3) It should be explicit whether any security properties are expected from the values that are substituted. For instance, is it important that other clients 
    not be able to guess what the server will substitute?
4) It should be explicit that the server generates a string that makes sense for the context that the variable appears in (see question below), and describe
    what error the server returns if it can't make a substitution resulting in a legal document.
5) Please take care to avoid implementer confusion about quotes around the string being substituted.


Please also make sure any use of this mechanism in the document (or -examples) lines up with the conclusion. Right now, there are some instances
of AUTO_GENERATE without a _n for any n in the document.

You may also want to consider why the incrementing integer is important. The mechanism would work just as well with a document that only contained
AUTO_GENERATE_1 and AUTO_GENERATE_512. (The server isn't asked to look for gaps, and I'm not seeing why it should. Should a request be
rejected because it has a gap in its AUTO_GENERATE sequence?).

You might also want to say in the document why the group didn't just allow strings like "AUTO_GENERATE_ALICE" and "AUTO_GENERATE_FOO".
I think the answer is that we wanted to keep the parsing simple for the server while facilitating substitution into arbitrary contexts (with examples being
replacing only the username part of an xcon-userid, and with the tradeoff being that you can't substitute into a context where the next character would be
a digit).

So coming back to point 4, assume the following stanza beginnings occur in different documents. What strings would you expect the server to substitute
in place of the placeholder in each case, and what would the server do next? What part of the spec actually tells an implementation to do what you expected?

A)             <userInfo entity="xcon-userid:[e-mail]">
B)            <userInfo entity="xcon-userid:AUTO_GENERATE_1">
C)            <userInfo entity="AUTO_GENERATE_1">
D)            <userinfo entity="xcon-userid:AUTO_GENERATE_1@AUTO_GENERATE_2">
E)            <userinfo AUTO_GENERATE_1>
F)            <userinfo entity="xcon-userid:[e-mail]">

What text constrains where AUTO_GENERATE_n can appear? I suspect we don't want the server looking to replace it in an xmlns: declaration...

RjS


On Jan 19, 2011, at 5:29 PM, Mary Barnes wrote:


> Hi Simon,
> 
> I apologize for the long delay.  I do finally get what you are saying and see why a single dummy value won't work.  So, I would suggest we add text something like the following.  Please let me know if that looks okay and then I generate a new version.  Keith also had a few comments that require changes:
> http://www.ietf.org/mail-archive/web/xcon/current/msg02476.html
> 
> Thanks,
> Mary. 
> 
> OLD: 
>    To solve this kind of issues, the CCMP will 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). 
> 
> NEW:
>    To resolve these issues, the CCMP MUST 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
>    the wildcard strings "AUTO_GENERATE_X".  The value of X MUST
>    be initialized with a value of "1" and incremented for each mandatory field in the 
>    for which the client does not have a value.  Upon receipt of requests containing
>    fields with wildcard strings, the server MUST:  (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). 
>   
> 
> On Wed, Dec 15, 2010 at 2:44 AM, Simon Pietro Romano <[e-mail]> wrote:
> 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~~~~~~~~~~~~~~~~~~~~~~~~~
>                          \ (    (   )
>                           \_)    ) /
>                                 (_/
> 
> 
>