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

From: [email-masked]
Date: Wed, 11 Nov 2009 18:00:02 -0800 (PST)

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: "Duddy, Sean (Sean)" <[email-masked]>
Date: Wed, 18 Nov 2009 17:49:23 -0000

Some comments on the latest ccmp draft:-

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.

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

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

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

Sean

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

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

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

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.