From fschmaus@gmail.com Wed May 6 11:24: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 4CD771A903E; Wed, 6 May 2015 11:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 LfRN20sPrHgR; Wed, 6 May 2015 11:24:51 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (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 4EFFF1A8F42; Wed, 6 May 2015 11:24:51 -0700 (PDT) Received: by widdi4 with SMTP id di4so212859180wid.0; Wed, 06 May 2015 11:24:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=ymPhQVXgZiZrtiEbrS4IarSmgvdvq5lr3NpkDqWHjKk=; b=P9hk+Jq7WregusRproCLeoqxPMbgXfChSRqaUuy0uVQidk0SeDV6Pb2DXpqVV9Nscw wyMOjtPJe3OPQQwoFYO1ZfsaVzDP7aptel9+awZJ1UPpbxAq7snR+moJKCBtF/vUy8yh YrC2b9lquRErmJZVNyvLQNqwAtrnJ4tYWgUWtLWNFY7dgsDIPq6De1qGG7yKSwWX/Uqo xigaC48+M2MiKlDax7n2v6qAu7QvEkOCrlU1qqMl7qqQ1ffe2mrqfa7o5ZqFn5ze1Bxf JYYDc0WbbYGb7mVDJ1PYfpgrOccB1lc3FUwXJg44UAZx5FQnHYsO/Ma/0RQtaAEmYoCG /D/w== X-Received: by 10.194.93.195 with SMTP id cw3mr53603wjb.150.1430936690052; Wed, 06 May 2015 11:24:50 -0700 (PDT) Received: from [192.168.100.19] (ppp-62-216-212-216.dynamic.mnet-online.de. [62.216.212.216]) by mx.google.com with ESMTPSA id z13sm3905272wjr.44.2015.05.06.11.24.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2015 11:24:48 -0700 (PDT) Message-ID: <554A5C70.9050805@geekplace.eu> Date: Wed, 06 May 2015 20:24:48 +0200 From: Florian Schmaus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: xmpp@ietf.org, draft-ietf-xmpp-6122bis.all@ietf.org Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QE6txosuIQOcDhQ09xlOSg1m9fr9vpCcU" Archived-At: Subject: [xmpp] 6122bis nit 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, 06 May 2015 18:27:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QE6txosuIQOcDhQ09xlOSg1m9fr9vpCcU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, I know that 6122bis's IESG state is "Publication Requested", but I've a minor remark: 3.1: resourcepart =3D 1*1023(resourcebyte) ; ; an "opaquebyte" is a byte used to represent a Shouldn't 'resourcebyte' be 'opaquebyte'? This was introduced with -18: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-xmpp-6122bis-17&url2=3Ddra= ft-ietf-xmpp-6122bis-18 - Florian --QE6txosuIQOcDhQ09xlOSg1m9fr9vpCcU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVSlxwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMzU3QjAxODY1QjI1MDNDMTg0NTNEMjA4 Q0FDMkE5Njc4NTQ4RTM1AAoJEIysKpZ4VI41YuIH/1UQ8jlzvgGuXF9lFEolz8IA FvZMr8qqoJFQNZZgZsaz7qaMjd73L8ydIzM0UqTJso6JXPC58e9VU4MRW+ZHQhhU VuEkDK9bnFVRx+5uYqXqA5YxhiJ8BPtxovRywR+Ubjz6isP52X0Yu7fu1mMO5tnY WQqZETL9dHghXhz+M4+Vgo3kPoKpzTGa2QKsEsWHbcb2VpyHEs0eYft/uFPScsY9 lWogVzr8GFmo5tCrcD90NrLGq6DU44js1Sw7V3OAiFTKEHtxu+TbN5bDkX0SLEf+ dFIgbysr5ycF398BQIRn2PRaOGXv86y677dGDXV4aLWkZPxbWujeEOV41l8yAlo= =Ne9p -----END PGP SIGNATURE----- --QE6txosuIQOcDhQ09xlOSg1m9fr9vpCcU-- From nobody Wed May 6 11:35: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 E04E71A8863 for ; Wed, 6 May 2015 11:35:08 -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 nRJJIamNfZPW for ; Wed, 6 May 2015 11:35:07 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (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 4DAC91A1E0B for ; Wed, 6 May 2015 11:35:07 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so103881363igb.0 for ; Wed, 06 May 2015 11:35:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=QmVhT6/zv1OqXSNQ+OjPmbeE9RxpnKHfygXsYHPDxL4=; b=Jq0IcAMefnZVaAwrH/cDq9MpzR85k0aVDXjEuTFQSHLQYEogFHm2K2eqk0aCDucvhm f4gZ2mLpmXsnWHKEnw7Z6zjDtgx8hylzjGOeR70bTpj2VXbCtfcR0ZvpdKvWhlBPZJiI mbihZA4g7XLpPYxf3DY4l0dO+jdDSqbIVDKbrh47vBx3wf2g72/RkTzGplDGIU+FOg7k T9bejCUx2aJ6hj+xgZuIDGHenoBg81gHPV0Gldqe++dE1L+3IBzd99JrsNqUCWF2HBKY B04+MnHJ8vbDe8ohKjilwcHtv9WKeeB0iEbNgmtPcPN6uCFAx9g74YROd+KhCIVaIRvS N7TQ== X-Gm-Message-State: ALoCoQkrM/M3BmcmgUJMFRAv1FrtLV1ih/iLLHb/8x+TuYQciJJMJOZKh1BDSULOYO2PRPXb2dov X-Received: by 10.50.112.73 with SMTP id io9mr9965726igb.18.1430937306777; Wed, 06 May 2015 11:35:06 -0700 (PDT) Received: from [10.0.0.5] (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j39sm1637604iod.41.2015.05.06.11.35.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 May 2015 11:35:06 -0700 (PDT) References: <554A5C70.9050805@geekplace.eu> Mime-Version: 1.0 (1.0) In-Reply-To: <554A5C70.9050805@geekplace.eu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12F70) From: Peter Saint-Andre Date: Wed, 6 May 2015 12:35:04 -0600 To: Florian Schmaus Archived-At: Cc: "xmpp@ietf.org" , "draft-ietf-xmpp-6122bis.all@ietf.org" Subject: Re: [xmpp] 6122bis nit 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, 06 May 2015 18:35:09 -0000 Yes. I will fix this before publication. Good catch!=20 > On May 6, 2015, at 12:24 PM, Florian Schmaus wrote: >=20 > Hi everyone, >=20 > I know that 6122bis's IESG state is "Publication Requested", but I've a > minor remark: >=20 > 3.1: >=20 > resourcepart =3D 1*1023(resourcebyte) > ; > ; an "opaquebyte" is a byte used to represent a >=20 > Shouldn't 'resourcebyte' be 'opaquebyte'? >=20 > This was introduced with -18: > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-xmpp-6122bis-17&url2=3Ddraf= t-ietf-xmpp-6122bis-18 >=20 > - Florian >=20 > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From nobody Wed May 6 11:54: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 780DF1B2E4A for ; Wed, 6 May 2015 11:54:04 -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 1FdtgTJFMi10 for ; Wed, 6 May 2015 11:54:02 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (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 7E5FA1B2E44 for ; Wed, 6 May 2015 11:54:02 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so24286155ied.1 for ; Wed, 06 May 2015 11:54:02 -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=Pb1/WFsTpMMrwj/yI3jMr3dgYB4U2712vlvwdbs0208=; b=MyuO35NGsB3mPRaXVuy9//mB4x6kNT80fMIjmdbh783O/FVflLISh5t3oX8UQ0rx7o VXA6GlRrqsWoX2mimQIe7K1bb6XdR9B8bju7gZZ/v7pmrhmcwIpW3UXX5URHBiJ2G116 vKVbKk9KYnZEei7kIENG/wjf43MWDJ5z99VQKrAI/ImbxfQkRSDnR+TJbmtyNtG9G/yV M3r/dWkk7FtM8XHtcYcI8tJ+J02fYnteA/bMixTSkQZHZ2JwVlmr1AG6YtD9sAaU4Cfs PYGLhQHwmqUQZSYjeYZyXNGlK1ptuBg+IqmS1UO/aNINbnd/HEIHAg21ziP/qwMxwG40 ieiQ== X-Gm-Message-State: ALoCoQljHof2cCMiZtjiOHCMNOd0SZIR+1AH1oYqFI+G0nl7DhdW7LziwR/e538cDoeVtbsmHVkI X-Received: by 10.50.23.105 with SMTP id l9mr10036986igf.13.1430938441951; Wed, 06 May 2015 11:54:01 -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 k74sm1677671iok.30.2015.05.06.11.54.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2015 11:54:01 -0700 (PDT) Message-ID: <554A6346.9010406@andyet.net> Date: Wed, 06 May 2015 12:53:58 -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.6.0 MIME-Version: 1.0 To: Florian Schmaus , xmpp@ietf.org, draft-ietf-xmpp-6122bis.all@ietf.org References: <554A5C70.9050805@geekplace.eu> In-Reply-To: <554A5C70.9050805@geekplace.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [xmpp] 6122bis nit 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, 06 May 2015 18:54:04 -0000 On 5/6/15 12:24 PM, Florian Schmaus wrote: > Hi everyone, > > I know that 6122bis's IESG state is "Publication Requested", but I've a > minor remark: > > 3.1: > > resourcepart = 1*1023(resourcebyte) > ; > ; an "opaquebyte" is a byte used to represent a > > Shouldn't 'resourcebyte' be 'opaquebyte'? Fixed in SVN: https://svn.tools.ietf.org/svn/wg/xmpp/draft-ietf-xmpp-6122bis.xml Thanks for the bug report! Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon May 11 08:33:53 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 527BA1A90D8; Mon, 11 May 2015 08:33:50 -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 JchkwnOEOGnP; Mon, 11 May 2015 08:33:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE3B1A9060; Mon, 11 May 2015 08:33: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: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511153349.29114.68145.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 08:33:49 -0700 Archived-At: Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-22.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, 11 May 2015 15:33:50 -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-22.txt Pages : 25 Date : 2015-05-11 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: https://tools.ietf.org/html/draft-ietf-xmpp-6122bis-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-22 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 May 11 08:34:51 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 90CE81A90C8 for ; Mon, 11 May 2015 08:34:50 -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 difOabOldjES for ; Mon, 11 May 2015 08:34:49 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (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 32E961A90A4 for ; Mon, 11 May 2015 08:34:49 -0700 (PDT) Received: by iecmd7 with SMTP id md7so33207139iec.3 for ; Mon, 11 May 2015 08:34:48 -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=kWvRZ9Z3FS71JSSPV3MwOxMDbkKxLOfooLbZ5w8mNWU=; b=MEzYJZO1pjV0CeGvKN5NuAsx3C/+WIT4TbuC5DltuwEDeWPHvfJVLNXHNvgZT/otRq EZK5LbfzXaxZ/eHJUKKc8rEVm/PjcsIMkV+Pa5R+HjX6XN6iANYdoTPLM0S2UW6r9ZK/ VolpN3XdeywjFFZGInuIGXNtIUvpzPAXtYyhcSVsilfbY9FTv2jkmT7Jodq10z+ZAmjO 4fvc/VkIGyEdK628QgYO4Kvto3qkGU51+rxhCqrQAW2aFT/WWcajz9F31dUtjLg/QAAI ZtWIuHnpoVoPMmroqflaHPo07A2kOfdDETF1OSS9ta7rqM/LwoS53yABshv/TU837ouC +WvA== X-Gm-Message-State: ALoCoQm4vddi3W2WpBDKmJB4ZKvmHpkVYY2qxg7ImFqGFtsLrEHUb4kEQFyu+nT1XR2QkH1AzqPR X-Received: by 10.50.13.10 with SMTP id d10mr15064707igc.20.1431358483670; Mon, 11 May 2015 08:34:43 -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 i191sm6329036ioe.0.2015.05.11.08.34.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2015 08:34:42 -0700 (PDT) Message-ID: <5550CC10.6050508@andyet.net> Date: Mon, 11 May 2015 09:34: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.6.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <20150511153349.29114.68145.idtracker@ietfa.amsl.com> In-Reply-To: <20150511153349.29114.68145.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-22.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, 11 May 2015 15:34:50 -0000 A small fix to the bug that Florian Schmaus noted... Peter On 5/11/15 9:33 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. > > Title : Extensible Messaging and Presence Protocol (XMPP): Address Format > Author : Peter Saint-Andre > Filename : draft-ietf-xmpp-6122bis-22.txt > Pages : 25 > Date : 2015-05-11 > > 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: > https://tools.ietf.org/html/draft-ietf-xmpp-6122bis-22 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-22 > > > 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 > From nobody Mon May 18 15:09: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 CF3151ACD5C for ; Mon, 18 May 2015 15:09:34 -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 jpXI3l47zk6G for ; Mon, 18 May 2015 15:09:32 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (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 A1EEE1A1BE9 for ; Mon, 18 May 2015 15:09:32 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so70819687pdb.1 for ; Mon, 18 May 2015 15:09:32 -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=zt980zlLZ1XCerhpAOiOTRvGcKJhKt+Py8kmkv/mZiU=; b=Os1D/Qq1uGCY8Lehz+fFIXcPVg/u1Iv4mg6ii5GyHGB6GsibUAmvybCMOpb31rPpYs v9sDm2NtbttafPrQbWDhjGX5NjfjP/FkF5fzZyIloe85OTSfeVHKO7WFlR27+XmoMeqL U7yWNURg0PxhehvPfLBgKYdi9tqza3Qg5dZFbXcgn9w4PHLx7lkkI0oD80a+XXYqu2E6 iBoeYyGFQXUlDEIy+D9OU3hkg3aeLEdxmf1VzuZSW6MhEUbWZ9yYyhtsp2fMqRt/koRU 1xDVKDIJcnZ066d4jovaBkxhN5MUe16Rh/Zy/u9kJ/5wo6CB/nM5X+8KjK0e+R7HwJJs 3niQ== X-Gm-Message-State: ALoCoQm0PgirQZxN2mkbs1tS+T2hnN/07jGE+hA62Dq6pROR2a3JDnAZqsil1ScsQ86+3z78U1xe X-Received: by 10.66.159.68 with SMTP id xa4mr48734763pab.105.1431986972355; Mon, 18 May 2015 15:09:32 -0700 (PDT) Received: from aither.local ([2620:101:80fc:232:69a0:90a5:a596:1371]) by mx.google.com with ESMTPSA id nw8sm11022066pdb.30.2015.05.18.15.09.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2015 15:09:31 -0700 (PDT) Message-ID: <555A6319.9010703@andyet.net> Date: Mon, 18 May 2015 15:09:29 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: XMPP Working Group References: <555A61CA.2020108@andyet.net> In-Reply-To: <555A61CA.2020108@andyet.net> X-Forwarded-Message-Id: <555A61CA.2020108@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [xmpp] Fwd: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP 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, 18 May 2015 22:09:35 -0000 This thread started on the DANE WG list but I think it belongs here. -------- Forwarded Message -------- Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP Date: Mon, 18 May 2015 15:03:54 -0700 From: Peter Saint-Andre - &yet To: dane@ietf.org On 5/17/15 9:55 AM, Kim Alvefur wrote: > Hello list! Hi Zash! > Georg Lukas noted that section 4.1 says, in the context of XMPP, to use > to='xmpp23.hosting.example.net' in the stream header, as that is the > "functional equivalent" of SNI in XMPP. However, that conflicts with > the current semantics of 'to' being the service domain name to the > server host name. That will break many, if not all, deployed servers. > The server should know what certificate to use for the indicated domain > name. > > http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1 Hmm. First, all draft-ietf-dane-srv says is that you don't need to use SNI in XMPP because we already have a way for the TLS client to specify which domain name it expects of the TLS server, i.e., the 'to' address of the initial stream header. Second, draft-ietf-xmpp-dna is the document that specifies the behavior of XMPP entities. So IMHO this is a topic for the XMPP WG list, not the DANE WG list. I'll forward this message to that list and continue the conversation there. :-) Peter -- Peter Saint-Andre https://andyet.com/ -- Peter Saint-Andre https://andyet.com/ From nobody Mon May 18 15:24:11 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 A39091A876E for ; Mon, 18 May 2015 15:24:10 -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 6XcyGUQfZXrC for ; Mon, 18 May 2015 15:24:06 -0700 (PDT) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (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 A3DFC1ACD81 for ; Mon, 18 May 2015 15:24:06 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so166693654pdb.0 for ; Mon, 18 May 2015 15:24:06 -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=OrfvKpWnybp+I5uR9Ukz31/lyNejN2S3fZg/XKtpGFc=; b=axaHr9KfU3iXWiYrZ1AubZK0VecWS4VsC6mXLWNcG1ePtub6Pq7L5Vg64EmH0xpx7O fIsQ06Lxux9c5YW58QUvo9B00uNhHqp4VmEv3DTlexjotCvkGQYZM77kgKRRlNmCeQeJ LeHdH2Hhnx5s2znLN5flEug8cotdJqWxUkYepGCy3KLeJOIo1gXXDnwaoZW2axELDZ4N Eh+LACuq35zcmfYs0QduoUvl0UP8WSFTEzjaCqLfoWB5YcMF4/zwfr+TnXifpUc2TLRV 0r9JkH9xr3sJbJRKcloUPSnMFgTKcoeMOgvB4/tpeS52/F2nWR3ex3rMBFOfgj7e7T7x F5mA== X-Gm-Message-State: ALoCoQlPuFQsepy4Z+C72T44+3Zgp3Fby/ghZVBqYWWwtlnV0e39lJR/VeDzjmkNmtwM0xdffZ8w X-Received: by 10.66.124.226 with SMTP id ml2mr48123269pab.118.1431987846332; Mon, 18 May 2015 15:24:06 -0700 (PDT) Received: from aither.local ([2620:101:80fc:232:69a0:90a5:a596:1371]) by mx.google.com with ESMTPSA id pa1sm11023669pdb.73.2015.05.18.15.24.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2015 15:24:05 -0700 (PDT) Message-ID: <555A6684.4000100@andyet.net> Date: Mon, 18 May 2015 15:24:04 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: XMPP Working Group References: <555A61CA.2020108@andyet.net> <555A6319.9010703@andyet.net> In-Reply-To: <555A6319.9010703@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [xmpp] Fwd: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP 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, 18 May 2015 22:24:10 -0000 On 5/18/15 3:09 PM, Peter Saint-Andre - &yet wrote: > This thread started on the DANE WG list but I think it belongs here. > > > -------- Forwarded Message -------- > Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP > Date: Mon, 18 May 2015 15:03:54 -0700 > From: Peter Saint-Andre - &yet > To: dane@ietf.org > > On 5/17/15 9:55 AM, Kim Alvefur wrote: >> Hello list! > > Hi Zash! > >> Georg Lukas noted that section 4.1 says, in the context of XMPP, to use >> to='xmpp23.hosting.example.net' in the stream header, as that is the >> "functional equivalent" of SNI in XMPP. However, that conflicts with >> the current semantics of 'to' being the service domain name to the >> server host name. That will break many, if not all, deployed servers. >> The server should know what certificate to use for the indicated domain >> name. >> >> http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1 > > Hmm. > > First, all draft-ietf-dane-srv says is that you don't need to use SNI in > XMPP because we already have a way for the TLS client to specify which > domain name it expects of the TLS server, i.e., the 'to' address of the > initial stream header. > > Second, draft-ietf-xmpp-dna is the document that specifies the behavior > of XMPP entities. So IMHO this is a topic for the XMPP WG list, not the > DANE WG list. I'll forward this message to that list and continue the > conversation there. :-) So, draft-ietf-xmpp-dna (§5.1) says: The DANE prooftype makes use of the DNS-Based Authentication of Named Entities [RFC6698], specifically the use of DANE with DNS SRV records [I-D.ietf-dane-srv]. For XMPP purposes, the following rules apply: o If there is no SRV resource record, pursue the fallback methods described in [RFC6120]. o Use the 'to' address of the initial stream header to determine the domain name of the TLS client's reference identifier (since use of the Server Name Indication extension (TLS SNI) [RFC6066] is purely discretionary in XMPP, as mentioned in [RFC6120]). As I understand it, Kim is saying that if a client were to (i) discover via SRV methods that the service domain "example.com" is located at the target server "hosting.example.net" and (ii) discover via DANE methods that the expected identity of the certificate for the connection endpoint is not the service domain but the target server host name, then (iii) it would break things on the XMPP network for the client to specify a 'to' address of the target server host name instead of the service domain because (iv) the XMPP server software figures out which certificate to present based on the service domain, not the target server host name. I'm not sure about that. It seems to me that if an application service provider is doing the whole DANE thing, then it will always just present a certificate for "hosting.example.net" instead of for "example.com" or any particular service domain hosted there, so why does it even need to differentiate? Now, there might be some other reason to want the 'to' address to be the service domain (e.g., maybe some cluster or machine is dedicated for hosting that service domain, or the application service provider wants to terminate spurious connections as quickly as possible and not use TLS/SASL resources and round trips for accounts that it doesn't host), but I'm not yet convinced that choosing the right certificate is the reason. However, I freely admit that I might be missing something, so enlightenment would be appreciated. :) Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon May 18 15:26: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 D4C4E1ACD7E for ; Mon, 18 May 2015 15:26:03 -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 yrCSdkvlSj6q for ; Mon, 18 May 2015 15:26:02 -0700 (PDT) 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 34EDF1A876E for ; Mon, 18 May 2015 15:26:02 -0700 (PDT) Received: by obbkp3 with SMTP id kp3so142672412obb.3 for ; Mon, 18 May 2015 15:26:01 -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=g53HXP9M/W9njahjzDMSkaqPB1BohD9VdSB81G8mCu8=; b=LF8xvqmuPEvW9A83zmSJxGlSqnYhXECSOmQGLT3EkN0BX1gM4gDiUsLfI8MtkAblpk vrxhk9zn7ObFDL+yyEgpVNU52QjY3ECjZGa0OV0lbPS/vOqvSh3WpI1VA7SwDI4q7ZMX 22mfAkL6LahYfMgwJge9mNx4VfWqDyqAdBhaQ= 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=g53HXP9M/W9njahjzDMSkaqPB1BohD9VdSB81G8mCu8=; b=Dupzz1ecIqW22X3wCnSyIsa3i2DO/ueyDzuOW6wrMIGOrWZS+TvuHDoZvg+Ei5to2B 7cTx+6Rtqc4bPGXZR4fEiY98LQujyweNlSEAvG1Of1gpVuz3C2iWdGYWbAdpFBhJk4a/ D1vQNGzNJq4AXCVS8lIXJ9KCXm3h87q4muMHt2AZmlTvnXgrjHeUHFyt4KTGtxkmbZbk fMdrhDt0xGFDgT+4fuHzzmtIrBqVQBB9XnEpWp+l29FrUv5pfVe3m2g7o5sE5koOk3eG C0tSiKi097Rw2EV+mAhN+YWdeYTpRp2pgVWXaJfs3po41gEBOKVw0nN9pgGomYIuXIDP Agdw== X-Gm-Message-State: ALoCoQkGy6+uyiRJVdHaX+lHkTN1PRzQdtip3CH3zA56wLMLiVBw9tCNqqsR2aTa4zKMtmVTLwZA MIME-Version: 1.0 X-Received: by 10.202.195.23 with SMTP id t23mr20121095oif.117.1431987961664; Mon, 18 May 2015 15:26:01 -0700 (PDT) Received: by 10.60.119.4 with HTTP; Mon, 18 May 2015 15:26:01 -0700 (PDT) Received: by 10.60.119.4 with HTTP; Mon, 18 May 2015 15:26:01 -0700 (PDT) In-Reply-To: <555A6319.9010703@andyet.net> References: <555A61CA.2020108@andyet.net> <555A6319.9010703@andyet.net> Date: Mon, 18 May 2015 23:26:01 +0100 Message-ID: From: Dave Cridland To: "Peter Saint-Andre - &yet" Content-Type: multipart/alternative; boundary=001a1137c846c736d8051662ad40 Archived-At: Cc: XMPP Working Group Subject: Re: [xmpp] Fwd: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP 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, 18 May 2015 22:26:04 -0000 --001a1137c846c736d8051662ad40 Content-Type: text/plain; charset=UTF-8 On 18 May 2015 23:09, "Peter Saint-Andre - &yet" wrote: > > This thread started on the DANE WG list but I think it belongs here. > > > -------- Forwarded Message -------- > Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP > Date: Mon, 18 May 2015 15:03:54 -0700 > From: Peter Saint-Andre - &yet > To: dane@ietf.org > > On 5/17/15 9:55 AM, Kim Alvefur wrote: >> >> Hello list! > > > Hi Zash! > >> Georg Lukas noted that section 4.1 says, in the context of XMPP, to use >> to='xmpp23.hosting.example.net' in the stream header, as that is the >> "functional equivalent" of SNI in XMPP. However, that conflicts with >> the current semantics of 'to' being the service domain name to the >> server host name. That will break many, if not all, deployed servers. >> The server should know what certificate to use for the indicated domain >> name. >> >> http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1 > > > Hmm. > > First, all draft-ietf-dane-srv says is that you don't need to use SNI in > XMPP because we already have a way for the TLS client to specify which > domain name it expects of the TLS server, i.e., the 'to' address of the > initial stream header. > Actually, it's a interesting problem. As I understand it, SNI is unencrypted in the handshake, so offers no value, but could easily cause major confusion if used, since it is not clear which might take precedence. However, my understanding - possibly flawed - is that TLS version 1.3 introduces encrypted handshakes, and then it might be useful to hide the server domains used. > Second, draft-ietf-xmpp-dna is the document that specifies the behavior > of XMPP entities. So IMHO this is a topic for the XMPP WG list, not the > DANE WG list. I'll forward this message to that list and continue the > conversation there. :-) > > Peter > > -- > Peter Saint-Andre > https://andyet.com/ > > -- > Peter Saint-Andre > https://andyet.com/ > > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp --001a1137c846c736d8051662ad40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 18 May 2015 23:09, "Peter Saint-Andre - &yet" <peter@andyet.net> wrote:
>
> This thread started on the DANE WG list but I think it belongs here. >
>
> -------- Forwarded Message --------
> Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP
> Date: Mon, 18 May 2015 15:03:54 -0700
> From: Peter Saint-Andre - &yet <peter@andyet.net>
> To: dane@ietf.org
>
> On 5/17/15 9:55 AM, Kim Alvefur wrote:
>>
>> Hello list!
>
>
> Hi Zash!
>
>> Georg Lukas noted that section 4.1 says, in the context of XMPP, t= o use
>> to=3D'xmpp23.hos= ting.example.net' in the stream header, as that is the
>> "functional equivalent" of SNI in XMPP.=C2=A0 However, t= hat conflicts with
>> the current semantics of 'to' being the service domain nam= e to the
>> server host name.=C2=A0 That will break many, if not all, deployed= servers.
>> The server should know what certificate to use for the indicated d= omain
>> name.
>>
>> http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1 >
>
> Hmm.
>
> First, all draft-ietf-dane-srv says is that you don't need to use = SNI in
> XMPP because we already have a way for the TLS client to specify which=
> domain name it expects of the TLS server, i.e., the 'to' addre= ss of the
> initial stream header.
>

Actually, it's a interesting problem. As I understand it= , SNI is unencrypted in the handshake, so offers no value, but could easily= cause major confusion if used, since it is not clear which might take prec= edence.

However, my understanding - possibly flawed - is that TLS ve= rsion 1.3 introduces encrypted handshakes, and then it might be useful to h= ide the server domains used.

> Second, draft-ietf-xmpp-dna is the document that specif= ies the behavior
> of XMPP entities. So IMHO this is a topic for the XMPP WG list, not th= e
> DANE WG list. I'll forward this message to that list and continue = the
> conversation there. :-)
>
> Peter
>
> --
> Peter Saint-Andre
> https://andyet.com/
>
> --
> Peter Saint-Andre
> https://andyet.com/
>
>
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.iet= f.org/mailman/listinfo/xmpp

--001a1137c846c736d8051662ad40-- From nobody Mon May 18 16:32:53 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 66A9D1B2AFF for ; Mon, 18 May 2015 16:32:52 -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 W6YMh6pQknUV for ; Mon, 18 May 2015 16:32:50 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (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 9B63A1A8776 for ; Mon, 18 May 2015 16:32:50 -0700 (PDT) Received: by pabru16 with SMTP id ru16so171482450pab.1 for ; Mon, 18 May 2015 16:32:49 -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=BzQqpw139pp39QsVy6XoRxUHXGFn67kHFjYyscNWA/c=; b=Eim11qhj007ED/cXeS8Pjf7n5hpJjVBRqQlxS42vC1AcjthIFeufJtA9UY3LSlUwN+ xoIdoaJPohfpy0bMI5AeYZagAsItXCGnOClrQbEhZL9upk42fPk09qTFlEkVHfiVxooj UsEoHuDeIta1VPTWgVNeBwp21tiTxH2PDpL4UDpL41LWT0R97gUUPQZnDHdtKyMrhZlp Z8Tkc9T/RpF9Em7J2JplWbWBDny5adJ4DYZi8FdF6NYv1VcuVRb/Pm3JL9+6jndRdzzA uTmru/bQnYbhdn4YRVhyOTcaWwQu1khJEFwvavGMZelfMva0whiK13SUPXTgmQSvJ3sE dbUg== X-Gm-Message-State: ALoCoQlUY71MvTXYq0aJiFmc/EDEOjaWWH3hROrrWT8mjmCni29rxF5BH7bIzzPplpdP0KrVBo8Z X-Received: by 10.66.117.233 with SMTP id kh9mr49321620pab.103.1431991969686; Mon, 18 May 2015 16:32:49 -0700 (PDT) Received: from aither.local (guest.mtv2.mozilla.com. [63.245.221.34]) by mx.google.com with ESMTPSA id qz7sm11096344pbc.11.2015.05.18.16.32.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2015 16:32:48 -0700 (PDT) Message-ID: <555A769D.6060003@andyet.net> Date: Mon, 18 May 2015 16:32:45 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Dave Cridland References: <555A61CA.2020108@andyet.net> <555A6319.9010703@andyet.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: XMPP Working Group Subject: Re: [xmpp] Fwd: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP 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, 18 May 2015 23:32:52 -0000 On 5/18/15 3:26 PM, Dave Cridland wrote: > > On 18 May 2015 23:09, "Peter Saint-Andre - &yet" > wrote: > > > > This thread started on the DANE WG list but I think it belongs here. > > > > > > -------- Forwarded Message -------- > > Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP > > Date: Mon, 18 May 2015 15:03:54 -0700 > > From: Peter Saint-Andre - &yet > > > To: dane@ietf.org > > > > On 5/17/15 9:55 AM, Kim Alvefur wrote: > >> > >> Hello list! > > > > > > Hi Zash! > > > >> Georg Lukas noted that section 4.1 says, in the context of XMPP, to use > >> to='xmpp23.hosting.example.net ' > in the stream header, as that is the > >> "functional equivalent" of SNI in XMPP. However, that conflicts with > >> the current semantics of 'to' being the service domain name to the > >> server host name. That will break many, if not all, deployed servers. > >> The server should know what certificate to use for the indicated domain > >> name. > >> > >> http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1 > > > > > > Hmm. > > > > First, all draft-ietf-dane-srv says is that you don't need to use SNI in > > XMPP because we already have a way for the TLS client to specify which > > domain name it expects of the TLS server, i.e., the 'to' address of the > > initial stream header. > > > > Actually, it's a interesting problem. As I understand it, SNI is > unencrypted in the handshake, so offers no value, but could easily cause > major confusion if used, since it is not clear which might take precedence. Good point. > However, my understanding - possibly flawed - is that TLS version 1.3 > introduces encrypted handshakes, and then it might be useful to hide the > server domains used. I admit that I haven't been tracking the TLS 1.3 initiative, although I recall that being one of the goals. However, since TLS 1.3 isn't here yet, it doesn't help us with draft-ietf-xmpp-dna (although we might want to mention that this applies to TLS 1.2 and lower). Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue May 19 08:42:25 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 394791A9077 for ; Tue, 19 May 2015 08:42:24 -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 Q-BJA_no1ahj for ; Tue, 19 May 2015 08:42:22 -0700 (PDT) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (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 C0CED1A90FD for ; Tue, 19 May 2015 08:41:36 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so29585374pac.2 for ; Tue, 19 May 2015 08:41:36 -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=sl0z3MLOksXZwCJN3E2gKXVU/LHJPS82DEP9Gp6iRt0=; b=Wm7k+ioLT7fssvYk3uiMKOMtILiJveDT9TDTWf3qKuxs3VA4JOH4TuF9+r7JtO50rA j12XHunZvA0c50Vr6cmamvPCEv6nd9drEq46EuN/MeuNQLF3U98iNf1D8rj/V67fdtYL ERI4k1bzzSmT5Ap5V2m4nAb9pQBPujMJsNsG5oa88vAzxXy4URORA1REo6uQeQeaUjnj 4PTgQakJMPthydaZhzfG86Sn36yEN6/g69N4YXHLnq+aQGf9nozZ76jEOsXQA+rU2MaH kwTzovznDkV27El7E9/NsRNyhR0FFocaasFE6ZQz2VVWw0QqlSDaaETTB+AMr/CPvULH SVlA== X-Gm-Message-State: ALoCoQmo1zvyWkUsBnq86HOSUd/LhroqA49acgT7SFIOOTzEndXQ/dFi5l3SBiHEsW0pZDc2cHJr X-Received: by 10.70.6.161 with SMTP id c1mr54854606pda.76.1432050096372; Tue, 19 May 2015 08:41:36 -0700 (PDT) Received: from aither.local ([12.249.93.110]) by mx.google.com with ESMTPSA id ql9sm13430161pbc.65.2015.05.19.08.41.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 08:41:35 -0700 (PDT) Message-ID: <555B59AD.2030700@andyet.net> Date: Tue, 19 May 2015 08:41:33 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: XMPP Working Group References: <555A61CA.2020108@andyet.net> <555A6319.9010703@andyet.net> <555A6684.4000100@andyet.net> In-Reply-To: <555A6684.4000100@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [xmpp] Fwd: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP 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, 19 May 2015 15:42:24 -0000 On 5/18/15 3:24 PM, Peter Saint-Andre - &yet wrote: > On 5/18/15 3:09 PM, Peter Saint-Andre - &yet wrote: >> This thread started on the DANE WG list but I think it belongs here. >> >> >> -------- Forwarded Message -------- >> Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP >> Date: Mon, 18 May 2015 15:03:54 -0700 >> From: Peter Saint-Andre - &yet >> To: dane@ietf.org >> >> On 5/17/15 9:55 AM, Kim Alvefur wrote: >>> Hello list! >> >> Hi Zash! >> >>> Georg Lukas noted that section 4.1 says, in the context of XMPP, to use >>> to='xmpp23.hosting.example.net' in the stream header, as that is the >>> "functional equivalent" of SNI in XMPP. However, that conflicts with >>> the current semantics of 'to' being the service domain name to the >>> server host name. That will break many, if not all, deployed servers. >>> The server should know what certificate to use for the indicated domain >>> name. >>> >>> http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1 >> >> Hmm. >> >> First, all draft-ietf-dane-srv says is that you don't need to use SNI in >> XMPP because we already have a way for the TLS client to specify which >> domain name it expects of the TLS server, i.e., the 'to' address of the >> initial stream header. >> >> Second, draft-ietf-xmpp-dna is the document that specifies the behavior >> of XMPP entities. So IMHO this is a topic for the XMPP WG list, not the >> DANE WG list. I'll forward this message to that list and continue the >> conversation there. :-) > > So, draft-ietf-xmpp-dna (§5.1) says: > > The DANE prooftype makes use of the DNS-Based Authentication of Named > Entities [RFC6698], specifically the use of DANE with DNS SRV records > [I-D.ietf-dane-srv]. For XMPP purposes, the following rules apply: > > o If there is no SRV resource record, pursue the fallback methods > described in [RFC6120]. > > o Use the 'to' address of the initial stream header to determine the > domain name of the TLS client's reference identifier (since use of > the Server Name Indication extension (TLS SNI) [RFC6066] is purely > discretionary in XMPP, as mentioned in [RFC6120]). > > As I understand it, Kim is saying that if a client were to (i) discover > via SRV methods that the service domain "example.com" is located at the > target server "hosting.example.net" and (ii) discover via DANE methods > that the expected identity of the certificate for the connection > endpoint is not the service domain but the target server host name, then > (iii) it would break things on the XMPP network for the client to > specify a 'to' address of the target server host name instead of the > service domain because (iv) the XMPP server software figures out which > certificate to present based on the service domain, not the target > server host name. > > I'm not sure about that. It seems to me that if an application service > provider is doing the whole DANE thing, then it will always just present > a certificate for "hosting.example.net" instead of for "example.com" or > any particular service domain hosted there, so why does it even need to > differentiate? > > Now, there might be some other reason to want the 'to' address to be the > service domain (e.g., maybe some cluster or machine is dedicated for > hosting that service domain, or the application service provider wants > to terminate spurious connections as quickly as possible and not use > TLS/SASL resources and round trips for accounts that it doesn't host), > but I'm not yet convinced that choosing the right certificate is the > reason. > > However, I freely admit that I might be missing something, so > enlightenment would be appreciated. :) See further discussion on the DANE list: http://www.ietf.org/mail-archive/web/dane/current/msg07686.html I think draft-ietf-xmpp-dna is fine (it just says "use the 'to' address, not SNI") whereas draft-ietf-dane-srv is the document that needs to be adjusted slightly. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed May 20 14:29: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 C86F51A923E for ; Wed, 20 May 2015 14:29: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 4CjjsLTilGTf for ; Wed, 20 May 2015 14:29: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 933F41A923B for ; Wed, 20 May 2015 14:29:39 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4KLTSiG056051 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2015 16:29:38 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: draft-ietf-xmpp-6122bis.all@tools.ietf.org, "XMPP Working Group" Date: Wed, 20 May 2015 16:29:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [xmpp] AD Evaluation: draft-ietf-xmpp-6122bis-22 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, 20 May 2015 21:29:40 -0000 Hi, This is my AD evaluation of draft-ietf-xmpp-6122bis-22. I think this is ready for IETF last call, and will start that shortly. I have only one comment of any substance: -- section 3.1, 4 paragraphs from the end makes normative statements about the minimum and maximum length for each part of a JID. But the sections for each part repeat those statements, creating redundant normative language. I don't see disagreements between the sections, but it would still be better to avoid the redundancy. Thanks! Ben. From nobody Wed May 20 15:16: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 561921A0015 for ; Wed, 20 May 2015 15:16:36 -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 Kab6xLiozbCk for ; Wed, 20 May 2015 15:16:35 -0700 (PDT) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.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 E13201A0122 for ; Wed, 20 May 2015 15:16:34 -0700 (PDT) Received: by pdfh10 with SMTP id h10so83968504pdf.3 for ; Wed, 20 May 2015 15:16:34 -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=qWvOUqB+eYnCzspkgrustqI9AimsuwZWuJYVNf5OMvI=; b=XibROkxex4pz8p9bJ1VDw+S44uZN6Ucn0RBKUnQh/tRrHr/xONDk8FAAzz3xp0V//w p8n9YbSS9GKfATb3l44Iy4QjK//+vnwWH96OaHW+phN3Swe63p9vpme5L56xx1fU7nkk iQ9oCWszPfAHJewwBHmLHPYe8BFlCYPOkMHiw1S8BYgzv1yX6wnPlLeI5D6UKeNk5ro5 7GFXb/Lkxpq3DWhu3M0ioV4Asln6D30hSo0JdBbVq98RrAemEHW7m2wBCjT7NGbuB8NU hwoJQO6q9BYW2eXno+pF7G0D484IGH2rB9wbTrCEJPFsNXKlHwxnRmgfv4ksH6muMUpm Ikxg== X-Gm-Message-State: ALoCoQlFqh9ysuoLLm2BxHVkeWpgJ4/zJbzvyTFa/Kqvb035KPn/YPFUvdKtGhlPXVBvPTYSF+iS X-Received: by 10.68.243.9 with SMTP id wu9mr9243948pbc.28.1432160194574; Wed, 20 May 2015 15:16:34 -0700 (PDT) Received: from aither.local ([208.66.31.140]) by mx.google.com with ESMTPSA id oj10sm17144907pdb.38.2015.05.20.15.16.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2015 15:16:33 -0700 (PDT) Message-ID: <555D07BE.8040104@andyet.net> Date: Wed, 20 May 2015 15:16:30 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ben Campbell , XMPP Working Group References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [xmpp] AD Evaluation: draft-ietf-xmpp-6122bis-22 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, 20 May 2015 22:16:36 -0000 On 5/20/15 2:29 PM, Ben Campbell wrote: > Hi, > > This is my AD evaluation of draft-ietf-xmpp-6122bis-22. I think this is > ready for IETF last call, and will start that shortly. Thanks, Ben. > I have only one comment of any substance: > > -- section 3.1, 4 paragraphs from the end makes normative statements > about the minimum and maximum length for each part of a JID. But the > sections for each part repeat those statements, creating redundant > normative language. I don't see disagreements between the sections, but > it would still be better to avoid the redundancy. How about this change to remove the normative statement in §3.1? OLD Each allowable portion of a JID (localpart, domainpart, and resourcepart) MUST NOT be zero octets in length and MUST NOT be more than 1023 octets in length, resulting in a maximum total size (including the '@' and '/' separators) of 3071 octets. NEW Each allowable portion of a JID (localpart, domainpart, and resourcepart) is from 1 to 1023 octets in length, resulting in a maximum total size (including the '@' and '/' separators) of 3071 octets. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed May 20 16:37:11 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 0B05D1ACC89; Wed, 20 May 2015 16:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 nfAvbUBzQR8F; Wed, 20 May 2015 16:37:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 623331ACCFA; Wed, 20 May 2015 16:36:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150520233644.11615.19688.idtracker@ietfa.amsl.com> Date: Wed, 20 May 2015 16:36:44 -0700 Archived-At: Cc: xmpp@ietf.org Subject: [xmpp] Last Call: (Extensible Messaging and Presence Protocol (XMPP): Address Format) to Proposed Standard X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 23:37:10 -0000 The IESG has received a request from the Extensible Messaging and Presence Protocol WG (xmpp) to consider the following document: - 'Extensible Messaging and Presence Protocol (XMPP): Address Format' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-06-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed May 20 21:05: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 2E74F1ACEF3 for ; Wed, 20 May 2015 21:05:54 -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 Lo_I8bxQ_pUZ for ; Wed, 20 May 2015 21:05: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 F34421ACEF2 for ; Wed, 20 May 2015 21:05:51 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4L45Vpg088389 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2015 23:05:41 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Peter Saint-Andre - &yet" Date: Wed, 20 May 2015 23:05:30 -0500 Message-ID: In-Reply-To: <555D07BE.8040104@andyet.net> References: <555D07BE.8040104@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: XMPP Working Group Subject: Re: [xmpp] AD Evaluation: draft-ietf-xmpp-6122bis-22 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, 21 May 2015 04:05:54 -0000 On 20 May 2015, at 17:16, Peter Saint-Andre - &yet wrote: > On 5/20/15 2:29 PM, Ben Campbell wrote: >> Hi, >> >> This is my AD evaluation of draft-ietf-xmpp-6122bis-22. I think this >> is >> ready for IETF last call, and will start that shortly. > > Thanks, Ben. > >> I have only one comment of any substance: >> >> -- section 3.1, 4 paragraphs from the end makes normative statements >> about the minimum and maximum length for each part of a JID. But the >> sections for each part repeat those statements, creating redundant >> normative language. I don't see disagreements between the sections, >> but >> it would still be better to avoid the redundancy. > > How about this change to remove the normative statement in §3.1? > > OLD > Each allowable portion of a JID (localpart, domainpart, and > resourcepart) MUST NOT be zero octets in length and MUST NOT be more > than 1023 octets in length, resulting in a maximum total size > (including the '@' and '/' separators) of 3071 octets. > > NEW > Each allowable portion of a JID (localpart, domainpart, and > resourcepart) is from 1 to 1023 octets in length, resulting in a > maximum total size (including the '@' and '/' separators) of 3071 > octets. > That WFM. I suggest dealing with that when you deal with any IETF last call feedback. Thanks! Ben. From nobody Wed May 20 22:52:31 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 7576F1A016C for ; Wed, 20 May 2015 22:52: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=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 L0pKjfu1_gyI for ; Wed, 20 May 2015 22:52:29 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (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 236731A014E for ; Wed, 20 May 2015 22:52:29 -0700 (PDT) Received: by pabru16 with SMTP id ru16so93556788pab.1 for ; Wed, 20 May 2015 22:52: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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iNgcLhpYBgGglSwExrbzuuvGbS20hbMCQDjQozyjvZE=; b=eKj6rc7v35+7FYkxV7wkEAP/0YtzSElTlhOOP+xeo9bKefPzD4MjtnUg5s3/XCf54y LMmTAKHdN5j7fEqXUXhsN3dGYJJ4XFYgx+5Zw1iH9WGeIes2KsvhQ9zb/d2becE/Ttne d4jKNbllAFgw21eedEWsnuiVY2HbmX9WRcD87TE7y7YwImuXTL5Z1Zvqvi20QuFbmnPF H6+TA+o53zugY0nW/ILp+K3Gru6Xrlv3vN7EbaDheN+eV5jeTZxmRcTl4gWfThIaddMK 8+RdDDg9vLc+MlEPkxIZsE5M9vihfEKx8HUmamCLOH/kcFQVXNdqWzW48w6kuxrwhYlu XeRg== X-Gm-Message-State: ALoCoQnt33vTsZ7IuqRlNBzzXrfGbzKbZ/UcEkgUp+2JC6xhupuKY51dBa/5lnxIlMl5/9o8sxYS X-Received: by 10.70.90.162 with SMTP id bx2mr2294489pdb.60.1432187548583; Wed, 20 May 2015 22:52:28 -0700 (PDT) Received: from aither.local ([12.249.93.110]) by mx.google.com with ESMTPSA id ca2sm17940028pdb.25.2015.05.20.22.52.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2015 22:52:27 -0700 (PDT) Message-ID: <555D729A.7090606@andyet.net> Date: Wed, 20 May 2015 22:52:26 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ben Campbell References: <555D07BE.8040104@andyet.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: XMPP Working Group Subject: Re: [xmpp] AD Evaluation: draft-ietf-xmpp-6122bis-22 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, 21 May 2015 05:52:31 -0000 On 5/20/15 9:05 PM, Ben Campbell wrote: > On 20 May 2015, at 17:16, Peter Saint-Andre - &yet wrote: > >> On 5/20/15 2:29 PM, Ben Campbell wrote: >>> Hi, >>> >>> This is my AD evaluation of draft-ietf-xmpp-6122bis-22. I think this is >>> ready for IETF last call, and will start that shortly. >> >> Thanks, Ben. >> >>> I have only one comment of any substance: >>> >>> -- section 3.1, 4 paragraphs from the end makes normative statements >>> about the minimum and maximum length for each part of a JID. But the >>> sections for each part repeat those statements, creating redundant >>> normative language. I don't see disagreements between the sections, but >>> it would still be better to avoid the redundancy. >> >> How about this change to remove the normative statement in §3.1? >> >> OLD >> Each allowable portion of a JID (localpart, domainpart, and >> resourcepart) MUST NOT be zero octets in length and MUST NOT be more >> than 1023 octets in length, resulting in a maximum total size >> (including the '@' and '/' separators) of 3071 octets. >> >> NEW >> Each allowable portion of a JID (localpart, domainpart, and >> resourcepart) is from 1 to 1023 octets in length, resulting in a >> maximum total size (including the '@' and '/' separators) of 3071 >> octets. >> > > That WFM. I suggest dealing with that when you deal with any IETF last > call feedback. Ack. Will do. Peter -- Peter Saint-Andre https://andyet.com/