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

[Peter Saint-Andre - &yet <[e-mail]>]

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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".

Noted.

>         *  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 
text.

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

Yep.

> -- 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):
>
> OLD
>     o  A "url" field whose value is a JSON string specifying the HTTPS
>        URL where POSH clients can obtain the actual certificate
>        information.
> NEW
>     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.
> END

+1

> -- 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:
>     https://hosting.example.net/.well-known/posh/spice/json
> or this (I prefer the former, but don't really care):
>     https://hosting.example.net/.well-known/posh/spice.json
> ...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
    [RFC3986].

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?

Peter

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