Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT)

Peter Saint-Andre - &yet <> Fri, 28 August 2015 04:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6B2711B3D5D for <>; Thu, 27 Aug 2015 21:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.291
X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0VjECEjzLE4q for <>; Thu, 27 Aug 2015 21:51:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3C4B1B3D5C for <>; Thu, 27 Aug 2015 21:51:19 -0700 (PDT)
Received: by pacdd16 with SMTP id dd16so49276202pac.2 for <>; Thu, 27 Aug 2015 21:51:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Wg6NQY62YabX2wGun2MjF4kkuRTW1eL7e3piXJ66dQI=; b=E8Grvp/ilYWmu5rGvu0cfc2+76Rz0H5E+5OzDWqwbhCszUw3o3PkIPTQVLm4ok7hMb A1nIKvcvf1fgfiRVaNXxQaawIDs9ay7qbZYHJ0R/G6zELZjup0ea7S/hyZp920qD/SCi N1ExPywhzKCPWu0KQi53AoJlwd9Tu+c9CLin4uvv8/TqnNSf9etTXfOVuLDlwHY8OLTx fb0aoKuKxBrcA99Q2sWJTgk+nlHsuR3IhNkPj/WMIS6DuZ3brTh1RwmJYSGiEA37+U+2 4uMKPHt1DmqwH3Zg5PWSt5fk6AqeuZdSKPYoXgRrMEJKdXt+uok86qv3P6P93RbEoJGl Xq6Q==
X-Gm-Message-State: ALoCoQnxIcCuDOqYmZDO+9PE+C4NSulz7AOYEK5DfvuzVwW2brShdZNRtpL9WRM+NPUaNvreuHxv
X-Received: by with SMTP id b5mr11768452pas.81.1440737479054; Thu, 27 Aug 2015 21:51:19 -0700 (PDT)
Received: from aither.local ( []) by with ESMTPSA id oq3sm4153297pdb.75.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Aug 2015 21:51:18 -0700 (PDT)
To: Ben Campbell <>, ⌘ Matt Miller <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Peter Saint-Andre - &yet <>
Message-ID: <>
Date: Thu, 27 Aug 2015 21:51:16 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc:,,,, Barry Leiba <>,, The IESG <>
Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT)
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, 28 Aug 2015 04:51:22 -0000

On 8/25/15 7:29 PM, Peter Saint-Andre - &yet wrote:
> On 8/24/15 7:07 PM, Ben Campbell wrote:
>> On 24 Aug 2015, at 18:52, ⌘ Matt Miller wrote:
>>>> Hi,
>>>> Any updates?
>>>> Thanks!
>>>> Ben.
>>> Peter and I have reached out to a number of implementers.  No one
>>> we've talked to objects to changing the URI.  We still need to make
>>> the appropriate changes to POSH and DNA; we are meeting later this
>>> week to work out those details.
>> Thanks!
> Right, I think we need to do the following:
> 1. Recommend URIs like
> 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...


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.

    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.

    Registration requests are to be sent to the 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 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 "".

    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.

    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

    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 list or elsewhere have significant concerns it would be 
great to hear from you. :-)



Peter Saint-Andre