IETF Logo Mail Archive

[Stox] Nickname Usage Conflict Resolution

"De Vries, Michael [USA]" <devries_michael@bah.com> Fri, 19 July 2013 23:07 UTC

Return-Path: <prvs=9053bd65d=devries_michael@bah.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75F011E81BA for <stox@ietfa.amsl.com>; Fri, 19 Jul 2013 16:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.164
X-Spam-Level:
X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdE8f3Adc-6L for <stox@ietfa.amsl.com>; Fri, 19 Jul 2013 16:07:27 -0700 (PDT)
Received: from mclniron01-ext.bah.com (mclniron01-ext.bah.com [128.229.5.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7488411E81B7 for <stox@ietf.org>; Fri, 19 Jul 2013 16:07:27 -0700 (PDT)
x-SBRS: None
X-REMOTE-IP: 10.12.10.218
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8EAAvF6VEKDAra/2dsb2JhbABbhAvAS4EndIImBTpRASoUQiYBBBu/U49eg0huA6w8gio
X-IPAS-Result: Ap8EAAvF6VEKDAra/2dsb2JhbABbhAvAS4EndIImBTpRASoUQiYBBBu/U49eg0huA6w8gio
X-IronPort-AV: E=Sophos;i="4.89,705,1367985600"; d="scan'208";a="248430260"
Received: from ashbcshb06.resource.ds.bah.com ([10.12.10.218]) by mclniron01-int.bah.com with ESMTP; 19 Jul 2013 19:07:24 -0400
Received: from ASHBDAG1M2.resource.ds.bah.com ([169.254.2.214]) by ASHBCSHB06.resource.ds.bah.com ([10.12.10.218]) with mapi id 14.03.0123.003; Fri, 19 Jul 2013 19:07:23 -0400
From: "De Vries, Michael [USA]" <devries_michael@bah.com>
To: "stox@ietf.org" <stox@ietf.org>
Thread-Topic: Nickname Usage Conflict Resolution
Thread-Index: Ac6Ejowa9Oxuzw0USjSgmP9ujOftBA==
Date: Fri, 19 Jul 2013 23:07:23 +0000
Message-ID: <D928759B0247C54198D70FCD4A07DD8E38E38B62@ASHBDAG1M2.resource.ds.bah.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.12.230.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [Stox] Nickname Usage Conflict Resolution
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 23:07:33 -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

v2.23.0 | Report a Bug | By Email