From mamille2@cisco.com Wed Apr 4 14:05:14 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B81911E8099 for ; Wed, 4 Apr 2012 14:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 RVVVD6uxkoml for ; Wed, 4 Apr 2012 14:05:13 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id AE4B211E8089 for ; Wed, 4 Apr 2012 14:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=2344; q=dns/txt; s=iport; t=1333573513; x=1334783113; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aVF67+yk0U6C1CfTFZWIf8jbbS0oKP9l6BmrpiaC94w=; b=lHToi6DFrYOYTYfhqh0q77zi/7KedaFl6PnkXTqreEevuTo5GZt3WL/w HMK9CiYCfY2NSsV5vGdyNy//ErjazGqBrwaY7P4KyrV4i9qwxcyiUA6Q7 qNu5zLCYE4jzc+1j2ulZ4mkpI5AReFCYbmmiAEjR0W+cRiKxYY1uZYn/o M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG62fE+rRDoJ/2dsb2JhbABDuDeBB4IJAQEBAwESAScyDRALRlcGEwkZh2IEAQufPZZ2j2xjBIhYjQuBEY02gWmDBg X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="39093179" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 04 Apr 2012 21:05:13 +0000 Received: from dhcp-64-101-72-213.cisco.com (dhcp-64-101-72-213.cisco.com [64.101.72.213]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q34L5C5A000783; Wed, 4 Apr 2012 21:05:12 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matt Miller In-Reply-To: <4F7332A5.1030602@bbn.com> Date: Wed, 4 Apr 2012 15:05:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <29698B3B-431E-42BA-AC8F-7FAF1B013960@cisco.com> References: <4F731C64.3000209@bbn.com> <20897.1332949022.825953@puncture> <4F7332A5.1030602@bbn.com> To: "Richard L. Barnes" X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: XMPP Working Group Subject: Re: [xmpp] Commonality of proof types X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 21:05:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 28, 2012, at 09:47, Richard L. Barnes wrote: >>> Just musing on what proof types look like... >>=20 >> That smells like it's somewhat combining the proof types. >>=20 >> That is, you're saying we'd use DNSSEC if possible, but to maximize = the >> potential of it working, we'd serialize the chain and stick it = somewhere >> well-known, secured by HTTPS as a final fallback. >>=20 >> The serialization of the chain is basically a potted set of the DNS >> answers (and their signatures) that you'd have got if you'd gone = through >> the DNS anyway. If you can (only) trust the HTTPS cert used to secure >> the blob, you use that. >>=20 >> Does that sounds roughly right? >=20 > Yep, you got it. >=20 >=20 >> My only concern is that the "bare" certificate in .well-known (as >> exemplified by TurboHalibut) has a very low implementation = threshold[1], >> whereas this would invoke DNSSEC quite heavily. >>=20 >> Dave. >>=20 >> [1] - This means it's easy to code. >=20 > Appreciate the concern. It does help that there are already tools, as = in: > >=20 Using a "bare" certificate isn't just easy to code against, it's also = easy to obtain and deploy (there's already lots of tools for that, = certain doctors notwithstanding). This makes it a lot easier for me to = explain to ops how to deploy it, and without requiring me to provide = more utilities outside of my core product/service. As DANE gains wider acceptance, I expect DNS hosts to provide nice web = tools that let that same ops person take that same cert and drop it into = a web form. - - m&m Matt Miller - Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPfLeHAAoJEJq6Ou0cgrSPxC0IAKzVEgd10X1bvM08Z37ledHK F6DqHJY7GFnTyCRdh5U1b78VYh5YhjkAh+N16TA5dlULRwwLH0frNNnAv2GAkFH6 L/QiD1SIDDr5es6LSvYBV+0YOcYBoQ31kFJhTCTw6fDJMmtw/NwL60CGuuRpdWy3 oA7c2CLJp0hh0uvk6tHAXQNKRBflFhS1XbIOVaK9nbdJAo1vRRLU8fbc0Yj5y08Y gqaUB6oNEv2rorZjHI8dQBR/LUCFs81FkpV3tmJJ23H/R5gSfYd7pTK/ZROCna+m lLVbNTFhMPeN+dv4eApW9sk0x0HQ9H94uVcVWWSCcoID2UIP/BJ9OmEUcvZ8U30=3D =3DWa0v -----END PGP SIGNATURE----- From ben@nostrum.com Fri Apr 6 13:49:18 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD53D21F84DA for ; Fri, 6 Apr 2012 13:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 SfTR+v-4Pqvh for ; Fri, 6 Apr 2012 13:49:18 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2991321F84D3 for ; Fri, 6 Apr 2012 13:49:18 -0700 (PDT) Received: from dn3-123.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q36KnEBL045760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Apr 2012 15:49:16 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Apr 2012 15:49:14 -0500 Message-Id: To: XMPP Group Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [xmpp] Paris Meeting Draft Minutes X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 20:49:18 -0000 Hi Everyone, The draft minutes for the XMPP meeting at IETF83 are available at the = following link. Please send any additions or corrections to the XMPP = list as soon as possible. http://www.ietf.org/proceedings/83/minutes/minutes-83-xmpp.txt Thanks! Ben.= From stpeter@stpeter.im Mon Apr 9 18:33:58 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60BF21F85A0 for ; Mon, 9 Apr 2012 18:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 KxEFXWTYFlIS for ; Mon, 9 Apr 2012 18:33:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 17EF421F8562 for ; Mon, 9 Apr 2012 18:33:58 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 750FB40058 for ; Mon, 9 Apr 2012 19:47:43 -0600 (MDT) Message-ID: <4F838E03.3080504@stpeter.im> Date: Mon, 09 Apr 2012 19:33:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis-01 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 01:33:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've just submitted version -01 of draft-ietf-xmpp-6122bis. I've attempted to capture what I take to be the emerging consensus regarding the open issues I posted about on the list before IETF 83, namely: 1. Internationalized labels within domainparts must be U-labels (instead of should be U-labels). 2. Servers must enforce the address formatting rules. 3. Use Unicode Normalization Form C. 4. Define various protocol slots. 5. Delegate the handling of full-width and half-width codepoints to draft-yoneya-precis-mappings. Please review version -01 and post to the list if you disagree with how I have attempted to capture the working group discussions. Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+DjgMACgkQNL8k5A2w/vxaaQCgwmx2RzxneU3QkjtCwr85CcDn ZFIAoKP1ll8N/Hx90giacQdIQjmods14 =2wfX -----END PGP SIGNATURE----- From internet-drafts@ietf.org Mon Apr 9 18:36:54 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B16111E808D; Mon, 9 Apr 2012 18:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 aNvsFKPwvjZJ; Mon, 9 Apr 2012 18:36:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AC011E8079; Mon, 9 Apr 2012 18:36:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120410013653.30877.4106.idtracker@ietfa.amsl.com> Date: Mon, 09 Apr 2012 18:36:53 -0700 Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-01.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 01:36:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Extensible Messaging and Presence Pro= tocol Working Group of the IETF. Title : Extensible Messaging and Presence Protocol (XMPP): Addre= ss Format Author(s) : Peter Saint-Andre Filename : draft-ietf-xmpp-6122bis-01.txt Pages : 20 Date : 2012-04-09 This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the US-ASCII range. This document obsoletes RFC 6122. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xmpp-6122bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-xmpp-6122bis-01.txt From fippo@mail.symlynx.com Tue Apr 10 09:01:16 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7885A21F85AC for ; Tue, 10 Apr 2012 09:01:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tpIrDmj0Lfp for ; Tue, 10 Apr 2012 09:01:15 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 401D021F859A for ; Tue, 10 Apr 2012 09:01:14 -0700 (PDT) Received: from [192.168.2.100] (p549723CD.dip.t-dialin.net [84.151.35.205]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3AG18Bc023670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 18:01:12 +0200 Message-ID: <4F84593F.9010503@mail.symlynx.com> Date: Tue, 10 Apr 2012 18:01:03 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: XMPP Working Group , Peter Saint-Andre References: <4F508095.50104@mail.symlynx.com> In-Reply-To: <4F508095.50104@mail.symlynx.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:01:16 -0000 Am 02.03.2012 09:11, schrieb Philipp Hancke: > the example for the host-unknown stream error is quite odd > http://tools.ietf.org/html/rfc6120#section-4.9.1.3 Additionally, it is setting a version=1.0 on the response stream without sending (which is a MUST from 4.3.2) All examples (*) showing a stream error during setup should not set a version=1.0 on the response stream. Accordingly, there should be some text in 4.9.1.2 saying that the receiving entity should not set the version on the response stream if an error occured. (*) examples 4.9.1.2, 4.9.1.3, 4.9.3.2, 4.9.3.3, 4.9.3.5, 4.9.3.6, 4.9.3.10, 4.9.3.15, 4.9.3.17, 4.9.3.19, 4.9.3.22 and 4.9.3.25. From dave@cridland.net Tue Apr 10 09:12:29 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6EE11E80F2 for ; Tue, 10 Apr 2012 09:12:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3M3rDwPHgkG for ; Tue, 10 Apr 2012 09:12:28 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 56C6511E80BE for ; Tue, 10 Apr 2012 09:12:28 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id EE3A21168087; Tue, 10 Apr 2012 17:12:22 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EF6LoGFbxyj; Tue, 10 Apr 2012 17:12:20 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 64FD51168067; Tue, 10 Apr 2012 17:12:20 +0100 (BST) References: <4F508095.50104@mail.symlynx.com> <4F84593F.9010503@mail.symlynx.com> In-Reply-To: <4F84593F.9010503@mail.symlynx.com> MIME-Version: 1.0 Message-Id: <3404.1334074340.382261@puncture> Date: Tue, 10 Apr 2012 17:12:20 +0100 From: Dave Cridland To: Philipp Hancke , XMPP Working Group , Peter Saint-Andre Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:12:29 -0000 On Tue Apr 10 17:01:03 2012, Philipp Hancke wrote: > Am 02.03.2012 09:11, schrieb Philipp Hancke: >> the example for the host-unknown stream error is quite odd >> http://tools.ietf.org/html/rfc6120#section-4.9.1.3 > > Additionally, it is setting a version=1.0 on the response stream > without sending (which is a MUST from 4.3.2) > > All examples (*) showing a stream error during setup should not set > a version=1.0 on the response stream. Accordingly, there should be > some text in 4.9.1.2 saying that the receiving entity should not > set the version on the response stream if an error occured. Philipp and I had quite a chat about this. The examples are wrong in and of themselves because they're not sending stream features - but it turned out that we have both implenented this case to not send a version attribute (and, correspondingly, not send features) in order to avoid confusion - in general, my thinking is that existing features are worthless in this case. Therefore I agree entirely with Philipp's suggestion here, which is to fix the examples by removing the version attribute, (rather than by adding features) and additionally add text recommending this practise in §4.9.1.2. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From justin@affinix.com Tue Apr 10 09:34:49 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD2C11E8131 for ; Tue, 10 Apr 2012 09:34:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxFDkae3dtVs for ; Tue, 10 Apr 2012 09:34:48 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1689011E812E for ; Tue, 10 Apr 2012 09:34:48 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 68FBA10AFB2 for ; Tue, 10 Apr 2012 09:34:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=affinix.com; h=from:to:subject :date:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; q=dns; s=affinix.com; b=q 3tkgJmpur9LVjvTIOSCrrY9Mt/NtBoJwfTJbPiUNs9FK78r52iLK8WcrprC0GqxE nULOp+V9PUr9t+Y+kRwesVsqlioQBErRNrr+U1qCK82GngSEu2o3nGdm8eFJZkZS n+QtZH0Q3cr2s50QRJlMVacSe1EYhSyfop+YVKbqp0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=affinix.com; h=from:to :subject:date:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; s=affinix.com; bh=w48T1Oh 4KGXCyanlGh2DRHfZo30=; b=cBr2igpsGvm3/LYGnUOJuxV+A4rcfRvT8Jclu8R skjHVTM6ZF1Wh0AWnRBLuiF5/WEzWkacG6oits8Bg6huE0dFi6rJvdzVYIusya/t VbOkfOh8EL8HgSZQ9gIeUxKejxTqtTkhK7ZbUpT8iUY5qMz05SzrlGuhtWC2Xlb/ ppEw= Received: from purelace.localnet (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: justin@affinix.com) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id 38AE310AFB1 for ; Tue, 10 Apr 2012 09:34:47 -0700 (PDT) From: Justin Karneges To: xmpp@ietf.org Date: Tue, 10 Apr 2012 09:34:44 -0700 User-Agent: KMail/1.13.6 (Linux/2.6.38-13-generic; KDE/4.6.5; x86_64; ; ) References: <4F508095.50104@mail.symlynx.com> <4F84593F.9010503@mail.symlynx.com> <3404.1334074340.382261@puncture> In-Reply-To: <3404.1334074340.382261@puncture> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201204100934.44412.justin@affinix.com> Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:34:49 -0000 On Tuesday, April 10, 2012 09:12:20 AM Dave Cridland wrote: > On Tue Apr 10 17:01:03 2012, Philipp Hancke wrote: > > Am 02.03.2012 09:11, schrieb Philipp Hancke: > >> the example for the host-unknown stream error is quite odd > >> http://tools.ietf.org/html/rfc6120#section-4.9.1.3 > >=20 > > Additionally, it is setting a version=3D1.0 on the response stream > > without sending (which is a MUST from 4.3.2) > >=20 > > All examples (*) showing a stream error during setup should not set > > a version=3D1.0 on the response stream. Accordingly, there should be > > some text in 4.9.1.2 saying that the receiving entity should not > > set the version on the response stream if an error occured. >=20 > Philipp and I had quite a chat about this. >=20 > The examples are wrong in and of themselves because they're not > sending stream features - but it turned out that we have both > implenented this case to not send a version attribute (and, > correspondingly, not send features) in order to avoid confusion - in > general, my thinking is that existing features are worthless in this > case. >=20 > Therefore I agree entirely with Philipp's suggestion here, which is > to fix the examples by removing the version attribute, (rather than > by adding features) and additionally add text recommending this > practise in =A74.9.1.2. Does the spec ever generally discuss this kind of "XMPP 0.9" behavior? If n= ot,=20 I'd think this would be quite confusing to new readers. Justin From stpeter@stpeter.im Tue Apr 10 10:09:27 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D8811E80F3 for ; Tue, 10 Apr 2012 10:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 vwVqBSPw7XHH for ; Tue, 10 Apr 2012 10:09:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 75C6811E80E8 for ; Tue, 10 Apr 2012 10:09:26 -0700 (PDT) Received: from dhcp-64-101-72-216.cisco.com (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 42E8740058; Tue, 10 Apr 2012 11:23:14 -0600 (MDT) Message-ID: <4F846944.2040801@stpeter.im> Date: Tue, 10 Apr 2012 11:09:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Justin Karneges References: <4F508095.50104@mail.symlynx.com> <4F84593F.9010503@mail.symlynx.com> <3404.1334074340.382261@puncture> <201204100934.44412.justin@affinix.com> In-Reply-To: <201204100934.44412.justin@affinix.com> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:09:27 -0000 On 4/10/12 10:34 AM, Justin Karneges wrote: > On Tuesday, April 10, 2012 09:12:20 AM Dave Cridland wrote: >> On Tue Apr 10 17:01:03 2012, Philipp Hancke wrote: >>> Am 02.03.2012 09:11, schrieb Philipp Hancke: >>>> the example for the host-unknown stream error is quite odd >>>> http://tools.ietf.org/html/rfc6120#section-4.9.1.3 >>> >>> Additionally, it is setting a version=1.0 on the response stream >>> without sending (which is a MUST from 4.3.2) >>> >>> All examples (*) showing a stream error during setup should not set >>> a version=1.0 on the response stream. Accordingly, there should be >>> some text in 4.9.1.2 saying that the receiving entity should not >>> set the version on the response stream if an error occured. >> >> Philipp and I had quite a chat about this. >> >> The examples are wrong in and of themselves because they're not >> sending stream features - but it turned out that we have both >> implenented this case to not send a version attribute (and, >> correspondingly, not send features) in order to avoid confusion - in >> general, my thinking is that existing features are worthless in this >> case. >> >> Therefore I agree entirely with Philipp's suggestion here, which is >> to fix the examples by removing the version attribute, (rather than >> by adding features) and additionally add text recommending this >> practise in §4.9.1.2. > > Does the spec ever generally discuss this kind of "XMPP 0.9" behavior? If not, > I'd think this would be quite confusing to new readers. Agreed. I'd rather finesse the issue by changing Section 4.3.2 as follows. OLD If the initiating entity includes in the initial stream header the 'version' attribute set to a value of at least "1.0" (see Section 4.7.5), after sending the response stream header the receiving entity MUST send a child element NEW If the initiating entity includes in the initial stream header the 'version' attribute set to a value of at least "1.0" (see Section 4.7.5), after sending the response stream header the receiving entity MUST, if it intends to maintain the stream, send a child element This gives us some wiggle room about not sending features in the situation where the receiving entity immediately closes the stream. Peter -- Peter Saint-Andre https://stpeter.im/ From florob@babelmonkeys.de Tue Apr 10 10:52:57 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B23B11E8104 for ; Tue, 10 Apr 2012 10:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 eS3v6KUd4NjL for ; Tue, 10 Apr 2012 10:52:56 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 7804F11E8103 for ; Tue, 10 Apr 2012 10:52:56 -0700 (PDT) Received: from [2001:470:7a2c:0:21a:73ff:fee5:4fbf] by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SHfFM-00075J-N9; Tue, 10 Apr 2012 19:52:52 +0200 Message-ID: <4F847373.4090700@babelmonkeys.de> Date: Tue, 10 Apr 2012 19:52:51 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120406 Thunderbird/11.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <4F508095.50104@mail.symlynx.com> <4F84593F.9010503@mail.symlynx.com> <3404.1334074340.382261@puncture> <201204100934.44412.justin@affinix.com> <4F846944.2040801@stpeter.im> In-Reply-To: <4F846944.2040801@stpeter.im> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:52:57 -0000 Am 10.04.2012 19:09, schrieb Peter Saint-Andre: > On 4/10/12 10:34 AM, Justin Karneges wrote: > Agreed. > > I'd rather finesse the issue by changing Section 4.3.2 as follows. > > OLD > If the initiating entity includes in the initial stream header the > 'version' attribute set to a value of at least "1.0" (see > Section 4.7.5), after sending the response stream header the > receiving entity MUST send a child element > > NEW > If the initiating entity includes in the initial stream header the > 'version' attribute set to a value of at least "1.0" (see > Section 4.7.5), after sending the response stream header the > receiving entity MUST, if it intends to maintain the stream, send a > child element > > This gives us some wiggle room about not sending features in the > situation where the receiving entity immediately closes the stream. > +∞ Just because we are sending a stream error, the server does not suddenly not speak "XMPP 1.0" any more. Changing the problematic text seems much nicer than "hacking around it" everywhere else to me too. Regards, Florian Zeitz From dave@cridland.net Tue Apr 10 12:44:46 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0008611E813F for ; Tue, 10 Apr 2012 12:44:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD1QHFgOxQXW for ; Tue, 10 Apr 2012 12:44:25 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id C68A111E8132 for ; Tue, 10 Apr 2012 12:44:24 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 5CC671168087; Tue, 10 Apr 2012 20:44:19 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDxoTOaNq2Xc; Tue, 10 Apr 2012 20:44:16 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 0B41C1168067; Tue, 10 Apr 2012 20:44:15 +0100 (BST) References: <4F508095.50104@mail.symlynx.com> <4F84593F.9010503@mail.symlynx.com> <3404.1334074340.382261@puncture> <201204100934.44412.justin@affinix.com> <4F846944.2040801@stpeter.im> <4F847373.4090700@babelmonkeys.de> In-Reply-To: <4F847373.4090700@babelmonkeys.de> MIME-Version: 1.0 Message-Id: <3404.1334087055.971582@puncture> Date: Tue, 10 Apr 2012 20:44:15 +0100 From: Dave Cridland To: Florian Zeitz , XMPP Working Group , Peter Saint-Andre Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:44:48 -0000 On Tue Apr 10 18:52:51 2012, Florian Zeitz wrote: > Just because we are sending a stream error, the server does not > suddenly > not speak "XMPP 1.0" any more. > Changing the problematic text seems much nicer than "hacking around > it" > everywhere else to me too. We're not just considering changing problematic text; we're working around existing implementations. I'll admit this is somewhat optimizing for the failure case, and as such it's possibly not the greatest hill to choose to die upon, but I do feel that the correct fix (from an engineering, not a purist design) standpoint is to drop the version attribute if the intent is not to send stream features. This *is* compliant - it's not hacking around it - and it's compliant with the existing specification text, not the examples. As such, it's merely adding a clarification to the normative text and correcting the (non-normative) examples, and not changing the specification at all. Finally, it'll work with all existing implementations. Changing the protocol, on the other hand - whilst we may well be changing it to how we might have designed it in the first place with hindsight - is still changing it. The effects are unknown, and may well be detrimental. There's clearly a way to proceed without introducing this risk. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter@stpeter.im Tue Apr 10 12:52:34 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A97311E814A for ; Tue, 10 Apr 2012 12:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 nP1tZsgi7k3Q for ; Tue, 10 Apr 2012 12:52:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A24B811E8144 for ; Tue, 10 Apr 2012 12:52:33 -0700 (PDT) Received: from dhcp-64-101-72-235.cisco.com (unknown [64.101.72.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C7C6640058; Tue, 10 Apr 2012 14:06:21 -0600 (MDT) Message-ID: <4F848F80.5010709@stpeter.im> Date: Tue, 10 Apr 2012 13:52:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Dave Cridland References: <4F508095.50104@mail.symlynx.com> <4F84593F.9010503@mail.symlynx.com> <3404.1334074340.382261@puncture> <201204100934.44412.justin@affinix.com> <4F846944.2040801@stpeter.im> <4F847373.4090700@babelmonkeys.de> <3404.1334087055.971582@puncture> In-Reply-To: <3404.1334087055.971582@puncture> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:52:34 -0000 On 4/10/12 1:44 PM, Dave Cridland wrote: > On Tue Apr 10 18:52:51 2012, Florian Zeitz wrote: >> Just because we are sending a stream error, the server does not suddenly >> not speak "XMPP 1.0" any more. >> Changing the problematic text seems much nicer than "hacking around it" >> everywhere else to me too. > > We're not just considering changing problematic text; we're working > around existing implementations. > > I'll admit this is somewhat optimizing for the failure case, and as such > it's possibly not the greatest hill to choose to die upon, but I do feel > that the correct fix (from an engineering, not a purist design) > standpoint is to drop the version attribute if the intent is not to send > stream features. Section 4.7.5 says: The inclusion of the version attribute set to a value of at least "1.0" signals support for the stream-related protocols defined in this specification, including TLS negotiation (Section 5), SASL negotiation (Section 6), stream features (Section 4.3.2), and stream errors (Section 4.9). So not including the version attribute indicates that you don't support stream errors; immediately sending a stream error after that seems odd. > This *is* compliant - it's not hacking around it - and it's compliant > with the existing specification text, not the examples. As such, it's > merely adding a clarification to the normative text and correcting the > (non-normative) examples, and not changing the specification at all. > > Finally, it'll work with all existing implementations. > > Changing the protocol, on the other hand - whilst we may well be > changing it to how we might have designed it in the first place with > hindsight - is still changing it. The effects are unknown, and may well > be detrimental. There's clearly a way to proceed without introducing > this risk. "Clearly" might be a bit strong. Peter -- Peter Saint-Andre https://stpeter.im/ From dave@cridland.net Tue Apr 10 13:37:28 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25D511E8140 for ; Tue, 10 Apr 2012 13:37:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQDqlHJ+eOjM for ; Tue, 10 Apr 2012 13:37:27 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 12C6311E8141 for ; Tue, 10 Apr 2012 13:37:26 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 840DD1168087; Tue, 10 Apr 2012 21:37:19 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzOXkCbvLV1d; Tue, 10 Apr 2012 21:37:15 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 59C821168067; Tue, 10 Apr 2012 21:37:15 +0100 (BST) References: <4F508095.50104@mail.symlynx.com> <4F84593F.9010503@mail.symlynx.com> <3404.1334074340.382261@puncture> <201204100934.44412.justin@affinix.com> <4F846944.2040801@stpeter.im> <4F847373.4090700@babelmonkeys.de> <3404.1334087055.971582@puncture> <4F848F80.5010709@stpeter.im> In-Reply-To: <4F848F80.5010709@stpeter.im> MIME-Version: 1.0 Message-Id: <3404.1334090235.352128@puncture> Date: Tue, 10 Apr 2012 21:37:15 +0100 From: Dave Cridland To: Peter Saint-Andre , Florian Zeitz , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:37:28 -0000 On Tue Apr 10 20:52:32 2012, Peter Saint-Andre wrote: > Section 4.7.5 says: > > The inclusion of the version attribute set to a value of at least > "1.0" signals support for the stream-related protocols defined in > this specification, including TLS negotiation (Section 5), SASL > negotiation (Section 6), stream features (Section 4.3.2), and > stream > errors (Section 4.9). > > So not including the version attribute indicates that you don't > support > stream errors; immediately sending a stream error after that seems > odd. Hmmm... Trouble is, I suspect too many things expect a features block after the header, and I've certainly seen clients crash when faced with empty features - and sending features beyond empty seems wasteful. So I'll back down from "clearly", yes - but I think I'll stand by my position for now at least - partly because I'm pretty sure that there are XMPP entities capable of understanding stream errors but not features... If we need to have a version, I'd really rather send features. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From justin@affinix.com Tue Apr 10 13:51:12 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3318E11E8149 for ; Tue, 10 Apr 2012 13:51:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY9YQC7vD8QC for ; Tue, 10 Apr 2012 13:51:11 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 83E3711E8148 for ; Tue, 10 Apr 2012 13:51:11 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 1962F51C070 for ; Tue, 10 Apr 2012 13:51:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=affinix.com; h=from:to:subject :date:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; q=dns; s=affinix.com; b=q f3y3IYPH7kVG9uabDEtcN1XoDzxO9bcYQVwrq0333tSPUciApsfqNiiIHPvnjGm7 IiLpEaYQDZNN6a6PsN3Kb3d8qE7ntNeeucRpEVFCaGjrpbI7VJ/U8w1ew/E93Tk9 p5MVJicNbkBZigwC6zDjgujSjpk6C5a/Y8XefRYf3A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=affinix.com; h=from:to :subject:date:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; s=affinix.com; bh=7/dhFzs hMRn2B71yDfssevzf/JM=; b=EnWqrG+aRGg/HI6YE5TX1pEkGxr0ffFvfCYW24k I/FD9U/Wcyff6i5siP9LAZGhgerTA+36dK2Lj8gmRo3ooYoxx8TOMHiVpTuBhu2P f97zjFE7N054fE5O1BrS+wKNYlR3w8y8X3bqqDwf5AZ7xRNykdNCnxlY5wfvfBTu yGs0= Received: from purelace.localnet (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: justin@affinix.com) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id 090C151C063 for ; Tue, 10 Apr 2012 13:51:11 -0700 (PDT) From: Justin Karneges To: xmpp@ietf.org Date: Tue, 10 Apr 2012 13:51:06 -0700 User-Agent: KMail/1.13.6 (Linux/2.6.38-13-generic; KDE/4.6.5; x86_64; ; ) References: <4F508095.50104@mail.symlynx.com> <4F848F80.5010709@stpeter.im> <3404.1334090235.352128@puncture> In-Reply-To: <3404.1334090235.352128@puncture> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204101351.07103.justin@affinix.com> Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:51:12 -0000 On Tuesday, April 10, 2012 01:37:15 PM Dave Cridland wrote: > On Tue Apr 10 20:52:32 2012, Peter Saint-Andre wrote: > > Section 4.7.5 says: > > The inclusion of the version attribute set to a value of at least > > "1.0" signals support for the stream-related protocols defined in > > this specification, including TLS negotiation (Section 5), SASL > > negotiation (Section 6), stream features (Section 4.3.2), and > > > > stream > > > > errors (Section 4.9). > > > > So not including the version attribute indicates that you don't > > support > > stream errors; immediately sending a stream error after that seems > > odd. > > Hmmm... > > Trouble is, I suspect too many things expect a features block after > the header, and I've certainly seen clients crash when faced with > empty features - and sending features beyond empty seems wasteful. > > So I'll back down from "clearly", yes - but I think I'll stand by my > position for now at least - partly because I'm pretty sure that there > are XMPP entities capable of understanding stream errors but not > features... > > If we need to have a version, I'd really rather send features. The issue here seems to be the possibility of implementations unable to process a stream error while waiting for stream features. As a worst case, I would think even if there exist implementations incapable of handling this properly, they might handle this in some acceptably improper way, such as considering it to be invalid protocol or to be a random disconnect. The true reason for error is lost in this case, which could cause some problems, but in practice I wonder they'd be. Maybe mishandling of "host- unknown" or "conflict" ? Any others? Justin From stpeter@stpeter.im Tue Apr 10 13:51:34 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF3E21F8531 for ; Tue, 10 Apr 2012 13:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.688 X-Spam-Level: X-Spam-Status: No, score=-102.688 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Q7mPD360DZGJ for ; Tue, 10 Apr 2012 13:51:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3C01521F852E for ; Tue, 10 Apr 2012 13:51:34 -0700 (PDT) Received: from dhcp-64-101-72-235.cisco.com (unknown [64.101.72.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 84C3640058; Tue, 10 Apr 2012 15:05:22 -0600 (MDT) Message-ID: <4F849D54.80709@stpeter.im> Date: Tue, 10 Apr 2012 14:51:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Dave Cridland References: <4F508095.50104@mail.symlynx.com> <4F84593F.9010503@mail.symlynx.com> <3404.1334074340.382261@puncture> <201204100934.44412.justin@affinix.com> <4F846944.2040801@stpeter.im> <4F847373.4090700@babelmonkeys.de> <3404.1334087055.971582@puncture> <4F848F80.5010709@stpeter.im> <3404.1334090235.352128@puncture> In-Reply-To: <3404.1334090235.352128@puncture> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:51:35 -0000 On 4/10/12 2:37 PM, Dave Cridland wrote: > On Tue Apr 10 20:52:32 2012, Peter Saint-Andre wrote: >> Section 4.7.5 says: >> >> The inclusion of the version attribute set to a value of at least >> "1.0" signals support for the stream-related protocols defined in >> this specification, including TLS negotiation (Section 5), SASL >> negotiation (Section 6), stream features (Section 4.3.2), and stream >> errors (Section 4.9). >> >> So not including the version attribute indicates that you don't support >> stream errors; immediately sending a stream error after that seems odd. > > Hmmm... > > Trouble is, I suspect too many things expect a features block after the > header, and I've certainly seen clients crash when faced with empty > features Submit a bug report? > - and sending features beyond empty seems wasteful. > > So I'll back down from "clearly", yes - but I think I'll stand by my > position for now at least - partly because I'm pretty sure that there > are XMPP entities capable of understanding stream errors but not > features... > > If we need to have a version, I'd really rather send features. OK, so: what about about sending empty features in these cases of immediate stream close? The receiving entity isn't offering any features then anyway, because it's immediately closing the stream with an error. Peter -- Peter Saint-Andre https://stpeter.im/ From justin@affinix.com Tue Apr 10 13:57:37 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653B221F860D for ; Tue, 10 Apr 2012 13:57:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vov5OnSBMg2B for ; Tue, 10 Apr 2012 13:57:36 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id DDDD721F85AF for ; Tue, 10 Apr 2012 13:57:36 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 77571208071 for ; Tue, 10 Apr 2012 13:57:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=affinix.com; h=from:to:subject :date:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; q=dns; s=affinix.com; b=j Y7vtAovF3uIsaEd2jOxTQ2BPGmwOZ5/w9DUxhEP4n0x1hx6gYTNrzLHjvXplu+cB ONMmCRQJUo6XhEH9F0HRRMu6Ft/NzA4xI7uP8u2mzfgWp6bkbA0PcGGBral2VVuh gqAqbkL1wAc6/GtrtjNE6msX4OeWTTYoF3t/q694WU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=affinix.com; h=from:to :subject:date:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; s=affinix.com; bh=UAKA01Y 4pV/tSxNDyK0sLT7GFec=; b=DWH4GVSfzYzTifYQzWOn6bnpbCfOkMwyCKTxC6v KSuvJaUXu9+OkIMhfcJV4GoAIpnXmhjtJ0tzLIN5FJ8x7tYIiMh3Sk29dZqbjgTH q3GuvulNgAi4cIq9w9C0rocYPaifGpSzzRFHLYWFOBCeA6T5s+JM+TA2v3lnqPgC 1hE4= Received: from purelace.localnet (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: justin@affinix.com) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPSA id 4DE9920806D for ; Tue, 10 Apr 2012 13:57:36 -0700 (PDT) From: Justin Karneges To: xmpp@ietf.org Date: Tue, 10 Apr 2012 13:57:33 -0700 User-Agent: KMail/1.13.6 (Linux/2.6.38-13-generic; KDE/4.6.5; x86_64; ; ) References: <4F508095.50104@mail.symlynx.com> <3404.1334090235.352128@puncture> <201204101351.07103.justin@affinix.com> In-Reply-To: <201204101351.07103.justin@affinix.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204101357.33339.justin@affinix.com> Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:57:37 -0000 On Tuesday, April 10, 2012 01:51:06 PM Justin Karneges wrote: > On Tuesday, April 10, 2012 01:37:15 PM Dave Cridland wrote: > > On Tue Apr 10 20:52:32 2012, Peter Saint-Andre wrote: > > > Section 4.7.5 says: > > > The inclusion of the version attribute set to a value of at least > > > "1.0" signals support for the stream-related protocols defined in > > > this specification, including TLS negotiation (Section 5), SASL > > > negotiation (Section 6), stream features (Section 4.3.2), and > > > > > > stream > > > > > > errors (Section 4.9). > > > > > > So not including the version attribute indicates that you don't > > > support > > > stream errors; immediately sending a stream error after that seems > > > odd. > > > > Hmmm... > > > > Trouble is, I suspect too many things expect a features block after > > the header, and I've certainly seen clients crash when faced with > > empty features - and sending features beyond empty seems wasteful. > > > > So I'll back down from "clearly", yes - but I think I'll stand by my > > position for now at least - partly because I'm pretty sure that there > > are XMPP entities capable of understanding stream errors but not > > features... > > > > If we need to have a version, I'd really rather send features. > > The issue here seems to be the possibility of implementations unable to > process a stream error while waiting for stream features. > > As a worst case, I would think even if there exist implementations > incapable of handling this properly, they might handle this in some > acceptably improper way, such as considering it to be invalid protocol or > to be a random disconnect. The true reason for error is lost in this case, > which could cause some problems, but in practice I wonder they'd be. Maybe > mishandling of "host- unknown" or "conflict" ? Any others? Also, it seems Prosody puts version 1.0 on stream errors even if there are no stream features. I tested this just now with Psi by trying to connect to an unknown domain against a manually specified server. Also, Psi correctly picks this up as a host-unknown error in the UI. I suspect that clients have had to deal with this behavior in the wild now for awhile, and don't rely on a stream features arriving. Justin From dave@cridland.net Tue Apr 10 13:57:59 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C6221F860D for ; Tue, 10 Apr 2012 13:57:59 -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=[AWL=0.000, BAYES_00=-2.599] 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 OGw22PcJP5gv for ; Tue, 10 Apr 2012 13:57:59 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id ECD0521F85AF for ; Tue, 10 Apr 2012 13:57:58 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 094131168087; Tue, 10 Apr 2012 21:57:58 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mp47Z7t39pml; Tue, 10 Apr 2012 21:57:55 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 83D5A1168067; Tue, 10 Apr 2012 21:57:55 +0100 (BST) References: <4F508095.50104@mail.symlynx.com> <4F84593F.9010503@mail.symlynx.com> <3404.1334074340.382261@puncture> <201204100934.44412.justin@affinix.com> <4F846944.2040801@stpeter.im> <4F847373.4090700@babelmonkeys.de> <3404.1334087055.971582@puncture> <4F848F80.5010709@stpeter.im> <3404.1334090235.352128@puncture> <4F849D54.80709@stpeter.im> In-Reply-To: <4F849D54.80709@stpeter.im> MIME-Version: 1.0 Message-Id: <3404.1334091475.550619@puncture> Date: Tue, 10 Apr 2012 21:57:55 +0100 From: Dave Cridland To: Peter Saint-Andre , Florian Zeitz , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:57:59 -0000 On Tue Apr 10 21:51:32 2012, Peter Saint-Andre wrote: > OK, so: what about about sending empty features in these cases of > immediate stream close? The receiving entity isn't offering any > features > then anyway, because it's immediately closing the stream with an > error. I could go along with that, yes, but I'd like to look at the extent of the "empty features" issue. If it's just one client I'm happy. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From mamille2@cisco.com Tue Apr 10 14:34:46 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E3721F866E for ; Tue, 10 Apr 2012 14:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8] 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 oWgolDtAtcPt for ; Tue, 10 Apr 2012 14:34:45 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 58ABE21F8663 for ; Tue, 10 Apr 2012 14:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=7050; q=dns/txt; s=iport; t=1334093685; x=1335303285; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=MRrWsjkFo8e7Lph8V7zTbv4tqZPdr6DFyvv6T+hycpA=; b=ahNatyaraf5FW8mlIo2OaWY5FkJbqbZTHtUWuSd8exRGBMdBZOgM33io RYzwV8lpnBKferjV9gInVyRdNKzozcS5CFNa0FDMc+YKNOGj5H/LNMr65 oV6fptu8WubUQ90nzeqtkoRrTT9q/LKkG0G9scGssIbRn4ckmXubIqkOm 8=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOemhE+rRDoH/2dsb2JhbABFuTuBB4IJAQEBAwESAWYFCwsYLgJVBhMih2cEAZpZoDOPfmMEiFqGEocAjk2BaYMG X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="sig'?p7s'?scan'208";a="36814407" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 10 Apr 2012 21:34:44 +0000 Received: from dhcp-64-101-72-210.cisco.com (dhcp-64-101-72-210.cisco.com [64.101.72.210]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3ALYitS013422; Tue, 10 Apr 2012 21:34:44 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-60--695801818" From: Matt Miller In-Reply-To: <201204101357.33339.justin@affinix.com> Date: Tue, 10 Apr 2012 15:34:43 -0600 Message-Id: References: <4F508095.50104@mail.symlynx.com> <3404.1334090235.352128@puncture> <201204101351.07103.justin@affinix.com> <201204101357.33339.justin@affinix.com> To: Justin Karneges Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: xmpp@ietf.org Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:34:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-60--695801818 Content-Type: multipart/signed; boundary=Apple-Mail-59--695801839; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-59--695801839 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 10, 2012, at 14:57, Justin Karneges wrote: > On Tuesday, April 10, 2012 01:51:06 PM Justin Karneges wrote: >> On Tuesday, April 10, 2012 01:37:15 PM Dave Cridland wrote: >>> On Tue Apr 10 20:52:32 2012, Peter Saint-Andre wrote: >>>> Section 4.7.5 says: >>>> The inclusion of the version attribute set to a value of at least >>>> "1.0" signals support for the stream-related protocols defined in >>>> this specification, including TLS negotiation (Section 5), SASL >>>> negotiation (Section 6), stream features (Section 4.3.2), and >>>>=20 >>>> stream >>>>=20 >>>> errors (Section 4.9). >>>>=20 >>>> So not including the version attribute indicates that you don't >>>> support >>>> stream errors; immediately sending a stream error after that seems >>>> odd. >>>=20 >>> Hmmm... >>>=20 >>> Trouble is, I suspect too many things expect a features block after >>> the header, and I've certainly seen clients crash when faced with >>> empty features - and sending features beyond empty seems wasteful. >>>=20 >>> So I'll back down from "clearly", yes - but I think I'll stand by my >>> position for now at least - partly because I'm pretty sure that = there >>> are XMPP entities capable of understanding stream errors but not >>> features... >>>=20 >>> If we need to have a version, I'd really rather send features. >>=20 >> The issue here seems to be the possibility of implementations unable = to >> process a stream error while waiting for stream features. >>=20 >> As a worst case, I would think even if there exist implementations >> incapable of handling this properly, they might handle this in some >> acceptably improper way, such as considering it to be invalid = protocol or >> to be a random disconnect. The true reason for error is lost in this = case, >> which could cause some problems, but in practice I wonder they'd be. = Maybe >> mishandling of "host- unknown" or "conflict" ? Any others? >=20 > Also, it seems Prosody puts version 1.0 on stream errors even if there = are no=20 > stream features. I tested this just now with Psi by trying to connect = to an=20 > unknown domain against a manually specified server. Also, Psi = correctly picks=20 > this up as a host-unknown error in the UI. >=20 > I suspect that clients have had to deal with this behavior in the wild = now for=20 > awhile, and don't rely on a stream features arriving. >=20 Basically this. All of the clients I've worked on have had to deal with = an opened stream, no features, and a stream:error. - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-59--695801839 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMDIxMzQ0 NFowIwYJKoZIhvcNAQkEMRYEFJFvlJCL+yAmhRO3x97sASr7+8DMMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQCgsSOW5NnzeRaTEU1HfjtkoUQOUgtKDgj2TTr2e+nKBdfe9fwS99uElSyO hfoJM07NB3jszVZHNf6tQoG0g3Shx23TISTiRP0Ej3iaVMrFufWKSqZvS6yaky3RfeXTEEwRTawI lL0v7fZK0ozhrUAi4KiLDXYLEp2fwhtFLSOzG5Y9D4L31LhHeNPjlBsRep0IDXUEWEpvq6rFAVri 8Bl1YCtv4T4pJ8/PhjtG8Y6oVndqr5VErgOCcD9gZKX6Nf/YLjvabvMa23sYURcAo2hZADN11ZKR qArgOlR0MABsFh6cBKyz9mI19igyN2AVxciKx1I675IAceY1u45/7c5/AAAAAAAA --Apple-Mail-59--695801839-- --Apple-Mail-60--695801818 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPhKd0AAoJEJq6Ou0cgrSPU+YH/j3qA1v0JwFXOO2Ya+telmdE 9f4tiMnbENP1E5fo4BSwP0JXbhZItw6Zx38WbEpVEHd92bnQB+qpGa4yBe5lc/tv 3fRQDjeycyRdupmxvSkziXYTvtYnVZoqAKaU31QtjN7VbSRZMgaUcc1n1N1olnng i3mZ/xmjPyHGjqjGLL1LmhhYgNSWC76VhUiINHgdUnQbQLPI7iVF6ENt2AsOnzzg zKi95dIoCUdYQIktaMhmB5wS088tgvrsT7+AYom8x7HxdxwNkXpwGI/+Zbf8yCMu vD3IG+eNT71P2AHsMgdgTOaff/gQfS7RLLIqXv7vGvAz7enVxk6PHnhBfvrLjQM= =39SF -----END PGP SIGNATURE----- --Apple-Mail-60--695801818-- From florob@babelmonkeys.de Tue Apr 10 17:33:38 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE1411E812C for ; Tue, 10 Apr 2012 17:33:38 -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=[AWL=-0.000, BAYES_00=-2.599] 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 X2Jh5A67qRlk for ; Tue, 10 Apr 2012 17:33:36 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE7511E8081 for ; Tue, 10 Apr 2012 17:33:36 -0700 (PDT) Received: from xdsl-87-79-136-69.netcologne.de ([87.79.136.69] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SHlV8-0001Ww-3F; Wed, 11 Apr 2012 02:33:34 +0200 Message-ID: <4F84D157.8060201@babelmonkeys.de> Date: Wed, 11 Apr 2012 02:33:27 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120406 Thunderbird/11.0.1 MIME-Version: 1.0 To: Dave Cridland References: <4F508095.50104@mail.symlynx.com> <4F84593F.9010503@mail.symlynx.com> <3404.1334074340.382261@puncture> <201204100934.44412.justin@affinix.com> <4F846944.2040801@stpeter.im> <4F847373.4090700@babelmonkeys.de> <3404.1334087055.971582@puncture> <4F848F80.5010709@stpeter.im> <3404.1334090235.352128@puncture> <4F849D54.80709@stpeter.im> <3404.1334091475.550619@puncture> In-Reply-To: <3404.1334091475.550619@puncture> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: XMPP Working Group Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 00:33:38 -0000 Am 10.04.2012 22:57, schrieb Dave Cridland: > On Tue Apr 10 21:51:32 2012, Peter Saint-Andre wrote: >> OK, so: what about about sending empty features in these cases of >> immediate stream close? The receiving entity isn't offering any features >> then anyway, because it's immediately closing the stream with an error. > > I could go along with that, yes, but I'd like to look at the extent of > the "empty features" issue. If it's just one client I'm happy. > I think I need some clarification on what we're actually trying to accomplish here. As I have not seen a real world example yet, I'm going to assume we're designing for a hypothetical client (that may or may not exist in reality). That hypothetical client would expect a features block if it sees a version attribute in the stream header. The implication being it does not actually look at the name of the first element it receives. What I'm not clear on is what this hypothetical client does when it doesn't receive a version attribute. Does it act more intelligently and check whether the element's name is "error" or "feature"? Does it blindly assume it is an "error" element? In either case I'm under the impression that just looking at the element's name instead of relying on the existence of the version attribute is a far more intuitive implementation. As such I'd be very surprised to see a client that does not choose this way to implement it. Also we have text that mandates the inclusion of the version attribute: «The receiving entity MUST set the value of the 'version' attribute in the response stream header to either the value supplied by the initiating entity or the highest version number supported by the receiving entity, whichever is lower» As such I consider both, not including features, as well as, not including a version attribute in violation of the RFC. That, from a protocol standpoint, would imply sending a version and empty features. However, accommodating current implementations, I too have seen implementations that will not play nicely with empty features, I have however not yet witnessed an implementation that would not accept an error when the version attribute was specified. Regards, Florian Zeitz From justin@affinix.com Tue Apr 10 18:13:41 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058BF11E811A for ; Tue, 10 Apr 2012 18:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_65=0.6] 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 KSFAWCXm4wkM for ; Tue, 10 Apr 2012 18:13:40 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC6911E8081 for ; Tue, 10 Apr 2012 18:13:40 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id E04F134806E for ; Tue, 10 Apr 2012 18:13:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=affinix.com; h=from:to:subject :date:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; q=dns; s=affinix.com; b=p psop4Fia1AFx2OKPDqSoMxTp3NGfmq5wXktuxFS7OVApdPUDW5GnDl92L0GtHC0x 5Xx5ZbUnlf4z/50g99u0ZKUKtDE+LSwqZXbT7yC6Sz/byfuZWxd7t7MgpyQ3ngTU u/l386srYv0PRAsQPJ4aWFYX0lcNgz75kxnZZe7y5I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=affinix.com; h=from:to :subject:date:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; s=affinix.com; bh=1dyUbZi tBCxh+daGuse+o5wzFco=; b=oWDEVT5TT5HSktipk2ubSmDL7O6KvfLdicgI9cu AcMlVfEZ0QpNn87aXZ9kJIMWmDOpJ5IdajebpVIaRvYKMMpA2sfFU/Adj2E0ctvF dHq5XTMOM6xp2hTmVVSeWkaqC2Nuomc+r0XlM4Yk6qWFlEyAoB1UuaGmuSKsqTve DPzY= Received: from purelace.localnet (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: justin@affinix.com) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPSA id D400F34806B for ; Tue, 10 Apr 2012 18:13:39 -0700 (PDT) From: Justin Karneges To: xmpp@ietf.org Date: Tue, 10 Apr 2012 18:13:36 -0700 User-Agent: KMail/1.13.6 (Linux/2.6.38-13-generic; KDE/4.6.5; x86_64; ; ) References: <4F508095.50104@mail.symlynx.com> <3404.1334091475.550619@puncture> <4F84D157.8060201@babelmonkeys.de> In-Reply-To: <4F84D157.8060201@babelmonkeys.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204101813.36462.justin@affinix.com> Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 01:13:41 -0000 On Tuesday, April 10, 2012 05:33:27 PM Florian Zeitz wrote: > However, accommodating current implementations, I too have seen > implementations that will not play nicely with empty features, I have > however not yet witnessed an implementation that would not accept an > error when the version attribute was specified. Good point. Sending an empty features list to a client seems sketchy, and there's a good chance the client would throw an error about encountering invalid protocol before it would have a chance to read the stream:error that follows. Looking at the code for Psi, it would appear that if an empty features element is receved then it will switch to legacy auth mode and immediately send an iq for jabber:iq:auth. This works because starttls is optional, and bind doesn't matter unless SASL is used and completed. A client not supporting legacy auth would almost surely complain about the lack of SASL mechanisms and fail early though. Justin From dave@cridland.net Wed Apr 11 00:42:05 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B4F21F858F for ; Wed, 11 Apr 2012 00:42:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJF8SFP3iwCV for ; Wed, 11 Apr 2012 00:42:04 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 19F2321F858E for ; Wed, 11 Apr 2012 00:42:03 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 473EC1168087; Wed, 11 Apr 2012 08:41:57 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDVgmcx39kdt; Wed, 11 Apr 2012 08:41:53 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 214851168067; Wed, 11 Apr 2012 08:41:53 +0100 (BST) References: <4F508095.50104@mail.symlynx.com> <4F84593F.9010503@mail.symlynx.com> <3404.1334074340.382261@puncture> <201204100934.44412.justin@affinix.com> <4F846944.2040801@stpeter.im> <4F847373.4090700@babelmonkeys.de> <3404.1334087055.971582@puncture> <4F848F80.5010709@stpeter.im> <3404.1334090235.352128@puncture> <4F849D54.80709@stpeter.im> <3404.1334091475.550619@puncture> <4F84D157.8060201@babelmonkeys.de> In-Reply-To: <4F84D157.8060201@babelmonkeys.de> MIME-Version: 1.0 Message-Id: <3404.1334130113.118335@puncture> Date: Wed, 11 Apr 2012 08:41:53 +0100 From: Dave Cridland To: Florian Zeitz , Peter Saint-Andre , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 07:42:05 -0000 On Wed Apr 11 01:33:27 2012, Florian Zeitz wrote: > Am 10.04.2012 22:57, schrieb Dave Cridland: > > On Tue Apr 10 21:51:32 2012, Peter Saint-Andre wrote: > >> OK, so: what about about sending empty features in these cases of > >> immediate stream close? The receiving entity isn't offering any > features > >> then anyway, because it's immediately closing the stream with an > error. > > > > I could go along with that, yes, but I'd like to look at the > extent of > > the "empty features" issue. If it's just one client I'm happy. > > > I think I need some clarification on what we're actually trying to > accomplish here. > > As I have not seen a real world example yet, I'm going to assume > we're > designing for a hypothetical client (that may or may not exist in > reality). > > I'm mostly concerned with servers. Diagnosing S2S failure is much, much harder than diagnosing C2S failure as it is. > That hypothetical client would expect a features block if it sees a > version attribute in the stream header. > The implication being it does not actually look at the name of the > first > element it receives. > > No, that's not the implication. The implication is that its code paths rely on features being the first element, and it fails to handle any other case. You do indeed describe one possible case. This is reasonable behaviour according to the specification, I'd remind you - we have made a guarantee that an initiator will see a features element directly after the stream header. Changing that effectively means pulling the rug out from under those implementations. > What I'm not clear on is what this hypothetical client does when it > doesn't receive a version attribute. > Does it act more intelligently and check whether the element's name > is > "error" or "feature"? Does it blindly assume it is an "error" > element? > > It won't be expecting an error. What'll likely happen is it'll check for the dialback namespace declaration, and probably start trying dialback regardless of whether it finds one - and find the error "in response". Since in practise most servers understand stream errors even if they only do 0.9 on S2S, because they already do 1.0 on C2S (think Tigase, Openfire, Google...) then they'll handle the case fine. Sorry, did you want to stick with hypothetical implementations? > In either case I'm under the impression that just looking at the > element's name instead of relying on the existence of the version > attribute is a far more intuitive implementation. As such I'd be > very > surprised to see a client that does not choose this way to > implement it. > > Be surprised about servers, then. I'm not claiming that servers which fall foul of the "got version, expect features, ignore error" are very good implementations, or indeed that you (or I) would write one this way. But the reality is that such implementations are within the specification as it is currently written, and if there's a way of addressing the issue *without* changing the behaviour this seems the best path. > Also we have text that mandates the inclusion of the version > attribute: > «The receiving entity MUST set the value of the 'version' attribute > in > the response stream header to either the value supplied by the > initiating entity or the highest version number supported by the > receiving entity, whichever is lower» > > Only if you're intending speaking XMPP. > As such I consider both, not including features, as well as, not > including a version attribute in violation of the RFC. > That, from a protocol standpoint, would imply sending a version and > empty features. > However, accommodating current implementations, I too have seen > implementations that will not play nicely with empty features, I > have > however not yet witnessed an implementation that would not accept an > error when the version attribute was specified. I can believe that of clients. In any case, I think if you do want to go this route, the correct fix is to state that a responding stream header MUST be followed by either a features or an error element. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From ralphm@ik.nu Wed Apr 11 03:09:34 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799CF21F866A for ; Wed, 11 Apr 2012 03:09:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxVGkTUOYmQD for ; Wed, 11 Apr 2012 03:09:34 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [IPv6:2001:16f8:4::61]) by ietfa.amsl.com (Postfix) with ESMTP id 55E5A21F8647 for ; Wed, 11 Apr 2012 03:09:31 -0700 (PDT) Received: from mag.ik.nu (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id 4A498A1031 for ; Wed, 11 Apr 2012 12:09:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at ik.nu Received: from mag.ik.nu ([127.0.0.1]) by mag.ik.nu (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id nDfu+g8G-W2f for ; Wed, 11 Apr 2012 12:09:28 +0200 (CEST) Received: from [192.168.3.103] (unknown [83.117.22.112]) by mag.ik.nu (Postfix) with ESMTPSA id 81C96A100F for ; Wed, 11 Apr 2012 12:09:28 +0200 (CEST) Message-ID: <4F855857.7090007@ik.nu> Date: Wed, 11 Apr 2012 12:09:27 +0200 From: Ralph Meijer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120402 Thunderbird/11.0.1 MIME-Version: 1.0 To: xmpp@ietf.org References: <4F508095.50104@mail.symlynx.com> <4F84593F.9010503@mail.symlynx.com> <3404.1334074340.382261@puncture> <201204100934.44412.justin@affinix.com> <4F846944.2040801@stpeter.im> <4F847373.4090700@babelmonkeys.de> <3404.1334087055.971582@puncture> <4F848F80.5010709@stpeter.im> <3404.1334090235.352128@puncture> <4F849D54.80709@stpeter.im> <3404.1334091475.550619@puncture> <4F84D157.8060201@babelmonkeys.de> <3404.1334130113.118335@puncture> In-Reply-To: <3404.1334130113.118335@puncture> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 10:09:34 -0000 On 2012-04-11 09:41, Dave Cridland wrote: > [..] > In any case, I think if you do want to go this route, the correct fix i= s > to state that a responding stream header MUST be followed by either a > features or an error element. =85 or nothing, closing the connection with or without a "". That seems good to me. I don't see any value in sending an empty=20 features element at all. As it is now, this is really sending the wrong=20 message, too. From RFC 6120, section 4.3.2: The element can contain one child, contain multiple children, or be empty. and: An empty element indicates that the stream negotiation is complete and that the initiating entity is cleared to send XML stanzas. I think that we can agree that entities that cannot cope with an empty=20 features element are broken. I'm ok with them treating the combination=20 with an error element and a connection close as a 'random' lost connectio= n. --=20 ralphm From mwild1@gmail.com Wed Apr 11 07:16:27 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B8211E809C for ; Wed, 11 Apr 2012 07:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] 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 J9c8ipDmcaTU for ; Wed, 11 Apr 2012 07:16:26 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B6B9111E8088 for ; Wed, 11 Apr 2012 07:16:26 -0700 (PDT) Received: by ghbg16 with SMTP id g16so504209ghb.31 for ; Wed, 11 Apr 2012 07:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=DnOPJZObB4Gh9Gypk8+eVmV0hj/ANFFtQ6fMqb9KsLU=; b=UNL9LzLqVVMMW5fNj6l5OgOh0iF7nlK2/7Tq9NSSmwwbONFHQ0P9qkpD/0XNEF2Fnc 7QzreYxMSRXd8BCZR5zS4QMSPt0YzPpKn6MPpPIMs9W6l3tv2jGs5ZcQXQsvsDMq0s1T Egt/+mRwkVo9H8vdmL76q/9tGl/g4Rlq5j57HSuHsen7Gm3RF/y1+C2eRhlNxH33I/CZ SQUEslA8B/nQeKA5pnNEYft+y41w0TBoJBlU+xJ3t7+hyDKHw9uKI9CiablLrJyQw+De vhvf+NHv3yW30cqU5rqRlnkhpePb03fbCf1KH7t4vUko7Q7qBh0IZBvHz2NRu+h/GaDg w49g== Received: by 10.50.85.232 with SMTP id k8mr2290193igz.16.1334153786227; Wed, 11 Apr 2012 07:16:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.173.74 with HTTP; Wed, 11 Apr 2012 07:16:04 -0700 (PDT) In-Reply-To: <201204101357.33339.justin@affinix.com> References: <4F508095.50104@mail.symlynx.com> <3404.1334090235.352128@puncture> <201204101351.07103.justin@affinix.com> <201204101357.33339.justin@affinix.com> From: Matthew Wild Date: Wed, 11 Apr 2012 15:16:04 +0100 Message-ID: To: Justin Karneges Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: xmpp@ietf.org Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:16:27 -0000 On 10 April 2012 21:57, Justin Karneges wrote: > On Tuesday, April 10, 2012 01:51:06 PM Justin Karneges wrote: >> On Tuesday, April 10, 2012 01:37:15 PM Dave Cridland wrote: >> > On Tue Apr 10 20:52:32 2012, Peter Saint-Andre wrote: >> > > Section 4.7.5 says: >> > > =C2=A0 =C2=A0The inclusion of the version attribute set to a value o= f at least >> > > =C2=A0 =C2=A0"1.0" signals support for the stream-related protocols = defined in >> > > =C2=A0 =C2=A0this specification, including TLS negotiation (Section = 5), SASL >> > > =C2=A0 =C2=A0negotiation (Section 6), stream features (Section 4.3.2= ), and >> > > >> > > stream >> > > >> > > =C2=A0 =C2=A0errors (Section 4.9). >> > > >> > > So not including the version attribute indicates that you don't >> > > support >> > > stream errors; immediately sending a stream error after that seems >> > > odd. >> > >> > Hmmm... >> > >> > Trouble is, I suspect too many things expect a features block after >> > the header, and I've certainly seen clients crash when faced with >> > empty features - and sending features beyond empty seems wasteful. >> > >> > So I'll back down from "clearly", yes - but I think I'll stand by my >> > position for now at least - partly because I'm pretty sure that there >> > are XMPP entities capable of understanding stream errors but not >> > features... >> > >> > If we need to have a version, I'd really rather send features. >> >> The issue here seems to be the possibility of implementations unable to >> process a stream error while waiting for stream features. >> >> As a worst case, I would think even if there exist implementations >> incapable of handling this properly, they might handle this in some >> acceptably improper way, such as considering it to be invalid protocol o= r >> to be a random disconnect. The true reason for error is lost in this cas= e, >> which could cause some problems, but in practice I wonder they'd be. May= be >> mishandling of "host- unknown" or "conflict" ? Any others? > > Also, it seems Prosody puts version 1.0 on stream errors even if there ar= e no > stream features. I tested this just now with Psi by trying to connect to = an > unknown domain against a manually specified server. Also, Psi correctly p= icks > this up as a host-unknown error in the UI. > Indeed. In my view a stream:error can happen anywhere, including before stream:features. I don't really understand what the fuss is about here. Regards, Matthew From mamille2@cisco.com Wed Apr 11 07:30:10 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A5711E807F for ; Wed, 11 Apr 2012 07:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8] 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 uD3vPjQXfIBi for ; Wed, 11 Apr 2012 07:30:09 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C6C8811E8072 for ; Wed, 11 Apr 2012 07:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=4686; q=dns/txt; s=iport; t=1334154609; x=1335364209; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=pc6jb3gMAV7V0GcXhMZqkPllygVwNA8SQslRHXl5EzI=; b=l67xeNNlrZbB6s3gK15XMH/6qhBkgEtYAMEu9reNnAQM7Qtut1wT/a2C nAat5gF3R9yzNzkt3IPt+rT+izOiNkjrRB+dJuLvtDpGQYLLX6sLEcybz loXaNGJPNC6wHx9K4P/Kh02Du199MbZuhtHiLacotruJBHLxBM4AzO6s5 Y=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI2UhU+rRDoI/2dsb2JhbABCuVuBB4IJAQEBAwESAWYFCwsOOAJVBhMih2cEAZ8CmEWQY2MEiFqGEocAjk2BaYMG X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="sig'?p7s'?scan'208";a="40022723" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 11 Apr 2012 14:30:09 +0000 Received: from dhcp-64-101-72-210.cisco.com (dhcp-64-101-72-210.cisco.com [64.101.72.210]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3BEU9cu002756; Wed, 11 Apr 2012 14:30:09 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-66--634875728" From: Matt Miller In-Reply-To: Date: Wed, 11 Apr 2012 08:30:09 -0600 Message-Id: <1C2C63D9-7C28-4AC6-8613-90BF462B496A@cisco.com> References: <4F508095.50104@mail.symlynx.com> <3404.1334090235.352128@puncture> <201204101351.07103.justin@affinix.com> <201204101357.33339.justin@affinix.com> To: Matthew Wild Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: xmpp@ietf.org Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:30:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-66--634875728 Content-Type: multipart/signed; boundary=Apple-Mail-65--634875749; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-65--634875749 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Apr 11, 2012, at 08:16, Matthew Wild wrote: > Indeed. In my view a stream:error can happen anywhere, including > before stream:features. I don't really understand what the fuss is > about here. > +1 - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-65--634875749 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMTE0MzAx MFowIwYJKoZIhvcNAQkEMRYEFIegrq4GWG/Zlb7acvhOEoPcJGjpMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAgENzq+7F26ScfTzxRk0wxKNlzXp7QejofY4Z2UZZiSYAAy34etT6T1MTe 1SbCFs9vOV/dL/AL/4yK6os9vptTyohwvBXhDt+uvNANzsRzv5l4dZEk1HkuBHVAoB8CcycJ/Hty sSH+PhxTmt3b+nWQNV6b0/c4+p2lqn0z5oz3iq+T5a/x1r/0dhYz4n4xyXXjm13Y6IJViIs1kTWl BBuPjtNaIhTF1wDQ3LMEodfInql0ogC4bCiQrRD1p/pD2Rya7tOGpftcoEpheDM+oq/Fkoq7p5gH gyAq7nLn0d6GHt5Smw8Y9zDY41DIVe2b5MfI7yGIkwBcZrx4n/hS9ZcdAAAAAAAA --Apple-Mail-65--634875749-- --Apple-Mail-66--634875728 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPhZVyAAoJEJq6Ou0cgrSPMPoH/28+F+UfV80ogDYETwXUNUpM iMTi+zaAR49eGWb+KOrDy8s810YppmcztUsddCu2IF28yJus8Vkqd9zPy64NfDgm 6KgYCeiycmmhXHtHKu1b8EDLggl3s7qM0eXK8Aix/hAd0vGu4HS8o9S//5s4U3M6 0V/Y1RbriQQuf9P+kUwYmQkR/EVO7M9swQj7uHm25ptlHFTqPVaJj/ASRJh964tN Q0jQAg0/sv4wNDxAZtnRge9lknjaeralH47dLoXwdomMAuj4C0zTOfJf7dgvqMns Wmefnp/cr58QVRzWIK86e1m3bIibNFmpFMka2ArPY4tVq3DFGjvnYu9p1P+5Nnk= =G34Q -----END PGP SIGNATURE----- --Apple-Mail-66--634875728-- From stpeter@stpeter.im Wed Apr 11 07:38:48 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE02121F85D5 for ; Wed, 11 Apr 2012 07:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] 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 sQ7Q1amyt9qQ for ; Wed, 11 Apr 2012 07:38:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBBD21F85D4 for ; Wed, 11 Apr 2012 07:38:47 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BE0AB40058; Wed, 11 Apr 2012 08:52:37 -0600 (MDT) Message-ID: <4F859766.7030008@stpeter.im> Date: Wed, 11 Apr 2012 08:38:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Matt Miller References: <4F508095.50104@mail.symlynx.com> <3404.1334090235.352128@puncture> <201204101351.07103.justin@affinix.com> <201204101357.33339.justin@affinix.com> <1C2C63D9-7C28-4AC6-8613-90BF462B496A@cisco.com> In-Reply-To: <1C2C63D9-7C28-4AC6-8613-90BF462B496A@cisco.com> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:38:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/11/12 8:30 AM, Matt Miller wrote: > > On Apr 11, 2012, at 08:16, Matthew Wild wrote: > > >> Indeed. In my view a stream:error can happen anywhere, including >> before stream:features. I don't really understand what the fuss >> is about here. > > +1 Right, that's why I proposed adding a bit of wiggle room in the text. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Fl2YACgkQNL8k5A2w/vxxXACg77r4YEv5P5dFZ3vkmQl89GsC xMsAoNrYyXY3w6TWoPez8dJxARkJTklj =2pAS -----END PGP SIGNATURE----- From mamille2@cisco.com Wed Apr 11 07:51:30 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF4111E80CE for ; Wed, 11 Apr 2012 07:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8] 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 knYrmc7jLprh for ; Wed, 11 Apr 2012 07:51:29 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6347F11E80B2 for ; Wed, 11 Apr 2012 07:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=4996; q=dns/txt; s=iport; t=1334155888; x=1335365488; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=AEhVcllroAQqyr7ezEV1JgiiEFJYcr+1wuitrnFsbNg=; b=LgTHZoN6thskkNMHSy5izwmrCB8MhF3POH7XKaVJQaRK4cQ2rmOajaxp IPj8A5VBuaUN6u5IirSVmBWdT6HIsk6ma9Ya9PYH0YUYu+qLcohAe/mzP NO9LjY/Mb75ffEsS4FbQlEp1nRzYL6lUGw7lqIRG5F5+FZiM863+xsL3N A=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD6ahU+rRDoJ/2dsb2JhbABFuU6BB4IJAQEBBBIBZhALGC4CVQYTIodrAZpvoCuQY2MEiFqGEocAjk2BaYMG X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="sig'?p7s'?scan'208";a="39934797" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 11 Apr 2012 14:51:28 +0000 Received: from dhcp-64-101-72-210.cisco.com (dhcp-64-101-72-210.cisco.com [64.101.72.210]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3BEpRr7023861; Wed, 11 Apr 2012 14:51:27 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-68--633597021" From: Matt Miller In-Reply-To: <4F859766.7030008@stpeter.im> Date: Wed, 11 Apr 2012 08:51:28 -0600 Message-Id: <48C958B5-1B3C-4804-811C-0A52645947FD@cisco.com> References: <4F508095.50104@mail.symlynx.com> <3404.1334090235.352128@puncture> <201204101351.07103.justin@affinix.com> <201204101357.33339.justin@affinix.com> <1C2C63D9-7C28-4AC6-8613-90BF462B496A@cisco.com> <4F859766.7030008@stpeter.im> To: Peter Saint-Andre Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: xmpp@ietf.org Subject: Re: [xmpp] host-unknown stream error example in rfc 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:51:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-68--633597021 Content-Type: multipart/signed; boundary=Apple-Mail-67--633597051; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-67--633597051 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Apr 11, 2012, at 08:38, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/11/12 8:30 AM, Matt Miller wrote: >> >> On Apr 11, 2012, at 08:16, Matthew Wild wrote: >> >> >>> Indeed. In my view a stream:error can happen anywhere, including >>> before stream:features. I don't really understand what the fuss >>> is about here. >> >> +1 > > Right, that's why I proposed adding a bit of wiggle room in the text. > Consider this a transitive +1 to the proposal (-: - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-67--633597051 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMTE0NTEy OFowIwYJKoZIhvcNAQkEMRYEFDmBI9mMqrDP/MRo7eLwBTukfhkRMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQB8UzQjujp5Kt7f0mtbbtW9DHJ3MIxkB5OCb7ewszwRIy6G5yYC5+l4FOvn 8viNjEMY+IQt0+gT5DDyptNt4y8X9k3hXNnpQ783fLsDsEn4++VhpbbxUeXVs+fDGuHXR8JKXI4+ 38sWFdz3cItXWJ4oOl1SheMpVMYZMmnwAd/HevXHXTRE7KIpLAuOgC+mw2/+z4Eg1nZExxNGfGT9 X/R+BbAZ+rpnMn3+ep0k8C+bZZep5CVpiyivhMuStIgI/QMh2wOSsTg9tylV+75dlBi/R8oEs9IK 6iH+MRHzAjCb9fxw/sI1HbzAicipxMT1qFWscjRRjUZ16rNT6l7b+YAhAAAAAAAA --Apple-Mail-67--633597051-- --Apple-Mail-68--633597021 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPhZpwAAoJEJq6Ou0cgrSPCZ4H/1W93xkduGtukmvkbjj94dx+ F9ViOmFHj/FLaJqoaanPMUNcxKdfpRZK6IytJy/xV/64JJQ3oRs4F0ZiwZqiu6HV uDI3ZAj9Gwe33K1iPonApOImNTiWHunn0pP6LWzrhPvjobHIRv8e5tJpAecJZAxg K3JeCaxLE3eTIhhQ8+hcYY+pOi6uzW4fczSh+tHjvdFPHTbf1RtimLwwbGc185VK Jk9PjZQLeFyvsIrtwKJy2ueHZcaUZDpQCeodmgZH+ZEOqcOA+OO2YZsveumZFECY Pz34TysnfAlBbGvt3TNG0LuURFDJOGKAGfKsEdNYTEj1AKowdzzTKA1A6y37SuY= =vQrX -----END PGP SIGNATURE----- --Apple-Mail-68--633597021-- From florob@babelmonkeys.de Wed Apr 11 12:15:49 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A38521F84F4 for ; Wed, 11 Apr 2012 12:15:49 -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=[AWL=-0.000, BAYES_00=-2.599] 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 pczYehWyJhXL for ; Wed, 11 Apr 2012 12:15:48 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id BA34921F84EB for ; Wed, 11 Apr 2012 12:15:48 -0700 (PDT) Received: from xdsl-87-79-60-43.netcologne.de ([87.79.60.43] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SI316-000128-Ca for xmpp@ietf.org; Wed, 11 Apr 2012 21:15:44 +0200 Message-ID: <4F85D859.6070102@babelmonkeys.de> Date: Wed, 11 Apr 2012 21:15:37 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120406 Thunderbird/11.0.1 MIME-Version: 1.0 To: XMPP Working Group X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: [xmpp] draft-ietf-xmpp-6122bis-01 feedback X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:15:49 -0000 Hi, as I had promised some time ago, here are some comments based on a full review of draft-ietf-xmpp-6122bis(-01). Section 2.1: I realize it has always been that way, but considering some people try to rely on it I was wondering whether the ABNF should fully specify the requirements for a JID. It currently doesn't convey some aspects, such as length restrictions, or the fact that A-labels are invalid as ifqdn. I'd suggest at least adding some text saying that the ABNF only lays out the basic structure, while other requirements are defined below. The example used in the implementation note is no longer valid, when using NFC, i.e. U+FE6B does not canonically decompose to U+0040. In fact I have not found any characters that are currently canonically decomposable to either '@' or '/'. I still feel the note as such is necessary though to be future-proof. Section 2.2: «The domainpart for every XMPP service MUST be a fully qualified domain name» I have not been able to find a definition of "fully qualified domain name", particularly not in RFC 1035 as the current text suggests. I'm somewhat worried that this could be misinterpreted as "a domain name as stored in DNS", which would imply A-labels I think. Maybe someone more competent than me could comment on this. «In the terms of IDNA2008 [RFC5890], the domainpart of a JID is a "domain name slot".» Maybe we should use the more specific term "IDNA-aware domain name slot" from that RFC? The wording «For the purpose of communication over XMPP» is still used in this section. It should be harmonized with the following sections (I like the new wording by the way). Section 2.2 - 2.4: «With regard to directionality, the "Bidi Rule" provided in [RFC5893] applies.» The Bidi Rule as such only mentions Bidi domain names and doesn't "apply" as such. I'd prefer saying that the conditions therein MUST be fulfilled. Section 3: The conformance requirements mention the rules SHOULD be enforced by clients. This is not reflected in this section as such (as far as I can tell). In particular I'd like to have an implementation note somewhere, reminding client developers that for comparison some normalization can be necessary/helpful. E.g. a client might send a message to one JID, but receive a reply from a normalized version thereof. Interpreting these as separate entities can lead to a bad user experience. Section 5.3.1: Not sure if it is worth mentioning here, but proper TLS certificate checking would mitigate DNS poisoning too. Regards, Florian Zeitz From stpeter@stpeter.im Wed Apr 11 18:38:47 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7514021F845D for ; Wed, 11 Apr 2012 18:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 94ah8w5G8w0U for ; Wed, 11 Apr 2012 18:38:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B34F121F845C for ; Wed, 11 Apr 2012 18:38:42 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9581040058; Wed, 11 Apr 2012 19:52:34 -0600 (MDT) Message-ID: <4F863221.2070901@stpeter.im> Date: Wed, 11 Apr 2012 19:38:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Florian Zeitz References: <4F85D859.6070102@babelmonkeys.de> In-Reply-To: <4F85D859.6070102@babelmonkeys.de> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: XMPP Working Group Subject: Re: [xmpp] draft-ietf-xmpp-6122bis-01 feedback X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 01:38:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/11/12 1:15 PM, Florian Zeitz wrote: > Hi, > > as I had promised some time ago, here are some comments based on a > full review of draft-ietf-xmpp-6122bis(-01). Thanks for the review! > Section 2.1: I realize it has always been that way, but considering > some people try to rely on it I was wondering whether the ABNF > should fully specify the requirements for a JID. I am not a master of ABNF, but I do know that it can be tricky to specify all of the restrictions in ABNF, so I would prefer not to make the attempt. However, as document editor, I will incorporate revised (and accurate) ABNF into the spec if someone else contributes it. > It currently doesn't convey some aspects, such as length > restrictions, or the fact that A-labels are invalid as ifqdn. I'd > suggest at least adding some text saying that the ABNF only lays > out the basic structure, while other requirements are defined > below. That I can easily do. I propose the following change: OLD All JIDs are based on the foregoing structure. NEW All JIDs are based on the foregoing structure. However, note that the foregoing structure does not capture all of the rules and restrictions that apply to JIDs, which are described below. > The example used in the implementation note is no longer valid, > when using NFC, i.e. U+FE6B does not canonically decompose to > U+0040. In fact I have not found any characters that are currently > canonically decomposable to either '@' or '/'. I haven't found any, either. > I still feel the note as such is necessary though to be > future-proof. We could note that currently this occurs under NFKC, not NFC. I propose the following change: OLD Implementation Note: When dividing a JID into its component parts, an implementation needs to match the separator characters '@' and '/' before applying any transformation algorithms, which might decompose certain Unicode code points to the separator characters (e.g., under Unicode Normalization Form KC U+FE6B SMALL COMMERCIAL AT might decompose to U+0040 COMMERCIAL AT). NEW Implementation Note: When dividing a JID into its component parts, an implementation needs to match the separator characters '@' and '/' before applying any transformation algorithms, which might decompose certain Unicode code points to the separator characters (e.g., under Unicode Normalization Form KC U+FE6B SMALL COMMERCIAL AT decomposes to U+0040 COMMERCIAL AT, although this is not true under Unicode Normalization C, which is used in this specification). > Section 2.2: «The domainpart for every XMPP service MUST be a fully > qualified domain name» I have not been able to find a definition of > "fully qualified domain name", particularly not in RFC 1035 as the > current text suggests. I have never been able to find such a definition, either (I looked when Jeff Hodges and I were working on RFC 6125). Would you like to write an Internet-Draft about it? Warning: there be dragons. The closest thing to a definition can be found in RFC 1034 (not 1035), which talks about the concept of an absolute domain name (which is equated to a fully qualified domain name in RFC 1535, see also RFC 1123 with regard to email). However, note that in the DNS, an absolute domain name ends with ".", so pedants might argue that "foo.example.com." is an FQDN whereas "foo.example.com" is not. > I'm somewhat worried that this could be misinterpreted as "a domain > name as stored in DNS", which would imply A-labels I think. Maybe > someone more competent than me could comment on this. I see no reason for such an interpretation. See for example Section 4.2 of RFC 5890: ### 4.2. U-label Lengths Labels associated with the DNS have traditionally been limited to 63 octets by the general restrictions in RFC 1035 and by the need to treat them as a six-bit string length followed by the string in actual calls to the DNS. That format is used in some other applications and, in general, that representations of domain names as dot-separated labels and as length-string pairs have been treated as interchangeable. Because A-labels (the form actually used in the DNS) are potentially much more compressed than UTF-8 (and UTF-8 is, in general, more compressed that UTF-16 or UTF-32), U-labels that obey all of the relevant symmetry (and other) constraints of these documents may be quite a bit longer, potentially up to 252 characters (Unicode code points). A fully-qualified domain name containing several such labels can obviously also exceed the nominal 255 octet limit for such names. Application authors using U-labels must exert due caution to avoid buffer overflow and truncation errors and attacks in contexts where shorter strings are expected. ### To allay any concerns, I propose the following change: OLD The domainpart for every XMPP service MUST be a fully qualified domain name (FQDN; see [RFC1035]), IPv4 address, IPv6 address, or unqualified hostname (i.e., a text label that is resolvable on a local network). NEW The domainpart for every XMPP service MUST be a fully-qualified domain name (FQDN), an IPv4 address, an IPv6 address, or an unqualified hostname (i.e., a text label that is resolvable on a local network). Informational Note: The term "fully-qualified domain name" is not well defined. In [RFC1034] it also called an absolute domain name, and the two terms are associated in [RFC1535]. The earliest use of the term can be found in [RFC1123]. References to those older specifications ought not to be construed as limiting the characters of a fully-qualified domain name to the ASCII range; for example, [RFC5890] mentions that a fully-qualified domain name can contain one or more U-labels. > «In the terms of IDNA2008 [RFC5890], the domainpart of a JID is a > "domain name slot".» Maybe we should use the more specific term > "IDNA-aware domain name slot" from that RFC? Good point. > The wording «For the purpose of communication over XMPP» is still > used in this section. It should be harmonized with the following > sections (I like the new wording by the way). Ah, I missed that instance. Will fix. > Section 2.2 - 2.4: «With regard to directionality, the "Bidi Rule" > provided in [RFC5893] applies.» The Bidi Rule as such only mentions > Bidi domain names and doesn't "apply" as such. I'd prefer saying > that the conditions therein MUST be fulfilled. Actually, Section 2 of RFC 5893 states that "the following rule applies to labels in Bidi domain names", so one can apply the rule to strings other than domain names as long as conceptually one substitutes the term "label" with the term "string". That's how it is treated in the PRECIS framework document, but you're right that slightly more careful wording would be helpful. I propose the following change: OLD With regard to directionality, the "Bidi Rule" provided in [RFC5893] applies. NEW With regard to directionality, applications MUST apply the "Bidi Rule" defined in [RFC5893] (i.e., each of the six conditions of the Bidi Rule must be satisfied). > Section 3: The conformance requirements mention the rules SHOULD be > enforced by clients. This is not reflected in this section as such > (as far as I can tell). In particular I'd like to have an > implementation note somewhere, reminding client developers that for > comparison some normalization can be necessary/helpful. E.g. a > client might send a message to one JID, but receive a reply from a > normalized version thereof. Interpreting these as separate entities > can lead to a bad user experience. Or security problems! I propose the following changes: OLD Enforcement of the XMPP address format rules is the responsibility of XMPP servers. Although XMPP clients are encouraged to prepare complete JIDs and parts of JIDs in accordance with these rules before including them in protocol slots within XMPP streams, XMPP servers hold the primary responsibility for enforcing the rules. NEW Enforcement of the XMPP address format rules is the responsibility of XMPP servers. Although XMPP clients SHOULD prepare complete JIDs and parts of JIDs in accordance with these rules before including them in protocol slots within XMPP streams, XMPP servers MUST enforce the rules wherever possible. OLD In general, servers are responsible for enforcing the address format rules when receiving protocol elements from clients where the server is expected to process or act on such elements; two examples from [RFC6120] are the 'to' attribute on XML stanzas (which is a JID slot used by XMPP servers for routing of outbound stanzas) and the child of the element (which is a resourcepart slot used by XMPP servers for binding of a resource to an account for routing of stanzas between the server and a particular client). However, servers are not responsible for enforcing the rules when the protocol elements are intended for communication among other entities; two examples are the 'initiator' attribute in the Jingle extension [XEP-0166] (which is a JID slot used for client-to-client coordination of multimedia sessions) and the 'nick' attribute in the Multi-User Chat extension [XEP-0045] (which is a resourcepart slot used for administrative purposes in the context of XMPP chatrooms). NEW In general, servers are responsible for enforcing the address format rules when receiving protocol elements from clients where the server is expected to process or act on such elements; two examples from [RFC6120] are the 'to' attribute on XML stanzas (which is a JID slot used by XMPP servers for routing of outbound stanzas) and the child of the element (which is a resourcepart slot used by XMPP servers for binding of a resource to an account for routing of stanzas between the server and a particular client). However, servers are not responsible for enforcing the rules when the protocol elements are intended for communication among other entities; two examples are the 'initiator' attribute in the Jingle extension [XEP-0166] (which is a JID slot used for client-to-client coordination of multimedia sessions) and the 'nick' attribute in the Multi-User Chat extension [XEP-0045] (which is a resourcepart slot used for administrative purposes in the context of XMPP chatrooms); in such cases, clients SHOULD enforce the rules, and client implementers need to understand that not enforcing the rules can lead to a degraded user experience or security vulnerabilities. > Section 5.3.1: Not sure if it is worth mentioning here, but proper > TLS certificate checking would mitigate DNS poisoning too. I think that's already covered by Section 13.9.2 of RFC 6120. Thanks again, Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+GMiAACgkQNL8k5A2w/vxh5wCgsGNbVs6qFqWhHBYe77El/Skx LdoAoMbuj2/naM+93Ly36FTkDOM0vtPX =s65R -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Apr 12 05:35:11 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7DA21F8587; Thu, 12 Apr 2012 05:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 tLH-j6UlB16q; Thu, 12 Apr 2012 05:35:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBEB21F8572; Thu, 12 Apr 2012 05:35:10 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7810A40058; Thu, 12 Apr 2012 06:49:03 -0600 (MDT) Message-ID: <4F86CBF5.20809@stpeter.im> Date: Thu, 12 Apr 2012 06:35:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <6155.1334219161.556547@puncture> <70B6EFCD-62B6-46C2-A0ED-38DF80FE9C6F@nic.cz> <6155.1334233124.001138@puncture> <99E176A1-AC49-480F-93A4-0997179E7772@nic.cz> In-Reply-To: <99E176A1-AC49-480F-93A4-0997179E7772@nic.cz> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "dane@ietf.org list" , xmpp@ietf.org Subject: Re: [xmpp] [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:35:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/12/12 6:33 AM, OndÅ™ej Surý wrote: > > On 12. 4. 2012, at 14:18, Dave Cridland wrote: > >> On Thu Apr 12 12:03:37 2012, OndÅ™ej Surý wrote: >>> Please see http://trac.tools.ietf.org/wg/dane/trac/ticket/28 >>> before discussing SRV records further. We have left SRV >>> records on purpose and we expect that this will be solved in >>> separate document (for each affected protocol). >> Foolish me, I must have missed the reference to that ticket in >> the draft. >> >> Really, if this is out of scope, declare it as such - but then >> don't use SMTP either, given that's very close in spirit to SRV. >> >> But certainly for XMPP, DANE is currently insufficient, which is >> a real shame. > > We would certainly welcome new document defining interaction of > XMPP and DANE. But I think that this needs to be crafted in the > XMPP working group. We had a long discussion about this in the DANE WG. Matt Miller and I volunteered to write a document about this, but other folks are welcome to beat us to it if they please. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Gy/UACgkQNL8k5A2w/vxtQACdHKlwz1UOSs/G3dxO+rxdHJBu DgwAoJMMl59ahGahNzWgL9iNAGFRAnDA =R3AD -----END PGP SIGNATURE----- From ondrej.sury@nic.cz Thu Apr 12 05:33:24 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A704421F865A; Thu, 12 Apr 2012 05:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 2eQwkSIdY7Ub; Thu, 12 Apr 2012 05:33:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CC5CE21F862F; Thu, 12 Apr 2012 05:33:23 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:de3:3a2e:898e:dddb] (unknown [IPv6:2001:1488:ac14:1400:de3:3a2e:898e:dddb]) by mail.nic.cz (Postfix) with ESMTPSA id 27FBE140421; Thu, 12 Apr 2012 14:33:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334234003; bh=N9sb2MvbZMy3t18F7mvvIR4barc7W+y/FGsrk0c9LJA=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=N9N9HeAOwDyXFuydiSHgONjcAdv5MI+fahJ5e/1E3FHPb55pNsVAx7hA1fBvmqO+V 9gsMTnGv+FBSH3MWuvzpuEe+TAgyom2npczoxjQvi0zZqSizVB6t9YjnlefyKwd7al FwIZJ8+aBOU4i8FCIp1ZatH4+sNOyOS87HGO++aQ= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <6155.1334233124.001138@puncture> Date: Thu, 12 Apr 2012 14:33:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99E176A1-AC49-480F-93A4-0997179E7772@nic.cz> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <6155.1334219161.556547@puncture> <70B6EFCD-62B6-46C2-A0ED-38DF80FE9C6F@nic.cz> <6155.1334233124.001138@puncture> To: Dave Cridland , xmpp@ietf.org X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 12 Apr 2012 15:41:32 -0700 Cc: IETF-Discussion , "dane@ietf.org list" Subject: Re: [xmpp] [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:33:24 -0000 On 12. 4. 2012, at 14:18, Dave Cridland wrote: > On Thu Apr 12 12:03:37 2012, Ond=C5=99ej Sur=C3=BD wrote: >> Please see http://trac.tools.ietf.org/wg/dane/trac/ticket/28 before = discussing SRV records >> further. We have left SRV records on purpose and we expect that this = will be solved in >> separate document (for each affected protocol). > Foolish me, I must have missed the reference to that ticket in the = draft. >=20 > Really, if this is out of scope, declare it as such - but then don't = use SMTP either, given that's very close in spirit to SRV. >=20 > But certainly for XMPP, DANE is currently insufficient, which is a = real shame. We would certainly welcome new document defining interaction of XMPP and = DANE. But I think that this needs to be crafted in the XMPP working group. >> > As a final comment, I'd presonally like to see some comments about = how, and when, extended validation information should be checked and = trusted. It seems to me that such information should be ignored when = handling type 2 or type 3 certificates; or at best it should be = validated independantly using the traditional methods - that is, it = should be treated as a type 0 or type 1 certificate for the purposes of = extended validation. >> I think that Extended Validation is out of the scope of this = document. And if I am not >> mistaken the CA which are able to issue EV certificates are hardcoded = in the browsers. >> Thus I think that DANE-aware applications can use standard rules for = EV certificates. >=20 > I think this needs calling out. EV seems like a very good argument for = the existence of CAs in a DANE world; I think it would be beneficial to = touch on the subject if possible. Alright point taken. I have opened = http://trac.tools.ietf.org/wg/dane/trac/ticket/39 O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From internet-drafts@ietf.org Sat Apr 14 09:43:10 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C1A21F8550; Sat, 14 Apr 2012 09:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 CGZEfLotfkDq; Sat, 14 Apr 2012 09:43:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC8D21F84D2; Sat, 14 Apr 2012 09:43:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120414164309.28723.98020.idtracker@ietfa.amsl.com> Date: Sat, 14 Apr 2012 09:43:09 -0700 Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-02.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 16:43:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Extensible Messaging and Presence Pro= tocol Working Group of the IETF. Title : Extensible Messaging and Presence Protocol (XMPP): Addre= ss Format Author(s) : Peter Saint-Andre Filename : draft-ietf-xmpp-6122bis-02.txt Pages : 20 Date : 2012-04-14 This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the US-ASCII range. This document obsoletes RFC 6122. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xmpp-6122bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-xmpp-6122bis-02.txt From stpeter@stpeter.im Sat Apr 14 09:50:09 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07ACB21F8576 for ; Sat, 14 Apr 2012 09:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 CbJLDUOFpspy for ; Sat, 14 Apr 2012 09:50:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 37C0E21F85D6 for ; Sat, 14 Apr 2012 09:50:08 -0700 (PDT) Received: from [192.168.0.3] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 814C740058 for ; Sat, 14 Apr 2012 11:04:08 -0600 (MDT) Message-ID: <4F89AA08.3060409@stpeter.im> Date: Sat, 14 Apr 2012 10:47:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: xmpp@ietf.org References: <20120414164309.28723.98020.idtracker@ietfa.amsl.com> In-Reply-To: <20120414164309.28723.98020.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-02.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 16:50:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This version addresses feedback from Florian Zeitz. On 4/14/12 10:43 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Extensible Messaging > and Presence Protocol Working Group of the IETF. > > Title : Extensible Messaging and Presence Protocol > (XMPP): Address Format Author(s) : Peter Saint-Andre Filename > : draft-ietf-xmpp-6122bis-02.txt Pages : 20 Date > : 2012-04-14 > > This document defines the address format for the Extensible > Messaging and Presence Protocol (XMPP), including support for code > points outside the US-ASCII range. This document obsoletes RFC > 6122. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-xmpp-6122bis-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-xmpp-6122bis-02.txt > > _______________________________________________ xmpp mailing list > xmpp@ietf.org https://www.ietf.org/mailman/listinfo/xmpp -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JqgcACgkQNL8k5A2w/vzfVwCdEXTnmwY122MaqULOkO6Cx5PI WnsAn35kqF6RgXXeAEWbedubOjPFnWXJ =gtra -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Apr 16 09:48:51 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C9C21F85D3 for ; Mon, 16 Apr 2012 09:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.653 X-Spam-Level: X-Spam-Status: No, score=-102.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ONaSg77JLCrx for ; Mon, 16 Apr 2012 09:48:50 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BE1B021F85D2 for ; Mon, 16 Apr 2012 09:48:50 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C2E2040058 for ; Mon, 16 Apr 2012 11:02:57 -0600 (MDT) Message-ID: <4F8C4D71.3060208@stpeter.im> Date: Mon, 16 Apr 2012 10:48:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: xmpp@ietf.org References: <4F8C4CE7.8030502@stpeter.im> In-Reply-To: <4F8C4CE7.8030502@stpeter.im> X-Enigmail-Version: 1.4 X-Forwarded-Message-Id: <4F8C4CE7.8030502@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: Re: [Standards] error in RFC 6120 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 16:48:51 -0000 Forwarding this to the WG list for completeness... -------- Original Message -------- Subject: Re: [Standards] error in RFC 6120 Date: Mon, 16 Apr 2012 10:46:31 -0600 From: Peter Saint-Andre Reply-To: XMPP Standards To: XMPP Standards On 4/15/12 4:20 AM, Yann Leboulanger wrote: > Hi, > > I think there is a small error in RFC6120, in section 4.9.3.19, at the > end of the section: > > "(b) the receiving entity MAY have a policy of following redirects only > if it has authenticated the receiving entity" > > I think it should be "(b) the *initiating* entity MAY have a policy of > following redirects only if it has authenticated the receiving entity" You're right! > But thanks for it, it's much more clear than previous version of the RFC. I'm happy to hear it. Peter -- Peter Saint-Andre https://stpeter.im/ From mamille2@cisco.com Mon Apr 30 11:52:53 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0150921F88E5; Mon, 30 Apr 2012 11:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Enw+76H7Y2Tq; Mon, 30 Apr 2012 11:52:52 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5D21F8476; Mon, 30 Apr 2012 11:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5717; q=dns/txt; s=iport; t=1335811972; x=1337021572; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=BnspdV8hLc24MYyPNQQgMtTe4eVX3FUp1+aOWkmDExo=; b=YPEf0rTvFeyHmzpgX+R8a0cjuRk7f5vX/+nLcrZb6dnvMGdE5gmThW32 Pp8n3rtKyHJSl1MkAHyeU8yXlHsKgbLEiVtBHMpowf+/EVcGbrayxQSPk QElLiiA/z7VpUAzbCc88p0NaIoNGzHH+VxXAnR5XP0OGMHJcjwFM/0x/T Y=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPXenk+rRDoI/2dsb2JhbABEr1ODAIEHggkBAQEDARIBZgULIyMLAlUGEyKHZgQBmkGgApA/YwSIZIYThweOWYFpgwc X-IronPort-AV: E=Sophos;i="4.75,505,1330905600"; d="sig'?p7s'?scan'208";a="42745738" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 30 Apr 2012 18:52:52 +0000 Received: from dhcp-64-101-72-220.cisco.com (dhcp-64-101-72-220.cisco.com [64.101.72.220]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3UIqpDh029149; Mon, 30 Apr 2012 18:52:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-81-1022493794" From: Matt Miller In-Reply-To: <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org> Date: Mon, 30 Apr 2012 12:52:59 -0600 Message-Id: <708C6B7F-A6E7-4DF5-9A77-7718791B7CE6@cisco.com> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com> <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org> To: Paul Hoffman Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: XMPP Working Group , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: [xmpp] Documenting DANE for XMPP (WAS: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 18:52:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-81-1022493794 Content-Type: multipart/signed; boundary=Apple-Mail-80-1022493784; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-80-1022493784 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 30, 2012, at 12:37, Paul Hoffman wrote: > On Apr 30, 2012, at 10:46 AM, Matt Miller wrote: >=20 >> I think there might still need to be some explicitness on what name = to expect to match on regardless of where the certificate is found, = especially with multi-domain XMPP servers (e.g. a server = "im.shakespeare.lit" that services domains "capulet.shakespeare.lit" and = "denmark.shakespeare.lit"). >=20 > Yes. >=20 >> Maybe that doesn't need to be its own document. =20 >=20 > Are you serious!?!?! After the amount of confusing and disagreement we = have seen in the past few months on this topic, a stand-alone document = that can be referred to easily is exactly what we need. >=20 The preference of having a single document came from the XMPP WG. I = personally am not sure it's the best idea, but I also don't have = anything written up yet. I'm more than willing to fight hard to = separate, but I also need to see what it looks like with the rest of = XMPP federation stuff. >> I am working on a proposal for improving XMPP federation, and a = section in that document might be sufficient...Probably (-: >=20 > I'm skeptical, to say the least. I did say "might" and "probably" (-: - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-80-1022493784 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQzMDE4NTI1 OVowIwYJKoZIhvcNAQkEMRYEFKYtQhbUbQq6VO9BjRW4o7U+td2dMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBZGZTwnJyeiCvy128Fhymh/a1dXYE0WsyKMgQDMbJJzOhqHPWT9fQDFNN9 uohWmQT+9SgKhgvlqcpT0siUmqjGd/uNGEk0b+wJLQXsI/uKLxqQBZn9E/rsPVNMdX36jcOley4m bSOHhDby3Gf9nUWu5RqClnR392iLZbtfqS0dx6mekIW+1leNCjBhDsrJjH2PLMY4NxXj2Sh1E/Nr Crpnn7OItQ6TsK5MBsk5IhbKXhaXye2Lh/QDJNHrLLeE8kdR7xli9MDDlje8V7GhyjOUqoh079ef nZEBKJfGfd96TE7BV8K96aG1dkBNNFk9q5fJ2z7r7qhVII+lkiWqIoIhAAAAAAAA --Apple-Mail-80-1022493784-- --Apple-Mail-81-1022493794 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPnt+LAAoJEJq6Ou0cgrSP31gH/iDRqgPeVdEKhIPCTpMweHxF XtNVctZbkegNAO0ZkXlcFvjIJF1BXkBrSAXFPpsMawAmoQ7cmwQlaJP/kWscN7m5 IU57kdFBa4EkGYvW1SMd4zdbsuR/BAu2NryxaQRXWkoLhdaTJGN2+DksID5LFG8Z WJJvIAJ/GmIZI3s24/qBDYWtfAgT7REcogHzHcJbjdg86B/Cl08VOAIe5sNDfPWk HV4QBxdCCBCLnl3q0aGIYcOLZ4nOPHO0AudykZfBhfg4YhGctlrRcgXR8C7AVlc/ DkvKaT49AJo3c6G6j+4JhzcX4XEtHJIEL4H+xQxdNzZzWsWZIStB0MRrTyhocBk= =rOzu -----END PGP SIGNATURE----- --Apple-Mail-81-1022493794-- From rbarnes@bbn.com Mon Apr 30 14:47:43 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018EB21E80C3; Mon, 30 Apr 2012 14:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.444 X-Spam-Level: X-Spam-Status: No, score=-106.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 QlulIcSspzH8; Mon, 30 Apr 2012 14:47:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2C321E80C0; Mon, 30 Apr 2012 14:47:41 -0700 (PDT) Received: from [128.89.253.186] (port=60199) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SOyRA-000Fm9-JB; Mon, 30 Apr 2012 17:47:16 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <708C6B7F-A6E7-4DF5-9A77-7718791B7CE6@cisco.com> Date: Mon, 30 Apr 2012 17:48:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com> <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org> <708C6B7F-A6E7-4DF5-9A77-7718791B7CE6@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org Discuss" , Paul Hoffman , XMPP Working Group , IETF DANE WG list Subject: Re: [xmpp] [dane] Documenting DANE for XMPP (WAS: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 21:47:43 -0000 +1 to documenting the use of DANE with XMPP +1 also to incorporating this discussion in a broader DNA / "server = federation" document On Apr 30, 2012, at 2:52 PM, Matt Miller wrote: >=20 > On Apr 30, 2012, at 12:37, Paul Hoffman wrote: >=20 >> On Apr 30, 2012, at 10:46 AM, Matt Miller wrote: >>=20 >>> I think there might still need to be some explicitness on what name = to expect to match on regardless of where the certificate is found, = especially with multi-domain XMPP servers (e.g. a server = "im.shakespeare.lit" that services domains "capulet.shakespeare.lit" and = "denmark.shakespeare.lit"). >>=20 >> Yes. >>=20 >>> Maybe that doesn't need to be its own document. =20 >>=20 >> Are you serious!?!?! After the amount of confusing and disagreement = we have seen in the past few months on this topic, a stand-alone = document that can be referred to easily is exactly what we need. >>=20 >=20 > The preference of having a single document came from the XMPP WG. I = personally am not sure it's the best idea, but I also don't have = anything written up yet. I'm more than willing to fight hard to = separate, but I also need to see what it looks like with the rest of = XMPP federation stuff. >=20 >>> I am working on a proposal for improving XMPP federation, and a = section in that document might be sufficient...Probably (-: >>=20 >> I'm skeptical, to say the least. >=20 > I did say "might" and "probably" (-: >=20 >=20 > - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From stpeter@stpeter.im Mon Apr 30 15:24:39 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB8321E80DC; Mon, 30 Apr 2012 15:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] 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 yUGhfoqq0Cxh; Mon, 30 Apr 2012 15:24:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3A59021E80DB; Mon, 30 Apr 2012 15:24:38 -0700 (PDT) Received: from [10.154.131.165] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1A6C340058; Mon, 30 Apr 2012 16:39:28 -0600 (MDT) Message-ID: <4F9F1122.7080603@stpeter.im> Date: Mon, 30 Apr 2012 15:24:34 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com> <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org> <708C6B7F-A6E7-4DF5-9A77-7718791B7CE6@cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list , Paul Hoffman , XMPP Working Group Subject: Re: [xmpp] [dane] Documenting DANE for XMPP (WAS: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 22:24:39 -0000 [ - apps-discuss ] On 4/30/12 2:48 PM, Richard L. Barnes wrote: > +1 to documenting the use of DANE with XMPP > > +1 also to incorporating this discussion in a broader DNA / "server federation" document I agree with Paul that it would be nice to have a standalone DANE+XMPP document available that other folks can point to when working on DANE+FOO specs, but I also agree with Matt about the desirability of having one document about XMPP federation that developers can reference. For now I think Matt and I will work on a separate DANE+XMPP spec and then fold that in later when all the other federation pieces are complete. Peter -- Peter Saint-Andre https://stpeter.im/