Re: [xmpp] 3921bis: delivery of messages addressed to bare JIDs

"Ben Schumacher" <Ben.Schumacher@webex.com> Fri, 29 January 2010 23:21 UTC

Return-Path: <Ben.Schumacher@webex.com>
X-Original-To: xmpp@core3.amsl.com
Delivered-To: xmpp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBE53A6803 for <xmpp@core3.amsl.com>; Fri, 29 Jan 2010 15:21:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.531
X-Spam-Level:
X-Spam-Status: No, score=-104.531 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8WE1q0koiAK for <xmpp@core3.amsl.com>; Fri, 29 Jan 2010 15:21:03 -0800 (PST)
Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id DDFA23A67E1 for <xmpp@ietf.org>; Fri, 29 Jan 2010 15:21:03 -0800 (PST)
Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 15:21:27 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: from 66.114.169.8 ([66.114.169.8]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.12]) with Microsoft Exchange Server HTTP-DAV ; Fri, 29 Jan 2010 23:21:19 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA139.C37298AD"
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b2pre Thunderbird/3.0.1
Content-class: urn:content-classes:message
Date: Fri, 29 Jan 2010 15:21:19 -0800
Message-ID: <952A4B1F81123B479292D4B5FDC00D8503BA5E30@SRV-EXSC03.webex.local>
In-Reply-To: <2767D2DD-75E1-41B5-8C2C-A60213CC1C28@webkeks.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [xmpp] 3921bis: delivery of messages addressed to bare JIDs
Thread-Index: AcqhOcNyS2e/N4/iRi6vvuopOZK7RQ==
References: <4B621B30.8090508@stpeter.im> <2767D2DD-75E1-41B5-8C2C-A60213CC1C28@webkeks.org>
From: Ben Schumacher <Ben.Schumacher@webex.com>
To: xmpp@ietf.org
X-OriginalArrivalTime: 29 Jan 2010 23:21:27.0473 (UTC) FILETIME=[C8092210:01CAA139]
X-Mailman-Approved-At: Sun, 31 Jan 2010 10:50:16 -0800
Subject: Re: [xmpp] 3921bis: delivery of messages addressed to bare JIDs
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2010 23:21:04 -0000

On 01/29/2010 05:39 AM, Jonathan Schleifer wrote:
> Hm, this sounds to me like killing resources all together. Why not let 
> the user decide? For example, if the user gives all resources the same 
> priority, all resources get the message. If the user decides to use 
> different priorities, only the one with the higehst gets it (if 2 are 
> sharing the highest prio, both should get it).
>
> I think priorities and resources are one of the killer features of 
> XMPP and should not be removed or crippled.

Priorities and resource-based routing are killer features only if you 
happen to be a member of the relatively small XMPP developer community 
-- for IM users it's just confusing and unnecessary. They want to login 
a client and get instant messages.

Missing IMs because you accidentally left yourself logged in on another 
machine, or because Client X has different default priority settings 
than Client Y is inconvenient, annoying and prone to error. These is 
nothing in the wording change that's going to _force_ implementations 
into a different behavior, but with luck it'll encourage servers and 
clients to move towards more explicit solutions to choosing sessions for 
message delivery, i.e. privacy lists, SIFT and Mine-ing.

My opinion, anyhow.

Ben