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

From: Mary Barnes <[email-masked]>
Date: Wed, 19 Jan 2011 17:29:10 -0600

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 <[email-masked]>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: [email-masked]
>          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~~~~~~~~~~~~~~~~~~~~~~~~~
>                          \ (    (   )
>                           \_)    ) /
>                                 (_/
>
>
>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 24 Jan 2011 13:31:50 -0600

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:[email-masked]">
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:[email-masked]">

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:
>    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
> On Wed, Dec 15, 2010 at 2:44 AM, Simon Pietro Romano <[email-masked]> wrote:
> Hi Mary,
> 
> [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:
> 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 )

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 26 Jan 2011 19:23:21 +0100

Hi Robert,

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

> (if I've missed where these are already covered, please add pointers 
> to to where they're covered to the text you propose below).
>
[spromano] Agreed. I would go for case sensitive operation, and specify 
that AUTO_GENERATE_n has to be upper case. OK?

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

> 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

[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
[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?
>
[spromano] <userInfo entity="xcon-userid:[email-masked]">

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

[spromano] e.g.: <userInfo entity="xcon-userid:[email-masked]">

> C) <userInfo entity="AUTO_GENERATE_1">

[spromano] e.g.: <userInfo entity="xcon-userid:[email-masked]">

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

[spromano] as above, e.g.: <userInfo 
entity="xcon-userid:[email-masked]">
> E) <userinfo AUTO_GENERATE_1>

[spromano] Error! 404 Bad Request

> F) <userinfo entity="xcon-userid:[email-masked]">

[spromano] e.g.: <userInfo entity="xcon-userid:[email-masked]">

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

>> 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:
>> On Wed, Dec 15, 2010 at 2:44 AM, Simon Pietro Romano 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hi Mary,
>>
>>         [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]
>>
>>
>>         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 )
>>                    e-mail: [email-masked] <mailto:[email-masked]>

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Robert Sparks <[email-masked]>
Date: Wed, 26 Jan 2011 12:36:56 -0600

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

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

Yes, and I'm not necessarily asking for more text. Just make sure the existing text can't be read ambiguously, and that
the examples are not misleading. 

<snip>

> [spromano] as above, e.g.: <userInfo entity="xcon-userid:[email-masked]">

For A-D, I don't believe the existing text tells an implementation what kind of string it should have created. Do you think that's covered already?

> 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). 
> 
>> 
> [spromano] Sure we don't! I would stick to the above definition of AUTO_GENERATE_n. What do you think?

That seems like a reasonable approach. The details on how you capture it in the document will be important.