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

["Stephen Farrell" <[e-mail]>]

Stephen Farrell 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:
----------------------------------------------------------------------



3.1: fingerprints: sigh, I wish we could agree to just
do this kind of thing a few times and not re-do it over
and over and over (but we always do;-). RFC6920 could
probably have been used there (caveat lector: that's an
RFC I'm a co-author on). 

3.1: fingerprints - your hash input here is the entire
cert so the value will be out of date when a cert
expires (or is revoked). While 3.3 makes clear that
a match on any of these is ok, I think it'd be good
to say here that the hashes may be of different certs. 
You do clarify in section 7, but I'd suggest moving
section 7 into 3.1 myself. (I don't object if you
prefer to not change though.)

3.2: A "MUST use HTTPS" statement might have been nice
there. It's not absolutely needed but would maybe be
something to help an implementer not get this wrong by
just using some generic URL handling library without a
check for scheme==https.

section 6: surely the cache expiry ought be the earliest
of the possibly two POST expires or the X.509 notAfter?

section 8: see my comments on draft-dna, I think the
.well-known URIs should be here and not there. But
it works as-is too, even if ickky:-)

section 8: I dislike the "{servicedesc}" thing, but
that's just me. Breaking down servicedesc further into
"{service}.{proto}" is worse though, I don't get why
that's a good idea at all, nor the "_" convention. If
you want/need all that you should've just registered
"posh" as a well-known and then said the the rest of the
pathname was whatever structure you needed and not
possibly end up registering loads of DNA .well-known
URLs.

section 9: section 8 is IMO an IANA section, so you're
fibbing here:-)

- 11.2: odd one this but [HASH-NAMES] might be better
in 11.1. I won't try force you to do that though as
it may be messy.