Re: draft-ietf-simple-chat-10

On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote:

> On 11/24/11 9:43 PM, Ben Campbell wrote:
>> 
>> On Nov 24, 2011, at 7:39 AM, Ben Campbell wrote:
>> 
>>> 
>>> On Nov 24, 2011, at 3:45 AM, Miguel A. Garcia wrote:
>>> 
>>>> On 23/11/2011 19:42, Ben Campbell wrote:
>>>>>> - the nickname is bound only to a session, not to an AOR.
>>>>>> The nicknames for sessions must all be unique.
>>>>> 
>>>>> I think this is the right answer, but I think it's really "bound to an AoR in the scope of a session". It seems like any scoping of nicknames beyond a specific session should be a matter of local policy. Is there anything that stops an implementation from binding a nickname across multiple simultaneous sessions or even multiple sequential sessions if it wants to?
>>>>> 
>>>> 
>>>> I wouldn't like to see this option as the only one. I would like to join the conference with the same AOR from different devices and use the same nickname. Basically, I would like to hide the fact that I am using several devices to join the chat, and be known with a single nickname across all devices.
>>> 
>>> Sure, but isn't that still a  local policy choice on how an implementation handles the same nicknames across multiple MSRP sessions?
>> 
>> To elaborate: Would it make sense to say something the effect that a nick is bound to an AoR for the scope of the MSRP session. A conference server MAY, as a matter of local policy, bind the nick at a higher scope. For example… [list a few use cases]
>> 
>> Or do you think the other use cases need to be standardized? This is more of a user experience question than an interop question, as long as we have a way of telling a client it can't use a particular nickname.
> 
> I think there can be room for policy differences here, if people feel that to be important. But then the usage mechanisms should be clear so that a UA can understand what it is getting.
> 
> I can see binding the nickname to an AOR for some duration, thus guaranteeing that some other AOR can't use it.
> 
> But there should then be some determinism as to whether such a binding is then automatically applied to each session from that AOR, or if it must be requested by each session that wants it.
> 
> And if the nickname can be used with more than one session of the same AOR, then the lifetime of the binding needs to be specified - is it till the last session using it terminates? Or till the conference terminates?
> 
> This will impact end user behavior: must the user specify the nickname independently on each of his devices? And, *may* the user use a different nickname from each of his devices even though the AOR is the same?

Ah, I think I see where you are going. 

My knee jerk reaction is that the client should have to re-request the nickname for each MSRP session. It would be dangerous for a conference server to simply assume that a second session from the same AoR should have the same nickname. My thoughts were more along the line of if a client was _allowed_ to use the same nickname in more than one MSRP session.

It seems like that a conference server SHOULD NOT (or maybe MUST NOT) assume the same nickname applies for more than one session from the same AoR, but MAY allow it. Allowing a nickname means accepting a nickname request, but never means assuming a nickname for a session when none was explicitly requested on that session. 

The policy question is about what a conference server allows. Or more to the point, what it rejects. But never what it _assumes_. For example, reject a nickname request if it is already in use for another session in the same conference. Or, reject a nickname request if it is already in use by a different AoR in the same conference. Or reject it if it used by a different AoR for any active conference. Or if it was used in an active conference in the last XXX minutes. Or something else.


Ben.