Re: draft-ietf-simple-chat-10

Ben,

I'm ok with everything you say. But if there are multiple endpoints 
using the same AOR, that want to use the same nickname, then there is 
the issue of how they all discover what nickname to use.

If there were a way to discover the nicknames that have been reserved 
for the AOR, and there happened to be only one, then each endpoint could 
perhaps automatically request that one.

Alternately, we could imagine that the server could be configured with a 
policy to not only reserve a nickname for an AOR, but also to 
automatically request it for each UA that establishes a session with the 
AOR.

Either of those approaches requires a little bit of protocol support to 
enable the behavior and clue the UA in that it has happened.

	Thanks,
	Paul

On 11/29/11 7:16 AM, Ben Campbell wrote:
>
> On Nov 28, 2011, at 4:57 PM, Paul Kyzivat wrote:
>
>> On 11/29/11 4:18 AM, Ben Campbell wrote:
>>>
>>> On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote:
>>>
>>>>
>
> […]
>
>>>> 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.
>
> Is it a permanent _assignment_ or a permanent _reservation_? That is, does this mean that all the sessions for an AoR will automatically get the nickname, or that sessions for some other AoR _can't_ get the nickname?
>
>>
>> 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.
>
> I agree. And it seems to me that the approach of never assigning a nickname unless explicitly requested in the session gives the most predictable for any remaining policy choice--and avoids the potential for embarrassment when I suddenly realize the hard way that my drinking-buddy chat room is hosted on the same service as my church chatroom. That is, I'm afraid any automatic or default assignments have the potential to be a privacy problem.
>
>
>>
>> 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.
>
> My argument above is that it is, in a generic sense, _dangerous_ to assume an assignment in any one session gets applied to any other session.
>
>>
>> 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.
>
> How expensive is one nickname transaction per session really going to be? What problem is solved by default nicknames? Is it a question of not having to remember my nickname across multiple clients?
>
>>
>> The important thing is to get enough semantics nailed down to provide implementers with reasonable and consistent behavior.
>
> I totally agree, and thank you for making me realize this was a more complex issue than I originally thought :-)
>
>>
>> 	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
>>>
>>
>> _______________________________________________
>> Simple mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/simple
>
> _______________________________________________
> Simple mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/simple
>