Subject: Re: [Simple] draft-ietf-simple-chat-10

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 22 Nov 2011 12:39:11 +0100

Hi Paul,

I noticed that we never discussed this issue in depth. Allow me to come 
back to it.

I believe the general principle is that a nickname gets associated to a 
SIP AOR, establishing a one-to-one relationship between them. Therefore, 
if a user joins the conference under the same SIP AOR, he should be only 
allowed to use the same nickname that has been already associated from 
other devices. In any other case, an error should be generated.

Do you agree?

/Miguel

On 07/10/2011 0:58, Paul Kyzivat wrote:
> Somehow I missed the WGLC of draft-ietf-simple-chat-10 until I came
> across the post-WGLC review request sent to MMUSIC. As I was looking
> through it I came across a possible issue that isn't related to SDP
> usage. Maybe its too late to do anything about it, and maybe nothing
> needs to be done about it, but I'll mention it anyway:
>
> Section 7, in multiple places, requires that nicknames be unambiguous.
> The most specific is:
>
>      The reservation of a nickname can fail, e.g. if the NICKNAME request
>      contains a malformed or non-existent Use-Nickname header field, or if
>      the same nickname has already been reserved by another participant in
>      the conference.
>
> Elsewhere in the document the possibility is raised that the same user
> may connect to the chat from multiple devices, and that private messages
> addressed to the user would then be delivered to all those devices.
>
> So, in such a case, can each of the devices request the same nickname?
> Or must they each request a distinct nickname? It seems like it would be
> desirable to permit them all to use the same nickname. Its unclear to me
> whether the draft intends to permit this.
>
> 	Sorry to be so tardy,
> 	Paul
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Nov 2011 02:02:17 +0800

> other devices. In any other case, an error should be generated.

Conceptually that works for me. But I'm confused by the mechanics.
Isn't the request for a nickname is made in the context of an MSRP 
session? And isn't it assumed that it will go away when the session is 
terminated, unless the nickname was prereserved via some unspecified means?

If so, how is this intended to work if multiple MSRP sessions are 
established using the same AOR? Is it that each should request the 
nickname? Or only the first? If session X requests the nickname, and 
then session Y is established but does not request the nickname, can it 
still use the nickname? Then, if session X is terminated, is the 
nickname still active for session Y? If session X requests nickname NX, 
and session Y then requests nickname NY, does NY then become the 
nickname for both X and Y?

I can see several ways this *could* work:
- the nickname is bound to an AOR. Once assigned, it applies to
   all sessions from that AOR. If assigned by the nickname request
   (rather than being preassigned) it would go away when there are
   no sessions for that AOR.

- the nickname is bound to one AOR and one or more sessions.
   It is bound to both by the nickname request. Multiple sessions
   can bind the same nickname to one AOR. Once assigned it applies
   only to the sessions that bound it. If assigned by the nickname
   request it will be unbound from a session when the session ends,
   and from the AOR when there are no sessions binding that nickname.
   (Two sessions with the same AOR could have the same nickname,
   different nicknames, or no nicknames.)

- the nickname is bound only to a session, not to an AOR.
   The nicknames for sessions must all be unique.

Maybe there are more, but those are the ones that come to me.
Take your pick. But right now the draft really doesn't say how it works.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Wed, 23 Nov 2011 12:42:14 -0600

(as individual)

On Nov 23, 2011, at 12:02 PM, Paul Kyzivat wrote:

> Isn't the request for a nickname is made in the context of an MSRP session? And isn't it assumed that it will go away when the session is terminated, unless the nickname was prereserved via some unspecified means?
> 
> If so, how is this intended to work if multiple MSRP sessions are established using the same AOR? Is it that each should request the nickname? Or only the first? If session X requests the nickname, and then session Y is established but does not request the nickname, can it still use the nickname? Then, if session X is terminated, is the nickname still active for session Y? If session X requests nickname NX, and session Y then requests nickname NY, does NY then become the nickname for both X and Y?
> 

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?

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 24 Nov 2011 10:45:03 +0100

> 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 p…

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.

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 24 Nov 2011 07:39:03 -0600

On Nov 24, 2011, at 3:45 AM, Miguel A. Garcia wrote:

> 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?

---

From: Ben Campbell <[email-masked]>
Date: Thu, 24 Nov 2011 07:43:53 -0600

> 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Nov 2011 03:47:51 +0800

> 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 particu…

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?

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Nov 2011 14:18:15 -0600

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. 

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Nov 2011 06:57:31 +0800

> 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 accep…

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.

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.

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.

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.

The important thing is to get enough semantics nailed down to provide 
implementers with reasonable and consistent behavior.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Nov 2011 17:16:19 -0600

>> On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote:

[…]

> 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 :-)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Nov 2011 09:29:31 +0800

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Nov 2011 23:03:41 -0600

(still as individual)

On Nov 29, 2011, at 7:29 PM, Paul Kyzivat wrote:

> 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.

Their human tells them? :-)  (Yeah, I know…)

> 
> 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.

That's an interesting problem. I can see maybe having the nickname method return a list of available nicknames, if applicable. And maybe a "selected" one. But that's adding a lot of mechanism late in this effort. Any chance we can just mention it as an "out of scope" issue, and if anyone cares enough about a nickname sync extension to work on it, that can be a separate effort?

> 
> 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.

My concern here is that nickname usage policies could be arbitrarily complex.

> 
> 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
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Nov 2011 23:07:07 -0600

(as chair this time)

Surely Paul, Miguel, and I aren't the only ones still in this conversation? If anyone else has thoughts or opinions, please speak up.

Thanks!

Ben.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 30 Nov 2011 12:23:13 +0100

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Dec 2011 06:30:52 +0800

I wouldn't object to this.

	Thanks,
	Paul

On 11/30/11 7:23 PM, Miguel A. Garcia wrote:
>>>>>>> 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.
>>>
>>> that to be important. But then the usage mechanisms should be clear
>>> so that a UA can understand what it is getting.
>>>
>>> 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?
>>
>> 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.
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Nov 2011 16:35:09 -0600

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?