Re: draft-ietf-simple-chat-10

On Dec 1, 2011, at 2:52 AM, Miguel A. Garcia wrote:

> Hi Ben,
> 
> The draft currently says that a nickname is associated with a URI of which the participant is known to the focus. I don't have a use case in mind where a conference server could link two different SIP AoRs and allow them to request the same nickname. It could be done, without standardization support, but I prefer not to consider this case.
> 

Okay, I think I can live with it like it is :-)

> /Miguel
> 
> On 30/11/2011 23:35, Ben Campbell wrote:
>> Given the "MUST NOT automatically assign" part, do we need to put any
>> constraints on what nicknames the conference server MAY allow? For
>> example, is it illegal to allow two different AoRs to use the same
>> nickname, if the service provider has some a priori knowledge that
>> they represent the same entity?
>> 
>> On Nov 30, 2011, at 4:30 PM, Paul Kyzivat wrote:
>> 
>>> 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.
>>>> 
>>> 
>> 
> 
> -- 
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain