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

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Tue, 26 Jan 2010 12:21:57 -0000

Hi Simon,
	I am still confused about the purpose of the confUserId/password fields. I would have thought that all CCMP requests would require these
fields for authentication purposes? I think CCMP has too many purposes for these fields and we need to refine the ccmp xml data model.
Even a simple example, say I want to retrieve all my conferences, what password do I supply? And then if I want to modify an individual conference 
I must supply the conference passcode. Which implies any particpant of the conference could work out the 'AA' details to modify the conference..

I propose the following change:-

<xs:complexType abstract="true"
        name="ccmp-request-message-type">
      <xs:sequence>
        <xs:element name="subject" type="subject-type" <!-- Subjest is a JAAS term it could be renamed to something else...-->
                    minOccurs="1" maxOccurs="1" />
        <xs:element name="confUserID" type="xs:string"
                    minOccurs="0" maxOccurs="1" />
        <xs:element name="confObjID" type="xs:string"
                    minOccurs="0" maxOccurs="1" />
        <xs:element name="operation" type="operationType"
                    minOccurs="0" maxOccurs="1" />
        <xs:element name="conference-password" type="xs:string" <!- rename password to conference-password-->
                    minOccurs="0" maxOccurs="1" />

      </xs:sequence>
    </xs:complexType>

<xs:complexType name="subject-type">
      <xs:sequence>
        <xs:element name="username" type="xs:string"
                    minOccurs="0" maxOccurs="1" />
        <xs:element name="password" type="xs:string"
                    minOccurs="0" maxOccurs="1" />
        <xs:any namespace="##other" processContents="lax"
	         minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>

The subject details are independent of the conference details.

Sean

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 21 December 2009 17:41
To: Duddy, Sean (Sean)
Cc: [email-masked]
Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt

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~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: [email-masked]
Date: Wed, 27 Jan 2010 19:55:02 +0100

Sean,

>         <xs:element name="subject" type="subject-type" <!-- Subjest   
> is a JAAS term it could be renamed to something else...-->
>         <xs:element name="conference-password" type="xs:string" <!-   
> rename password to conference-password-->

[spromano] I like this suggestion. This would completely decouple AAA  
issues from conference-related issues. Shall we proceed? Personally, I  
also like the JAAS-style "subject" term.

Simon