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

["Barry Leiba" <[e-mail]>]

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.

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

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

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.

   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".  Why is this
"SHOULD" and not "MUST", and why is 0 not just outright invalid (previous
sentence, change "non-negative" to "positive")?  (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).  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

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

Hable conmigo...