Re: draft-ietf-simple-chat-10

I wouldn't object to this.

	Thanks,
	Paul

On 11/30/11 7:23 PM, Miguel A. Garcia wrote:
> 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.
>