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

["Duddy, Sean (Sean)" <duddy at avaya.com>]

Hi Mary,
	See some comments below.

4.  Protocol Overview

	Regarding locking, I think it is an implementation issue and
common sense 
	should apply to the implementation. Typically, each CCMP
operation would be 
	wrapped in a transaction on the CCMP server, this would
guarantee data integrity. 
	Depending on the type of transaction mechanism, other requests
wanting to modify 
	the same piece of data could overwrite it, once the other
clients tx is committed or
	a 'StaleDataException' could be thrown.
	
	An OPTIONS request is mentioned here but this is no longer part
of CCMP.

6.1.  Conference Object
	How in the schema can a conference/blueprints attributes be
marked as unalterable? 
	Can this feature be expanded on in the draft?
	
7.1.  Implementation Approach
	
	It states that using the single HTTP verb to transport all CCMP
messages provides the 
	capability to use CCMP with any chosen transport protocol. Is
this a valid goal since this draft is
	only going to specify one transport mechanism? e.g. If I decide
to wrap the messages in SOAP,
	then obviously my interface is non-standard. 
	
	Personally I prefer SOAP, as it is geared towards a
client/server
	implementation, has standards for security, encryption etc that
could be used and there are a wide variety 
	of SOAP framework vendors out there...
	
	Another thing about using generic messages for everything, is
that depending on the message
	type some parameters are mandatory and some are not. This leads
to more complex code when generating the messages...
	
7.2.3.2.  confsRequest and confsResponse messages
	This request needs to be extended to allow search criteria to be
passed to reduce the 
	number of conferences passes to client. All implememtations
would require this so
	it might as well be part of the standard.
	
11.  Managing notifications
	I dont think the SIP notifications mechanism is viable as it
implies clients need both a HTTP
	stack and SIP stack at their disposal... Also, if a client is
soley a booking client, 
	SIP should not come into the picture...
	
	I think the notification format and transport mechanism needs to
be defined similiarly to CCMP. 
	The SIP notification spec, to the best of my knowledge deals
with call control,
	it has nothing for provisioning... What we really need is a
notification specification that defines 
	the notifications for the complete conference model(including
call control), a subscription mechanism 
	and details of transport mechanisms - SIP and some other
protocol suitable for CCMP clients...

Sean

-----Original Message-----
From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On Behalf Of
Mary Barnes
Sent: 11 March 2009 20:00
To: xcon at ietf.org
Cc: Henning Schulzrinne
Subject: [XCON] FW: I-D Action:draft-ietf-xcon-ccmp-02.txt

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.
_______________________________________________
XCON mailing list
XCON at ietf.org
https://www.ietf.org/mailman/listinfo/xcon