Subject: [XCON] Protocol Action: 'Conference Event Package Data Format Extension for Centralized Conferencing (XCON)' to Proposed Standard
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, xcon mailing list <[email-masked]>, xcon chair <[email-masked]>, RFC Editor <[email-masked]>
Date: Mon, 2 Mar 2009 09:47:42 -0800 (PST)
List-Id: Centralized Conferencing <xcon.ietf.org>

The IESG has approved the following document:

- 'Conference Event Package Data Format Extension for Centralized 
   Conferencing (XCON) '
   <draft-ietf-xcon-event-package-01.txt> as a Proposed Standard

This document is the product of the Centralized Conferencing Working 
Group. 

The IESG contact persons are Cullen Jennings and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-event-package-01.txt

Technical Summary

  This document specifies a Session Initiation Protocol (SIP)
  Event Package to provide state to partipants in a Centralized
  Conferencing (XCON)-defined conference, including the specification
  of a mechanism for partial notifications.

Working Group Summary

  This document is a product of the XCON working group.
  Its contents have been uncontroversial in working group
  discussions.

Document Quality

  Adam Roach has reviewed the document for quality.

Personnel

  Adam Roach is the Document Shepherd for this document.
  Cullen Jennings is the responsible Area Director.

RFC Editor Notes

Please create a "Non-Normative References" section:
  - Move draft-ietf-xcon-framework to it 
  - Move RFC 3688 to the non-normative references section.

Section 6.3:
  - Please replace "consent-status" in the section heading
    with "xcon-conference-info-diff".

Please consider changing
 Section 3:
  s/instance has experimented/instance has experienced/
 Section 5.2:
  s/received in notification/received in the notification/
  s/If subscriber/If the subscriber/

From [email-masked]  Thu Mar  5 09:34:02 2009
Date: Thu, 05 Mar 2009 09:33:44 -0800
To: "Roni Even" <[email-masked]>
From: Keith Lantz <[email-masked]>
Cc: 'Alan Johnston' <[email-masked]>, [email-masked]
Subject: Re: [XCON] [Sip] Questions about the status of dual video feature in SIP

--=====================_240206218==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Indeed, this is one of several issues being addressed by the newly 
created "SIP Parity Group". Here's the announcement of that group 
that was just posted yesterday:

>Subject: [imtcmembers] Announcing IMTC SIP Parity Activity Group
>Date: Wed, 4 Mar 2009 12:50:19 -0800
>From: "Susan Lowe" <[email-masked]>
>To: "IMTC Members" <[email-masked]>
>
>
>Announcing SIP Parity AG
>IMTC's new Activity Group
>Dear IMTC Member;
>The IMTC recently added a new activity group to the organization, 
>the SIP Parity AG.  The group first came together in December 2008 
>led by Matt Collier, IMTC Board Director and SVP Corporate 
>Development at LifeSize Communications.  Ashish Goyal has joined 
>Matt as the technical co-chair who is also with LifeSize Communications.
>The two primary goals of this effort are to provide a forum for 
>members to 1.) Agree on an overall SIP profile for video with the 
>objective to bring it to full feature parity with H.323 video 
>communications, 2.) Conduct an interoperability event in Q3/Q4 2009.
>Since the beginning of the year, the group has further defined 
>itself by breaking into (3) sub-groups as follows 1.) Security, 2.) 
>Flow control/Fast update/Bandwidth negotiations, and 3). Dual video. 
>Each sub-group meets via conference call twice a month.
>The work effort has seen significant contributions from all (20) 
>participating companies. There is also a group meeting of all 
>participating companies held once a month to review the status of 
>each sub-groups work to date. The work effort will culminate in a 
>reference architecture that will be submitted to the appropriate 
>standards bodies (IETF, ITU) and the scheduling of an 
>interoperability event, target date Q3/Q4 2009.
>IMTC companies participating in the group include; Cisco, France 
>Telecom, LifeSize Communications, Polycom, TANDBERG, Sony, Canon, 
>Sharp, Aethra, Siemens, Avaya, RADVISION and several others.
>
>If you are interested in this work effort, please contact Susan Lowe 
>at <mailto:[email-masked]>[email-masked] or Matt Collier 
>at <mailto:[email-masked]>[email-masked]
>
>Best Regards,
>
>Matt Collier
>SVP Corporate Development
>LifeSize Communications
>Visit SIP Parity AG at 
><http://www.imtc.org/activity_groups/SIP.asp>http://www.imtc.org/activity_groups/SIP.asp

Regards,
Keith

At 09:01 AM 2/27/2009, Roni Even wrote:
>Hi,
>I had an initial document covering H.239 in SIP. The document has expired
>but is a starting point
>
>http://internet-drafts.osmirror.nl/draft-even-xcon-pnc-01.txt
>
>As far as I know the IMTC (http://www.imtc.org/ ) has recently started some
>effort to restart this work and get a common solution between the different
>vendors with the objective to bring a draft to the IETF.
>You can send an email to Ashish Goyal ([email-masked]) asking about the
>state of the work.
>
>Regards
>Roni Even
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan
>Johnston
>Sent: Friday, February 27, 2009 6:47 PM
>To: poplarbird
>Cc: [email-masked]
>Subject: Re: [Sip] Questions about the status of dual video feature in SIP
>
>Hi Yang,
>
>Based on a little reading on H.239, it sounds like it is a conference
>feature set, which would be implemented using SIP, RTP, various SDP
>extensions for media labeling and grouping, and XCON protocols such as
>BFCP for floor control and possibly CCMP for conference control.
>
>As such, you won't find one document that describes all these protocols,
>and most of the action happens outside of SIP.  If you have trouble
>finding some of these protocols, let me know.
>
>Also, discussion on this would probably be most productive on the XCON list.
>
>Thanks,
>Alan
>
>
>poplarbird wrote:
> >
> > Hi All,
> >
> >
> >
> > I am currently working on the interworking between SIP and H323.
> >
> >
> >
> > I had difficult in finding the status of SIP supporting dual video
> > (e.g. H.239 from a H.323 endpoint).
> >
> > Are there any drafts or standards working on it?
> >
> >
> >
> > Also with the text chatting in a SIP call, if anyone can give me the
> > RFC number that would be great.
> >
> >
> >
> > Thanks,
> >
> > Yang
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
>
>_______________________________________________
>Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments on the application of sip
>
>_______________________________________________
>XCON mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/xcon

--=====================_240206218==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Indeed, this is one of several issues being addressed by the newly
created &quot;SIP Parity Group&quot;. Here's the announcement of that
group that was just posted yesterday:<br><br>
<blockquote type=cite class=cite cite="">Subject: [imtcmembers]
Announcing IMTC SIP Parity Activity Group<br>
Date: Wed, 4 Mar 2009 12:50:19 -0800<br>
From: &quot;Susan Lowe&quot; &lt;[email-masked]&gt;<br>
To: &quot;IMTC Members&quot; &lt;[email-masked]&gt;<br><br>
<font face="Arial, Helvetica" size=2>&nbsp;<br>
</font><font face="Arial, Helvetica" size=4>Announcing SIP Parity AG
<br>
IMTC’s new Activity Group&nbsp; <br>
</font><font face="Arial, Helvetica" size=2>Dear IMTC Member;<br>
The IMTC recently added a new activity group to the organization, the SIP
Parity AG.&nbsp; The group first came together in December 2008 led by
Matt Collier, IMTC Board Director and SVP Corporate Development at
LifeSize Communications.&nbsp; Ashish Goyal has joined Matt as the
technical co-chair who is also with LifeSize Communications.&nbsp; <br>
The two primary goals of this effort are to provide a forum for members
to 1.) Agree on an overall SIP profile for video with the objective to
bring it to full feature parity with H.323 video communications, 2.)
Conduct an interoperability event in Q3/Q4 2009.<br>
Since the beginning of the year, the group has further defined itself by
breaking into (3) sub-groups as follows 1.) Security, 2.) Flow
control/Fast update/Bandwidth negotiations, and 3). Dual video. Each
sub-group meets via conference call twice a month. <br>
The work effort has seen significant contributions from all (20)
participating companies. There is also a group meeting of all
participating companies held once a month to review the status of each
sub-groups work to date. The work effort will culminate in a reference
architecture that will be submitted to the appropriate standards bodies
(IETF, ITU) and the scheduling of an interoperability event, target date
Q3/Q4 2009.<br>
IMTC companies participating in the group include; Cisco, France Telecom,
LifeSize Communications, Polycom, TANDBERG, Sony, Canon, Sharp, Aethra,
Siemens, Avaya, RADVISION and several others. <br>
</font><br>
<font face="Arial, Helvetica" size=2>If you are interested in this work
effort, please contact Susan Lowe at
<a href="mailto:[email-masked]">[email-masked]</a> or Matt
Collier at
<a href="mailto:[email-masked]">[email-masked]</a><br>
</font><br>
<font face="Arial, Helvetica" size=2>Best Regards,<br>
</font><br>
<font face="Arial, Helvetica" size=2>Matt Collier<br>
SVP Corporate Development<br>
LifeSize Communications<br>
Visit SIP Parity AG at
<a href="http://www.imtc.org/activity_groups/SIP.asp">
http://www.imtc.org/activity_groups/SIP.asp</a></font></blockquote><br>
Regards, <br>
Keith<br><br>
<br>
At 09:01 AM 2/27/2009, Roni Even wrote:<br>
<blockquote type=cite class=cite cite="">Hi, <br>
I had an initial document covering H.239 in SIP. The document has
expired<br>
but is a starting point<br><br>
<a href="http://internet-drafts.osmirror.nl/draft-even-xcon-pnc-01.txt" eudora="autourl">
http://internet-drafts.osmirror.nl/draft-even-xcon-pnc-01.txt</a><br><br>
As far as I know the IMTC
(<a href="http://www.imtc.org/" eudora="autourl">http://www.imtc.org/
</a>) has recently started some<br>
effort to restart this work and get a common solution between the
different<br>
vendors with the objective to bring a draft to the IETF.<br>
You can send an email to Ashish Goyal ([email-masked]) asking about
the<br>
state of the work.<br><br>
Regards<br>
Roni Even<br><br>
-----Original Message-----<br>
From: [email-masked]
[<a href="mailto:[email-masked]" eudora="autourl">
mailto:[email-masked]</a>] On Behalf Of Alan<br>
Johnston<br>
Sent: Friday, February 27, 2009 6:47 PM<br>
To: poplarbird<br>
Cc: [email-masked]<br>
Subject: Re: [Sip] Questions about the status of dual video feature in
SIP<br><br>
Hi Yang,<br><br>
Based on a little reading on H.239, it sounds like it is a conference
<br>
feature set, which would be implemented using SIP, RTP, various SDP <br>
extensions for media labeling and grouping, and XCON protocols such as
<br>
BFCP for floor control and possibly CCMP for conference control.<br><br>
As such, you won't find one document that describes all these protocols,
<br>
and most of the action happens outside of SIP.&nbsp; If you have trouble
<br>
finding some of these protocols, let me know.<br><br>
Also, discussion on this would probably be most productive on the XCON
list.<br><br>
Thanks,<br>
Alan<br><br>
<br>
poplarbird wrote:<br>
&gt;<br>
&gt; Hi All,<br>
&gt;<br>
&gt;&nbsp; <br>
&gt;<br>
&gt; I am currently working on the interworking between SIP and
H323.<br>
&gt;<br>
&gt;&nbsp; <br>
&gt;<br>
&gt; I had difficult in finding the status of SIP supporting dual video
<br>
&gt; (e.g. H.239 from a H.323 endpoint).<br>
&gt;<br>
&gt; Are there any drafts or standards working on it?<br>
&gt;<br>
&gt;&nbsp; <br>
&gt;<br>
&gt; Also with the text chatting in a SIP call, if anyone can give me the
<br>
&gt; RFC number that would be great.<br>
&gt;<br>
&gt;&nbsp; <br>
&gt;<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Yang<br>
&gt;<br>
&gt;
------------------------------------------------------------------------<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Sip mailing list&nbsp;
<a href="https://www.ietf.org/mailman/listinfo/sip" eudora="autourl">
https://www.ietf.org/mailman/listinfo/sip</a><br>
&gt; This list is for NEW development of the core SIP Protocol<br>
&gt; Use [email-masked] for questions on current
sip<br>
&gt; Use [email-masked] for new developments on the application of
sip<br><br>
_______________________________________________<br>
Sip mailing list&nbsp;
<a href="https://www.ietf.org/mailman/listinfo/sip" eudora="autourl">
https://www.ietf.org/mailman/listinfo/sip</a><br>
This list is for NEW development of the core SIP Protocol<br>
Use [email-masked] for questions on current sip<br>
Use [email-masked] for new developments on the application of
sip<br><br>
_______________________________________________<br>
XCON mailing list<br>
[email-masked]<br>
<a href="https://www.ietf.org/mailman/listinfo/xcon" eudora="autourl">
https://www.ietf.org/mailman/listinfo/xcon</a></blockquote></body>
</html>

--=====================_240206218==.ALT--

From [email-masked]  Fri Mar  6 11:39:53 2009
Date: Fri, 06 Mar 2009 13:40:16 -0600
From: Alan Johnston <[email-masked]>
To: [email-masked]
Cc: Adam Roach <[email-masked]>
Subject: [XCON] Agenda Requests

Please submit agenda requests for IETF-74 to Adam and me by Tuesday, 
3/10.  Include your name, draft name, topic, and how much time you would 
like.

Currently, the schedule has us meeting for 1 hour on Tuesday, March 24 
in 1710-1810 Afternoon Session III.

Thanks,
Alan

From [email-masked]  Mon Mar  9 16:15:01 2009
From: [email-masked]
To: [email-masked]
Date: Mon,  9 Mar 2009 16:15:01 -0700 (PDT)
Cc: [email-masked]
Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-02.txt

--NextPart

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.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-xcon-ccmp-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From [email-masked]  Wed Mar 11 12:57:35 2009
Content-class: urn:content-classes:message
Date: Wed, 11 Mar 2009 15:00:14 -0500
From: "Mary Barnes" <[email-masked]>
To: <[email-masked]>
Cc: Henning Schulzrinne <[email-masked]>
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. =20

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

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).=20
2) Revisit the normative language -  some SHOULDs might need to be MUSTs
(and perhaps vice versa).=20
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.). =20
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). =20

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?=20

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? =20

Regards,
Mary, Simon, Chris, Henning.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, March 09, 2009 6:15 PM
To: [email-masked]
Cc: [email-masked]
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.

From [email-masked]  Thu Mar 12 04:37:24 2009
Content-class: urn:content-classes:message
Date: Thu, 12 Mar 2009 11:37:33 -0000
From: "Duddy, Sean (Sean)" <[email-masked]>
To: "Mary Barnes" <[email-masked]>, <[email-masked]>
Cc: Henning Schulzrinne <[email-masked]>
Subject: Re: [XCON] FW:  I-D Action:draft-ietf-xcon-ccmp-02.txt

Hi Mary,
	See some comments below.

4.  Protocol Overview

	Regarding locking, I think it is an implementation issue and
common sense=20
	should apply to the implementation. Typically, each CCMP
operation would be=20
	wrapped in a transaction on the CCMP server, this would
guarantee data integrity.=20
	Depending on the type of transaction mechanism, other requests
wanting to modify=20
	the same piece of data could overwrite it, once the other
clients tx is committed or
	a 'StaleDataException' could be thrown.
=09
	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?=20
	Can this feature be expanded on in the draft?
=09
7.1.  Implementation Approach
=09
	It states that using the single HTTP verb to transport all CCMP
messages provides the=20
	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.=20
=09
	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=20
	of SOAP framework vendors out there...
=09
	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...
=09
7.2.3.2.  confsRequest and confsResponse messages
	This request needs to be extended to allow search criteria to be
passed to reduce the=20
	number of conferences passes to client. All implememtations
would require this so
	it might as well be part of the standard.
=09
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,=20
	SIP should not come into the picture...
=09
	I think the notification format and transport mechanism needs to
be defined similiarly to CCMP.=20
	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=20
	the notifications for the complete conference model(including
call control), a subscription mechanism=20
	and details of transport mechanisms - SIP and some other
protocol suitable for CCMP clients...

Sean

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mary Barnes
Sent: 11 March 2009 20:00
To: [email-masked]
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. =20

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

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).=20
2) Revisit the normative language -  some SHOULDs might need to be MUSTs
(and perhaps vice versa).=20
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.). =20
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). =20

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?=20

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? =20

Regards,
Mary, Simon, Chris, Henning.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, March 09, 2009 6:15 PM
To: [email-masked]
Cc: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/xcon

From [email-masked]  Thu Mar 26 08:06:15 2009
Date: Thu, 26 Mar 2009 15:06:42 +0000
From: Chris Boulton <[email-masked]>
To: [email-masked]
Subject: [XCON] draft-boulton-xcon-conference-control-package-04.txt

Hi,

A new version of the XCON Client Conference Control Package has been 
submitted and can be retrieved from the following link -

http://www.ietf.org/internet-drafts/draft-boulton-xcon-conference-control-package-04.txt.

All feedback welcomed.

Thanks.

Chris.

From [email-masked]  Tue Mar 31 00:55:36 2009
Content-class: urn:content-classes:message
Date: Tue, 31 Mar 2009 09:31:24 +0200
From: "Oscar Novo" <[email-masked]>
To: <[email-masked]>
Subject: [XCON] Additional Data in the Data Model

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B1D2.B2618354
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi guys!

As per discussion in this mailing list and in the last IETF-74 meeting,
the authors of the data model are proposing to add the following
elements to the data model to explicit express cloning in the document.
The elements we're planning to add are:

- cloning-parent: When this element is present, it indicates that the
conference object is a child of a parent conference. This element
contains the conference object Identifier (XCON-URI) (different from the
main XCON-URI) of the parent.
- sidebar-parent; When this element is present, it indicates that the
conference object represents a sidebar of another conference. This
element contains the conference object Identifier (XCON-URI) (different
from the main XCON-URI) of the parent.

If nobody oppose to this modifications, we'll submit a new version of
the document in brief.

Of course, any feedback to the document or to the previous modifications
are always very welcome. :)

Cheers,

Oscar

------_=_NextPart_001_01C9B1D2.B2618354
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7654.12">
<TITLE>Additional Data in the Data Model</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi guys!</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As per discussion in this mailing list =
and in the last IETF-74 meeting, the authors of the data model are =
proposing to add the following elements to the data model to explicit =
express cloning in the document.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The elements we're planning to add =
are:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- cloning-parent: When this element is =
present, it indicates that the conference object is a child of a parent =
conference. This element contains the conference object Identifier =
(XCON-URI) (different from the main XCON-URI) of the parent.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- sidebar-parent; When this element is =
present, it indicates that the conference object represents a sidebar of =
another conference. This element contains the conference object =
Identifier (XCON-URI) (different from the main XCON-URI) of the =
parent.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If nobody oppose to this modifications, =
we'll submit a new version of the document in brief.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Of course, any feedback to the document =
or to the previous modifications are always very welcome. :)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Oscar</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9B1D2.B2618354--

From [email-masked]  Tue Mar 31 04:26:53 2009
Date: Tue, 31 Mar 2009 13:27:46 +0200
From: [email-masked]
To: Oscar Novo <[email-masked]>
Cc: [email-masked]
Subject: Re: [XCON] Additional Data in the Data Model

I'm ok with the proposed modifications.

Cheers,

Simon

Quoting Oscar Novo <[email-masked]>:

> Hi guys!
>
> As per discussion in this mailing list and in the last IETF-74 meeting,
> the authors of the data model are proposing to add the following
> elements to the data model to explicit express cloning in the document.
> The elements we're planning to add are:
>
> - cloning-parent: When this element is present, it indicates that the
> conference object is a child of a parent conference. This element
> contains the conference object Identifier (XCON-URI) (different from the
> main XCON-URI) of the parent.
> - sidebar-parent; When this element is present, it indicates that the
> conference object represents a sidebar of another conference. This
> element contains the conference object Identifier (XCON-URI) (different
> from the main XCON-URI) of the parent.
>
> If nobody oppose to this modifications, we'll submit a new version of
> the document in brief.
>
> Of course, any feedback to the document or to the previous modifications
> are always very welcome. :)
>
> Cheers,
>
> Oscar
>

--=20
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/