From nobody Fri Feb 6 10:01:29 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A589D1A1E0F for ; Fri, 6 Feb 2015 10:01:28 -0800 (PST) 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 AQJT6HnBV8z1 for ; Fri, 6 Feb 2015 10:01:26 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B111A0E10 for ; Fri, 6 Feb 2015 10:01:26 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so4473899igk.1 for ; Fri, 06 Feb 2015 10:01:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wSdX5/hAJXlfWEpktIIxWnGef+wk8B1rcB7L5MxEy7s=; b=JFV5frN8dG5TzYSPvs8WJY094uHkF/J5hlx4ePuO8oVwjGvd9eErJ5VynW64UJFNQy qxbmgdc9BC57QXKKO3sVSJlzH9DOu/7dVeI9v9sQ5l0Vvn4a4ZlYXcTUNtxLaSb5xc9T NgJdWKp9+Y5URvqbGIXeSC2wPE7Psk/+nhVS1v0CuDgKZ9ReVTuNzAiBkRSF+iNEqFzT fjf9wpK1GueK0T4Ef3adO+JRho6scBpreSt+k5BYuxOlijvTfcPW6A+CMgr4K7bTxvO9 yTGJngO/AdBfRkmvozHlaqRtwVYv3ESdRa99R3KvP22nqS62BcF4GppPtUhNTSimnh4V 3DxQ== X-Gm-Message-State: ALoCoQnJ/vlSmsIgmyBJSE/UJq84eT1+9nLgftdfuxONdR52JOFmIhWb9ksrkxaortp4Oo36Bq3N X-Received: by 10.42.111.5 with SMTP id s5mr13755842icp.79.1423245685968; Fri, 06 Feb 2015 10:01:25 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id g20sm786793igt.14.2015.02.06.10.01.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Feb 2015 10:01:25 -0800 (PST) Message-ID: <54D50174.2050904@andyet.net> Date: Fri, 06 Feb 2015 11:01:24 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: XMPP Working Group References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [xmpp] Fwd: [precis] WGLC on draft-ietf-precis-saslprepbis 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 Feb 2015 18:01:28 -0000 As noted, our work on 6122bis depends on this document, so reviews from folks here would be very helpful! -------- Forwarded Message -------- Subject: [precis] WGLC on draft-ietf-precis-saslprepbis Date: Fri, 6 Feb 2015 12:32:31 -0500 From: Marc Blanchet To: precis@ietf.org Hello, this is a 2 weeks WGLC on draft-ietf-precis-saslprepbis, ending on February 20th 2015, 23h59 UTC. Please send support, comments, suggestions, modifications to the list and to the authors (draft-ietf-precis-saslprepbis@tools.ietf.org). Those who read the document and support it without modifications, please indicate so to the mailing list. The assigned shepherd of the document is Matthew Miller. Please note that xmpp-6122bis which depends on saslprepbis will be co-WGLC with xmpp wg after the saslprepbis precis WGLC is done. Marc, co-chair precis wg. _______________________________________________ precis mailing list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis From nobody Fri Feb 13 09:50:23 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD151A006F for ; Fri, 13 Feb 2015 09:50:18 -0800 (PST) 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 DKjsiD5m5i3m for ; Fri, 13 Feb 2015 09:50:16 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F70F1A005F for ; Fri, 13 Feb 2015 09:50:00 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so12158017igq.0 for ; Fri, 13 Feb 2015 09:50:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=TG6hym9MSgp2otwuyGUxyVBu+HEAHl4mOSCI+IAJ1fQ=; b=f1FmrlY2b/ZTS5W3ZxZyzLe5B91tEdaAmAxCRqaV64ecLZGR5YfG+iGi+Q4QBCbStn W6d6o46a/kk1FrFC4cKbfXhxSnEl3/r9Lomwnkj0I/vTBGf/DpDHhsn9lEDqybGxfMtn 1SX5vdpilvag+0qNzq7cwwklu39rLY1SK/V2wLfdO2hRucgTgu1WUSgOc2Z7TWVKFvdR uNdHVbLEZZRJQNi5VjwuM53OuAWnFnlDZd4upt/8tlSmqJ8DHQAynY99d/yB73EEcg7t AD/AgHrXrCoupNn3BF48BIvaJCmDvQXOFQkpJFJ69X/HeJ+t//BWzhqceMFysIva5eqx jFNg== X-Gm-Message-State: ALoCoQlIopB2ZtfCNADgcS87t48NZyOncD+OStif/YMMubXSpNKQodBkqliufHiEfA5I85DYME2a X-Received: by 10.107.17.203 with SMTP id 72mr13408239ior.42.1423849800011; Fri, 13 Feb 2015 09:50:00 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id ie15sm3622329igb.12.2015.02.13.09.49.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Feb 2015 09:49:59 -0800 (PST) Message-ID: <54DE3946.8020108@andyet.net> Date: Fri, 13 Feb 2015 10:49:58 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: XMPP Working Group Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [xmpp] e2e encryption 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, 13 Feb 2015 17:50:19 -0000 We're close to finishing all of our deliverables (6122bis, POSH, DNA) other than end-to-end encryption ("e2e") - IMHO they can all be sent to the IESG by, say, the end of April. I know we plan to talk about e2e at IETF 92 in Dallas at the end of March, but I figured it would be good to start a list thread before then. To be blunt, we (narrowly the XMPP WG but more widely and importantly the XMPP community) have failed to deliver an e2e technology. It's not for lack of proposals over the years: PGP, S/MIME, XML encryption, SIGMA, e2e TLS, OTR, and JOSE-based signing and encryption have all flitted across the stage. To also be blunt, I don't think we have the right people in the room here to make significant progress on e2e. I don't think the XSF has had the right people in the room, either. I am of the opinion that, in order to move forward, someone - probably the XSF - needs to get all the relevant client and library developers working together. By which I mean writing code, experimenting with alternative approaches, meeting in person for interop testing, hashing out spec details, etc. That will require funding (which the XSF might be able to raise and provide), dedicated energy among developers, and a real attempt to push forward together as a community. This isn't the place to make an organizing proposal for such an initiative. Although it is possible that the IETF or the XMPP WG could work in concert with the XSF or the XMPP developer community on such an initiative, that has its own challenges. In any case, I don't think the IETF can really find rough consensus until we have the relevant developers engaged to write some running code. Thus my suggestion is that we complete our other deliverables, shut down the XMPP WG without delivering an e2e solution, and put our energy into another venue where we'll have a greater chance of success on e2e. If and when we have an e2e technology that really seems promising and has the XMPP developer community on board with running code, then we can always spin up another incarnation of the XMPP WG to adapt or review that technology as a potential standard. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Feb 13 10:27:19 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F4B1A00E6 for ; Fri, 13 Feb 2015 10:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyD0sDwcL1gr for ; Fri, 13 Feb 2015 10:27:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5975A1A00BD for ; Fri, 13 Feb 2015 10:27:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0E01DBEEC; Fri, 13 Feb 2015 18:27:10 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG2P6oZT1Qlk; Fri, 13 Feb 2015 18:27:09 +0000 (GMT) Received: from [10.10.5.195] (unknown [216.127.117.11]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 891AABEEB; Fri, 13 Feb 2015 18:27:08 +0000 (GMT) Message-ID: <54DE41FA.5030200@cs.tcd.ie> Date: Fri, 13 Feb 2015 18:27:06 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , XMPP Working Group References: <54DE3946.8020108@andyet.net> In-Reply-To: <54DE3946.8020108@andyet.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [xmpp] e2e encryption 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, 13 Feb 2015 18:27:16 -0000 Hiya, I'd be a bit sad if the xmpp wg closed without getting a good e2e spec done. But I agree that progress so far has not been stellar despite various credible proposals and various folks' diligent efforts. On 13/02/15 17:49, Peter Saint-Andre - &yet wrote: > I am of the opinion that, in order to move forward, someone - probably > the XSF - needs to get all the relevant client and library developers > working together. By which I mean writing code, experimenting with > alternative approaches, meeting in person for interop testing, hashing > out spec details, etc. That will require funding (which the XSF might be > able to raise and provide), dedicated energy among developers, and a > real attempt to push forward together as a community. If that's the route that's taken, I'd be happy to try help to the extent I can, which is probably not much, but I'd be supportive of continued efforts, even if those are outside the IETF process for a bit. If there's a way that the IETF could help with that, e.g. a list, or providing room space at meetings or something, I'd be very happy to help make that happen. Cheers, S. From nobody Sat Feb 14 00:06:32 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3D01A1AF9 for ; Sat, 14 Feb 2015 00:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 FHYvzzSUL_81 for ; Sat, 14 Feb 2015 00:06:26 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 4695A1A1AF2 for ; Sat, 14 Feb 2015 00:06:26 -0800 (PST) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id ED44993C1AF; Sat, 14 Feb 2015 08:05:20 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: <54DE3946.8020108@andyet.net> Date: Sat, 14 Feb 2015 09:06:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <44B29692-EB69-48FB-B7EA-59FC31B03B54@edvina.net> References: <54DE3946.8020108@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: XMPP Working Group Subject: Re: [xmpp] e2e encryption 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: Sat, 14 Feb 2015 08:06:29 -0000 On 13 Feb 2015, at 18:49, Peter Saint-Andre - &yet = wrote: > We're close to finishing all of our deliverables (6122bis, POSH, DNA) = other than end-to-end encryption ("e2e") - IMHO they can all be sent to = the IESG by, say, the end of April. >=20 > I know we plan to talk about e2e at IETF 92 in Dallas at the end of = March, but I figured it would be good to start a list thread before = then. >=20 > To be blunt, we (narrowly the XMPP WG but more widely and importantly = the XMPP community) have failed to deliver an e2e technology. It's not = for lack of proposals over the years: PGP, S/MIME, XML encryption, = SIGMA, e2e TLS, OTR, and JOSE-based signing and encryption have all = flitted across the stage. >=20 > To also be blunt, I don't think we have the right people in the room = here to make significant progress on e2e. I don't think the XSF has had = the right people in the room, either. I am of the opinion that, in order = to move forward, someone - probably the XSF - needs to get all the = relevant client and library developers working together. By which I mean = writing code, experimenting with alternative approaches, meeting in = person for interop testing, hashing out spec details, etc. That will = require funding (which the XSF might be able to raise and provide), = dedicated energy among developers, and a real attempt to push forward = together as a community. >=20 > This isn't the place to make an organizing proposal for such an = initiative. Although it is possible that the IETF or the XMPP WG could = work in concert with the XSF or the XMPP developer community on such an = initiative, that has its own challenges. In any case, I don't think the = IETF can really find rough consensus until we have the relevant = developers engaged to write some running code. >=20 > Thus my suggestion is that we complete our other deliverables, shut = down the XMPP WG without delivering an e2e solution, and put our energy = into another venue where we'll have a greater chance of success on e2e. = If and when we have an e2e technology that really seems promising and = has the XMPP developer community on board with running code, then we can = always spin up another incarnation of the XMPP WG to adapt or review = that technology as a potential standard. I agree. e2e is a shared problem for many similar systems. SIP has exactly the = same problem. /O= From nobody Tue Feb 17 08:27:44 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3B41A8AE6; Tue, 17 Feb 2015 08:27:41 -0800 (PST) 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 Q5nTwW6EZ7ct; Tue, 17 Feb 2015 08:27:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDAC1A8AC1; Tue, 17 Feb 2015 08:27:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217162729.16058.70505.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 08:27:29 -0800 Archived-At: Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-dna-09.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 16:27:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP) Authors : Peter Saint-Andre Matthew Miller Philipp Hancke Filename : draft-ietf-xmpp-dna-09.txt Pages : 20 Date : 2015-02-17 Abstract: This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server host name (e.g., hosting.example.net), which is especially important in multi-tenanted environments where the same target server hosts a large number of domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-dna-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-dna-09 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 Feb 20 13:36:58 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7191A012D for ; Fri, 20 Feb 2015 13:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKYZ9l6EHgsF for ; Fri, 20 Feb 2015 13:36:56 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1601A87B2 for ; Fri, 20 Feb 2015 13:36:53 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1KLaQZq091982 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Feb 2015 15:36:26 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "XMPP Working Group" Date: Fri, 20 Feb 2015 15:36:19 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate Trial (1.9r5060) Archived-At: Cc: draft-ietf-xmpp-dna.all@tools.ietf.org Subject: [xmpp] WGLC of draft-ietf-xmpp-dna-09 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 21:36:57 -0000 This is an XMPP Working Group Last Call of draft-ietf-xmpp-dna-09. The draft is available at the following URL https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ The WGLC will conclude on March 6, 2015. Please send your comments to the authors and the XMPP mailing list. (Given that the draft deadline for IETF92 is the following Monday, I suspect the authors would really appreciate people not waiting till the last minute to send feedback.) Thanks! Ben. From nobody Fri Feb 20 16:30:46 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5429B1A0451 for ; Fri, 20 Feb 2015 16:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Xu9HfpD_zp3 for ; Fri, 20 Feb 2015 16:30:43 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6382D1A0439 for ; Fri, 20 Feb 2015 16:30:43 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1L0Ubxf004805 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Feb 2015 18:30:38 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: draft-ietf-xmpp-posh.all@tools.ietf.org Date: Fri, 20 Feb 2015 18:30:37 -0600 Message-ID: <9A67CFDB-5504-43E0-A63C-82E996A70620@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate Trial (1.9r5060) Archived-At: Cc: XMPP Working Group Subject: [xmpp] PROTO review of draft-ietf-xmpp-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: Sat, 21 Feb 2015 00:30:45 -0000 Hi Peter and Matt, I’m in the process of doing a PROTO writeup for POSH, and have one possibly material comment, and a few minor comments. Apologies for not turning these up during WLGC, and also if these rehash stuff we’ve already closed on. (The chairs should yell at me.) — Material Comment: IANA Considerations These seems a bit unusual, since we are registering a “fragment” that other protocols will use to register actual URIs. This does not seem to have been contemplated by RFC5785. This also the side effect of establishing rules for certain entries in the well-known URI registry over and above those from RFC5785. Does it make sense to actually register the prefix itself, since it’s not really a URI? It would seem reasonable to leave the actual registration to protocols that need to register posh URIs. I see Mark Nottingham is the expert for the well-known URI registry. By any chance has anyone run this by him? Editorial Comments: — section 3, numbered steps: Which server is the POSH server? Is that the hosting server, or the web server that serves the well-known URI? I can infer the answer, but it would be good to be explicit. — section 3.2, 3rd paragraph from end: (starting with “Note: The JSON document…”) There’s 2119 language in a “Note”. I tend to read indented notes as parenthetical. If it needs 2119 language it should probably be part of the mainstream text. — Security Considerations: “To protect against circular references, clients MUST NOT follow an infinite number of redirects.” That’s a bit of a circular reference. Or at least a tautology. Perhaps it could be non-normative, or reformulated as something to the effect of “… MUST limit the number of redirects…” —References: IDNits reports a few out-of-date references. Thanks! Ben. From nobody Mon Feb 23 13:58:11 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEED81A6FF5 for ; Mon, 23 Feb 2015 13:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 mQIe5M3EBYAm for ; Mon, 23 Feb 2015 13:58:09 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE3B1A6FEE for ; Mon, 23 Feb 2015 13:58:09 -0800 (PST) Received: by iecrp18 with SMTP id rp18so27300591iec.1 for ; Mon, 23 Feb 2015 13:58:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0haz44BgVqaETX7MTM/OvuIgjybwxjN1xmSEi3fVtUw=; b=B4WuGe9KrtJjq19tn1i1tgc9umtF0ew9w4xssZAjGeJ2YG9TTMRxBJGmQZaunAR6I7 xJgdHdzQh/FB8xXDoVOBOk+KaU14z2iqiEIRFYyC0jjhcobyMZpmHeSDjAdOhECERqPp YjyvTz33d9VE2Vo6uYiLY+auYDQEA3Mb1u7dF6aMTxhTlQUyfmv0r/IuRIh0EkrYjSmi GEiEKTw+HlRvo8T3u0Kwn9UtI/EYon/PqoHQd9V38RHWACcfdvMne79yrMwXRQ5SkD2r VJ/QzKHmTBe47ZaihAy9OgtYeY/ChwwLlrvsQg7uMCQfMwZDw0a/KwIMFSpNb9YH8OtY eAXQ== X-Gm-Message-State: ALoCoQm5ni07zkyKcM6f3YI5oZO0mUCyOBc52PzcFp2VCfLPfi/R2hPPVk5sdmYTzBi5x8mQJXYY X-Received: by 10.50.117.41 with SMTP id kb9mr15900637igb.37.1424728688616; Mon, 23 Feb 2015 13:58:08 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id h15sm11438705ioh.27.2015.02.23.13.58.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 13:58:07 -0800 (PST) Message-ID: <54EBA26D.4080000@andyet.net> Date: Mon, 23 Feb 2015 14:58:05 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell , draft-ietf-xmpp-posh.all@tools.ietf.org References: <9A67CFDB-5504-43E0-A63C-82E996A70620@nostrum.com> In-Reply-To: <9A67CFDB-5504-43E0-A63C-82E996A70620@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: XMPP Working Group Subject: Re: [xmpp] PROTO review of draft-ietf-xmpp-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, 23 Feb 2015 21:58:11 -0000 Hi Ben, thanks for the review. On 2/20/15 5:30 PM, Ben Campbell wrote: > Hi Peter and Matt, > > I’m in the process of doing a PROTO writeup for POSH, and have one > possibly material comment, and a few minor comments. Apologies for not > turning these up during WLGC, and also if these rehash stuff we’ve > already closed on. (The chairs should yell at me.) > > — Material Comment: IANA Considerations > > These seems a bit unusual, since we are registering a “fragment” that > other protocols will use to register actual URIs. This does not seem to > have been contemplated by RFC5785. This also the side effect of > establishing rules for certain entries in the well-known URI registry > over and above those from RFC5785. > > Does it make sense to actually register the prefix itself, since it’s > not really a URI? It would seem reasonable to leave the actual > registration to protocols that need to register posh URIs. You make a very good point. I think you're right that it makes more sense for the POSH spec to provide instructions to protocols that need to register POSH URIs - as, for instance, draft-ietf-xmpp-dna does - but not to register a URI prefix (instead, just say "please use the prefix"). > I see Mark Nottingham is the expert for the well-known URI registry. By > any chance has anyone run this by him? I have a vague recollection of having talked with him about it once, but I can find no evidence of that in my email folders. If we agree that what you suggest is the best approach, then I think it makes sense to update the document before reaching out to him (and in fact that might not be necessary since this document wouldn't be doing anything unusual). > Editorial Comments: > > — section 3, numbered steps: > > Which server is the POSH server? Is that the hosting server, or the web > server that serves the well-known URI? I can infer the answer, but it > would be good to be explicit. It is the server hosting the application service. I agree that this could be clearer in the text. The web server is called the "Source Domain HTTPS server" here (which is rather a mouthful). > — section 3.2, 3rd paragraph from end: (starting with “Note: The JSON > document…”) > > There’s 2119 language in a “Note”. I tend to read indented notes as > parenthetical. If it needs 2119 language it should probably be part of > the mainstream text. Yeah, taking that out of a note seems best. > — Security Considerations: > > “To protect against circular > references, clients MUST NOT follow an infinite number of redirects.” > > That’s a bit of a circular reference. Or at least a tautology. > Perhaps it could be non-normative, or reformulated as something to the > effect of “… MUST limit the number of redirects…” Right, "less than infinite" isn't all that helpful. :-) Going straight to the source, I find that RFC 7231 says: A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops). Note: An earlier version of this specification recommended a maximum of five redirections ([RFC2068], Section 10.3). Content developers need to be aware that some clients might implement such a fixed limitation. If it's good enough for HTTPBIS perhaps it's good enough for us, but even RFC 7231 only makes it a SHOULD (which I find slightly surprising). > —References: > > IDNits reports a few out-of-date references. The authors will update our I-D caches. Peter From nobody Mon Feb 23 14:10:32 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7051A00B7 for ; Mon, 23 Feb 2015 14:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRci02k4E7qK for ; Mon, 23 Feb 2015 14:10:29 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B231A0027 for ; Mon, 23 Feb 2015 14:10:29 -0800 (PST) Received: from [192.168.11.1] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1NMAC4U073682 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2015 16:10:22 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [192.168.11.1] From: "Ben Campbell" To: "Peter Saint-Andre - &yet" Date: Mon, 23 Feb 2015 16:10:12 -0600 Message-ID: <5CD6E0B8-CB86-472B-9A3B-9F89274DB2FF@nostrum.com> In-Reply-To: <54EBA26D.4080000@andyet.net> References: <9A67CFDB-5504-43E0-A63C-82E996A70620@nostrum.com> <54EBA26D.4080000@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate Trial (1.9r5060) Archived-At: Cc: draft-ietf-xmpp-posh.all@tools.ietf.org, XMPP Working Group Subject: Re: [xmpp] PROTO review of draft-ietf-xmpp-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, 23 Feb 2015 22:10:30 -0000 Hi Peter, further comments below. I removed sections that do not seem to need further discussion. On 23 Feb 2015, at 15:58, Peter Saint-Andre - &yet wrote: [...] >> >> — Material Comment: IANA Considerations >> >> These seems a bit unusual, since we are registering a “fragment” >> that >> other protocols will use to register actual URIs. This does not seem >> to >> have been contemplated by RFC5785. This also the side effect of >> establishing rules for certain entries in the well-known URI registry >> over and above those from RFC5785. >> >> Does it make sense to actually register the prefix itself, since >> it’s >> not really a URI? It would seem reasonable to leave the actual >> registration to protocols that need to register posh URIs. > > You make a very good point. I think you're right that it makes more > sense for the POSH spec to provide instructions to protocols that need > to register POSH URIs - as, for instance, draft-ietf-xmpp-dna does - > but not to register a URI prefix (instead, just say "please use the > prefix"). So if I understand the implications of this path, it would mean we give guidance that any protocol that uses posh should register a “posh.*” URL. (I note that the well-known URI registry uses the specification required policy. Is that adequate for POSH use?). But this doc would not register anything. Would that guidance still go in the IANA considerations section? I suspect the answer is probably not. Also, does anything implode if some protocol chooses not to use the POSH prefix? Do we actually care? I assume we don’t expect developers to try to guess well-known URIs. > >> I see Mark Nottingham is the expert for the well-known URI registry. >> By >> any chance has anyone run this by him? > > I have a vague recollection of having talked with him about it once, > but I can find no evidence of that in my email folders. If we agree > that what you suggest is the best approach, then I think it makes > sense to update the document before reaching out to him (and in fact > that might not be necessary since this document wouldn't be doing > anything unusual). I agree that if we don’t register anything, and don’t try to change the well-known URI registration policy for posh purposes, it might not be necessary to involve Mark. (But for the record, if he were okay with the way things are currently documented, I would back off on this point.) [...] From nobody Mon Feb 23 14:19:52 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AC71A01A8 for ; Mon, 23 Feb 2015 14:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YNyvJNUYaYI for ; Mon, 23 Feb 2015 14:19:47 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688541A0199 for ; Mon, 23 Feb 2015 14:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3715; q=dns/txt; s=iport; t=1424729987; x=1425939587; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=29nQp7yG4wA0PWc362wDcYdLzGXRIMm8qqHBmnjg1W8=; b=i4M9YGtMQ4FMtQR+Tyx6EwlRLVRzV1mx2TSljMim/KJlL+hB4oAgyqfM DI5ubizNA7zgLCRcef4dJuGLNdEgij3XxJqGgDbGJXneyJSbLW4MV0Dpk l7SawUtY+nENStqe3hZz3MAHAaob+7SIOxJiljAonyrHSSAfHfcRVjd/A k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AzBQA5putU/5JdJa1VBoMGUloEgwTACYV4AoEjQwEBAQEBAXyEEAEBBCMPATgNARALGAICBRYLAgIJAwIBAgE1EAYBDAEFAgEBiCu6YZhFAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYlyhCsQMweCaIFDBYpKiGaFZYEbgxWCLoYIhk0iggEdgXBPgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,633,1418083200"; d="scan'208";a="126218561" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP; 23 Feb 2015 22:19:46 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t1NMJkQ6003007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Feb 2015 22:19:46 GMT Received: from [10.129.24.63] (10.129.24.63) by xhc-rcd-x06.cisco.com (173.37.183.80) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 23 Feb 2015 16:19:46 -0600 Message-ID: <54EBA781.5080401@cisco.com> Date: Mon, 23 Feb 2015 15:19:45 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell , Peter Saint-Andre - &yet References: <9A67CFDB-5504-43E0-A63C-82E996A70620@nostrum.com> <54EBA26D.4080000@andyet.net> <5CD6E0B8-CB86-472B-9A3B-9F89274DB2FF@nostrum.com> In-Reply-To: <5CD6E0B8-CB86-472B-9A3B-9F89274DB2FF@nostrum.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.63] Archived-At: Cc: draft-ietf-xmpp-posh.all@tools.ietf.org, XMPP Working Group Subject: Re: [xmpp] PROTO review of draft-ietf-xmpp-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, 23 Feb 2015 22:19:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2/23/15 3:10 PM, Ben Campbell wrote: > Hi Peter, further comments below. I removed sections that do not > seem to need further discussion. > > On 23 Feb 2015, at 15:58, Peter Saint-Andre - &yet wrote: > > [...] > >>> >>> — Material Comment: IANA Considerations >>> >>> These seems a bit unusual, since we are registering a >>> “fragment” that other protocols will use to register actual >>> URIs. This does not seem to have been contemplated by RFC5785. >>> This also the side effect of establishing rules for certain >>> entries in the well-known URI registry over and above those >>> from RFC5785. >>> >>> Does it make sense to actually register the prefix itself, >>> since it’s not really a URI? It would seem reasonable to leave >>> the actual registration to protocols that need to register posh >>> URIs. >> >> You make a very good point. I think you're right that it makes >> more sense for the POSH spec to provide instructions to protocols >> that need to register POSH URIs - as, for instance, >> draft-ietf-xmpp-dna does - but not to register a URI prefix >> (instead, just say "please use the prefix"). > > So if I understand the implications of this path, it would mean we > give guidance that any protocol that uses posh should register a > “posh.*” URL. (I note that the well-known URI registry uses the > specification required policy. Is that adequate for POSH use?). But > this doc would not register anything. Would that guidance still go > in the IANA considerations section? I suspect the answer is > probably not. > > Also, does anything implode if some protocol chooses not to use the > POSH prefix? Do we actually care? I assume we don’t expect > developers to try to guess well-known URIs. >> >>> I see Mark Nottingham is the expert for the well-known URI >>> registry. By any chance has anyone run this by him? >> >> I have a vague recollection of having talked with him about it >> once, but I can find no evidence of that in my email folders. If >> we agree that what you suggest is the best approach, then I think >> it makes sense to update the document before reaching out to him >> (and in fact that might not be necessary since this document >> wouldn't be doing anything unusual). > > I agree that if we don’t register anything, and don’t try to change > the well-known URI registration policy for posh purposes, it might > not be necessary to involve Mark. (But for the record, if he were > okay with the way things are currently documented, I would back off > on this point.) > I also recall discussing it with Mark, but I can't find any documentation to back that up either. As I recall, the intent was to constrain the crazy stuff future people might do in the .well-known namespace. I'd rather change this to guidance on how to register an app-specific POSH URI, than try to do something new-ish with the existing IANA tables. The authors will discuss it and come up with a proposed change. - -- - - 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 iQEcBAEBCgAGBQJU66eBAAoJEDWi+S0W7cO1J/wIAIvDJFiiq/dE7HsnilGX0kDz o5jqXm9xVXm4HatqRHmyeixswU+5qLe5B2XNARoRcXMAfm2Ep/IpVd2aYwqVveAx QU0xGmz7EOZXK8CI5oC9wFCP1e4ZEEli8U4XmmnQAS13jVvE/uTjXEjLJmrEezB1 f/SN8reQGmNpeU9HgX8nqdqVR90poIIF3c13baeDRXP49tDa1h93NsdB80N7AF6U QJr3rTkcwNjNYZkltWNWnmsbI+BOktHavTJBZpnsTsGaWNP+bJSS9KrxO7EVMcp5 b8r6fbetSGwTigSnuxGhY/nnvffkvV4SdjlOndx7yz4yMTDa1PNkceL2OH9O2eg= =cfbb -----END PGP SIGNATURE----- From nobody Mon Feb 23 14:32:05 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3281A039D for ; Mon, 23 Feb 2015 14:32:03 -0800 (PST) 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 W9cDKLlDOZk3 for ; Mon, 23 Feb 2015 14:32:00 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE731A034C for ; Mon, 23 Feb 2015 14:32:00 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so22175404igb.3 for ; Mon, 23 Feb 2015 14:31:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NnbiagSuB1CpsEuAPMUU9JHIsz0TtOlPztXZdqgJfMs=; b=Nf7oBy2hSKTrBSbDFjtctHKyRLQYsf0GFzLR6ICQiIxg1/k09+gBw0OfJdxVdUXfwj 6xriRJw9T5QOh2hvhZnok2d0VWHYqhZ+V6JBYjuHRenYJvvvqZurvljqrAGGONy5Hg3V vR+GWWMDckOHmOMt5UZL+KbXyb0vASjXbw3TWSq22lu2Y2EzmhgekRVqQALKAHYpQIzB MX5OdOHTgSQQyUDWXyCpPdZa9zmGzcprnF3j7ASsiRecBR47w0Fb+8DfdMkGxlx2beDR nH8nnOkdEzfDPzYQ5gVdxOO36BtKRombHonZ0dSbfYqWRQ9CKnZv29nWqf+rJjQGKjWP NWWw== X-Gm-Message-State: ALoCoQkZAQQxCagEdQQnPkK0kWFbLFogBQOLBALlZPvPF5Lkf9SdaSYGhIUwqDEvbVgWih3btnwm X-Received: by 10.50.66.243 with SMTP id i19mr16266972igt.7.1424730719604; Mon, 23 Feb 2015 14:31:59 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id a9sm3887564ioa.23.2015.02.23.14.31.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 14:31:58 -0800 (PST) Message-ID: <54EBAA5C.508@andyet.net> Date: Mon, 23 Feb 2015 15:31:56 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell References: <9A67CFDB-5504-43E0-A63C-82E996A70620@nostrum.com> <54EBA26D.4080000@andyet.net> <5CD6E0B8-CB86-472B-9A3B-9F89274DB2FF@nostrum.com> In-Reply-To: <5CD6E0B8-CB86-472B-9A3B-9F89274DB2FF@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-xmpp-posh.all@tools.ietf.org, XMPP Working Group Subject: Re: [xmpp] PROTO review of draft-ietf-xmpp-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, 23 Feb 2015 22:32:03 -0000 On 2/23/15 3:10 PM, Ben Campbell wrote: > Hi Peter, further comments below. I removed sections that do not seem to > need further discussion. > > On 23 Feb 2015, at 15:58, Peter Saint-Andre - &yet wrote: > > [...] > >>> >>> — Material Comment: IANA Considerations >>> >>> These seems a bit unusual, since we are registering a “fragment” that >>> other protocols will use to register actual URIs. This does not seem to >>> have been contemplated by RFC5785. This also the side effect of >>> establishing rules for certain entries in the well-known URI registry >>> over and above those from RFC5785. >>> >>> Does it make sense to actually register the prefix itself, since it’s >>> not really a URI? It would seem reasonable to leave the actual >>> registration to protocols that need to register posh URIs. >> >> You make a very good point. I think you're right that it makes more >> sense for the POSH spec to provide instructions to protocols that need >> to register POSH URIs - as, for instance, draft-ietf-xmpp-dna does - >> but not to register a URI prefix (instead, just say "please use the >> prefix"). > > So if I understand the implications of this path, it would mean we give > guidance that any protocol that uses posh should register a “posh.*” > URL. Yes but that's really just for a friendly consistency. Matt and I chatted about it over IM and we both recalled that we were trying to prevent crazy registrations in .well-known (this was around the time that Mark Nottingham was starting to work on the evocatively named draft-nottingham-uri-get-off-my-lawn, now RFC 7320). > (I note that the well-known URI registry uses the specification > required policy. Is that adequate for POSH use?). I think so. Over time we've tried to become more liberal about IANA registrations policies. > But this doc would not > register anything. Correct. > Would that guidance still go in the IANA > considerations section? I suspect the answer is probably not. It would go in another section since we wouldn't be registering anything, nor would we be providing actionable guidance to IANA. > Also, does anything implode if some protocol chooses not to use the POSH > prefix? No imminent implosions to worry about. > Do we actually care? Not much, although as I said it provides a friendly consistency. > I assume we don’t expect developers to try > to guess well-known URIs. That's true. >>> I see Mark Nottingham is the expert for the well-known URI registry. By >>> any chance has anyone run this by him? >> >> I have a vague recollection of having talked with him about it once, >> but I can find no evidence of that in my email folders. If we agree >> that what you suggest is the best approach, then I think it makes >> sense to update the document before reaching out to him (and in fact >> that might not be necessary since this document wouldn't be doing >> anything unusual). > > I agree that if we don’t register anything, and don’t try to change the > well-known URI registration policy for posh purposes, it might not be > necessary to involve Mark. (But for the record, if he were okay with the > way things are currently documented, I would back off on this point.) Well, I think the way things are currently documented is misguided, so we might as well correct it. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Feb 23 14:53:15 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731AB1A0262 for ; Mon, 23 Feb 2015 14:53:13 -0800 (PST) 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 ufWckCI6dS2Q for ; Mon, 23 Feb 2015 14:53:11 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0773E1A0235 for ; Mon, 23 Feb 2015 14:53:11 -0800 (PST) Received: by iecvy18 with SMTP id vy18so27409733iec.13 for ; Mon, 23 Feb 2015 14:53:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6eg01lW2gmNlgThoiLF0h+7FJyaBDBSZ9v5PjTtSqWs=; b=ZOMliNX/WgM6p9z+Pnq7AadjZ8G1K5ekhtpbBvgdfVw/7d0WP5aTPXKTcby5/lwA33 r2I7mBlXF/Uuj9gaIEnFxx1bIInqNR8jGp613hNif3zWh10osZcsfu29YRK4EJv7781T pQFqDQt/RDUPLEKqHyRbQ1pvky0rPq7m5bDOv4ni2lIye1gty7LiOYnz91LZ3g9JVV// pNkhQMcMDHx5RlkSgNEcrTntOkV8UZ7/9KDKctHPtyjbM1qLQ2E0E/8oYJEaXpqU1TgM jnbFwdycuMkGzhtWJXvonYMjyzCyp3OTxnxqj8Y73vbX9TQm2PhSL5ptMcDLve06twYO nRAg== X-Gm-Message-State: ALoCoQmt5e/1r3BJHxCgQS1WD+jUHjvzm5sy0qx1IVgthaPOoYEq2xM0lIZDQjdlcA69icxPAPzN X-Received: by 10.107.136.26 with SMTP id k26mr15760819iod.26.1424731990469; Mon, 23 Feb 2015 14:53:10 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id k2sm4112925iod.13.2015.02.23.14.53.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 14:53:09 -0800 (PST) Message-ID: <54EBAF53.9020904@andyet.net> Date: Mon, 23 Feb 2015 15:53:07 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell References: <9A67CFDB-5504-43E0-A63C-82E996A70620@nostrum.com> <54EBA26D.4080000@andyet.net> <5CD6E0B8-CB86-472B-9A3B-9F89274DB2FF@nostrum.com> <54EBAA5C.508@andyet.net> In-Reply-To: <54EBAA5C.508@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-xmpp-posh.all@tools.ietf.org, XMPP Working Group Subject: Re: [xmpp] PROTO review of draft-ietf-xmpp-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, 23 Feb 2015 22:53:13 -0000 On 2/23/15 3:31 PM, Peter Saint-Andre - &yet wrote: > On 2/23/15 3:10 PM, Ben Campbell wrote: >> Hi Peter, further comments below. I removed sections that do not seem to >> need further discussion. >> >> On 23 Feb 2015, at 15:58, Peter Saint-Andre - &yet wrote: >> >> [...] >> >>>> >>>> — Material Comment: IANA Considerations >>>> >>>> These seems a bit unusual, since we are registering a “fragment” that >>>> other protocols will use to register actual URIs. This does not >>>> seem to >>>> have been contemplated by RFC5785. This also the side effect of >>>> establishing rules for certain entries in the well-known URI registry >>>> over and above those from RFC5785. >>>> >>>> Does it make sense to actually register the prefix itself, since it’s >>>> not really a URI? It would seem reasonable to leave the actual >>>> registration to protocols that need to register posh URIs. >>> >>> You make a very good point. I think you're right that it makes more >>> sense for the POSH spec to provide instructions to protocols that need >>> to register POSH URIs - as, for instance, draft-ietf-xmpp-dna does - >>> but not to register a URI prefix (instead, just say "please use the >>> prefix"). >> >> So if I understand the implications of this path, it would mean we give >> guidance that any protocol that uses posh should register a “posh.*” >> URL. > > Yes but that's really just for a friendly consistency. > > Matt and I chatted about it over IM and we both recalled that we were > trying to prevent crazy registrations in .well-known (this was around > the time that Mark Nottingham was starting to work on the evocatively > named draft-nottingham-uri-get-off-my-lawn, now RFC 7320). > >> (I note that the well-known URI registry uses the specification >> required policy. Is that adequate for POSH use?). > > I think so. Over time we've tried to become more liberal about IANA > registrations policies. > >> But this doc would not >> register anything. > > Correct. > >> Would that guidance still go in the IANA >> considerations section? I suspect the answer is probably not. > > It would go in another section since we wouldn't be registering > anything, nor would we be providing actionable guidance to IANA. > >> Also, does anything implode if some protocol chooses not to use the POSH >> prefix? > > No imminent implosions to worry about. > >> Do we actually care? > > Not much, although as I said it provides a friendly consistency. > >> I assume we don’t expect developers to try >> to guess well-known URIs. > > That's true. > >>>> I see Mark Nottingham is the expert for the well-known URI registry. By >>>> any chance has anyone run this by him? >>> >>> I have a vague recollection of having talked with him about it once, >>> but I can find no evidence of that in my email folders. If we agree >>> that what you suggest is the best approach, then I think it makes >>> sense to update the document before reaching out to him (and in fact >>> that might not be necessary since this document wouldn't be doing >>> anything unusual). >> >> I agree that if we don’t register anything, and don’t try to change the >> well-known URI registration policy for posh purposes, it might not be >> necessary to involve Mark. (But for the record, if he were okay with the >> way things are currently documented, I would back off on this point.) > > Well, I think the way things are currently documented is misguided, so > we might as well correct it. Here is proposed text: ### 8. Guidelines for Protocols that Use POSH Protocols that use POSH will need to register well-known URIs wth the IANA in accordance with [RFC5785] (the IANA registration policy [RFC5226] for well-known URIs is Specification Required). For the sake of consistency, it would be best if the URIs registered by such protocols match the URI template [RFC6570] path "/.well-known /posh.{servicedesc}.json"; that is, begin with "posh." and end with ".json" (indicating a media type of application/json [RFC7159]). For POSH-using protocols that rely on DNS SRV records [RFC2782], it would be best if the "{servicedesc}" part of the well-known URI is "{service}.{proto}", where the "{service}" is the DNS SRV "Service" prepended by the underscore character "_" and the "{proto}" is the DNS SRV "Proto" also prepended by the underscore character "_". As an example, the well-known URI for XMPP server-to-server connections would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers a service name of "xmpp-server" and uses TCP as the underlying transport protocol. For other POSH-using protocols, the "{servicedesc}" part of the well- known URI can be any unique string or identifier for the protocol, which might be a service name registered with the IANA in accordance with [RFC6335] or which might be an unregistered name. As an example, the well-known URI for a hypothetical "SPICE" application could be "posh.spice.json". ### Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Feb 23 15:02:25 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C547E1A03E3 for ; Mon, 23 Feb 2015 15:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-c0kBw5-kSg for ; Mon, 23 Feb 2015 15:02:23 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A491B1A064C for ; Mon, 23 Feb 2015 15:02:22 -0800 (PST) Received: from [192.168.11.1] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1NN29uG078029 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2015 17:02:20 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [192.168.11.1] From: "Ben Campbell" To: "Peter Saint-Andre - &yet" Date: Mon, 23 Feb 2015 17:02:09 -0600 Message-ID: <1A0833CA-B0BB-4396-A98B-DBA4A479B23D@nostrum.com> In-Reply-To: <54EBAF53.9020904@andyet.net> References: <9A67CFDB-5504-43E0-A63C-82E996A70620@nostrum.com> <54EBA26D.4080000@andyet.net> <5CD6E0B8-CB86-472B-9A3B-9F89274DB2FF@nostrum.com> <54EBAA5C.508@andyet.net> <54EBAF53.9020904@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate Trial (1.9r5060) Archived-At: Cc: draft-ietf-xmpp-posh.all@tools.ietf.org, XMPP Working Group Subject: Re: [xmpp] PROTO review of draft-ietf-xmpp-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, 23 Feb 2015 23:02:24 -0000 On 23 Feb 2015, at 16:53, Peter Saint-Andre - &yet wrote: > Here is proposed text: > > ### > > 8. Guidelines for Protocols that Use POSH > > Protocols that use POSH will need to register well-known URIs wth the > IANA in accordance with [RFC5785] (the IANA registration policy > [RFC5226] for well-known URIs is Specification Required). > > For the sake of consistency, it would be best if the URIs registered > by such protocols match the URI template [RFC6570] path "/.well-known > /posh.{servicedesc}.json"; that is, begin with "posh." and end with > ".json" (indicating a media type of application/json [RFC7159]). > > For POSH-using protocols that rely on DNS SRV records [RFC2782], it > would be best if the "{servicedesc}" part of the well-known URI is > "{service}.{proto}", where the "{service}" is the DNS SRV "Service" > prepended by the underscore character "_" and the "{proto}" is the > DNS SRV "Proto" also prepended by the underscore character "_". As > an example, the well-known URI for XMPP server-to-server connections > would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers > a service name of "xmpp-server" and uses TCP as the underlying > transport protocol. > > For other POSH-using protocols, the "{servicedesc}" part of the well- > known URI can be any unique string or identifier for the protocol, > which might be a service name registered with the IANA in accordance > with [RFC6335] or which might be an unregistered name. As an > example, the well-known URI for a hypothetical "SPICE" application > could be "posh.spice.json". > > ### That works for me. I would also not complain if the “it would be best” lines were replaced with SHOULDs [1], but I’m also okay like it is. [1] based on the 2119 usage of normative text to avoid harm, even if it’s not needed for interoperability, said harm being the pollution of the well-known URI registry with “craziness.” From nobody Mon Feb 23 15:05:45 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2171A09C9; Mon, 23 Feb 2015 15:05:43 -0800 (PST) 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 cPDBmLzxOUgP; Mon, 23 Feb 2015 15:05:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE631A03E3; Mon, 23 Feb 2015 15:05:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223230542.16689.2371.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 15:05:42 -0800 Archived-At: Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-posh-04.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 23:05:43 -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-04.txt Pages : 15 Date : 2015-02-23 Abstract: Experience has shown that it is extremely difficult to deploy proper PKIX certificates for TLS in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications 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. While these methods developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols. 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-posh-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 23 15:09:00 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BC21A064C for ; Mon, 23 Feb 2015 15:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qfuzavUvoU7 for ; Mon, 23 Feb 2015 15:08:56 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30DC1A039D for ; Mon, 23 Feb 2015 15:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2811; q=dns/txt; s=iport; t=1424732937; x=1425942537; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=9p8N01pUbAR433ZYaYjTYxSHtq//LIEPUkIRWufab/Y=; b=mi833yfuMoumS1lIpljGFcAkAaMYR/w4BZZkg67Oah3eBtRDPxcWjDAX Baa54rO32VG6ZafEjg5/+04YMVz78G40jybqAkSpTg0Goq7yqkT7JXKVF LrNH9M7mZJvPdi+XeHuaYwsCezNWiW2Rp7DjrlILKlVmZxjGuvP1/SCYR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A0BQDysetU/4sNJK1RAQmDBlJVBQSDBMAHCoVwAoElQwEBAQEBAXyEEAEBBAEBASBLChELGAICBRYLAgIJAwIBAgEVMAYNBAICAQEFiCYIBbpNmFgBAQEBAQEBAwEBAQEBAQEbgSGJcoQSASg6FoJSgUMFikqDF4VPhWWBGziCXYIujFUiggEdgXAiLYFEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,634,1418083200"; d="scan'208";a="126225883" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP; 23 Feb 2015 23:08:57 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t1NN8tUT031958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Feb 2015 23:08:55 GMT Received: from [10.129.24.63] (10.129.24.63) by xhc-rcd-x06.cisco.com (173.37.183.80) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 23 Feb 2015 17:08:55 -0600 Message-ID: <54EBB307.1030403@cisco.com> Date: Mon, 23 Feb 2015 16:08:55 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: References: <20150223230542.16689.2371.idtracker@ietfa.amsl.com> In-Reply-To: <20150223230542.16689.2371.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.63] Archived-At: Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-posh-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, 23 Feb 2015 23:08:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This revision should address all of Ben's outstanding concerns. Thanks! - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 2/23/15 4:05 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-04.txt Pages : 15 Date : > 2015-02-23 > > Abstract: Experience has shown that it is extremely difficult to > deploy proper PKIX certificates for TLS in multi-tenanted > environments. As a result, domains hosted in such environments > often deploy applications 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. While these methods developed for use in > the Extensible Messaging and Presence Protocol (XMPP) as a Domain > Name Association (DNA) prooftype, they might also be usable in > other non-HTTP application protocols. > > > 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-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-posh-04 > > > 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU67MHAAoJEDWi+S0W7cO1x4cH/RkY1LsJdpc9t8DbaPNrLdTz 3nN1gjQQj8aJkoz7c9ZNRVsFStJlHBVoX5GidRmbl4ZnFY8OevSarzddrrITgArN C3dUQrqzhs2MRNsQfzFOmj7m0Mu+jlhStZjt8GDV/NnDFnR7dUHl6JrSek80KI6w cDtJvBbsskGGNb10XhbQaTRErjhyd7K/pDH+eerTcOHNlHchGUXhZ8MmENCjDrWO E1Mu8MwcEclG4ox6/zcr8Y158ZOU9Pi+VJWbzYa+rpv3Kbv1fSjjilZCJYIKEs1Q bzZtbLY6TZHwiZTbt0+4wCaXsO6EabAqMwJ+zGhBmWjO7Yse2XtfOFD2RAj4KlY= =QN87 -----END PGP SIGNATURE----- From nobody Wed Feb 25 11:59:31 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87301A1AA5 for ; Wed, 25 Feb 2015 11:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 I0ObBOEUyF-z for ; Wed, 25 Feb 2015 11:59:29 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2929C1A1B7F for ; Wed, 25 Feb 2015 11:59:29 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1PJx9CR006100 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2015 13:59:20 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "=?utf-8?q?=E2=8C=98?= Matt Miller" , "Peter Saint-Andre - &yet" Date: Wed, 25 Feb 2015 13:59:09 -0600 Message-ID: In-Reply-To: <54EBB307.1030403@cisco.com> References: <20150223230542.16689.2371.idtracker@ietfa.amsl.com> <54EBB307.1030403@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9r5066) Archived-At: Cc: xmpp@ietf.org Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-posh-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: Wed, 25 Feb 2015 19:59:30 -0000 I think this version looks good to go to the IESG. In my chair opinion, the changes in this version are not substantial enough to require a new WGLC (and have been published on the list.) Do the authors agree? It occurs to me to wonder if we should submit posh and DNA (currently in WGLC) together as a package, or submit them separately as they are ready. Thoughts? /Ben On 23 Feb 2015, at 17:08, ⌘ Matt Miller wrote: > This revision should address all of Ben's outstanding concerns. > > > Thanks! > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > On 2/23/15 4:05 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-04.txt Pages : 15 Date : >> 2015-02-23 >> >> Abstract: Experience has shown that it is extremely difficult to >> deploy proper PKIX certificates for TLS in multi-tenanted >> environments. As a result, domains hosted in such environments >> often deploy applications 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. While these methods developed for use in >> the Extensible Messaging and Presence Protocol (XMPP) as a Domain >> Name Association (DNA) prooftype, they might also be usable in >> other non-HTTP application protocols. >> >> >> 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-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-posh-04 >> >> >> 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 >> > > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From nobody Wed Feb 25 12:11:21 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1DC1A1AAD for ; Wed, 25 Feb 2015 12:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IIfWN8Q2xwj for ; Wed, 25 Feb 2015 12:11:19 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4561A1AB9 for ; Wed, 25 Feb 2015 12:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1289; q=dns/txt; s=iport; t=1424895079; x=1426104679; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=400LCg1X79wVFozoAyVAldAzSxdlNNk0bRFfnJlIJZI=; b=C86LpErVaEeP88Rr/blP2T7q4mkLlJQoWxG5WCi/0f+5SgoBtA6QqJHB veoZhDBbY7nL8kGUenPBwl1ikJMODiV4mtB0WsCUdh++hfxuIpu7zwCZq HSZtBfovODob5bJDVe7JhMl77rXd3JvfZNK2XIwlLNFRdT0bSEZkNkmLx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOBQD6Ku5U/5RdJa1bgwJSWgSDBcAShXgCgShDAQEBAQEBfIQPAQEBAwEjVQEFCwsYAgIFFgsCAgkDAgECATUQBgEMAQUCAQGIIwi8dpkrAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYlyhDszB4JogUMBBIpOgxuFU4VlhmSMWiKCAR2BcE+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,646,1418083200"; d="scan'208";a="399460635" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP; 25 Feb 2015 20:11:18 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t1PKBI4F016716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 20:11:18 GMT Received: from [10.24.154.9] (10.24.154.9) by xhc-rcd-x12.cisco.com (173.37.183.86) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 25 Feb 2015 14:11:17 -0600 Message-ID: <54EE2C64.3050907@cisco.com> Date: Wed, 25 Feb 2015 13:11:16 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ben Campbell , Peter Saint-Andre - &yet References: <20150223230542.16689.2371.idtracker@ietfa.amsl.com> <54EBB307.1030403@cisco.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.24.154.9] Archived-At: Cc: xmpp@ietf.org Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-posh-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: Wed, 25 Feb 2015 20:11:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2/25/15 12:59 PM, Ben Campbell wrote: > I think this version looks good to go to the IESG. > > In my chair opinion, the changes in this version are not > substantial enough to require a new WGLC (and have been published > on the list.) Do the authors agree? > I agree. > It occurs to me to wonder if we should submit posh and DNA > (currently in WGLC) together as a package, or submit them > separately as they are ready. Thoughts? > Personally, I think it's fine to submit POSH before DNA. DNA has normative dependencies on POSH, but not the reverse. What does our AD think? - -- - - 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 iQEcBAEBCgAGBQJU7ixkAAoJEDWi+S0W7cO1ZX4IAKFU7UOehhUTZcEOkXCieHfK K8RJYhvmwjE2bMtLpQ+DQumkBHZDg0jcIVGdqyqNaSurArORcs4XAvxAVD6bNs/6 CXhjExXKG+kcIt8lxFWo7SsoJMNOzTFfSKV6dVkqrGx7Kr6XBZTmTd4udV2WI8ad x9uqxwaUlrMfm4wk7iAXr5tAV/D6iIBZ0p9oO/htBgwtlwmWwol27tJtq/CvMP4G UHZ+Ca3cX0Ai+IxZJmfAO1cESDTCCHEwIBuqB/9HOWTtV+2MQGCDsx6wcmGRKzKu ncqF25zlhEwk0LbIBsI+s1Fx3muMw9uyA6+X+AOx9A/BFrq9URyHWLUvDvxMwzo= =W662 -----END PGP SIGNATURE----- From nobody Thu Feb 26 18:17:41 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71741A6F5D; Thu, 26 Feb 2015 18:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzq3dvbxkUaC; Thu, 26 Feb 2015 18:17:38 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96DF41A6F87; Thu, 26 Feb 2015 18:17:38 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1R2HHZu007410 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2015 20:17:27 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "XMPP Group" , precis@ietf.org Date: Thu, 26 Feb 2015 20:17:17 -0600 Message-ID: <98C92FA8-F99C-4861-9199-7B0443506574@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Cc: Marc Blanchet Subject: [xmpp] Cross-WG WGLC of draft-ietf-xmpp-6122bis-18 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 02:17:39 -0000 (Cross-posted to XMPP and PRECIS) Hi, This is a XMPP working group last call for draft-ietf-xmpp-6122bis-18. Since this draft includes a profile of the PRECIS framework, we are cross-posting the WGLC to PRECIS. https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ We actually did a WGLC on this about a year ago, but much has changed since then. Please send comments to the authors and both lists by March 12, 2015. If you've read the draft and consider it ready to go, please send comments to that effect. Thanks! Ben. From nobody Thu Feb 26 20:50:50 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B60C1A00B6 for ; Thu, 26 Feb 2015 20:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd2-FXnAoSV4 for ; Thu, 26 Feb 2015 20:50:46 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5221A0004 for ; Thu, 26 Feb 2015 20:50:46 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t1R4oZoW019368 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2015 22:50:46 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "XMPP Working Group" Date: Thu, 26 Feb 2015 22:50:35 -0600 Message-ID: <4B5EFD87-50AD-4BC3-9ADA-57776C96FC2A@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5066) Archived-At: Cc: draft-ietf-xmpp-dna.all@tools.ietf.org Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-dna-09 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 04:50:48 -0000 Hi everyone, We are half way through the WGLC on draft-ietf-xmpp-dna-09, and I haven't seen any comments. Please keep in mind that our area directors may interpret the lack of comments as a lack of interest. Even comments of the form of "I've read this and it's ready to go" are useful. Thanks! Ben. On 20 Feb 2015, at 15:36, Ben Campbell wrote: > This is an XMPP Working Group Last Call of draft-ietf-xmpp-dna-09. The > draft is available at the following URL > > https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ > > The WGLC will conclude on March 6, 2015. Please send your comments to > the authors and the XMPP mailing list. > > (Given that the draft deadline for IETF92 is the following Monday, I > suspect the authors would really appreciate people not waiting till > the last minute to send feedback.) > > Thanks! > > Ben. > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp