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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 05 Aug 2015 08:02:44 -0700

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.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 5 Aug 2015 18:06:24 +0200

> possibly end up registering loads of DNA .well-known

Yep... I made a similar comment, which Peter and I have been
discussing.  He's mulling over what to do.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Aug 2015 17:20:29 +0100

> discussing.  He's mulling over what to do.

Thanks - I saw that go by but didn't follow. Best
to continue in that other thread I'd say.

S

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 5 Aug 2015 16:55:26 -0600

Hi Stephen, this is a quick reply because time is short here (also, I 
will be offilne tomorrow and Friday).

> https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/

Sorry, I should have thought of RFC 6920 in this context. :(

Matt and I will look at this. (He is offline this week so we won't be 
able to sync up until then.) We will also reach out to implementers 
because as I recall we chose this approach in part for ease of 
implementation.

> to say here that the hashes may be of different certs.

Good points all.

> prefer to not change though.)

I think that might be a sensible change.

> just using some generic URL handling library without a

We have been assuming "MUST use HTTPS" but it seems that we didn't quite 
come out and say that.

> of the possibly two POST expires or the X.509 notAfter?

We were thinking specifically of HTTPS-related caching, but yes I 
certainly see your point!

> it works as-is too, even if ickky:-)

We had some debate about exactly where things belonged, but decided in 
the end that the xmpp-related registrations belonged in the -dna document.

> possibly end up registering loads of DNA .well-known

See other thread.

> section 9: section 8 is IMO an IANA section, so you're

Section 8 doesn't make any requests of the IANA, so it doesn't feel like 
material for a standard IANA considerations section.

> in 11.1. I won't try force you to do that though as

I'm agnostic on that, I suppose.

Peter

-- 
Peter Saint-Andre
https://andyet.com/