From nobody Wed Jun 4 15:18:01 2014 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 D60281A032B for ; Wed, 4 Jun 2014 15:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 OmjAAUZEWjGJ for ; Wed, 4 Jun 2014 15:17:57 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737851A0309 for ; Wed, 4 Jun 2014 15:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2654; q=dns/txt; s=iport; t=1401920271; x=1403129871; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pOcwTRArMaB2EOUC3ciuET0btjkM9Y1i1TnWNPGRBiA=; b=Fy2QJZxvWD2Zv0sQJG6uBlEavHe1ZgRgajVdASSwGEOM30n2ADceUGWq SKgtXitMm+s8B80s26V/K9HSzzH+MvBKqm7hrb5oveekkyNbcXzp5D58R 2Yl4R+/FT/9XWATD1j9bhuxBy/CNCEUCQe/NKMQHEAMsrDlfh1J9ys+TL I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtELADSaj1OtJV2b/2dsb2JhbABZgwdSWKo5DAEBAQEBBQGYJwGBEBZ0giYBAQRuCgEQLBYPCQMCAQIBOwoGDQEFAgEBiD7SOReFVYh9B4RABIlxOo9ogT+ReoNXgVAkHA X-IronPort-AV: E=Sophos;i="4.98,975,1392163200"; d="scan'208";a="327502543" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 04 Jun 2014 22:17:51 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s54MHp1O024093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jun 2014 22:17:51 GMT Received: from MAMILLE2-M-T03K.CISCO.COM (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 4 Jun 2014 17:17:50 -0500 Message-ID: <538F9B0D.1030504@cisco.com> Date: Wed, 4 Jun 2014 16:17:49 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: XMPP Group References: In-Reply-To: X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/osWRhoQ67f9Z3c-RZKaVzyhIneM Cc: Thijs Alkemade Subject: [xmpp] Fwd: [POSH] What's the point of using JWKs in POSH? 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, 04 Jun 2014 22:18:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [ Forwarding to the xmpp@ietf.org mailing list on behalf of Thjis Alkemade ] Hello, Today, I've spent some time on trying to implement POSH-checking for xmpp.net. My implementation aimed to do two things: doing the validation as described and showing someone how they could set up their .well-known file by converting their X509 certificates to JSON Web Keys. The latter part was a lot more work than the former and made me wonder why it is defined the way it is. - From draft-ietf-xmpp-posh: Each included JWK object MUST possess the following information: o The "kty" field set to the appropriate key type used for TLS connections (e.g., "RSA" for a certificate using an RSA key). o The required public parameters for the key type (e.g., "n" and "e" for a certificate using an RSA key). o The "x5t" field set to the certificate thumbprint, as described in section 3.6 of [JOSE-JWK]. Yet the data that is required in the first and second bullet is never used. It doesn't specify if and how clients should verify it. Verification only uses the x5t field and optionally x5c. There are good arguments for "pinning" just the public key. draft-ietf-websec-key-pinning only uses the SPKI field, DANE can use either the full cert or its SPKI field (and optionally hashed). But the way it is specified here won't allow that: the x5t field always needs to be present and clients should verify it. So the public parameters of the key are useless here, but they make a key >10x as large is they have to be. Generating them is also not as easy: most certificate viewers show a SHA1 fingerprint and it's really easy to do with the openssl cli tool, but extracting n and e and base64-encoding them is a lot more work. I wouldn't even know what to do for ECDSA keys. Are there any interoperability reasons for using JWKs that I'm not aware of? Couldn't it just use a list of SHA1 hashes? Best regards, Thijs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTj5sMAAoJEDWi+S0W7cO1ZikH/ijVFWOIJg/9i2sYQu/5q7/g nmCpcMtt3U703/gYlZp7uCGGPhBJZ6bzfreTEHy10SVYeGJw5+IwWdix3R2ED+sz LBKJWPFMBKICgyl2VgGo+xliznITozSXamA817Ti4boGGuZcOyf2GI233XeRtyAE H3Ac0tyT7ZkEH0kbL1qVpux/MLlYOwIjpxJsFYWuR072+Li/wpnyAM136h9A/lSe Ej5+xJtNCsec0Vqa7OHEGN1cDy0FRiPB2IWIcChGJqAX/nXSeBIHjajxbnLbNtaJ ULe4pbYn2JjBPtYEA1usK35ktYg0f5lN+iUOIK1a4v3GJTWcxyWwb3nzeu+g3x8= =IQfu -----END PGP SIGNATURE----- From nobody Wed Jun 4 15:46:37 2014 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 ADDD71A037F for ; Wed, 4 Jun 2014 15:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 hE4Qu0kI7Pw9 for ; Wed, 4 Jun 2014 15:46:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA571A0348 for ; Wed, 4 Jun 2014 15:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4326; q=dns/txt; s=iport; t=1401921985; x=1403131585; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7aG7Ypuv8TMWDmH38TPupzC1JrQB0LVJ5eBzi4YxJX4=; b=G+1tnfNon1IthQqX3Q+fdWvnAXw0LImxcX0QWnKfmF/c7IL2pUtaFJsP jH+EjdEOKPORhRACn+X4NSCt5hOhN82gjZak/OSJyaGightKDcNfqMYxQ O9hbejDa7cgBlMqdqdc2JsHPHYHl6A4zai8TnF3DirtljO/11jjhYPz2z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtELAAOhj1OtJA2N/2dsb2JhbABZgwdSWKo/DAEBAQEBBQGYJwGBCxZ0giUBAQEEbgoBEAsYCRYPCQMCAQIBRQYNAQUCAQGIPtJDF4VViEozB4RAAQOJcTqPaIE/kXqDV4FQJBw X-IronPort-AV: E=Sophos;i="4.98,975,1392163200"; d="scan'208";a="327510205" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 04 Jun 2014 22:46:24 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s54MkOwW011543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jun 2014 22:46:24 GMT Received: from MAMILLE2-M-T03K.CISCO.COM (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 4 Jun 2014 17:46:23 -0500 Message-ID: <538FA1BD.1070508@cisco.com> Date: Wed, 4 Jun 2014 16:46:21 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: XMPP Group References: <538F9B0D.1030504@cisco.com> In-Reply-To: <538F9B0D.1030504@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/nD9pIuZ6E_LZChDx8ZKhiJ-lt5U Cc: Thijs Alkemade Subject: Re: [xmpp] Fwd: [POSH] What's the point of using JWKs in POSH? 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, 04 Jun 2014 22:46:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 6/4/14, 4:17 PM, Matt Miller wrote: > [ Forwarding to the xmpp@ietf.org mailing list on behalf of Thjis > Alkemade ] > > Hello, > > Today, I've spent some time on trying to implement POSH-checking > for xmpp.net. My implementation aimed to do two things: doing the > validation as described and showing someone how they could set up > their .well-known file by converting their X509 certificates to > JSON Web Keys. > > The latter part was a lot more work than the former and made me > wonder why it is defined the way it is. > > From draft-ietf-xmpp-posh: > > Each included JWK object MUST possess the following information: > > o The "kty" field set to the appropriate key type used for TLS > connections (e.g., "RSA" for a certificate using an RSA key). > > o The required public parameters for the key type (e.g., "n" and > "e" for a certificate using an RSA key). > > o The "x5t" field set to the certificate thumbprint, as described > in section 3.6 of [JOSE-JWK]. > > Yet the data that is required in the first and second bullet is > never used. It doesn't specify if and how clients should verify > it. Verification only uses the x5t field and optionally x5c. > > There are good arguments for "pinning" just the public key. > draft-ietf-websec-key-pinning only uses the SPKI field, DANE can > use either the full cert or its SPKI field (and optionally hashed). > But the way it is specified here won't allow that: the x5t field > always needs to be present and clients should verify it. > > So the public parameters of the key are useless here, but they make > a key >10x as large is they have to be. Generating them is also not > as easy: most certificate viewers show a SHA1 fingerprint and it's > really easy to do with the openssl cli tool, but extracting n and e > and base64-encoding them is a lot more work. I wouldn't even know > what to do for ECDSA keys. > > Are there any interoperability reasons for using JWKs that I'm not > aware of? Couldn't it just use a list of SHA1 hashes? > > Best regards, Thijs As I stated in the previous venue (posh@ietf.org), us authors were originally working to support various other use-cases, such as browserid. However, no one is arguing to actually support those other use-cases, so the desire to use JWKs is much less. My co-author and I discussed this today, and think what would be best is to switch from using a JWK-set to (roughly) your suggestion of a list of hashes. It would allow us to stay with a single syntax for both the "by-reference" and "by-value" documents, as well as provide a simple point of extension (if that is ever necessary). An example: { "fingerprints": [ { "sha-1": "ij39Ctarv+LwSw45qoqaZl7venM=", "sha-256": "WhEr4Lpv2L5pv769aRj9rrm4G6MNNCfQlre23Gol/eA=" }, { "sha-1": "JWow1EHNSbNyRfhQchi22bjurr0=", "sha-256": "K52a2gXfrjchMLYwv16QyOtv5bkKRE6rnR30hY3JM8k=" } ], "expires": 604800 } Each "fingerprint" is a JSON object, where the key is the hash algorithm and the value is the base64 encoding of hashing the DER-encoded certificate with the given algorithm. I do think that algorithm agility is necessary, which means something more than a simple array in my opinion. Generating this should be very simple; I could kludge this together on the command-line pretty quickly If the WG is ok with this, we can get a new revision of draft-ietf-xmpp-posh out relatively soon (by next week). - -- - - 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTj6G9AAoJEDWi+S0W7cO1aW4IAKdVeW6ayYrRWDu7oQh8Wx8D b4NZ6eeMv29btPx+eXdTksctBU4GWj+qxYICznZkHjIhaQKZ8LJ9caJTinh9SW8G Hz6JGCniAbU/gh2HgHIxyW0Fp71PuBeNxBkz1/K+T3FtnXjyZGbYHF755e89/OlO ioGYK99m5ygS3hhYQH40FSfOcYc1DYjkAUZd05qPkHzLkuntcmq5T8hITu6RVuyS MQYLcKDNmOXIV97S/npLZULszZft4LTuY+fr7iUIV2an6FqjLHzWnEAcGo8w0rRr CR7XqwAEVoBWITEgOptRPcwwBDitntDSDgrF9HIKgxE/oYPH5IIWMSQIpnA2gd0= =YAEX -----END PGP SIGNATURE----- From nobody Fri Jun 6 04:57:10 2014 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 03C471A0470 for ; Fri, 6 Jun 2014 04:57:08 -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 eMMHac6MZLOH for ; Fri, 6 Jun 2014 04:57:00 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FF01A0439 for ; Fri, 6 Jun 2014 04:56:59 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id b13so1729748wgh.21 for ; Fri, 06 Jun 2014 04:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buddycloud.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JcvrCPjhAq2W5Jjr2GKZmutxto5cp3b7y3zx7Raui8E=; b=QCpXKyrZMjUNGH9dj2xWjLfOfBSA/MRwAIUWR3KnSXzMFiXebVIihbmZHsMU3uvtDm r0SY6irHzhcE2BsREj1yQImZK3hSUn/Bz+7wS52otq3SsgobjQgaoFFFrTq6pg2rzac2 doRfQNQO8Mjh8Ml2eEaeqRTUCG80hcRY/S7AU= 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=JcvrCPjhAq2W5Jjr2GKZmutxto5cp3b7y3zx7Raui8E=; b=e/SVNLUarJA5PX2i6BL9qiw39RDy/GFTxlwyj2QcK9JqBqUoW1OFETi21O1TGO5m9R +EVGNf/6wMS8v4ME6Qhh5Q/3zQb1htcXYK2E3aYXtQgBn75waL2EjI8ww/W1VMC32WJY xjPJoRRkUmGUVEXKS8JeMDdRC6JtUW0U+VWzkUxjtAr3HTMxcT+levxB32YxdNahUIT0 xv9uYkQmxctCL83nLdSUufMe3Zp5cFFVv03YN7M5agCFPfPprRcxngAGMMh/N30radq7 O6vCms89NOyUjFSnDi766hxTzYdxB2LwRKYNgqbDodyw24tRcHIOuecf43wd8Kv4spSQ R7wA== X-Gm-Message-State: ALoCoQnkduvqNVQIskdZvTc996oyo3IXXz1/DVRc+YuhBh691fF8fGMN9GMM/DXcseGFoPUkDyiB MIME-Version: 1.0 X-Received: by 10.194.92.148 with SMTP id cm20mr4685315wjb.53.1402055811793; Fri, 06 Jun 2014 04:56:51 -0700 (PDT) Received: by 10.194.109.129 with HTTP; Fri, 6 Jun 2014 04:56:51 -0700 (PDT) X-Originating-IP: [77.47.7.58] In-Reply-To: <5328B3CB.5080501@cisco.com> References: <5319AC20.4090906@cisco.com> <5328B3CB.5080501@cisco.com> Date: Fri, 6 Jun 2014 13:56:51 +0200 Message-ID: From: Simon Tennant To: Matt Miller Content-Type: multipart/alternative; boundary=047d7bfd01669e1abd04fb298e6e Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/b0wFhD6_2jc6xetk5QcSXi7h-a4 Cc: " Group" Subject: Re: [xmpp] comments on draft-miller-xmpp-e2e-06 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 Jun 2014 11:57:08 -0000 --047d7bfd01669e1abd04fb298e6e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Matt, A few high-level questions: - Do I understand it correctly that all keys are session based and there isn't a pgp style key that the user publishes in a directory? I guess I'= m not clear on how the keys are created or exchanged or looked up for contacts. - How would this handle me sending a to an offline contact? Or retrieving encrypted messages after being offline for a while? - Could this work for component to component / user to component messages? - Are keys always session based? Would it be possible to hook into other key directories? S. =E1=90=A7 On 18 March 2014 21:59, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 3/7/14, 5:28 AM, Carl Wallace wrote: > > > > > > On 3/7/14, 6:23 AM, "Matt Miller" wrote: > > > > Thank you very much for the feedback! > > > > I'll incorporate your suggestions as soon as I can. > > > > On 3/6/14, 3:12 PM, Carl Wallace wrote: > >>>> Section 1 - This may be in the reqs draft, but seems worth > >>>> stating here that some end points for a given recipient may > >>>> share keys, some may use different keys, some may have no > >>>> keys and some may not support encryption or signature > >>>> verification at all. > >>>> > > > > We did discuss reviving the e2e-reqs draft in the WG session on > > Tuesday, but it would be important to include this. > > > >> It=C2=B9s also worth noting the sender may have multiple end points > >> with the same properties. If the same SMK were used in replies, > >> it creates kind of a odd scenario where both parties could be > >> providing the SMK for the asking. > > > > Good point. > > > > >>>> Section 3 - What should the sender do if some end points for > >>>> a recipient indicate lack of support for encryption? Are > >>>> error responses helpful independent of confirmation that some > >>>> end points support encryption? Is the intent for messages to > >>>> only be sent to end points that advertise support? > > > > There is little (read: nothing) that can be said on what existing > > "legacy" end-points ought to do. I tried to say something on what > > existing clients already do, to the best of my knowledge. Many > > (most) drop anything they don't understand, so getting errors could > > very well be impossible unless the applications were specifically > > updated to "anti-support" this specification. It's also possible > > I'm missing the point here, too (-: > > > > The intention is not for the sending end-point to only send to > > other supporting end-points. Indeed, I want this to be compatible > > with [CARBONS] and [MUC] where the possible. To that end, most > > clients try to do something if there is a body, and this document > > could suggest that sending end-points include an appropriate > > generic "this message is protected" body. > > > >> I=C2=B9ve not yet looked, but I had wondered if it would be possible > >> to define the signature format so a non-supporting client could > >> still display the text (similar to cleartext email vs opaque). > >> This probably brings a can of canonicalization worms though. > > > > There is an XSF XEP that covers this using a different technology, and > calls it opportunistic signatures. > > My experience has been that opportunistic signatures opens a very > large can of worms, which is why I avoided it in my draft. There are > additional considerations for s, since the expectation is for > there to be a single child element (except for type=3D'error', where > there is also an in the parent's namespace). > > We could decide to remove signatures from this draft almost entirely, > and leave it as someone else's exercise to deal with in the general > case. In this scenario, I envision keeping some form of signature is > to aid in authenticating PFS key exchanges, but then it can be > specific to the keyreq then. > > > > >>>> > >>>> - Why not include an end point's key in its info results and > >>>> enable return of the encrypted SMK (or even CEK) with the > >>>> encrypted payload (to save a round trip). Given a single > >>>> message could trigger a number of requests for the SMK, the > >>>> option to include the encrypted CEK in the payload may be > >>>> worthwhile. Including the encrypted CEK would help with > >>>> storage too. > > > > The encrypted CEK is included in each message with -06. > > > >> I made this error a couple of times. What I meant was encrypted > >> CEK for a key already held by the end point, to avoid to the need > >> for a round trip to get the SMK, to remove the online requirement > >> for the sender at recipient reading time and to simplify future > >> use of stored encrypted messages. The CEK could also be > >> encrypted under the SMK to bootstrap unknown end points. > > > > > > Including an encrypted SMK is a possibility, although I start to > > worry about the size of the overall stanza. If it's absolutely > > known that the message will be delivered to a single end-point it > > shouldn't get too large, but I am assuming that servers will start > > multiplexing chat messages (a la [CARBONS]) which means the > > benefits of including the encrypted SMK are unrealized if only > > there's only a single instance of the encrypted SMK; including > > multiple SMKs can be very problematic (e.g., many server > > deployments reject very large stanzas). > > > >> Do you know what the threshold is? > > The threshold is different for different deployments /-: > > There are some without any limit, which means the system crashes if it > runs out of memory trying to deal with an extremely large stanza. > Another I'm aware of has a limit of 40KB, and will drop the connection > on anything bigger. > > I don't know how common any particular limit is, though. And worse, > there's no real way to detect prior to trying. > > > > > > >>>> > >>>> > >>>> - Why is the SID required to be unique for a {sender, > >>>> recipient, SMK} tuple? This would allow for the same SID to > >>>> be used to name every SMK used with a recipient. Suggest > >>>> unique for each recipient (i.e., SMK's are uniquely > >>>> identified by recipient+SID for a given sender). > >>>> > > > > I'm not sure what you're trying to say here (it could be due to me > > responding on the last day of an IETF meeting). Can you provide > > an example of what your concern here is? > > > >> Assume a sender has used two SMKs while communicating with a > >> given recipient: sender+recipient+SMK1 and sender+recipient+SMK2. > >> The current text requires the SID to be unique "for a given > >> (sender, recipient, SMK) tuple=C2=B2. That allows for the same SID to > >> be used for either SMK1 or SMK2. I am suggesting the SID should > >> be unique for each recipient, from a sender=C2=B9s perspective. > > > > > > I see your point now. > > >>>> - Discuss how multiple recipients are handled > > > > That is a very good point. There is some text there, but it is > > fairly weak. I was considering a form of ASCII sequence diagram of > > the general flow -- would that better help to explain things? > > > >> That would help. > > > > > >>>> > >>>> - s/optionallly/optionally > >>>> > > > > Fixed in working copy. > > > >>>> - It would be nice to have a summary of new state information > >>>> the sender and recipient are required to manage (like SMKs) > >>>> and significant new operations (like authorization of key > >>>> requests where a given recipient may use a number of > >>>> different public keys) > > > > That is a very good suggestion. Do you think you could provide > > some text to get it started? > > > >> Sure. Will try to send something next week. > > > > > >>>> > >>>> - Should include an example of a reply to an encrypted > >>>> message. Should/must the same SMK be used in replies? > >>>> > > > > That is not a bad idea. I'll look into it. > > > >>>> - Is there any reason pre-placed SMK values cannot be used > >>>> instead of SMK values retrieved automatically from the > >>>> sender? > >>>> > > > > Is there any additional concern here beyond the point a few above? > > > >> No, just looking for another place to not use of a key already > >> know to the receiver. > > > > > >>>> Section 4 - How is the public key used to verify signatures > >>>> published to the recipients? If not included in the > >>>> payload, should be available a la the SMK. This would be > >>>> useful, at a minimum, when the signer uses a certificate from > >>>> a PKI the recipient trusts. > >>>> > > > > These are good points, and it ought to be included. The JWS > > structure does allow for inclusion of the jwk (or jku, or x5c, or > > x5t, or x5u) which would be the key used to sign the content. I'll > > add more clarity on this point. > > > >>>> - s/Playload/payload > >>>> > > > > Fixed in working copy. > > > >>>> - Include some text indicating users MUST be able to > >>>> determine if a message was authenticated > >>>> > > > > That is a good point. > > > >>>> - Should data be presented to the user when the timestamp is > >>>> not acceptable? There are guidelines for invalid signatures, > >>>> but not for unacceptable timestamps. Same comment on 3.3.5 > >>>> too. > >>>> > > > > I have been hesitant on dictating what to display to users. I > > don't want to tie the hands of implementations, and it's rather > > difficult to independently verify that a given implementation > > complies without some sort of officiating body (which we definitely > > don't want). > > > >> I thought these UI notes were more reminders to developers to > >> make sure user=C2=B9s could determine checks had been performed. > > > > I'm sure we can come up with something that's not exactly normative > language. > > > > >>>> - May want to distinguish between successful authentication > >>>> vs successful verification > >>>> > > > > Noted. > > > >>>> Section 5 - Should describe how the entity requesting a key > >>>> gets the SID > >>>> > > > > I thought I had said that in here, but I'll clarify it further. > > > >>>> - Should make it more clear that a new CEK is generated in > >>>> order to encrypt the SMK, then the CEK is encrypted under the > >>>> public key. > >>>> > > > > You have this reversed: the SMK is used to encrypt the CEK, and > > the recipient's public key is used to encrypt the SMK. It is > > completely possible that I was not consistent here. > > > >> I thought when the SMK is communicated to the end point, it is > >> also encrypted under a content encryption key (referred to as a > >> CMK in the text), that is then encrypted using the end point=C2=B9s > >> public key. If that is correct there are four keys at work: the > >> CEK for the stanza (CEK1), the SMK to encrypt the CEK, the CEK to > >> encrypt the SMK (CEK2) and the recipient=C2=B9s public key to encrypt > >> CEK2. > > > > You are absolutely correct; sorry for my own confuzzlement! > > > > >>>> Section 9 - The requirement for the sender to be online would > >>>> seem like sufficient grounds for including encrypted CEKs in > >>>> the payload. > >>>> > > > > Encrypted CEKs are in the payload in -06. > > > >> I tried to clarify in a reply comment above. This applies to the > >> next few comments too. Read =C2=B3encrypted CEKs=C2=B2 are =C2=B3CEKs= encrypted > >> using a key already possessed by the recipient=C2=B2. I think I was > >> consistent in misusing the term =C2=B3encrypted CEKs=C2=B2 in my comme= nts > >> in this way, and introduced the CEK term in my comments where it > >> does not appear in the draft:-) > > > > > > > >>>> Section 11 - Offline storage may be another reason to > >>>> include encrypted CEKs in a payload. Perhaps the solution > >>>> should be to encrypt for each of a recipient's known keys > >>>> plus an SMK that could be used by end points using a > >>>> different, not-yet-known-to-the-sender key. > >>>> > > > > You mean encrypted SMKs here. > > > > One idea that had been discussed outside the meeting was to try > > and use [PEP] as a way to do this, but we didn't spend a lot of > > time thinking about the mechanics and implications here. > > > > > >>>> - Need to address authorization for SMK release. > >>>> > > > > I have pretty much hand-waved over this part. One idea that came > > to light this week was to provide fingerprints for the recipients' > > public keys, somehow. Suggestions for improvements are welcome. > > > >>>> - Include some guidance on SMK lifetime. > > > > There is *some* guidance in section 11.2, but I admit it is rather > > vague. Could you provide more specific suggestions? > > > >> As above, will try to send some text next week. > > - -- > - - 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 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTKLPLAAoJEDWi+S0W7cO1L3IH/igYVs7+S4bJACRXkzVqUDqr > AUiIg/Ply3x04Cf06O0oCmRmfdxe9GhNv3CRbs07tETihZY31PV0Nez+BkHkVpN2 > jcTE2ACDYbChGZAb55F8ThBNHWuDZfKJuRN0F+Elfckl9GVkCuwDiGj9TPLXvnbS > 1KUdoFr0OQSwF8qaLMPdX3N/1/7srTmM84bkHL0RYpT4sihlzbWwYydr0/NKYSqy > L1Zn33Yw8RQpKjrtqOw5I7CrhN/qTytTD6srZNnqR/W68+MmDfb1y4RYfqnYX8Qy > NPuDdk/hME42hSkUoJqSGEKez0iClmSTakNserA3vjl6cn3cRUYZWRzoKBk43vI=3D > =3D36MU > -----END PGP SIGNATURE----- > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > --=20 Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP --047d7bfd01669e1abd04fb298e6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Matt,=C2=A0

A few high-level questio= ns:=C2=A0
  • Do I understand it correctly that all keys are = session based and there isn't a pgp style key that the user publishes i= n a directory? I guess I'm not clear on how the keys are created or exc= hanged or looked up for contacts.
  • How would this handle me sending a <message> to an offline contac= t? Or retrieving encrypted messages after being offline for a while?
    • Could this work for component to component =C2=A0/ user to component mess= ages?
  • Are keys always session based? Would it be possible to hook into other = key directories?
S.

=E1=90=A7


On 18 M= arch 2014 21:59, Matt Miller <mamille2@cisco.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 3/7/14, 5:28 AM, Carl Wallace wrote:
>
>
> On 3/7/14, 6:23 AM, "Matt Miller" <mamille2@cisco.com> wrote:
>
> Thank you very much for the feedback!
>
> I'll incorporate your suggestions as soon as I can.
>
> On 3/6/14, 3:12 PM, Carl Wallace wrote:
>>>> Section 1 - This may be in the reqs draft, but seems worth=
>>>> stating here that some end points for a given recipient ma= y
>>>> share keys, some may use different keys, some may have no<= br> >>>> keys and some may not support encryption or signature
>>>> verification at all.
>>>>
>
> We did discuss reviving the e2e-reqs draft in the WG session on
> Tuesday, but it would be important to include this.
>
>> It=C2=B9s also worth noting the sender may have multiple end point= s
>> with the same properties. =C2=A0If the same SMK were used in repli= es,
>> it creates kind of a odd scenario where both parties could be
>> providing the SMK for the asking.
>

Good point.

>
>>>> Section 3 - What should the sender do if some end points f= or
>>>> a recipient indicate lack of support for encryption? =C2= =A0Are
>>>> error responses helpful independent of confirmation that s= ome
>>>> end points support encryption? =C2=A0Is the intent for mes= sages to
>>>> only be sent to end points that advertise support?
>
> There is little (read: nothing) that can be said on what existing
> "legacy" end-points ought to do. =C2=A0I tried to say someth= ing on what
> existing clients already do, to the best of my knowledge. =C2=A0Many > (most) drop anything they don't understand, so getting errors coul= d
> very well be impossible unless the applications were specifically
> updated to "anti-support" this specification. =C2=A0It's= also possible
> I'm missing the point here, too (-:
>
> The intention is not for the sending end-point to only send to
> other supporting end-points. =C2=A0Indeed, I want this to be compatibl= e
> with [CARBONS] and [MUC] where the possible. =C2=A0To that end, most > clients try to do something if there is a body, and this document
> could suggest that sending end-points include an appropriate
> generic "this message is protected" body.
>
>> I=C2=B9ve not yet looked, but I had wondered if it would be possib= le
>> to define the signature format so a non-supporting client could >> still display the text (similar to cleartext email vs opaque).
>> This probably brings a can of canonicalization worms though.
>

There is an XSF XEP that covers this using a different technology, an= d
calls it opportunistic signatures.

My experience has been that opportunistic signatures opens a very
large can of worms, which is why I avoided it in my draft. =C2=A0There are<= br> additional considerations for <iq/>s, since the expectation is for there to be a single child element (except for type=3D'error', wher= e
there is also an <error/> in the parent's namespace).

We could decide to remove signatures from this draft almost entirely,
and leave it as someone else's exercise to deal with in the general
case. =C2=A0In this scenario, I envision keeping some form of signature is<= br> to aid in authenticating PFS key exchanges, but then it can be
specific to the keyreq then.

>
>>>>
>>>> - Why not include an end point's key in its info resul= ts and
>>>> enable return of the encrypted SMK (or even CEK) with the<= br> >>>> encrypted payload (to save a round trip). =C2=A0Given a si= ngle
>>>> message could trigger a number of requests for the SMK, th= e
>>>> option to include the encrypted CEK in the payload may be<= br> >>>> worthwhile. =C2=A0Including the encrypted CEK would help w= ith
>>>> storage too.
>
> The encrypted CEK is included in each message with -06.
>
>> I made this error a couple of times. =C2=A0What I meant was encryp= ted
>> CEK for a key already held by the end point, to avoid to the need<= br> >> for a round trip to get the SMK, to remove the online requirement<= br> >> for the sender at recipient reading time and to simplify future >> use of stored encrypted messages. =C2=A0The CEK could also be
>> encrypted under the SMK to bootstrap unknown end points.
>
>
> Including an encrypted SMK is a possibility, although I start to
> worry about the size of the overall stanza. =C2=A0If it's absolute= ly
> known that the message will be delivered to a single end-point it
> shouldn't get too large, but I am assuming that servers will start=
> multiplexing chat messages (a la [CARBONS]) which means the
> benefits of including the encrypted SMK are unrealized if only
> there's only a single instance of the encrypted SMK; including
> multiple SMKs can be very problematic (e.g., many server
> deployments reject very large stanzas).
>
>> Do you know what the threshold is?

The threshold is different for different deployments /-:

There are some without any limit, which means the system crashes if it
runs out of memory trying to deal with an extremely large stanza.
Another I'm aware of has a limit of 40KB, and will drop the connection<= br> on anything bigger.

I don't know how common any particular limit is, though. =C2=A0And wors= e,
there's no real way to detect prior to trying.

>
>
>>>>
>>>>
>>>> - Why is the SID required to be unique for a {sender,
>>>> recipient, SMK} tuple? =C2=A0This would allow for the same= SID to
>>>> be used to name every SMK used with a recipient. =C2=A0Sug= gest
>>>> unique for each recipient (i.e., SMK's are uniquely >>>> identified by recipient+SID for a given sender).
>>>>
>
> I'm not sure what you're trying to say here (it could be due t= o me
> responding on the last day of an IETF meeting). =C2=A0Can you provide<= br> > an example of what your concern here is?
>
>> Assume a sender has used two SMKs while communicating with a
>> given recipient: sender+recipient+SMK1 and sender+recipient+SMK2.<= br> >> The current text requires the SID to be unique "for a given >> (sender, recipient, SMK) tuple=C2=B2. =C2=A0That allows for the sa= me SID to
>> be used for either SMK1 or SMK2. I am suggesting the SID should >> be unique for each recipient, from a sender=C2=B9s perspective. >
>

I see your point now.

>>>> - Discuss how multiple recipients are handled
>
> That is a very good point. =C2=A0There is some text there, but it is > fairly weak. =C2=A0I was considering a form of ASCII sequence diagram = of
> the general flow -- would that better help to explain things?
>
>> That would help.
>
>
>>>>
>>>> - s/optionallly/optionally
>>>>
>
> Fixed in working copy.
>
>>>> - It would be nice to have a summary of new state informat= ion
>>>> the sender and recipient are required to manage (like SMKs= )
>>>> and significant new operations (like authorization of key<= br> >>>> requests where a given recipient may use a number of
>>>> different public keys)
>
> That is a very good suggestion. =C2=A0Do you think you could provide > some text to get it started?
>
>> Sure. =C2=A0Will try to send something next week.
>
>
>>>>
>>>> - Should include an example of a reply to an encrypted
>>>> message. Should/must the same SMK be used in replies?
>>>>
>
> That is not a bad idea. =C2=A0I'll look into it.
>
>>>> - Is there any reason pre-placed SMK values cannot be used=
>>>> instead of SMK values retrieved automatically from the
>>>> sender?
>>>>
>
> Is there any additional concern here beyond the point a few above?
>
>> No, just looking for another place to not use of a key already
>> know to the receiver.
>
>
>>>> Section 4 - How is the public key used to verify signature= s
>>>> published to the recipients? =C2=A0If not included in the<= br> >>>> payload, should be available a la the SMK. =C2=A0This woul= d be
>>>> useful, at a minimum, when the signer uses a certificate f= rom
>>>> a PKI the recipient trusts.
>>>>
>
> These are good points, and it ought to be included. =C2=A0The JWS
> structure does allow for inclusion of the jwk (or jku, or x5c, or
> x5t, or x5u) which would be the key used to sign the content. =C2=A0I&= #39;ll
> add more clarity on this point.
>
>>>> - s/Playload/payload
>>>>
>
> Fixed in working copy.
>
>>>> - Include some text indicating users MUST be able to
>>>> determine if a message was authenticated
>>>>
>
> That is a good point.
>
>>>> - Should data be presented to the user when the timestamp = is
>>>> not acceptable? =C2=A0There are guidelines for invalid sig= natures,
>>>> but not for unacceptable timestamps. =C2=A0Same comment on= 3.3.5
>>>> too.
>>>>
>
> I have been hesitant on dictating what to display to users. =C2=A0I > don't want to tie the hands of implementations, and it's rathe= r
> difficult to independently verify that a given implementation
> complies without some sort of officiating body (which we definitely > don't want).
>
>> I thought these UI notes were more reminders to developers to
>> make sure user=C2=B9s could determine checks had been performed. >

I'm sure we can come up with something that's not exact= ly normative
language.

>
>>>> - May want to distinguish between successful authenticatio= n
>>>> vs successful verification
>>>>
>
> Noted.
>
>>>> Section 5 - Should describe how the entity requesting a ke= y
>>>> gets the SID
>>>>
>
> I thought I had said that in here, but I'll clarify it further. >
>>>> - Should make it more clear that a new CEK is generated in=
>>>> order to encrypt the SMK, then the CEK is encrypted under = the
>>>> public key.
>>>>
>
> You have this reversed: the SMK is used to encrypt the CEK, and
> the recipient's public key is used to encrypt the SMK. =C2=A0It is=
> completely possible that I was not consistent here.
>
>> I thought when the SMK is communicated to the end point, it is
>> also encrypted under a content encryption key (referred to as a >> CMK in the text), that is then encrypted using the end point=C2=B9= s
>> public key. =C2=A0If that is correct there are four keys at work: = the
>> CEK for the stanza (CEK1), the SMK to encrypt the CEK, the CEK to<= br> >> encrypt the SMK (CEK2) and the recipient=C2=B9s public key to encr= ypt
>> CEK2.
>

You are absolutely correct; sorry for my own confuzzlement!

>
>>>> Section 9 - The requirement for the sender to be online wo= uld
>>>> seem like sufficient grounds for including encrypted CEKs = in
>>>> the payload.
>>>>
>
> Encrypted CEKs are in the payload in -06.
>
>> I tried to clarify in a reply comment above. =C2=A0This applies to= the
>> next few comments too. =C2=A0Read =C2=B3encrypted CEKs=C2=B2 are = =C2=B3CEKs encrypted
>> using a key already possessed by the recipient=C2=B2. =C2=A0I thin= k I was
>> consistent in misusing the term =C2=B3encrypted CEKs=C2=B2 in my c= omments
>> in this way, and introduced the CEK term in my comments where it >> does not appear in the draft:-)
>
>
>
>>>> Section 11 - Offline storage may be another reason to
>>>> include encrypted CEKs in a payload. =C2=A0Perhaps the sol= ution
>>>> should be to encrypt for each of a recipient's known k= eys
>>>> plus an SMK that could be used by end points using a
>>>> different, not-yet-known-to-the-sender key.
>>>>
>
> You mean encrypted SMKs here.
>
> One idea that had been discussed outside the meeting was to try
> and use [PEP] as a way to do this, but we didn't spend a lot of > time thinking about the mechanics and implications here.
>
>
>>>> - Need to address authorization for SMK release.
>>>>
>
> I have pretty much hand-waved over this part. =C2=A0One idea that came=
> to light this week was to provide fingerprints for the recipients'=
> public keys, somehow. =C2=A0Suggestions for improvements are welcome.<= br> >
>>>> - Include some guidance on SMK lifetime.
>
> There is *some* guidance in section 11.2, but I admit it is rather
> vague. =C2=A0Could you provide more specific suggestions?
>
>> As above, will try to send some text next week.

- --
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTKLPLAAoJEDWi+S0W7cO1L3IH/igYVs7+S4bJACRXkzVqUDqr
AUiIg/Ply3x04Cf06O0oCmRmfdxe9GhNv3CRbs07tETihZY31PV0Nez+BkHkVpN2
jcTE2ACDYbChGZAb55F8ThBNHWuDZfKJuRN0F+Elfckl9GVkCuwDiGj9TPLXvnbS
1KUdoFr0OQSwF8qaLMPdX3N/1/7srTmM84bkHL0RYpT4sihlzbWwYydr0/NKYSqy
L1Zn33Yw8RQpKjrtqOw5I7CrhN/qTytTD6srZNnqR/W68+MmDfb1y4RYfqnYX8Qy
NPuDdk/hME42hSkUoJqSGEKez0iClmSTakNserA3vjl6cn3cRUYZWRzoKBk43vI=3D
=3D36MU
-----END PGP SIGNATURE-----

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



--
= Simon Tennant | buddycl= oud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
--047d7bfd01669e1abd04fb298e6e-- From nobody Fri Jun 6 07:20:35 2014 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 8FC161A0114 for ; Fri, 6 Jun 2014 07:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 Igu_v6znOmHz for ; Fri, 6 Jun 2014 07:20:32 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0A71A0092 for ; Fri, 6 Jun 2014 07:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14618; q=dns/txt; s=iport; t=1402064425; x=1403274025; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0T7iKqrIDGJxXwe4BqrDzZzfaNrAseyZdnBqvA3T6qA=; b=i+i+3rp9DNdPUv55hQwYJn97ZAHy7J8JwzEaGC7L6tlmFdGYRtJqwv4g Q1F1zuulhWXUF/CRGmeGEGkLzgldojO5qE1bCiGV6DE9ZtY4zOpd5yFxV brYH61O0YyVhH9AoV3Ka/c/RaI3AfQ0LPukca78VYJ8nIcmso8S2AEpWt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIWAHDNkVOtJA2M/2dsb2JhbABZgw1SUgeCbKgCBQGRT4c8AYEGFnWEAwEBAQMBAQEBIA8BOwoBEAsYAgIFFggDAgIJAwIBAgEVHxEGDQEFAgEBF4gfCAgFrWyfOReBKoQzg2GESQsGAQcWDSYHgnWBTAEDii2LX4QKgUGMCwGFc4NbVgEBdwgXIg X-IronPort-AV: E=Sophos;i="4.98,989,1392163200"; d="scan'208";a="331132789" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP; 06 Jun 2014 14:20:24 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s56EKNBR002526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jun 2014 14:20:23 GMT Received: from MAMILLE2-M-T03K.CISCO.COM (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 6 Jun 2014 09:20:23 -0500 Message-ID: <5391CE28.8080605@cisco.com> Date: Fri, 6 Jun 2014 08:20:24 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Simon Tennant References: <5319AC20.4090906@cisco.com> <5328B3CB.5080501@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Z7xJPz9FyF2P-KqVM3IIYtGhTMI Cc: " Group" Subject: Re: [xmpp] comments on draft-miller-xmpp-e2e-06 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 Jun 2014 14:20:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Simon! On 6/6/14, 5:56 AM, Simon Tennant wrote: > Hi Matt, > > A few high-level questions: > > * Do I understand it correctly that all keys are session based and > there isn't a pgp style key that the user publishes in a > directory? I guess I'm not clear on how the keys are created or > exchanged or looked up for contacts. the keys are session based; the recipients use sub-protocol (§ 5) to request the session key from the sender. The does use an asymmetric key that the recipient provides to the sender. This draft is leaving most of how that key is verified up to implementations right now. > * How would this handle me sending a to an offline > contact? Or retrieving encrypted messages after being offline for a > while? The current one would not handle that approach, and this shortcoming is discussed in § 9. > * Could this work for component to component / user to component > messages? I see no reason for it not to work, as long as the components and users > * Are keys always session based? Would it be possible to hook into > other key directories? I don't think this prevents other key management schemes from being used. As long as those specs properly described the mapping between 'sid' and the extended key management schemes, and how to signal that another management scheme is in use. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > ᐧ > > > On 18 March 2014 21:59, Matt Miller > wrote: > > On 3/7/14, 5:28 AM, Carl Wallace wrote: > > >> On 3/7/14, 6:23 AM, "Matt Miller" > wrote: > >> Thank you very much for the feedback! > >> I'll incorporate your suggestions as soon as I can. > >> On 3/6/14, 3:12 PM, Carl Wallace wrote: >>>>> Section 1 - This may be in the reqs draft, but seems worth >>>>> stating here that some end points for a given recipient >>>>> may share keys, some may use different keys, some may have >>>>> no keys and some may not support encryption or signature >>>>> verification at all. >>>>> > >> We did discuss reviving the e2e-reqs draft in the WG session on >> Tuesday, but it would be important to include this. > >>> It¹s also worth noting the sender may have multiple end points >>> with the same properties. If the same SMK were used in >>> replies, it creates kind of a odd scenario where both parties >>> could be providing the SMK for the asking. > > > Good point. > > >>>>> Section 3 - What should the sender do if some end points >>>>> for a recipient indicate lack of support for encryption? >>>>> Are error responses helpful independent of confirmation >>>>> that some end points support encryption? Is the intent for >>>>> messages to only be sent to end points that advertise >>>>> support? > >> There is little (read: nothing) that can be said on what >> existing "legacy" end-points ought to do. I tried to say >> something on what existing clients already do, to the best of my >> knowledge. Many (most) drop anything they don't understand, so >> getting errors could very well be impossible unless the >> applications were specifically updated to "anti-support" this >> specification. It's also possible I'm missing the point here, >> too (-: > >> The intention is not for the sending end-point to only send to >> other supporting end-points. Indeed, I want this to be >> compatible with [CARBONS] and [MUC] where the possible. To that >> end, most clients try to do something if there is a body, and >> this document could suggest that sending end-points include an >> appropriate generic "this message is protected" body. > >>> I¹ve not yet looked, but I had wondered if it would be >>> possible to define the signature format so a non-supporting >>> client could still display the text (similar to cleartext email >>> vs opaque). This probably brings a can of canonicalization >>> worms though. > > > There is an XSF XEP that covers this using a different technology, > and calls it opportunistic signatures. > > My experience has been that opportunistic signatures opens a very > large can of worms, which is why I avoided it in my draft. There > are additional considerations for s, since the expectation is > for there to be a single child element (except for type='error', > where there is also an in the parent's namespace). > > We could decide to remove signatures from this draft almost > entirely, and leave it as someone else's exercise to deal with in > the general case. In this scenario, I envision keeping some form > of signature is to aid in authenticating PFS key exchanges, but > then it can be specific to the keyreq then. > > >>>>> >>>>> - Why not include an end point's key in its info results >>>>> and enable return of the encrypted SMK (or even CEK) with >>>>> the encrypted payload (to save a round trip). Given a >>>>> single message could trigger a number of requests for the >>>>> SMK, the option to include the encrypted CEK in the payload >>>>> may be worthwhile. Including the encrypted CEK would help >>>>> with storage too. > >> The encrypted CEK is included in each message with -06. > >>> I made this error a couple of times. What I meant was >>> encrypted CEK for a key already held by the end point, to avoid >>> to the need for a round trip to get the SMK, to remove the >>> online requirement for the sender at recipient reading time and >>> to simplify future use of stored encrypted messages. The CEK >>> could also be encrypted under the SMK to bootstrap unknown end >>> points. > > >> Including an encrypted SMK is a possibility, although I start to >> worry about the size of the overall stanza. If it's absolutely >> known that the message will be delivered to a single end-point >> it shouldn't get too large, but I am assuming that servers will >> start multiplexing chat messages (a la [CARBONS]) which means >> the benefits of including the encrypted SMK are unrealized if >> only there's only a single instance of the encrypted SMK; >> including multiple SMKs can be very problematic (e.g., many >> server deployments reject very large stanzas). > >>> Do you know what the threshold is? > > The threshold is different for different deployments /-: > > There are some without any limit, which means the system crashes if > it runs out of memory trying to deal with an extremely large > stanza. Another I'm aware of has a limit of 40KB, and will drop the > connection on anything bigger. > > I don't know how common any particular limit is, though. And > worse, there's no real way to detect prior to trying. > > > >>>>> >>>>> >>>>> - Why is the SID required to be unique for a {sender, >>>>> recipient, SMK} tuple? This would allow for the same SID >>>>> to be used to name every SMK used with a recipient. >>>>> Suggest unique for each recipient (i.e., SMK's are >>>>> uniquely identified by recipient+SID for a given sender). >>>>> > >> I'm not sure what you're trying to say here (it could be due to >> me responding on the last day of an IETF meeting). Can you >> provide an example of what your concern here is? > >>> Assume a sender has used two SMKs while communicating with a >>> given recipient: sender+recipient+SMK1 and >>> sender+recipient+SMK2. The current text requires the SID to be >>> unique "for a given (sender, recipient, SMK) tuple². That >>> allows for the same SID to be used for either SMK1 or SMK2. I >>> am suggesting the SID should be unique for each recipient, from >>> a sender¹s perspective. > > > > I see your point now. > >>>>> - Discuss how multiple recipients are handled > >> That is a very good point. There is some text there, but it is >> fairly weak. I was considering a form of ASCII sequence diagram >> of the general flow -- would that better help to explain things? > >>> That would help. > > >>>>> >>>>> - s/optionallly/optionally >>>>> > >> Fixed in working copy. > >>>>> - It would be nice to have a summary of new state >>>>> information the sender and recipient are required to manage >>>>> (like SMKs) and significant new operations (like >>>>> authorization of key requests where a given recipient may >>>>> use a number of different public keys) > >> That is a very good suggestion. Do you think you could provide >> some text to get it started? > >>> Sure. Will try to send something next week. > > >>>>> >>>>> - Should include an example of a reply to an encrypted >>>>> message. Should/must the same SMK be used in replies? >>>>> > >> That is not a bad idea. I'll look into it. > >>>>> - Is there any reason pre-placed SMK values cannot be used >>>>> instead of SMK values retrieved automatically from the >>>>> sender? >>>>> > >> Is there any additional concern here beyond the point a few >> above? > >>> No, just looking for another place to not use of a key already >>> know to the receiver. > > >>>>> Section 4 - How is the public key used to verify >>>>> signatures published to the recipients? If not included in >>>>> the payload, should be available a la the SMK. This would >>>>> be useful, at a minimum, when the signer uses a certificate >>>>> from a PKI the recipient trusts. >>>>> > >> These are good points, and it ought to be included. The JWS >> structure does allow for inclusion of the jwk (or jku, or x5c, >> or x5t, or x5u) which would be the key used to sign the content. >> I'll add more clarity on this point. > >>>>> - s/Playload/payload >>>>> > >> Fixed in working copy. > >>>>> - Include some text indicating users MUST be able to >>>>> determine if a message was authenticated >>>>> > >> That is a good point. > >>>>> - Should data be presented to the user when the timestamp >>>>> is not acceptable? There are guidelines for invalid >>>>> signatures, but not for unacceptable timestamps. Same >>>>> comment on 3.3.5 too. >>>>> > >> I have been hesitant on dictating what to display to users. I >> don't want to tie the hands of implementations, and it's rather >> difficult to independently verify that a given implementation >> complies without some sort of officiating body (which we >> definitely don't want). > >>> I thought these UI notes were more reminders to developers to >>> make sure user¹s could determine checks had been performed. > > > I'm sure we can come up with something that's not exactly > normative language. > > >>>>> - May want to distinguish between successful >>>>> authentication vs successful verification >>>>> > >> Noted. > >>>>> Section 5 - Should describe how the entity requesting a >>>>> key gets the SID >>>>> > >> I thought I had said that in here, but I'll clarify it further. > >>>>> - Should make it more clear that a new CEK is generated in >>>>> order to encrypt the SMK, then the CEK is encrypted under >>>>> the public key. >>>>> > >> You have this reversed: the SMK is used to encrypt the CEK, and >> the recipient's public key is used to encrypt the SMK. It is >> completely possible that I was not consistent here. > >>> I thought when the SMK is communicated to the end point, it is >>> also encrypted under a content encryption key (referred to as >>> a CMK in the text), that is then encrypted using the end >>> point¹s public key. If that is correct there are four keys at >>> work: the CEK for the stanza (CEK1), the SMK to encrypt the >>> CEK, the CEK to encrypt the SMK (CEK2) and the recipient¹s >>> public key to encrypt CEK2. > > > You are absolutely correct; sorry for my own confuzzlement! > > >>>>> Section 9 - The requirement for the sender to be online >>>>> would seem like sufficient grounds for including encrypted >>>>> CEKs in the payload. >>>>> > >> Encrypted CEKs are in the payload in -06. > >>> I tried to clarify in a reply comment above. This applies to >>> the next few comments too. Read ³encrypted CEKs² are ³CEKs >>> encrypted using a key already possessed by the recipient². I >>> think I was consistent in misusing the term ³encrypted CEKs² in >>> my comments in this way, and introduced the CEK term in my >>> comments where it does not appear in the draft:-) > > > >>>>> Section 11 - Offline storage may be another reason to >>>>> include encrypted CEKs in a payload. Perhaps the solution >>>>> should be to encrypt for each of a recipient's known keys >>>>> plus an SMK that could be used by end points using a >>>>> different, not-yet-known-to-the-sender key. >>>>> > >> You mean encrypted SMKs here. > >> One idea that had been discussed outside the meeting was to try >> and use [PEP] as a way to do this, but we didn't spend a lot of >> time thinking about the mechanics and implications here. > > >>>>> - Need to address authorization for SMK release. >>>>> > >> I have pretty much hand-waved over this part. One idea that >> came to light this week was to provide fingerprints for the >> recipients' public keys, somehow. Suggestions for improvements >> are welcome. > >>>>> - Include some guidance on SMK lifetime. > >> There is *some* guidance in section 11.2, but I admit it is >> rather vague. Could you provide more specific suggestions? > >>> As above, will try to send some text next week. > > > _______________________________________________ xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > > > > > -- Simon Tennant | buddycloud.com | +49 17 > 8545 0880 | office hours: goo.gl/tQgxP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTkc4oAAoJEDWi+S0W7cO1OvIH/3JTH5HslWSzfR6g38blta5G AOYhYnfqe7YzEDOmexyIlqdetGX64JKlMw4y6Jhxkfptt6CKskDAMTKmkSsRUJf0 qVDDDmWuBFiyr9Es8rzCJTA4sRQalE8+60pf2IOKjwOSgwcYD+sqNV/r1u0cqK+A 7yt1cOBwt56L5vxgN5EKDZkX5XntLYxqM6HX65D6Ob3zoMJWN0NC8InXpaWxbNOU FJDX6Bsru03UeW6+DjUKPSiF9/BPvQCMt7SPICYnySjFzh/ttBAnDXwbnPDrd3IX gWENKbNSpmt296H2n2de0uOg48mbJPP86YR+VxvDmszrOGyvZmmti3YpihcG2QA= =R/5j -----END PGP SIGNATURE----- From nobody Fri Jun 6 12:48:07 2014 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 C465F1A00FC for ; Fri, 6 Jun 2014 12:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 qOWctuVLPTck for ; Fri, 6 Jun 2014 12:48:05 -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 79FE71A0163 for ; Fri, 6 Jun 2014 12:48:05 -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.14.9/8.14.7) with ESMTP id s56Jlsn4099727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jun 2014 14:47:56 -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] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell In-Reply-To: <5384D9E8.5000601@stpeter.im> Date: Fri, 6 Jun 2014 14:47:54 -0500 X-Mao-Original-Outgoing-Id: 423776874.06667-c90d196d5be3094769a0e1a6ffde5397 Content-Transfer-Encoding: quoted-printable Message-Id: <6FF542E9-904E-4997-936F-D4C61087179A@nostrum.com> References: <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net> <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com> <5384D9E8.5000601@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/CH0x-DHvfUpvA3JdKLOXbb33ha8 Cc: XMPP Working Group Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02 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 Jun 2014 19:48:06 -0000 Sorry for the delay. I just returned from a very disconnected vacation. On May 27, 2014, at 1:31 PM, Peter Saint-Andre = wrote: > Connection managers are trusted server components, so the = administrators of the service are aware that there is a CM in the mix, = but the server need not be (all it knows is that sessions have been = created and that some trusted entity did so). >=20 >> Is it assumed to >> implement this draft? >=20 > The server doesn't really need to implement the websocket aspect of = things, since that's handled by the CM. >=20 >> Are we requiring special behavior of the >> server, without the server knowing it needs to do it? >=20 > Not as far as I can see. Is there any reason to mention connection managers at all? Unless I = missed something, the draft only mentions them parenthetically, but it = does so in a normative statement. It's starting to sound like an = implementation detail that doesn't need anything normative, if any = mention at all. From nobody Fri Jun 6 12:50:31 2014 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 C41C21A0225 for ; Fri, 6 Jun 2014 12:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 izyhJaubrOWh for ; Fri, 6 Jun 2014 12:50:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 495121A0207 for ; Fri, 6 Jun 2014 12:50:29 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3F62E40D01; Fri, 6 Jun 2014 13:50:22 -0600 (MDT) Message-ID: <53921B7C.8080403@stpeter.im> Date: Fri, 06 Jun 2014 13:50:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ben Campbell References: <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net> <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com> <5384D9E8.5000601@stpeter.im> <6FF542E9-904E-4997-936F-D4C61087179A@nostrum.com> In-Reply-To: <6FF542E9-904E-4997-936F-D4C61087179A@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/n23C6PgXz2LiDhsMjyvFwsTwPvY Cc: XMPP Working Group Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02 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 Jun 2014 19:50:30 -0000 On 6/6/14, 1:47 PM, Ben Campbell wrote: > Sorry for the delay. I just returned from a very disconnected vacation. > > On May 27, 2014, at 1:31 PM, Peter Saint-Andre wrote: > >> Connection managers are trusted server components, so the administrators of the service are aware that there is a CM in the mix, but the server need not be (all it knows is that sessions have been created and that some trusted entity did so). >> >>> Is it assumed to >>> implement this draft? >> >> The server doesn't really need to implement the websocket aspect of things, since that's handled by the CM. >> >>> Are we requiring special behavior of the >>> server, without the server knowing it needs to do it? >> >> Not as far as I can see. > > Is there any reason to mention connection managers at all? Unless I missed something, the draft only mentions them parenthetically, but it does so in a normative statement. It's starting to sound like an implementation detail that doesn't need anything normative, if any mention at all. It is in fact an implementation detail. Peter From nobody Fri Jun 6 12:54:28 2014 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 49B581A0195 for ; Fri, 6 Jun 2014 12:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 2X57k3syoSdy for ; Fri, 6 Jun 2014 12:54:26 -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 377351A0078 for ; Fri, 6 Jun 2014 12:54:26 -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.14.9/8.14.7) with ESMTP id s56JsGe7000353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jun 2014 14:54:17 -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] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell In-Reply-To: <53921B7C.8080403@stpeter.im> Date: Fri, 6 Jun 2014 14:54:16 -0500 X-Mao-Original-Outgoing-Id: 423777256.140981-8404061a8f615e127eba9678c365bfa7 Content-Transfer-Encoding: quoted-printable Message-Id: <73438225-60E0-4301-ABD8-7AE8C8C7CDEE@nostrum.com> References: <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net> <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com> <5384D9E8.5000601@stpeter.im> <6FF542E9-904E-4997-936F-D4C61087179A@nostrum.com> <53921B7C.8080403@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/YbVBJIEQevi66ygW9bu7ddYW1y0 Cc: XMPP Working Group Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02 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 Jun 2014 19:54:27 -0000 On Jun 6, 2014, at 2:50 PM, Peter Saint-Andre = wrote: > On 6/6/14, 1:47 PM, Ben Campbell wrote: >> Sorry for the delay. I just returned from a very disconnected = vacation. >>=20 >> On May 27, 2014, at 1:31 PM, Peter Saint-Andre = wrote: >>=20 >>> Connection managers are trusted server components, so the = administrators of the service are aware that there is a CM in the mix, = but the server need not be (all it knows is that sessions have been = created and that some trusted entity did so). >>>=20 >>>> Is it assumed to >>>> implement this draft? >>>=20 >>> The server doesn't really need to implement the websocket aspect of = things, since that's handled by the CM. >>>=20 >>>> Are we requiring special behavior of the >>>> server, without the server knowing it needs to do it? >>>=20 >>> Not as far as I can see. >>=20 >> Is there any reason to mention connection managers at all? Unless I = missed something, the draft only mentions them parenthetically, but it = does so in a normative statement. It's starting to sound like an = implementation detail that doesn't need anything normative, if any = mention at all. >=20 > It is in fact an implementation detail. Strictly as an individual, I then propose we either remove the mention = entirely (my preference), or move it to an "implementation note" so that = it cannot be conflated with the normative statement it's currently = attached to. But I realize that's pretty pedantic, and if the authors are tired of = making new versions, I can live with it as is :-) >=20 > Peter From nobody Fri Jun 6 13:31:23 2014 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 A0CA01A023E; Fri, 6 Jun 2014 13:31:18 -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 30YUDb7IPHgK; Fri, 6 Jun 2014 13:31:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEE91A01B2; Fri, 6 Jun 2014 13:31:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606203117.8092.47273.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 13:31:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/puOPZrEmIgUEoiYsTi_w4Zw0xWY Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-websocket-07.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: Fri, 06 Jun 2014 20:31:18 -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 : An XMPP Sub-protocol for WebSocket Authors : Lance Stout Jack Moffitt Eric Cestari Filename : draft-ietf-xmpp-websocket-07.txt Pages : 14 Date : 2014-06-06 Abstract: This document defines a binding for the XMPP protocol over a WebSocket transport layer. A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-websocket-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-websocket-07 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 Fri Jun 6 13:36:14 2014 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 EE4CA1A01B2 for ; Fri, 6 Jun 2014 13:36:11 -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 ysX9XEYi2P-n for ; Fri, 6 Jun 2014 13:36:10 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4751A0025 for ; Fri, 6 Jun 2014 13:36:10 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rq2so2933427pbb.3 for ; Fri, 06 Jun 2014 13:36:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=OKwZsOqVSZ8vSuKAd5MPG/jaokQp+DoxuiH6PGixQic=; b=C1H8NOBs8bdDutlymY7IdHqlJWv+1nJxC6NSrXjBoEAtK7C5fnp56I+iqr/oJpUBQu bMnCaVu65M/3GfE/HL3MS0ytCq80sq1MHbM2M0hj9K65trVusjaCQ69PnWeG0bePdJvo ILbudmIWMg8vmKZLFLEZ4ZRG+poyeEyRVtmS+uwY4kaqSbjT0ePTfWGg2cYnm2/UuwwD 6KtGxaVLU7+TLeMr3aRHZ/jObxv3g+Df3Ib2Ri4cE4otllQNhoroQgvd2ZyNB8FwYLAa 6+dXKM5Rz1fn55GB7aRUxfEW4tornb73w4jET9lSKkftsdQcttxD67sB313yHFhhqENr hYig== X-Gm-Message-State: ALoCoQnILCKSrTKajP+lnXeurCk6O6E4/FiJn8NQo+Uv4H9Lgf70ghZVtTCV223A2/fNWNrSq96o X-Received: by 10.68.242.135 with SMTP id wq7mr4581822pbc.147.1402086963616; Fri, 06 Jun 2014 13:36:03 -0700 (PDT) Received: from [192.168.1.23] (66-191-14-77.static.knwc.wa.charter.com. [66.191.14.77]) by mx.google.com with ESMTPSA id jt7sm39548390pbc.46.2014.06.06.13.36.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Jun 2014 13:36:02 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E7724817-C649-48D3-A14D-3B3D633ED489"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Lance Stout In-Reply-To: <73438225-60E0-4301-ABD8-7AE8C8C7CDEE@nostrum.com> Date: Fri, 6 Jun 2014 13:36:00 -0700 Message-Id: <0F867757-72F8-4961-9B0C-476F2987652C@andyet.net> References: <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net> <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com> <5384D9E8.5000601@stpeter.im> <6FF542E9-904E-4997-936F-D4C61087179A@nostrum.com> <53921B7C.8080403@stpeter.im> <73438225-60E0-4301-ABD8-7AE8C8C7CDEE@nostrum.com> To: XMPP Working Group X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/ganCRzK958s6d1CHIb7vTunW0Rs Cc: Ben Campbell Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02 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 Jun 2014 20:36:12 -0000 --Apple-Mail=_E7724817-C649-48D3-A14D-3B3D633ED489 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Strictly as an individual, I then propose we either remove the mention = entirely (my preference), or move it to an "implementation note" so that = it cannot be conflated with the normative statement it's currently = attached to. >=20 > But I realize that's pretty pedantic, and if the authors are tired of = making new versions, I can live with it as is :-) Not tired. I've removed the offending parenthetical :-) However, I did amend the Security Considerations based on the prior = discussion here, stating that if the XMPP over WebSocket service is = provided as an intermediary between the XMPP server and client, then it = SHOULD use an encrypted channel between itself and the XMPP server. = Likewise, a client would need to use e2e encryption if it truly wants = data privacy as there's no way to prove that the WS intermediary really = is using encryption to the XMPP server. (The same considerations that = apply for BOSH services) =97 Lance= --Apple-Mail=_E7724817-C649-48D3-A14D-3B3D633ED489 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 KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNjA2MjAzNjAxWjAjBgkq hkiG9w0BCQQxFgQUxnsX4kiNcyTVL6jbKCI6K8zzW7cwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIvpTCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkg SW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwDQYJKoZIhvcNAQEBBQAEggEApuBcFsrLkxrH/AKw jpwvd9cF7nYHrM77BKMUKxm/XZBIJ4CzTizY3BxT7lMWVyHI5VnDmJ0ZWavM1rYY2t4SDOmxkF/c CWcbspKjWY0A+68y4/8nTnZh/+FWudxOo4LydONP+DsTctnwqlrm4PNTo6CZIkk0JI/zTzdRjIQg MROWt2REfGChDDckUEQs7yopFd8Vwqex0Y86My8oHSUe5YMVimEnqUpSkY9bk4sIDYwCzRBrWmZ3 tCmSQ/PymRjIwjbU4743+sVavzVAi9BX585j4+qfDLY1I0HUhlSElbFJPoy7Rm3ksTMlz23jtlbZ 7dV7rlEcURIY0aW0YrZ+9gAAAAAAAA== --Apple-Mail=_E7724817-C649-48D3-A14D-3B3D633ED489-- From nobody Fri Jun 6 14:33:56 2014 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 C6BC41A02A6 for ; Fri, 6 Jun 2014 14:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 YclusCKEzdlt for ; Fri, 6 Jun 2014 14:33:51 -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 265F61A0274 for ; Fri, 6 Jun 2014 14:33:50 -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.14.9/8.14.7) with ESMTP id s56LXe3h009051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jun 2014 16:33:42 -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] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell In-Reply-To: <0F867757-72F8-4961-9B0C-476F2987652C@andyet.net> Date: Fri, 6 Jun 2014 16:33:40 -0500 X-Mao-Original-Outgoing-Id: 423783220.38295-1fab9a14bd3ebd1cce90af2c42c87990 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net> <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com> <5384D9E8.5000601@stpeter.im> <6FF542E9-904E-4997-936F-D4C61087179A@nostrum.com> <53921B7C.8080403@stpeter.im> <73438225-60E0-4301-ABD8-7AE8C8C7CDEE@nostrum.com> <0F867757-72F8-4961-9B0C-476F2987652C@andyet.net> To: Lance Stout X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/i9iHQwJ9uBqMpDR65OtsSH0MMSU Cc: XMPP Working Group Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02 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 Jun 2014 21:33:52 -0000 On Jun 6, 2014, at 3:36 PM, Lance Stout wrote: >=20 >> Strictly as an individual, I then propose we either remove the = mention entirely (my preference), or move it to an "implementation note" = so that it cannot be conflated with the normative statement it's = currently attached to. >>=20 >> But I realize that's pretty pedantic, and if the authors are tired = of making new versions, I can live with it as is :-) >=20 > Not tired. I've removed the offending parenthetical :-) >=20 >=20 > However, I did amend the Security Considerations based on the prior = discussion here, stating that if the XMPP over WebSocket service is = provided as an intermediary between the XMPP server and client, then it = SHOULD use an encrypted channel between itself and the XMPP server. = Likewise, a client would need to use e2e encryption if it truly wants = data privacy as there's no way to prove that the WS intermediary really = is using encryption to the XMPP server. (The same considerations that = apply for BOSH services) WFM Thanks! Ben. >=20 > =97 Lance From nobody Sun Jun 8 04:41:06 2014 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 435D91A03A4 for ; Sun, 8 Jun 2014 04:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, 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 PFJ0IK7smmAE for ; Sun, 8 Jun 2014 04:41:00 -0700 (PDT) Received: from mail.zash.se (sphyrna.zash.se [IPv6:2001:470:28:559::]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927141A03A3 for ; Sun, 8 Jun 2014 04:40:59 -0700 (PDT) Received: from [77.110.10.237] (ip3-237.bon.riksnet.se [77.110.10.237]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: zash) by mail.zash.se (Postfix) with ESMTPSA id 59ADD601F1 for ; Sun, 8 Jun 2014 13:40:49 +0200 (CEST) Message-ID: <53944BC0.1030300@zash.se> Date: Sun, 08 Jun 2014 13:40:48 +0200 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <538F9B0D.1030504@cisco.com> <538FA1BD.1070508@cisco.com> In-Reply-To: <538FA1BD.1070508@cisco.com> X-Enigmail-Version: 1.6 OpenPGP: id=B67AD329; url=http://zash.se/~zash/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HiXlv8x4EhFo3w9S44emxaQa9Qf6BJbkS" Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/42Y4FW9BWZlbrHaA1Wn44Mewsp4 Subject: Re: [xmpp] Fwd: [POSH] What's the point of using JWKs in POSH? 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: Sun, 08 Jun 2014 11:41:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HiXlv8x4EhFo3w9S44emxaQa9Qf6BJbkS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-06-05 00:46, Matt Miller wrote: > Each "fingerprint" is a JSON object, where the key is the hash > algorithm and the value is the base64 encoding of hashing the > DER-encoded certificate with the given algorithm. I do think that > algorithm agility is necessary, which means something more than a > simple array in my opinion. Generating this should be very simple; I > could kludge this together on the command-line pretty quickly >=20 > If the WG is ok with this, we can get a new revision of > draft-ietf-xmpp-posh out relatively soon (by next week). I'm ok with this. -- Kim "Zash" Alvefur --HiXlv8x4EhFo3w9S44emxaQa9Qf6BJbkS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTlEvAAAoJEK3tmne2etMpaKoP/1Ro6sB5+/3e8ngDvTsGut8X Ag0JLNvuS6pSsLDhQv0ZQbRTytztG8We5FnYve2L2LKV5lj1Pd0EvjFfl4JcDHio q3kz3V6HtvtCFLfgI7JFkNfCLB00/fUp8BwKV0BUQhi6VdiYDapBVP9SqQpg/6v/ AwGYnae+Nc2iHhXs4GEXfs0Lbx8jG4y54p1u2T9jXoD/5A94HgugqMWZWW+3C8Sr NFC2iuCf77Y5PNmyWvAx1gW0kZs7i8MSRD8QhhSF3U9p+Ufr+D2gm0OCRqkFoZ+4 pzX5bYmPRFz3dpWqzEKmFkY5DkkN08CZjnfH+ARZi7OsQMep/t29ZSHFDRduURhV fzRF7kY5j+8cqx+xUlQlEf2B9aVlqf/npnEJUB9rs3sypdObUgXKljlpvvpJvoj/ p9kbh41rZ6UwMD2QMXkuoaCtoli4TmjlqDwDqCzVqlHj+wK4ZMUay8LWC4daCLD0 q98xZClY92V8VD6FlFMdGyUbcBzG6e1+Ha7bLHaDeqOqzVRNQfc//4mKYnWoSFox PaPPEpeq9pQ5725KYWivyF7/GpJSUcKszLN3btGCSUVHQJcC08lqgdLt4aLz5B4B 5+j/GJ3iU08udD3hLZUmFuJSUCb+LPliJWl9s4bLtxFCXiyw8L/+FqwlhqlC+soN 11qiYcmP7MDwJ83JW/i4 =3bGT -----END PGP SIGNATURE----- --HiXlv8x4EhFo3w9S44emxaQa9Qf6BJbkS-- From nobody Mon Jun 9 03:14:47 2014 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 BB8F21A0032 for ; Mon, 9 Jun 2014 03:14:44 -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 hE7eWOm1y4WK for ; Mon, 9 Jun 2014 03:14:43 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34FD1A004C for ; Mon, 9 Jun 2014 03:14:43 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id g18so5649836oah.19 for ; Mon, 09 Jun 2014 03:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=0gWoKlG9NPCLmN55+Mjc4tYfrdC2d/TqyPvhiHxIrXk=; b=BlX0GH6hSxBy03AL746AE8cXujp1ftg2CI9HX0V6kjkeNE8TSl6gRR67tYUuO1KoSC k1nTCkoq898l91qawfkprp/tekj+msvWwIjCV+Td1t1TMB2EydOPu7BUuiDainym22b8 KUK4mAwfgvRx+i+oDla9h+QBA69aG9JLxYMfw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=0gWoKlG9NPCLmN55+Mjc4tYfrdC2d/TqyPvhiHxIrXk=; b=Jqb6sroV/NKOHiyNfOxOPsgUkNwMkMypbXAHZzyCBYrY1Rw+SHAumBr3LnIGdszsQr ngrEe911JjzZGu8Zb0MXhOwc1bz3pgC/X0uZWg+JnhOdUf+QR6xlFGcqR1OcqhMP9g/S PI4bRDybXehtfvrsgX4U9DxOaZcwa3AMdJ92tcDZKrK0R4k5MFE3KlUjYx9IstuTJa7N tLtBLF/rcCCMnWB/36k9/54gXRjwkpUiCbaNkxBLxtn797WfNVrYqq2h2oxfm5jOZAFa ZjjAw6uuL4GSSnskSBAPv9CyiHTKqx/54OzEycUBJoCpSDcuJr698KSrczT46x9xThRJ 7rjA== X-Gm-Message-State: ALoCoQmg+5mrMTkp8K7HDMW5NccRhnNSHCW0XxcVXRGdu7QNzo3MAzz6vISq0EtIDTDoVRImDkVR MIME-Version: 1.0 X-Received: by 10.182.232.135 with SMTP id to7mr1504048obc.73.1402308883172; Mon, 09 Jun 2014 03:14:43 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Mon, 9 Jun 2014 03:14:43 -0700 (PDT) Date: Mon, 9 Jun 2014 11:14:43 +0100 Message-ID: From: Dave Cridland To: XMPP Working Group Content-Type: multipart/alternative; boundary=001a11c32812d8ff3604fb647a5d Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/8J0O1MnEAoXdmOmFsaNJdE0snPY Subject: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 10:14:44 -0000 --001a11c32812d8ff3604fb647a5d Content-Type: text/plain; charset=UTF-8 https://datatracker.ietf.org/doc/draft-cridland-xmpp-session/ After some discussion in the XSF's chatrooms, I've submitted this which I think captures current practise and seems to be the least-unsensible option. Happy to have the WG adopt this if the chairs and WG desire, otherwise I'll go fishing for an AD sponsor. The nub is as described in its Section 2: 2. The Session Establishment Tombstone This specification formalizes the marker and explicitly defines the Session Establishment request itself as a no-op. Dave. --001a11c32812d8ff3604fb647a5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
https://datatracker.ietf.org/doc/draft-cridland-xmpp-sessio= n/

After some discussion in the XSF's chatro= oms, I've submitted this which I think captures current practise and se= ems to be the least-unsensible option.

Happy to have the WG adopt this if the chairs and WG de= sire, otherwise I'll go fishing for an AD sponsor.

=
The nub is as described in its Section 2:

2. =C2=A0The Session Establishment Tombstone

= =C2=A0 =C2=A0This specification formalizes the <optional/> marker and= explicitly
=C2=A0 =C2=A0defines the Session Establishment reques= t itself as a no-op.

Dave.
--001a11c32812d8ff3604fb647a5d-- From nobody Mon Jun 9 08:46:46 2014 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 4B4511A0216 for ; Mon, 9 Jun 2014 08:46:35 -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 Rn905wihfgh2 for ; Mon, 9 Jun 2014 08:46:27 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701921A0238 for ; Mon, 9 Jun 2014 08:46:20 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id jt11so5090274pbb.27 for ; Mon, 09 Jun 2014 08:46:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=kF3g/af4G/2RZD4GlshMvbOJ1z4x4P4Ex9/AZeAOmH0=; b=DBJ5/bvWEQrKIZDzlPVMiP4JDJSD+NKPWNAOnvon9ms9il8zeXvNtmNgFMkyVpcqFQ +kyBimwxC88XHYxWGGIg8jZb/FQdCBzp6I3IVf7nWbgG6VKS+syQ9cwTTct6rl8Aj9iv 6hQu56usMQJdpvheOTLFiX5cHVgp5T8oa8Qmdofy1Y4tmFjZPdXHHeddMabE09F0BrYV mvoCryoEYr+Lk2m3McPCiCyL3C5Q3uVSQ5zijfXxNZ+OqdiYtsc5xzXPo+PaPVIXj+KC B9PX7kPsCOeemer6PQ3BkVaU43sqV1AcFbG+pcAA24y1pZGLoIeKVN1BrpCVJIGZC7dN yabQ== X-Gm-Message-State: ALoCoQn1OhQqz0dZdxYKeEqOySLszEj9RoM2XKBa1JGo6vSNXCtEFz0ZX7C8YC67lxGKVNKae8Y3 X-Received: by 10.66.243.225 with SMTP id xb1mr5513295pac.49.1402328780061; Mon, 09 Jun 2014 08:46:20 -0700 (PDT) Received: from [192.168.1.23] (66-191-14-77.static.knwc.wa.charter.com. [66.191.14.77]) by mx.google.com with ESMTPSA id or4sm64707258pbb.17.2014.06.09.08.46.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 08:46:19 -0700 (PDT) From: Lance Stout Content-Type: multipart/signed; boundary="Apple-Mail=_17343B51-3FB8-4F03-9E2E-DAB13F5D06C2"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Mon, 9 Jun 2014 08:46:18 -0700 References: To: XMPP Working Group In-Reply-To: X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/a0bWqWP56AfidAUjaufyN5Xxy2A Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 15:46:35 -0000 --Apple-Mail=_17343B51-3FB8-4F03-9E2E-DAB13F5D06C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 for standardizing this. It's a pragmatic solution that lets us cut = out a round-trip during session startup without worrying about older = servers.= --Apple-Mail=_17343B51-3FB8-4F03-9E2E-DAB13F5D06C2 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 KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNjA5MTU0NjE4WjAjBgkq hkiG9w0BCQQxFgQU+l5UhN0YATsz86Cocoy6XpckbTEwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIvpTCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkg SW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwDQYJKoZIhvcNAQEBBQAEggEAlF0kNqhA8xZxEl7T mXJYnQfSif+fUvyClGtuiqa59wvsdkIwH7j0YKzXm7V51r9amBDjfGaqJnNGwSGa8pYPDwVV5+OH Pm5CDd/VvDKvr5fnY7LA2EEAfpMh8lHDA4Btik7QLbKDR9Cn4E/HzR8BsNl3UZBM9RTmQgsvptzp qrdGk2AzwFdK45ONUVaIIYu/Ch3B1y5uOOq6jtoqAd+ZaWEW9vRz8ULuJzP7MxBSHEeH3nwZqoyR iewcpLoBuOKlBV1iwIJFJqvdpvAha3jZpfJ8H1iufe3e3afiCJ9wMPBG9vRcajau2Xrykkppv60T o52Ias6bgF39xI4JKqZICwAAAAAAAA== --Apple-Mail=_17343B51-3FB8-4F03-9E2E-DAB13F5D06C2-- From nobody Mon Jun 9 08:59:35 2014 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 337AC1A0216 for ; Mon, 9 Jun 2014 08:59: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 jXS9yYMoBmcZ for ; Mon, 9 Jun 2014 08:59:31 -0700 (PDT) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C281A01EC for ; Mon, 9 Jun 2014 08:59:31 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kx10so866295pab.26 for ; Mon, 09 Jun 2014 08:59:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=hY2l8K6prm4ItuJNf8qeWW0rvJsJDtTvflvS/Z7+z9M=; b=ERW8s+wV7RhnH3FK2x7JFy/XE53f8WsxDGT1LzUmsx22sF25sRMkfMAeB8ugB+Ztd6 XVlEeUIyBZgEh5CIqLU9xEFDHyCRdAFaQ1Zg/+m/eIi8EL//TKa7CHNm/EvaXofinWq/ qDLBO+LRhzf9uawx75rlQQaM3njSvEnZXF5tOkCXAa0RIBUddydootaZ2m8fLJCNb0Mm zl6hsQWFV24Ha6sP953g8kuZaI/GBu7x2wJS939cvA3s9FIjsgZjoMEM8v1lkc3p3r0p 0/kIXfebTLTg3ti2c9Wp6uOOc6qZ86elPHorVyiq/cOwA4lKJ+j7Pc3T7gsMY88ZbFy9 9OgQ== X-Gm-Message-State: ALoCoQnTFYW5+X2mh8kNhQDD+FCRjpnn6pwpHbMVQhgPklKMvyfvKw+YenpfnLyUTmx99sPW99D9 X-Received: by 10.68.97.37 with SMTP id dx5mr5414839pbb.119.1402329571205; Mon, 09 Jun 2014 08:59:31 -0700 (PDT) Received: from [192.168.1.23] (66-191-14-77.static.knwc.wa.charter.com. [66.191.14.77]) by mx.google.com with ESMTPSA id ec2sm64695923pbc.63.2014.06.09.08.59.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 08:59:30 -0700 (PDT) From: Lance Stout Content-Type: multipart/signed; boundary="Apple-Mail=_F603D1AA-8A28-4901-BC78-58AB8C2A8EFD"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <78B53C44-9C02-4CB3-9D45-48748CA75F54@andyet.net> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Mon, 9 Jun 2014 08:59:28 -0700 References: <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net> <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com> <5384D9E8.5000601@stpeter.im> <6FF542E9-904E-4997-936F-D4C61087179A@nostrum.com> <53921B7C.8080403@stpeter.im> <73438225-60E0-4301-ABD8-7AE8C8C7CDEE@nostrum.com> <0F867757-72F8-4961-9B0C-476F2987652C@andyet.net> To: XMPP Working Group In-Reply-To: X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/ZCKOAVd3odeiZ_2HiLE1fMpW1jw Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02 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 Jun 2014 15:59:33 -0000 --Apple-Mail=_F603D1AA-8A28-4901-BC78-58AB8C2A8EFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > WFM >=20 > Thanks! >=20 > Ben. Then I think that all WGLC feedback has now been addressed in -07. Next = step? =97 Lance= --Apple-Mail=_F603D1AA-8A28-4901-BC78-58AB8C2A8EFD 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 KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNjA5MTU1OTI4WjAjBgkq hkiG9w0BCQQxFgQUqxgR6Gf3jlnqELaZ9eDxJzsPlUcwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIvpTCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkg SW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwDQYJKoZIhvcNAQEBBQAEggEAPZBWeTjvO3wVvpGX kKI+y4Qafzz+F95v+HCOedkHJ1HfpeMm81hI0AxSQ3r0Nvy7iY1N28JRSS/O4YIX8YqLQ7XBBFny s2BsMOCSnPXHs3eVNkFJ4b4g5SpjasYWMnI5pK5/E/RB1CWVofYQb87P+dweYOYGCLqlEnnH2Eui W/JVEQLkOL8CX2UEUV8k1b8oR0GeZKIUVZN9y0cZ3RHul+FmXAyXoOa2uCeWek7vQ8Pyn7E1fv+R XdCK6ZYzvoIEuzLmyW51KoimHCtkXdYF1SH31vmohgJO1uORlmEd6YrlPg9+XwOrnpkdysgVyQl+ 20VTfyYvJwpsvZr/oq2OlAAAAAAAAA== --Apple-Mail=_F603D1AA-8A28-4901-BC78-58AB8C2A8EFD-- From nobody Mon Jun 9 09:03:21 2014 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 27BF21A0238 for ; Mon, 9 Jun 2014 09:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.153 X-Spam-Level: X-Spam-Status: No, score=-1.153 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 NHsuxmORq36v for ; Mon, 9 Jun 2014 09:03:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 571F41A0201 for ; Mon, 9 Jun 2014 09:02:55 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E716B40C58; Mon, 9 Jun 2014 10:02:54 -0600 (MDT) Message-ID: <5395DAAE.8090906@stpeter.im> Date: Mon, 09 Jun 2014 10:02:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Lance Stout , XMPP Working Group References: <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net> <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com> <5384D9E8.5000601@stpeter.im> <6FF542E9-904E-4997-936F-D4C61087179A@nostrum.com> <53921B7C.8080403@stpeter.im> <73438225-60E0-4301-ABD8-7AE8C8C7CDEE@nostrum.com> <0F867757-72F8-4961-9B0C-476F2987652C@andyet.net> <78B53C44-9C02-4CB3-9D45-48748CA75F54@andyet.net> In-Reply-To: <78B53C44-9C02-4CB3-9D45-48748CA75F54@andyet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/ztN-JfVHQciPORhMR4BmrBi1FrU Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02 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 Jun 2014 16:03:21 -0000 On 6/9/14, 9:59 AM, Lance Stout wrote: > >> WFM >> >> Thanks! >> >> Ben. > > > Then I think that all WGLC feedback has now been addressed in -07. Next step? For my part as the document shepherd, I have reviewed the diff between 06 and 07, and have updated the writeup accordingly: https://stpeter.im/files/writeup-ietf-xmpp-websocket.txt IMHO we can proceed to WGLC. Peter From nobody Mon Jun 9 09:19:20 2014 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 D72931A0263 for ; Mon, 9 Jun 2014 09:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 PtIBYPlmQHeJ for ; Mon, 9 Jun 2014 09:19:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 39A531A00DE for ; Mon, 9 Jun 2014 09:19:18 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D04B340C58; Mon, 9 Jun 2014 10:19:17 -0600 (MDT) Message-ID: <5395DE85.6070606@stpeter.im> Date: Mon, 09 Jun 2014 10:19:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Philipp Hancke , XMPP Working Group References: <20131020230241.22714.80535.idtracker@ietfa.amsl.com> <52769F8B.8090306@goodadvice.pages.de> In-Reply-To: <52769F8B.8090306@goodadvice.pages.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/TPrCmrg4oPiTjHhKtxLmtVK8yuM Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-04.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 Jun 2014 16:19:20 -0000 On 11/3/13, 12:10 PM, Philipp Hancke wrote: > Am 21.10.2013 01:02, schrieb internet-drafts@ietf.org: >> >> 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) >> Author(s) : Peter Saint-Andre >> Matthew Miller >> Filename : draft-ietf-xmpp-dna-04.txt >> Pages : 16 >> Date : 2013-10-20 >> >> Abstract: >> This document improves the security of the Extensible Messaging and >> Presence Protocol (XMPP) in two ways. First, it specifies how >> "prooftypes" can establish a strong association between a domain name >> and an XML stream. Second, it describes how to securely delegate a >> source domain to a derived domain, which is especially important in >> virtual hosting environments. > > Just noticed that none of the terminology defined in section 2 is > actually used. I think the reference to XEP-0238 can therefore be removed. Yes, some of the terminology is used (e.g., "source domain") but none of the XEP-0238 terminology is used, so we can remove that text and the reference. > I do suspect the figure showing the overall process can be simplified as > proposed in > https://github.com/fippo/xmpp-fed/commit/913a183a5a74ea7b03a1b8a67164bb35df9e0c9b > but it has been long enough since that commit that I need to recheck this. Yes, the flow diagram is really long, so I agree that it'd be good to shorten it. Will review, too. Peter From nobody Mon Jun 9 09:22:27 2014 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 7F26C1A0264 for ; Mon, 9 Jun 2014 09:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 ZkQo7VmQ5aXx for ; Mon, 9 Jun 2014 09:22:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF281A01D0 for ; Mon, 9 Jun 2014 09:22:25 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1222C40C58; Mon, 9 Jun 2014 10:22:25 -0600 (MDT) Message-ID: <5395DF40.2030509@stpeter.im> Date: Mon, 09 Jun 2014 10:22:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Lance Stout , XMPP Working Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/zgOqCjvDB8ARnugCuh4E68HUHtk Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 16:22:26 -0000 On 6/9/14, 9:46 AM, Lance Stout wrote: > +1 for standardizing this. It's a pragmatic solution that lets us cut out a round-trip during session startup without worrying about older servers. +1, seems fine. That was the thinking behind RFC 6121 but it seems that we neglected to make the flag explicit. Peter From nobody Mon Jun 9 09:36:39 2014 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 439CC1A0275 for ; Mon, 9 Jun 2014 09:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 ZMjmII1W6r8F for ; Mon, 9 Jun 2014 09:36:36 -0700 (PDT) Received: from monet.mumbo.ca (monet.mumbo.ca [204.109.63.66]) by ietfa.amsl.com (Postfix) with ESMTP id CE66E1A0274 for ; Mon, 9 Jun 2014 09:36:35 -0700 (PDT) Received: from rembrandt.mumbo.ca (unknown [184.66.12.24]) by monet.mumbo.ca (Postfix) with ESMTPSA id 27F3C45021; Mon, 9 Jun 2014 09:36:33 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Curtis King In-Reply-To: <5395DF40.2030509@stpeter.im> Date: Mon, 9 Jun 2014 09:36:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> References: <5395DF40.2030509@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Ip_IfJ2ULSH02Mm2h8nqIYqGGBc Cc: XMPP Working Group Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 16:36:37 -0000 On Jun 9, 2014, at 9:22 AM, Peter Saint-Andre = wrote: > On 6/9/14, 9:46 AM, Lance Stout wrote: >> +1 for standardizing this. It's a pragmatic solution that lets us cut = out a round-trip during session startup without worrying about older = servers. >=20 > +1, seems fine. That was the thinking behind RFC 6121 but it seems = that we neglected to make the flag explicit. Instead of adding an redundant flag into the XMPP spec. Why doesn=92t = this draft state the flag explicit and give the session as = an example? Otherwise we will be adding to more features = than session. ck= From nobody Mon Jun 9 09:38:24 2014 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 51C271A0096 for ; Mon, 9 Jun 2014 09:38:15 -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 T0Gox-pI84W6 for ; Mon, 9 Jun 2014 09:38:13 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94E11A028B for ; Mon, 9 Jun 2014 09:38:12 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id g18so6173887oah.35 for ; Mon, 09 Jun 2014 09:38:12 -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=O5WYLNHKX9sc7KkJFb38mb4BFmsUCyBsuRAVk6O/acM=; b=Kzb07KyOVDW7/FGUnwlA7mLj225xy+z9TO0meUI+FR3bqVgIngT4kZJDTqFLVzfb45 hk+bOtcO8akVXuCczLix//cLsGG9XIaQg2p6I7tLFvB9HvN9doaDonaI3Xed+R1obO8g DZ9miU5H6wgA259Si+xUe7Y8sA1ITZ2wokD4M= 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=O5WYLNHKX9sc7KkJFb38mb4BFmsUCyBsuRAVk6O/acM=; b=j5LFYpz8ub7nYamFXuKK54UWSBwiKRy+7QqY0NrnpiIBUSgnvoRjNhlMUBiPwgZGas 6pky5FQwLyEQ6+/UjhmoXAHlwiWyPY7ype5eLUUliUbpzpTdvuDiQueDjNxbXyrTcRPE Mhq3MJL/j5Tpz0iXZkt49nvET6Qo0Rib3CmbQKqCHzscOka3PWyOICd58APStTBZkRpn xvq1toDyYSeQnWJ5+VIORAEOVpyL1hiYFebLmyIGiGoai7pzUKclgn+hyU3V5jJbT6Kp Ug3loH3VUpH7qLgwHQ8R7D2tZcCYDxhh1osvc5y/vRuOUCm+bfj5oYMmIdl8yItocd/a 6UMg== X-Gm-Message-State: ALoCoQlpJ+B5zcS4jVnYUR07QPmHHmlWWUf0Ea7sv661HN2Hcz5xGfZ++e+I10rhT8JnuJWZo+Pa MIME-Version: 1.0 X-Received: by 10.182.60.65 with SMTP id f1mr3471327obr.78.1402331892271; Mon, 09 Jun 2014 09:38:12 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Mon, 9 Jun 2014 09:38:12 -0700 (PDT) In-Reply-To: <5395DF40.2030509@stpeter.im> References: <5395DF40.2030509@stpeter.im> Date: Mon, 9 Jun 2014 17:38:12 +0100 Message-ID: From: Dave Cridland To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=089e01538ad84becf104fb69d6ee Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/F8StyS2NcUKakBPOMILHZr2O7ec Cc: XMPP Working Group Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 16:38:15 -0000 --089e01538ad84becf104fb69d6ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A careful reading of RFC 3921 suggests that is itself optional - if it's not there, it means you don't do it. So from a purely theoretical standpoint, we were right to just drop it in 6121. Unfortunately, it seems that existing clients (old versions of Smack, for example) actually generate errors if it's not advertised, and in fairness, it's not stand-out clear that wasn't mandatory for IM servers; it certainly looks from 3921=C2=A7C.1 that it's a requirement of XMPP (over Jabber). On 9 June 2014 17:22, Peter Saint-Andre wrote: > On 6/9/14, 9:46 AM, Lance Stout wrote: > >> +1 for standardizing this. It's a pragmatic solution that lets us cut ou= t >> a round-trip during session startup without worrying about older servers= . >> > > +1, seems fine. That was the thinking behind RFC 6121 but it seems that w= e > neglected to make the flag explicit. > > Peter > > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > --089e01538ad84becf104fb69d6ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A careful reading of RFC 3921 suggests that <session/&g= t; is itself optional - if it's not there, it means you don't do it= . So from a purely theoretical standpoint, we were right to just drop it in= 6121.

Unfortunately, it seems that existing clients (old versions = of Smack, for example) actually generate errors if it's not advertised,= and in fairness, it's not stand-out clear that <session/> wasn&#= 39;t mandatory for IM servers; it certainly looks from 3921=C2=A7C.1 that i= t's a requirement of XMPP (over Jabber).


On 9 Ju= ne 2014 17:22, Peter Saint-Andre <stpeter@stpeter.im> wrote= :
On 6/9/14, 9:46 AM, Lance Stout wrote:
+1 for standardizing this. It's a pragmatic solution that lets us cut o= ut a round-trip during session startup without worrying about older servers= .

+1, seems fine. That was the thinking behind RFC 6121 but it seems that we = neglected to make the <optional/> flag explicit.

Peter


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

--089e01538ad84becf104fb69d6ee-- From nobody Mon Jun 9 09:54:04 2014 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 0EB9C1A0278 for ; Mon, 9 Jun 2014 09:54: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 pPvI6J1mIg0O for ; Mon, 9 Jun 2014 09:54:02 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC09C1A0274 for ; Mon, 9 Jun 2014 09:54:01 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id i7so1398874oag.8 for ; Mon, 09 Jun 2014 09:54: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=RPXHP7YELi/FrujN5JjHoM2TT8lQRVg3iKqu8JBA8dc=; b=TQmzKnADvKiWwGQa7ddd7lO5CZJnqORN407a2d2EcY5l3A73vWs8R1n4C/kn95epQ7 Hch6SEklzWV2ph4Fridunl9RP0ocFj74Psw1qyHIn9hFn3rlsCfZnPd1MP5cz9bcKs/W G7vVh/YLULEuKCcnrrj32v16PwtG7AMVJDAFA= 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=RPXHP7YELi/FrujN5JjHoM2TT8lQRVg3iKqu8JBA8dc=; b=IgX+sWG8d4tn2pDkdnE0/oH1+ovOrFn2+GoRKIGfn7ueOaH0lLyfvcW+PML5SUM+/l cm9Offsf0mMbiLN/r8i2kbMaEFimPPHYKXkiuoLSGwuYYGH7+PiBqoMqHXEQQPmFXwBL 8k/6t8gicEfqBoeHcq41b6LR7qEK+wjNmRQYCBsmYb+iOfRxWA/d7mlRXhGSIlXWe1zI FtGNq6mO+naP0iKmVcUHqIVNEX5z2319FwH5TiiPwQmxOh+x4Za+pnnBrkYbkbvhWjcY qUppMvkxiLU89ncntVtPe/W/1KBxXGdYjv8pTLru9A/Sp2N8Zi5GXu08+KmbGZYfFCMJ m2nw== X-Gm-Message-State: ALoCoQmr1H4mz3f3/oc82EENJSRm8FVgKG3b6Zvzvr1vwCELHmKSKQnV5kD2Vod2kCffDl7yr9Z9 MIME-Version: 1.0 X-Received: by 10.60.132.207 with SMTP id ow15mr10673623oeb.59.1402332841328; Mon, 09 Jun 2014 09:54:01 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Mon, 9 Jun 2014 09:54:01 -0700 (PDT) In-Reply-To: <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> Date: Mon, 9 Jun 2014 17:54:01 +0100 Message-ID: From: Dave Cridland To: Curtis King Content-Type: multipart/alternative; boundary=047d7b472832dd53e104fb6a0e68 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Ox6bpIWairNuPEeZi2sZGdnAsLE Cc: XMPP Working Group Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 16:54:03 -0000 --047d7b472832dd53e104fb6a0e68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9 June 2014 17:36, Curtis King wrote: > Instead of adding an redundant flag into the XMPP spec. Why doesn=E2=80= =99t this > draft state the flag explicit and give the session as an > example? Otherwise we will be adding to more features than > session. > We've discussed, and rejected, this before, for example: http://www.ietf.org/mail-archive/web/xmpp/current/msg02403.html http://www.ietf.org/mail-archive/web/xmpp/current/msg01125.html I'm not averse to reopening the discussion, though I'll still argue against it. One or other of a generic and will always be redundant, and multiple elements will often conflict. In any case, you'll note that in this instance doesn't really mean "optional" so much as "redundant" - in fact, I think the name is an artifact of the discussion we had back then, though I can't find the thread that proposes it in this case. (But both M-Link and Prosody do this, so I assume it was discussed sometime). Dave. --047d7b472832dd53e104fb6a0e68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 9= June 2014 17:36, Curtis King <cking@mumbo.ca> wrote:
Instead of adding an redundant flag into the XMPP spec. Why= doesn=E2=80=99t this draft state the <optional/> flag explicit and g= ive the session as an example? Otherwise we will be adding <optional/>= ; to more features than session.

We've discussed, and rejected, t= his before, for example:


I'm not averse to reopening the discu= ssion, though I'll still argue against it. One or other of a generic &l= t;optional/> and <required/> will always be redundant, and multipl= e <required/> elements will often conflict.

In any case, you'll note that <optional/> in = this instance doesn't really mean "optional" so much as "= ;redundant" - in fact, I think the name is an artifact of the discussi= on we had back then, though I can't find the thread that proposes it in= this case. (But both M-Link and Prosody do this, so I assume it was discus= sed sometime).

Dave.

--047d7b472832dd53e104fb6a0e68-- From nobody Mon Jun 9 10:13:01 2014 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 AF3591A01D6 for ; Mon, 9 Jun 2014 10:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 qPjFCwVzBXa9 for ; Mon, 9 Jun 2014 10:12:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 23DCA1A01AC for ; Mon, 9 Jun 2014 10:12:58 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 39FEB40C58; Mon, 9 Jun 2014 11:12:57 -0600 (MDT) Message-ID: <5395EB18.4090701@stpeter.im> Date: Mon, 09 Jun 2014 11:12:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Philipp Hancke , xmpp@ietf.org References: <20140204202306.13810.80083.idtracker@ietfa.amsl.com> <530E5C61.1010000@goodadvice.pages.de> In-Reply-To: <530E5C61.1010000@goodadvice.pages.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/kfGiF7l86Xtpf6-Lw8de_VslCcw Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.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 Jun 2014 17:12:59 -0000 On 2/26/14, 2:28 PM, Philipp Hancke wrote: > Am 04.02.2014 21:23, schrieb internet-drafts@ietf.org: >> >> 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. > [...] > > I've been prodded to give feedback again... > overall, I (still) think the technique described solve the problem. > The description still confuses me and I want to rewrite this from > scratch, but lack the time to actually do this. > > In part, this confusion seems to be caused by the attempt to do both C2S > and S2S. DNA is needed for both, but the document mostly describes S2S, > which is the more complicated case. > > I think starting with a C2S scenario would be better. It's alot easier > because only a single party does DNA. Explaining delegation and > multi-tenancy is easier, too. That is all true, and you make a good point. I think I'll work on this a bit for the next version, because the C2S case is indeed easier to describe and we want folks to understand the general concept. > I have a problem with the description of S2S. > Bullet #6 in section 4 (as well as the flow chart) puts the creation of > the association immediately after the TLS negotation. > > While authentication happens during/after the TLS handshake and the > subsequent exchange of stream headers, there is an identity assertion > step which is done either using SASL (EXTERNAL) or . > > IMO this is where the domain name association is created. Yes! > And it gets alot easier to explain the need for stuff like piggybacking > in subsequent sections. > > For C2S (or the client role of S2S), I actually agree that the client > creates the association immediately after (or during) the TLS handshake, > i.e. MUST check whether they like their counterparts authorization > enough to continue. But clients have a concept of expected identity of > the server (RFC 6125?) Correct. > Servers, however, do not yet know who their counterpart is or wants to > act as (assuming they discarded all information that was obtained in an > insecure way before the TLS handshake). > > > Additionally, there is no clear definition of what "A establishes DNA > for B" actually means, which may be another source of confusion. > It seems to be an entry in a list of "i know who this guy is"-domains > which can then be used in dialback. > However, so far I haven't felt a need to explicitly implement it that > way, probably because most of the time a synchronus lookup in the list > of domains contained in the cert was enough. DANE and POSH change that > obviously. Hmm, yes. We do need to explain this better. Matt and I will go back to the workshop and see what we can fashion. :-) Peter From nobody Mon Jun 9 10:36:01 2014 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 D982C1A01AC for ; Mon, 9 Jun 2014 10:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] 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 P795gLTsw4ZY for ; Mon, 9 Jun 2014 10:35:56 -0700 (PDT) Received: from s.xnyhps.nl (s.xnyhps.nl [46.19.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id BADB41A00BD for ; Mon, 9 Jun 2014 10:35:55 -0700 (PDT) Received: from [192.168.1.11] (196pc201.sshunet.nl [145.97.201.196]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by s.xnyhps.nl (Postfix) with ESMTPSA id 7C01B2042A for ; Mon, 9 Jun 2014 19:35:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=xnyhps.nl; s=mail; t=1402335352; bh=vOtX00BMg2BzSuV1GdDsErH3i+iBV4mNOyEAwUwbWaw=; h=From:Subject:Date:References:To:In-Reply-To; b=p5wZ2bLzne893PyMYxIQ92lj7pvW56Wks2gzsmXHvPYrB+LgstxEPWQsP4vkh9Kbn a/F6eSWW1W5r4/Ia5ZbjXWdGd6s+W6qCQbHniz0lgmhMF8YZpBGeADYe2svvddpXGf mwJWO/DoAbUxATE/kQC342NlqwAIp5EHy/RgxfAg= From: Thijs Alkemade Content-Type: multipart/signed; boundary="Apple-Mail=_1322ABE1-C9A3-470B-9E8C-565D72786C2A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Mon, 9 Jun 2014 19:34:23 +0200 References: <538F9B0D.1030504@cisco.com> <538FA1BD.1070508@cisco.com> To: XMPP Group In-Reply-To: <538FA1BD.1070508@cisco.com> X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/fqCnMB5GAo7sPYRSoWA-YNDr9K4 Subject: Re: [xmpp] [POSH] What's the point of using JWKs in POSH? 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 Jun 2014 17:35:58 -0000 --Apple-Mail=_1322ABE1-C9A3-470B-9E8C-565D72786C2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Resending this message from the right address. Sorry for the duplicate = copy, Matt.] On 5 jun. 2014, at 00:46, Matt Miller wrote: > Signed PGP part > On 6/4/14, 4:17 PM, Matt Miller wrote: >> [ Forwarding to the xmpp@ietf.org mailing list on behalf of Thjis >> Alkemade ] >>=20 >> Hello, >>=20 >> Today, I've spent some time on trying to implement POSH-checking >> for xmpp.net. My implementation aimed to do two things: doing the >> validation as described and showing someone how they could set up >> their .well-known file by converting their X509 certificates to >> JSON Web Keys. >>=20 >> The latter part was a lot more work than the former and made me >> wonder why it is defined the way it is. >>=20 >> =46rom draft-ietf-xmpp-posh: >>=20 >> Each included JWK object MUST possess the following information: >>=20 >> o The "kty" field set to the appropriate key type used for TLS >> connections (e.g., "RSA" for a certificate using an RSA key). >>=20 >> o The required public parameters for the key type (e.g., "n" and >> "e" for a certificate using an RSA key). >>=20 >> o The "x5t" field set to the certificate thumbprint, as described >> in section 3.6 of [JOSE-JWK]. >>=20 >> Yet the data that is required in the first and second bullet is >> never used. It doesn't specify if and how clients should verify >> it. Verification only uses the x5t field and optionally x5c. >>=20 >> There are good arguments for "pinning" just the public key. >> draft-ietf-websec-key-pinning only uses the SPKI field, DANE can >> use either the full cert or its SPKI field (and optionally hashed). >> But the way it is specified here won't allow that: the x5t field >> always needs to be present and clients should verify it. >>=20 >> So the public parameters of the key are useless here, but they make >> a key >10x as large is they have to be. Generating them is also not >> as easy: most certificate viewers show a SHA1 fingerprint and it's >> really easy to do with the openssl cli tool, but extracting n and e >> and base64-encoding them is a lot more work. I wouldn't even know >> what to do for ECDSA keys. >>=20 >> Are there any interoperability reasons for using JWKs that I'm not >> aware of? Couldn't it just use a list of SHA1 hashes? >>=20 >> Best regards, Thijs >=20 > As I stated in the previous venue (posh@ietf.org), us authors were > originally working to support various other use-cases, such as > browserid. However, no one is arguing to actually support those other > use-cases, so the desire to use JWKs is much less. >=20 > My co-author and I discussed this today, and think what would be best > is to switch from using a JWK-set to (roughly) your suggestion of a > list of hashes. It would allow us to stay with a single syntax for > both the "by-reference" and "by-value" documents, as well as provide a > simple point of extension (if that is ever necessary). >=20 > An example: >=20 > { > "fingerprints": [ > { > "sha-1": "ij39Ctarv+LwSw45qoqaZl7venM=3D", > "sha-256": "WhEr4Lpv2L5pv769aRj9rrm4G6MNNCfQlre23Gol/eA=3D" > }, > { > "sha-1": "JWow1EHNSbNyRfhQchi22bjurr0=3D", > "sha-256": "K52a2gXfrjchMLYwv16QyOtv5bkKRE6rnR30hY3JM8k=3D" > } > ], > "expires": 604800 > } >=20 > Each "fingerprint" is a JSON object, where the key is the hash > algorithm and the value is the base64 encoding of hashing the > DER-encoded certificate with the given algorithm. I do think that > algorithm agility is necessary, which means something more than a > simple array in my opinion. Generating this should be very simple; I > could kludge this together on the command-line pretty quickly >=20 > If the WG is ok with this, we can get a new revision of > draft-ietf-xmpp-posh out relatively soon (by next week). >=20 This looks good to me! Thijs --Apple-Mail=_1322ABE1-C9A3-470B-9E8C-565D72786C2A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTlfAfAAoJELRGwhIrI4PE+4gP/iLpXUlHFqe4jXbJKcuiEXIY jgzDo5udzkzLRXIH01BRJ8DFmwywx6Uk6qVOMG45nZzvO5v4yj+VSUUyZRw5L3dh Xp6WRaJ0hTyQ80cmqlgyHlSDE9qvC00PeywmbNnkt9Cj8HMsdzMW9Uw6kal9Z6Xr 2P1unD9XQpt5gpozwO2Ux4hA3AcNdGt47AK6UJEaNfSh+qjVaxuI0FlZpUTSaUO9 Awosu82a9/UvblJ0g7kqldRTjhqe1TpsHVpWSZ6WXTOTJTu+6kUeczF9Q/8xrwCq Zk+8JiAJm49FdSrUWf+atdWD/4T3+faGu4O4WFysWG9Ys6bTmrKrPBbFKlZRocPR tZ3emNAe/omvdD8+w2QUS4GH3hEMhXy6G/cGdZ4NYqaqA7ickswQN1zWD4K28DVz vgx9pFbAgeT1hO1sRhoYKxVbm3rZ5s2+lhgOFGz9OObCrg/yGFVWpDRczuKaT0F5 S9qwsJCvjFF/NMVas9H1Ob3OYsCX3+zcv0whehJuYXznI3D+5FYSpCAx2VB+O+2U iLgyElc56R5BJpWXf/v6M2JQjG5yMkR5+p+mdmYOmFjgwiPl8kuR13V/Opnz5+ey Nc7pzYSbew9ZJVj3+8FwQxS4xrW/dHM1nY8WKBGgQYzm+bqY9FU9QeJM5KQ8WV6p 26MqmgolYjRZy0Rk/zD3 =n59H -----END PGP SIGNATURE----- --Apple-Mail=_1322ABE1-C9A3-470B-9E8C-565D72786C2A-- From nobody Mon Jun 9 11:20:42 2014 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 85D261A01AC for ; Mon, 9 Jun 2014 10:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.095 X-Spam-Level: X-Spam-Status: No, score=0.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 yL_3TxWdlTgo for ; Mon, 9 Jun 2014 10:33:14 -0700 (PDT) Received: from s.xnyhps.nl (s.xnyhps.nl [46.19.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id EBC961A00BD for ; Mon, 9 Jun 2014 10:33:13 -0700 (PDT) Received: from [192.168.1.11] (196pc201.sshunet.nl [145.97.201.196]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by s.xnyhps.nl (Postfix) with ESMTPSA id 445F42042A; Mon, 9 Jun 2014 19:33:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thijsalkema.de; s=mail; t=1402335188; bh=wc3mwXHtjREq4t5hPZaobV+DoKJItvsc7B1f19Z6OQk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=l3r6587VnXU+ngvtlD7AfeQzB/bPsoi5WONXCnLdGWtAxQDbOOuRLGdFXyxmgamzu GFq8GG4gPjpyvEeVfZLgpUHZuX1op9YcMJGyRPSWc6hvNgtoIPFzcnEVFHwIBp9C0r QVES+aaM8kHIuROFNWMTbT0Ln1QhLMrO2UroeJR4= Content-Type: multipart/signed; boundary="Apple-Mail=_BE5F04E7-BFD2-46BF-959D-CFBFE42F0A30"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Thijs Alkemade In-Reply-To: <538FA1BD.1070508@cisco.com> Date: Mon, 9 Jun 2014 19:31:33 +0200 Message-Id: <5A8EFA13-AB45-4D9C-BE9F-8A4C16BD1B3D@thijsalkema.de> References: <538F9B0D.1030504@cisco.com> <538FA1BD.1070508@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Ll2A_8mP_tJI7sw-losk7vZM3qg X-Mailman-Approved-At: Mon, 09 Jun 2014 11:20:39 -0700 Cc: XMPP Group Subject: Re: [xmpp] [POSH] What's the point of using JWKs in POSH? 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 Jun 2014 17:33:16 -0000 --Apple-Mail=_BE5F04E7-BFD2-46BF-959D-CFBFE42F0A30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 5 jun. 2014, at 00:46, Matt Miller wrote: > Signed PGP part > On 6/4/14, 4:17 PM, Matt Miller wrote: > > [ Forwarding to the xmpp@ietf.org mailing list on behalf of Thjis > > Alkemade ] > > > > Hello, > > > > Today, I've spent some time on trying to implement POSH-checking > > for xmpp.net. My implementation aimed to do two things: doing the > > validation as described and showing someone how they could set up > > their .well-known file by converting their X509 certificates to > > JSON Web Keys. > > > > The latter part was a lot more work than the former and made me > > wonder why it is defined the way it is. > > > > From draft-ietf-xmpp-posh: > > > > Each included JWK object MUST possess the following information: > > > > o The "kty" field set to the appropriate key type used for TLS > > connections (e.g., "RSA" for a certificate using an RSA key). > > > > o The required public parameters for the key type (e.g., "n" and > > "e" for a certificate using an RSA key). > > > > o The "x5t" field set to the certificate thumbprint, as described > > in section 3.6 of [JOSE-JWK]. > > > > Yet the data that is required in the first and second bullet is > > never used. It doesn't specify if and how clients should verify > > it. Verification only uses the x5t field and optionally x5c. > > > > There are good arguments for "pinning" just the public key. > > draft-ietf-websec-key-pinning only uses the SPKI field, DANE can > > use either the full cert or its SPKI field (and optionally hashed). > > But the way it is specified here won't allow that: the x5t field > > always needs to be present and clients should verify it. > > > > So the public parameters of the key are useless here, but they make > > a key >10x as large is they have to be. Generating them is also not > > as easy: most certificate viewers show a SHA1 fingerprint and it's > > really easy to do with the openssl cli tool, but extracting n and e > > and base64-encoding them is a lot more work. I wouldn't even know > > what to do for ECDSA keys. > > > > Are there any interoperability reasons for using JWKs that I'm not > > aware of? Couldn't it just use a list of SHA1 hashes? > > > > Best regards, Thijs > > As I stated in the previous venue (posh@ietf.org), us authors were > originally working to support various other use-cases, such as > browserid. However, no one is arguing to actually support those other > use-cases, so the desire to use JWKs is much less. > > My co-author and I discussed this today, and think what would be best > is to switch from using a JWK-set to (roughly) your suggestion of a > list of hashes. It would allow us to stay with a single syntax for > both the "by-reference" and "by-value" documents, as well as provide a > simple point of extension (if that is ever necessary). > > An example: > > { > "fingerprints": [ > { > "sha-1": "ij39Ctarv+LwSw45qoqaZl7venM=", > "sha-256": "WhEr4Lpv2L5pv769aRj9rrm4G6MNNCfQlre23Gol/eA=" > }, > { > "sha-1": "JWow1EHNSbNyRfhQchi22bjurr0=", > "sha-256": "K52a2gXfrjchMLYwv16QyOtv5bkKRE6rnR30hY3JM8k=" > } > ], > "expires": 604800 > } > > Each "fingerprint" is a JSON object, where the key is the hash > algorithm and the value is the base64 encoding of hashing the > DER-encoded certificate with the given algorithm. I do think that > algorithm agility is necessary, which means something more than a > simple array in my opinion. Generating this should be very simple; I > could kludge this together on the command-line pretty quickly > > If the WG is ok with this, we can get a new revision of > draft-ietf-xmpp-posh out relatively soon (by next week). > This looks good to me! Thijs --Apple-Mail=_BE5F04E7-BFD2-46BF-959D-CFBFE42F0A30 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTle96AAoJELRGwhIrI4PE2oQQAIbsc0GvUrR9ixRgHnMc/Bxf zCtFwjqqFi2zAeA1wrYY4W3g6k9Raz1otoKQIt4nPMQm9XF5Jdw3/fdFj0AwN5u4 0DkgpF3v4syo2zgjKoMMh63iaKThJqOZsaLIMXSe1HTigMmh2P7iTlskriWsImVH QmahL6sZ+il9nEB6p+lVdWDTyF8SO+gS/YvZXwbtKC8Bve/XXsJXQCplVHEYSvqO +5Qw+67aTlJFFVvV0TPBCFTHCEiDHiOZaMbXatE3HJvlxsIC7VotQbeMEefA1Vvm m5xUywxubHe7utLCEtAx3YM0Ixew7l5kWA6qOWIkBM/HaqJfG/uBayZLBXkjQ+wY O9hIDRyjtWt+kjByS+33FMlk6v+uz9QinIpHAZKnFPpUMA6ZYfTu6RN8a3Tv5P3T EX6nl+chKPYOMt2Yn91JAwGjFhqhnao4HOQw6Nm8WEZj8AHvO29TL5TkvxI6ftxL yk7F5U4Kj0SRuOvV8i3N/0N+Hnk2ZWrKueI0mliVEVETcFNNKNHw5vrPfia+J4vN gJOMBB/0TbvysYalKzZDSHpCHM9MRuBT+3uVtfOraBkykO+YRfTBUNxdu1IONu4Z z0U5M4lbAhatljHbq2tvA/YLHcDTeSpgP1cBPvYwQjCk/vIyzjIsCqRuTji3vhXT bfATLN5L7N6MGrZEQ1Wl =nF4L -----END PGP SIGNATURE----- --Apple-Mail=_BE5F04E7-BFD2-46BF-959D-CFBFE42F0A30-- From nobody Mon Jun 9 11:23:15 2014 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 D322C1A02A5 for ; Mon, 9 Jun 2014 11:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 14Eixvk_P4nf for ; Mon, 9 Jun 2014 11:23:09 -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 313151A02A6 for ; Mon, 9 Jun 2014 11:23:09 -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.14.9/8.14.7) with ESMTP id s59IN31m074653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Jun 2014 13:23:05 -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] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell In-Reply-To: <5395DAAE.8090906@stpeter.im> Date: Mon, 9 Jun 2014 13:23:01 -0500 X-Mao-Original-Outgoing-Id: 424030981.694746-60ea410c3fb3d09ca114a20fdf50976e Content-Transfer-Encoding: quoted-printable Message-Id: References: <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net> <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com> <5384D9E8.5000601@stpeter.im> <6FF542E9-904E-4997-936F-D4C61087179A@nostrum.com> <53921B7C.8080403@stpeter.im> <73438225-60E0-4301-ABD8-7AE8C8C7CDEE@nostrum.com> <0F867757-72F8-4961-9B0C-476F2987652C@andyet.net> <78B53C44-9C02-4CB3-9D45-48748CA75F54@andyet.net> <5395DAAE.8090906@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/S1OdnrBA09bXy-vt0CWB6YMu3IQ Cc: XMPP Working Group Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02 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 Jun 2014 18:23:13 -0000 On Jun 9, 2014, at 11:02 AM, Peter Saint-Andre = wrote: > On 6/9/14, 9:59 AM, Lance Stout wrote: >>=20 >>> WFM >>>=20 >>> Thanks! >>>=20 >>> Ben. >>=20 >>=20 >> Then I think that all WGLC feedback has now been addressed in -07. = Next step? >=20 > For my part as the document shepherd, I have reviewed the diff between = 06 and 07, and have updated the writeup accordingly: >=20 > https://stpeter.im/files/writeup-ietf-xmpp-websocket.txt >=20 > IMHO we can proceed to WGLC. Do you mean IETF Last Call? Or do you think we need to repeat the WGLC? >=20 > Peter >=20 >=20 > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From nobody Mon Jun 9 11:43:39 2014 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 D6A5E1A02BF for ; Mon, 9 Jun 2014 11:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 32BRpEdPARma for ; Mon, 9 Jun 2014 11:43:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C7B151A02B9 for ; Mon, 9 Jun 2014 11:43:35 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4301F40C58; Mon, 9 Jun 2014 12:43:34 -0600 (MDT) Message-ID: <53960056.5080509@stpeter.im> Date: Mon, 09 Jun 2014 12:43:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ben Campbell References: <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net> <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com> <5384D9E8.5000601@stpeter.im> <6FF542E9-904E-4997-936F-D4C61087179A@nostrum.com> <53921B7C.8080403@stpeter.im> <73438225-60E0-4301-ABD8-7AE8C8C7CDEE@nostrum.com> <0F867757-72F8-4961-9B0C-476F2987652C@andyet.net> <78B53C44-9C02-4CB3-9D45-48748CA75F54@andyet.net> <5395DAAE.8090906@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/xj4z3RS66jLk3BIb_7a8thw_Gyc Cc: XMPP Working Group Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02 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 Jun 2014 18:43:38 -0000 On 6/9/14, 12:23 PM, Ben Campbell wrote: > > On Jun 9, 2014, at 11:02 AM, Peter Saint-Andre wrote: > >> On 6/9/14, 9:59 AM, Lance Stout wrote: >>> >>>> WFM >>>> >>>> Thanks! >>>> >>>> Ben. >>> >>> >>> Then I think that all WGLC feedback has now been addressed in -07. Next step? >> >> For my part as the document shepherd, I have reviewed the diff between 06 and 07, and have updated the writeup accordingly: >> >> https://stpeter.im/files/writeup-ietf-xmpp-websocket.txt >> >> IMHO we can proceed to WGLC. > > Do you mean IETF Last Call? Or do you think we need to repeat the WGLC? IETF. It's hard to keep track of which drafts are in which states. :-) From nobody Mon Jun 9 20:44:34 2014 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 5EBA11A0398 for ; Mon, 9 Jun 2014 20:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 PYVjVozQOA8o for ; Mon, 9 Jun 2014 20:44:32 -0700 (PDT) Received: from monet.mumbo.ca (monet.mumbo.ca [204.109.63.66]) by ietfa.amsl.com (Postfix) with ESMTP id D27771A0383 for ; Mon, 9 Jun 2014 20:44:31 -0700 (PDT) Received: from rembrandt.mumbo.ca (unknown [184.66.12.24]) by monet.mumbo.ca (Postfix) with ESMTPSA id 02AB245021; Mon, 9 Jun 2014 20:44:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E26DCCB0-EC3E-478B-AF2F-CC232AFE4EC7" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Curtis King In-Reply-To: Date: Mon, 9 Jun 2014 20:44:27 -0700 Message-Id: <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> To: Dave Cridland X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/tDTONLHTk8DgWp4F0xGhUBnD6YE Cc: XMPP Working Group Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 03:44:33 -0000 --Apple-Mail=_E26DCCB0-EC3E-478B-AF2F-CC232AFE4EC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 9, 2014, at 9:54 AM, Dave Cridland wrote: > On 9 June 2014 17:36, Curtis King wrote: > Instead of adding an redundant flag into the XMPP spec. Why doesn=92t = this draft state the flag explicit and give the session as = an example? Otherwise we will be adding to more features = than session. >=20 > We've discussed, and rejected, this before, for example: >=20 > http://www.ietf.org/mail-archive/web/xmpp/current/msg02403.html > http://www.ietf.org/mail-archive/web/xmpp/current/msg01125.html >=20 > I'm not averse to reopening the discussion, though I'll still argue = against it. One or other of a generic and will = always be redundant, and multiple elements will often = conflict. >=20 > In any case, you'll note that in this instance doesn't = really mean "optional" so much as "redundant" - in fact, I think the = name is an artifact of the discussion we had back then, though I can't = find the thread that proposes it in this case. (But both M-Link and = Prosody do this, so I assume it was discussed sometime). It was in the 3921bis draft then removed. BTW, we are about to remove it = from M-Link because it isn=92t covered in any RFC or XEP. This draft will require servers and client changes, you could accomplish = the same goal by a pure informational draft pointing such features are = optional. Then only certain clients need to change. Note: Good clients = like Swift already ignore the session feature. If you think it is clearer using a flag lets use a descriptive flag name = like, rfc3921-compatibility. cheers, ck --Apple-Mail=_E26DCCB0-EC3E-478B-AF2F-CC232AFE4EC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 9, 2014, at 9:54 AM, Dave = Cridland <dave@cridland.net> = wrote:

On 9 June 2014 17:36, Curtis King <cking@mumbo.ca> wrote:
Instead of adding an redundant flag into the XMPP spec. = Why doesn=92t this draft state the <optional/> flag explicit and = give the session as an example? Otherwise we will be adding = <optional/> to more features than session.

We've discussed, and rejected, = this before, for example:

h= ttp://www.ietf.org/mail-archive/web/xmpp/current/msg01125.html

I'm not averse to reopening the discussion, though = I'll still argue against it. One or other of a generic <optional/> = and <required/> will always be redundant, and multiple = <required/> elements will often conflict.

In any case, you'll note that <optional/> in = this instance doesn't really mean "optional" so much as "redundant" - in = fact, I think the name is an artifact of the discussion we had back = then, though I can't find the thread that proposes it in this case. (But = both M-Link and Prosody do this, so I assume it was discussed = sometime).

It = was in the 3921bis draft then removed. BTW, we are about to remove it = from M-Link because it isn=92t covered in any RFC or = XEP.

This draft will require servers and client = changes, you could accomplish the same goal by a pure informational = draft pointing such features are optional. Then only certain clients = need to change. Note: Good clients like Swift already ignore the session = feature.

If you think it is clearer using a = flag lets use a descriptive flag name like, = rfc3921-compatibility.

cheers,

ck

= --Apple-Mail=_E26DCCB0-EC3E-478B-AF2F-CC232AFE4EC7-- From nobody Tue Jun 10 00:20:01 2014 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 705BB1A0422 for ; Tue, 10 Jun 2014 00:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 6S5eR58D8kIh for ; Tue, 10 Jun 2014 00:19:54 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [83.98.201.61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7811A1A023C for ; Tue, 10 Jun 2014 00:19:54 -0700 (PDT) Received: from mag.ik.nu (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id BE39DA1065 for ; Tue, 10 Jun 2014 09:19:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at ik.nu Received: from mag.ik.nu ([127.0.0.1]) by mag.ik.nu (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id PYsTdvMoxPBI for ; Tue, 10 Jun 2014 09:19:51 +0200 (CEST) Received: from [192.168.3.215] (s53751670.adsl.online.nl [83.117.22.112]) by mag.ik.nu (Postfix) with ESMTPSA id D3322A1047 for ; Tue, 10 Jun 2014 09:19:50 +0200 (CEST) Message-ID: <5396B196.6060309@ik.nu> Date: Tue, 10 Jun 2014 09:19:50 +0200 From: Ralph Meijer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> In-Reply-To: <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/sVaoAbKsFoPKRXuWrcfYC7c8q24 Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 07:19:57 -0000 On 2014-06-10 05:44, Curtis King wrote: >=20 > On Jun 9, 2014, at 9:54 AM, Dave Cridland wrote: >=20 >> On 9 June 2014 17:36, Curtis King wrote: >> Instead of adding an redundant flag into the XMPP spec. Why doesn=92t = this draft state the flag explicit and give the session as an= example? Otherwise we will be adding to more features than s= ession. >> >> We've discussed, and rejected, this before, for example: >> >> http://www.ietf.org/mail-archive/web/xmpp/current/msg02403.html >> http://www.ietf.org/mail-archive/web/xmpp/current/msg01125.html >> >> I'm not averse to reopening the discussion, though I'll still argue ag= ainst it. One or other of a generic and will alwa= ys be redundant, and multiple elements will often conflict. >> >> In any case, you'll note that in this instance doesn't rea= lly mean "optional" so much as "redundant" - in fact, I think the name is= an artifact of the discussion we had back then, though I can't find the = thread that proposes it in this case. (But both M-Link and Prosody do thi= s, so I assume it was discussed sometime). >=20 > It was in the 3921bis draft then removed. BTW, we are about to remove i= t from M-Link because it isn=92t covered in any RFC or XEP. >=20 > This draft will require servers and client changes, you could accomplis= h the same goal by a pure informational draft pointing such features are = optional. Then only certain clients need to change. Note: Good clients li= ke Swift already ignore the session feature. >=20 > If you think it is clearer using a flag lets use a descriptive flag nam= e like, rfc3921-compatibility. The problem is that RFC 3921 said that you MUST negotiate Session Establishment when advertised by the server [1]. RFC 6121 then had it completely removed. While RFC 6120 says that by default stream features are optional to negotiate, this one wasn't. I think the idea is that if you do implement this flag (like Prosody and M-Link), we know for certain that the server does indeed no longer require Session Establishment. If a client *requires* changes, this is because it has a bug: negotiating session establishment while it has not been advertised. This particular flag just makes it possible for a client to decide to not negotiate Session Management as an optimization. Eventually, when enough clients no longer show the above mentioned buggy behaviour, we can remove this protocol from servers entirely. [1] http://xmpp.org/rfcs/rfc3921.html#session --=20 ralphm From nobody Tue Jun 10 00:43:53 2014 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 CF3A21A044D for ; Tue, 10 Jun 2014 00:43:42 -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 137s_RTvWmUT for ; Tue, 10 Jun 2014 00:43:41 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E571A0424 for ; Tue, 10 Jun 2014 00:43:41 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wp18so4528592obc.14 for ; Tue, 10 Jun 2014 00:43:40 -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=HvmuA9DrXD3oLUOpQvbCMxJ1GRzeiYnmwG7gvQjEhg0=; b=jIZEOmJ4bqzWxKVxW7Y8YPZFnH/h5EExeC/JfWW2c7K9gK6dBRZA9fjsTEiI/lb8Qp 6exiYJsII3EAdqbyNafaA2xFhdy/VsMKmgRCNQufF5ChCssIOYISgIPVyD9qlUO6yvIK nKlsNsNNLn3b9O1M5AmRR4YDOcPKVKf/clqhE= 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=HvmuA9DrXD3oLUOpQvbCMxJ1GRzeiYnmwG7gvQjEhg0=; b=N4kDmGLuus41lJFbG0iS8h90DiNDYxDwRSovydMfbZPwsX5bjEVJn5vHQqueuiOOlM lfMcMcIe/8T/IFZmYwSu9VhQgNjbUGlRSDUlvF4x+ccFRxN/NtwK9VgUYmBOJ1uYVk0a BoAX/ZdZ9xuvtT7Dx4xia9y3FgEgWQUw7H7h0GYuBvEl9nc+x5r2iNpMH+f+2K3PUl1s XdpE9TzRK/g0bwXZ8XPvYXCduINnal+7dzDXmEIB9Ocpw2fEBfcbMb1xDTirbxss62xT ZTshqHAioD2dkS4VGdG7qJPK/UhR4mEimZnQtcaqvXgzpnaJGWvBPnU6LbtJsCnNcnmW KDeA== X-Gm-Message-State: ALoCoQnLlryjCagznCLUVCuG3WTOA9f6HzmMAQT1whLfd7aJRGAio4Hb/8A+9gOvdoLRgThkftIT MIME-Version: 1.0 X-Received: by 10.182.125.99 with SMTP id mp3mr29631939obb.40.1402386220861; Tue, 10 Jun 2014 00:43:40 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Tue, 10 Jun 2014 00:43:40 -0700 (PDT) In-Reply-To: <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> Date: Tue, 10 Jun 2014 08:43:40 +0100 Message-ID: From: Dave Cridland To: Curtis King Content-Type: multipart/alternative; boundary=089e0122f628885f0c04fb767c62 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/KaXRb55Xz5VaGqQarGVBWlbmmPc Cc: XMPP Working Group Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 07:43:42 -0000 --089e0122f628885f0c04fb767c62 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10 June 2014 04:44, Curtis King wrote: > > On Jun 9, 2014, at 9:54 AM, Dave Cridland wrote: > > On 9 June 2014 17:36, Curtis King wrote: > >> Instead of adding an redundant flag into the XMPP spec. Why doesn=E2=80= =99t this >> draft state the flag explicit and give the session as an >> example? Otherwise we will be adding to more features than >> session. >> > > We've discussed, and rejected, this before, for example: > > http://www.ietf.org/mail-archive/web/xmpp/current/msg02403.html > http://www.ietf.org/mail-archive/web/xmpp/current/msg01125.html > > I'm not averse to reopening the discussion, though I'll still argue > against it. One or other of a generic and will > always be redundant, and multiple elements will often conflic= t. > > In any case, you'll note that in this instance doesn't really > mean "optional" so much as "redundant" - in fact, I think the name is an > artifact of the discussion we had back then, though I can't find the thre= ad > that proposes it in this case. (But both M-Link and Prosody do this, so I > assume it was discussed sometime). > > > It was in the 3921bis draft then removed. BTW, we are about to remove it > from M-Link because it isn=E2=80=99t covered in any RFC or XEP. > > Right, this is an alternative way to solve that problem. > This draft will require servers and client changes, you could accomplish > the same goal by a pure informational draft pointing such features are > optional. Then only certain clients need to change. Note: Good clients li= ke > Swift already ignore the session feature. > > Then it's not a good client - the session feature, if advertised, is mandatory. So if you remove the marker from M-Link, every conforming client has to negotiate it. You can't claim that if it's RFC 6121 only then it's exempt, because then certain servers won't work (I think ejabberd is one that actually requires the , in line with RFC 3921). In an ideal world, we'd track down every client that requires the feature to be advertised, unfortunately that means every client using Smack over a certain age, which includes almost every Android client amongst others. > If you think it is clearer using a flag lets use a descriptive flag name > like, rfc3921-compatibility. > I'm just documenting the status quo as deployed. > > cheers, > > ck > > --089e0122f628885f0c04fb767c62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 0 June 2014 04:44, Curtis King <cking@mumbo.ca> wrote:

On= Jun 9, 2014, at 9:54 AM, Dave Cridland <dave@cridland.net> wrote:

On 9= June 2014 17:36, Curtis King <cking@mumbo.ca> wrote:
Instead of adding an redundant flag into the XMPP spec. Why doesn=E2= =80=99t this draft state the <optional/> flag explicit and give the s= ession as an example? Otherwise we will be adding <optional/> to more= features than session.

We've discussed, and rejected, t= his before, for example:


I'm not averse to r= eopening the discussion, though I'll still argue against it. One or oth= er of a generic <optional/> and <required/> will always be redu= ndant, and multiple <required/> elements will often conflict.

In any case, you'll note that <optional/> in = this instance doesn't really mean "optional" so much as "= ;redundant" - in fact, I think the name is an artifact of the discussi= on we had back then, though I can't find the thread that proposes it in= this case. (But both M-Link and Prosody do this, so I assume it was discus= sed sometime).

It was in th= e 3921bis draft then removed. BTW, we are about to remove it from M-Link be= cause it isn=E2=80=99t covered in any RFC or XEP.


Right, this is an alternative way to solve= that problem.
=C2=A0
This draft will require servers and client changes, yo= u could accomplish the same goal by a pure informational draft pointing suc= h features are optional. Then only certain clients need to change. Note: Go= od clients like Swift already ignore the session feature.


Then it's n= ot a good client - the session feature, if advertised, is mandatory. So if = you remove the <optional/> marker from M-Link, every conforming clien= t has to negotiate it. You can't claim that if it's RFC 6121 only t= hen it's exempt, because then certain servers won't work (I think e= jabberd is one that actually requires the <session/>, in line with RF= C 3921).

In an ideal world, we'd track down every client tha= t requires the feature to be advertised, unfortunately that means every cli= ent using Smack over a certain age, which includes almost every Android cli= ent amongst others.
=C2=A0
If you think it is clearer using a flag lets = use a descriptive flag name like, rfc3921-compatibility.

I'm just documenting the s= tatus quo as deployed.
=C2=A0

cheers,

ck

=

--089e0122f628885f0c04fb767c62-- From nobody Tue Jun 10 00:57:05 2014 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 E5F8E1A04B8 for ; Tue, 10 Jun 2014 00:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, 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 xb5wey85fJMt for ; Tue, 10 Jun 2014 00:57:01 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848961A0325 for ; Tue, 10 Jun 2014 00:57:01 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so434186pab.1 for ; Tue, 10 Jun 2014 00:57:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=iUfw++JgGYVNb111Oy3VApECV39jxUGvR6vK5Z7j4Ps=; b=jSGaD7omrpRonV404FciK2pAQdI0Ymlim7mEKRY4cFQ0ys7/EP+V6BMlmrEWUUfaJR xzoiBZpQCwH8rIGXxIbFxu4ID92bED88yMmCNJPolH2JNdhcQIiSxR28E6gm9M4OMoP2 MA2rGNmssoR90HVO3uqPnhvfLnQm7Xv/i9HUuWz/iDjd+rX6l/Lbc3RfmP0OAoWWbZUP UOxB/6LnstqqW4yHPhKsZPJAI5MsEsLxVIX155f8nAPLYYZYKpat6Tv3JYPReLU+oBaM RO0c5bWN7/iqslodRndR7fbxd35QEvmNO4XaCtYXvdJPysXiGmj5xGnoS3nNMsPqCSfa +8ow== X-Gm-Message-State: ALoCoQnRt4NDZZtRUcyoPh4/t794zA5hbay4ylGCSFtM4Dtk0QjvNUF3q7eXAJOmHaB/HKg3rNz5 X-Received: by 10.68.254.70 with SMTP id ag6mr9981832pbd.33.1402387021144; Tue, 10 Jun 2014 00:57:01 -0700 (PDT) Received: from [10.0.1.172] (68-186-83-170.dhcp.knwc.wa.charter.com. [68.186.83.170]) by mx.google.com with ESMTPSA id no9sm67882356pbc.83.2014.06.10.00.56.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 00:57:00 -0700 (PDT) From: Lance Stout Content-Type: multipart/signed; boundary="Apple-Mail=_8C28DB0D-6A00-4555-83DE-93D6E66F74DF"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <059DEECD-D00B-4480-81DE-B66EAFDF5475@andyet.net> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Tue, 10 Jun 2014 00:56:58 -0700 References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> To: XMPP Working Group In-Reply-To: X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/wggaJi50HnPEMv3I-mOrmDnSDMk Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 07:57:03 -0000 --Apple-Mail=_8C28DB0D-6A00-4555-83DE-93D6E66F74DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 10, 2014, at 12:43 AM, Dave Cridland wrote: > I'm just documenting the status quo as deployed. Coincidentally, I added support in stanza.io for the flag = the day before this I-D showed up, based on what Prosody does. So there are both server and client implementations for this approach, = as documented. =97 Lance= --Apple-Mail=_8C28DB0D-6A00-4555-83DE-93D6E66F74DF 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 KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNjEwMDc1NjU4WjAjBgkq hkiG9w0BCQQxFgQUBH9+1FrrZwCGEtVsZl/igbmQxM0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIvpTCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkg SW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwDQYJKoZIhvcNAQEBBQAEggEAgklfVOMKmTBqW9Vw y/izIfi9bcWCIRrvDYfIHV5OZDyHiH+GF5IIlkCoVj3rKPv6J5pU86XKrMjusJkhQHLAZbixj6Qg yblwcVeIKNc3YoUbsdHx98FnnmL/VNJADYJQeG9SweOwBkxSo0M9RVY38q/9cinylwFhTF8vQYcs Iz+xu5GxpyQAWD2TdD/TgRG/hbz7l51WNs/LePLr+UymrAuAtdyRmHh84rSqh+Kx9htLIGl1mf++ bURFtZYs8q9BVbs0UHMkj8zI1FYUG52OsrvxgSUVdQxWFfAleowP8J5UjyBOPyBH6SvwjZ4jeU9v 4KiPf/V+YHo2nZhItknb6gAAAAAAAA== --Apple-Mail=_8C28DB0D-6A00-4555-83DE-93D6E66F74DF-- From nobody Tue Jun 10 01:07:10 2014 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 73B301A01EB for ; Tue, 10 Jun 2014 01:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 Bk7SaIlc1IBa for ; Tue, 10 Jun 2014 01:07:08 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E424C1A01BC for ; Tue, 10 Jun 2014 01:07:07 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so1229653wib.0 for ; Tue, 10 Jun 2014 01:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DOFZYoxVeCKWg8oDesr+RbCDVza5zYzodAmElSqFgDo=; b=D0JKQphI1uZNmzR4EZJReZqj9JVly/22IN5O+0bkQxUAFQlvn7CArg6uJjk0Qq9PBe ChXp3rg8vXcqZz7kGrZvUJlEKSRAagKSOE1xghFDcLBguQvdcp2ih9Pa5aHk1L2G7boT jZyROMeUQoXw57PXGzrmDCDaUWiDjTcjb3+JzIoqNS30Ou2nmH0lgp+bNc+E5V1KAvCe u2OyP+p6RFSgvgTYcbZWp0tZXwvlfd2baM5270KYs4LWflcbZt7K27FeVrLQiG4Q/y0u mZMg97CoQRT04wrq13B8tDKkBHC5LzZlHH9FLOHM0lJz1vEDum7QK7jb6/VhFs7mPiie Q7Iw== MIME-Version: 1.0 X-Received: by 10.181.13.106 with SMTP id ex10mr2681376wid.30.1402387625115; Tue, 10 Jun 2014 01:07:05 -0700 (PDT) Sender: k.i.smith@gmail.com Received: by 10.217.59.194 with HTTP; Tue, 10 Jun 2014 01:07:05 -0700 (PDT) In-Reply-To: References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> Date: Tue, 10 Jun 2014 09:07:05 +0100 X-Google-Sender-Auth: O47NCOC_ikxRKBSO2yqdePFf0Js Message-ID: From: Kevin Smith To: Dave Cridland Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Ow2SeLhiCbXuLjG8ZBeMjUwh3KE Cc: XMPP Working Group Subject: Re: [xmpp] draft-cridland-xmpp-session-00 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 08:07:09 -0000 On Tue, Jun 10, 2014 at 8:43 AM, Dave Cridland wrote: >> This draft will require servers and client changes, you could accomplish >> the same goal by a pure informational draft pointing such features are >> optional. Then only certain clients need to change. Note: Good clients like >> Swift already ignore the session feature. >> > > Then it's not a good client - the session feature, if advertised, is > mandatory. Yeah, I don't believe this is true. Swift treats the session start as unnecessary, but if it's offered by the server it'll negotiate it. The relevant code is splattered around http://swift.im/git/swift/tree/Swiften/Client/ClientSession.cpp > So if you remove the marker from M-Link, every > conforming client has to negotiate it. Every 3920/1 client, that is, rather than every 6120/1 client. yes? > You can't claim that if it's RFC 6121 > only then it's exempt, because then certain servers won't work (I think > ejabberd is one that actually requires the , in line with RFC > 3921). Right. Clients still need to implement this for old servers (I assume modern ejabberd /doesn't/ require this, but very old versions are undoubtedly out in the wild). I think the draft is roughly the right thing to do. Nits: od->of really isn't what this really is. Is there scope for naming it ? How widely deployed are clients-servers that use optional and are unlikely to be upgradable? I'm uncomfortable with standardising that means MUST NOT. If we have to do this, we should probably add some text that is only used in the context of session startup. /K From nobody Tue Jun 10 01:24:31 2014 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 245391A0286 for ; Tue, 10 Jun 2014 01:24:30 -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 G7vxC5oZsh2Q for ; Tue, 10 Jun 2014 01:24:29 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172A91A027E for ; Tue, 10 Jun 2014 01:24:29 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wo20so7113567obc.6 for ; Tue, 10 Jun 2014 01:24:28 -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=dc7W3MkZo8fj/a488Gb8C3W8zlVfFLMInNkzoXCcIQE=; b=OlyB63Y/5zb4oYDUUigqIQq8/FmEy4CIrSWG0u0a8fAjK+zfUK1kHm3QPvgBg7gY8h 2R0fppJBJElO0cfJuDgUiPvl1DT/XZc/MpyG8jJXx8pXJl+B735zUu7CrgAVdGpaAO0B 7bUKG0aMbeFSweyamVHOM4xWrMN+hNTMajS7w= 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=dc7W3MkZo8fj/a488Gb8C3W8zlVfFLMInNkzoXCcIQE=; b=SBgdcLO3DRsFGq5PHvKLsapDYi7wTkabdBf0gr7saayCJShRhg0v6d8V7+cwRUK3Y1 fQZEN48Zcmmf93mHV2z2k+0ZXsoBoN2wb+RmCb+euWm9dvd6jUTcKrtfoBevJaX1YtMw rSWJByNchLrKmMJ+Y9MskwIqHoSKpiZCyIIvEnAsvuKgAg6eLCQhpD5CPrbybdGC8IkQ 8gbseOVkGinEehq1tzSZvk0eGLnDa7Z6odpjk0oV1yj/lo6XAMw6TGjKWVsBMeEu4fyH m7vV9qJyF9orP13M6kHR0lnNMk8H8gD0lD0ekymiiriIFKrNrj40c38ctLNd/rTCHTop iMXg== X-Gm-Message-State: ALoCoQlatA/eU8T3cBJl4fOP46YFjLMYIHnz3e+n3X9qXusZMwndSgXHqxlgMrY3JCsEKO7ukAiH MIME-Version: 1.0 X-Received: by 10.60.146.167 with SMTP id td7mr31347211oeb.6.1402388668447; Tue, 10 Jun 2014 01:24:28 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Tue, 10 Jun 2014 01:24:28 -0700 (PDT) In-Reply-To: References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> Date: Tue, 10 Jun 2014 09:24:28 +0100 Message-ID: From: Dave Cridland To: Kevin Smith Content-Type: multipart/alternative; boundary=047d7b5d376c6b9ce804fb770eb1 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/SIo2ZnczLgIoQH2jzNLHUB8OXoo Cc: XMPP Working Group Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 08:24:30 -0000 --047d7b5d376c6b9ce804fb770eb1 Content-Type: text/plain; charset=UTF-8 On 10 June 2014 09:07, Kevin Smith wrote: > > I think the draft is roughly the right thing to do. Nits: > > od->of > > Thanks. I've also heard (from Openfire devs) that the statement explaining where should go isn't very clear, plus it could use an example of the advertisement. > really isn't what this really is. Is there scope for > naming it ? How widely deployed are clients-servers that > use optional and are unlikely to be upgradable? I'm uncomfortable with > standardising that means MUST NOT. If we have to do this, > we should probably add some text that is only used in the > context of session startup. > > I think we do have to do this - as I say, this is based on deployed running code. We get significant value by documenting the status quo over inventing something new, and while I dislike as a name, it's what we have, and we know it works. Looking back on it, though, saying means "MUST NOT" is too strong anyway; it should be "SHOULD NOT" at most, since it doesn't affect interoperability. Perhaps "MAY", with a note saying it's a waste of a round-trip? I'll try some text. Dave. --047d7b5d376c6b9ce804fb770eb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 0 June 2014 09:07, Kevin Smith <kevin@kismith.co.uk> wrote= :
I think the draft is roughly the right thing to do. Nits:

od->of


Thanks. I've also heard (from Open= fire devs) that the statement explaining where <optional/> should go = isn't very clear, plus it could use an example of the advertisement.
=C2=A0
<optional/> really isn't what this really is. Is there scope for<= br> naming it <obsolete/>? How widely deployed are clients-servers that use optional and are unlikely to be upgradable? I'm uncomfortable with<= br> standardising that <optional/> means MUST NOT. If we have to do this,=
we should probably add some text that <optional/> is only used in the=
context of session startup.


I think we do have to do this - as I say, this is ba= sed on deployed running code. We get significant value by documenting the s= tatus quo over inventing something new, and while I dislike <optional/&g= t; as a name, it's what we have, and we know it works.

Looking back on it, though, saying <optional/> me= ans "MUST NOT" is too strong anyway; it should be "SHOULD NO= T" at most, since it doesn't affect interoperability. Perhaps &quo= t;MAY", with a note saying it's a waste of a round-trip?

I'll try some text.

Dave.<= /div>
--047d7b5d376c6b9ce804fb770eb1-- From nobody Tue Jun 10 01:26:31 2014 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 386891A020B for ; Tue, 10 Jun 2014 01:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 IEwQBx5CqDid for ; Tue, 10 Jun 2014 01:26:29 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [IPv6:2001:16f8:4::61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085261A02D9 for ; Tue, 10 Jun 2014 01:26:29 -0700 (PDT) Received: from mag.ik.nu (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id CA0CFA1021 for ; Tue, 10 Jun 2014 10:26:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at ik.nu Received: from mag.ik.nu ([127.0.0.1]) by mag.ik.nu (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id WiD6p01WxrDw for ; Tue, 10 Jun 2014 10:26:26 +0200 (CEST) Received: from [192.168.3.215] (s53751670.adsl.online.nl [83.117.22.112]) by mag.ik.nu (Postfix) with ESMTPSA id F3176A100F for ; Tue, 10 Jun 2014 10:26:25 +0200 (CEST) Message-ID: <5396C131.8030508@ik.nu> Date: Tue, 10 Jun 2014 10:26:25 +0200 From: Ralph Meijer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/zFZF303NsyEKSVv-3GkCmDeapZ0 Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 08:26:31 -0000 On 2014-06-10 10:07, Kevin Smith wrote: > On Tue, Jun 10, 2014 at 8:43 AM, Dave Cridland wrote: >>> This draft will require servers and client changes, you could accomplish >>> the same goal by a pure informational draft pointing such features are >>> optional. Then only certain clients need to change. Note: Good clients like >>> Swift already ignore the session feature. >>> >> >> Then it's not a good client - the session feature, if advertised, is >> mandatory. > > Yeah, I don't believe this is true. Swift treats the session start as > unnecessary, but if it's offered by the server it'll negotiate it. The > relevant code is splattered around > http://swift.im/git/swift/tree/Swiften/Client/ClientSession.cpp Oh, but it is. RFC 3921 says, section 3 says: Upon being so informed that session establishment is required [*] (and after completing resource binding), the client MUST establish a session [..] [*] The part above that shows the stream feature being advertised, and because of that wording I believe it implies that advertising Session Establishment makes it required. Then RFC 6121 only mentions that the protocol is unnecessary (Appendix E), but doesn't explicitly make it optional when advertised. I.e. it doesn't change the protocol, just doesn't document it any more. >> So if you remove the marker from M-Link, every >> conforming client has to negotiate it. > > Every 3920/1 client, that is, rather than every 6120/1 client. yes? I think you will find there are no pure forms of either, in reality. >> You can't claim that if it's RFC 6121 >> only then it's exempt, because then certain servers won't work (I think >> ejabberd is one that actually requires the , in line with RFC >> 3921). > > Right. Clients still need to implement this for old servers (I assume > modern ejabberd /doesn't/ require this, but very old versions are > undoubtedly out in the wild). I disagree. Clients only need to implement this if they want to benefit from the removal of a roundtrip with servers advertising this flag. > I think the draft is roughly the right thing to do. Nits: > > od->of > > really isn't what this really is. Is there scope for > naming it ? How widely deployed are clients-servers that > use optional and are unlikely to be upgradable? I'm uncomfortable with > standardising that means MUST NOT. As I said before, adding this flag makes the client *choose* to not negotiate Session Establishment, therefore making it optional. I don't really care for renaming this with existing implementations (like your own) already having this deployed in the field. I don't think it does anyone a favour, except protocol purists. I do agree should mean 'SHOULD NOT negotiate'. > If we have to do this, we should probably add some text that > is only used in the context of session startup. I'm not sure what you mean here. To be sure, this flag is only being defined for this namespace / stream feature. -- ralphm From nobody Tue Jun 10 01:34:04 2014 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 B6E551A020B for ; Tue, 10 Jun 2014 01:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 bC74IFVcGR4t for ; Tue, 10 Jun 2014 01:34:01 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A18A1A01B3 for ; Tue, 10 Jun 2014 01:34:00 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w62so2646630wes.10 for ; Tue, 10 Jun 2014 01:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zEd//bZAOBz0Z7SgD2DS2DmNstyqVf1kCkw49UVjivU=; b=tmR/YSuXbrFHvsKRlfcjkgaw0bHLtILTv+ClFoHTH4ktcf67IIuDjBEscXLCxSdXZQ y4OjyZPFSckz+TX1d2U4XwkZ+1Ul7sP+SCE478izP5/XX/WMHIFKyXLE0sfGKcXC0jRJ ybgdt9Ve2Uql6osxuF4w2PbWANqe94J0848Zm4tjuqNLxNYXFiZ/ln1qe65CwRVrbHv7 YWZbDIlrpMpRBvjDSctO8U3V1LvBh5IG1PXAmidPG8SnuIid7Zo2S7YcxdXsU3hq7SfC jofo7hyiaTZw7Me0aORbAHdpVpAE4D33xa8Vn7l7hJRL58o42nKRi+TCNSG9ODJKRWSS YWJw== MIME-Version: 1.0 X-Received: by 10.194.80.7 with SMTP id n7mr39225841wjx.8.1402389238854; Tue, 10 Jun 2014 01:33:58 -0700 (PDT) Sender: k.i.smith@gmail.com Received: by 10.217.59.194 with HTTP; Tue, 10 Jun 2014 01:33:58 -0700 (PDT) In-Reply-To: <5396C131.8030508@ik.nu> References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> <5396C131.8030508@ik.nu> Date: Tue, 10 Jun 2014 09:33:58 +0100 X-Google-Sender-Auth: xTZ2RX_-ugA5xdVAh95A4dJTuck Message-ID: From: Kevin Smith To: Ralph Meijer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/SnrDo8V3y2hDcOWOsv6bNUBqpWo Cc: XMPP Working Group Subject: Re: [xmpp] draft-cridland-xmpp-session-00 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 08:34:02 -0000 On Tue, Jun 10, 2014 at 9:26 AM, Ralph Meijer wrote: > On 2014-06-10 10:07, Kevin Smith wrote: >> On Tue, Jun 10, 2014 at 8:43 AM, Dave Cridland wrote: >>>> This draft will require servers and client changes, you could accomplish >>>> the same goal by a pure informational draft pointing such features are >>>> optional. Then only certain clients need to change. Note: Good clients like >>>> Swift already ignore the session feature. >>>> >>> >>> Then it's not a good client - the session feature, if advertised, is >>> mandatory. >> >> Yeah, I don't believe this is true. Swift treats the session start as >> unnecessary, but if it's offered by the server it'll negotiate it. The >> relevant code is splattered around >> http://swift.im/git/swift/tree/Swiften/Client/ClientSession.cpp > > Oh, but it is. RFC 3921 says, section 3 says: > > Upon being so informed that session establishment is required [*] > (and after completing resource binding), the client MUST establish > a session [..] > > [*] The part above that shows the stream feature being advertised, and > because of that wording I believe it implies that advertising Session > Establishment makes it required. > > Then RFC 6121 only mentions that the protocol is unnecessary (Appendix > E), but doesn't explicitly make it optional when advertised. I.e. it > doesn't change the protocol, just doesn't document it any more. You've said it's true that Swift's a bad client, then described exactly what I said Swift does as being what a good client should do :p >>> So if you remove the marker from M-Link, every >>> conforming client has to negotiate it. >> >> Every 3920/1 client, that is, rather than every 6120/1 client. yes? > > I think you will find there are no pure forms of either, in reality. True. >>> You can't claim that if it's RFC 6121 >>> only then it's exempt, because then certain servers won't work (I think >>> ejabberd is one that actually requires the , in line with RFC >>> 3921). >> >> Right. Clients still need to implement this for old servers (I assume >> modern ejabberd /doesn't/ require this, but very old versions are >> undoubtedly out in the wild). > > I disagree. Clients only need to implement this if they want to benefit > from the removal of a roundtrip with servers advertising this flag. 'this' in this case being session establishment, not optional. > As I said before, adding this flag makes the client *choose* to not > negotiate Session Establishment, therefore making it optional. I don't > really care for renaming this with existing implementations (like your > own) already having this deployed in the field. I don't think it does > anyone a favour, except protocol purists. I do agree should > mean 'SHOULD NOT negotiate'. Well, protocol purists and potentially future implementers. I don't think it's impossible that using 2119 language in protocol to mean something very different from the 2119 meanings could cause significant confusion. But I'm not set against this, as I said earlier, I just wanted to broach the question of doing the 'right' thing before we decide to standardise the status quo. >> If we have to do this, we should probably add some text that >> is only used in the context of session startup. > > I'm not sure what you mean here. To be sure, this flag is only being > defined for this namespace / stream feature. Yes. I think this is worth being explicit about. /K From nobody Tue Jun 10 01:34:18 2014 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 5D47B1A0291 for ; Tue, 10 Jun 2014 01:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 rlnjDg5gLDep for ; Tue, 10 Jun 2014 01:34:16 -0700 (PDT) Received: from monet.mumbo.ca (monet.mumbo.ca [204.109.63.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8FE1A01B3 for ; Tue, 10 Jun 2014 01:34:16 -0700 (PDT) Received: from rembrandt.mumbo.ca (unknown [184.66.12.24]) by monet.mumbo.ca (Postfix) with ESMTPSA id 475A445021; Tue, 10 Jun 2014 01:34:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F6AD58A6-E782-406B-9509-AC829D802778" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Curtis King In-Reply-To: Date: Tue, 10 Jun 2014 01:34:11 -0700 Message-Id: References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> To: Dave Cridland X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/1BhKX3tcRMhEeKGk-rndZgxWFI8 Cc: XMPP Working Group Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 08:34:17 -0000 --Apple-Mail=_F6AD58A6-E782-406B-9509-AC829D802778 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 10, 2014, at 12:43 AM, Dave Cridland wrote: > I'm just documenting the status quo as deployed. >=20 Avoiding round trips is a good thing, since the flag was not = made explicit. I=92m fine with draft. ck= --Apple-Mail=_F6AD58A6-E782-406B-9509-AC829D802778 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 10, 2014, at 12:43 AM, Dave = Cridland <dave@cridland.net> = wrote:

I'm = just documenting the status quo as deployed.


Avoiding = round trips is a good thing, since the <optional/> flag was not = made explicit. I=92m fine with = draft.

ck
= --Apple-Mail=_F6AD58A6-E782-406B-9509-AC829D802778-- From nobody Tue Jun 10 01:35:03 2014 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 B9E2C1A01B3 for ; Tue, 10 Jun 2014 01:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 yFu4w2RoP0af for ; Tue, 10 Jun 2014 01:35:00 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [IPv6:2001:16f8:4::61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4EE1A0011 for ; Tue, 10 Jun 2014 01:35:00 -0700 (PDT) Received: from mag.ik.nu (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id 10227A1068 for ; Tue, 10 Jun 2014 10:34:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at ik.nu Received: from mag.ik.nu ([127.0.0.1]) by mag.ik.nu (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id UXEkJa-tjnz5 for ; Tue, 10 Jun 2014 10:34:48 +0200 (CEST) Received: from [192.168.3.215] (s53751670.adsl.online.nl [83.117.22.112]) by mag.ik.nu (Postfix) with ESMTPSA id BDC25A1067 for ; Tue, 10 Jun 2014 10:34:48 +0200 (CEST) Message-ID: <5396C328.3080100@ik.nu> Date: Tue, 10 Jun 2014 10:34:48 +0200 From: Ralph Meijer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> In-Reply-To: <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/CskLUSStII_KzkaYhhIsQVYsOFw Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 08:35:01 -0000 On 2014-06-10 05:44, Curtis King wrote: >=20 > On Jun 9, 2014, at 9:54 AM, Dave Cridland wrote: >=20 >> On 9 June 2014 17:36, Curtis King wrote: >> Instead of adding an redundant flag into the XMPP spec. Why doesn=92t = this draft state the flag explicit and give the session as an= example? Otherwise we will be adding to more features than s= ession. >> >> We've discussed, and rejected, this before, for example: >> >> http://www.ietf.org/mail-archive/web/xmpp/current/msg02403.html >> http://www.ietf.org/mail-archive/web/xmpp/current/msg01125.html >> >> I'm not averse to reopening the discussion, though I'll still argue ag= ainst it. One or other of a generic and will alwa= ys be redundant, and multiple elements will often conflict. >> >> In any case, you'll note that in this instance doesn't rea= lly mean "optional" so much as "redundant" - in fact, I think the name is= an artifact of the discussion we had back then, though I can't find the = thread that proposes it in this case. (But both M-Link and Prosody do thi= s, so I assume it was discussed sometime). >=20 > It was in the 3921bis draft then removed. BTW, we are about to remove i= t from M-Link because it isn=92t covered in any RFC or XEP. Alas, elements are (or are not) defined per stream feature, in whatever document specifies them, not in any generic way. You are correct that we shot down that idea in the threads linked above. This Draft proposes a flag to make optional negotiation explicit, while RFC 3921 (the only document specifying the protocol) make it required by default. Also, see my other messages. As for the flag not being in any RFC or XEP, isn't that what this draft is exactly about? It is not like there is any hurry in removing it from your code base right now. Chairs, I want to request this Draft to become a Workgroup item. --=20 ralphm From nobody Tue Jun 10 01:44:04 2014 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 D91A21A0291 for ; Tue, 10 Jun 2014 01:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 kKuVdjqSHQ3Y for ; Tue, 10 Jun 2014 01:44:02 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [IPv6:2001:16f8:4::61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17631A01B3 for ; Tue, 10 Jun 2014 01:44:02 -0700 (PDT) Received: from mag.ik.nu (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id 87401A1021 for ; Tue, 10 Jun 2014 10:44:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at ik.nu Received: from mag.ik.nu ([127.0.0.1]) by mag.ik.nu (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id ZH5saoeRXJJw for ; Tue, 10 Jun 2014 10:44:00 +0200 (CEST) Received: from [192.168.3.215] (s53751670.adsl.online.nl [83.117.22.112]) by mag.ik.nu (Postfix) with ESMTPSA id C2F24A100F for ; Tue, 10 Jun 2014 10:44:00 +0200 (CEST) Message-ID: <5396C550.8060909@ik.nu> Date: Tue, 10 Jun 2014 10:44:00 +0200 From: Ralph Meijer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> <5396C131.8030508@ik.nu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/TyOT0PglcpSMOxTtRNmEWUlxn6o Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 08:44:04 -0000 On 2014-06-10 10:33, Kevin Smith wrote: > On Tue, Jun 10, 2014 at 9:26 AM, Ralph Meijer wrote: > [..] >> I disagree. Clients only need to implement this if they want to benefit >> from the removal of a roundtrip with servers advertising this flag. > > 'this' in this case being session establishment, not optional. Well, yeah: 1) (New) clients need to implement negotiating Session Establishment to interact with servers that advertise Session Establishment, but only if advertized. 2) Clients may have to negotiate Session Establishment to work around broken servers that don't advertise, but do require it to be negotiated. I hope this is never the case, though. If there are such implementations in the wild, I hope to have them fixed *and* implement this draft. 3) Clients already supporting Session Establishment, SHOULD (per the upcoming version of this draft) skip negotiating Session Establishment. > [..] >> I'm not sure what you mean here. To be sure, this flag is only being >> defined for this namespace / stream feature. > > Yes. I think this is worth being explicit about. Agreed. -- ralphm From nobody Tue Jun 10 01:48:47 2014 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 00FCE1A020B for ; Tue, 10 Jun 2014 01:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 WHirOhdNIIrK for ; Tue, 10 Jun 2014 01:48:45 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0386B1A01EB for ; Tue, 10 Jun 2014 01:48:44 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id b13so2200532wgh.26 for ; Tue, 10 Jun 2014 01:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=h73yNvc2LkJZrSh+KQ1q/p6snaBdWwLNKwfPqmpNKz0=; b=QkCqSwhqAZlGatRCuNxJyhdAmaJoFUSUeD/5CK5FgOlafdJPqJL1cYNQWTocVC9BQR W8B58SKa9bOqSU4M2dgXVwyB4NGLCyQFQeboen5YSQUzLYvdAcRwIQIQSpQTSRJkiur6 wfSl3suI38RRaMMx+Wi4FDA2LoQ7buYM9aP4wTcg4irEiLo+G9qKcPHwkffnOsSBCRdz wQscTIE9356tM1fiORuE10vMpQ0hnXOs5O9rcKFPJCua+0ca8CRZE2szqW5pFviQmzz4 IDEL2bPBFy5wcwQVcU6MaHeUALS9VHDR6gCj1qCi7gMInQSABTedeM7CsjRfnCpqobIb V9nw== MIME-Version: 1.0 X-Received: by 10.180.74.6 with SMTP id p6mr3388272wiv.17.1402390123462; Tue, 10 Jun 2014 01:48:43 -0700 (PDT) Sender: k.i.smith@gmail.com Received: by 10.217.59.194 with HTTP; Tue, 10 Jun 2014 01:48:43 -0700 (PDT) In-Reply-To: <5396C550.8060909@ik.nu> References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> <5396C131.8030508@ik.nu> <5396C550.8060909@ik.nu> Date: Tue, 10 Jun 2014 09:48:43 +0100 X-Google-Sender-Auth: AaalMNl12u1USbVXldsFPRCYI8U Message-ID: From: Kevin Smith To: Ralph Meijer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/ayTJnAoF2qbkWCtplyrUJIu7bnY Cc: XMPP Working Group Subject: Re: [xmpp] draft-cridland-xmpp-session-00 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 08:48:46 -0000 On Tue, Jun 10, 2014 at 9:44 AM, Ralph Meijer wrote: > On 2014-06-10 10:33, Kevin Smith wrote: >> On Tue, Jun 10, 2014 at 9:26 AM, Ralph Meijer wrote: >> [..] >>> I disagree. Clients only need to implement this if they want to benefit >>> from the removal of a roundtrip with servers advertising this flag. >> >> 'this' in this case being session establishment, not optional. > > Well, yeah: > > 1) (New) clients need to implement negotiating Session Establishment to > interact with servers that advertise Session Establishment, but only if > advertized. Yes (and, post this Draft, only if not optional). > 2) Clients may have to negotiate Session Establishment to work around > broken servers that don't advertise, but do require it to be negotiated. > I hope this is never the case, though. If there are such implementations > in the wild, I hope to have them fixed *and* implement this draft. Swift negotiates iff it is advertised. I'm not aware of any such broken servers. > 3) Clients already supporting Session Establishment, SHOULD (per the > upcoming version of this draft) skip negotiating Session Establishment. ...when advertised as optional. /K From nobody Tue Jun 10 01:58:22 2014 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 CA6F31A01EB for ; Tue, 10 Jun 2014 01:58:21 -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 LkWSg-8KfC9O for ; Tue, 10 Jun 2014 01:58:20 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6AEF1A0166 for ; Tue, 10 Jun 2014 01:58:20 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id wm4so7285339obc.12 for ; Tue, 10 Jun 2014 01:58:20 -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=FY04WXZ7VwuVDm6U4PlMDwLgVUlfza7zGVBGmlIycB8=; b=eFbb81Ds7uKFM1x2mbvKDw1R68WDll2Dch7mxLPdoNFhH3y1SI3Q633kitNTiUe6Sw hBxlNsJLdqI1aj3kkALKLQe2dBrglaQMA5kj0SQNK4DXMFWYblSWwfolVm6CdMWRhPj2 pxxY+JrY915Yvh5w/mJplSINcRcQwWjHDk9Ok= 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=FY04WXZ7VwuVDm6U4PlMDwLgVUlfza7zGVBGmlIycB8=; b=cJi5QeRJUpPu0DxqtOMIOg2xQkrR5VPKeejjA2J2R6GWIgYG7c0mro1JkNkDMsErdX MjKLFmVp/fwjxRe6GwacxCn3xHlvFDL7HOjrIGYdfnNClphffvM+RyCwcUswNdGYXkhT V1LXtbDm9RuhqjfBLSanDZEa0QGmqHfoHxjLm1d5zArHnQAxxQwp5fkj2WKi6JTPuKlh sIxMOTCbVzgawb1E1gmv4tdKKBfjfUtlNKJMwNHYeBHoyAmTUFs/hKYTBYHn2E9QzTBy TVlTacip+VqxyXItzlGzvmT1o+ZmqCRtEJnrAW+jUGVILwTW/D8BHJtsuwTdsb94+NqY viVg== X-Gm-Message-State: ALoCoQmDSYvEHSVhWIzc2X3Wjit8eKfnxGq0PLsAYLD6DyrYptLBMUZstHtmPk9jcxHJ/Bbnalxo MIME-Version: 1.0 X-Received: by 10.60.146.167 with SMTP id td7mr31500863oeb.6.1402390700112; Tue, 10 Jun 2014 01:58:20 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Tue, 10 Jun 2014 01:58:20 -0700 (PDT) In-Reply-To: References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> <5396C131.8030508@ik.nu> <5396C550.8060909@ik.nu> Date: Tue, 10 Jun 2014 09:58:20 +0100 Message-ID: From: Dave Cridland To: Kevin Smith Content-Type: multipart/alternative; boundary=047d7b5d376c844a4404fb7787f6 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/0gho7qcUpOtvhTwfg5OzI26zbN0 Cc: XMPP Working Group , Ralph Meijer Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 08:58:21 -0000 --047d7b5d376c844a4404fb7787f6 Content-Type: text/plain; charset=UTF-8 On 10 June 2014 09:48, Kevin Smith wrote: > On Tue, Jun 10, 2014 at 9:44 AM, Ralph Meijer wrote:> 3) > Clients already supporting Session Establishment, SHOULD (per the > > upcoming version of this draft) skip negotiating Session Establishment. > > ...when advertised as optional. > The odd thing about this draft is that is mandatory. An artifact of how one writes these things... Right, I've gone for: OLD: Clients SHALL ignore such advertisements. NEW: Clients MAY ignore such advertisements, and are encouraged to do so. So in RFC 2119 terms, it's truly optional, but for reasons other than interoperability we're encouraging people to avoid the request. Also, later on, I've added: NEW: It is important to note that there is no value in performing this request, and New clients are expected to elide the request when the marker is present. https://github.com/surevine/openstd/commits/master/draft-cridland-xmpp-session-01.xml (unsubmitted). Dave. --047d7b5d376c844a4404fb7787f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 0 June 2014 09:48, Kevin Smith <kevin@kismith.co.uk> wrote= :
On Tue, Jun 10, 2014 at 9:44 AM, Ralph Meijer <ralphm@ik.nu> wrote:> =C2=A03) Clients a= lready supporting Session Establishment, SHOULD (per the
> upcoming version of this draft) skip negotiating Session Establishment= .

...when advertised as optional.

T= he odd thing about this draft is that <optional/> is mandatory. An ar= tifact of how one writes these things...

Right, I&= #39;ve gone for:=C2=A0

OLD:=C2=A0Clients SHALL ignore such advertisements.
NEW:=C2=A0Clients MAY ignore such advertisements, and are encouraged= to do so.

So in RFC 2119 terms, it's truly op= tional, but for reasons other than interoperability we're encouraging p= eople to avoid the request.

Also, later on, I've added:

NEW: It is important to note that there is no value in performing th= is request, and New clients are expected to elide the request when the <= optional/> marker is present.


Dave.
--047d7b5d376c844a4404fb7787f6-- From nobody Tue Jun 10 01:59:46 2014 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 2F0F11A0301 for ; Tue, 10 Jun 2014 01:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 55_KmRCNC2Kd for ; Tue, 10 Jun 2014 01:59:45 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281B31A044D for ; Tue, 10 Jun 2014 01:59:45 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so5667527wiw.10 for ; Tue, 10 Jun 2014 01:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=F4vgH/4p7xKJTj+38iht1ZgOZ7DkVA/qrOFnz+NXToY=; b=eoO1R99xq3ga3l5BLlBAzZhahAc0swLVqTT59x3HO/Z1CjAcCisH24JHjUUImeC+YU 0/L4BBODuAGvaJg8cPUm/VAOu17gIk8pFsABcQrT+GiqtQIpDOi3Lu6OKZLemMPcfsXB XFjRnzfn9Kq/QSy1nPmznmZHIt0qKocrvu3dYMCRXJAz9eVmigjLDjuGv6xvTlmcFJmw qAM8khEzT/w0eJ+CRYnB5eOvPg4baATpOeP8yDeA2T/WTgkOlJi7WJp6S9bD76s5WSyM UFWtNE9Kqrcx77sYpRl30u/yeLc23KXQnRkXTsT/b7tM1gKk/OIn/8g4BmFy6xq+Zstx mkAg== MIME-Version: 1.0 X-Received: by 10.194.142.205 with SMTP id ry13mr38900100wjb.69.1402390783507; Tue, 10 Jun 2014 01:59:43 -0700 (PDT) Sender: k.i.smith@gmail.com Received: by 10.217.59.194 with HTTP; Tue, 10 Jun 2014 01:59:43 -0700 (PDT) In-Reply-To: References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> <5396C131.8030508@ik.nu> <5396C550.8060909@ik.nu> Date: Tue, 10 Jun 2014 09:59:43 +0100 X-Google-Sender-Auth: dfnk_G8TlHTUEPnIJC614UIcZOs Message-ID: From: Kevin Smith To: Dave Cridland Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/iom_2HPEfSBz-lDgJ8H2VmOU7vM Cc: XMPP Working Group , Ralph Meijer Subject: Re: [xmpp] draft-cridland-xmpp-session-00 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 08:59:46 -0000 On Tue, Jun 10, 2014 at 9:58 AM, Dave Cridland wrote: > On 10 June 2014 09:48, Kevin Smith wrote: >> >> On Tue, Jun 10, 2014 at 9:44 AM, Ralph Meijer wrote:> 3) >> Clients already supporting Session Establishment, SHOULD (per the >> >> > upcoming version of this draft) skip negotiating Session Establishment. >> >> ...when advertised as optional. > > > The odd thing about this draft is that is mandatory. An artifact > of how one writes these things... > > Right, I've gone for: > > OLD: Clients SHALL ignore such advertisements. > NEW: Clients MAY ignore such advertisements, and are encouraged to do so. > > So in RFC 2119 terms, it's truly optional, but for reasons other than > interoperability we're encouraging people to avoid the request. > > Also, later on, I've added: > > NEW: It is important to note that there is no value in performing this > request, and New clients are expected to elide the request when the > marker is present. Sounds great, thanks. An example of the stream feature, and a note saying 'this is only defined in this namespace for this stream feature' and I'll be happy. /K From nobody Tue Jun 10 02:01:19 2014 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 071481A02FE for ; Tue, 10 Jun 2014 02:01:19 -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 t-wjkRT8ev-o for ; Tue, 10 Jun 2014 02:01:14 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55DCC1A02BA for ; Tue, 10 Jun 2014 02:01:14 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id l6so1315874oag.26 for ; Tue, 10 Jun 2014 02:01:13 -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=+MS6xCQJtDIBi9Lw78oyYN1zA/vJXJKbnfI6sytJorM=; b=Ikd3CFMG1TrgGfQMB7bbsGVgLkVbf35mjkHKWuNNY20F46crHBC5CTy5Arbq2lV4Do IZB2mwkNekYiH+tBS+lg0mLhbEP0POYgrkQAKklkUIs7hF2L5F06eAOvNmhnVrpRqbcE y+HCVz4F/qLyJ8RqZpDtoY9O+7mEj905mhmwg= 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=+MS6xCQJtDIBi9Lw78oyYN1zA/vJXJKbnfI6sytJorM=; b=koWaF1jwQ/YrJfx55Xx5m0rAH7kWpZZll2XFUOtlhrqIw5wbISGkSPhVwrW1ih4ZUl nfM55WRnjpdL46K3eWN004lHIPqAqorqTsip44f2CfRlNJ0ibesZbbF6PzEjaZ5S695P S2PUixldN5QIy0R/It8DGlW613b+ioXhDeS7EayTtS5Vqwt1jVqpBbxG9fKilN5XYE/s aJGsAjjvSlEbS1v1puEoFuy89BR7TpV8W6UzoX6nwu7DyJqbbnJ6+OfhyY7vOcNcxxGx OlN1IoPIvtXpa9ms0o/RTN3r45U8++zlHVR35+DS0BWeF/ksUgr7sLxz1iQf+oCubBWG 4EXw== X-Gm-Message-State: ALoCoQnkdeskLCfKBbjnxdaRqOlkGVyq8pv+vvwPGJ5ZMMhCa6xqqTcPI5Z/kCNv8HIR24jSa7lI MIME-Version: 1.0 X-Received: by 10.60.146.167 with SMTP id td7mr31514966oeb.6.1402390873794; Tue, 10 Jun 2014 02:01:13 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Tue, 10 Jun 2014 02:01:13 -0700 (PDT) In-Reply-To: References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> <5396C131.8030508@ik.nu> <5396C550.8060909@ik.nu> Date: Tue, 10 Jun 2014 10:01:13 +0100 Message-ID: From: Dave Cridland To: Kevin Smith Content-Type: multipart/alternative; boundary=047d7b5d376cde6f0604fb77914b Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/rbfOehAVWmtoIOjgrWw_E9bHvao Cc: XMPP Working Group , Ralph Meijer Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 09:01:19 -0000 --047d7b5d376cde6f0604fb77914b Content-Type: text/plain; charset=UTF-8 On 10 June 2014 09:59, Kevin Smith wrote: > Sounds great, thanks. An example of the stream feature, and a note > saying 'this is only defined in this namespace for this stream > feature' and I'll be happy. > I have the former, I'll do the latter now. Dave. --047d7b5d376cde6f0604fb77914b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 0 June 2014 09:59, Kevin Smith <kevin@kismith.co.uk> wrote= :
Sounds great, thanks. An example of the stream feature, and= a note
saying 'this is only defined in this namespace for this stream
feature' and I'll be happy.

I h= ave the former, I'll do the latter now.

Dave.= =C2=A0
--047d7b5d376cde6f0604fb77914b-- From nobody Tue Jun 10 02:11:54 2014 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 48CA61A0367 for ; Tue, 10 Jun 2014 02:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.922 X-Spam-Level: X-Spam-Status: No, score=0.922 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, MANGLED_TOOL=2.3, 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 u7tyWv9DzwgD for ; Tue, 10 Jun 2014 02:11:46 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46291A0354 for ; Tue, 10 Jun 2014 02:11:45 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id uy5so289603obc.22 for ; Tue, 10 Jun 2014 02:11:45 -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=YZyyGnBivfu8m942he+zQkXZbTAkNg6esUQrHhQ1fBM=; b=DqB6Q6uHAFFRrLVgNE8TCMG+xMS+Bu2BuDkZfWNOurAA8g1AoBvLqbzOswLy/+ua2f Ob5sacQQBM93VmpX0Pf5A7EsHmD++uA63uc09W4BTSqXMGOMZErxFWlaCJZjdfLhfJM4 S5fJ9vs1G/ZAD9vVJ1q8POtYyuYYeHcN70978= 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=YZyyGnBivfu8m942he+zQkXZbTAkNg6esUQrHhQ1fBM=; b=jT3Dc205HEiggckMqRh9jWEwmIdBM5nRsNRh+ODlxRdtmAD5O77tgGmbjob+l8OPW+ +FTQLJLWGYdgoALrjTLWaa/USGUjRAkjA6umdejPqWDxJLZv9/L/NVtSUF1VrckPz+ye hSJFuXGi6ww2qIgwTDhX5tsTyohkDDr7ufsbaiKPKU0yTQ2k6sz9U8R91J+lP89qaDI3 IOP4F0S4zn/SBU3tj1aHQkAr54rDFsd61o3ZMzoGgO8lyL/Kpee1rjKaxdcWsmLW76Os 7gMvomkNh4a0XlOROWtz9f+l1DwrTWIi0tGn8KigBu8WEK4EsgkHs7UofuuUuL21tpn2 ONhg== X-Gm-Message-State: ALoCoQn2pmEBToNTcXcQvPZ8sULTTyG1AfAdROkEp/UK5xapf9UEGwAiAEZgmJKAzHsq5sVbaAIF MIME-Version: 1.0 X-Received: by 10.60.146.167 with SMTP id td7mr31568426oeb.6.1402391505330; Tue, 10 Jun 2014 02:11:45 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Tue, 10 Jun 2014 02:11:45 -0700 (PDT) In-Reply-To: References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> <5396C131.8030508@ik.nu> <5396C550.8060909@ik.nu> Date: Tue, 10 Jun 2014 10:11:45 +0100 Message-ID: From: Dave Cridland To: Kevin Smith Content-Type: multipart/alternative; boundary=047d7b5d376c82eed204fb77b716 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/PcXlGCQ53PqEYbwz9UYG2jctAn0 Cc: XMPP Working Group , Ralph Meijer Subject: Re: [xmpp] draft-cridland-xmpp-session-00 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 Jun 2014 09:11:53 -0000 --047d7b5d376c82eed204fb77b716 Content-Type: text/plain; charset=UTF-8 Updated to -01: datatracker.ietf.org/doc/draft-cridland-xmpp-session/ Thanks for all the comments. On 10 June 2014 10:01, Dave Cridland wrote: > On 10 June 2014 09:59, Kevin Smith wrote: > >> Sounds great, thanks. An example of the stream feature, and a note >> saying 'this is only defined in this namespace for this stream >> feature' and I'll be happy. >> > > I have the former, I'll do the latter now. > > Dave. > --047d7b5d376c82eed204fb77b716 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Updated to -01:=C2=A0datatracker.ietf.org/doc/draft-cridland= -xmpp-session/

Thanks for all the comments.


On 10 June 2014 10:01, Dave Cridland <d= ave@cridland.net> wrote:
On 10 June 2014 09:59, Kevin Smith <kevin@kismith.co.uk&= gt; wrote:
Sounds great, thanks. An example of the stream feature, and a note
=
saying 'this is only defined in this namespace for this stream
feature' and I'll be happy.

I have the former, I'll do the latter now.

Dave.=C2=A0

--047d7b5d376c82eed204fb77b716-- From nobody Tue Jun 10 02:21:59 2014 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 0047D1A04CA for ; Tue, 10 Jun 2014 02:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MANGLED_TOOL=2.3, 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 0huBShaT3R1I for ; Tue, 10 Jun 2014 02:21:57 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261431A04E7 for ; Tue, 10 Jun 2014 02:21:56 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so2655384wiw.5 for ; Tue, 10 Jun 2014 02:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=25XL8NrQ3XUJMhavSxHlvmm/BHzhzy3kLOOFItLBWv8=; b=eqK4VmvAmGhsFmjZWk2DHHAyw6/nA6Tz2bcrKbm0/aXwg1CMUf3LCEL4vHobCEh7VF AVX1BPMBEkzBTPE9/Tj5cYmnsR3beaWZSuv/3xM6o13xlshXQi9fssVv2Nj1ciWvRseY P+RoUebkvnz7eYRDNBCoMowiq3eLMC0GSLNgekn+jVLJue4mDsoUUSR5BZTHZdpP80vC w5eBTVpvHMnqlShoneOZnxQXXQZbpG+4U7BMXyCRJ9tookzQ/4MC2BqSA466yg8Yr2y2 U0Zt14cjXAyMTMibch4J09xrLa+g6lEHK7/wlnqbCNUeHd1R43ayA88LjnwCfrtObiLV iKDA== MIME-Version: 1.0 X-Received: by 10.180.90.242 with SMTP id bz18mr36669900wib.12.1402392114972; Tue, 10 Jun 2014 02:21:54 -0700 (PDT) Sender: k.i.smith@gmail.com Received: by 10.217.59.194 with HTTP; Tue, 10 Jun 2014 02:21:54 -0700 (PDT) In-Reply-To: References: <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca> <5396C131.8030508@ik.nu> <5396C550.8060909@ik.nu> Date: Tue, 10 Jun 2014 10:21:54 +0100 X-Google-Sender-Auth: cjdKmWXExqa23urlJ32ePk2lVNo Message-ID: From: Kevin Smith To: Dave Cridland Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/uui7MJ0JCpiutsO9d-JnzhTGa58 Cc: XMPP Working Group , Ralph Meijer Subject: Re: [xmpp] draft-cridland-xmpp-session-00 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 09:21:58 -0000 On Tue, Jun 10, 2014 at 10:11 AM, Dave Cridland wrote: > Updated to -01: datatracker.ietf.org/doc/draft-cridland-xmpp-session/ Apart from the one typo of > for <, this looks good. Thanks. /K From nobody Tue Jun 10 10:24:43 2014 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 C7C1D1A00E9 for ; Tue, 10 Jun 2014 10:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 GUpOQW1QTEwU for ; Tue, 10 Jun 2014 10:24:20 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC341A00D4 for ; Tue, 10 Jun 2014 10:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4788; q=dns/txt; s=iport; t=1402421059; x=1403630659; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=EBLWI309kxn2x2mfFuYc2BVshVAL8b9xY4REMEz28ik=; b=kCamIHW8OCjOnfRO4lCegWiuHpl3sUOnXBcx88YKRNtxEVi7TRIrpFS0 n5ZOR8RFucp3Na2e9YGdin24BNdpWtWTPphGaeE8/LniaX2wROJbzuzqn diJF9rchRMHGo1bhCtDFAJDAJtC+F6L9BiPpXatfelqIgPUtOp8HW1gJ2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgALABM+l1OtJA2E/2dsb2JhbABZgw1SWappAQEGmRIBgQgWdYQDAQEBBG4KEQsYCRYPCQMCAQIBRQYNBgIBAYg+zFAXhVaIQDqEQQEDiXk6j3GBQpIDg1uBUCQc X-IronPort-AV: E=Sophos;i="4.98,1010,1392163200"; d="scan'208";a="51906082" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 10 Jun 2014 17:24:18 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5AHOIGs010861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2014 17:24:18 GMT Received: from MAMILLE2-M-T03K.CISCO.COM (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Jun 2014 12:24:18 -0500 Message-ID: <53973F43.5040901@cisco.com> Date: Tue, 10 Jun 2014 11:24:19 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: XMPP Group References: <538F9B0D.1030504@cisco.com> <538FA1BD.1070508@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/6qlADRlsfUffooSzRTLtpG4Uy9Y Subject: Re: [xmpp] [POSH] What's the point of using JWKs in POSH? 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 Jun 2014 17:24:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 6/9/14, 11:34 AM, Thijs Alkemade wrote: > [Resending this message from the right address. Sorry for the > duplicate copy, Matt.] > > On 5 jun. 2014, at 00:46, Matt Miller wrote: > >> Signed PGP part On 6/4/14, 4:17 PM, Matt Miller wrote: >>> [ Forwarding to the xmpp@ietf.org mailing list on behalf of >>> Thjis Alkemade ] >>> >>> Hello, >>> >>> Today, I've spent some time on trying to implement >>> POSH-checking for xmpp.net. My implementation aimed to do two >>> things: doing the validation as described and showing someone >>> how they could set up their .well-known file by converting >>> their X509 certificates to JSON Web Keys. >>> >>> The latter part was a lot more work than the former and made >>> me wonder why it is defined the way it is. >>> >>> From draft-ietf-xmpp-posh: >>> >>> Each included JWK object MUST possess the following >>> information: >>> >>> o The "kty" field set to the appropriate key type used for >>> TLS connections (e.g., "RSA" for a certificate using an RSA >>> key). >>> >>> o The required public parameters for the key type (e.g., "n" >>> and "e" for a certificate using an RSA key). >>> >>> o The "x5t" field set to the certificate thumbprint, as >>> described in section 3.6 of [JOSE-JWK]. >>> >>> Yet the data that is required in the first and second bullet >>> is never used. It doesn't specify if and how clients should >>> verify it. Verification only uses the x5t field and optionally >>> x5c. >>> >>> There are good arguments for "pinning" just the public key. >>> draft-ietf-websec-key-pinning only uses the SPKI field, DANE >>> can use either the full cert or its SPKI field (and optionally >>> hashed). But the way it is specified here won't allow that: the >>> x5t field always needs to be present and clients should verify >>> it. >>> >>> So the public parameters of the key are useless here, but they >>> make a key >10x as large is they have to be. Generating them is >>> also not as easy: most certificate viewers show a SHA1 >>> fingerprint and it's really easy to do with the openssl cli >>> tool, but extracting n and e and base64-encoding them is a lot >>> more work. I wouldn't even know what to do for ECDSA keys. >>> >>> Are there any interoperability reasons for using JWKs that I'm >>> not aware of? Couldn't it just use a list of SHA1 hashes? >>> >>> Best regards, Thijs >> >> As I stated in the previous venue (posh@ietf.org), us authors >> were originally working to support various other use-cases, such >> as browserid. However, no one is arguing to actually support >> those other use-cases, so the desire to use JWKs is much less. >> >> My co-author and I discussed this today, and think what would be >> best is to switch from using a JWK-set to (roughly) your >> suggestion of a list of hashes. It would allow us to stay with a >> single syntax for both the "by-reference" and "by-value" >> documents, as well as provide a simple point of extension (if >> that is ever necessary). >> >> An example: >> >> { "fingerprints": [ { "sha-1": "ij39Ctarv+LwSw45qoqaZl7venM=", >> "sha-256": "WhEr4Lpv2L5pv769aRj9rrm4G6MNNCfQlre23Gol/eA=" }, { >> "sha-1": "JWow1EHNSbNyRfhQchi22bjurr0=", "sha-256": >> "K52a2gXfrjchMLYwv16QyOtv5bkKRE6rnR30hY3JM8k=" } ], "expires": >> 604800 } >> >> Each "fingerprint" is a JSON object, where the key is the hash >> algorithm and the value is the base64 encoding of hashing the >> DER-encoded certificate with the given algorithm. I do think >> that algorithm agility is necessary, which means something more >> than a simple array in my opinion. Generating this should be >> very simple; I could kludge this together on the command-line >> pretty quickly >> >> If the WG is ok with this, we can get a new revision of >> draft-ietf-xmpp-posh out relatively soon (by next week). >> > > This looks good to me! > > Thijs > > We'll get a new revision with this change out by next week. - -- - - 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTlz9DAAoJEDWi+S0W7cO148wIALZH+7Zjo4V7kZ/uN+KT1Xc7 PbD4fOm1PAPJQYH1gigU2yBBloAt3MeN0H0Ka/5AGUF2IRSb/+2pyoJVGYaw5xGM Qe3astvIF8jhqZuAbTVDDv0vHv9tTkARyat7hd6W2FLmWzKJumUZjW85xV/uCVdN wqsyEBOdczbP/gN8eKTksscNmvXGQKBUffkaGlNNLJ/19BEg1PIbpaEniUPgnCP3 9+x6/alzleTZOdNeqhlD3m4lU4GlTfchPfkcxghAaRJ0c/Yc+ZutNW0JkN5B3+4c 9VPLcpDhWNSkXQ770XnpgU8I/JICi2ZMYVof+VBIXkfKxV/orSBoklsxiZ6C2B8= =7vkZ -----END PGP SIGNATURE----- From nobody Mon Jun 16 10:43:56 2014 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 4D31D1A000F for ; Mon, 16 Jun 2014 10:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 9SvalEJzQunD for ; Mon, 16 Jun 2014 10:43:47 -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 00FBE1A00DF for ; Mon, 16 Jun 2014 10:43:43 -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.14.9/8.14.7) with ESMTP id s5GHhfbb089252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 16 Jun 2014 12:43:43 -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] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Campbell Date: Mon, 16 Jun 2014 12:43:41 -0500 X-Mao-Original-Outgoing-Id: 424633421.186739-b8c333ce5871325fa722a27e328d3b4d Content-Transfer-Encoding: quoted-printable Message-Id: References: <18924.1402682912@sandelman.ca> To: XMPP Working Group X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/NxTnwMwCFY0zh6liiqsIJff0Mlk Subject: [xmpp] Fwd: third call: NomCom 2014-2015 Call for Volunteers 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, 16 Jun 2014 17:43:50 -0000 Hi All, Please help out the nomcom! Thanks! Ben. Begin forwarded message: > From: Michael Richardson > Subject: third call: NomCom 2014-2015 Call for Volunteers > Date: June 13, 2014 at 1:08:32 PM CDT > To: ietf@ietf.org >=20 >=20 > This is the third call for volunteers. > VOLUNTEER NOW: we need to make 200. > The DEADLINE is June 26 to volunteer. >=20 > The IETF nomcom appoints folks to fill the open slots on the IAOC, the = IAB, > and the IESG (including IETF Chair). >=20 > If your name is on the below, then you have volunteered and are = qualified. > In addition to those who volunteered by email, it also includes those = who > indicated their willingness to serve on the IETF90 registration form, = and > whose eligibility has been confirmed. 54 people were confirmed to be > eligible, and 70 people were not confirmed based upon the email they = have > used to register. Those 124 people have been contacted directly. >=20 > If you have heard from me, but are not on the list, then there is some > problem, and you should have gotten a query from me to determine your > eligibility. >=20 > If you have volunteered and not heard from him, then please resend; > it got lost. >=20 > Ten voting members for the nomcom are selected in a verifiably random > way from a pool of volunteers. The more volunteers, the better chance = we have > of choosing a random yet representative cross section of the IETF = population. >=20 > Let's break the 200 volunteer mark again this year! > We are at 123 volunteers so far, and WE NEED TO HAVE 200!!! >=20 > The details of the operation of the nomcom can be found in RFC 3777, > and BCP10/RFC3797 details the selection algorithm. >=20 > Volunteers must have attended 3 of the past 5 IETF meetings. As = specified in > RFC 3777, that means three out of the five past meetings up to the = time this > email announcement goes out to start the solicitation of volunteers. > The five meetings out of which you must have attended *three* > are IETF 85(Atlanta), \ > 86(Orlando), \ > 87(Berlin), *** ANY THREE! > 88(Vancouver), / > 89(London) / >=20 > If you qualify, please volunteer. However, much as we want this, = before you > decide to volunteer, please be sure you are willing to forgo = appointment > to any of the positions for which this nomcom is responsible. >=20 > The list of people and posts whose terms end with the March 2015 IETF > meeting, and thus the positions for which this nomcom is responsible, = are >=20 > IAOC: > To be confirmed >=20 > IAB: > Joel Halpern > Russ Housley > Eliot Lear > Xing Li > Andrew Sullivan > Dave Thaler >=20 > IESG: > Pete Resnick (Applications) > Ted Lemon (Internet) > Joel Jaeggli (Operations and Management) > Richard Barnes (RAI) > Adrian Farrel* (Routing) > Stephen Farrell (Security) > Spencer Dawkins (Transport) > Jari Arkko (Gen) >=20 > (names with * have publically indicated they will not serve another = term) >=20 > The primary activity for this nomcom will begin in July 2014 and = should be > completed in January 2015. The nomcom will have regularly scheduled > conference calls to ensure progress. (We might dogfood WebRTC) > There will be activities to collect requirements from the community, = review > candidate questionnaires, review feedback from community members about > candidates, and talk to candidates. >=20 > Thus, being a nomcom member does require some time commitment; but it = is also > a very rewarding experience. >=20 > It is very important that you be able to attend IETF91 to conduct = interviews. > Being at IETF90 is useful for training. Being at IETF92 is not = essential. >=20 > Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 = hours) > June 22, 2013, as follows: >=20 > To: nomcom-chair-2014@ietf.org > Subject: Nomcom 2014-15 Volunteer >=20 > Please include the following 4 lines the email body (it is simplest > if you just include the info); >=20 > Your Full Name > Emails used to register > Telephone > Current Primary Affiliation >=20 > You should expect an email response from me within 3 business days = stating > whether or not you are qualified. If you don't receive this response, > please re-send your email with the tag "RESEND"" added to the subject = line. >=20 > If you are not yet sure if you would like to volunteer, please = consider > that nomcom members play a very important role in shaping the = leadership > of the IETF. Questions by email or voice are welcome. > Volunteering for the nomcom is a great way to contribute to the IETF! >=20 > You can find a detailed timeline on the nomcom web site at: > https://datatracker.ietf.org/nomcom/2014/ >=20 > I will be publishing a more detailed target timetable, as well as = details > of the randomness seeds to be used for the RFC 3797 selection process, > within the next couple weeks. >=20 > Thank you! > Michael Richardson > mcr+nomcom@sandelman.ca > nomcom-chair-2014@ietf.org >=20 > =3D=3D=3D=3D=3D qualified volunteers so far, in alphabetical order by = first name > ANM Zaheduzzaman Sarker > Adam Montville > Ari Ker?nen > Benson Schliesser > Bhumip Khasnabish > Bill VerSteeg > Carl Williams > Carlos Martinez > Charles Eckel > Charles Perkins > Christer Holmberg > Craig White > DHRUV DHODY > Dacheng Zhang > Damien Saucez > Dapeng Liu > Dean Bogdanovic > Dimitri Papadimitriou > Donald Eastlake > Edward Crabbe > Emil Ivov > Eric Rescorla > Eric VYNCKE > Fangwei Hu > Fatai Zhang > Fernando Gont > Fred Baker > Giles Heron > Gonzalo Salgueiro > Gregory Mirsky > Hannes Gredler > Hongyu Li > Hosnieh Rafiee > Hugo Salgado > Hui Deng > Iuniana Oprescu > Jeff Tantsura > John Drake > John Jason Brzozowski > John Levine > John Scudder > Jon Hudson > Jon Mitchell > Karen O'Donoghue > Karen Seo > Kaveh Ranjbar > Klaas Wierenga > Larry Masinter > Lars Eggert > Lee Howard > Lei Zhu > Li Xue > Linda Dunbar > Lingli Deng > Louis (Lou) Berger > Luca Martini > Lucy Lynch > Lucy Yong > Luigi Iannone > Mach Chen > Marcelo Bagnulo > Mark Townsley > Matt Lepinski > Matthew Bocci > Mehmet Ersue > Melinda Shore > Michael Jones > Min Ye > Mingui Zhang > Ning Zong > Ole Troan > Pascal Thubert > Paul Hoffman > Peter Lothberg > Peter Yee > QIN WU > Ralph Droms > Ron Bonica > Ross Callon > Ross Finlayson > Russ White > Sam K. Aldrin > Samuel Weiler > Sandeep Kumar > Sanjay Mishra > Scott Mansfield > Sheng JIANG > Shucheng Liu > Simon Pietro Romano > Stan Ratliff > Stephan Friedl > Stephan Wenger > Stephen Kent > Stewart Bryant > Stig Venaas > Suhas Nandakumar > Suresh Krishnan > Susan Hares > Thomas Walsh > Tim Wicinski > Tissa Senevirathne > Toerless Eckert > Tony Hansen > Ulrich Herberg > Varun Singh > Wassim Haddad > Xiaohu XU > Yi Zhao > Yizhou Li > Yong Cui > Yuanlong Jiang > Yunfei Zhang > Zhaohui Zhang > Zhen Cao > iuniana oprescu >=20 >=20 > -- > Michael Richardson > mcr+nomcom@sandelman.ca > nomcom-chair-2014@ietf.org >=20 >=20 >=20 From nobody Mon Jun 16 10:55:12 2014 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 F30F51A002A for ; Mon, 16 Jun 2014 10:55: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=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 e58YSmWR3JYy for ; Mon, 16 Jun 2014 10:55:07 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410181A001A for ; Mon, 16 Jun 2014 10:55:07 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id fb1so2306992pad.0 for ; Mon, 16 Jun 2014 10:55:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=blLKBT23udprCv0t08rFs5T6UlnaopJWv2IBu5iW0cI=; b=kgJRHGM/ZNy1eMKWR3BR9Tyh1blRnk0XSSoDLlNFfys8MMRk0eAZ3RmEB9GU4BEPf0 TSuQNKpcB6Dv21ZviCwBlKS4OJKxV++w0tXAhseUnVrhDyky4zwROWCV6wnzPxvE8YLE BoMXsbxnDprbI9MBhqhtuvi+GVu5FfKx94zesSifgcjQDlb25JFSE846r3/O7aS8VwxL gGDbB53/YKeIBAKxych1BjMtfilThoKV6fliGc6WJx+V9FVbqS/izFn491DYNVjOcyj/ 5TVic8S+54ygSAmxYARkd0qxTrSDaM18HYsWgcTQHpSElNb1vzijUmPABYUDZDusZpIE /P3w== X-Gm-Message-State: ALoCoQnINKjYXEODutCoO/+0qNZiYxRvTxJWv/cHfpHbAlrFWhmpa+FuYsthPOYeq6nbyB7YA00v X-Received: by 10.66.136.131 with SMTP id qa3mr25756552pab.77.1402941306914; Mon, 16 Jun 2014 10:55:06 -0700 (PDT) Received: from [192.168.1.23] (66-191-14-77.static.knwc.wa.charter.com. [66.191.14.77]) by mx.google.com with ESMTPSA id fu12sm71959959pad.42.2014.06.16.10.55.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Jun 2014 10:55:01 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_613F959D-8123-4B3A-AE9F-08727101B067"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Lance Stout In-Reply-To: <53960056.5080509@stpeter.im> Date: Mon, 16 Jun 2014 10:54:59 -0700 Message-Id: References: <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net> <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com> <5384D9E8.5000601@stpeter.im> <6FF542E9-904E-4997-936F-D4C61087179A@nostrum.com> <53921B7C.8080403@stpeter.im> <73438225-60E0-4301-ABD8-7AE8C8C7CDEE@nostrum.com> <0F867757-72F8-4961-9B0C-476F2987652C@andyet.net> <78B53C44-9C02-4CB3-9D45-48748CA75F54@andyet.net> <5395DAAE.8090906@stpeter.im> <53960056.5080509@stpeter.im> To: XMPP Working Group X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/4GndarRJKbJNKTbONuYAJRFviNA Cc: Ben Campbell Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02 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, 16 Jun 2014 17:55:09 -0000 --Apple-Mail=_613F959D-8123-4B3A-AE9F-08727101B067 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On Jun 9, 2014, at 11:43 AM, Peter Saint-Andre wrote: >> >> Do you mean IETF Last Call? Or do you think we need to repeat the WGLC? > > IETF. It's hard to keep track of which drafts are in which states. :-) +1 for going to IETF Last Call --Apple-Mail=_613F959D-8123-4B3A-AE9F-08727101B067 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 KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNjE2MTc1NDYwWjAjBgkq hkiG9w0BCQQxFgQUM0kGEOasVaIe9I6hBZHwoN/M8pcwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIvpTCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkg SW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwDQYJKoZIhvcNAQEBBQAEggEAQ8cbD1sp55HWKMHa aJa8MS46dF8Dn+1Z+5/RSqHuAyG/gr2f2owdPqsWufq9edv3fru9pIxPy9l7YMyieUyxqDdTl74m ngIeNCci28CJZNp6quobY2Ju59c2vCv9eFv+TaW96+DkB8dJygzx8dWmgaAoMwVD3O42SrjcOBF2 elvtdt9yEEx856r2y7RjTDnSxRXwyOcqHYPJ9H+awryw40qKouO5IjOHJl2EHkUjGNOwVs88yiGR BhGHKtBtqZkITWCfTg4q7io/PaSV9ivaclNtvySSUixrKSI2fc1Gy9QmyITuJc1kYBbXovjmGsff RlzzFlobjZB8VsE5isEBYwAAAAAAAA== --Apple-Mail=_613F959D-8123-4B3A-AE9F-08727101B067-- From nobody Tue Jun 17 07:30:00 2014 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 512F21A0025 for ; Tue, 17 Jun 2014 07:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 gBaCIdfRlkud for ; Tue, 17 Jun 2014 07:29: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 D9CA91A0024 for ; Tue, 17 Jun 2014 07:29:57 -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.14.9/8.14.7) with ESMTP id s5HETtDh012551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 17 Jun 2014 09:29:56 -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 Content-Type: text/plain; charset=us-ascii X-Mao-Original-Outgoing-Id: 424708195.554313-cd5a6e9c7ef7a27d855ec7dd4d488e04 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Message-Id: <6AAED05F-A9CE-489D-A60D-3F9A50EF6886@nostrum.com> Date: Tue, 17 Jun 2014 09:29:55 -0500 To: XMPP Working Group X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Peju_WXLMWShql7zGIYHL1QlVqA Subject: [xmpp] Publication Requested for draft-ietf-xmpp-websocket-07 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, 17 Jun 2014 14:29:59 -0000 Hi Everyone, We just requested publication for draft-ietf-xmpp-websocket-07. It's in = the hands of the IESG now.=20 Thanks to the authors for all the hard work on this (so far :-) ). = Thanks also go to all those who reviewed and discussed it. Ben.= From nobody Thu Jun 19 20:40:42 2014 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 839781A02FB; Thu, 19 Jun 2014 20:40:40 -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 TRGSqznsqhxV; Thu, 19 Jun 2014 20:40:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB221A0168; Thu, 19 Jun 2014 20:40:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140620034038.16277.78785.idtracker@ietfa.amsl.com> Date: Thu, 19 Jun 2014 20:40:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/t3rJl-qg3tlkcHpGjlUuLBLktuU Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-posh-01.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: Fri, 20 Jun 2014 03:40:40 -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 : PKIX over Secure HTTP (POSH) Authors : Matthew Miller Peter Saint-Andre Filename : draft-ietf-xmpp-posh-01.txt Pages : 14 Date : 2014-06-19 Abstract: Experience has shown that it is extremely difficult to deploy proper PKIX certificates for TLS in multi-tenanted environments, since certification authorities will not issue certificates for hosted domains to hosting services, hosted domains do not want hosting services to hold their private keys, and hosting services wish to avoid liability for holding those keys. As a result, domains hosted in multi-tenanted environments often deploy non-HTTP applications such as email and instant messaging using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in obvious security implications. This document defines two methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. The first method enables the TLS client associated with a user agent or peer application server to obtain the end-entity certificate of a hosted domain over secure HTTP as an alternative to standard PKIX techniques. The second method enables a hosted domain to securely delegate a non-HTTP application to a hosting service using redirects provided by HTTPS itself or by a pointer in a file served over HTTPS at the hosted domain. While this approach was developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association prooftype, it can be applied to any non-HTTP application protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-posh-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-posh-01 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 Thu Jun 19 20:50:41 2014 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 6B7021A01CA for ; Thu, 19 Jun 2014 20:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.131 X-Spam-Level: X-Spam-Status: No, score=-14.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 9_8dzKUQY0QT for ; Thu, 19 Jun 2014 20:50:36 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD9B1A01C8 for ; Thu, 19 Jun 2014 20:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3524; q=dns/txt; s=iport; t=1403236235; x=1404445835; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=L1aC7Au8WgxhgZycmpBA6t6gI3jxOcmVYn8Sn816htQ=; b=P/0WMCPrv+fGcC9BoymlKUkv0EfjBJFVtHc31xftdLBbJ0qO4/VwT/Na H5+V04brADLaglIm+VFXrrAWWR9UVQf2xFc2G7VOZMy+UNgL1BmnN2x3b bJTPn0Q1LN7GDquhYLfTMoJFKbZomihql0UyLuoVja+EPFTYK8yS7Q2Cm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsSAD2vo1OtJV2d/2dsb2JhbABPAQmDDVJTB6ocAQEBAQEBBQGZKQElZxZ1g3sIAQEBBHgBEAsYCRYPCQMCAQIBRRMBAwICAQEFhW2CTAgFzDoXhWKIMgYBCgEdMweDBoE9BIoFOpAEgUOSFYNhIoE2OQ X-IronPort-AV: E=Sophos;i="5.01,511,1400025600"; d="scan'208";a="54600051" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP; 20 Jun 2014 03:50:27 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5K3oRWs011292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 20 Jun 2014 03:50:27 GMT Received: from MAMILLE2-M-T03K.CISCO.COM (10.89.15.187) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 19 Jun 2014 22:50:26 -0500 Message-ID: <53A3AF81.5010102@cisco.com> Date: Thu, 19 Jun 2014 21:50:25 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: References: <20140620034038.16277.78785.idtracker@ietfa.amsl.com> In-Reply-To: <20140620034038.16277.78785.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.89.15.187] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Jsfc5g2p9Oq9eaHPyKYqv4qT9TQ Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-posh-01.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: Fri, 20 Jun 2014 03:50:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 6/19/14, 9:40 PM, 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 : PKIX over Secure HTTP (POSH) Authors : > Matthew Miller Peter Saint-Andre Filename : > draft-ietf-xmpp-posh-01.txt Pages : 14 Date : > 2014-06-19 > > Abstract: Experience has shown that it is extremely difficult to > deploy proper PKIX certificates for TLS in multi-tenanted > environments, since certification authorities will not issue > certificates for hosted domains to hosting services, hosted domains > do not want hosting services to hold their private keys, and > hosting services wish to avoid liability for holding those keys. > As a result, domains hosted in multi-tenanted environments often > deploy non-HTTP applications such as email and instant messaging > using certificates that identify the hosting service, not the > hosted domain. Such deployments force end users and peer services > to accept a certificate with an improper identifier, resulting in > obvious security implications. This document defines two methods > that make it easier to deploy certificates for proper server > identity checking in non-HTTP application protocols. The first > method enables the TLS client associated with a user agent or peer > application server to obtain the end-entity certificate of a hosted > domain over secure HTTP as an alternative to standard PKIX > techniques. The second method enables a hosted domain to securely > delegate a non-HTTP application to a hosting service using > redirects provided by HTTPS itself or by a pointer in a file served > over HTTPS at the hosted domain. While this approach was developed > for use in the Extensible Messaging and Presence Protocol (XMPP) as > a Domain Name Association prooftype, it can be applied to any > non-HTTP application protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-xmpp-posh-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-posh-01 > > > 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/ > This revision changes the "by value" document from JWK-set to the fingerprints expressed in a previous email. - -- - - 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTo6+BAAoJEDWi+S0W7cO1aY4H/1r68xg0dZe66Rs1CpkZzWZF OU+R9rwGJcJF7MzZiDeZVHXV/gP/3eBVeOIozstddQn6j1Re7YyOVULisq+vC6+z na8Gqa7W4LyqAE3ppp9rrzSGLNAZVKNIMUn7Wfhtl+ZwgPGWlFmCQsGaTijwjUln DBzur4rbDpRZNkoyBk9qOMQHhxaJfdgHKpz2vMNgKxILSVgTo9MuuvgSSAXGK9gO 2hwxsBs8dwFYUKvIWVyfIK1tQg9pNAWZFJ9E91Ra4yAMBR1+7L3dnx2cDVpxISWw +9QeTArWVLRPJpZ+Gk4JE8zdkWGYs5pwR/LT9g1fu+/nt+eGOzvkyf8jcaWWgR0= =FRbW -----END PGP SIGNATURE----- From nobody Fri Jun 20 13:10:23 2014 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 1C51F1B28EC for ; Fri, 20 Jun 2014 13:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 mJzL2OMknyKU for ; Fri, 20 Jun 2014 13:10:19 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435081B2905 for ; Fri, 20 Jun 2014 13:09:57 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id n16so7887811oag.6 for ; Fri, 20 Jun 2014 13:09:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=84e4jJoUmJXVnJS1awI10/b/CQ29OCG6oZvWhqqGg3M=; b=Sl7zgbNK8avQyJvdwDWgWSaG37/2wjc3jExHh3U3o4+ScL86AfTw3XBVGQe+4cF2gv /2vYpDLpbRFhU0hBhMlt0XA1WX6dDpbfYWujsrKcNTAY17jJ4mAHRzvJ/xNvloPgDi7+ imrJE8OIEFjlPFHwVsf6xyJtPuynGhf2KcyBfOocdUz70qEttoMJV5AIUDOgMIizuuQn TCAofmApGvHeOLg9BDZrFle/5yNW/E9X0O0KWKQCM2OLSfj3DnSNhS++OKTq2+XT2kI0 ub9K1H7y3yInLH9JiCLRL5lwIUu8zWncIDQWj6yC6ERs1WWGpMG/i33HAdBeYs/dbfZ5 oNsA== X-Gm-Message-State: ALoCoQkOfVUbSnWI4uRAwYRZjVbCeTvEF3nkQRlULNopdMvMVp/V95SjGt1AfRtEJwElMail9lBd MIME-Version: 1.0 X-Received: by 10.60.179.138 with SMTP id dg10mr5892154oec.13.1403294996579; Fri, 20 Jun 2014 13:09:56 -0700 (PDT) Received: by 10.60.143.131 with HTTP; Fri, 20 Jun 2014 13:09:56 -0700 (PDT) Date: Fri, 20 Jun 2014 16:09:56 -0400 Message-ID: From: Richard Barnes To: XMPP Working Group , draft-ietf-xmpp-websocket@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7b86d782c957e304fc4a13e4 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/wYXZ5kzXxxmnW56I_y_6ax_iAvQ Subject: [xmpp] AD review of draft-ietf-xmpp-websocket 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, 20 Jun 2014 20:10:21 -0000 --047d7b86d782c957e304fc4a13e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have reviewed this draft in preparation for IETF LC. Overall, it looks to be in good shape. Thanks for a nice document. I've requested last call, and there are a few minor comments below to consider along with LC comments. Thanks, --Richard MINOR S3.1. "WebSocket messages sent or received will conform" Should this be "MUST conform"? S3.6.1. "a different transport, such as BOSH" How is the recipient of one of these messages supposed to tell what transport? Does the use of an http- or https-schemed URI imply BOSH? S3.7. "[Streams implicitly closed]" Does this usage map cleanly to the TCP case? That is, would a element be sent in this closure case? I'm just imagining that if you have, say, a relatively na=C3=AFve gateway that translates to and to , this could cause problems. --047d7b86d782c957e304fc4a13e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this draft in preparation for IETF LC. =C2= =A0Overall, it looks to be in good shape. =C2=A0Thanks for a nice document.= =C2=A0I've requested last call, and there are a few minor comments bel= ow to consider along with LC comments.

Thanks,
--Richard


MINOR

S3.1. "WebSocket messages sent or= received will conform"
Should this be "MUST conform&qu= ot;?

S3.6.1. "a different transport, such as BOSH"=
How is the recipient of one of these messages supposed to tell w= hat transport? =C2=A0Does the use of an http- or https-schemed URI imply BO= SH?

S3.7. "[Streams implicitly closed]"
Does this usage map cleanly to the TCP case? =C2=A0That is, would a </s= tream> element be sent in this closure case? =C2=A0I'm just imaginin= g that if you have, say, a relatively na=C3=AFve gateway that translates &l= t;stream> to <open> and </stream> to <close>, this cou= ld cause problems.

--047d7b86d782c957e304fc4a13e4-- From nobody Fri Jun 20 14:35:25 2014 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 2CE251B2909 for ; Fri, 20 Jun 2014 14:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 069NJJZd2k-w for ; Fri, 20 Jun 2014 14:35:20 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9991A0283 for ; Fri, 20 Jun 2014 14:35:20 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id w10so3396702pde.17 for ; Fri, 20 Jun 2014 14:35:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=zee07dQ0Iuv/VgtgPBEOHJR3otroYOlRXljmIFSAphg=; b=OEhabRB+509IXhVHczfIT9zHVx9jGBs4PMeGrdcj2WcA9z5W4thdAg5k8evblVRuxe PHvTjGUM455LKJeQDDDB7ll1bQWYs9ZhmFJeuRbkPsiQmysdTBgAdvYoVcHWgxDiuGoG p/yrPFZwg2LGMK7fhy2UBTLguAPP4PcM588OVORJLeIcM680o5crFdrFOiFTZIqXP080 a5JxowuC3zi/R7jXTjmzUos3tWkoPGMJxjmOx3oCGQG2aC+H4Tvcf/eg0Su7K5fOCoCv zja+SNkqZs4OxnUNBPpzCQQ6Z8ndn7DfZHT7GnrzuK3Mf5/CEyi6l6fXCLqi2FlaEFf5 G5yA== X-Gm-Message-State: ALoCoQkmrPqF1/+oLJF4D7SeOuVLbDwQSC9Grcg2qSDmUPOGlt1nSCTXuzkpa031WLaKlQ7YgdJQ X-Received: by 10.66.156.71 with SMTP id wc7mr8210555pab.64.1403300119990; Fri, 20 Jun 2014 14:35:19 -0700 (PDT) Received: from [192.168.1.23] (66-191-14-77.static.knwc.wa.charter.com. [66.191.14.77]) by mx.google.com with ESMTPSA id zb2sm15007601pbb.45.2014.06.20.14.35.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 14:35:18 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8C554B1D-7471-4E85-B409-273075C09CE9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Lance Stout In-Reply-To: Date: Fri, 20 Jun 2014 14:35:17 -0700 Message-Id: <617D9F2E-D236-48C8-902F-9BDFEDD92F91@andyet.net> References: To: Richard Barnes X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/PeGj-edyt0hvTAzD03jhfAsKEAI Cc: XMPP Working Group Subject: Re: [xmpp] AD review of draft-ietf-xmpp-websocket 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, 20 Jun 2014 21:35:22 -0000 --Apple-Mail=_8C554B1D-7471-4E85-B409-273075C09CE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > MINOR >=20 > S3.1. "WebSocket messages sent or received will conform" > Should this be "MUST conform"? Makes sense to me to make that MUST, since that's the entire point of = this document. > S3.6.1. "a different transport, such as BOSH" > How is the recipient of one of these messages supposed to tell what = transport? Does the use of an http- or https-schemed URI imply BOSH? I would assume that's implied, as BOSH is the only defined transport for = the http/https scheme, and I don't expect for us to define another given = the existing deployment base. However, I can see where this could get fuzzy. Any suggestions on a = solution? > S3.7. "[Streams implicitly closed]" > Does this usage map cleanly to the TCP case? That is, would a = element be sent in this closure case? I'm just imagining that = if you have, say, a relatively na=EFve gateway that translates = to and to , this could cause problems. Yes, this intentionally mirrors the process used in the TCP binding. The = Prosody implementation of this spec actually does exactly that 'na=EFve = gateway' approach internally to convert the framed stream to the TCP C2S = stream format to reuse its existing code paths. - Lance --Apple-Mail=_8C554B1D-7471-4E85-B409-273075C09CE9 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 KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNjIwMjEzNTE3WjAjBgkq hkiG9w0BCQQxFgQUlf1M9iULa1l3aYaVEbjn90aLONkwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIvpTCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkg SW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwDQYJKoZIhvcNAQEBBQAEggEAmTeShMDIq3MdtEnn XmqRUtjtXsoEQZnrW0vnx5W7l6C323RlX8YxGjGBrSPLl8/UF1k/mGudErw3NXmH62BEpkPCW+5a eBTk94Vca0cZMQ3cA8QT655XBGBXLPT2kL1dCc+PY2EiQIWPIjvU/Yl1E28KEvsNNs/Ebq5YzeMy LF7ZxflQ2VGlCaid0Ux7uVPNoo+bhHEL0Rw6Dgtp8R7gw0kg+cYLb/oowE1jq+dF4jfsJDOszYZG aZb3RfXK8RHPAP4edEz0msXnlw29QYLS+je1kRxGGcaerqhbvIWQttl555mgMSuMtBMs6MIo6Kq5 biBCcXno5yVtWWJGuzu/gAAAAAAAAA== --Apple-Mail=_8C554B1D-7471-4E85-B409-273075C09CE9-- From nobody Fri Jun 20 16:42:43 2014 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 257351A04AC for ; Fri, 20 Jun 2014 16:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 s5hgxuFG0Oca for ; Fri, 20 Jun 2014 16:42:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339FF1A04B8 for ; Fri, 20 Jun 2014 16:42:39 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id uy5so1834603obc.3 for ; Fri, 20 Jun 2014 16:42:38 -0700 (PDT) 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=EAy2VYbmpXIy1GITNF/tL8wlKgEtAmopBMKlIDW1C7Y=; b=JiDxSNb947+oBnMYDOGBGOQkNph5/16T+TGspCpEWa0Pgiex0RdTx89xRSjwOjWRL6 P6J6qYxUf/13o3/hxc1/Yk5RyfbyZVpnx8fwOVdEgb5ZtSovnwsMx/xyRke8wtzOruce 5FgeniBpc1jTGhd3IEUW6TIJLJwQw/gPrDEO64Ts49FCy7tSj3wPsv5taXUVrailprZl l1Tv5s0eZ53CqfXqMHWaePkL26LjfmLPt8ZebUvviFwCrZQ0LVhazjqG2KZR+6+Vfz3+ SPhb8vFH4Cwdqf7zqiL/XB3i7RdfcqEy5BIw7uyyCrlqiuhXKLnAln2isQ5r4KhRSd/C NdDA== X-Gm-Message-State: ALoCoQmJodTThwFdLrncy/iApm1+yzcoxch2K9ozJAUenOyIxgztboLmE0K4j6xRofy6evT04Kyb MIME-Version: 1.0 X-Received: by 10.182.24.38 with SMTP id r6mr6849394obf.10.1403307758619; Fri, 20 Jun 2014 16:42:38 -0700 (PDT) Received: by 10.60.143.131 with HTTP; Fri, 20 Jun 2014 16:42:38 -0700 (PDT) In-Reply-To: <617D9F2E-D236-48C8-902F-9BDFEDD92F91@andyet.net> References: <617D9F2E-D236-48C8-902F-9BDFEDD92F91@andyet.net> Date: Fri, 20 Jun 2014 19:42:38 -0400 Message-ID: From: Richard Barnes To: Lance Stout Content-Type: multipart/alternative; boundary=001a11c29c8276a29e04fc4d0cae Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/fBT6kYgOkgie56RoLtc5uy1Go2M Cc: XMPP Working Group Subject: Re: [xmpp] AD review of draft-ietf-xmpp-websocket 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, 20 Jun 2014 23:42:41 -0000 --001a11c29c8276a29e04fc4d0cae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 20, 2014 at 5:35 PM, Lance Stout wrote: > > > MINOR > > > > S3.1. "WebSocket messages sent or received will conform" > > Should this be "MUST conform"? > > Makes sense to me to make that MUST, since that's the entire point of thi= s > document. > > > > S3.6.1. "a different transport, such as BOSH" > > How is the recipient of one of these messages supposed to tell what > transport? Does the use of an http- or https-schemed URI imply BOSH? > > I would assume that's implied, as BOSH is the only defined transport for > the http/https scheme, and I don't expect for us to define another given > the existing deployment base. > > However, I can see where this could get fuzzy. Any suggestions on a > solution? If it wouldn't be too disruptive to change the syntax, you could just do the same thing as XEP-0156 and specify the protocol explicitly. Otherwise, perhaps some text of the form: "Since BOSH is the only HTTP-based transport for XMPP, an HTTP URI in the "see-other-uri" attribute indicates that the client should connect using BOSH. Likewise, a WebSocket URI indicates that the client should use the transport defined in this document." There's some risk that a persnickety AD will ask for a registry (scheme to protocol mapping), but I think we can push back on that. > > S3.7. "[Streams implicitly closed]" > > Does this usage map cleanly to the TCP case? That is, would a > element be sent in this closure case? I'm just imagining that if you hav= e, > say, a relatively na=C3=AFve gateway that translates to a= nd > to , this could cause problems. > > Yes, this intentionally mirrors the process used in the TCP binding. The > Prosody implementation of this spec actually does exactly that 'na=C3=AFv= e > gateway' approach internally to convert the framed stream to the TCP C2S > stream format to reuse its existing code paths. > > > > - Lance > > > --001a11c29c8276a29e04fc4d0cae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 20, 2014 at 5:35 PM, Lance Stout <lance@andyet.net> w= rote:

> MINOR
>
> S3.1. "WebSocket messages sent or received will conform"
> Should this be "MUST conform"?

Makes sense to me to make that MUST, since that's the entire poin= t of this document.


> S3.6.1. "a different transport, such as BOSH"
> How is the recipient of one of these messages supposed to tell what tr= ansport? =C2=A0Does the use of an http- or https-schemed URI imply BOSH?
I would assume that's implied, as BOSH is the only defined transp= ort for the http/https scheme, and I don't expect for us to define anot= her given the existing deployment base.

However, I can see where this could get fuzzy. Any suggestions on a solutio= n?

If it wouldn't be too disruptive to = change the syntax, you could just do the same thing as XEP-0156 and specify= the protocol explicitly. =C2=A0Otherwise, perhaps some text of the form:

"Since BOSH is the only HTTP-based transport for X= MPP, an HTTP URI in the "see-other-uri" attribute indicates that = the client should connect using BOSH. =C2=A0Likewise, a WebSocket URI indic= ates that the client should use the transport defined in this document.&quo= t;

There's some risk that a persnickety AD will ask fo= r a registry (scheme to protocol mapping), but I think we can push back on = that.
=C2=A0
> S3.7. "[Streams implicitly closed]"
> Does this usage map cleanly to the TCP case? =C2=A0That is, would a &l= t;/stream> element be sent in this closure case? =C2=A0I'm just imag= ining that if you have, say, a relatively na=C3=AFve gateway that translate= s <stream> to <open> and </stream> to <close>, this= could cause problems.

Yes, this intentionally mirrors the process used in the TCP binding. = The Prosody implementation of this spec actually does exactly that 'na= =C3=AFve gateway' approach internally to convert the framed stream to t= he TCP C2S stream format to reuse its existing code paths.



- Lance



--001a11c29c8276a29e04fc4d0cae-- From nobody Fri Jun 20 16:56:12 2014 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 7B86C1B291C; Fri, 20 Jun 2014 16:56:11 -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 vUaefYpc2wKX; Fri, 20 Jun 2014 16:56:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5185D1A04C5; Fri, 20 Jun 2014 16:56:10 -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: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140620235610.32497.80891.idtracker@ietfa.amsl.com> Date: Fri, 20 Jun 2014 16:56:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/sIfCbU5s13BfbsYGS0nqTvoKcCY Cc: xmpp@ietf.org Subject: [xmpp] Last Call: (An XMPP Sub-protocol for WebSocket) 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: Fri, 20 Jun 2014 23:56:11 -0000 The IESG has received a request from the Extensible Messaging and Presence Protocol WG (xmpp) to consider the following document: - 'An XMPP Sub-protocol for WebSocket' 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 2014-07-04. 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 a binding for the XMPP protocol over a WebSocket transport layer. A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sat Jun 21 18:50:59 2014 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 A17831B286A; Sat, 21 Jun 2014 18: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 QhOQ2MfR3b3I; Sat, 21 Jun 2014 18:50:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4551A02DA; Sat, 21 Jun 2014 18:50:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140622015050.18121.40882.idtracker@ietfa.amsl.com> Date: Sat, 21 Jun 2014 18:50:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/wAdtpaNrmYk-oer0NaC9VrLp4JQ Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-dna-06.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: Sun, 22 Jun 2014 01:50:52 -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 Filename : draft-ietf-xmpp-dna-06.txt Pages : 17 Date : 2014-06-21 Abstract: This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how "prooftypes" can establish a strong association between a domain name and an XML stream. Second, it describes how to securely delegate a source domain to a derived domain, which is especially important in multi-tenanted environments. 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-dna-06 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 Sat Jun 21 18:53:28 2014 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 F35AB1B2865 for ; Sat, 21 Jun 2014 18:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 ybkbJ9V10ea2 for ; Sat, 21 Jun 2014 18:53:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6238D1A02DA for ; Sat, 21 Jun 2014 18:53:25 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2B5E840D53; Sat, 21 Jun 2014 19:53:25 -0600 (MDT) Message-ID: <53A63714.7080905@stpeter.im> Date: Sat, 21 Jun 2014 19:53:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <20140622015050.18121.40882.idtracker@ietfa.amsl.com> In-Reply-To: <20140622015050.18121.40882.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/JXbV8acgh29hQJeHed9bFJrmTSI Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-06.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: Sun, 22 Jun 2014 01:53:27 -0000 To address feedback from Philipp Hancke, described the client-to-server flow (much simpler than server-to-server!). I think we still need to address some other feedback, too, but we'll push out a revised I-D for that. Peter On 6/21/14, 7:50 PM, 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 > Filename : draft-ietf-xmpp-dna-06.txt > Pages : 17 > Date : 2014-06-21 > > Abstract: > This document improves the security of the Extensible Messaging and > Presence Protocol (XMPP) in two ways. First, it specifies how > "prooftypes" can establish a strong association between a domain name > and an XML stream. Second, it describes how to securely delegate a > source domain to a derived domain, which is especially important in > multi-tenanted environments. > > > 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-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-dna-06 > > > 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 >