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

Peter Saint-Andre - &yet <> Fri, 28 August 2015 13:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E62A41ACEB6 for <>; Fri, 28 Aug 2015 06:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 A_z7KwRzLE-V for <>; Fri, 28 Aug 2015 06:49:10 -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 D0C261AC3E1 for <>; Fri, 28 Aug 2015 06:49:07 -0700 (PDT)
Received: by padfo6 with SMTP id fo6so25104545pad.0 for <>; Fri, 28 Aug 2015 06:49:07 -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=9CEUzuajDk5nJtXBtUVM+s6L8lAfj6SVFV59rxzdk1w=; b=VewVw8oOz1xSfkgerZc54Nysh6QIDTcPpMlFm7N5BgolIt53+IIX+GeVqvuUkGffkK rH/A7T9LwNeWXc+pKfl/yfdG+cKfedPJ5FEjntijNqK6GlhpTcVi39JENV1hW6y7aHdY E7uV4ogMWld4RXIS7H5R29om4fgZHZoE2OlbkE/q8CxOnae0NelcjtPQi27rokDZRA0O szbxf/83ak0xB/hByQxEEIV1Fgve6zc7BWrbV6FpUIvXC15bRzAsk7kc7coMDHG5mhuz T74kHVliWf6rUE7Y2WAVH9xI5o5HDMRDd0zA4fsXDgglP2qqdRvJ18OXTe+yEibPqAPz H91g==
X-Gm-Message-State: ALoCoQmSt5KC9VQkW1Aovecr032ebPwipn2EjRK/8nHST2A8vcBwHyQ2r0J0mcqsF/DbvQwxH5YK
X-Received: by with SMTP id ex1mr15165184pbc.75.1440769747447; Fri, 28 Aug 2015 06:49:07 -0700 (PDT)
Received: from aither.local ( []) by with ESMTPSA id fd9sm1147229pab.34.2015. (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Aug 2015 06:49:06 -0700 (PDT)
To: Barry Leiba <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Peter Saint-Andre - &yet <>
Message-ID: <>
Date: Fri, 28 Aug 2015 06:49:04 -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: 7bit
Archived-At: <>
Cc: Ben Campbell <>,,,,,, 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 13:49:12 -0000

On 8/28/15 6:05 AM, Barry Leiba wrote:
>>> 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...
> 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 

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


>>     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. :-)
> Barry

Thanks for the review!


Peter Saint-Andre