Re: draft-ietf-httpbis-encryption-encoding

[Martin Thomson <[e-mail]>]

Thanks for the prompt review.  Inline.

On 22 December 2016 at 17:01, Kari Hurtta <[e-mail]> wrote:
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-09#section-2
>
> |                   Connections that use client certificates for other
> |   reasons MAY be reused, though client certificates MUST NOT affect the
> |   responses to requests for "http" resources.
[...]
> What are connections  that use client certificates for other reasons
> because they can not be connections which are used for "https" requests ?

That's an editorial snafu.  I've fixed it.  It now reads (in full):

   Client certificates are not meaningful for URLs with the "http"
   scheme, and therefore clients creating new TLS connections to
   alternative services for the purposes of this specification MUST NOT
   present them.  A server that also provides "https" resources on the
   same port can request a certificate during the TLS handshake, but it
   MUST NOT abort the handshake if the client does not provide one.

> I'm not sure that this
>
>     "they have obtained a valid http-opportunistic response for an origin (as
>     per Section 2.3)."
>
> is saying.

Section 2.3 defines a valid http-opportunistic response:

   [...] A client is said to have a valid http-opportunistic
   response for a given origin when:

> This text or example after that seems not say from read /.well-known/http-opportunistic
> need to be read. From original connection or from putative alternative service.
> Or is it irrelevant?

Yes, that's an oversight.  The only requirement is that the request is
made to the authenticated alternative.

And the contradiction is a problem.  I've pushed a commit that should fix this:

https://github.com/httpwg/http-extensions/commit/467d6b2773304e47cad09f6a8af62a7448fe3312