Re: draft-ietf-simple-chat-10

Since we are converging, do you have any comments to the following text?

	  Once the conference server has reserved a nickname and has
	  bound it to a URI (e.g., a SIP Address-of-Record), the
	  conference server MAY allow the usage of the same nickname
	  by the same user (identified by the same URI, such as a SIP
	  AoR) over a second MSRP session. This might be the case if
	  the user joins the same conference from a different SIP
	  UA. In this case, the user MAY request the same or a
	  different nickname than that used in conjunction with the
	  first MSRP session; the conference server MAY accept the
	  usage of the same nickname by the same user. The conference
	  server MUST NOT automatically assign the same nickname to
	  more than one MSRP session established from the same URI,
	  because this can create confusion to the user as whether the
	  same nickname is bound to the second MSRP session.

/Miguel



On 28/11/2011 21:18, 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.
>
> 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.

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain