Re: draft-ietf-simple-chat-10

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.

/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