Subject: RE: [XCON] New version of the Common Conference Information Data Model

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Tue, 18 Jul 2006 08:42:57 +0200

It seems an old data model draft appears in the XCON mailing list
yesterday. 
One month ago, I sent that version to the mailing list and the XCON
mailing list's filters stopped it because the size of the message was
too big. It seems the administrator of the XCON mailing list allows that
message to pass through the filters yesterday...
The actual version of the data model is 02, it is not 01.
 
Cheers,
 
Oscar 

From: Oscar Novo (JO/LMF) [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 1:42 AM
To: XCON-IETF
Cc: [email-masked]; [email-masked]; Gonzalo Camarillo
(JO/LMF)
Subject: [XCON] New version of the Common Conference Information Data
Model 

Hi everybody,

Here you have the new version of the Common Conference Information Data
model draft with the new updates.

Cheers,

Oscar Novo

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

---

From: "Srivatsa Srinivasan" <[email-masked]>
Date: Tue, 18 Jul 2006 09:08:28 -0700

Roni/Oscar,

Couple of minor comments as I quickly went through this version (again).
I have some other comments about the event package extensions to be
defined and the issues with controls, which I will send out separately
later.
		
	1. Section 3.5 talks about <security-mechanism>. It supplies
clients with information about protocol capabilities and methods support
(like lack of support for the SIP MESSAGE method). While this may be
interesting for some clients that dynamically adjust their protocol
interaction based on capabilities of the system discovered via the
control protocol, it's easier to describe this through an extension like
a <capabilities> element that is explicit about what is supported (as a
feature whole and related protocol specifics) and what is not. Can we
defer this section to an extension?

	2. Section 3.7.3.1 and other references to from_mixer and
to_mixer. Can we be consistent here and have these as defined as
from-mixer and to-mixer instead? Lastly, I suppose it would have been
useful to have a [TODO: update schema to reflect -02 changes] comment in
Section 6.

Srivatsa.