Re: draft-ietf-simple-chat-10

(as individual)

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

> On 11/22/11 7:39 PM, Miguel A. Garcia wrote:
>> 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?
> 
> 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.

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?


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