From nobody Thu Mar 5 08:58:42 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B9A1A1A25 for ; Thu, 5 Mar 2015 08:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwrO1nGdmieZ for ; Thu, 5 Mar 2015 08:58:38 -0800 (PST) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81A6B1A1A60 for ; Thu, 5 Mar 2015 08:58:25 -0800 (PST) Received: by oifu20 with SMTP id u20so12756134oif.12 for ; Thu, 05 Mar 2015 08:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=47Olq072kRNQcRdXS/xbqFPR77agLLJYNETz5ls90aI=; b=UDr4Zu9KCsl+r6otLnU41mfB0nMEUfh7of8fCivVwu5Exb+6iDmLshR2omF0j4iPUu zvKw5rI5AkykuZQyNgPHWWyWFp0qoSsLzE6aAjyeUQx3yH3qcKFQeiENSAWGdlgFY2JV DKcYXmYSQDdjc2bkgNq9qBOhCxuzTCMeYiz4M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=47Olq072kRNQcRdXS/xbqFPR77agLLJYNETz5ls90aI=; b=MKxOpBHweeEnU+Ej0gPAU79N4Z5/OEDJP2fgUf4KHdWIL34yU8XtGIyNFxaY3njHeG RqeyfgWbPG7F7xQI5WJSQx5IQFIgvT5ZpuhX/N9/9nCe2bimXjsH0f1ibL+9N97QM+hP xbUpKFT3tsREU2F5hJ9X3VQlS9GdDdxDCXPwN1tE8W8P7Bm800bW7Lxnnxo/l65CtSB+ pSDQb3hCEShBIuuzMQ3SPT7JIa29aPzw+cAroUOuH38PttUDdLBIhGysbM+lJd6YqNsk uMWSOGoPZhnPrJVWkVFNRYL0CpUXeozObJlkH17z8BM46H85jacYHNAQaYFmSQupCYrp zbpA== X-Gm-Message-State: ALoCoQmJMwBgae2zEMDfDsHUldD7ObJ3rN2U01p97v1uwnnpudF5cj/n/hcO6qZM8PfHdlczBJTW MIME-Version: 1.0 X-Received: by 10.60.131.238 with SMTP id op14mr7746063oeb.59.1425574659894; Thu, 05 Mar 2015 08:57:39 -0800 (PST) Received: by 10.60.62.172 with HTTP; Thu, 5 Mar 2015 08:57:39 -0800 (PST) In-Reply-To: <98C92FA8-F99C-4861-9199-7B0443506574@nostrum.com> References: <98C92FA8-F99C-4861-9199-7B0443506574@nostrum.com> Date: Thu, 5 Mar 2015 16:57:39 +0000 Message-ID: From: Dave Cridland To: Ben Campbell Content-Type: multipart/alternative; boundary=047d7b4723b83446f905108d7715 Archived-At: Cc: XMPP Group Subject: Re: [xmpp] Cross-WG WGLC of draft-ietf-xmpp-6122bis-18 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:58:41 -0000 --047d7b4723b83446f905108d7715 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 27 February 2015 at 02:17, Ben Campbell wrote: > We actually did a WGLC on this about a year ago, but much has changed > since then. Please send comments to the authors and both lists by March 1= 2, > 2015. If you've read the draft and consider it ready to go, please send > comments to that effect. > Non-Precis comments: 1) "at slash at". The domainpart of a jid is described as being after the first '@', if any. That's not always true; consider the following legal jid: service.example.org/foo@example.net This issue arises because the resourcepart can contain an '@', and to find the domainpart we need to (conceptually) remove the resourcepart first. So I think this implies two things: Firstly, the text at the beginning of =C2=A73.2 needs changing slightly, perhaps: The domainpart of a jid is that portion which remains once any portion from the first '/' character to the end of the string has been removed (if there is a '/' character present), and then any portion from the beginning of the string to the first '@' character (if there is a '@' character present). This is ugly text. The second implication is that the examples could use the nasty cases like this. 2) "case folding examples" The examples given as 8, 9, and 10 confuse me more by their presence than their absence, because the resourcepart of a jid is compared case-insensitively anyway - I don't know Greek well enough to know if the final sigma would be used at the end of a localpart, but it seems to me that the capital and lower case sigma example might be best re-cast as a localpart example. (When I read the details of the case-map versus final examples, I worried that we'd changed the comparison for resourceparts to case-folding somewhere...) 3) "angle brackets" The presence of angle brackets in example 16 is, I think, more confusing than the thing it's attempting to solve; in part because the < does indeed make the jid illegal under =C2=A73.3.1, so I didn't initially read the explanation... 4) "applicability to what now?" Can we change =C2=A73.4.1's title to "Applicability within XMPP extensions"= or something? I'll see if I can navigate the Turtles of Precis enough to come up with some comments there. Sadly I suspect I won't be able to sensibly comment until I've tried implementing. Dave. --047d7b4723b83446f905108d7715 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 7 February 2015 at 02:17, Ben Campbell <ben@nostrum.com> wrote= :
We actually did a WGLC on this about a = year ago, but much has changed since then. Please send comments to the auth= ors and both lists by March 12, 2015. If you've read the draft and cons= ider it ready to go, please send comments to that effect.
<= div>
Non-Precis comments:

1) "a= t slash at".

The domainpart of a jid is descr= ibed as being after the first '@', if any. That's not always tr= ue; consider the following legal jid:


This issue arises becaus= e the resourcepart can contain an '@', and to find the domainpart w= e need to (conceptually) remove the resourcepart first.

So I think this implies two things: Firstly, the text at the beginnin= g of =C2=A73.2 needs changing slightly, perhaps:

T= he domainpart of a jid is that portion which remains once any portion from = the first '/' character to the end of the string has been removed (= if there is a '/' character present), and then any portion from the= beginning of the string to the first '@' character (if there is a = '@' character present).

This is ugly text.=

The second implication is that the examples could= use the nasty cases like this.

2) "case fold= ing examples"

The examples given as 8, 9, and= 10 confuse me more by their presence than their absence, because the resou= rcepart of a jid is compared case-insensitively anyway - I don't know G= reek well enough to know if the final sigma would be used at the end of a l= ocalpart, but it seems to me that the capital and lower case sigma example = might be best re-cast as a localpart example.

(Whe= n I read the details of the case-map versus final examples, I worried that = we'd changed the comparison for resourceparts to case-folding somewhere= ...)

3) "angle brackets"

<= /div>
The presence of angle brackets in example 16 is, I think, more co= nfusing than the thing it's attempting to solve; in part because the &l= t; does indeed make the jid illegal under =C2=A73.3.1, so I didn't init= ially read the explanation...

4) "applicabili= ty to what now?"

Can we change =C2=A73.4.1= 9;s title to "Applicability within XMPP extensions" or something?=

I'll see if I can navigate the Turtles of Pre= cis enough to come up with some comments there. Sadly I suspect I won't= be able to sensibly comment until I've tried implementing.
<= br>
Dave.
--047d7b4723b83446f905108d7715-- From nobody Thu Mar 5 11:34:50 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285031A87BC for ; Thu, 5 Mar 2015 11:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CN0HqFTxu7y for ; Thu, 5 Mar 2015 11:34:45 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6629F1A8825 for ; Thu, 5 Mar 2015 11:34:37 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t25JYQoh026824 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2015 13:34:36 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "XMPP Working Group" Date: Thu, 05 Mar 2015 13:34:26 -0600 Message-ID: <0EC92524-01C6-4410-A881-1AF11B7F401F@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Cc: draft-ietf-xmpp-dna.all@tools.ietf.org Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-dna-09 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 19:34:48 -0000 Reminder: This WGLC ends tomorrow. I have not seen any feedback. If you have read the draft, and think it is ready to go, please say so. Thanks! Ben. On 20 Feb 2015, at 15:36, Ben Campbell wrote: > This is an XMPP Working Group Last Call of draft-ietf-xmpp-dna-09. The > draft is available at the following URL > > https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ > > The WGLC will conclude on March 6, 2015. Please send your comments to > the authors and the XMPP mailing list. > > (Given that the draft deadline for IETF92 is the following Monday, I > suspect the authors would really appreciate people not waiting till > the last minute to send feedback.) > > Thanks! > > Ben. > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From nobody Thu Mar 5 11:39:04 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3B31A886A for ; Thu, 5 Mar 2015 11:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze-JUNM_uuVO for ; Thu, 5 Mar 2015 11:39:02 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981F91A885D for ; Thu, 5 Mar 2015 11:39:02 -0800 (PST) Received: by wevm14 with SMTP id m14so55074682wev.13 for ; Thu, 05 Mar 2015 11:39:01 -0800 (PST) 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; bh=PowVo1sQ2MAmIa80fIsPGlKYZujSkb3lE0zdJmkmhoA=; b=RQaT+lpzOJqKw0eJYD+/ywviSAdaACAKhBF1sMfWRnbeNfyOTN8PpvUzPHwgSwpd3p G6G+FRr4Hxz1/9T/XoVzfEKFjAH1TZg1MyWTdy0gYkyL4Ved6CFrSaa/t5dC5zoXecJg 4AtOG0PYYt7LNQ+ogJ+8R018bkzYlabMTYpXTQHTfUq4xA//rEYkmX3N5djgKbKNQLFL 4NjEOPyuE7OKnMgxFBLS9FY2sNEok5vDLlcreEv7DxtxSBfTqQTnQI0nL2Q4YKgXHEpK 3xwvBAKoOebyphlZCD31yYP43OwLrF7JEacFem87nnCyBvOxc51OS6HZzF24JY6cgvYL oSdA== X-Received: by 10.180.108.13 with SMTP id hg13mr25539761wib.7.1425584341463; Thu, 05 Mar 2015 11:39:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.43.132 with HTTP; Thu, 5 Mar 2015 11:38:41 -0800 (PST) In-Reply-To: <0EC92524-01C6-4410-A881-1AF11B7F401F@nostrum.com> References: <0EC92524-01C6-4410-A881-1AF11B7F401F@nostrum.com> From: Matthew Wild Date: Thu, 5 Mar 2015 19:38:41 +0000 Message-ID: To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-xmpp-dna.all@tools.ietf.org, XMPP Working Group Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-dna-09 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 19:39:03 -0000 On 5 March 2015 at 19:34, Ben Campbell wrote: > Reminder: This WGLC ends tomorrow. I have not seen any feedback. > > If you have read the draft, and think it is ready to go, please say so. Thanks for the reminder! I spent some time reading through the document, and I think it's ready to go. Regards, Matthew From nobody Thu Mar 5 11:44:20 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD19E1A8890 for ; Thu, 5 Mar 2015 11:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XekkZNZ-gmWg for ; Thu, 5 Mar 2015 11:44:10 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40461A8893 for ; Thu, 5 Mar 2015 11:44:09 -0800 (PST) Received: by pablj1 with SMTP id lj1so35893840pab.10 for ; Thu, 05 Mar 2015 11:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=FqmKd96F6CEnPx3sT+waCA2F5COR2n+I11JrLsyuaoc=; b=oLHO6dAO1hUPEBkD7POcvCahHRY9UE1Vvg/1z+LCLmzbzLkOKq+LQjAGOdrbxEWCLy xpcn+g7f/EIFtsdYzyYF8nlF2iYaZGA9y3sBPlQS+Zwl3kKyaTakHTJHozpoT9kls1p7 FsXD1gB5uz8AwqI3fUzm+f30E7DRXYVV2ZEBKllVHXXTxV9PD6EXz6iMwYkv+aNR8ouZ Y17lrrvBKbEHaxvN6bG1H1m65Pgr+jquK0aoMCcpeVMKFJOiTKsXYQfVILgeYo3nxTlQ wl842+ffmpDSPrwPNtNmVmSxCEjkdN8POnplGLOeY7v2+56FQWZIeC/7KpR2BGM11cve QzIQ== X-Received: by 10.66.184.106 with SMTP id et10mr19297830pac.138.1425584649437; Thu, 05 Mar 2015 11:44:09 -0800 (PST) Received: from [192.168.1.62] (68-113-20-60.dhcp.knwc.wa.charter.com. [68.113.20.60]) by mx.google.com with ESMTPSA id fl4sm7757782pab.8.2015.03.05.11.44.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 11:44:08 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_407AC982-7379-4EEE-9DEC-AE16ACFEA7B7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Lance Stout In-Reply-To: <0EC92524-01C6-4410-A881-1AF11B7F401F@nostrum.com> Date: Thu, 5 Mar 2015 11:44:07 -0800 Message-Id: <73EFDD33-E17C-4566-9DC6-1A19A87F5986@gmail.com> References: <0EC92524-01C6-4410-A881-1AF11B7F401F@nostrum.com> To: XMPP Working Group X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: draft-ietf-xmpp-dna.all@tools.ietf.org Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-dna-09 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 19:44:12 -0000 --Apple-Mail=_407AC982-7379-4EEE-9DEC-AE16ACFEA7B7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > If you have read the draft, and think it is ready to go, please say so. The draft looks good to go. - Lance --Apple-Mail=_407AC982-7379-4EEE-9DEC-AE16ACFEA7B7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM5jCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGqjCCBZKg AwIBAgICL6UwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MzAzMTQwNTM1MTJaFw0xNTAzMTUyMjMyMzZaMIGMMRkwFwYDVQQNExBQTDAxbVhKMjhha3BBRzVj MQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGluZ3RvbjESMBAGA1UEBxMJS2VubmV3aWNrMRQw EgYDVQQDEwtMYW5jZSBTdG91dDEjMCEGCSqGSIb3DQEJARYUbGFuY2VzdG91dEBnbWFpbC5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr0XNL4SLaoBR9y72zNo3eAefV7vk1UaEx xML9TqPKZHV9gGxA/XO5YilACUU/l5In+8akri5djy/haORYEm5HwsR/R1vxhOK7cBEyXMCY41Vg KyqnQPJlidJ0L5PMinz1cwo0wyLlh8WhxIBHBjgLbA8XAoDC7FL6KzDq+qoJdsBbehu4W9fVscRr T7XeM41zHjc7FqJOD8I2n9Z5CIlEeWwaIEZO0HpxOlcbD5EGVaC7Wbji/nEOuQ1OI6iGId/7Xakg JrGfjSg1wQ5dXIBMzbSZmw3B6WmDdNgpCzHYL+QrCLrFenO0u2D6ZR/dZQgIkPRhL6I7PqniJ3FN 0hJpAgMBAAGjggMSMIIDDjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFggdjTZDgsglI1DBpZiCB24Ub+ZMB8GA1UdIwQYMBaA FK5Vg2/sMcq59x36r2sx88gd46y7MFcGA1UdEQRQME6BFGxhbmNlc3RvdXRAZ21haWwuY29tgRRs YW5jZXN0b3V0QGdtYWlsLmNvbYEObGFuY2VAbGFuY2UuaW2BEGxhbmNlQGFuZHlldC5uZXQwggFM BgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBh Y2NvcmRpbmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0 YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2Ug aW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIu Y2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20v MA0GCSqGSIb3DQEBBQUAA4IBAQALnAVqIrddlyGYqOAb4TfJ25u3sOtC352yAF7VaQdhkV/Z7Rum OPpsEN7rwLfHOphYhafI4IxKy39NZbFBjzzcW8Kx6OJ1L/eDEW5Dbt1XzaBF4VVM1/DZyg/l3C0N 9/YrumhcgdSUgxLL2d/GzEk1dNTcZLpLJABf6L1W5RszU4HSPyVppLzYVVq5yLwmKnlIcnDjEdMr jmsFq8b0Duk1j05IE2KBiWNy/Q0H9Hj/943/rvQOx7464jzuEGkWYO8AU7Nmq3h2DLoo8GECFwxy e7rSL0o3KFkAQHC0YE/8GbaT05Jo7xnF/9X/IOWd0rSvBmTVkreGARQywViv35eCMYIDbDCCA2gC AQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFz cyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwCQYFKw4DAhoFAKCCAa0wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwMzA1MTk0NDA4WjAjBgkq hkiG9w0BCQQxFgQUAGX9jWLm74iSftt8lCsysLzdXDMwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIvpTCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkg SW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwDQYJKoZIhvcNAQEBBQAEggEAKq/oNANBMB7BaJXn CeNhWQaY0ia5fs41qFaiidUhGBXkPzm7UlMpicPoJeqNGQbSscVG2WXvRQ3MyS3+asxoKhu9t4ES j34c+LBSVDWW/85lgWA04MPEBYPIk1fWiVlXHDH62tzH3zjD8rkQOuLugjNEkipEeuSg0N7zubix 7hM3gc7P9QqrnKUP/ajOV/lxXYC5xOQaw7kDC2J733ozobYiSCb0J5gzDtVjqG+kjbAtIKEDdFO4 VJQ1L6eZAQjdWiM2YCKukt40bsCOgFcVl5+T1li8L9G7plZSZoALe/7QwBN0kIxM5KMZUk2/pb+7 y6wCMQ9nh/mDlkCDwXSOWgAAAAAAAA== --Apple-Mail=_407AC982-7379-4EEE-9DEC-AE16ACFEA7B7-- From nobody Thu Mar 5 12:24:26 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69B11A8932 for ; Thu, 5 Mar 2015 12:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2Rm6YTtQxrX for ; Thu, 5 Mar 2015 12:24:24 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E584F1A008B for ; Thu, 5 Mar 2015 12:24:23 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t25KOC3x031077 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2015 14:24:22 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "XMPP Working Group" Date: Thu, 05 Mar 2015 14:24:12 -0600 Message-ID: <86AF6DC8-C3FC-47D3-928D-DE829637194C@nostrum.com> In-Reply-To: <0EC92524-01C6-4410-A881-1AF11B7F401F@nostrum.com> References: <0EC92524-01C6-4410-A881-1AF11B7F401F@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Cc: draft-ietf-xmpp-dna.all@tools.ietf.org Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-dna-09 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 20:24:25 -0000 (as individual) I suppose I should send my own review :-) I think the draft is pretty much ready to go, and support publication. I have a couple of minor comments, neither of which are critical. -- section 5.1, step 4: It might be nice to repeat the secure DNS reference here. -- section 6: It seems like this section has a fair amount of redundancy to section 5. (especially 5.0 and 5.2). On 5 Mar 2015, at 13:34, Ben Campbell wrote: > Reminder: This WGLC ends tomorrow. I have not seen any feedback. > > If you have read the draft, and think it is ready to go, please say > so. > > Thanks! > > Ben. > [...] From nobody Thu Mar 5 13:21:56 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB461A8BC1 for ; Thu, 5 Mar 2015 13:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKu3nDhU5imS for ; Thu, 5 Mar 2015 13:21:53 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194DD1A6F02 for ; Thu, 5 Mar 2015 13:21:53 -0800 (PST) Received: by obbnt9 with SMTP id nt9so16790665obb.3 for ; Thu, 05 Mar 2015 13:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s3LoogelmMH9jIsCB73ENsTTLNlcSiJ+QSqcFOFFPo8=; b=U6zZM2l2SSnV5DLc93dClbOW5mxq65b1RHGrJ2731sZPMbmVThpwzHT03mSl6+VAJh PmDev/Bj1lP51XJ3hBEWfrgRNXpAN+ojFe8I2q4SrB9841uRV6uu6trc+iZyyAggkOxA DwbBC9du+lfsu2TpxS4mKKNflRC53lm3emr38= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s3LoogelmMH9jIsCB73ENsTTLNlcSiJ+QSqcFOFFPo8=; b=aQDgqtjBOXR07+mEt09df9/z9OaUd2i5DD2hUoWsR27ts2QP66H4o0uJ+erEaIMDBs 9OtdVhXiuUy6xsLzt4bMw6VWioXQIlWrDSvDQvc/FKiWaZeUG+vFICAvdMzyDZ+Te4BZ 2e2rUjrQSQIkZevArjwJ91v1hyXGITU/X3DDdlCCzvJNCuXub9uYxTpLklwQjv0pkAA+ y39QT1PuNytNUKQE5qpWRuLelRZ3ZVsdgwDFI8N98NWqiEe7iEBgBvMOOkFiaw5IYVnL ooNQLHxv9Q7PHnybVyx39C8RjC1rdGsKp8L+n9i5pjG69nPnEQY6Nr6DpUo2txFuAGuB PVQA== X-Gm-Message-State: ALoCoQk9IC8GjrDqWWM150uLZ5ijvtMtt1qAd50bkodDAtJ2G4QXsib04vo3/Wik3R7qslb5unEZ MIME-Version: 1.0 X-Received: by 10.182.148.71 with SMTP id tq7mr8622725obb.78.1425590512542; Thu, 05 Mar 2015 13:21:52 -0800 (PST) Received: by 10.60.62.172 with HTTP; Thu, 5 Mar 2015 13:21:52 -0800 (PST) In-Reply-To: <0EC92524-01C6-4410-A881-1AF11B7F401F@nostrum.com> References: <0EC92524-01C6-4410-A881-1AF11B7F401F@nostrum.com> Date: Thu, 5 Mar 2015 21:21:52 +0000 Message-ID: From: Dave Cridland To: Ben Campbell Content-Type: multipart/alternative; boundary=089e013a0a7a189f7f05109128f2 Archived-At: Cc: draft-ietf-xmpp-dna.all@tools.ietf.org, XMPP Working Group Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-dna-09 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 21:21:54 -0000 --089e013a0a7a189f7f05109128f2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5 March 2015 at 19:34, Ben Campbell wrote: > Reminder: This WGLC ends tomorrow. I have not seen any feedback. > > If you have read the draft, and think it is ready to go, please say so. I do not think this draft is ready, sorry. I should have looked at this in detail before. The major problem is the implications in =C2=A74.3, which are unfortunately= very much incorrect. Specifically, it is loosely describing XEP-0220 as enhanced by XEP-0344, and touches on the impact of XEP-0288. This is in itself probably useful, though by restating much of those XEPs I'm not entirely clear on its value. To start with, the title of the section is "One-Way Authentication". This is most certainly incorrect. To say that authentication is one way is to assert that one or other end is considered anonymous by its peer. Server A, the initiating entity, intends sending stanzas to b.example - there is clearly no way that Server A will send those stanzas to Server B unless it has authenticated Server B as hosting b.example. Meanwhile, Server B will not accept stanzas from Server A unless it has also authenticated Server A as hosting a.example. Therefore, if stanzas get sent from A to B, mutual authentication must have taken place. This is a shame, as conceptually, XEP-0220 can be viewed as taking a one-way authentication method (traditionally "DNS and hope") and using it to gain a mutually authenticated session which can then be used for stanza transmission. At the end of the section, it then says that "at this point the servers are using two TCP connections instead of one" - this is problematic too, because servers can use either a "verify-only" session, or can use the reverse connection to send stanzas on. If they authenticate using PKIX, however, they still have to open a second connection to return stanzas. The text then goes on to assert that XEP-0288 can be used "to tie the authentication achieved on the second TCP connection to the first TCP connection" - that's not even slightly true - in fact that's what XEP-0220 does. Instead, XEP-0288 simply removes the (historical, and somewhat silly) restriction that S2S channels can only transmit stanzas from initiator to receiver, by a (too) simple negotiation. There are other minor issues; I'll go through those in detail later. --089e013a0a7a189f7f05109128f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 5= March 2015 at 19:34, Ben Campbell <ben@nostrum.com> wrote:
Reminder: This WGLC ends tomorrow. I have n= ot seen any feedback.

If you have read the draft, and think it is ready to go, please say so.

I do not think this draft is ready, sorry. I s= hould have looked at this in detail before.

The ma= jor problem is the implications in =C2=A74.3, which are unfortunately very = much incorrect. Specifically, it is loosely describing XEP-0220 as enhanced= by XEP-0344, and touches on the impact of XEP-0288. This is in itself prob= ably useful, though by restating much of those XEPs I'm not entirely cl= ear on its value.

To start with, the title of the = section is "One-Way Authentication". This is most certainly incor= rect. To say that authentication is one way is to assert that one or other = end is considered anonymous by its peer. Server A, the initiating entity, i= ntends sending stanzas to b.example - there is clearly no way that Server A= will send those stanzas to Server B unless it has authenticated Server B a= s hosting b.example. Meanwhile, Server B will not accept stanzas from Serve= r A unless it has also authenticated Server A as hosting a.example. Therefo= re, if stanzas get sent from A to B, mutual authentication must have taken = place.

This is a shame, as conceptually, XEP-0220 = can be viewed as taking a one-way authentication method (traditionally &quo= t;DNS and hope") and using it to gain a mutually authenticated session= which can then be used for stanza transmission.

A= t the end of the section, it then says that "at this point the servers= are using two TCP connections instead of one" - this is problematic t= oo, because servers can use either a "verify-only" session, or ca= n use the reverse connection to send stanzas on. If they authenticate using= PKIX, however, they still have to open a second connection to return stanz= as.

The text then goes on to assert that XEP-0288 = can be used "to tie the authentication achieved on the second TCP conn= ection to the first TCP connection" - that's not even slightly tru= e - in fact that's what XEP-0220 does.

Instead= , XEP-0288 simply removes the (historical, and somewhat silly) restriction = that S2S channels can only transmit stanzas from initiator to receiver, by = a (too) simple negotiation.

There are other minor = issues; I'll go through those in detail later.
--089e013a0a7a189f7f05109128f2-- From nobody Thu Mar 5 18:05:16 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95521A9101 for ; Thu, 5 Mar 2015 18:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_17=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff0HaLdIqknv for ; Thu, 5 Mar 2015 18:05:11 -0800 (PST) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F31E1A90FC for ; Thu, 5 Mar 2015 18:05:11 -0800 (PST) Received: from [192.168.20.188] (97-90-49-254.static.yakm.wa.charter.com [97.90.49.254]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t2625KBU025055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 6 Mar 2015 03:05:23 +0100 Message-ID: <54F90B4B.502@goodadvice.pages.de> Date: Thu, 05 Mar 2015 18:04:59 -0800 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <0EC92524-01C6-4410-A881-1AF11B7F401F@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-dna-09 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 02:05:14 -0000 Am 05.03.2015 um 13:21 schrieb Dave Cridland: > On 5 March 2015 at 19:34, Ben Campbell wrote: > >> Reminder: This WGLC ends tomorrow. I have not seen any feedback. >> >> If you have read the draft, and think it is ready to go, please say so. > > > I do not think this draft is ready, sorry. I should have looked at this in > detail before. Thanks for doing it, even if late. That's quite good feedback, I missed those issues. > The major problem is the implications in §4.3, which are unfortunately very > much incorrect. Specifically, it is loosely describing XEP-0220 as enhanced > by XEP-0344, and touches on the impact of XEP-0288. This is in itself I had _totally_ forgotten that we had documented some of this in 0344. I'll see where this fits best and if it makes 4.3 easier. > probably useful, though by restating much of those XEPs I'm not entirely > clear on its value. I don't think we mention this case in 0344 which, in 2.4 describes only the other way round. > To start with, the title of the section is "One-Way Authentication". This > is most certainly incorrect. To say that authentication is one way is to This section assumes a trusted certificate at the receiving server so the authentication is using PKIX only one-way (originating server uses pkix, dane, posh etc to authenticate the receiving server). I'll see if I can come up with a better term. > assert that one or other end is considered anonymous by its peer. Server A, > the initiating entity, intends sending stanzas to b.example - there is > clearly no way that Server A will send those stanzas to Server B unless it > has authenticated Server B as hosting b.example. Meanwhile, Server B will > not accept stanzas from Server A unless it has also authenticated Server A > as hosting a.example. Therefore, if stanzas get sent from A to B, mutual > authentication must have taken place. Right. > This is a shame, as conceptually, XEP-0220 can be viewed as taking a > one-way authentication method (traditionally "DNS and hope") and using it > to gain a mutually authenticated session which can then be used for stanza > transmission. 0220 only works for asserting the senders identify. The receiving servers identity has always been DNS and hope if the certificate was not trusted. Unless that's what you mean, hope in the one direction and dns in the other ;-) > At the end of the section, it then says that "at this point the servers are > using two TCP connections instead of one" - this is problematic too, > because servers can use either a "verify-only" session, or can use the > reverse connection to send stanzas on. If they authenticate using PKIX, > however, they still have to open a second connection to return stanzas. Good catch. For bidirectional communication, they will end up using two connections, but that is not shown here. Unless they use 0288, they will end up repeating the process in the reverse direction. Which is described in 0220 so it makes little sense to repeat it here. I think that paragraph should just go away. > The text then goes on to assert that XEP-0288 can be used "to tie the > authentication achieved on the second TCP connection to the first TCP > connection" - that's not even slightly true - in fact that's what XEP-0220 > does. Yes, that should have referenced 0220 instead. Will either fix or remove. > Instead, XEP-0288 simply removes the (historical, and somewhat silly) > restriction that S2S channels can only transmit stanzas from initiator to > receiver, by a (too) simple negotiation. +1 > There are other minor issues; I'll go through those in detail later. keep'em coming :-) From nobody Fri Mar 6 15:20:55 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE07A1A6FCF for ; Fri, 6 Mar 2015 15:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX0wW8nA-tyK for ; Fri, 6 Mar 2015 15:20:52 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE481A6F33 for ; Fri, 6 Mar 2015 15:20:52 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t26NKdq0095497 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2015 17:20:50 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "XMPP Working Group" Date: Fri, 06 Mar 2015 17:20:39 -0600 Message-ID: <084FF347-D930-4B36-BD57-7E9877EB6C7B@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Subject: [xmpp] No XMPP Meeting in Dallas X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 23:20:54 -0000 Hi Everyone, I assume people have noticed by now that there is no XMPP meeting scheduled for Dallas. In the opinion of the chairs, none of our deliverables are currently in a state to benefit from a meeting. ( In all honesty, Joe and I had considered scheduling a meeting, but somehow screwed up the request. But that seems to have worked out for the best.) I apologize for any inconvenience. Thanks! Ben. From nobody Mon Mar 9 14:46:34 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA961A90BE for ; Mon, 9 Mar 2015 14:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNodoyw4MWph for ; Mon, 9 Mar 2015 14:46:31 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15DF1ACDAE for ; Mon, 9 Mar 2015 14:46:29 -0700 (PDT) Received: by iery20 with SMTP id y20so14163065ier.0 for ; Mon, 09 Mar 2015 14:46:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cTk80+IfB1aNj4eiDdx31fpNlKnuR+ZeyDqWDiGhP9g=; b=dEhA+TWx3ggjOQpfi2edSAQXA563XOZZv9DtDVvnvLZ+eZcmif7ItqaP3geLMFyjU9 33Zm8Fk7NPhatYRw4aar/9GJz3efU2J0FYE58eQxMa/sph1vUEo58NSDykLt1/82CQLC 5GV2tL3spHPAdcUh7GGUoh6joxWXZ46KT3EafTs+wxYdujEfn1Zl2Z9j01C4/c+n2ZJL rXKOuI/Bu4iokPAIkZmMkxWtGZ2ncFbJt4f+453h6WHZv33tX/+4wTHQe6c+PuD67UQk 3XbZ2iiNXyOG9/Wtz2H0LWCjhXwEX0syIDdhjUM2+UINpZRGbp70z1fMU8AkTfXKTL5q 3caA== X-Gm-Message-State: ALoCoQnvbbniaKu163wIwNC/ZKgROODJ/PDoIVDj1WlqWPrquj7y8siYe0aOyIY8tWF326z5pWst X-Received: by 10.50.72.108 with SMTP id c12mr40056421igv.27.1425937589133; Mon, 09 Mar 2015 14:46:29 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id nv8sm6843757igb.6.2015.03.09.14.46.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 14:46:28 -0700 (PDT) Message-ID: <54FE14B7.8020601@andyet.net> Date: Mon, 09 Mar 2015 15:46:31 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dave Cridland , Ben Campbell References: <98C92FA8-F99C-4861-9199-7B0443506574@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: XMPP Group Subject: Re: [xmpp] Cross-WG WGLC of draft-ietf-xmpp-6122bis-18 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:46:33 -0000 Hi Dave, thanks for the review. Comments inline. On 3/5/15 9:57 AM, Dave Cridland wrote: > On 27 February 2015 at 02:17, Ben Campbell > wrote: > > We actually did a WGLC on this about a year ago, but much has > changed since then. Please send comments to the authors and both > lists by March 12, 2015. If you've read the draft and consider it > ready to go, please send comments to that effect. > > > Non-Precis comments: > > 1) "at slash at". > > The domainpart of a jid is described as being after the first '@', if > any. That's not always true; consider the following legal jid: > > service.example.org/foo@example.net > > > This issue arises because the resourcepart can contain an '@', and to > find the domainpart we need to (conceptually) remove the resourcepart first. True. > So I think this implies two things: Firstly, the text at the beginning > of §3.2 needs changing slightly, perhaps: > > The domainpart of a jid is that portion which remains once any portion > from the first '/' character to the end of the string has been removed > (if there is a '/' character present), and then any portion from the > beginning of the string to the first '@' character (if there is a '@' > character present). > > This is ugly text. Well, it is accurate, which is an improvement. > The second implication is that the examples could use the nasty cases > like this. Yes. Will add. > 2) "case folding examples" > > The examples given as 8, 9, and 10 confuse me more by their presence > than their absence, because the resourcepart of a jid is compared > case-insensitively anyway - I don't know Greek well enough to know if > the final sigma would be used at the end of a localpart, but it seems to > me that the capital and lower case sigma example might be best re-cast > as a localpart example. That's a good suggestion, thanks. > (When I read the details of the case-map versus final examples, I > worried that we'd changed the comparison for resourceparts to > case-folding somewhere...) > > 3) "angle brackets" > > The presence of angle brackets in example 16 is, I think, more confusing > than the thing it's attempting to solve; in part because the < does > indeed make the jid illegal under §3.3.1, so I didn't initially read the > explanation... I think it would be best for all of the examples to be enclosed in angle brackets (this is what we did in the precis-nickname spec). > 4) "applicability to what now?" > > Can we change §3.4.1's title to "Applicability within XMPP extensions" > or something? Sure. > I'll see if I can navigate the Turtles of Precis enough to come up with > some comments there. Sadly I suspect I won't be able to sensibly comment > until I've tried implementing. That's quite possible. Internationalization is perplexing. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Mar 9 15:30:39 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A2A1A8830 for ; Mon, 9 Mar 2015 15:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnV0nad1vFZt for ; Mon, 9 Mar 2015 15:30:36 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AECE1A8A7B for ; Mon, 9 Mar 2015 15:30:36 -0700 (PDT) Received: by oiav1 with SMTP id v1so32223955oia.9 for ; Mon, 09 Mar 2015 15:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RPeZ13VcAtByOSoupcoyZa+nZbAog9ybTIJtB3Dcg4M=; b=LBPMOFEnnYrmjBcZQID6qGz3HRBxudSEu81hwVBhzJgAXPkOabbe1Kj+5uZyYHoCcV pQUEh9GSmd2RjB5MKcCY4pFVigePJykPEFQnR29KC4oTHfxSOL56f47LDxo5viS3ZmEn ZRWTwuVQXQ5aF8z9VA+u0a4RgP6Vm4w6L71Lw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RPeZ13VcAtByOSoupcoyZa+nZbAog9ybTIJtB3Dcg4M=; b=RgbZADrolWNySKhN4XXeyUC5+Nw5Wd0z8maumwR9ZTKBNO0S9Omfwv21zL/7sIvF+y VrY1SBrKuxjrMM2yuKn6D69HyIuMyS1FVqjxyXbDvfa8kRnvq7nuIT0LSwcWknc0aLgc grkNaFgBvWoMa6MOnxVoa26fKsPlZHwPwh0xzRjALdpHySG3PgiZKXPYyxNL0oabZu3b KesMhNCa9z0SH0kTreNhozAOvdo37u4W3HJGFpy2t2FMUdPikTWM+aGpTsoVobTsi595 jaD31ghyN2COgRQjLOvpfR98UVQriSYKBbH7djWIbrhw2y/Xd7YsMCdXKGVDzDExD2HF 4G0A== X-Gm-Message-State: ALoCoQkuLrKK+rjr0ky2pKILwGDaZ22WDvh1/BKQ8qaW0RVmkWOmvvwNI9yA7y+bJ1T0YszhbTIG MIME-Version: 1.0 X-Received: by 10.60.51.165 with SMTP id l5mr23429735oeo.69.1425940235560; Mon, 09 Mar 2015 15:30:35 -0700 (PDT) Received: by 10.60.62.172 with HTTP; Mon, 9 Mar 2015 15:30:35 -0700 (PDT) In-Reply-To: <54FE14B7.8020601@andyet.net> References: <98C92FA8-F99C-4861-9199-7B0443506574@nostrum.com> <54FE14B7.8020601@andyet.net> Date: Mon, 9 Mar 2015 22:30:35 +0000 Message-ID: From: Dave Cridland To: "Peter Saint-Andre - &yet" Content-Type: multipart/alternative; boundary=001a11c3093a363e370510e29503 Archived-At: Cc: Ben Campbell , XMPP Group Subject: Re: [xmpp] Cross-WG WGLC of draft-ietf-xmpp-6122bis-18 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:30:37 -0000 --001a11c3093a363e370510e29503 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9 March 2015 at 21:46, Peter Saint-Andre - &yet wrote= : > 3) "angle brackets" >> >> The presence of angle brackets in example 16 is, I think, more confusing >> than the thing it's attempting to solve; in part because the < does >> indeed make the jid illegal under =C2=A73.3.1, so I didn't initially rea= d the >> explanation... >> > > I think it would be best for all of the examples to be enclosed in angle > brackets (this is what we did in the precis-nickname spec). Yes, that would also work for me. Dave. --001a11c3093a363e370510e29503 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 9 March 2015 at 21:46, Peter Saint-Andre - &yet <peter@andyet.ne= t> wrote:
=
3) "angle brackets"

The presence of angle brackets in example 16 is, I think, more confusing than the thing it's attempting to solve; in part because the < does<= br> indeed make the jid illegal under =C2=A73.3.1, so I didn't initially re= ad the
explanation...

 I think it would be best for all of the examples to be enclosed in angle br= ackets (this is what we did in the precis-nickname spec).
=
Yes, that would also work for me.

D= ave.=C2=A0
--001a11c3093a363e370510e29503-- From nobody Mon Mar 9 15:56:19 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82D51ACE0D for ; Mon, 9 Mar 2015 15:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBcRYQU-egUx for ; Mon, 9 Mar 2015 15:56:13 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0F61ACE03 for ; Mon, 9 Mar 2015 15:56:12 -0700 (PDT) Received: by iecvy18 with SMTP id vy18so43692543iec.9 for ; Mon, 09 Mar 2015 15:56:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dHhRfdVWxTB+bO5l3TJ/dNeL6seIE/N6qfASYlDuNks=; b=DFKybwYpoYoVIbcCyIgiU0D0htMi2sEYmnbz4gS6mqzGoYCTWeG6YgyKi2aZ6z1CH3 C87YMBOM3yXDQsSKSTQcV4iz8eyN5EEo7pTtZiCZGk0k+JJLBgzdtCB1r6WX2ttLW37u Pcw1iViSSAN4YCVlfnLX7xK+haN+kKLG5NY4oc9PSIao0eUs+vAGa2K2QhbtjrcMp1+u JxxpQTwKyOLqvOLfr8T1Ab5NkCfoRsx1FuhJD47kIFDdMpHm0c8++VJIJD6ck8BWuxte FFce6Ky3GfB0V4qNj6ETJ/wIC/Sl2Iaj1SulBa209sOO3xcp4HpduwshcCev5pwhKHiV X0MQ== X-Gm-Message-State: ALoCoQnRAJ8LwUbGm8/uM0juh6r5hkSWGubumYgpckEIEXs69sCyo6tUEz4OqPVovrR2aF6s5mwB X-Received: by 10.50.30.130 with SMTP id s2mr52097365igh.11.1425941771499; Mon, 09 Mar 2015 15:56:11 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id g74sm10000867ioi.42.2015.03.09.15.56.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 15:56:10 -0700 (PDT) Message-ID: <54FE250D.3010802@andyet.net> Date: Mon, 09 Mar 2015 16:56:13 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dave Cridland References: <98C92FA8-F99C-4861-9199-7B0443506574@nostrum.com> <54FE14B7.8020601@andyet.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Ben Campbell , XMPP Group Subject: Re: [xmpp] Cross-WG WGLC of draft-ietf-xmpp-6122bis-18 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:56:16 -0000 On 3/9/15 4:30 PM, Dave Cridland wrote: > > > On 9 March 2015 at 21:46, Peter Saint-Andre - &yet > wrote: > > 3) "angle brackets" > > The presence of angle brackets in example 16 is, I think, more > confusing > than the thing it's attempting to solve; in part because the < does > indeed make the jid illegal under §3.3.1, so I didn't initially > read the > explanation... > > > I think it would be best for all of the examples to be enclosed in > angle brackets (this is what we did in the precis-nickname spec). > > > Yes, that would also work for me. OK, I'm about to submit a revised I-D, then. Peter From nobody Mon Mar 9 15:57:10 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AB31A8F4A; Mon, 9 Mar 2015 15:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQtLZ1vPex-J; Mon, 9 Mar 2015 15:56:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 645D31ACE16; Mon, 9 Mar 2015 15:56:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309225654.31349.86771.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 15:56:54 -0700 Archived-At: Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-19.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:57:02 -0000 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 : Peter Saint-Andre Filename : draft-ietf-xmpp-6122bis-19.txt Pages : 25 Date : 2015-03-09 Abstract: This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 16:03:30 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1470C1A9302 for ; Mon, 9 Mar 2015 16:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ON7NaQg09CfI for ; Mon, 9 Mar 2015 16:03:27 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589A01A8898 for ; Mon, 9 Mar 2015 16:03:27 -0700 (PDT) Received: by obcva8 with SMTP id va8so25874028obc.8 for ; Mon, 09 Mar 2015 16:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=g8oO/B1d4fI24t6bX/01k7UukJhe7dMMb+wfjpLCen8=; b=MeMvGCAOhMp+9/lShxyICtBvFThZy/A7OOmb7so18zV8nEBh148zER54XlgDV8XP5+ WAJHRjihF43kbAQxDW5vxB8f4ICLw0wcYMX35+f4QMhx7YhqgOqb76e/00K78URqHEX+ 1PSq8MdrkdQvAWVgOiaa7SsUqMrGyf8gRRPlQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=g8oO/B1d4fI24t6bX/01k7UukJhe7dMMb+wfjpLCen8=; b=L6NoXvBcZnDgptprat7jGiNKmNV4NfkDYL1wJKj7fnAQgXTJQX2y+cx89S8vQ8K6tH DQqWjflK8naVUlWfX1TohA5wFER24lC4q8oNZa9kOAZJe/Z1h7GHKfT/V0MiNeeooGTN usT7YOaiRdzV5tIXP7DhkJvf31TDNPXwQXkmVofmlowKc8BB8UT+sHmh8VdmVW5eHie1 Hhx68x1JzVtGLlBRMRtllAMb38OSGxtFAmCcgBARJL5xY+4KWEycMA5N3idC+ihyV3Ap wDa3Qwb+PMzFTAghuSlbznGPjicSj5N3Q4jfvVlHiMLZWDtSgdLc+BRZvAF0/4cWX8zC hQqg== X-Gm-Message-State: ALoCoQkjvm8YnltCR2H0MEdTAPxtjxtONYN3OKkFhXiUpq/BhcqF5rpnHS5rtSJLzDCdDb6TgI7e MIME-Version: 1.0 X-Received: by 10.60.134.237 with SMTP id pn13mr14050843oeb.59.1425942206924; Mon, 09 Mar 2015 16:03:26 -0700 (PDT) Received: by 10.60.62.172 with HTTP; Mon, 9 Mar 2015 16:03:26 -0700 (PDT) In-Reply-To: <20150309225654.31349.86771.idtracker@ietfa.amsl.com> References: <20150309225654.31349.86771.idtracker@ietfa.amsl.com> Date: Mon, 9 Mar 2015 23:03:26 +0000 Message-ID: From: Dave Cridland To: XMPP Working Group Content-Type: multipart/alternative; boundary=047d7b471e3ab6d7890510e30ac2 Archived-At: Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-19.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:03:29 -0000 --047d7b471e3ab6d7890510e30ac2 Content-Type: text/plain; charset=UTF-8 This resolves all my issues, thanks. On 9 March 2015 at 22:56, 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 : Peter Saint-Andre > Filename : draft-ietf-xmpp-6122bis-19.txt > Pages : 25 > Date : 2015-03-09 > > Abstract: > This document defines the address format for the Extensible Messaging > and Presence Protocol (XMPP), including support for code points > outside the ASCII range. This document obsoletes RFC 6122. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-19 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-19 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > --047d7b471e3ab6d7890510e30ac2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This resolves all my issues, thanks.

On 9 March 2015 at 22:56, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Extensible Messaging and Presence Pr= otocol Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Extensible Messaging and Presence Protocol (XMPP): Address Format
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Pete= r Saint-Andre
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-xmpp-6122bis-19.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 25
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-03-09

Abstract:
=C2=A0 =C2=A0This document defines the address format for the Extensible Me= ssaging
=C2=A0 =C2=A0and Presence Protocol (XMPP), including support for code point= s
=C2=A0 =C2=A0outside the ASCII range.=C2=A0 This document obsoletes RFC 612= 2.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/<= br>
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-19

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-xmpp-6122bis= -19


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
xmpp mailing list
xmpp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/xmpp

--047d7b471e3ab6d7890510e30ac2-- From nobody Tue Mar 10 15:30:54 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D051A8F37; Tue, 10 Mar 2015 15:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITfmK6LndASm; Tue, 10 Mar 2015 15:30:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960821A0126; Tue, 10 Mar 2015 15:30:49 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2AMUcbZ084681 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2015 17:30:49 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "XMPP Working Group" , precis@ietf.org, draft-ietf-xmpp-6122bis.all@ietf.org Date: Tue, 10 Mar 2015 17:30:38 -0500 Message-ID: <30D40A1D-09C3-4257-8DC1-A90AFE561571@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Subject: [xmpp] WGLC Comments on 6122bis X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 22:30:53 -0000 (as individual) Hi, This is a very well written draft. It's easy to understand given the complexity of the material. I support it's publication. I have a few minor comments: -- section 3.2, paragraph 6: Is there a reason to avoid a reference for IDNA2008? -- 3.3, implementation note: Are there any practical consequences for the implementor? Are there potential conflicts where the XMPP implementation correctly forms a Localpart, but it contains an identifier that is interpreted incorrectly by some SASL mechanism? -- 3.3.1, implementation note: I have mixed feelings about XEP-0106 being an informational reference (using the standard of "need to read to understand/implement this document"). Even if an implementation chooses not to create JIDs with escaped characters, it had to be prepared to receive them from somewhere else, doesn't it? -- 4, para 10 (I think): "In such cases, clients SHOULD enforce..." The sending client, receiving client, or both? Assuming the former, it might be worth adding some words to the effect of "before transmitting..." -- 8: While I don't object to the approach of the section, I think there's some risk of confusion about which text is authoritative from a 2119 perspective. I think it might be worth noting that the authoritative text is in the referenced sections, and only summarized here for convenience. (It only really matters if they conflict, but redundant normative text makes life harder for future updates.) Thanks! /Ben. From nobody Tue Mar 10 15:38:38 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52381A9051; Tue, 10 Mar 2015 15:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb-gwjlqmc4E; Tue, 10 Mar 2015 15:38:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE8E1A8F46; Tue, 10 Mar 2015 15:38:34 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2AMcNN7085744 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2015 17:38:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "XMPP Working Group" , precis@ietf.org, draft-ietf-xmpp-6122bis.all@ietf.org Date: Tue, 10 Mar 2015 17:38:23 -0500 Message-ID: In-Reply-To: <30D40A1D-09C3-4257-8DC1-A90AFE561571@nostrum.com> References: <30D40A1D-09C3-4257-8DC1-A90AFE561571@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Subject: Re: [xmpp] WGLC Comments on 6122bis X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 22:38:36 -0000 BTW, I reviewed version 19, quite by accident :-) On 10 Mar 2015, at 17:30, Ben Campbell wrote: > (as individual) > > Hi, > > This is a very well written draft. It's easy to understand given the > complexity of the material. I support it's publication. > > I have a few minor comments: > > -- section 3.2, paragraph 6: > > Is there a reason to avoid a reference for IDNA2008? > > -- 3.3, implementation note: > > Are there any practical consequences for the implementor? Are there > potential conflicts where the XMPP implementation correctly forms a > Localpart, but it contains an identifier that is interpreted > incorrectly by some SASL mechanism? > > -- 3.3.1, implementation note: > > I have mixed feelings about XEP-0106 being an informational reference > (using the standard of "need to read to understand/implement this > document"). Even if an implementation chooses not to create JIDs with > escaped characters, it had to be prepared to receive them from > somewhere else, doesn't it? > > -- 4, para 10 (I think): "In such cases, clients SHOULD enforce..." > > The sending client, receiving client, or both? Assuming the former, > it might be worth adding some words to the effect of "before > transmitting..." > > -- 8: > > While I don't object to the approach of the section, I think there's > some risk of confusion about which text is authoritative from a 2119 > perspective. I think it might be worth noting that the authoritative > text is in the referenced sections, and only summarized here for > convenience. (It only really matters if they conflict, but redundant > normative text makes life harder for future updates.) > > Thanks! > > /Ben. > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From nobody Tue Mar 10 16:13:33 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05271A8880 for ; Tue, 10 Mar 2015 16:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlMdOVoOpj3g for ; Tue, 10 Mar 2015 16:13:30 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF301A8AC9 for ; Tue, 10 Mar 2015 16:13:29 -0700 (PDT) Received: by iecsf10 with SMTP id sf10so35284390iec.2 for ; Tue, 10 Mar 2015 16:13:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sfvjYngnKDyb/8QpapUzaxXoNM/gOjY9G369EYQA/lY=; b=FhRsu8m+hK3LVDq3kiGpyXvSne8NMPU5/WGsnbfYSJucfpGUqoLf2cdEML5h8H6EB7 dS8QFE3XWGgL8bII54U4QsSysCn14VCDnWP51yUf/HBNCgIPqfQU2ladGOGab7JZySoO KUGta8S243xEOc/QAiRs/bes7GDOnB8SNzztnwXmO7krQK1pSPDfqlOx2SNRbXPNjnN5 SdJaOLXGOsY7JUsHsyAaMgup4SFRkP3bvsMdT5b8DsrMKsSTc7m2UjPRnRDWA6mgJ9BO u4nRjLCuInA/rhPN6WCky/nZvJy0nMg+uqf9h8V2fI1mUt4eVyBs1PEWmpZGFlI8Ke3W HIXQ== X-Gm-Message-State: ALoCoQk+DvG2sZJu8cnUoQuw7lVG5JQ0TDPZQud9q8hveSkrXr6DaUD7OjJ9/y5cpdfV/elCHuDX X-Received: by 10.50.39.65 with SMTP id n1mr87048186igk.37.1426029208360; Tue, 10 Mar 2015 16:13:28 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id d6sm1350862ioe.44.2015.03.10.16.13.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2015 16:13:27 -0700 (PDT) Message-ID: <54FF7A98.4090600@andyet.net> Date: Tue, 10 Mar 2015 17:13:28 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ben Campbell , XMPP Working Group , precis@ietf.org, draft-ietf-xmpp-6122bis.all@ietf.org References: <30D40A1D-09C3-4257-8DC1-A90AFE561571@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [xmpp] [precis] WGLC Comments on 6122bis X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 23:13:31 -0000 On 3/10/15 4:38 PM, Ben Campbell wrote: > BTW, I reviewed version 19, quite by accident :-) > > On 10 Mar 2015, at 17:30, Ben Campbell wrote: > >> (as individual) >> >> Hi, >> >> This is a very well written draft. It's easy to understand given the >> complexity of the material. I support it's publication. >> >> I have a few minor comments: >> >> -- section 3.2, paragraph 6: >> >> Is there a reason to avoid a reference for IDNA2008? Well, IDNA2008 is collectively RFCs 5890-5894 and we do point to several of those specs in §3.2. :-) >> -- 3.3, implementation note: >> >> Are there any practical consequences for the implementor? Are there >> potential conflicts where the XMPP implementation correctly forms a >> Localpart, but it contains an identifier that is interpreted >> incorrectly by some SASL mechanism? Re-using the UsernameCaseMapped profile from draft-ietf-precis-saslprepbis should help in this regard. However, as noted, some SASL mechanisms might not be upgraded quickly and thus would still use SASLprep (RFC 4013). The differences are explained a bit more in Appendix A of draft-ietf-precis-saslprepbis - as I see it, the only semi-major issue is that certain characters that were "mapped to nothing" in RFC 4013 are simply disallowed by the UsernameCaseMapped profile that we re-use in 6122bis. >> -- 3.3.1, implementation note: >> >> I have mixed feelings about XEP-0106 being an informational reference >> (using the standard of "need to read to understand/implement this >> document"). Even if an implementation chooses not to create JIDs with >> escaped characters, it had to be prepared to receive them from >> somewhere else, doesn't it? Well, the alternative is to reject the JID - but since the escaping mechanism in XEP-0106 is really a matter of presentation, it's something that affects clients more than servers anyway (and the JID escaping would be applied before PRECIS-related processing happens anyway). >> -- 4, para 10 (I think): "In such cases, clients SHOULD enforce..." >> >> The sending client, receiving client, or both? Assuming the former, >> it might be worth adding some words to the effect of "before >> transmitting..." Good catch. We might want to say "the entities involved SHOULD enforce", because in the second example there the chatroom might enforce the rules (so it's not just about clients) and more importantly it's not always a good idea to trust the sender. >> -- 8: >> >> While I don't object to the approach of the section, I think there's >> some risk of confusion about which text is authoritative from a 2119 >> perspective. I think it might be worth noting that the authoritative >> text is in the referenced sections, and only summarized here for >> convenience. (It only really matters if they conflict, but redundant >> normative text makes life harder for future updates.) I see your point: it's never a great idea to say the same thing in two places. We do say: This section describes a protocol feature set that summarizes the conformance requirements of this specification.... We could add a sentence like: The summary is purely informational and does not override any of the more detailed descriptions in the body of this specification. Peter From nobody Tue Mar 10 17:52:10 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95811A92B8; Tue, 10 Mar 2015 17:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stsvpnN1nn9M; Tue, 10 Mar 2015 17:51:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071EF1A92B1; Tue, 10 Mar 2015 17:51:46 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2B0pVUh004427 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2015 19:51:41 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Peter Saint-Andre - &yet" Date: Tue, 10 Mar 2015 19:51:31 -0500 Message-ID: In-Reply-To: <54FF7A98.4090600@andyet.net> References: <30D40A1D-09C3-4257-8DC1-A90AFE561571@nostrum.com> <54FF7A98.4090600@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9r5066) Archived-At: Cc: precis@ietf.org, XMPP Working Group , draft-ietf-xmpp-6122bis.all@ietf.org Subject: Re: [xmpp] [precis] WGLC Comments on 6122bis X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 00:51:58 -0000 On 10 Mar 2015, at 18:13, Peter Saint-Andre - &yet wrote: > On 3/10/15 4:38 PM, Ben Campbell wrote: >> BTW, I reviewed version 19, quite by accident :-) >> >> On 10 Mar 2015, at 17:30, Ben Campbell wrote: >> >>> (as individual) >>> >>> Hi, >>> >>> This is a very well written draft. It's easy to understand given the >>> complexity of the material. I support it's publication. >>> >>> I have a few minor comments: >>> >>> -- section 3.2, paragraph 6: >>> >>> Is there a reason to avoid a reference for IDNA2008? > > Well, IDNA2008 is collectively RFCs 5890-5894 and we do point to > several of those specs in §3.2. :-) I guess I should have said "... here", but needing 5 references probably argues against doing it again. :-) It just sort of looked strange that it was missing while the next phrase had a reference. > >>> -- 3.3, implementation note: >>> >>> Are there any practical consequences for the implementor? Are there >>> potential conflicts where the XMPP implementation correctly forms a >>> Localpart, but it contains an identifier that is interpreted >>> incorrectly by some SASL mechanism? > > Re-using the UsernameCaseMapped profile from > draft-ietf-precis-saslprepbis should help in this regard. However, as > noted, some SASL mechanisms might not be upgraded quickly and thus > would still use SASLprep (RFC 4013). The differences are explained a > bit more in Appendix A of draft-ietf-precis-saslprepbis - as I see it, > the only semi-major issue is that certain characters that were "mapped > to nothing" in RFC 4013 are simply disallowed by the > UsernameCaseMapped profile that we re-use in 6122bis. So an identifier created with UsernameCaseMapped should be fine, but an identifier created somewhere else in sasl might not be legal? That _seems_ unlikely to be a problem... It might not hurt to mention the saslprepbis appendix in the note. > >>> -- 3.3.1, implementation note: >>> >>> I have mixed feelings about XEP-0106 being an informational >>> reference >>> (using the standard of "need to read to understand/implement this >>> document"). Even if an implementation chooses not to create JIDs >>> with >>> escaped characters, it had to be prepared to receive them from >>> somewhere else, doesn't it? > > Well, the alternative is to reject the JID - but since the escaping > mechanism in XEP-0106 is really a matter of presentation, it's > something that affects clients more than servers anyway (and the JID > escaping would be applied before PRECIS-related processing happens > anyway). So a server would just operate on the escaped string without worrying about the fact. Got it. OTOH, this draft applies to clients, too. I suppose a client might display the raw string without unescaping, but that would be ugly. OTOH, that goes beyond the point of _this_ draft, so I'm okay leaving it as informational. [...] >>> -- 8: >>> >>> While I don't object to the approach of the section, I think there's >>> some risk of confusion about which text is authoritative from a 2119 >>> perspective. I think it might be worth noting that the authoritative >>> text is in the referenced sections, and only summarized here for >>> convenience. (It only really matters if they conflict, but >>> redundant >>> normative text makes life harder for future updates.) > > I see your point: it's never a great idea to say the same thing in two > places. > > We do say: > > This section describes a protocol feature set that summarizes the > conformance requirements of this specification.... > > We could add a sentence like: > > The summary is purely informational and does not override any of the > more detailed descriptions in the body of this specification. How about adding something more specific. For example, something to the effect of the following (to either the current text or with your proposed addition): "[RFC2119] keywords in this section are intended to describe the referenced normative text." (A careful reader will figure out the right thing without it. But I'm not worried about _careful_ readers ;-) ) From nobody Tue Mar 10 18:11:43 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46F71A8782; Tue, 10 Mar 2015 18:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4siUjPK1fre6; Tue, 10 Mar 2015 18:11:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680CB1A9124; Tue, 10 Mar 2015 18:11:39 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2B1BQR3006260 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2015 20:11:36 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Peter Saint-Andre - &yet" Date: Tue, 10 Mar 2015 20:11:26 -0500 Message-ID: <7C5C961D-FB27-445B-909B-981A7B76447B@nostrum.com> In-Reply-To: References: <30D40A1D-09C3-4257-8DC1-A90AFE561571@nostrum.com> <54FF7A98.4090600@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Cc: precis@ietf.org, XMPP Working Group , draft-ietf-xmpp-6122bis.all@ietf.org Subject: Re: [xmpp] [precis] WGLC Comments on 6122bis X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 01:11:40 -0000 On 10 Mar 2015, at 19:51, Ben Campbell wrote: > -- 3.3, implementation note: >>>> >>>> Are there any practical consequences for the implementor? Are there >>>> potential conflicts where the XMPP implementation correctly forms a >>>> Localpart, but it contains an identifier that is interpreted >>>> incorrectly by some SASL mechanism? > > >> >> Re-using the UsernameCaseMapped profile from >> draft-ietf-precis-saslprepbis should help in this regard. However, as >> noted, some SASL mechanisms might not be upgraded quickly and thus >> would still use SASLprep (RFC 4013). The differences are explained a >> bit more in Appendix A of draft-ietf-precis-saslprepbis - as I see >> it, the only semi-major issue is that certain characters that were >> "mapped to nothing" in RFC 4013 are simply disallowed by the >> UsernameCaseMapped profile that we re-use in 6122bis. > > > So an identifier created with UsernameCaseMapped should be fine, but > an identifier created somewhere else in sasl might not be legal? That > _seems_ unlikely to be a problem... I realized shortly after sending this that that made no sense. It seems more likely that you would run into a previously created identifier that followed older rules--but you already discuss that in the intro. Even so, it still might not hurt to mention the appendix. > > It might not hurt to mention the saslprepbis appendix in the note. From nobody Tue Mar 10 18:15:45 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15D61A9141 for ; Tue, 10 Mar 2015 18:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQOh4gfhR30b for ; Tue, 10 Mar 2015 18:15:42 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118D01A9124 for ; Tue, 10 Mar 2015 18:15:41 -0700 (PDT) Received: by igdh15 with SMTP id h15so8686374igd.3 for ; Tue, 10 Mar 2015 18:15:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=a/ae28sB19u0GdxCjxyouqSujnx4qfVvTyUwNvxwL5U=; b=ZXP2k9pit0fdRjkbwe3u6Snjx4WH1v1ZqkVgnBgWHd7Peun0aXSlv+Pewvarljhjlk H+VuuugWB59XB1p47f5MQjiYBHZfji+IvRPzp0EGNhs7kJCjRVndVGtoRef82E49IebW hkdxzHMHxXsGWNj3hdnDp3ZaDh4JxHYDPXxre6nrCNDTCqiOdHen8Kf5VG3vsNMSDbMm 6fb9MoZifJ4r+Y3ScNUAJEnsfChlLjXL4szzL1+peSbVKMps//fbMqyJUPgVNnjwhhpV iVx5Tj3FSzGTSdIcH7h8d7ohivVEPClNBFM/4dtNvJgTxZfFTVCJALvN1VmFw++NmJD9 CL5Q== X-Gm-Message-State: ALoCoQm5KcE3BUb9ObSnms7iNKixjddEqohb0s1v5iPgw1dV8G5Z34TOe0b9+GX6H5V67dAXG+Zv X-Received: by 10.107.9.213 with SMTP id 82mr44250851ioj.57.1426036539627; Tue, 10 Mar 2015 18:15:39 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id i16sm1543973ioe.17.2015.03.10.18.15.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2015 18:15:38 -0700 (PDT) Message-ID: <54FF973C.8090004@andyet.net> Date: Tue, 10 Mar 2015 19:15:40 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ben Campbell References: <30D40A1D-09C3-4257-8DC1-A90AFE561571@nostrum.com> <54FF7A98.4090600@andyet.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: precis@ietf.org, XMPP Working Group , draft-ietf-xmpp-6122bis.all@ietf.org Subject: Re: [xmpp] [precis] WGLC Comments on 6122bis X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 01:15:43 -0000 On 3/10/15 6:51 PM, Ben Campbell wrote: > On 10 Mar 2015, at 18:13, Peter Saint-Andre - &yet wrote: > >> On 3/10/15 4:38 PM, Ben Campbell wrote: >>> BTW, I reviewed version 19, quite by accident :-) >>> >>> On 10 Mar 2015, at 17:30, Ben Campbell wrote: >>> >>>> (as individual) >>>> >>>> Hi, >>>> >>>> This is a very well written draft. It's easy to understand given the >>>> complexity of the material. I support it's publication. >>>> >>>> I have a few minor comments: >>>> >>>> -- section 3.2, paragraph 6: >>>> >>>> Is there a reason to avoid a reference for IDNA2008? >> >> Well, IDNA2008 is collectively RFCs 5890-5894 and we do point to >> several of those specs in §3.2. :-) > > I guess I should have said "... here", but needing 5 references probably > argues against doing it again. :-) It just sort of looked strange that > it was missing while the next phrase had a reference. > >> >>>> -- 3.3, implementation note: >>>> >>>> Are there any practical consequences for the implementor? Are there >>>> potential conflicts where the XMPP implementation correctly forms a >>>> Localpart, but it contains an identifier that is interpreted >>>> incorrectly by some SASL mechanism? >> >> Re-using the UsernameCaseMapped profile from >> draft-ietf-precis-saslprepbis should help in this regard. However, as >> noted, some SASL mechanisms might not be upgraded quickly and thus >> would still use SASLprep (RFC 4013). The differences are explained a >> bit more in Appendix A of draft-ietf-precis-saslprepbis - as I see it, >> the only semi-major issue is that certain characters that were "mapped >> to nothing" in RFC 4013 are simply disallowed by the >> UsernameCaseMapped profile that we re-use in 6122bis. > > So an identifier created with UsernameCaseMapped should be fine, but an > identifier created somewhere else in sasl might not be legal? That > _seems_ unlikely to be a problem... Right. > It might not hurt to mention the saslprepbis appendix in the note. Actually, Section 6.1 of draft-ietf-precis-saslprepbis is an even better pointer because it describes the differences in more detail, with an eye toward migration from Stringprep to PRECIS. You might want to re-read that section to determine the level of your concern. >>>> -- 3.3.1, implementation note: >>>> >>>> I have mixed feelings about XEP-0106 being an informational reference >>>> (using the standard of "need to read to understand/implement this >>>> document"). Even if an implementation chooses not to create JIDs with >>>> escaped characters, it had to be prepared to receive them from >>>> somewhere else, doesn't it? >> >> Well, the alternative is to reject the JID - but since the escaping >> mechanism in XEP-0106 is really a matter of presentation, it's >> something that affects clients more than servers anyway (and the JID >> escaping would be applied before PRECIS-related processing happens >> anyway). > > So a server would just operate on the escaped string without worrying > about the fact. Got it. OTOH, this draft applies to clients, too. I > suppose a client might display the raw string without unescaping, but > that would be ugly. Yes, but it's interoperably ugly! ;-) > OTOH, that goes beyond the point of _this_ draft, so I'm okay leaving it > as informational. > > [...] > >>>> -- 8: >>>> >>>> While I don't object to the approach of the section, I think there's >>>> some risk of confusion about which text is authoritative from a 2119 >>>> perspective. I think it might be worth noting that the authoritative >>>> text is in the referenced sections, and only summarized here for >>>> convenience. (It only really matters if they conflict, but redundant >>>> normative text makes life harder for future updates.) >> >> I see your point: it's never a great idea to say the same thing in two >> places. >> >> We do say: >> >> This section describes a protocol feature set that summarizes the >> conformance requirements of this specification.... >> >> We could add a sentence like: >> >> The summary is purely informational and does not override any of the >> more detailed descriptions in the body of this specification. > > > How about adding something more specific. For example, something to the > effect of the following (to either the current text or with your > proposed addition): > > "[RFC2119] keywords in this section are intended to describe the > referenced normative text." > > (A careful reader will figure out the right thing without it. But I'm > not worried about _careful_ readers ;-) ) WFM! Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Mar 10 19:24:59 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5A01A1B9E; Tue, 10 Mar 2015 19:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt8G8bQXHCub; Tue, 10 Mar 2015 19:24:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AC91A1B51; Tue, 10 Mar 2015 19:24:56 -0700 (PDT) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2B2OoD1012014 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2015 21:24:51 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (12B466) In-Reply-To: <54FF973C.8090004@andyet.net> Date: Tue, 10 Mar 2015 21:24:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <229E9DC9-EE4A-4992-8F75-68BBFB667F26@nostrum.com> References: <30D40A1D-09C3-4257-8DC1-A90AFE561571@nostrum.com> <54FF7A98.4090600@andyet.net> <54FF973C.8090004@andyet.net> To: Peter Saint-Andre - &yet Archived-At: Cc: "precis@ietf.org" , XMPP Working Group , "draft-ietf-xmpp-6122bis.all@ietf.org" Subject: Re: [xmpp] [precis] WGLC Comments on 6122bis X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 02:24:58 -0000 On Mar 10, 2015, at 8:15 PM, Peter Saint-Andre - &yet wro= te: >> So an identifier created with UsernameCaseMapped should be fine, but an >> identifier created somewhere else in sasl might not be legal? That >> _seems_ unlikely to be a problem... >=20 > Right. >=20 >> It might not hurt to mention the saslprepbis appendix in the note. >=20 > Actually, Section 6.1 of draft-ietf-precis-saslprepbis is an even better p= ointer because it describes the differences in more detail, with an eye towa= rd migration from Stringprep to PRECIS. You might want to re-read that secti= on to determine the level of your concern. I'm sorry, were you expecting stateful reviewers? ;-) So maybe adding something to effect of "see 6.1 of that doc for more details= " would be enough. But I read the note to be about coexisting with or using o= f non-updated SASL mechanisms, while 6.1 seems more about migrating.=20= From nobody Wed Mar 11 14:44:05 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29F11A884B; Wed, 11 Mar 2015 14:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxbFhrk7VOav; Wed, 11 Mar 2015 14:44:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345F91A87C3; Wed, 11 Mar 2015 14:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=960; q=dns/txt; s=iport; t=1426110241; x=1427319841; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=WSzpp2tzZj3rbVNcRvmZEsF0UIrGZUJMgdvdCwbCWNo=; b=fCA1FQGn4GfG4bk8U6ErCTYgOwbmyEj/wic1Nzx8zNQFpevFQIpu+z9c zgAfbM8k6CZAei41qdLiPEzp+3iAI9gdvfcxY5CZ2KGQ6W8C7kzZI+XC/ QeKZDDYS38kiafqxTqk5kHqUdhu/WoNiQCpcZyxDilr6j/K6BzWMJXTdc k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D4CAALtgBV/5NdJa1cgwZSWgSDB7pohXeHN0wBAQEBAQF9hDkPAUU2AgUWCwILAwIBAgE1FgEMBgIBAYgrri2bLwEBAQEGAQEBAQEBARcEgSGRVoFFBYpziRGFdYEahVshjGMjggEdgW9QgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,384,1422921600"; d="scan'208";a="399732829" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP; 11 Mar 2015 21:44:00 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2BLi0jc024629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 21:44:00 GMT Received: from [10.129.24.54] (10.129.24.54) by xhc-rcd-x13.cisco.com (173.37.183.87) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 11 Mar 2015 16:44:00 -0500 Message-ID: <5500B71F.9060602@cisco.com> Date: Wed, 11 Mar 2015 15:43:59 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: , IETF XMPP Group , IETF PRECIS WG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.54] Archived-At: Subject: [xmpp] 6122bis WGLC Comments X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 21:44:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, I have read draft-ietf-xmpp-6122bis(-19), and support its publication. I think this document is clean and straight-forward (as one can be with i18n). I don't have any more to add over what Ben Campbell already noted. Thanks very much Peter for all the work! - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVALcfAAoJEDWi+S0W7cO1zsQH/Awxpy8E4pl60XhI5WjK5TT4 XIEH4jTaddESlbkxlf619k09+R6wyzKWXEfmQG+COsaEsWhPrqUfxgcWLAcuELvV fYwcMEBAWRDTNInaVQysf76PdwHBkpBst04MIEib+I4OgG/OkRLnnB+/0+oDUgiJ dEqGRJ/xqQUlI5NGrIOxAYMTYCLmSrPFHnhYxcoF4w3OMIYS40YhnNzLrEfKNL/z ZL+u34O+8OT+Mj8cuuavKtYIxA/HlgNe0k0vHfkdw6O2FGyi0dwRSzQ3xM/Z/M+4 dB0PM7grE8eHxFhGEtCjLpfIeiy+aKoCiwYdDaQgXZB/E7seHcKPbwAASxaaQW4= =xB1j -----END PGP SIGNATURE----- From nobody Mon Mar 23 07:46:47 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFC51A8ADC for ; Mon, 23 Mar 2015 07:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcLPiJoaKnyY for ; Mon, 23 Mar 2015 07:45:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E911A8AE2 for ; Mon, 23 Mar 2015 07:45:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323144532.29093.88868.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 07:45:32 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 07:46:45 -0700 Subject: [xmpp] Milestones changed for xmpp WG X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:45:35 -0000 Deleted milestone "Define a solution for end-to-end encryption.". URL: http://datatracker.ietf.org/wg/xmpp/charter/ From nobody Mon Mar 23 08:07:02 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B448A1A89A6 for ; Mon, 23 Mar 2015 08:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGMlMJLZWbRZ for ; Mon, 23 Mar 2015 08:06:57 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0E01A1A75 for ; Mon, 23 Mar 2015 08:06:57 -0700 (PDT) Received: from [31.133.176.150] (dhcp-b096.meeting.ietf.org [31.133.176.150]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2NF6s00033690 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 10:06:56 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-b096.meeting.ietf.org [31.133.176.150] claimed to be [31.133.176.150] From: "Ben Campbell" To: "XMPP Working Group" Date: Mon, 23 Mar 2015 10:06:49 -0500 Message-ID: <94B69AC2-4137-4B3D-BC56-E911AEA4D0E1@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9r5066) Archived-At: Subject: [xmpp] End-to-end milestone X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:06:59 -0000 Hi Everyone, Based on discussion between the chairs, draft authors, and are directors, we are removing the end-to-end milestone. This does not mean the e2e work is dead. If there is sufficient interest in continuing that work, we can start it back up in some other context (e.g. in a dedicated working group). Many thanks to the various draft authors who have worked on this so far. XMPP will continue to finish it’s other milestones, all of which are at the WGLC stage or later. When those are done, we expect to close the working group. Thanks! Ben. From nobody Mon Mar 23 10:29:17 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812961ACEA0; Mon, 23 Mar 2015 10:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIzT0R4Tttut; Mon, 23 Mar 2015 10:29:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B795A1ACEAF; Mon, 23 Mar 2015 10:28:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323172849.9271.62806.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 10:28:49 -0700 Archived-At: Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-20.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:29:12 -0000 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 : Peter Saint-Andre Filename : draft-ietf-xmpp-6122bis-20.txt Pages : 25 Date : 2015-03-23 Abstract: This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 23 11:45:03 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBFC1AD0CE for ; Mon, 23 Mar 2015 11:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXf0KIwvPVLZ for ; Mon, 23 Mar 2015 11:45:00 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B172B1AD0C3 for ; Mon, 23 Mar 2015 11:45:00 -0700 (PDT) Received: by yhim52 with SMTP id m52so45139722yhi.2 for ; Mon, 23 Mar 2015 11:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; s=swgoo; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4LYjjY3QJJMxtfzmKUbuvbh4VHdAN4T4jvmTXMnWgbQ=; b=ykxz02KBK9oTIZ0Li7kGuFw5Pfe+SwNEnsdoHQvACAlyQSttkpQXVwjPYkpPQcKYa1 uQR3ca/xPjVeiTYjBvIes0KtWRTKpFG/tCwLd9QgahAMLiiINTZR2Vr2NerfSohWQ0E2 LdyW9AGMitSgzZg5WpG93feJU/MbR66NUYlvA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4LYjjY3QJJMxtfzmKUbuvbh4VHdAN4T4jvmTXMnWgbQ=; b=iGzaz0QD42jSwB2KJd3JYXPguWq4aeUotgUjZ37xQYiuR3zxsCyDk1vS7Ukr+bLWHr 3iVMsjeUCD2fmyp8ROAOzCa82hcI7/wKZz+2m3N5Vym7tyXrDdj3vQPKvn5jZrJnyDsU oDTGL2g8uxMpqjeu+X0g/8gtq/o3lQnBkC/1Iy8mkzqlZtAERb1eoITOE5Bw0/+M5LZg GT7hGoBfmqHGaH/mS/lfMjitCrJzWox61fA83sDPY581MeS7IDTmfcLkEHViAFYpJt/p rOH6IxRSnFZmN+c6HV+YjLcFCBxsogrIMoNik/UX3vbfMAmFGf3WTf1EjqzBHoY8qW3G eosg== X-Gm-Message-State: ALoCoQmpmY+YAYMCx3CoXZFfH+swxCYRoZ3ggtLvJHLvFCYi6q6vnKi2fLCBy4U64qyske5xkAEN X-Received: by 10.55.24.159 with SMTP id 31mr1325567qky.74.1427136300061; Mon, 23 Mar 2015 11:45:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.179.202 with HTTP; Mon, 23 Mar 2015 11:44:19 -0700 (PDT) X-Originating-IP: [4.35.206.142] In-Reply-To: <20150323172849.9271.62806.idtracker@ietfa.amsl.com> References: <20150323172849.9271.62806.idtracker@ietfa.amsl.com> From: Sam Whited Date: Mon, 23 Mar 2015 13:44:19 -0500 Message-ID: To: internet-drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: xmpp@ietf.org, i-d-announce@ietf.org Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-20.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:45:02 -0000 On Mon, Mar 23, 2015 at 12:28 PM, 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 : Peter Saint-Andre > Filename : draft-ietf-xmpp-6122bis-20.txt > Pages : 25 > Date : 2015-03-23 > > Abstract: > This document defines the address format for the Extensible Messaging > and Presence Protocol (XMPP), including support for code points > outside the ASCII range. This document obsoletes RFC 6122. >From the text: > (e.g., under Unicode Normalization Form KC U+FE6B SMALL COMMERCIAL > AT decomposes to U+0040 COMMERCIAL AT, although note that this > decomposition does not occur under Unicode Normalization Form C, > which is used in this specification). Using an example which doesn't actually apply to the specification strikes me as a bad idea. Though it's pretty clearly stated that it's not actually applicable, this just seems unnecessary and confusing (you'll end up with a lot of test suites with this as a failing test, people emailing the various lists to ask about it, and finally them re-reading and figuring it out). This is a bit of a contrived problem, admittedly, but in the interest of clarity and simplicity I still think it makes sense to change it. Personally, I think it would be best to not have an example at all if no relevant example can be found (I didn't see one while glancing through the NFC definitions, but it was certainly not an exhaustive search). Best, Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Mon Mar 23 13:15:05 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD801A1A22 for ; Mon, 23 Mar 2015 13:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnUuc-UzdQS7 for ; Mon, 23 Mar 2015 13:15:02 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE311AD49B for ; Mon, 23 Mar 2015 13:14:57 -0700 (PDT) Received: by iedm5 with SMTP id m5so45134623ied.3 for ; Mon, 23 Mar 2015 13:14:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=v1Ew+hkPVCOhZlPMFPO3OG/ugeTCYbsO+FEhWDOSV9Q=; b=ItYsURN4dozX73QrAjmg1JqAtw4ndVuJqU0W0CHRUvxguH3DBjfF+/VPpWY9KxLZyp dGkgUIcDHvOcVNVdcWeScO2wP+jSqggq/zg76OzI+vXrtqgLeLmdpCYrcv1/Tiz51V4G 4gz+bfEtAT44JeiO/KOUuRL9kCSadah5qKPmAkZ0UWA6PCd36l+HkkAreUZXYIEqeEkK gTF2BEWkwQB43hCZPb/LAFr4PlQq1Eq0DgYFByJX4SxC87rUIOqHcUcQRpyizSpp7YgW XonWosKPxMrEiv9llD9oHX2y9Vv3tPm52fJpnRd6SmGDOSyHLy3xxTuLu8aeyR0suaF/ un7Q== X-Gm-Message-State: ALoCoQnD9eXAywCXrpVIwLlh0b1b0wpLdu2QjmhgZ86tkkkcUHGkVCkAYMjxxB15vSap1iwilS67 X-Received: by 10.50.176.196 with SMTP id ck4mr17380023igc.40.1427141697180; Mon, 23 Mar 2015 13:14:57 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id c76sm1263075ioc.16.2015.03.23.13.14.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 13:14:56 -0700 (PDT) Message-ID: <5510743D.2070703@andyet.net> Date: Mon, 23 Mar 2015 14:14:53 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sam Whited , internet-drafts@ietf.org References: <20150323172849.9271.62806.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: xmpp@ietf.org, i-d-announce@ietf.org Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-20.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:15:03 -0000 On 3/23/15 12:44 PM, Sam Whited wrote: > On Mon, Mar 23, 2015 at 12:28 PM, 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 : Peter Saint-Andre >> Filename : draft-ietf-xmpp-6122bis-20.txt >> Pages : 25 >> Date : 2015-03-23 >> >> Abstract: >> This document defines the address format for the Extensible Messaging >> and Presence Protocol (XMPP), including support for code points >> outside the ASCII range. This document obsoletes RFC 6122. > >>From the text: > >> (e.g., under Unicode Normalization Form KC U+FE6B SMALL COMMERCIAL >> AT decomposes to U+0040 COMMERCIAL AT, although note that this >> decomposition does not occur under Unicode Normalization Form C, >> which is used in this specification). > > Using an example which doesn't actually apply to the specification > strikes me as a bad idea. Though it's pretty clearly stated that it's > not actually applicable, this just seems unnecessary and confusing > (you'll end up with a lot of test suites with this as a failing test, > people emailing the various lists to ask about it, and finally them > re-reading and figuring it out). > > This is a bit of a contrived problem, admittedly, but in the interest > of clarity and simplicity I still think it makes sense to change it. > Personally, I think it would be best to not have an example at all if > no relevant example can be found (I didn't see one while glancing > through the NFC definitions, but it was certainly not an exhaustive > search). Now that we've switched to NFC, there are no examples that apply. However, the principle enunciated here is still valid (because it is possible that examples might crop up in future versions of Unicode): 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 So removing the example sees appropriate at this time. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Mar 24 08:50:55 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5821A8BB7; Tue, 24 Mar 2015 08:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m8BuSFfhtR0; Tue, 24 Mar 2015 08:50:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B008D1A8961; Tue, 24 Mar 2015 08:50:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324155049.5707.52124.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 08:50:49 -0700 Archived-At: Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-dna-10.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:50:51 -0000 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 : Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP) Authors : Peter Saint-Andre Matthew Miller Philipp Hancke Filename : draft-ietf-xmpp-dna-10.txt Pages : 20 Date : 2015-03-24 Abstract: This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server host name (e.g., hosting.example.net), which is especially important in multi-tenanted environments where the same target server hosts a large number of domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-dna-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-dna-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 24 08:53:14 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99901A8BB5 for ; Tue, 24 Mar 2015 08:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.19 X-Spam-Level: X-Spam-Status: No, score=-13.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yimGlBWPxMoy for ; Tue, 24 Mar 2015 08:53:09 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E931A8961 for ; Tue, 24 Mar 2015 08:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2746; q=dns/txt; s=iport; t=1427212387; x=1428421987; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=0fqKVDO12eRHIb/WhBymIc2VQcObIjBFKcLSRPeqbvw=; b=LrAMcUiKG5eensyIzjepvkm1jEVzT10Cd+FdlrVQXydL3M78dPOUHU7H wwZfmjwzt3LOONTLBifUMQl3iTfdEXLqs8ckXcNOFsbdtikiUq21bTcPq Jo98YAH0zUTujHz6G9ue8B77IRPyfTN++3NvZ4bBswB9yintW/ra8sqxC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DbNgC6hxFV/4UNJK1cgwZSVQUEgw6wfZBuBoFFCoV1AiiBEjgUAQEBAQEBAXyEDAkBAQQBAQEgSwoBEAsYAgIFFgsCAgkDAgECARUwEwEFAgEBBYVogj4IBa52mhQBAQEBAQEEAQEBAQEBHIEhigCEQzMHgmgPgTYFixOJLIYAgRs6gnaCOIcHhiIiggEdgW5RAYFDfwEBBQ X-IronPort-AV: E=Sophos;i="5.11,458,1422921600"; d="scan'208";a="134928611" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 24 Mar 2015 15:53:06 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2OFr6qs023970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 24 Mar 2015 15:53:06 GMT Received: from [10.89.8.107] (10.89.8.107) by xhc-rcd-x15.cisco.com (173.37.183.89) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 24 Mar 2015 10:53:06 -0500 Message-ID: <55118861.5060309@cisco.com> Date: Tue, 24 Mar 2015 10:53:05 -0500 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 CC: References: <20150324155049.5707.52124.idtracker@ietfa.amsl.com> In-Reply-To: <20150324155049.5707.52124.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.89.8.107] Archived-At: Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-10.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:53:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This revision should address all of the feedback we've received. Thanks again everyone! - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 3/24/15 10:50 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 : Domain Name Associations (DNA) in the Extensible > Messaging and Presence Protocol (XMPP) Authors : Peter > Saint-Andre Matthew Miller Philipp Hancke Filename : > draft-ietf-xmpp-dna-10.txt Pages : 20 Date : > 2015-03-24 > > Abstract: This document improves the security of the Extensible > Messaging and Presence Protocol (XMPP) in two ways. First, it > specifies how to establish a strong association between a domain > name and an XML stream, using the concept of "prooftypes". Second, > it describes how to securely delegate a service domain name (e.g., > example.com) to a target server host name (e.g., > hosting.example.net), which is especially important in > multi-tenanted environments where the same target server hosts a > large number of domains. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-xmpp-dna-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-dna-10 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ I-D-Announce > mailing list I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft > directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVEYhhAAoJEDWi+S0W7cO1nNwH/2anIXSxbozOeKbWwzjWhsMB BqBluH07sN1tBkcMcRRn28EyZaMZAqMIt01EMdNzdE5XXA4zX+54OY5FEewJFTYm XqK9d6pLEer60QbRNxNnOjTzDm9q3+vMBAQuGjjXupjLrSc258fRiOyiOSzqqcYC WVJt/CoXdxCaWdX+VmATcKbD0wwLIjkYRxD00K46YKP8lxkUg9OZHCsF+57eDP+C xx2o6SBL+k7wWDZPpP3OES2SwO7H6k7yoDetgzioNA6fInqrJliaZe2+xJhANcBu t1oHQmq2rh8LSSb8Lzj4hLmWwbx9vt9npOTvQX945M2w7TZ+JCfWA+IkLHLSjYU= =st6V -----END PGP SIGNATURE-----