Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt

From: [email-masked]
Date: Mon, 21 Dec 2009 18:41:13 +0100

Hi Sean,

thank you for your comments. Please find my answers in-line (with a  
prefix of [spromano]). BTW, we are going to submit a fresh version of  
the CCMP draft in the next few days.

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

[spromano] I take this as a suggestion to modify the data model,  
rather than the CCMP, since in the draft we are just referring to [I  
D.ietf xcon common data model].

This said, I personally think that you are touching again the  
important issue of defining a role-based access control policy system  
associated with the management of conferences, users and their  
respective roles. I keep on thinking that such system is somehow  
"orthogonal" to the framework itself.
Let me once again self-reference an old post about this topic:

http://www.ietf.org/mail-archive/web/xcon/current/msg01919.html

When we are eventually done with the last issues related to CCMP, I  
will be glad to work on the above proposal, if there is some interest  
in carrying it out.

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

[spromano] ?confUserId? is used to know who is asking to perform a  
certain operation (e.g. for AAA purposes). When such information is  
missing in a "userRequest/create" operation, this means that the  
request itself is a join operation PLUS creation of an xcon-userid  
(and related association tree on the server's side: sip-uri, xcon-uri,  
role, etc.) associated with the sender.

This should become clearer in the general sample call flows contained  
in the draft, as well as in the detailed flows presented in the  
companion XCON call flows draft.

As to the password, see the answer to your previous comment.

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

[spromano] The "password" field is optional. Again, we look at it as  
being strictly related to the conference, as per the  
<conference-password> element of the data model. We have not taken  
into account the case of a non-participating administrator who is  
willing to use such field to enter the conferencing system and carry  
out CCMP-based operations. Stated in different terms, we did not face  
the issue of authenticating the system administrator via a field other  
than his own xcon-userid.

I would ask other people in the WG to express their opinion on this topic.

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

[spromano] Right! We already proposed to add filters to both  
confsRequest and blueprintsRequest messages. Our idea would be the  
following (you'll find it in the upcoming versions of the draft), with  
reference, e.g. to the former message:

<!-- confsRequest -->

         <xs:complexType name="ccmp-confs-request-message-type">
         	<xs:complexContent>
         		<xs:extension base="tns:ccmp-request-message-type">
         			<xs:sequence>
         				<xs:element ref="confsRequest" />
         			</xs:sequence>
         		</xs:extension>
         	</xs:complexContent>
         </xs:complexType>

<!-- confsRequestType -->

         <xs:element name="confsRequest" type="confsRequestType" />

           <xs:complexType name="confsRequestType">
           <xs:sequence>
              <xs:element name="xpathFilter" type="xs:string" minOccurs="0"/>
           </xs:sequence>
         </xs:complexType>

As you can see, we propose to add an optional "xpathFilter" element  
(of a generic "xs:string" type) to the message, in order to allow the  
server to appropriately filter out unwanted information before sending  
back to the client the list of conferences.

Example --> retrieve just registered conferences:
xpathFilter="/info:conference-info[info:conference-state/info:active='false']";

What is your feeling about such proposal? Do you think it does the  
job? Or should we go for a finer-grained definition of the new element  
(which might be bound, for example, to sharply represent an xpath  
query rather than a generic string)?

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

[spromano] The xcon-userid of the target user is contained inside the  
"entity" attribute of the userRequest/retrieve message.

Example: Alice is administrator and wants to retrieve Bob's info, with  
Bob being a participant in conference 8977777. Alice sends the  
following message via the CCMP:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info"  
xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"  
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
xsi:type="ccmp:ccmp-user-request-message-type">
         <confUserID>xcon-userid:[email-masked]</confUserID>
         <confObjID>xcon:[email-masked]</confObjID>
         <operation>retrieve</operation>
         <ccmp:userRequest>
                 <userInfo entity="xcon-userid:[email-masked]"/>
         </ccmp:userRequest>
     </ccmpRequest>
</ccmp:ccmpRequest>

Inside the response, ?confUserId? contains  
?xcon-userid:[email-masked]?, whereas the ?userInfo? parameter  
carries back Bob's information.

>
> 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,
> 	they can simply ignore this info, but it is a significent
> performance hit for the CCMP server to provide up to date conference
> runtime
> 	info to clients... I think we need some mechanism to avoid this
> overhead for clients that do not need this info.

[spromano] If one wants to retrieve general information about  
available conferences, he can issue a confsRequest message, whose  
response will contain high-level information (in particular, all that  
can be inserted in a "uri-type" element -- display-text, uri, purpose,  
etc. --). A drill-down query can be issued by sending a confRequest  
message associated with a specific conference object. In principle,  
the entire conference document is sent back to the client, even though  
the choice of what kind of information to provide (e.g. users list,  
passwords, etc.) is completely implementation-dependent. The only  
requirement is for the server to send back an xml element compliant  
with the "conference-type" element of the data model. Once again, a  
policy-based approach might be put into place to properly  
identify/discriminate "who is trying to do what" and (re)act  
accordingly.

Finally, if a user wants to retrieve fragments of a conference object  
(e.g. info about a certain user, all users, sidebars, etc), she can  
exploit the ad-hoc conceived messages made available by the protocol.  
As you will have noticed, when deciding what messages to define for  
the CCMP, we tried to strike the balance between granularity of the  
protocol and its complexity.

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

[spromano] Right. Thank you for pointing this out.

Cheers,

Simon
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 12 November 2009 02:00
> To: [email-masked]
> Cc: [email-masked]
> 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.
> _______________________________________________
> XCON mailing list
> [email-masked]
> 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: [email-masked]

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