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-----