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

Peter Saint-Andre - &yet <> Fri, 31 July 2015 01:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A6DC11B2F9D for <>; Thu, 30 Jul 2015 18:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
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=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X4xl1OlgTW8a for <>; Thu, 30 Jul 2015 18:13:44 -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 3DEA41B2F9C for <>; Thu, 30 Jul 2015 18:13:41 -0700 (PDT)
Received: by igr7 with SMTP id 7so7308045igr.0 for <>; Thu, 30 Jul 2015 18:13:40 -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=1c4Ses86HMiVo8+UAXFnzuunZuAKsYH2j+cGVFx43Ig=; b=S6pMI+vEs0ZvQpAVMEM2Jx/4fEmJkXLDd+ToeKIEMEpi5G9dRiATIjj5rYBEYQ/R0a xrC9tLpnYOVC1Ggcn0CN2CsQH/ip0AaOOu9Z8g3KkKaQuOru+bZZL35baqIrhGd6Vpcq 1s63pPV5szZdRpV8pp9+XlBxBe9ddTyd38/N00CzralyHlltiFfNcwiczlp+ZhRir4V1 H1NW7arGb7fSCqPqTP/GP4BDBaw4DgFIDaYb54SbNc8oJb32MvFZz4nV4ukzqs2e2HTu K8K7D9UC+w4F6i0UNlPX13QswPtHxg/j/8ybsPXIw+6Ry4D9f2pxuVVcxhJ0XuvyB0Ed 6y5g==
X-Gm-Message-State: ALoCoQmAdiq+DoAC/Kw9QHxWCLFJ5WvArwa5H4oBY4IpvJrj1HI0QrIYrXNkqdy2yOoBXzrARWmR
X-Received: by with SMTP id u7mr687971igk.71.1438305220654; Thu, 30 Jul 2015 18:13:40 -0700 (PDT)
Received: from aither.local ([2601:282:4201:ef5b:644b:2b7f:76c5:30be]) by with ESMTPSA id x4sm2007245iod.26.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2015 18:13:39 -0700 (PDT)
To: Barry Leiba <>, The IESG <>
References: <>
From: Peter Saint-Andre - &yet <>
Message-ID: <>
Date: Thu, 30 Jul 2015 19:13:35 -0600
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: <>
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, 31 Jul 2015 01:13:45 -0000

Hi Barry, thanks for the review. Replies inline.

On 7/29/15 3:04 AM, Barry Leiba wrote:
> Barry Leiba has entered the following ballot position for
> draft-ietf-xmpp-posh-04: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> No objection, in that I'm not going to block on these points, but I do
> ask for some discussion, please; see below.
> General: You're inconsistent in your use of "URI" and "URL", using the
> former in Sections 3 and 8, the latter in Sections 1, 3.2, and 10 -- and,
> of course, calling the member "url", rather than "uri".  I'd prefer that
> you use "URI", but you should, in any case, be consistent.

Given that we have implementations, I'd prefer not to change the member 
name (although I can't remember why we would have named it "url" instead 
of "uri"). We will, however, make it consistent.

> -- Section 3 --
>     When POSH is used, the first two aspects remain the same: the POSH
>     server proves it identity by presenting a PKIX certificate [RFC5280]
> Typo: It proves "its" identity, not "it".


>         *  If it does not have any PKIX certificate information or a
>            reference to such information for the requested path, it
>            responds with an HTTP client error status code (e.g., 404).
> Do you really want to leave the status code unspecified ("e.g."), rather
> than just saying that the code to use is 404?

Good point. Specifying 404 would be better.

> -- Section 3.1 --
>     o  A "fingerprints" field whose value is a JSON array of fingerprint
>        descriptors.
> Here and elsewhere: the JSON term is "member", not "field" (for members
> of an object; arrays have "elements").

Yes, sloppy terminology on our part. We'll clean that up.

> Please check the content-length in the example; I don't think it's
> correct (I get 176, assuming CRLF-termination, and 135 even if I get rid
> of all the pretty-print).  Similarly for the example in Section 3.2.  If
> you're using the pretty-print, the content-length should reflect it.

We'll double-check those.

>     If no "expires" field
>     is included or its value is equal to 0, a POSH client SHOULD consider
>     these verification materials invalid.
> But above you say that having "expires" is a "MUST".

Good catch. Earlier in the life of this draft, the "expires" member was 
not required; that changed at one point but we neglected to update this 

> Why is this
> "SHOULD" and not "MUST", and why is 0 not just outright invalid (previous
> sentence, change "non-negative" to "positive")?

On reflection, I see no reason to say SHOULD (i.e., I see no 
circumstance under which it would make sense for the client to consider 
the verification materials as valid if the "expires" value is zero).

So changing SHOULD to MUST seems like the right thing to do.

> (And similarly for
> Section 3.2.)


> -- Section 3.2 --
> The example shows using the same sort of .well-known URI, but I presume
> there's no requirement that this referral be to one of those (if there
> is, the doc should say so).

The use of .well-known is not required, it's simply a useful convention.

> It might be worth making it clear, with
> something like this (or adjust it if my previous presumption is wrong):
>     o  A "url" field whose value is a JSON string specifying the HTTPS
>        URL where POSH clients can obtain the actual certificate
>        information.
>     o  A "url" field whose value is a JSON string specifying the HTTPS
>        URL where POSH clients can obtain the actual certificate
>        information.  The URL can be a similar .well-known POSH URL, but
>        it need not be.


> -- Section 8 --
> I'm not terribly happy with the mechanism of having a faux hierarchy in
> the .well-known name (posh.servicename.json), not registering any
> .well-known name here, and asking the .well-known registry (via the
> designated expert) to register and evaluate each POSH service -- the
> .well-known DE is not an expert for POSH.  Also if, using your example,
> Victoria Beckham should want to have a .well-known URI to access her
> tweets from anywhere, returning them in JSON wrappers, she might want to
> register "posh.spice.json", which would then get in the way of that name
> for POSH, entirely unintentionally.
> I'd be much happier with using a real URI hierarchy and registering
> "posh" as a .well-known name here, so a POSH URI might be this:
> or this (I prefer the former, but don't really care):
> ...and you might establish an FCFS registry of POSH service names under
> which "spice" (or "spice.json") would be registered.  Now you're putting
> it all under one .well-known name, and only asking the .well-known expert
> to review this one, rather than one for every POSH service.

We're not terribly happy with the faux hierarchy, either, and we 
considered the approach you suggest (and consulted on the matter with 
Mark Nottingham). Unfortunately, the specification for well-known URIs 
(RFC 5785) states:

    Registered names MUST conform to the segment-nz production in

Because the segment-nz production does not allow "/", a real hierarchy 
won't work.

In practice, we are not expecting a large number of POSH registrations 
so I doubt that this would put a significant burden on the DE for the 
well-known URI registry. However, do you think it would be helpful to 
provide some additional guidance to the DE in this document?


P.S. My co-author is on vacation right now so I might not be able to 
coordinate with him quickly.