Subject: [XCON] XCON Chatroom consensus

From: "Oscar Novo" <[email-masked]>
Date: Fri, 12 Oct 2007 11:48:47 +0200

Hi,

I am the designated editor of a XCON data model WG document
(draft-ietf-xcon-common-data-model-05). My purpose with this e-mail is
to reach consensus about the required new fields in the XCON data model
according to:

http://tools.ietf.org/html/draft-roach-xcon-chatroom-analysis-00

Reading the document, it seems there are some sections that propose some
modifications in the XCON data model. The following text explains these
sections and the new elements we should add (in case we decide to add
them) in the data model, comments and ideas are welcome:

Section 2.4.3 (Password-Protected Chatrooms)

"The current framework described in XCON uses user authentication for
admissions control.  However, some deployed systems instead use a
single, chatroom-wide password that can be used to enter a chatroom.
This allows users to disseminate the password as a kind of invitation
token without explicitly provisioning the allowed users into the
chatroom system."

If we decide to add this feature, it will require a new field
("conference password") in the XCON data model under <user> element.  

2.4.4.  (Private and Semi-Private Chatrooms)

"Currently, the XCON model allows users to be marked individually as
anonymous or not via their corresponding <provide-anonymity> tag. Some
systems, however, include a chatroom-wide setting that can be used to
specify that all users in a chatroom are either completely anonymous
(private), or anonymous to all users with equal or lesser permissions
(semi-private)."

If we decide to add this feature, it will require to modify the
<provide-anonymity> element with the values "private" and "semi-private"
instead of Boolean.

2.4.5.  (Banned Users)

In addition to removing specific users from a conference, most deployed
systems permit the specification of "banned" users. Such banned users
are prevented from re-joining the chatroom until they have been
un-banned. Currently it's needed additional work in the case where all
users are authenticated" 

If we decide to add this feature, a <denied-users-list> is needed to
reject any users in the conference.

2.4.10.3.  (Indication of Chatroom Log Archive Location)

"Some systems include the ability for clients to access the on-line
archive of a chatroom log from within the context of their chatroom
client. (e.g., a menu selection or button that brings up a the chatroom
log)."

This feature can be defined using the <service-uris> element defined in
RFC4575. Not need to create new elements.

2.4.12.  (Detailed User Registration)

"Some chatroom systems allow -- and some require -- registration of
detailed information about a user before they are allowed to join a
chatroom. Currently, the XCON data model does not include a way to store
persistent information (name, nickname, email address, etc.) about users
who are not actively part of an ongoing chatroom session."

The three solutions propose in the draft are:

(1) Adding elements to the <allowed-users-list>/<target> element in the
XCON data model that store information about users who are associated
with the chatroom, but not presently participating in it;
(2) Setting permissions on the operations for adding users to the
<allowed-users-list> so that anyone can add such elements (as long as
they can authenticate themselves as owning the URI present in the
entry);
(3) Setting the chatroom to "closedAuthenticated". This would then
require users to "register" with a chatroom before joining;

2.4.16.  (Designation of Chatroom Language)

"The XCON data model does not currently provide a mechanism for
indicating the predominant language that is expected to be employed
within a conference."

The intention of the data model was to define this feature using the
attribute 'lang' specify in the <conference-description> element. We'll
rewrote the text to make this idea more clear in the next version. 

Cheers,

Oscar

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

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 12 Oct 2007 13:49:50 -0500

Hi,

I've also been reviewing the chatroom analysis draft while updating the
individual XCON chat draft and have some responses and a few comments to
add to what Oscar has mentioned [MB].  

I'm still pondering some of the details in the Discussion History and
Chatroom Logging sections (sections 2.4.9 and 2.4.10) and I'll post any
additional comments in a separate email. 

Mary. 

-----Original Message-----
From: Oscar Novo [mailto:[email-masked]] 
Sent: Friday, October 12, 2007 4:49 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [XCON] XCON Chatroom consensus

Hi,

[MB] But, the XCON model still requires that we have each user in the
<"allowed-users-list"> and there is already a field for whether or not
PIN authorization (e.g., "IVR") is required. This chatroom-wide password
is specific to the authentication and separate from the issue as to
whether or not you provision allowed users in the chatroom system (i.e.,
from the end user perspective, they only need the PW, the conferencing
system functionality still needs the allocate identifiers and create the
allowed users). [/MB]

[MB] I agree with Oscar's proposal. [/MB]

2.4.5.  (Banned Users)

[MB] I agree with Oscar's reponse on this one. [/MB]

[MB] This is already "allowed" in the framework (i.e., an allowed-user
shouldn't necessarily have to be a participant), particularly in that a
reservation can be setup with a list of allowed-users without them
having yet joined the conference and per the 2nd sentence in section 5.3
of the framework.   My understanding was that it would then be up to a
conferencing system as to how it manages the persistence of the data -
if not then maybe we need something more in the framework, as well
(e.g., a statement like "As well as users appearing in specific
conference objects, a conferencing may maintain persistent information
about users." in section 5.3, possibly in the are where it is discussed
that conference user identifiers can be distributed out-of-band,etc.
[/MB] 

[MB] I agree with Oscar, as I thought that was already in the data
model.  [/MB]

Cheers,

Oscar

---

From: Adam Roach <[email-masked]>
Date: Fri, 12 Oct 2007 14:47:22 -0500

> system functionality still needs the allocate identifiers and create the

I was under the impression that one could create conferences that 
allowed general membership, without needing to add people to the 
<allowed-users-list>. (If not, I think we'll run into problems).

The PIN concept is pretty much what we're looking for here, but we need 
a mechanism to extend it to other protocols. My reading right now is 
that the PIN in the data model is good only for PSTN users.

> [MB] I agree with Oscar's proposal. [/MB]

So do I.

> [MB] I agree with Oscar's reponse on this one. [/MB]

So do I.

> RFC4575. Not need to create new elements.

Ah, yes. I overlooked that. A service-uri pointing to a web-page with a 
purpose of "recording" would certainly serve the purpose quite nicely. 
I'll make a note of this. Thanks for pointing it out.

> that conference user identifiers can be distributed out-of-band,etc.

I think you misread what I was proposing. I was pointing out that the 
<allowed-users-list> is where we keep information about users associated 
with the conference but not currently participating in it. I said that 
we need to add elements to these entries that contain ancillary 
information, like name, nickname, email, etc.

> [MB] I agree with Oscar, as I thought that was already in the data

Umm... I was under the impression that the language tag here indicated 
what language was being used in the <conference-description>, not in the 
conference itself. I guess one can take it as implied that the 
conference will be in the same language as the description, but that 
doesn't quite feel right to me. I would *personally* prefer it be more 
explicit than that in the data model. If consensus is that we want to 
necessarily use the language indicator in the <conference-description> 
to *also* indicate the language used inside the conference, then such a 
binding does, at least, need to be made explicit.

/a

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 12 Oct 2007 15:34:37 -0500

Adam,

More responses inline below [MB2].

Mary.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Friday, October 12, 2007 2:47 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Oscar Novo; [email-masked]
Subject: Re: [XCON] XCON Chatroom consensus

> PIN authorization (e.g., "IVR") is required. This chatroom-wide 
> password is specific to the authentication and separate from the issue

> as to whether or not you provision allowed users in the chatroom 
> system (i.e., from the end user perspective, they only need the PW, 
> the conferencing system functionality still needs the allocate 
> identifiers and create the allowed users). [/MB]
>   

[MB2] You can have conferences with general membership, BUT the
conferencing system associates an identifier with each user.  The
framework does mention (section 5.3) that while the user identifier is
NOT required to join a conference, it is necessary to manipulate a
conference.  Non-XCON aware users (for lack of a better term) aren't
expected to be aware of the user identifier - it's a system thing. But,
it might also be necessary to include in notifications to XCON-aware
clients as to conference membership, etc.  I almost think the
<allowed-users-list> element should just be renamed <users-list> as I
think the other attributes, such as user-admission-policy, introduce the
"allowed" aspect - i.e., that list is all users associated that can
potentially be associated with the conference instance. [/MB2]

The PIN concept is pretty much what we're looking for here, but we need
a mechanism to extend it to other protocols. My reading right now is
that the PIN in the data model is good only for PSTN users.
[MB2] It's my understanding that a PIN concept could apply to any user
type.  But, maybe I've misunderstood the data model. Actually, there may
be an inconsistency in the data model.  It does say in section 4.1.2.
that a URI of PSTN-ISDN has a "PIN code" attribute, however, there is a
"join-handling" value of "IVR" in 4.5. which specifies that the user
must provide a PIN and I don't think that is restricted to the PSTN-ISDN
user. So, I wonder if that "PIN code" attribute is really necessary in
the PSTN-type definition?   [/MB2]

So do I.

> 2.4.5.  (Banned Users)
>
> In addition to removing specific users from a conference, most 
> deployed systems permit the specification of "banned" users. Such 
> banned users are prevented from re-joining the chatroom until they 
> have been un-banned. Currently it's needed additional work in the case

> where all users are authenticated"
>

So do I.

> client. (e.g., a menu selection or button that brings up a the 
> chatroom log)."
>
> This feature can be defined using the <service-uris> element defined 
> in RFC4575. Not need to create new elements.
>   

> chatroom. Currently, the XCON data model does not include a way to 
> store persistent information (name, nickname, email address, etc.) 
> about users who are not actively part of an ongoing chatroom session."
>
> (1) Adding elements to the <allowed-users-list>/<target> element in 
> the XCON data model that store information about users who are 
> associated with the chatroom, but not presently participating in it;
>

> shouldn't necessarily have to be a participant), particularly in that 
> a reservation can be setup with a list of allowed-users without them 

> about users." in section 5.3, possibly in the are where it is 
> discussed that conference user identifiers can be distributed
out-of-band,etc.

[MB2] Okay, I see your point and agree that we would need to add that
additional info. [MB2]

> attribute 'lang' specify in the <conference-description> element. 
> We'll rewrote the text to make this idea more clear in the next
version.

[MB2] Okay, I see your point here too and agree that we likely need
both. [/MB2]

/a

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 15 Oct 2007 06:35:20 -0500

version.

Spencer: I agree with Adam and Mary (my employer certainly holds conferences 
in one language that would naturally have descriptions in a second 
language).