Subject: RE: URGENT REMINDER: [XCON] Conference Control: Path Forward

From: "Mary Barnes" <[email-masked]>
Date: Fri, 13 Jan 2006 18:38:47 -0600

Sean,

Thanks for re-starting this discussion.

There's actually a 2nd SOAP proposal that I submitted right near the
deadline that appeared on Jan 3rd:
http://www.ietf.org/internet-drafts/draft-barnes-xcon-ccmp-00.txt

This proposal is very preliminary as there's several TBD sections, but I
think it could be easily merged with Henning's COMP proposal as the
approaches are quite similar.

I think what we should be doing now is debating the advantages and
disadvantages of each of the proposals.  I had a chart in the package I
presented at IETF-64 during the framework discussion (chart 10):
http://www.softarmor.com/xcon/meets/ietf64/agenda.pl
This evaluation looked at some of the protocol motherhood statements and
I tried to work through a more detailed set of requirements, but kept
coming back to fundamentals such as:
1. Same protocol for data manipulation and conference operations.
2. Based on a protocol that's already implemented (or needing to be
implemented for other functionality) by clients. 
3. Affinity with the data model to reduce the complexity.  

I do think one of the difficulties is that we need to agree fundamental
requirements or priority of some of the motherhood requirements to see
which protocol is most suitable.

In considering the 3 protocols on the table (considering Henning's COMP
and CCMP as the same), I would still come up with a similar analysis as
that chart 10, which I'll summarize below (and apolgize in advance if
the formatting is funky):

                CCCP       CSCP     CCMP/COMP
                --------------------------------------------------------
Based on XML    Yes         No       No (but WSDL can be derived from
XML)

Existing        No        Yes(BFCP)  Yes
protocol

Event           Yes        Yes (?)    No (plan to use SIP)
Notification
Mechanism 

Compact         No         Yes        No

Efficient       Yes        Yes        Yes

Easy to         Yes        Yes        Yes
Implement 

And, I'm afraid this doesn't help much.  I think any of the approaches
could work. Of course, CCCP has been proven to work in one
implementation, but SOAP has been successfully implemented in many
implementations, albeit not for this application.  And, I think the
compact nature of CSCP might be appealing to the wireless folks. 

Obviously, my preference is for the COMP/CCMP approach.

Mary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sean Olson
Sent: Friday, January 13, 2006 5:52 PM
To: Adam Roach; Adam Roach
Cc: XCON-IETF
Subject: RE: URGENT REMINDER: [XCON] Conference Control: Path Forward

I haven't seen any discussion so far about the protocol submissions:

- Henning's SOAP proposal
(http://www.cs.columbia.edu/sip/draft/comp/draft-schulzrinne-xcon-comp-0
0.html) 

- Cullen/Oscar's CSCP proposal
(http://users.piuha.net/gonzalo/temp/draft-jennings-xcon-cscp-02.txt)

- Our CCCP proposal
(http://tools.ietf.org/wg/xcon/draft-levin-xcon-cccp-04.txt)

What are the next steps for evaluating these submissions?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Adam Roach
Sent: Monday, November 28, 2005 2:22 PM
To: Adam Roach
Cc: XCON-IETF
Subject: URGENT REMINDER: [XCON] Conference Control: Path Forward

[as chair]

If anyone in the working group cares about the protocol we end up
selecting for conference control -- or, indeed, finishing our work at
all -- they are strongly advised to participate in this conversation. If
we can't get any participation around our deliverables, we really have
no choice but to shut the working group down.

/a

Adam Roach wrote:

> [as chair]
>
> In Vancouver, the XCON chairs outlined a process by which we would 
> attempt to meet our proposed milestones. This message summarizes that 
> process, as amended by the input we received from the XCON
participants.
>
>   1. Proposals for candidates for the Conference Control Protocol
(CCP)
>      must be submitted in internet-draft format no later than December
>      31st, 2005. The draft does not need to be complete; however,
there
>      must be sufficient detail to make clear how the proposed protocol
>      would be used to modify information in both the Common Conference
>      Information and Conference Template. (See
>      draft-ietf-xcon-framework for definitions).
>
>   2. All protocols to be considered additionally need a brief message
>      from an author and/or proponent of the corresponding draft that
>      explains the design decisions taken in the design of the
protocol,
>      as well as a summary of strengths and drawbacks of the approach.
>      Such proponents should contact the XCON chairs to coordinate.
>          * Such proponents should discuss implementation lessons, if
>            available, around using their proposed protocol to modify
>            the Common Conference Information.
>          * Separately, such proponents should additionally discuss
>            implementation lessons, if available, around using their
>            proposed protocol to modify the Conference Template.
>
>   3. Starting in early January, the chairs will call for discussion on
>      the mailing list to gauge the overall direction the working group
>      wishes to proceed.
>
>   4. Between now and January, interested parties should discuss their
>      requirements around the CCP on the mailing list. These
discussions
>      should assist in coming to consensus on the CCP that XCON will
use.
>
> Hopefully, the result of the January discussions will resolve to a 
> single approach (either by selection of one of the proposals or by 
> combining one or more of them into a unified proposal).
>
> /a
>
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
>

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Jan 2006 14:44:00 -0500

> approaches are quite similar.

That's certainly my intent and hope.

> implemented for other functionality) by clients. 

Or, possibly, protocol*s*, since some proposals use more than one (SIP 
for event notification, for example).

> the formatting is funky):

I would consider CCMP/COMP as based on XML, in that the on-the-wire 
format is XML.

> Event           Yes        Yes (?)    No (plan to use SIP)

In general, if XML is used over TLS, TLS will do gzip-style compression, 
probably reducing the packet size footprint considerably.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 17 Jan 2006 19:24:59 +0200

Hi Henning,

> probably reducing the packet size footprint considerably.

out of curiosity, I thought TLS compression was not widely implemented. 
Do you know whether or not that is actually the case?

Thanks,

Gonzalo

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Jan 2006 12:49:03 -0500

I'm not a TLS expert, but I did find that GNU TLS seems to implement 
something related:

http://www.gnu.org/software/gnutls/manual/html_node/Compression-algorithms-used-in-the-record-layer.html

http://www.openssl.org/docs/ssl/SSL_COMP_add_compression_method.html has 
some related information and indicates that this maybe a transient 
problem. http://www.openssl.org/news/news.html mentionds

Changed the ZLIB compression method to be stateful.

which does indicate compression support. Somebody with first-hand 
knowledge probably should pipe up here.

Gonzalo Camarillo wrote:
> Hi Henning,
> 
>> In general, if XML is used over TLS, TLS will do gzip-style 
>> compression, probably reducing the packet size footprint considerably.
>

---

From: "Sean Olson" <[email-masked]>
Date: Mon, 23 Jan 2006 17:53:23 -0800

The implementation of TLS in the Windows OS (Schannel) does not support
compression. Application-level compression may be more appropriate
anyways for XML-based protocols. DEFLATE should do a good enough job,
but I'd be curious to hear other opinions.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Tuesday, January 17, 2006 9:49 AM
To: Gonzalo Camarillo
Cc: Adam Roach; Adam Roach; XCON-IETF
Subject: Re: URGENT REMINDER: [XCON] Conference Control: Path Forward

http://www.gnu.org/software/gnutls/manual/html_node/Compression-algorith
ms-used-in-the-record-layer.html