Subject: RE: [XCON] XCON Chatroom consensus

From: "Oscar Novo" <[email-masked]>
Date: Thu, 1 Nov 2007 09:35:15 +0100

Hello,

After the discussion of the new chatroom elements that should be include
in the data model. Here it's some more comments about the topic. If the
WG agree on that I'll add these elements in the next version of the data
model. Comments as [ON].

Cheers,

Oscar

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: 12. lokakuuta 2007 23:35
To: Adam Roach
Cc: Oscar Novo; [email-masked]
Subject: RE: [XCON] XCON Chatroom consensus

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

On 10/12/07 1:49 PM, Mary Barnes wrote:
> -----Original Message-----
> From: Oscar Novo [mailto:[email-masked]]
>
> 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.
>
> [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]
>   

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).

[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]

[ON] In the version 06 of the data model we have modified the 'IVR'
value of the <join-handling> element for an 'authenticate' value. The
'authenticate' value is not restricted to the PSTN-ISDN users as the
'IVR' value. As well, the <conf-uris> element does not have the
<PSTN-ISDN> element anymore under <conf-uris>. These changes have been
done to validate the consensus achieve in the last ietf meeting.  

In the next version of the draft we can add a new attribute 'conference
password' in the <conf-uris> element to complete the requirements of the
discussion above. 
[/ON]

> 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.
>
> [MB] I agree with Oscar's proposal. [/MB]
>   

So do I.

[ON] We'll do that [/ON]

> 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.
>
> [MB] I agree with Oscar's reponse on this one. [/MB]
>   

So do I.

[ON] We'll do that [/ON]

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

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.

> 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;
>
> [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]

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.

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

[ON] We'll add the solution number one to the next version of the data
model [/ON]

> 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.
>
> [MB] I agree with Oscar, as I thought that was already in the data 
> model.  [/MB]
>   

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.

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

[ON] We'll add a new element <language> under <conference-description>
to differentiate both cases. [/ON]

/a

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

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 14 Nov 2007 09:18:04 -0600

Oscar,

I didn't see any other responses here, but I'm okay with the proposals
you suggest below.

Mary. 

-----Original Message-----
From: Oscar Novo [mailto:[email-masked]] 
Sent: Thursday, November 01, 2007 3:35 AM
To: Barnes, Mary (RICH2:AR00); Adam Roach; Spencer Dawkins
Cc: [email-masked]
Subject: RE: [XCON] XCON Chatroom consensus

Hello,

Cheers,

Oscar

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 12. lokakuuta 2007 23:35
To: Adam Roach
Cc: Oscar Novo; [email-masked]
Subject: RE: [XCON] XCON Chatroom consensus

Adam,

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

"semi-private"

So do I.

[ON] We'll do that [/ON]

So do I.

[ON] We'll do that [/ON]

5.3

out-of-band,etc.

version.

/a