Re: [XCON] New version of CSCP draft

Alan Johnston <ajohnston@tello.com> Tue, 20 December 2005 16:53 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eokk4-0006PD-QY; Tue, 20 Dec 2005 11:53:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eokk3-0006Nt-Eq for xcon@megatron.ietf.org; Tue, 20 Dec 2005 11:53:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28984 for <xcon@ietf.org>; Tue, 20 Dec 2005 11:52:32 -0500 (EST)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EokmV-0004am-R9 for xcon@ietf.org; Tue, 20 Dec 2005 11:56:08 -0500
Received: from dsl027-191-178.sfo1.dsl.speakeasy.net ([216.27.191.178] helo=[10.75.74.128]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1Eokjq-0002Gj-JT; Tue, 20 Dec 2005 11:53:22 -0500
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 216.27.191.178
X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: digitalari
Message-ID: <43A836F5.9030707@tello.com>
Date: Tue, 20 Dec 2005 08:53:09 -0800
From: Alan Johnston <ajohnston@tello.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Oscar Novo (JO/LMF)" <oscar.novo@ericsson.com>
Subject: Re: [XCON] New version of CSCP draft
References: <A91F30A632473A47B40C18D2B107CA6F01B5276F@esealmw105.eemea.ericsson.se>
In-Reply-To: <A91F30A632473A47B40C18D2B107CA6F01B5276F@esealmw105.eemea.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Adam Roach <adam@nostrum.com>, XCON-IETF <xcon@ietf.org>, "Gonzalo Camarillo (JO/LMF)" <gonzalo.camarillo@ericsson.com>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>, <mailto:xcon-request@ietf.org?subject=subscribe>
Sender: xcon-bounces@ietf.org
Errors-To: xcon-bounces@ietf.org

(not as chair)

There are two areas that I would find useful to be discussed, either in 
the draft or on the list that may help me and others in evaluating this 
proposal.

First, while I undestand how the protocol can be used to change a single 
value (mute a line, change a display name, etc.)  to me it is not at all 
clear how a conference could be created, or a new user added as a dial 
out participant.  Could you show the sequence of messages needed to 
obtain this.

Secondly, this approach seems to essentially be a data manipulation 
approach.  As such, the question of why XCAP is not used is important, 
as XCAP is nearly finished and will likely be already implemented as a 
protocol on many of the conference participant devices.  Also, are the 
document locking capabilities of XCAP needed?  If not, some advice for 
implementors on how to resolve conflicts in large conferences.

Thanks,
Alan Johnston
sip:ajohnston@tello.com

Oscar Novo (JO/LMF) wrote:

>Hello,
>
>We would like to notify the new version of the CSCP draft. Until it
>appears in the archives, you can fetch it from:
>
>http://users.piuha.net/gonzalo/temp/draft-jennings-xcon-cscp-02.txt
>
>CSCP is an extension of the BFCP. In this version we have aligned the
>CSCP draft with the "Binary Floor Control Protocol (BFCP)" draft and the
>"Connection Establishment in the Binary Floor Control Protocol (BFCP)"
>draft.
>
>Here's an overall summary of the changes:
>
>- We have aligned the CSCP draft with the "Binary Floor Control Protocol
>(BFCP)" draft and the "Connection Establishment in the Binary Floor
>Control Protocol (BFCP)" draft 
>- Definition and explanation of the main errors of the CSCP protocol.
>- Added a new section 6 (Server Behaviour)
>- In Section 7 (example) added a new example and additional text
>explaining the example
>- Updated sections 9 (IANA Considerations) and section 10 (Security
>Considerations)
>
>CSCP is not done yet. There are changes that have to be incorporated in
>the following versions:
>
>- Definition of new operations (creation of a conference, termination of
>a conference, etc...)
>- Definition of new error values of the protocol
>- Better explanation of some operations (Adding Elements, etc...)
>- Discussion about the need of the synchronous "query" mechanism in the
>protocol
>
>But we believe it's enough to understand the propose of this protocol
>and to discuss in the mailing list if this protocol is a good option.
>
>The strengths of CSCP are:
>
>- CSCP is based on BFCP, reducing the number of protocols required to be
>supported by clients
>- It can modify the "variable" part data and the "common" part data
>using the same operations.
>- Easy to implement
>- Compact and Efficient
>
>Regards,
>
>Oscar
>
>
>_______________________________________________
>XCON mailing list
>XCON@ietf.org
>https://www1.ietf.org/mailman/listinfo/xcon
>
>
>  
>


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon