Subject: [Stox] Nickname Usage Conflict Resolution

From: "De Vries, Michael [USA]" <[email-masked]>
Date: Fri, 19 Jul 2013 23:07:23 +0000

Hello everyone,

I have a concern with the suggested possible resolutions for a Nickname Usage Conflict in the draft-ietf-stox-groupchat-00 document.  In section 3.2, the document says

|   Alternatively [to translating the MSRP 425 message to a <conflict/> error],
|   the gateway might generate a new nickname request on
|   behalf of the XMPP user, thus shielding the XMPP client from handling
|   the conflict error.

Additionally, section 5 says

|   If there is a conflict between the SIP nickname and the XMPP
|   nickname, the SIP-to-XMPP or XMPP-to-SIP gateway is responsible for
|   adjusting the nickname to avoid the conflict and for informing the
|   SIP or XMPP client of the unique nickname used to join the chatroom.

First, section 3.2 suggests that the gateway may choose to generate a new nickname, but can instead merely forward on the translated MSRP 425 or <conflict/> error, whereas section 5 says that the gateway is responsible for (aka MUST) adjusting the nickname in the event of a conflict.  Both of these sections suggest that in the case of a nickname conflict the gateway may act independently of the client to change the client-generated nickname to one which is unique within the context of the chatroom.  I'm not certain this is the most appropriate approach.  Nicknames are important in that they are needed to facilitate private messaging and other features, as well as being an important part of user identification.  It seems risky to automatically generate a new nickname when a conflict is found, instead of merely presenting the error to the user (via MSRP 425 message or <conflict/> error) so that they can choose a new nickname via their client.  Additionally, a cursory examination of the XMPP, MSRP, and MUC RFCs/XEPs does not appear to show any recommendation that nicknames be automatically generated in the event of a conflict.

I believe that it would be better to require that the gateway merely forward on the translated MSRP 425 or <conflict/> error instead of attempting to address the conflict automatically, but I may not sufficiently understand the reasoning behind the automated nickname resolution.

Thanks,
--Mike DeVries

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Sat, 20 Jul 2013 15:48:16 +0200

Hi Michael,

On Jul 20, 2013, at 1:07 AM, De Vries, Michael [USA] wrote:

> First, section 3.2 suggests that the gateway may choose to generate a new nickname, but can instead merely forward on the translated MSRP 425 or <conflict/> error, whereas section 5 says that the gateway is responsible for (aka MUST) adjusting the nickname in the event of a conflict.  Both of these sections suggest that in the case of a nickname conflict the gateway may act independently of the client to change the client-generated nickname to one which is unique within the context of the chatroom.  I'm not certain this is the most appropriate approach.  Nicknames are important in that they are needed to facilitate private messaging and other features, as well as being an important part of user identification.  It seems risky to automatically generate a new nickname when a conflict is found, instead of merely presenting the error to the user (via MSRP 425 message or <conflict/> error) so that they can choose a new nickname via their client.  Additionally, a cursory examinatio
> n of the XMPP, MSRP, and MUC RFCs/XEPs does not appear to show any recommendation that nicknames be automatically generated in the event of a conflict.
> 

I agree. This is how things are usually handled in MSRP. When testing things in XMPP however, not every client is able to properly deal with nickname conflicts though. Peter, maybe this was the reason why that text was added?

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Jul 2013 20:57:30 -0600

On 7/20/13 7:48 AM, Saúl Ibarra Corretgé wrote:
>> I have a concern with the suggested possible resolutions for a 
>> Nickname Usage Conflict in the draft-ietf-stox-groupchat-00 
>> document.  In section 3.2, the document says
>> 
>> |   Alternatively [to translating the MSRP 425 message to a 
>> <conflict/> error], |   the gateway might generate a new
>> nickname request on |   behalf of the XMPP user, thus shielding
>> the XMPP client from handling |   the conflict error.
>> 
>> | nickname, the SIP-to-XMPP or XMPP-to-SIP gateway is
>> responsible for |   adjusting the nickname to avoid the conflict
>> and for informing the |   SIP or XMPP client of the unique
>> nickname used to join the chatroom.
>> 
>> First, section 3.2 suggests that the gateway may choose to
>> generate a new nickname, but can instead merely forward on the
>> translated MSRP 425 or <conflict/> error, whereas section 5 says
>> that the gateway is responsible for (aka MUST) adjusting the
>> nickname in the event of a conflict.  Both of these sections
>> suggest that in the case of a nickname conflict the gateway may
>> act independently of the client to change the client-generated
>> nickname to one which is unique within the context of the
>> chatroom.  I'm not certain this is the most appropriate approach.
>> Nicknames are important in that they are needed to facilitate
>> private messaging and other features, as well as being an
>> important part of user identification.  It seems risky to
>> automatically generate a new nickname when a conflict is found,
>> instead of merely presenting the error to the user (via MSRP 425
>> message or <conflict/> error) so that they can choose a new
>> nickname via their client.  Additionally, a cursory examinatio n
>> of the XMPP, MSRP, and MUC RFCs/XEPs does not appear to show any
>> recommendation that nicknames be automatically generated in the
>> event of a conflict.
>> 
>> I believe that it would be better to require that the gateway 
>> merely forward on the translated MSRP 425 or <conflict/> error 
>> instead of attempting to address the conflict automatically, but
>> I may not sufficiently understand the reasoning behind the
>> automated nickname resolution.
>> 
> 
> I agree. This is how things are usually handled in MSRP. When
> testing things in XMPP however, not every client is able to
> properly deal with nickname conflicts though. Peter, maybe this was
> the reason why that text was added?

I doubt that was the reason, since I don't believe in designing
protocols around buggy software. :-)

Many XMPP clients will indeed shield the user from making a decision
about the nickname (e.g., if "stpeter" is taken they will cycle
through nicks like "stpeter1" or "stpeter_" or whatever). So pushing
an error back to the originating client seems fine to me in all cases.

Question: if the gateway were to choose a nick on behalf of the
client, are we sure that the chosen nick would get communicated back
to the originating client?

In any case, I think that what Mike proposes is sensible.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/