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

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

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

On 8/5/15 9:02 AM, Stephen Farrell wrote:
> 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).

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.

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

Good points all.

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

I think that might be a sensible change.

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

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

> section 6: surely the cache expiry ought be the earliest
> 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!

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

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

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

See other thread.

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

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

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

I'm agnostic on that, I suppose.

Peter

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