[XCON] FW: I-D Action:draft-ietf-xcon-ccmp-02.txt

["Mary Barnes" <mary.barnes at nortel.com>]

Hi all,

We have updated the CCMP protocol document based on feedback at IETF-73.
We have switched from the RESTful approach (in the -01) to an HTTP
transport approach.  This was a major rewrite, thus a diff is likely not
very helpful in reviewing the updated document. Indeed, this version is
likely closer to the -00 than the -01.  

The document is not complete, BUT the protocol described therein has
been implemented by Simon, Lorenzo, et al at the University of Napoli.
And, the details for the example message flows have been pulled from the
prototype. 

The work to complete the document includes the following:
1) Describe how to handle all the various error codes for each message
(for the most part, the text only covers the success and modified
cases). 
2) Revisit the normative language -  some SHOULDs might need to be MUSTs
(and perhaps vice versa). 
3) Add a section describing HTTP requirements to support CCMP - i.e.,
such things as caching, cookies, auth mechanisms, required header fields
(e.g., Content-Type, Accept, etc.).  
4) Update and expand upon the security section (based on past
experience, that's not a small task BUT the threat analysis is fairly
complete in the XCON FW and the requirements on the protocol are fairly
well spelled out).  

We'd like explicit feedback from the WG on a couple of things and of
course any other comments are welcome:
1) Do we need to define/describe a locking mechanism for the data? Right
now, there's nothing in the protocl that prevents user A from modifying
the same conference object as user B.  We could specify this is an
implementation issue, but it seems this really is a core protocol
requirement.  Could we use floor control? Or, do we need something like
WebDAV? 

2) How do folks feel about having the schema snippets in the body of the
document for each message? The benefit is that it does help you see the
protocol structure, without having to search through the schema section.
The con of course is that we need to fix two sections when there are
changes.

3) Notification mechanism: do we need to define one or reuse existing?
Right now, the default is specified as SIP. Is that sufficient for the
initial version of the protocol?  


Regards,
Mary, Simon, Chris, Henning.

-----Original Message-----
From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On Behalf Of
Internet-Drafts at ietf.org
Sent: Monday, March 09, 2009 6:15 PM
To: i-d-announce at ietf.org
Cc: xcon at ietf.org
Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-02.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-02.txt
	Pages           : 83
	Date            : 2009-03-09

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.  CCMP is a state-less client-server protocol based on a
request/response model.
Conferencing clients send requests to conference servers, which respond
to the client with the conference information.

This document also discusses options for using existing notification
protocols to inform conference client about the changes in the state of
a conference during its entire lifetime.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-02.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.