Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT)
⌘ Matt Miller <mamille2@cisco.com> Tue, 01 September 2015 17:16 UTC
Return-Path: <mamille2@cisco.com>
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 D49711B5A5A; Tue, 1 Sep 2015 10:16:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.201
X-Spam-Level:
X-Spam-Status: No, score=-14.201 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_FILL_THIS_FORM_SHORT=0.01, 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 G3G-eNbWngT8; Tue, 1 Sep 2015 10:16:19 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF561B59BE; Tue, 1 Sep 2015 10:16:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8300; q=dns/txt; s=iport; t=1441127779; x=1442337379; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yT39SgfmIAiCrfLuXCoQglxIIEWEtCeN142nVWFx26s=; b=hFfRcnibpJfVZksD77rLdB2K9t2E3gA0U0x02ihOXB9ovsY9uebe/KAk lG2rEA55t+B/08WNSm2olExcoKwqayGHrxxCqHRdqSVJh5GKA/p8rGU4Y 4LFwVmj2fEiO5D5prGmQ+WGtw9EMYN94SCAE1IbUo9bTr8R+P18xMQoBz A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0APAwAj3eVV/5JdJa1UCRMBAYMGVGmDI7sLAQmBd4V7AoFEOBQBAQEBAQEBgQqEJAEBBCMPATgDCgEQCxgCAgUQBgsCAgkDAgECAUUGAQwBBQIBAYgqDbR9lQYBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEiiUmBBYQvERgzB4JpgUMBBIU1hzp1h12FB4U9gjGIeJF0JoIOHRaBXR8zZwUbgUYBAQE
X-IronPort-AV: E=Sophos;i="5.17,450,1437436800"; d="scan'208";a="184032643"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP; 01 Sep 2015 17:15:59 +0000
Received: from [10.129.24.52] ([10.129.24.52]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t81HFtqg028306; Tue, 1 Sep 2015 17:15:55 GMT
Message-ID: <55E5DD49.6010505@cisco.com>
Date: Tue, 01 Sep 2015 11:15:53 -0600
From: ⌘ Matt Miller <mamille2@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet <peter@andyet.net>, Barry Leiba <barryleiba@computer.org>
References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <CALaySJ+k6Pt6b6UvhKNYgsk+=nMRfiSocd_T8aatRvLq4Vg+-w@mail.gmail.com> <55BBA4C1.6040404@andyet.net> <CALaySJLWDfRuCdziHSKqPFJ136d3O45Z7JDnYzDfQEZsKUsfdA@mail.gmail.com> <55CA9A10.2080603@andyet.net> <C4930219-3403-4782-869B-2348A7BFBEEB@nostrum.com> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> <55DBAE21.3020408@cisco.com> <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> <55DD249A.4080109@andyet.net> <55DFE8C4.7090707@andyet.net> <CALaySJJJP3xNPCW2t5XvN3_W5Rv3jsybiqYme+mhP0+oy7uEqA@mail.gmail.com> <55E066D0.3020109@andyet.net>
In-Reply-To: <55E066D0.3020109@andyet.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/iDIG4pg0Y93MqjvO_Aewi553Qb4>
Cc: Ben Campbell <ben@nostrum.com>, draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT)
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2015 17:16:22 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Peter and I just posted -05 which should address all the outstanding issues, and creates the POSH Service Names registry with IANA: < https://tools.ietf.org/html/draft-ietf-xmpp-posh-05 > To answer Barry's questions: 1) I can act as one of the designated experts for the POSH Service Names registry. 2) I have objections for the POSH Service Names registry requiring Expert Review or IETF Review (and is reflected in -05) - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 8/28/15 7:49 AM, Peter Saint-Andre - &yet wrote: > On 8/28/15 6:05 AM, Barry Leiba wrote: >>>> 1. Recommend URIs like >>>> https://example.com/.well-known/posh/spice.json >>>> >>>> 2. In draft-ietf-xmpp-posh, register "posh" in the well-known >>>> URIs registry >>>> >>>> 3. In draft-ietf-xmpp-posh, set up a registry for POSH >>>> protocols >>>> >>>> 4. In draft-ietf-xmpp-dna, register "xmpp-client" and >>>> "xmpp-server" in the POSH registry >>>> >>>> I offered to Matt that I can propose text for the IANA >>>> considerations sections since I've written such text before. >>>> I'll endeavor to draft something in the next few days. >>> >>> Here is proposed text for draft-ietf-xmpp-posh... >> >> Thanks, Peter; this looks good. Two questions, inline. >> >>> 9. IANA Considerations >>> >>> 9.1. Well-Known URI >>> >>> This specification registers "posh" in the Well-Known URI >>> Registry as defined by [RFC5785]. The completed template >>> follows. >>> >>> URI suffix: posh >>> >>> Change controller: IETF >>> >>> Specification: [[ this document ]] >>> >>> Related information: The suffix "posh" is expected to be >>> followed by an additional path component consisting of a >>> service name (say, "spice") and a file extension of ".json", >>> resulting in a full path of, for instance, >>> "/.well-known/posh/spice.json". Registration of service names >>> shall be requested by developers of the relevant application >>> protocols. >>> >>> 9.2. POSH Service Names >>> >>> This document establishes a registry for POSH service names. >> >> It would help IANA if you suggested where to put the registry (in >> an existing group of registries, or in its own, new top-level >> group). > > Ah, I thought that was up to the IANA. Given that POSH service > names are used an additional path component in well-known URIs, > placing this registry in the Uniform Resource Identifier (URI) > Schemes registry would make sense. > >>> POSH service names are registered on the advice of one or more >>> Designated Experts (appointed by the IESG or their delegate). >>> An IANA registration policy [RFC5226] of Expert Review was >>> chosen instead of the more liberal First Come First Served to >>> help ensure that POSH is used in appropriate ways within >>> applications. >> >> Thanks for that explanation; it helps. >> >> 1. Are Peter Saint-Andre and Matt Miller willing and able to act >> as the designated experts? If so, I'll put that in for IESG >> approval. > > I can serve in that capacity. > >> 2. Do you want expert review to also apply to IETF documents >> (such as xmpp-dna, which would then need expert review before >> final approval)? If not, you could use "Expert Review OR IETF >> Review", or "Expert Review OR Standards Action". > > I think "Expert Review OR IETF Review" would be fine but I'm not > sure what Matt thinks. > >> 3. It would be good to have a short paragraph or a pointer to >> other text that gives some guidance of what "used in appropriate >> ways" means, so the DEs (should we eventually put in someone >> other than the authors) know what not to accept. > > Matt and I will try to formulate some text. We had some more > specific text but it wasn't quite right. The basic idea is that we > don't want folks to be using POSH when other technologies are a > better fit. The example we had was DNS SRV but that wasn't correct > since the two are complementary. > >>> Registration requests are to be sent to the posh@ietf.org >>> mailing list for review and comment, with an appropriate >>> subject (e.g., "Request for POSH service name: example"). >>> >>> Before a period of 14 days has passed, the Designated Expert(s) >>> will either approve or deny the registration request, >>> communicating this decision both to the review list and to >>> IANA. Denials should include an explanation and, if >>> applicable, suggestions as to how to make the request >>> successful. Registration requests that are undetermined for a >>> period longer than 21 days can be brought to the IESG's >>> attention (using the iesg@iesg.org mailing list) for >>> resolution. >>> >>> 9.2.1. Registration Template >>> >>> Service name: The name requested, relative to >>> "/.well-known/posh/"; e.g., a service name of "example" would >>> result in a well-known URI such as >>> "https://example.com/.well-known/posh/example.json". >>> >>> Change controller: For Standards-Track RFCs, state "IETF". In >>> all other cases, give the name of the responsible party. >>> Other details (e.g., postal address, e-mail address, home page >>> URI) may also be included. >> >> Is there a reason not to make e-mail address mandatory? IANA >> ought to have a recorded contact point. > > True. I think that's better. > >>> Definition and usage: A brief description that defines the >>> service name and mentions where and how it is used (e.g., in >>> the context of a particular application protocol). >>> >>> Specification: Optionally, reference to a document that >>> specifies the service or application protocol that uses the >>> service name, preferably including a URI that can be used to >>> retrieve a copy of the document. An indication of the relevant >>> sections may also be included, but is not required. >>> >>> ### >>> >>> And we would need to make associated changes in >>> draft-ietf-xmpp-dna, such as... >>> >>> ### >>> >>> 9. IANA Considerations >>> >>> The POSH specification [I-D.ietf-xmpp-posh] establishes a >>> registry for POSH service names to be used in well-known URIs >>> [RFC5785]. This specification registers two such URIs for use >>> in XMPP: "xmpp-client" and "xmpp-server". The completed >>> registration templates follow. >>> >>> 9.1. POSH Service Name for xmpp-client Service >>> >>> POSH service name: xmpp-client >> >> This should probably match the template in the other document, >> so either change this to "Service name" or change the template to >> "POSH service name". > > Correct. > >>> Change controller: IETF >>> >>> Definition and usage: Specifies the location of a POSH file >>> containing verification material or a reference thereto that >>> enables a client to verify the identity of a server for a >>> client-to-server stream in XMPP >>> >>> Specification: [[ this document ]] >>> >>> 9.2. POSH Service Name for xmpp-server Service >>> >>> POSH service name: xmpp-server >>> >>> Change controller: IETF >>> >>> Definition and usage: Specifies the location of a POSH file >>> containing verification material or a reference thereto that >>> enables a server to verify the identity of a peer server for a >>> server-to- server stream in XMPP >>> >>> Specification: [[ this document ]] >>> >>> ### >>> >>> Matt and I have checked this approach with a few implementers >>> and potential implementers; no one has objected yet, but if >>> folks on the xmpp@ietf.org list or elsewhere have significant >>> concerns it would be great to hear from you. :-) >> >> Barry > > Thanks for the review! > > Peter > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJV5d1JAAoJEDWi+S0W7cO1AvkH/iHJmElKZ5XuMLx267EmBmEL 115VGo5KZX7hVtMc4SfDRhTpywK5Y6lTPEHF++RQFyaARaNMacSMo4ZrLQfy66AK lo8I3ZmLeAWzDZ328EO1u/mHv7wFZnBwSDO3+8bQciTCn2y2qyDxKO8FgwbmMs2n SE24M2xmrMOyGWRIySORw8orLBkqCl0JxgirjGOY2A6OtV/eaDSUTM4TdzzpfbKJ 5K5mrrr80ilzPq7xN85a85u84U5CXCmvNVW1UuaT40htTCPOXLENuYgu7A1kzA1G IC6OLru4bWPALvsDzcVxY3TRq4hl9OGNV6teqb7FmlTc4e4uJ3hZBKQBuGWJT4M= =CuZv -----END PGP SIGNATURE-----
- [xmpp] Barry Leiba's No Objection on draft-ietf-x… Barry Leiba
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Peter Saint-Andre - &yet
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Barry Leiba
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Ben Campbell
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Peter Saint-Andre - &yet
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Barry Leiba
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Peter Saint-Andre - &yet
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Peter Saint-Andre
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Mark Nottingham
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Peter Saint-Andre - &yet
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Barry Leiba
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Ben Campbell
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Peter Saint-Andre - &yet
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Ben Campbell
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… ⌘ Matt Miller
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Ben Campbell
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Peter Saint-Andre - &yet
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Peter Saint-Andre - &yet
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Barry Leiba
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Peter Saint-Andre - &yet
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Ben Campbell
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Barry Leiba
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Ben Campbell
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Barry Leiba
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Ben Campbell
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Barry Leiba
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… ⌘ Matt Miller
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… Ben Campbell
- Re: [xmpp] Barry Leiba's No Objection on draft-ie… ⌘ Matt Miller