Subject: [XCON] Comments on: http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-08

From: "Mary Barnes" <[email-masked]>
Date: Mon, 11 Feb 2008 15:21:01 -0600

Hi Oscar,

We (including my colleague Pierre Tane, whose cc'ed) reviewed the
document  and have a few comments on the -08 version, with a  few
comments relating to changes introduced in the -07 (Sx/Py means Section
x, Page y).  

Overall, the document is in good shape and is almost done. 

I've divided the comments into comments/issues versus nits, with the
nits at the end:

Comments/issues:
----------------

1) Floor control. The document seems to mandate BFCP as the floor
control protocol, however, per the XCON FW, BFCP is just one possible
choice for the floor control protocol. The following areas are ones we
noted need changes to reflect this (there may be others):

- S4.5.1/p1 it states "The <conference-ID> is a 32-bit BFCP conference
identifier defined in [RFC4582] section 5.1."  That whole section needs
to be changed to something like the following and noting that the schema
would also be impacted:
OLD:
   The <conference-ID> is a 32-bit BFCP conference identifier defined in
   [RFC4582] section 5.1. that identifies the BFCP conference the
   message belongs to.  This identifier represents a conference instance
   within floor control.  When created within the conferencing system,
   the 'conference-ID' has a 1:1 mapping to the unique conference object
   Identifier (XCON-URI).
NEW:
   The <conference-ID> represents a conference instance
   within floor control.  When created within the conferencing system,
   the 'conference-ID' can be represented by the unique conference
object
   Identifier (XCON-URI).  When BFCP serves as the floor control
protocol, 
   the <conference-ID> is a 32-bit BFCP conference identifier defined in
   [RFC4582] section 5.1 and there is a 1:1 mapping to the XCON-URI.

- S4.5.2 The SIP + BFCP parameters should be options when the FCP is
actually BFCP to retain flexibility for other FCPs to be bound to a XCON
conferencing server.

- S4.5.4., the third sentence needs rewording, along with the
description of the <moderator-id>:

OLD: 
   The 'id' attribute corresponds to the floor-id identifier defined in
[RFC4582]
   section 5.2.2.  
NEW: 
   In the case of BFCP [RFC4582], the 'id' attribute corresponds to the
floor-id 
   identifier defined in [RFC4582] section 5.2.2.  

OLD: 
   <moderator-id>: The optional <moderator-id> indicates the 'User
      ID' of the moderator.  The 'User ID' is a BFCP identifier defined
      in [RFC4582] section 5.1.  It MUST be set if the element
      <algorithm> is set to "Moderator-controlled" value.  Note that
      [RFC4582] refers to the moderator role as a 'floor chair'.

NEW:
   <moderator-id>: The optional <moderator-id> indicates the 'User
      ID' of the moderator.  It MUST be set if the element
      <algorithm> is set to "Moderator-controlled" value.  
      When the floor is created within the conferencing system, the
XCON-User identifier
      MAY be used as the moderator-id.  In the case of BFCP as the floor
control 
      protocol, the <moderator-id> is defined in [RFC4582] section 5.1.
Note that
      [RFC4582] refers to the moderator role as a 'floor chair'.

2) XCON-URI   
- S.9.3. My understanding is that you need more detail in this section
per RFC 4395 (Guidelines and Registration Schemas for URIs): e.g.,
Encoding considerations, Interoperatbility, security, contact, author,
references etc. 

3) XCON_USERID.
3a) General nit: Can we consistently name these identifiers with either
"-" or "_".  I am forever having to look at what they're called in the
document (and I realize this is a nit you inherited)? 

3b) S.4.6.5, p24. The schema for the XCON_USERID seems to be a cut and
paste error from the XCON-URI or I'm really confused (i.e., the type is
defined using a "conf-object-id"). In the past (i.e., when we had a lot
of this text in the XCON FW and a separate document), the XCON_USERID
was just a unique identifier and not a URI itself. It was used by the
conferencing system to map to other user identifiers , but not
necessarily other URIs - e.g., BFCP User ID which is an integer and in
the past the SIP example was the digest name and not the SIP URI. So,
I'm wondering if we really need to register a URI schema?  

Another concern is that the FW has the concept of a specific user having
multiple XCON_USERIDs within a given conferencing system to accommodate
different roles. As well, users that aren't actively part of a
conference (and may have no other signaling identifier) also need
Conference User Identifiers to be assigned. The current definition in
section 4.6.5 states that "the element <user> ... describes a single
participant in a conference", but the XCON framework provides a far
broader definition, since we allow users to manipulate the conference
using non-signaling means.  Some of the subsequent text is fine, I'm
just wondering if it wouldn't be useful to introduce the XCON_USERID
earlier in the document (e.g., section 3), since its use is broader than
that element in the data model. 

Some of this gets to the "persistence" discussion we had, since this
user information would need to be maintained by a conferencing system
outside the scope of active conferences or any conference object for
that matter. 

3c) S4.6.3/p23 Why is there a mandatory e-mail address for a user? It
seems rather odd to put such a stress on e-mail where a phone number or
any other sorts of identifier may be valid means of addressing a user.	

3d) S.9.4. Related to 3b), if a new URI schema is defined, per my
comment on S.9.3, there is additional detail required in this section. 

4) S4.6.5.3/p24	<provide-anonymity>

The framework introduces both the concept of anonymous and the idea of a
hidden participant. It's not clear to me we have everything we need to
accomplish the latter.  Is that the intent of the value of 'private'
versus the 'semi-private'? In other words, can we also  say that a
'private' user would not even appear as an "anonymous" participant if
another participant were to query the user list?  Or, is the current
text saying, for example, that a moderator that has higher permissions
would be able to see the names of all the other participants, but the
average user would not?  If so, then perhaps we need three levels for
the <provide-anonymity> and have a 'hidden' value meaning that the user
isn't visible to anyone in the conference.   Or, do we want to suggest
that a combination of 'private' and a "role" of "observer" would result
in a 'hidden' participant?  

Nits:
-------
1) S1/P4	Figure 1
	There is a mistake as the schema which is otherwise quite
generic is mentioning "Binary Floor Control Protocol" where it shall say
"Floor Control Protocol" as BFCP (RFC4582) is but one of the
alternatives for a Floor Control Protocol as mentioned in S1/P3 in the
paragraph that describes Figure 1.

S3.3.1/P8  "Conference URI Definition"
The XCON-URI gets referred to as Conference Object Identifier throughout
section 3, it would be better for consistency for section 3.3.1 to be
explicitly named "Conference Object URI Definition".

2) S4.1/p12	Change "this" to "these" and "notification" to
"notifications" per the following:
OLD:
    Note that the <conference-info> element does not have the attributes
    'state' and 'version' defined in [RFC4575] for this element because
    this attribute only applies to notifications mechanism.
NEW:
    Note that the <conference-info> element does not have the attributes
    'state' and 'version' defined in [RFC4575] for this element because
    these attributes only apply to notification mechanisms.

3) S4.2.1/p13	Second sentence in the following needs clarification:
OLD:
   The <language> element indicates the predominant language that is
   expected to be employed within a conference.  This element is not
   enforcing the language of the conference, only informs to the
   participants about the desirable language that they should used in
   the conference.  Participants are free to switch to other languages
   if they like.
NEW:
   The <language> element indicates the predominant language that is
   expected to be employed within a conference.  This element is not
   enforcing the language of the conference, but only informs the
   participants about the desirable language that they should use in
   the conference.  Participants are free to switch to other languages
   if they like.

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

---

From: Oscar Novo <[email-masked]>
Date: Fri, 22 Feb 2008 16:33:04 +0200

Hello Mary and Pierre,

Thanks for your comments. Some answer in line as [ON]. I'll try to
submit a new version of the draft with your comments in brief.

Regards,

Oscar

> I've divided the comments into comments/issues versus nits, with the

[ON] Right, I'll fix that in the new version.

> actually BFCP to retain flexibility for other FCPs to be bound to a XCON

[ON] Well, this section specifies all the different methods a conference participant can subscribe to a FCP nowadays but this section states in the last paragraph that additional connection mechanism can be defined in the future and can be added to the data model.

>       [RFC4582] refers to the moderator role as a 'floor chair'.

[ON] Thanks, I'll fix that. 
> Encoding considerations, Interoperatbility, security, contact, author,

[ON] I'll introduce a bit more of information: contact, specification,
subject, author...

> document (and I realize this is a nit you inherited)?

[ON] I'll name both of them as "-" to be more consistent.

> defined using a "conf-object-id").

[ON] Yes, it's a cut&paste error 

>  In the past (i.e., when we had a lot

[ON] The XCON_USERID still is used to map other user identifiers in the
conference and it can be use to identify one user inside a conference. 

> different roles. 
> As well, users that aren't actively part of a

[ON] In the use case of a participant with multiple XCON_USERIDs
different <user> element with different XCON_USERIDs should be defined.
Note as well one of the sentence in the section:
"It should be noted that a conferencing system is free to structure such
relationships as required and this information is just included as a
guideline that can be used."

> any other sorts of identifier may be valid means of addressing a user.	

[ON] This part of text is talking about chatroom systems and we think is
important to have the email information of the user joining a chatroom.
Note as well that the e-mail address is an optional element, not
mandatory and that is possible to extend the schema in the future with
more elements. 

> comment on S.9.3, there is additional detail required in this section. 

[ON] I'll add some more information in this section too.

> in a 'hidden' participant?  

[ON] I'll add a 'hidden' value to the <provide-anonymity> element.

> Nits:

[ON] Thanks for the nits. I'll fix all of them in the new version of the draft.