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

From: Robert Sparks <[email-masked]>
Date: Tue, 7 Dec 2010 10:37:36 -0600

Hi Mary - 

When do you expect to make the revision you indicate below
(adding text about AUTO_GENERATE_X?)

RjS

On Oct 26, 2010, at 4:45 PM, Mary Barnes wrote:

> Robert and WG,
> 
> We have updated the document to address the issues raised below:
> http://tools.ietf.org/html/draft-ietf-xcon-ccmp-11
> 
> As well, there are some small updates the XML schema.  The
> diff is a useful way to review the changes:
> http://tools.ietf.org/wg/xcon/draft-ietf-xcon-ccmp/draft-ietf-xcon-ccmp-11-from-10.diff.html
> 
> I have a few responses inline below [MB] on the changes.
> 
> Regards,
> Mary.
> 
> On Tue, Sep 14, 2010 at 10:51 AM, Robert Sparks <[email-masked]> wrote:
>> Summary: There are some minor issues to address before moving to IETF LC.
>> 
>> This is a good document - it was very easy to read. Thanks to all who worked
>> to get it into the shape it's in.
>> 
>> Administrative:
>> * Please send a request to type-review for application/ccmp+xml.
> [MB] Alan sent a request. As best as I could tell from the discussion
> on the ietf-types mailing list,  the primary issue raised is the same
> one that was raised with regards to HELD - making UTF-8 mandatory.  I
> added text inline with the final changes that we made to HELD around
> this issue in section 4.2, which  the use of HTTP and
> application/ccmp+xml:
> 
>   The XML documents in the CCMP
>   messages MUST be encoded in UTF-8.  This specification follows the
>   recommendations and conventions described in [RFC3023], including the
>   naming convention of the type ('+xml' suffix) and the usage of the
>   'charset' parameter.  The 'charset' parameter MUST be included with
>   the XML document.
> 
>> 
>> * I would like the writeup to name who verified the schema and examples
>>  (and what tool they used). How did the reviewer ensure the snippets of
>>  schema in the sections that describe various elements exactly matches
>>  the full schema listed in section 11?
>> 
>> Technical:
>> 
>> * Is there any text that prevents a ccmp request from being empty?
>>  (all of the elements in the schema have minOccurs="0"). If not,
>>  either some should be added, or the text should say something
>>  about how a server should react to a request built this way.
> [MB]  [MB] We don't allow an empty request in that you always have a
> message type and usually an operation, noting that there there is no
> operation for
> a blueprintsRequest or confsRequest, as stated in section
> 5.1 under the operation parameter description. Each message has other
> required and optional parameters and if the
> request doesn't have the mandatory parameters, a 400 response would be
> sent.  A note in that regards to section 5.3.   [/MB]
> 
>> 
>> * The AUTO_GENERATE mechanism's definition is currently hard to find,
>>  (it's at the end of 4.1), and easy to miss that it's a normative
>>  requirement on server behavior. (I couldn't find the place where
>>  the behavior was defined for my first several reads of this document).
>>  This behavior should be defined with 2119 terms. What definition
>>  exists in this section requires the wildcard to have the form of
>>  AUTO_GENERATE_X, but there are several examples and places in the text
>>  (here and in the examples document), particularly for xcon-userid:
>>  constructs where AUTO_GENERATE appears without the _X.
> [MB]  AUTO_GENERATE_X is an example and it isn't normative.  The
> normative aspect is that all the mandatory fields MUST be initialized.
> If there is no value, such as for the identifiers, then an
> appropriate wildcard string MUST be included.  The
> [email-masked] is one of example of the string that can
> be used for the XCON-URI.  I had intended to add text related to this,
> but in re-reviewing the diff, the changes I thought I made didn't make
> it, so this change is still needed and I'll update the doc again as
> soon as submissions open up again.   [/MB]
>> 
>> * The draft calls out "first party" and "third party" actions, but doesn't
>>  define those terms.
> [MB] Definitions have been added to the terminology section. [/MB]
>> 
>> * The document should call out why <standard-message-list> and
>>  <extended-message-list> were separated, and what makes that separation
>>  useful. What will an implementation do differently if a message name
>>  it doesn't understand shows up in a <standard-message-list> vs in an
>>  <extended-message-list>?
> [MB] Done. [/MB]
>> 
>> * Can you add a note explaining that the server chooses the contents
>>  of the URI when it creates a conference or user? The examples for
>>  creating users, such as 6.7, imply that some bits (Ciccio in this case)
>>  are copied from the request's userInfo into the response's userInfo
>>  AUTO_GENERATEd URI. While a server might choose to do something like
>>  that, it's not required to.
> [MB] A note has been added with regards to the server choosing the
> XCON-USERID. Not sure that addresses your second concern. [/MB]
>> 
>> * It should be more clearly stated in 6.9 that the "confSummaryRequest"
>>  is hypothetical and is not actually being defined.
> [MB] Clarified that it's an example. [/MB]
>> 
>> * The URL sub-namespace registration html is not well formed
>>  (There's a spurious <a/>).
> [MB] Fixed. [/MB]
>> 
>> * Is there a privacy leak with cloning existing conferences? What text
>>  prevents any member from cloning the conference to see who is in what
>>  sidebar? Was the intent to not allow cloning of conferences that are
>>  in progress?
> [MB] We do allow cloning of active
> conferences IF the client has the appropriate privileges/authorization
> and thus the appropriate privacy is provided.   However,
> sidebars are the only situation where that is done and we do have general
> text that a conference server SHOULD only allow authorized entities to
> perform operations.  Perhaps we need to make that a MUST? I added
> add some text in the cloning section that the only scenario
> under which an active conference would be cloned would be a sidebar.
> [/MB]
>> 
>> * The security considerations section should call out that most CCMP commands
>>  can pend indefinitely - clients need to be ready to wait an arbitrary amount
>>  of time to get the response (see section 6.3 of xcon-examples and consider
>>  Alice not responding and the IVR not timing out, Alice using an automaton
>>  to keep the IVR from completing its script when it did have timeout protection,
>>  etc. The document should say what a client should do when it is no longer
>>  willing to wait (close the underlying connection?), and point out what
>>  servers can do if they have lots of pending requests starting to pile up.
> [MB] Added text to the 6th item on DoS attacks in the security section
> - not sure if that's the exact right place, but hopefully the text
> addresses the concern. [/MB]
>> 
>> _______________________________________________
>> XCON mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/xcon
>>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 7 Dec 2010 14:45:10 -0600

I reviewed the diffs between -10 and -11 (while waiting for -12).

All of my concerns have been addressed except for the AUTO_GENERATE text that

> XCON-USERID. Not sure that addresses your second concern. [/MB]

Not completely, but I don't think any more text is needed. My concern is
that an implementer or system designer would come away thinking that
the right way to code populating the auto-generated URI would be to take
the mailto: or sip: URI you provided and just change the scheme.

> addresses the concern. [/MB]

That's a good a place as any. The group should be sure to review the extra normative
statements you've added.

Thanks!

RjS

---

From: Mary Barnes <[email-masked]>
Date: Tue, 7 Dec 2010 15:33:33 -0600

I'll try to get that done by the end of the week (ideally tomorrow) - sorry
it got lost in the meeting and post-meeting shuffle.

Mary.

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 09 Dec 2010 15:59:45 +0100

Hi guys,

let me jump into the discussion, just to clarify a couple of pints which 
still look a bit obscure...
I'm sorry I wasn't able to get in synch with Mary, before. We had to 
meet in Beijing, but in the end I could not make it :-(.
Please see in-line ([spromano]) my considerations.

 > > sent.  A note in that regards to section 5.3.   [/MB]

/[spromano] For the sake of completeness, we must say that the CCMP 
schema allows to have empty "optionsRequest" messages.
/

 > > soon as submissions open up again.   [/MB]

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

 > > XCON-USERID. Not sure that addresses your second concern. [/MB]

/[spromano] Example 6.7 should just be taken as 'an' example. URI 
generation does not necessarily depend on the user's nickname contained 
in the <display-text> element. We made this choice in the document just 
to simplify and increase readability. In case you think this might be 
misleading, we can clarify the point.
/

 > >>  the full schema listed in section 11?

/[spromano] Here at the University of Napoli, we had Roberta Presta (who 
is co-authoring the call-flow draft) validate each and every piece of 
XML snippet (both schema and messages) that you find in the latest 
version of the draft. We used for this the JAXB APIs. The same holds for 
the XCON examples document, of course.

Hope this helps move the discussion forward.

Cheers,

Simon

/

Il 07/12/2010 22:33, Mary Barnes ha scritto:
> I'll try to get that done by the end of the week (ideally tomorrow) - 
> sorry it got lost in the meeting and post-meeting shuffle.
>
> Mary.
>
> On Tue, Dec 7, 2010 at 10:37 AM, Robert Sparks <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Mary -
>
>     > On Tue, Sep 14, 2010 at 10:51 AM, Robert Sparks
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     > [email-masked] <mailto:[email-masked]>
>     is one of example of the string that can
>     >> [email-masked] <mailto:[email-masked]>

-- 
                             _\\|//_
                             ( 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: Mary Barnes <[email-masked]>
Date: Fri, 10 Dec 2010 14:08:21 -0600

Simon,

Thanks for looking at this in detail. My responses inline below [MB2].

Mary.

On Thu, Dec 9, 2010 at 8:59 AM, Simon Pietro Romano <[email-masked]>wrote:

> I'm sorry I wasn't able to get in synch with Mary, before. We had to meet
> in Beijing, but in the end I could not make it :-(.
> *[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]

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

> * *
> *[spromano] Example 6.7 should just be taken as 'an' example. URI
> generation does not necessarily depend on the user's nickname contained in
> the <display-text> element. We made this choice in the document just to
> simplify and increase readability. In case you think this might be
> *
>  *[spromano] Here at the University of Napoli, we had Roberta Presta (who
> is co-authoring the call-flow draft) validate each and every piece of XML
> snippet (both schema and messages) that you find in the latest version of
> the draft. We used for this the JAXB APIs. The same holds for the XCON
> examples document, of course.
>
> *
> On Tue, Dec 7, 2010 at 10:37 AM, Robert Sparks <[email-masked]>wrote:
>
>> Hi Mary -
>>
> XCON mailing [email-masked]://www.ietf.org/mailman/listinfo/xcon
>
>
> --
>                             _\\|//_
>                             ( O-O )

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 13 Dec 2010 23:18:28 +0100

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.
>     /
>
> contain a confUserID as described in the paragraph after the bulleted 
> list in section 5.3.12:
> 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]

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

Cheers,
Simon

---

From: Mary Barnes <[email-masked]>
Date: Tue, 14 Dec 2010 12:08:00 -0600

Hi Simon,

Responses inline below [MB3].

Thanks,
Mary.

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

>   *[spromano] For the sake of completeness, we must say that the CCMP
> 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.?
>
> 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]

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

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 15 Dec 2010 09:44:28 +0100

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]

> 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