From spromano@unina.it  Mon Nov  2 09:35:57 2009
Return-Path: <spromano@unina.it>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF4628C18C for <xcon@core3.amsl.com>; Mon,  2 Nov 2009 09:35:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.881
X-Spam-Level: *
X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veJ4jwwD6Gl8 for <xcon@core3.amsl.com>; Mon,  2 Nov 2009 09:35:56 -0800 (PST)
Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 4FFA628C17C for <xcon@ietf.org>; Mon,  2 Nov 2009 09:35:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id nA2HaDwQ011404; Mon, 2 Nov 2009 18:36:13 +0100
Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 02 Nov 2009 18:36:13 +0100
Message-ID: <20091102183613.yw41ed71y4gwg4cw@webmail.unina.it>
Date: Mon, 02 Nov 2009 18:36:13 +0100
From: spromano@unina.it
To: xcon@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.6)
X-Virus-Scanned: ClamAV 0.94.2/9751/Thu Aug 27 19:08:53 2009 on webmail.unina.it
X-Virus-Status: Clean
Subject: [XCON] New version of CCMP (draft-ietf-xcon-ccmp-04)
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2009 17:35:57 -0000

Hi all,

as you may know, we missed the deadline for submitting the -04 version =20
of the draft. While we wait for submissions to re-open, I put it on a =20
provisional server. You can download it at the following URL:

HTML version: http://www.meetecho.com/drafts/draft-ietf-xcon-ccmp-04.html
TXT version: http://www.meetecho.com/drafts/draft-ietf-xcon-ccmp-04.txt

You will notice that many things have changed in this new version. I'm =20
going to send in a minute on the mailing list our answers to the =20
reviews we received and which were really of great help.

Cheers,

Simon

--=20
                             _\\|//_
                             ( 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

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


From spromano@unina.it  Mon Nov  2 09:37:30 2009
Return-Path: <spromano@unina.it>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40243A6A64 for <xcon@core3.amsl.com>; Mon,  2 Nov 2009 09:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.936
X-Spam-Level: ***
X-Spam-Status: No, score=3.936 tagged_above=-999 required=5 tests=[AWL=-2.055,  BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, MANGLED_AVOID=2.3, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjwPafeRjDmB for <xcon@core3.amsl.com>; Mon,  2 Nov 2009 09:37:28 -0800 (PST)
Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id A32D73A6A3F for <xcon@ietf.org>; Mon,  2 Nov 2009 09:37:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id nA2HbVj8011684; Mon, 2 Nov 2009 18:37:32 +0100
Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 02 Nov 2009 18:37:31 +0100
Message-ID: <20091102183731.mcs6jhmio4cgk8cg@webmail.unina.it>
Date: Mon, 02 Nov 2009 18:37:31 +0100
From: spromano@unina.it
To: Richard Barnes <rbarnes@bbn.com>
References: <4A898F16.2040303@bbn.com>
In-Reply-To: <4A898F16.2040303@bbn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.6)
X-Virus-Scanned: ClamAV 0.94.2/9751/Thu Aug 27 19:08:53 2009 on webmail.unina.it
X-Virus-Status: Clean
Cc: xcon@ietf.org
Subject: Re: [XCON] Review of draft-ietf-xcon-ccmp-03
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2009 17:37:30 -0000

Hi Richard,

first of all let us thank you for your thorough review. It proved =20
really helpful in suggesting us how to refine the document. Indeed, we =20
made a lot of modifications to the document form -03 to -04 version. =20
The current version should keep into account most of the reviewers' =20
comments and suggestions. The most inportant part of the new version =20
relates to the way CCMP handles update modifications. We do believe =20
that in its current form, the document is really on the right track to =20
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 =20
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 =20
conference state, the mechanisms upon which the protocol itself is =20
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 =20
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 =20
multiple request (response) messages can be carried in a single =20
request (response). The relation is always one request (response) =20
message per request (response). The reason why you see the use of the =20
"xsi:type" instance specifier depends on our choice to specify the =20
protocol messages in an object-oriented fashion. We defined an =20
abstract structure associated with a generic request (response) and =20
containing the properties that are common to any CCMP message. Such =20
structure gets then specialized by actual message instances, which can =20
add to the basic message structure their own specific properties. BTW, =20
this approach allows for a direct mapping of the schema file onto code =20
implementations that can be automatically obtained through automated =20
binding technologies (e.g. JAXB for Java-based implementations). The =20
alternative would be to use the "xs:choice" schema element to describe =20
all message alternatives. While being equivalent at the logical level, =20
such approach typically brings to more weird mappings onto =20
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 =20
as "a sequence of <entry> child elements - each containing the URI to =20
be used in order to access the conference by different signaling =20
means". For each such element, a password can be defined. We put the =20
XCON-URI among the above mentioned idetifiers (even though, strictly =20
speaking, it is not a signaling URI).
Hence, we also defined, for the XCON-URI, a password, like in the =20
following sample excerpt:

<info:conf-uris>
      <info:entry>
           <info:uri>xcon:8977794@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 =20
scenarios, examples are provided in section 8. What is your feeling =20
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 =20
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 =20
decided to adopt, for CCMP updates, a mechanism =E0 la event package, =20
i.e. introduce versioning in CCMP messages. In order to effectively =20
manage modifications to conference data, a versioning approach is =20
exploited in the CCMP. In the following I'm pasting the part of =20
section 5.1 of version -04 which explains this point:


***** BEGIN SNIPPET FROM DRAFT *****

More precisely, each conference object is associated with a version =20
number indicating the most up to date view of the conference at the =20
server's side. Such version number is reported to the clients when =20
answering their requests. A client willing to make modifications to a =20
conference object has to send an update message to the server. In case =20
the modifications are all successfully applied, the server sends back =20
to the client a "success" response which also carries information =20
about the current server-side version of the modified object. With =20
such approach, a client which is working on version "X" of a =20
conference object and finds inside a "success" response a version =20
number which is "X+1" can be sure that the version it was aware of was =20
the most up to date. On the other hand, if the "success" response =20
carries back a version which is at least "X+2", the client can detect =20
that the object that has been modified at the server's side was more =20
up to date than the one it was working upon. This is clearly due to =20
the effect of concurrent modification requests issued by independent =20
clients. Hence, for the sake of having available the latest version of =20
the modified object, the client can send to the conference server a =20
further "retrieve" request. We remark that in no case a copy of the =20
conference object available at the server is returned to the client as =20
part of the update response message. Such a copy can always be =20
obtained through an ad-hoc "retrieve" message. Based on the above =20
considerations, all CCMP response messages except those associated =20
with the retrieval of either the list of blueprints or the list of =20
conferences will have to contain a mandatory "version" parameter. This =20
does not hold for request messages, for which the "version" parameter =20
is not at all required, since it represents useless information for =20
the server: as long as the required modifications can be applied to =20
the target conference object with no conflicts, the server does not =20
care whether or not the client had an up to date view of the =20
information stored at its side. This said, it stands clear that a =20
client which has subscribed at the server, through the XCON event =20
package [I?D.ietf?xcon?event?package], to notifications about =20
conference object modifications, will always have the most up to date =20
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 =20
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 =20
independently stored at the server. With the plural version of the =20
message you retrieve their
URIs, whereas with the singular version of the message you make a =20
drill-down query addressed to one specific server-side object. =20
Sidebars can only be retrieved by accessing the corresponding element =20
contained in the conference object associated with the 'main' =20
conference they belong to. That's why we only envisaged the second =20
kind of message (which, btw, has the plural representation due to the =20
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. =20
If a user wants to enter a conference via CCMP, she/he can issue a =20
userRequest/create message. Such request should act as a trigger for =20
the required signaling between the conference focus and the user. We =20
identified two distinct cases. The former relates to a user who =20
already has an xcon-userid (which means that the conference server is =20
aware of the mapping xcon-userid<-->CSP URI). In such case, the =20
userRequest/create message carries the user's xcon-userid inside the =20
'confUserId' parameter; the 'userInfo' parameter, in turn, contains a =20
<user> element whose 'entity' attribute is the mentioned xcon-userid.
The latter case refers to a user to whom no xcon-userid has been =20
assigned yet. In such case, the userRequest/create message carries a =20
void confUserId parameter, while the 'userInfo' parameter specifies =20
the sender's CSP address (e.g. her/his SIP URI). The server-created =20
xcon-userId is returned to the client inside the 'confUserId' =20
parameter of the response (which optionally also contains a whole =20
<user> element inside the 'userInfo' parameter).

In both cases, once done with the described CCMP interaction, =20
focus-user signaling starts. In the call flow examples draft, at page =20
28 ("adding a party") we also put a picture illustrating a possible =20
CCMP-CSP interaction in the case of user Alice trying to add user Bob =20
to a conference. In the mentioned example, after the CCMP request is =20
completed, the conference focus contacts Bob at the SIP address =20
communicated by Alice.

Indeed, all of the scenarios envisaged in RFC 4353 (page 14, "adding =20
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 =20
contains information about users who are non XCON-aware participants =20
in a conference. Such users DO NOT interact with the conference server =20
via the CCMP. Hence, we are not referring here neither to the =20
generation of CCMP messages on their side, nor to the interaction =20
between CSP and CCMP (which we briefly described above -- see answer =20
to your question about Section 7.2.3.5-6). We might make a reference =20
here to the call flows document, which illustrates most of the notable =20
use-cases associated with such interaction. What do you think about =20
this? Alternatively, if the sentence in the draft is misleading, we =20
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 =20
"Conferencing Server" (i.e. the Conference Control Server). Should we =20
make this explicit (and also replace "Conferencing Server" with =20
"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 =20
error message returned, which should be a 405 (method not allowed), =20
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@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@ietf.org
> https://www.ietf.org/mailman/listinfo/xcon



--=20
                             _\\|//_
                             ( 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

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


From spromano@unina.it  Mon Nov  2 09:44:24 2009
Return-Path: <spromano@unina.it>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38BA3A68D0 for <xcon@core3.amsl.com>; Mon,  2 Nov 2009 09:44:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.609
X-Spam-Level: *
X-Spam-Status: No, score=1.609 tagged_above=-999 required=5 tests=[AWL=2.328,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXWUBMwmY2m3 for <xcon@core3.amsl.com>; Mon,  2 Nov 2009 09:44:23 -0800 (PST)
Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id BA49028C186 for <xcon@ietf.org>; Mon,  2 Nov 2009 09:44:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id nA2HieMW013137; Mon, 2 Nov 2009 18:44:41 +0100
Received: from 143.225.229.230 ([143.225.229.230]) by webmail.unina.it (Horde MIME library) with HTTP; Mon, 02 Nov 2009 18:44:40 +0100
Message-ID: <20091102184440.4g7c5dlnkkso4ggg@webmail.unina.it>
Date: Mon, 02 Nov 2009 18:44:40 +0100
From: spromano@unina.it
To: Simo.Veikkolainen@nokia.com
References: <B23B311878A0B4438F5F09F47E01AAE03B18E5F6AB@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <B23B311878A0B4438F5F09F47E01AAE03B18E5F6AB@NOK-EUMSG-01.mgdnok.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.6)
X-Virus-Scanned: ClamAV 0.94.2/9751/Thu Aug 27 19:08:53 2009 on webmail.unina.it
X-Virus-Status: Clean
Cc: xcon@ietf.org
Subject: Re: [XCON] My review of draft-ietf-xcon-ccmp-03
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2009 17:44:24 -0000

Hi Simo,

I've just circulated the new draft, together with detailed answers to =20
Richard's review. We'll also prepare a detailed answer to your own =20
review in the next few days. In the meanwhile, if you have a look at =20
version -04, you'll notice that most of your questions/suggestions =20
should already be reflected in the document.

I would really appreciate if you can take some more time out of your =20
busy schedule to read the document before next Thursday's session!

Thanks a lot in advance,

Simon

Quoting Simo.Veikkolainen@nokia.com:

> Hello,
>
> I have now completed my review of draft-ietf-xcon-ccmp-03, for which =20
>  I volunteered in Stockholm meeting. I apologize for the  =20
> embarrasingly long time this took.
>
>
> Document: draft-ietf-xcon-ccmp-03
> Reviewer: Simo Veikkolainen
> Review date: Oct 22, 2009
>
> General comments
> ----------------
>
> The document seems to be in a good shape, I only had minor concerns  =20
> and comments. Note that I didn't review the schema because as I'm  =20
> not very fluent in XML.
>
> P. 7 "... the conference server SHOULD indicate that the data has  =20
> been modified and return the current conference object to the  =20
> client." It might be beneficial that some operations succeed even if =20
>  the object does not reflect the current state. Example: adding a =20
> user.
>
> P. 13 "[...] delete: to remove from the system a conference object  =20
> or a conference user" Does this apply also to conference sidebars?
>
> P. 36 When updating conference information, it was not always clear  =20
> whether the 'xxxInfo' should contain the entire element as defined  =20
> by the XCON data model, or is it possible to update just part of the =20
>  element. For example, when performing sending userRequest with  =20
> operation 'update', does the userInfo contain a complete <user>  =20
> element as defined by the data model? This should be clearly  =20
> indicated when describing each update operation.
>
> P. 72 The documents states that "For the case of users joining the  =20
> conference using the CCMP, TLS is RECOMMENDED". However, this does  =20
> not cover client authentication. What should the client  =20
> authentication mechanism to be (in case of CCMP), especially when  =20
> Section 11 says a conferencing client SHOULD NOT be required to  =20
> support HTTP authentication.
>
> P. 73 Section 12.3 states that the privacy of the conference users  =20
> is accomplished by manipulation of the "provide-anonymity" element.  =20
> The description of how the "provide-anonymity" element is  =20
> manipulated leaves some issues: for example, is it allowed to delete =20
>  the "provide-anonymity" element, and if yes, how can this be done?
>
> P. 65 An example of how Alice removes a participant from the  =20
> conference would be useful.
>
> Editorial and nits
> -------------------
> - check the usage of REQUIRED keyword in the whole document. Often,  =20
> the word is capitalized when actually there is no normative  =20
> statement made. For example: "[...] no additional information is  =20
> REQUIRED in the 'confResponse'" on page 29.
>
> P. 15 "A specialized response message MUST [...]" should be "A  =20
> specialized request message MUST [...]"
>
> P. 29 "In case of of a confRequest" -> duplicate "of"
>
> P. 29 "A response code of 'success' indicates that the referenced  =20
> conference document has not been changed by the conference server."  =20
> This should be "[...] has been changed [...]", right?
>
> P. 31 "If the 'userInfo' parameter is included [...]" Parameter name =20
>  should be 'usersInfo'
>
> P. 34 Delete "We remark that" from the beginning of the second paragraph.
>
> P. 36 "In both cases [...]" Which both cases do you refer to?
>
> P. 36 "In case of of [...]" Delete latter "of"
>
> P. 36 "[...] MUST be included in the 'confResponse' and the  =20
> 'userInfo' parameter MUST contain the entire <user> element which to =20
>  which [...]" -> delete "which to"
>
> P. 53 in the signalling diagram, what is "bp123"? Shouldn't this be  =20
> the XCON URI?
>
> P. 58 Similarly, what is "conf456Updates" in the signalling diagram?
>
> P. 71 1st bullet: reference is missing.
>
> P. 71 2nd bullet: MSUT -> MUST. I would also reword this to require  =20
> that the client must be able check the server's identity (using a  =20
> certificate).
>
> Regards,
> Simo
>
>
>
>
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www.ietf.org/mailman/listinfo/xcon
>



--=20
                             _\\|//_
                             ( 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

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


From root@core3.amsl.com  Mon Nov  9 23:00:01 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: xcon@ietf.org
Delivered-To: xcon@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 4C1FD3A6899; Mon,  9 Nov 2009 23:00:00 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20091110070001.4C1FD3A6899@core3.amsl.com>
Date: Mon,  9 Nov 2009 23:00:01 -0800 (PST)
Cc: xcon@ietf.org
Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-14.txt
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2009 07:00:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Centralized Conferencing Working Group of the IETF.


	Title           : Conference Information Data Model for Centralized Conferencing (XCON)
	Author(s)       : O. Novo, et al.
	Filename        : draft-ietf-xcon-common-data-model-14.txt
	Pages           : 92
	Date            : 2009-11-09

This document defines an Extensible Markup Language (XML)-based
conference information data model for centralized conferencing
(XCON).  A conference information data model is designed to convey
information about the conference and about participation in the
conference.  The conference information data model defined in this
document constitutes an extension of the data format specified in the
Session Initiation Protocol (SIP) Event Package for Conference State.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 14, 2010.

Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-14.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-xcon-common-data-model-14.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-11-09224654.I-D@ietf.org>


--NextPart--

From drage@alcatel-lucent.com  Mon Nov  9 23:41:11 2009
Return-Path: <drage@alcatel-lucent.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657253A692F for <xcon@core3.amsl.com>; Mon,  9 Nov 2009 23:41:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.434
X-Spam-Level: 
X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMkpXBhAJK4l for <xcon@core3.amsl.com>; Mon,  9 Nov 2009 23:41:10 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 454513A67DD for <xcon@ietf.org>; Mon,  9 Nov 2009 23:41:10 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAA7faap032742 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <xcon@ietf.org>; Tue, 10 Nov 2009 08:41:36 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 10 Nov 2009 08:41:36 +0100
From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
To: "xcon@ietf.org" <xcon@ietf.org>
Date: Tue, 10 Nov 2009 08:41:34 +0100
Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-common-data-model-14.txt
Thread-Index: Acph036NHdXsRsdUTeG9RKH2tgMwPwABWaDA
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE2092E625E@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <20091110070001.4C1FD3A6899@core3.amsl.com>
In-Reply-To: <20091110070001.4C1FD3A6899@core3.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84
Subject: Re: [XCON] I-D Action:draft-ietf-xcon-common-data-model-14.txt
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2009 07:41:11 -0000

The status of this document on the ID tracker is DEAD, which means that som=
eone at some time has set that tag against this document. Resubmitting the =
document will not change that status.

So can the WG chairs please give the true status, as there is little point =
in revising DEAD documents.

regards

Keith=20

> -----Original Message-----
> From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On=20
> Behalf Of Internet-Drafts@ietf.org
> Sent: Tuesday, November 10, 2009 7:00 AM
> To: i-d-announce@ietf.org
> Cc: xcon@ietf.org
> Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-14.txt
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Centralized Conferencing=20
> Working Group of the IETF.
>=20
>=20
> 	Title           : Conference Information Data Model for=20
> Centralized Conferencing (XCON)
> 	Author(s)       : O. Novo, et al.
> 	Filename        : draft-ietf-xcon-common-data-model-14.txt
> 	Pages           : 92
> 	Date            : 2009-11-09
>=20
> This document defines an Extensible Markup Language=20
> (XML)-based conference information data model for centralized=20
> conferencing (XCON).  A conference information data model is=20
> designed to convey information about the conference and about=20
> participation in the conference.  The conference information=20
> data model defined in this document constitutes an extension=20
> of the data format specified in the Session Initiation=20
> Protocol (SIP) Event Package for Conference State.
>=20
> Status of this Memo
>=20
> This Internet-Draft is submitted to IETF in full conformance=20
> with the provisions of BCP 78 and BCP 79.
>=20
> Internet-Drafts are working documents of the Internet=20
> Engineering Task Force (IETF), its areas, and its working=20
> groups.  Note that other groups may also distribute working=20
> documents as Internet- Drafts.
>=20
> Internet-Drafts are draft documents valid for a maximum of=20
> six months and may be updated, replaced, or obsoleted by=20
> other documents at any time.  It is inappropriate to use=20
> Internet-Drafts as reference material or to cite them other=20
> than as "work in progress."
>=20
> The list of current Internet-Drafts can be accessed at=20
> http://www.ietf.org/ietf/1id-abstracts.txt.
>=20
> The list of Internet-Draft Shadow Directories can be accessed=20
> at http://www.ietf.org/shadow.html.
>=20
> This Internet-Draft will expire on May 14, 2010.
>=20
> Copyright Notice
> Copyright (c) 2009 IETF Trust and the persons identified as=20
> the document authors.  All rights reserved.
>=20
> This document is subject to BCP 78 and the IETF Trust's Legal=20
> Provisions Relating to IETF Documents
> (http://trustee.ietf.org/license-info) in effect on the date=20
> of publication of this document.  Please review these=20
> documents carefully, as they describe your rights and=20
> restrictions with respect to this document.  Code Components=20
> extracted from this document must include Simplified BSD=20
> License text as described in Section 4.e of the Trust Legal=20
> Provisions and are provided without warranty as described in=20
> the BSD License.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-dat
> a-model-14.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail=20
> reader implementation to automatically retrieve the ASCII=20
> version of the Internet-Draft.
> =

From root@core3.amsl.com  Wed Nov 11 18:00:02 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: xcon@ietf.org
Delivered-To: xcon@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 1703D3A68FC; Wed, 11 Nov 2009 18:00:01 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20091112020002.1703D3A68FC@core3.amsl.com>
Date: Wed, 11 Nov 2009 18:00:02 -0800 (PST)
Cc: xcon@ietf.org
Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2009 02:00:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Centralized Conferencing Working Group of the IETF.


	Title           : Centralized Conferencing Manipulation Protocol
	Author(s)       : M. Barnes, et al.
	Filename        : draft-ietf-xcon-ccmp-04.txt
	Pages           : 98
	Date            : 2009-11-11

The Centralized Conferencing Manipulation Protocol (CCMP) can create,
retrieve, change and delete objects describing a centralized
conference, such as state and capabilities of the conference,
participants, and their roles.  The conference information is
contained in XML documents and fragments conforming to the
centralized conferencing data model schema.  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.  Conferencing clients send requests to
conference servers, which respond to the client with the conference
information.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 16, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-xcon-ccmp-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-11-11175217.I-D@ietf.org>


--NextPart--

From rjsparks@nostrum.com  Thu Nov 12 17:04:43 2009
Return-Path: <rjsparks@nostrum.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34523A6AEC for <xcon@core3.amsl.com>; Thu, 12 Nov 2009 17:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQvOHVXWQ-Sn for <xcon@core3.amsl.com>; Thu, 12 Nov 2009 17:04:42 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 498723A69E1 for <xcon@ietf.org>; Thu, 12 Nov 2009 17:04:42 -0800 (PST)
Received: from host-16-56.meeting.ietf.org (host-16-56.meeting.ietf.org [133.93.16.56]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAD156M4066847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Nov 2009 19:05:08 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-Id: <EE2BED2B-9201-4F68-88A0-D7FF9D20B8A9@nostrum.com>
From: Robert Sparks <rjsparks@nostrum.com>
To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE2092E625E@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 13 Nov 2009 10:05:05 +0900
References: <20091110070001.4C1FD3A6899@core3.amsl.com> <EDC0A1AE77C57744B664A310A0B23AE2092E625E@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
X-Mailer: Apple Mail (2.936)
Received-SPF: pass (nostrum.com: 133.93.16.56 is authenticated by a trusted mechanism)
Cc: "xcon@ietf.org" <xcon@ietf.org>
Subject: Re: [XCON] I-D Action:draft-ietf-xcon-common-data-model-14.txt
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2009 01:04:43 -0000

There is a script running on a timer at the secretariat that moves  
drafts in certain states that have not changed in a certain amount of  
time to DEAD.

I moved it back into AD is watching shortly after the robot tried to  
murder its state.

The chairs clarified during the meeting that this draft is in a  
holding pattern and will be sent to the IESG at the same time as ccmp.

RjS

On Nov 10, 2009, at 4:41 PM, DRAGE, Keith (Keith) wrote:

> The status of this document on the ID tracker is DEAD, which means  
> that someone at some time has set that tag against this document.  
> Resubmitting the document will not change that status.
>
> So can the WG chairs please give the true status, as there is little  
> point in revising DEAD documents.
>
> regards
>
> Keith
>
>> -----Original Message-----
>> From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On
>> Behalf Of Internet-Drafts@ietf.org
>> Sent: Tuesday, November 10, 2009 7:00 AM
>> To: i-d-announce@ietf.org
>> Cc: xcon@ietf.org
>> Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-14.txt
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>> This draft is a work item of the Centralized Conferencing
>> Working Group of the IETF.
>>
>>
>> 	Title           : Conference Information Data Model for
>> Centralized Conferencing (XCON)
>> 	Author(s)       : O. Novo, et al.
>> 	Filename        : draft-ietf-xcon-common-data-model-14.txt
>> 	Pages           : 92
>> 	Date            : 2009-11-09
>>
>> This document defines an Extensible Markup Language
>> (XML)-based conference information data model for centralized
>> conferencing (XCON).  A conference information data model is
>> designed to convey information about the conference and about
>> participation in the conference.  The conference information
>> data model defined in this document constitutes an extension
>> of the data format specified in the Session Initiation
>> Protocol (SIP) Event Package for Conference State.
>>
>> Status of this Memo
>>
>> This Internet-Draft is submitted to IETF in full conformance
>> with the provisions of BCP 78 and BCP 79.
>>
>> Internet-Drafts are working documents of the Internet
>> Engineering Task Force (IETF), its areas, and its working
>> groups.  Note that other groups may also distribute working
>> documents as Internet- Drafts.
>>
>> Internet-Drafts are draft documents valid for a maximum of
>> six months and may be updated, replaced, or obsoleted by
>> other documents at any time.  It is inappropriate to use
>> Internet-Drafts as reference material or to cite them other
>> than as "work in progress."
>>
>> The list of current Internet-Drafts can be accessed at
>> http://www.ietf.org/ietf/1id-abstracts.txt.
>>
>> The list of Internet-Draft Shadow Directories can be accessed
>> at http://www.ietf.org/shadow.html.
>>
>> This Internet-Draft will expire on May 14, 2010.
>>
>> Copyright Notice
>> Copyright (c) 2009 IETF Trust and the persons identified as
>> the document authors.  All rights reserved.
>>
>> This document is subject to BCP 78 and the IETF Trust's Legal
>> Provisions Relating to IETF Documents
>> (http://trustee.ietf.org/license-info) in effect on the date
>> of publication of this document.  Please review these
>> documents carefully, as they describe your rights and
>> restrictions with respect to this document.  Code Components
>> extracted from this document must include Simplified BSD
>> License text as described in Section 4.e of the Trust Legal
>> Provisions and are provided without warranty as described in
>> the BSD License.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-dat
>> a-model-14.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail
>> reader implementation to automatically retrieve the ASCII
>> version of the Internet-Draft.
>>
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www.ietf.org/mailman/listinfo/xcon


From rbarnes@bbn.com  Thu Nov 12 18:03:11 2009
Return-Path: <rbarnes@bbn.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC8B3A6945 for <xcon@core3.amsl.com>; Thu, 12 Nov 2009 18:03:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2uC0qef27Kc for <xcon@core3.amsl.com>; Thu, 12 Nov 2009 18:03:10 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 82DFC3A683D for <xcon@ietf.org>; Thu, 12 Nov 2009 18:03:10 -0800 (PST)
Received: from [128.89.252.65] (helo=host-16-79.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from <rbarnes@bbn.com>) id 1N8lVi-0002PJ-CP for xcon@ietf.org; Thu, 12 Nov 2009 21:03:39 -0500
Message-Id: <538299F7-B920-4471-AE66-21F45E1F7372@bbn.com>
From: Richard Barnes <rbarnes@bbn.com>
To: xcon <xcon@ietf.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 13 Nov 2009 11:03:36 +0900
X-Mailer: Apple Mail (2.936)
Subject: [XCON] XCON minutes from IETF 76
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2009 02:03:11 -0000

Minutes - XCON - IETF76

Summary (prepared by Richard Barnes):

1. Chairs' Introduction
The chairs reviewed the status of the WG's documents.  draft-ietf-xcon- 
common-data-model is in a holding pattern, waiting on CCMP.   There  
were no objections to removing IM- and policy-related milestones from  
the charter.

2. CCMP
  draft-ietf-xcon-ccmp
Simon Romano presented an update on this document.  The latest version  
includes several revisions in response to a review from Richard  
Barnes, all of which were supported by the WG.  Mr. Romano plans to  
take one more round of comments and have a final draft ready in early  
2010.

3. BFCP over UDP
  draft-sandbakken-xcon-bfcp-udp
Alan Johnston presented an update on this document on behalf of Tom  
Kristensen.  Several commenters pointed out that the current draft  
still has many problems that had been called out at previous meetings,  
The draft will not be taken up by the WG at this time.




Raw notes from Martin Thomson follow:
------------------------------------------------------------
Agenda Bash

Agenda was OK

Work Item Status

No discussion

Simon Romano on Conference Control Manipulation Protocol -04 posted  
recently

small but important modifications to the document

better clarity required and some technical issues

document structure was a source of confusion

issue over the scope of application ofthe conference password, does  
the password relate to the entire conference, or each conference URI?   
WG input sought; Mary Barnes noting that the URI encompasses the  
entire (not enough context to make sense of the conclusion -  
conclusion was to make no change)

XSD or RNG?  rbarnes wanted all xcon documents to use the same schema  
mechanism; roni even giving history, following the same path for the  
other document, adding RNG later

updates to confObjs.  Added versioning in the latest update.  if  
modifications are accepted, the server updates the entire object and  
it updates/increments the version.  all server responses will contain  
the version number.  is this OK?  mary barnes notes that this solves  
the problem of working out what version the server is operating on;  
alan johnston agrees this is workable and lightweight

request filtering?  mary notes that this is functionality that was  
desired from the framework, if it is not too hard, add it.

progress: mary thinks it's close to ready; adam roach agrees that it  
would be good to set an aggressive goal, and not even meet at IETF77;  
mary says that a meeting might be needed; simon: call flows are there,  
but they need work to be updated

gonzalo camarillo is waiting on the data model to be completed, what  
is the plan?  alan johnston: the data model is past WGLC;  gonzalo:  
pub-req along with CCMP? answer: yes; alan: maybe we can move  
everything together; general agreement to do that


==Revision of the Binary Floor Control Protocol for unreliable  
transport (Alan Johnston)

Current protocol relies on a TLS/TCP connection, but TCP does not  
always work.

Roni BFCP used where there are two video streams, for instance video  
and presentation.  TCP is problematic, more like problems with SBCs;  
some fallbacks to UDP, some to HTTP; need to create a profile that  
uses UDP as a fallback mode to deal with deployment problems

Roni: this is sometimes used for multipoint

Draft looks at limitations and flow maintenance issues.  Need to look  
at DTLS (for encryption), framing, fragmentation, and versioning.

No action requested by the authors on this document.

RJS feedback: the characterization that this is for NAT/firewall  
traversal needs to be changed to SBC traversal more specifically and  
explicitly; what about congestion safety over UDP?  Please have a look  
at congestion safety here so that we can make sure that this can  
proceed.

Gonzalo: has worked on this in the past, maybe to integrate with  
BFCP.  Problems were raised, but the authors did not respond.  We need  
to enumerate issues and address them.

Roni: this is now more important now that work is being done on this

John Elwell: This is now active again.

Adam Roach: repeating old concerns: this does not address  
interoperability with TCP-based implementations that are already out  
there; this does not work in SIP; needs a mechanism for negotiation or  
fallback; does not want un-interoperable

Gonzalo: the protocol can be fairly lax; needs more than just  
retransmission to ensure reliability

Roni: there are capability negotiations in SDP that could be used to  
address this

Simon: authors on chat have noted that there are some effort to  
address some of the concerns: fragmentation

Gonzalo: is OK to resurrect this, but doesn't like the tactics

Chairs: need to show interest, address issues and do so quickly  
because the WG is winding down


==Other issues

Alan: is there interest in dealing with the policy and IM-related work

Gonzalo: policy was removed from the protocol because it was hard; be  
serious about this if you take this on, don't expect the WG to die

Mary: maybe wrap this up, then see if people want to deal with this,  
then re-charter a new WG or go through DISPATCH for the work if there  
is the will to do so; don't continue in here

Simon: agrees and wants to close down

RBarnes: any objection to removing the milestones from the charter.

From duddy@avaya.com  Wed Nov 18 09:49:48 2009
Return-Path: <duddy@avaya.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F8A3A67DD for <xcon@core3.amsl.com>; Wed, 18 Nov 2009 09:49:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j+0sPxAQHrq for <xcon@core3.amsl.com>; Wed, 18 Nov 2009 09:49:47 -0800 (PST)
Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id A4F6C3A67CC for <xcon@ietf.org>; Wed, 18 Nov 2009 09:49:47 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.44,766,1249272000"; d="scan'208";a="180751397"
Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 18 Nov 2009 12:49:45 -0500
Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.151]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 18 Nov 2009 12:49:45 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Nov 2009 17:49:23 -0000
Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F7101016451@306900ANEX2.global.avaya.com>
In-Reply-To: <20091112020002.1703D3A68FC@core3.amsl.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt
Thread-Index: AcpjPBIid7J6TReeSky/cPwp2EEk9QFOoHMQ
References: <20091112020002.1703D3A68FC@core3.amsl.com>
From: "Duddy, Sean (Sean)" <duddy@avaya.com>
To: <xcon@ietf.org>
Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2009 17:49:49 -0000

Some comments on the latest ccmp draft:-

General:=20
	The new <xcon:conference-password> element needs to be expanded
to indicate its type.
	E.g. a conference could have a moderator and conferee password
and the ccmp client would
	need to know which is which.


6.1 CCMP Request Message Type
	confUserID/password
	The purpose of these elements is not clear. The draft states
that the password should contain
	the value of the xcon:conference-password element.=20
=09
	Section 6.3.6 states that the XCON-USERID could be an
administrator or some other non conference participating user
	of the ccmp server. In this case, the password field in the
request would be that of the administrator and would have nothing to
	do with the conferences he/she is about to provision.
=09
	So to summarise: The request password field may be a conference
password  but it also may be some other piece of info to authenticate
	the client issuing the command.

6.3.2.  confsRequest and confsResponse
	A filter mechanism needs to be specified here to allow clients
only retreieve a subset of conferences based on search crieteria.
	e.g. A ccmp client might only be interested in conferences
pertaining to a certain user or active conferences between a date range
etc.
=09
6.3.2   Related to the 6.1 issues, if an administrator wants to retrieve
a user belonging to a conference, where in the userRequest message
        is the user XCON ID specified? It looks like it is specified in
confUserID which would be wrong in this case....
=09
6.3.4.  confRequest and confResponse
	This is a general question. If one develops a CCMP based
provisioning client to simply provision conferences on the server,
	they are not interested in the conference runtime parameters of
conferences like the <user> entities. Not a big deal for the client,=20
	they can simply ignore this info, but it is a significent
performance hit for the CCMP server to provide up to date conference
runtime=20
	info to clients... I think we need some mechanism to avoid this
overhead for clients that do not need this info.

10 HTTP Transport
	Link 'Section 7.2.1.' does not exist

Sean
=20

-----Original Message-----
From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: 12 November 2009 02:00
To: i-d-announce@ietf.org
Cc: xcon@ietf.org
Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Centralized Conferencing Working Group
of the IETF.


	Title           : Centralized Conferencing Manipulation Protocol
	Author(s)       : M. Barnes, et al.
	Filename        : draft-ietf-xcon-ccmp-04.txt
	Pages           : 98
	Date            : 2009-11-11

The Centralized Conferencing Manipulation Protocol (CCMP) can create,
retrieve, change and delete objects describing a centralized conference,
such as state and capabilities of the conference, participants, and
their roles.  The conference information is contained in XML documents
and fragments conforming to the centralized conferencing data model
schema.  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.  Conferencing
clients send requests to conference servers, which respond to the client
with the conference information.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 16, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document
authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document.  Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in the
BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

From yguo2@cisco.com  Wed Nov 25 22:59:45 2009
Return-Path: <yguo2@cisco.com>
X-Original-To: xcon@core3.amsl.com
Delivered-To: xcon@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2773A69DF for <xcon@core3.amsl.com>; Wed, 25 Nov 2009 22:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level: 
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj9aUmBT72su for <xcon@core3.amsl.com>; Wed, 25 Nov 2009 22:59:42 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9FD473A677E for <xcon@ietf.org>; Wed, 25 Nov 2009 22:59:42 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArgFALe2DUurR7H+/2dsb2JhbACCIC+YJaEZl1iEMgQ
X-IronPort-AV: E=Sophos;i="4.47,291,1257120000";  d="scan'208,217";a="275198010"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 26 Nov 2009 06:59:37 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAQ6xb6Q016461 for <xcon@ietf.org>; Thu, 26 Nov 2009 06:59:37 GMT
Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 25 Nov 2009 22:59:37 -0800
Received: from 10.21.79.189 ([10.21.79.189]) by xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) with Microsoft Exchange Server HTTP-DAV ;  Thu, 26 Nov 2009 06:59:36 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Wed, 25 Nov 2009 22:59:36 -0800
From: yguo2 <yguo2@cisco.com>
To: <xcon@ietf.org>
Message-ID: <C7336758.5F9D%yguo2@cisco.com>
Thread-Topic: Comments about draft-ietf-xcon-ccmp-04.txt
Thread-Index: AcpuZgOfHacL8wTsTUC9M4+Mun9Hww==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3342034776_13952044"
X-OriginalArrivalTime: 26 Nov 2009 06:59:37.0845 (UTC) FILETIME=[04B94250:01CA6E66]
Subject: [XCON] Comments about draft-ietf-xcon-ccmp-04.txt
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xcon>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2009 07:01:23 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3342034776_13952044
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I have a few comments/questions about the latest CCMP draft

1 In section 7: A complete example of the CCMP in action
    Can we have a new example for scenario:
        Alice tries to mute another user Bob.

2 If the conference system consists of general purpose conference room whic=
h
is bound to any user, then how does CCMP work in this situation?
Specifically, how would CCMP model the scenario: =B3room San Jose wants to
invite room New York to a conference=B2?

Thanks
Yu

--B_3342034776_13952044
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Comments about draft-ietf-xcon-ccmp-04.txt</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I have a few comments/questions about the latest CCMP draft<BR>
<BR>
1 In section 7: A complete example of the CCMP in action <BR>
&nbsp;&nbsp;&nbsp;&nbsp;Can we have a new example for scenario:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Alice tries to mute another=
 user Bob.<BR>
<BR>
2 If the conference system consists of general purpose conference room whic=
h is bound to any user, then how does CCMP work in this situation? Specifica=
lly, how would CCMP model the scenario<SPAN STYLE=3D'font-size:14px'>: &#8220;=
<SPAN STYLE=3D'font-size:11pt'>room San Jose wants to invite room New York to =
a conference&#8221;?<BR>
</SPAN></SPAN></SPAN></FONT><SPAN STYLE=3D'font-size:11pt'><SPAN STYLE=3D'font-=
size:14px'><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Courier, Courier New"><B=
R>
Thanks<BR>
Yu</FONT></SPAN>
</BODY>
</HTML>


--B_3342034776_13952044--