Re: draft-ietf-simple-chat-10

Paul Kyzivat <[email protected]>
Newsgroups gmane.ietf.simple
Message-ID <[email protected]>
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.

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
>
> 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 protected]
>> https://www.ietf.org/mailman/listinfo/simple
>>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.