Hi Robert,

see our answers in-line ([spromano]).

> 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
[spromano] Agreed. I would go for case sensitive operation, and specify 
that AUTO_GENERATE_n has to be upper case. OK?

> 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.)
[spromano] Agreed.

>      - the server will substitute different strings for 
> AUTO_GENERATE_1 and AUTO_GENERATE_n for any n other than 1.

[spromano] Agreed.

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

[spromano] Agreed.

> 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?
[spromano] I don't really think so. These identifiers are not critical 
from the security perspective.

> 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.
[spromano] I guess the server should generate either a 400 Bad Request 
(see example E) below -- for the case when the request is syntactically 
incorrect), or a generic 500 Server Internal Error, in all cases when 
the request is OK, but the value obtained after the substitution on the 
server's side cannot be served because of semantic issues (e.g. a domain 
name which is not managed by the contacted server, see e.g. example F) 
below).

> 5) Please take care to avoid implementer confusion about quotes around 
> the string being substituted.

[spromano] Do you mean we have to make it explicit that the server 
substitutes just the content inside the quotes?

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

[spromano] OK. We'll double check this, both in the CCMP draft and in 
the call flows examples 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?).
[spromano] Correct sequencing is irrelevant, as long as the server looks 
after proper differentiation of the identifiers. So, we'll make this 
explicit in the document.

>
> 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).

[spromano] Agreed. The motivation should be exactly this one. Examples 
like F) below would not be allowed, otherwise.

>
> 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:AUTO_GENERATE_1@example.com">
[spromano] <userInfo entity="xcon-userid:pippo@example.com">

> B) <userInfo entity="xcon-userid:AUTO_GENERATE_1">

[spromano] e.g.: <userInfo entity="xcon-userid:pluto@whatever.com">

> C) <userInfo entity="AUTO_GENERATE_1">

[spromano] e.g.: <userInfo entity="xcon-userid:paperino@whatever.com">

> D) <userinfo entity="xcon-userid:AUTO_GENERATE_1@AUTO_GENERATE_2">

[spromano] as above, e.g.: <userInfo 
entity="xcon-userid:topolino@whatever.com">
> E) <userinfo AUTO_GENERATE_1>

[spromano] Error! 404 Bad Request

> F) <userinfo entity="xcon-userid:fooAUTO_GENERATE_1bar@example.com">

[spromano] e.g.: <userInfo entity="xcon-userid:fooPaperinobar@example.com">

Basically, I tend to think that all of the above examples, except 
example E) (which, as said, generates a 400 "Bad Request" response), are 
OK. AUTO_GENERATE_n should actually always be 'inside' the value part of 
an attribute/element in the provided XML excerpt. It should also be a 
RESERVED string, in all cases which might generate conflict situations, 
as per section 4.1 (last paragraph) of the CCMP draft (mandatory fields 
in the data model for which a value has not been set by the server as 
yet). Obviously, nothing should prevent a client from using such a 
string wherever it is not possible to generate any conflicts (e.g. in 
the <display-text>, which is not a mandatory field in the data model). 
This should also clarify the next point (see below).

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

[spromano] Sure we don't! I would stick to the above definition of 
AUTO_GENERATE_n. What do you think?

Thank you once again for your precious feedback.

Cheers,

Simon

>
> 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 
>> <spromano@unina.it <mailto:spromano@unina.it>> 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: +39 081 7683823 -- Fax: +39 081 7684219
>>                    e-mail: spromano@unina.it <mailto:spromano@unina.it>
>>     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~~~~~~~~~~~~~~~~~~~~~~~~~
>>                              \ (    (   )
>>                               \_)    ) /
>>                                     (_/
>>
>>
>>
>

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: spromano@unina.it
           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~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/