Re: [XCON] Review of draft-ietf-xcon-ccmp-03
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XCON] Review of draft-ietf-xcon-ccmp-03
Hi Richard,
first of all let us thank you for your thorough review. It proved
really helpful in suggesting us how to refine the document. Indeed, we
made a lot of modifications to the document form -03 to -04 version.
The current version should keep into account most of the reviewers'
comments and suggestions. The most inportant part of the new version
relates to the way CCMP handles update modifications. We do believe
that in its current form, the document is really on the right track to
reach its steady (and standard!) state.
Please find our detailed answers in-line.
DISCLAIMER: This is going to be a VEEERY LONG message ;-).
General comments:
1. The protocol seems pretty well thought out. Most of the below
comments are focused on clarity, but there are also a couple of
technical issues to be addressed.
Sounds good! This makes a good start, already.
2. It seems like this document and the data model should both use the
same specification language, either XSD or RelaxNG, to facilitate
parsing/validation.
Up to now, we have always sticked to the xsd approach. If needed, we
can provide a RelaxNG specification of the CCMP.
3. The document uses a mixture of single (') and double (") quotes
around things like element names. Might be nice to standardize on one
or the other.
Done. We chose double quotes as the "standard".
Specific comments:
Abstract
The abstract says that CCMP is stateless, but that seems a little weird
given that the whole point of the protocol is to modify the state of
the conference server. I understand the intent (the protocol itself is
stateless), but you might think about rewording.
Done. We changed text in the following way:
"Even though the goal of the CCMP is to appropriately manage
conference state, the mechanisms upon which the protocol itself is
built are based on a state-less request/response paradigm."
Does it look clearer now?
Section 4/5
These two sections could probably stand to be merged. I think it would
be helpful to have the content of Section 5 (especially Figure 1)
before most of Section 4, except maybe the first paragraph.
Section 5
Make sure that the label for Figure 1 stays with the figure.
Section 6
This section seems to be a little confused about what its purpose is.
The stated purpose is to give an overview of the conference and user
objects, but it has several tangential comments about how these objects
are handled in certain cases. Think about tightening the scope (see
below).
As to the above points, we restructured the overall document in a way
that looked more logical to us. We now have the following organization:
4: XCON Conference Control System Architecture
4.1. Conference Objects
4.2. Conference Users
5. Protocol Overview
5.1. Protocol Operations
5.2. Implementation Approach
6. CCMP messages
6.1. CCMP Request Message Type
6.2. CCMP Response Message Type
6.3. Detailed messages
Section 6.1, Paragraph 1
It might be helpful to provide a reference to Section 7.1 (Cloning
Tree) of RFC 5239 here.
Done.
Section 6.1, Paragraph 2, "A client MAY specify a parent element..."
The phrase "parent element" is a little confusing here, since we're
talking about XML objects, and the "parent" relationship is not in
terms of XML elements, but rather objects in the cloning tree. Suggest
changing this sentence to "A client MAY specify a parent object (a
conference or blueprint) from which to inherit values."
Done.
Section 6.1, Paragraph 2, "When creating conferences..."
This sentence seems like it belongs in Section 7.2.3.4 instead of here.
Section 6.2, Paragraph 1, "Users are inherited as well..."
For clarity, suggest adding "When a conference is cloned from a parent
object..."
Done.
Section 6.2, Paragraph 3
This paragraph seems like it belongs elsewhere, e.g., in Section
7.2.3.4 or 7.2.3.6.
Section 7.2
It took me a little while to figure out why all the messages in the
example are doubled up: "<ccmpRequest><ccmpRequest>..." It would be
helpful here to explain the general design methodology being followed
that leads to that. As I understand it, the idea is that you can carry
multiple request and response messages within a single request or
response. This idea would be helpful to note, as well as some idea of
how request and response messages are correlated. Also, since you
define elements for the detailed messages types, it would be clearer to
use those types in the examples (in Section 8), rather than casting
with xsi:type.
First, let us clarify that the protocol does not envisage that
multiple request (response) messages can be carried in a single
request (response). The relation is always one request (response)
message per request (response). The reason why you see the use of the
"xsi:type" instance specifier depends on our choice to specify the
protocol messages in an object-oriented fashion. We defined an
abstract structure associated with a generic request (response) and
containing the properties that are common to any CCMP message. Such
structure gets then specialized by actual message instances, which can
add to the basic message structure their own specific properties. BTW,
this approach allows for a direct mapping of the schema file onto code
implementations that can be automatically obtained through automated
binding technologies (e.g. JAXB for Java-based implementations). The
alternative would be to use the "xs:choice" schema element to describe
all message alternatives. While being equivalent at the logical level,
such approach typically brings to more weird mappings onto
implementations.
Section 7.2.1, confUserId, "This attribute is required ..."
Should there be RFC 2119 requirement here? "This attribute is REQUIRED..."
Done.
Section 7.2.1, password
I'm confused about how this parameter interacts with the
<conference-password> element in the data model: In the data model,
conference passwords are only scoped within a given <conf-uri>, whereas
a password for a CCMP request would presumably need to be scoped at the
level of the conference. Or is the CCMP password an independent value
not reflected in the conference object?
In rfc 4575, and in the Data Model as well, <conf-uris> is defined
as "a sequence of <entry> child elements - each containing the URI to
be used in order to access the conference by different signaling
means". For each such element, a password can be defined. We put the
XCON-URI among the above mentioned idetifiers (even though, strictly
speaking, it is not a signaling URI).
Hence, we also defined, for the XCON-URI, a password, like in the
following sample excerpt:
<info:conf-uris>
<info:entry>
<info:uri>xcon:8977794 at example.com</info:uri>
<info:display-text>Conference XCON-URI</info:display-text>
<xcon:conference-password>3456</xcon:conference-password>
</info:entry>
</info:conf-uris>
Section 7.2.1, Figure 2
It was helpful to have this structure here. It would be even better if
a brief example could be provided as well. Likewise for other sections
below.
We thought it would be sufficient to say that, for all interesting
scenarios, examples are provided in section 8. What is your feeling
about this?
Section 7.2.2.1
It's a little confusing to have the error messages introduced at this
point in the document, since the actions themselves haven't been
defined. Perhaps Table 2 (probably with the introductory text to
Section 7.2.3) could be moved up to Section 7.2.1 to give a clearer
idea of what the operations do.
Section 7.2.3, Paragraph 3 (counting the bulleted list as 1 para)
You need a different symbol than "N/A*" here, since * is also used with
a different meaning in the table.
Right. With the new structure of the document, these points should
have been fixed.
Section 7.2.3.3, Paragraph 3
The first sentence seems odd -- it's not clear in general that it
another blueprint would be useful to the conference client, so why
would it be RECOMMENDED to try another? Suggest changing to the
following: "If a response code fo "objectNotFound" is received in a
'blueprintResponse' message, a conference control client may attempt to
retrieve another conference blueprint if more than one had been
received in the "blueprintsResponse" message."
Done.
Section 7.2.3.4, Paragraph 6 (counting 2 bullets as 1 para)
The following phrase is confusing:
"
The 'confInfo' represents an object of type "conference-type"
containing all the changes to be applied...
"
"Conference-type" object, i.e., conference objects, represent
conference state, not changes. I see in the example (Section 8) that
the intent is to allow clients to send only a fragment of the
conference object, rather than the whole thing. There should be more
discussion here about how the client constructs the right fragment to
express his changes, and how the server interprets the fragment it gets.
You're definitely right on this. In version -04 of the protocol we
decided to adopt, for CCMP updates, a mechanism à la event package,
i.e. introduce versioning in CCMP messages. In order to effectively
manage modifications to conference data, a versioning approach is
exploited in the CCMP. In the following I'm pasting the part of
section 5.1 of version -04 which explains this point:
***** BEGIN SNIPPET FROM DRAFT *****
More precisely, each conference object is associated with a version
number indicating the most up to date view of the conference at the
server's side. Such version number is reported to the clients when
answering their requests. A client willing to make modifications to a
conference object has to send an update message to the server. In case
the modifications are all successfully applied, the server sends back
to the client a "success" response which also carries information
about the current server-side version of the modified object. With
such approach, a client which is working on version "X" of a
conference object and finds inside a "success" response a version
number which is "X+1" can be sure that the version it was aware of was
the most up to date. On the other hand, if the "success" response
carries back a version which is at least "X+2", the client can detect
that the object that has been modified at the server's side was more
up to date than the one it was working upon. This is clearly due to
the effect of concurrent modification requests issued by independent
clients. Hence, for the sake of having available the latest version of
the modified object, the client can send to the conference server a
further "retrieve" request. We remark that in no case a copy of the
conference object available at the server is returned to the client as
part of the update response message. Such a copy can always be
obtained through an ad-hoc "retrieve" message. Based on the above
considerations, all CCMP response messages except those associated
with the retrieval of either the list of blueprints or the list of
conferences will have to contain a mandatory "version" parameter. This
does not hold for request messages, for which the "version" parameter
is not at all required, since it represents useless information for
the server: as long as the required modifications can be applied to
the target conference object with no conflicts, the server does not
care whether or not the client had an up to date view of the
information stored at its side. This said, it stands clear that a
client which has subscribed at the server, through the XCON event
package [I?D.ietf?xcon?event?package], to notifications about
conference object modifications, will always have the most up to date
version of that object available at his side.
***** END SNIPPET FROM DRAFT *****
Section 7.2.3.5-10
Since users and sidebars are both sub-elements of the conferene object,
what's the rationale for handling them via separate CCMP requests? Is
the idea that it simplifies permissions management for the server (in
the case where some users are only allowed to access users/sidebars),
since the server doesn't have to look at what's in the changes to check
permissions?
It can also be useful in cases where the user is not interested in the
entire conference object, but just in some parts of it.
Section 7.2.3.5-10
Also, it seems like these messages should follow the pattern of the
blueprint[s] and conf[s] messages above: The plural messages should be
retreive-only, while the singular messages should allow other
operations.
Indeed, the idea here is that conferences and blueprints are
independently stored at the server. With the plural version of the
message you retrieve their
URIs, whereas with the singular version of the message you make a
drill-down query addressed to one specific server-side object.
Sidebars can only be retrieved by accessing the corresponding element
contained in the conference object associated with the 'main'
conference they belong to. That's why we only envisaged the second
kind of message (which, btw, has the plural representation due to the
name of the data model elements dealing with sidebars).
Hope this shades light on the comment above.
Section 7.2.3.5-6
How do these CCMP operations interact with the signaling protocols?
Presumably when a user joins via a CSP, he is added to the conference
object; is this equivalent to a userRequest/create operation?
Join operations with CCMP are equivalent to join operations via a CSP.
If a user wants to enter a conference via CCMP, she/he can issue a
userRequest/create message. Such request should act as a trigger for
the required signaling between the conference focus and the user. We
identified two distinct cases. The former relates to a user who
already has an xcon-userid (which means that the conference server is
aware of the mapping xcon-userid<-->CSP URI). In such case, the
userRequest/create message carries the user's xcon-userid inside the
'confUserId' parameter; the 'userInfo' parameter, in turn, contains a
<user> element whose 'entity' attribute is the mentioned xcon-userid.
The latter case refers to a user to whom no xcon-userid has been
assigned yet. In such case, the userRequest/create message carries a
void confUserId parameter, while the 'userInfo' parameter specifies
the sender's CSP address (e.g. her/his SIP URI). The server-created
xcon-userId is returned to the client inside the 'confUserId'
parameter of the response (which optionally also contains a whole
<user> element inside the 'userInfo' parameter).
In both cases, once done with the described CCMP interaction,
focus-user signaling starts. In the call flow examples draft, at page
28 ("adding a party") we also put a picture illustrating a possible
CCMP-CSP interaction in the case of user Alice trying to add user Bob
to a conference. In the mentioned example, after the CCMP request is
completed, the conference focus contacts Bob at the SIP address
communicated by Alice.
Indeed, all of the scenarios envisaged in RFC 4353 (page 14, "adding
participants") can be appropriately realized through the CCMP.
Section 7.2.3.5, Paragraph 2
s/userInfo/usersInfo/
Done.
Section 7.2.3.5, Bullet 1 (retreive)
Change SHOULD NOT to MUST NOT, since it is ignored anyway.
Done.
Section 7.2.3.5, Bullet 2 (update)
Same concern here as with 7.2.3.4 above -- how do you represent changes
with a users-type object?
See answer to 7.2.3.4 above...
Section 7.2.3.6, Paragraph 1, "Note that a user..."
This sentence seems like a non-sequitur: If a client is not XCON-aware,
then it's not going to generate these messages. Recommend saying
instead that some CSP operations might have the same effect as these
operations, i.e., that when a user joins/leaves/etc, the conference
server might perform an action that would otherwise be performed via a
userRequest.
The above sentence refers to the fact that the XCON Data Model also
contains information about users who are non XCON-aware participants
in a conference. Such users DO NOT interact with the conference server
via the CCMP. Hence, we are not referring here neither to the
generation of CCMP messages on their side, nor to the interaction
between CSP and CCMP (which we briefly described above -- see answer
to your question about Section 7.2.3.5-6). We might make a reference
here to the call flows document, which illustrates most of the notable
use-cases associated with such interaction. What do you think about
this? Alternatively, if the sentence in the draft is misleading, we
might just remove it.
Section 7.2.3.6, 'update' paragraph
Same concern here as with 7.2.3.4 above -- how do you represent changes
with a user-type object?
See answer to 7.2.3.4 above...
Section 7.2.3.8, 'update' paragraph
Same concern here as with 7.2.3.4 above -- how do you represent changes
with a conference-type object?
See answer to 7.2.3.4 above...
Section 7.2.3.10, 'update' paragraph
Same concern here as with 7.2.3.4 above -- how do you represent changes
with a conference-type object?
See answer to 7.2.3.4 above...
Section 9
Is this the process for dereferencing an XCON-URI? If so, you should say so.
This section illustrates how to derive the HTTP/HTTPS URI of the
"Conferencing Server" (i.e. the Conference Control Server). Should we
make this explicit (and also replace "Conferencing Server" with
"Conference Control Server")?
Section 11, Paragraph 3
The second sentence here ("Because the conferencing client...") doesn't
make sense. The reason you're not requiring HTTP authentication and
cookies is that CCMP has its own authentication. Suggest replacing with
"
A conferencing client that conforms to this specification is not
required to support HTTP authentication [RFC2617] or cookies [RFC2965].
These mechanisms are unnecessary because CCMP requests carry their own
authentication information (in the 'confUserId' and 'password' fields;
see Section 7.2.1).
"
Done! Sounds better this way...
Section 11, Paragraphs 4 and 7
Change first sentence to "CCMP requests MUST be carried in the body of
an HTTP POST request. If a CCMP server receives an HTTP request using
a method other than POST, it must respond with an error message, e.g.,
404 (not found)." In light of this change, paragraph 7 could be
deleted. On the other hand, it seems like it wouldn't be unreasonable
for the server to respond to a HEAD request. In which case: "CCMP
requests MUST be carried in the body of an HTTP POST request. A CCMP
server MAY respond to HEAD requests. If a CCMP server receives an HTTP
request using a method other than POST or HEAD, it must respond with an
error message, e.g., 404 (not found)."
We think the above paragraphs might stay unchanged except for the
error message returned, which should be a 405 (method not allowed),
rather than a generic 404.
What's your feeling about that?
Section 12
The security considerations here are relatively comprehensive, but a
little scatter-shot. I will provide a more thorough review of this
section later.
Perfect. We'll wait for your feedback on that specific part.
Section 14.4.1-2
I'm guessing you mean to register "Conference Server" tags rather than
"Location Server" tags, and for CCMP rather than HELD.
Your guess is definitely right ;-).
Regards,
Simon
Quoting Richard Barnes <rbarnes at bbn.com>:
Hi all,
In my effort to get up to speed on XCON, I'm in the process of
reviewing the active working group drafts (in addition to the other
relevant background). My review of draft-ietf-xcon-ccmp-03 is below.
--Richard
-----
Draft: draft-ietf-xcon-common-data-model-13
Reviewer: Richard Barnes
Review Date: 18 Aug 09
General comments:
1. The protocol seems pretty well thought out. Most of the below
comments are focused on clarity, but there are also a couple of
technical issues to be addressed.
2. It seems like this document and the data model should both use the
same specification language, either XSD or RelaxNG, to facilitate
parsing/validation.
3. The document uses a mixture of single (') and double (") quotes
around things like element names. Might be nice to standardize on one
or the other.
Specific comments:
Abstract
The abstract says that CCMP is stateless, but that seems a little weird
given that the whole point of the protocol is to modify the state of
the conference server. I understand the intent (the protocol itself is
stateless), but you might think about rewording.
Section 4/5
These two sections could probably stand to be merged. I think it would
be helpful to have the content of Section 5 (especially Figure 1)
before most of Section 4, except maybe the first paragraph.
Section 5
Make sure that the label for Figure 1 stays with the figure.
Section 6
This section seems to be a little confused about what its purpose is.
The stated purpose is to give an overview of the conference and user
objects, but it has several tangential comments about how these objects
are handled in certain cases. Think about tightening the scope (see
below).
Section 6.1, Paragraph 1
It might be helpful to provide a reference to Section 7.1 (Cloning
Tree) of RFC 5239 here.
Section 6.1, Paragraph 2, "A client MAY specify a parent element..."
The phrase "parent element" is a little confusing here, since we're
talking about XML objects, and the "parent" relationship is not in
terms of XML elements, but rather objects in the cloning tree. Suggest
changing this sentence to "A client MAY specify a parent object (a
conference or blueprint) from which to inherit values."
Section 6.1, Paragraph 2, "When creating conferences..."
This sentence seems like it belongs in Section 7.2.3.4 instead of here.
Section 6.2, Paragraph 1, "Users are inherited as well..."
For clarity, suggest adding "When a conference is cloned from a parent
object..."
Section 6.2, Paragraph 3
This paragraph seems like it belongs elsewhere, e.g., in Section
7.2.3.4 or 7.2.3.6.
Section 7.2
It took me a little while to figure out why all the messages in the
example are doubled up: "<ccmpRequest><ccmpRequest>..." It would be
helpful here to explain the general design methodology being followed
that leads to that. As I understand it, the idea is that you can carry
multiple request and response messages within a single request or
response. This idea would be helpful to note, as well as some idea of
how request and response messages are correlated. Also, since you
define elements for the detailed messages types, it would be clearer to
use those types in the examples (in Section 8), rather than casting
with xsi:type.
Section 7.2.1, confUserId, "This attribute is required ..."
Should there be RFC 2119 requirement here? "This attribute is REQUIRED..."
Section 7.2.1, password
I'm confused about how this parameter interacts with the
<conference-password> element in the data model: In the data model,
conference passwords are only scoped within a given <conf-uri>, whereas
a password for a CCMP request would presumably need to be scoped at the
level of the conference. Or is the CCMP password an independent value
not reflected in the conference object?
Section 7.2.1, Figure 2
It was helpful to have this structure here. It would be even better if
a brief example could be provided as well. Likewise for other sections
below.
Section 7.2.2.1
It's a little confusing to have the error messages introduced at this
point in the document, since the actions themselves haven't been
defined. Perhaps Table 2 (probably with the introductory text to
Section 7.2.3) could be moved up to Section 7.2.1 to give a clearer
idea of what the operations do.
Section 7.2.3, Paragraph 3 (counting the bulleted list as 1 para)
You need a different symbol than "N/A*" here, since * is also used with
a different meaning in the table.
Section 7.2.3.3, Paragraph 3
The first sentence seems odd -- it's not clear in general that it
another blueprint would be useful to the conference client, so why
would it be RECOMMENDED to try another? Suggest changing to the
following: "If a response code fo "objectNotFound" is received in a
'blueprintResponse' message, a conference control client may attempt to
retrieve another conference blueprint if more than one had been
received in the "blueprintsResponse" message."
Section 7.2.3.4, Paragraph 6 (counting 2 bullets as 1 para)
The following phrase is confusing:
"
The 'confInfo' represents an object of type "conference-type"
containing all the changes to be applied...
"
"Conference-type" object, i.e., conference objects, represent
conference state, not changes. I see in the example (Section 8) that
the intent is to allow clients to send only a fragment of the
conference object, rather than the whole thing. There should be more
discussion here about how the client constructs the right fragment to
express his changes, and how the server interprets the fragment it gets.
Section 7.2.3.5-10
Since users and sidebars are both sub-elements of the conferene object,
what's the rationale for handling them via separate CCMP requests? Is
the idea that it simplifies permissions management for the server (in
the case where some users are only allowed to access users/sidebars),
since the server doesn't have to look at what's in the changes to check
permissions?
Section 7.2.3.5-10
Also, it seems like these messages should follow the pattern of the
blueprint[s] and conf[s] messages above: The plural messages should be
retreive-only, while the singular messages should allow other
operations.
Section 7.2.3.5-6
How do these CCMP operations interact with the signaling protocols?
Presumably when a user joins via a CSP, he is added to the conference
object; is this equivalent to a userRequest/create operation?
Section 7.2.3.5, Paragraph 2
s/userInfo/usersInfo/
Section 7.2.3.5, Bullet 1 (retreive)
Change SHOULD NOT to MUST NOT, since it is ignored anyway.
Section 7.2.3.5, Bullet 2 (update)
Same concern here as with 7.2.3.4 above -- how do you represent changes
with a users-type object?
Section 7.2.3.6, Paragraph 1, "Note that a user..."
This sentence seems like a non-sequitur: If a client is not XCON-aware,
then it's not going to generate these messages. Recommend saying
instead that some CSP operations might have the same effect as these
operations, i.e., that when a user joins/leaves/etc, the conference
server might perform an action that would otherwise be performed via a
userRequest.
Section 7.2.3.6, 'update' paragraph
Same concern here as with 7.2.3.4 above -- how do you represent changes
with a user-type object?
Section 7.2.3.8, 'update' paragraph
Same concern here as with 7.2.3.4 above -- how do you represent changes
with a conference-type object?
Section 7.2.3.10, 'update' paragraph
Same concern here as with 7.2.3.4 above -- how do you represent changes
with a conference-type object?
Section 9
Is this the process for dereferencing an XCON-URI? If so, you should say so.
Section 11, Paragraph 3
The second sentence here ("Because the conferencing client...") doesn't
make sense. The reason you're not requiring HTTP authentication and
cookies is that CCMP has its own authentication. Suggest replacing with
"
A conferencing client that conforms to this specification is not
required to support HTTP authentication [RFC2617] or cookies [RFC2965].
These mechanisms are unnecessary because CCMP requests carry their own
authentication information (in the 'confUserId' and 'password' fields;
see Section 7.2.1).
"
Section 11, Paragraphs 4 and 7
Change first sentence to "CCMP requests MUST be carried in the body of
an HTTP POST request. If a CCMP server receives an HTTP request using
a method other than POST, it must respond with an error message, e.g.,
404 (not found)." In light of this change, paragraph 7 could be
deleted. On the other hand, it seems like it wouldn't be unreasonable
for the server to respond to a HEAD request. In which case: "CCMP
requests MUST be carried in the body of an HTTP POST request. A CCMP
server MAY respond to HEAD requests. If a CCMP server receives an HTTP
request using a method other than POST or HEAD, it must respond with an
error message, e.g., 404 (not found)."
Section 12
The security considerations here are relatively comprehensive, but a
little scatter-shot. I will provide a more thorough review of this
section later.
Section 14.4.1-2
I'm guessing you mean to register "Conference Server" tags rather than
"Location Server" tags, and for CCMP rather than HELD.
_______________________________________________
XCON mailing list
XCON at ietf.org
https://www.ietf.org/mailman/listinfo/xcon
--
_\\|//_
( 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 at unina.it
<<Molti mi dicono che lo scoraggiamento è l'alibi degli
idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
oooO
~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
\ ( ( )
\_) ) /
(_/
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
