Re: draft-ietf-simple-chat-10

On 11/29/11 4:18 AM, Ben Campbell wrote:
>
> 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.

I almost buy that logic. But consider a server that allows *permanent* 
assignment of a nickname to an AOR. In that case it might make a lot of 
sense to apply the nickname to sessions by default.

The fine line to walk here is to provide enough consistency in the 
protocol and its usage to give predictable behavior, while still 
permitting policy flexibility to the server.

If multiple sessions for the same AOR can request different nicknames, 
then I guess all of those would be bound to the AOR. In thata case it 
would not make much sense for the assignment to apply to other sessions, 
since it would be necessary to decide *which* of them would be used.

I guess it would be possible to add some option to the nickname request 
to designate it as the default for the AOR. (With only one at a time 
being permitted to be the default. Or that could be left to later, with 
no default for now.

The important thing is to get enough semantics nailed down to provide 
implementers with reasonable and consistent behavior.

	Thanks,
	Paul

> 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.
> _______________________________________________
> Simple mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/simple
>