Re: [xmpp] 'to' attribute on stanzas from server->client

Paul Aurich <paul@darkrain42.org> Sun, 17 October 2010 05:00 UTC

Return-Path: <paul@darkrain42.org>
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 CCE9A3A686A for <xmpp@core3.amsl.com>; Sat, 16 Oct 2010 22:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 xnOVE-HTL5Ib for <xmpp@core3.amsl.com>; Sat, 16 Oct 2010 22:00:17 -0700 (PDT)
Received: from mail.darkrain42.org (o-chul.darkrain42.org [IPv6:2001:470:1f05:d58::1]) by core3.amsl.com (Postfix) with ESMTP id 2F78E3A68BE for <xmpp@ietf.org>; Sat, 16 Oct 2010 22:00:17 -0700 (PDT)
Received: from [10.0.0.94] (68-118-35-134.static.mdfd.or.charter.com [68.118.35.134]) by mail.darkrain42.org (mail.darkrain42.org) with ESMTPSA id 491A4806D for <xmpp@ietf.org>; Sat, 16 Oct 2010 22:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=darkrain42.org; s=a; t=1287291701; bh=yQx98hgf7LEKG1gzEBm/uNtKDBt0gu9Jj04nyYV1ktk=; l=2583; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:DomainKey-Signature; b=ITSo3ZSFaJ9YldOYujYc5b4mXGc7nUMDYDW5adndwi2Eev42CZZl87uqikTGCiyhM Txl6GG1cohXxDzskJDGSua2QFqfucC196LFSF1Fi/HxBwI7UYitvEr/rV+DOazE5rb B9sUlwKjUyKQ9WaEk0bM3nJ/D6WABBPMABiD6B1mpSDXnYcLtyH06Ydn5OosKpxlLH xsIB40ca7THqM30AVvCaX+MOKlKnqQRqz2OgP/CGkaPsYrPG7HCQZH5PYgwq4zaxBB Naz6/svIJ5n1b2NE91aq7Hb9ZyQyDQ1Nk/JxZ5N9iVCNZe8gKBARSNt9ADwdWybY+A oXNnYOeDx+pDA==
DomainKey-Signature: a=rsa-sha1; s=a; d=darkrain42.org; c=simple; q=dns; b=bzbijy5ieVxymxTVc+Szdhb3NnEcuvSQ8tG21e/WRil/4rgt8Nqdcmz/ELxGOEJbq 3f4pT3fRHcYjYTSPhc1pA8F8fbBassDsyHAvTm5hS300/vPZLkSwkiNPIPS4+hI1rQN 0DWZH7I55SSMuX1ZtfkSxrds8+K+y0FglmBug/t5jSF+fl0ZaksWD4kKyiMSCW1cfqf OzUlG4BElsvlbTyDfABBa/7Lv/ga/qNP/BFk3r5Y+N7/T6pUBDqCux9hRmgcap/xpF6 1sqOALZ8dqJwoyhPH+Gfoik5QCT5Wj7QecQfMQympZ/2v9FMj+Qi2w8P3qihvlBeAST RlMyNuxSg==
Message-ID: <4CBA832F.7000303@darkrain42.org>
Date: Sat, 16 Oct 2010 22:01:35 -0700
From: Paul Aurich <paul@darkrain42.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: xmpp@ietf.org
References: <AANLkTikFGbJfET+Cx_cwnoZf1FzYjZENmB18zu8baYeP@mail.gmail.com> <4CB8B04D.7030900@stpeter.im> <4CB8BC7A.6010904@babelmonkeys.de>
In-Reply-To: <4CB8BC7A.6010904@babelmonkeys.de>
X-Enigmail-Version: 1.1.1
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enigBD7CD6B9C4946DB3709833D8"
Subject: Re: [xmpp] 'to' attribute on stanzas from server->client
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: Sun, 17 Oct 2010 05:00:25 -0000

On 2010-10-15 13:41, Florian Zeitz wrote:
> E.g. I have previously mentioned the social network that tells a client
> one JID during resource binding, but uses a completely different one for
> everything else. If clients were to ignore the 'to' attribute this would
> be valid (well doable) behavior and I personally think that's quite bad.
> Also almost all clients utterly fail against that service (at least for
> the roster get, not sure if we have text that causes this), so that
> change wouldn't be documenting the "status quo".

For what it's worth, my recollection of the issue with the social
network-that-we're-not-naming-and-shaming was that they stamped their IQ
response with a "from" attribute of what *they* thought the bare JID of
the account was (which wasn't what they told the client it was during
session binding), and clients validate that someone sending them roster
stanzas is allowed to do so (i.e. is from the account's bare JID or the
full JID of this session, the later option due to a quirk in RFC3921, IIRC).

At least, that was the primary issue with Pidgin (I can't think of any
specific places we validate the "to" attribute).

~Paul