RE: draft-ietf-httpbis-http2-encryption-06.txt

Having "tls-ports" and "tls-commit" in the same response seems mildly nonsensical.  If "tls-commit" is present, then for the lifetime of that origin object, I would expect a "secured, authenticated alternative" to be available.  I should therefore disregard any unauthenticated alternatives.  But "tls-ports" at the same time tells me what ports I should accept referrals to *without* requiring authentication.  It may not break anything to have both, but an implementation that respects tls-commit will likely disregard the tls-ports value, so it's an odd example to provide.

Or is there a scenario where offering both makes sense?

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Thursday, June 23, 2016 1:55 PM
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Cc: HTTP working group mailing list <ietf-http-wg@w3.org>; Mark Nottingham <mnot@mnot.net>; Mike Bishop <Michael.Bishop@microsoft.com>
Subject: Re: draft-ietf-httpbis-http2-encryption-06.txt

On 24 June 2016 at 00:56, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> |     "http://www.example.com": {
> |       "tls-ports": [443,8080],
> |       "tls-commit": true,
> |       "lifetime": 3600
> |     }
> |   }
>
> Should this example omit "tls-ports" member ?

I don't think so.  If this is going to be used, we need to know where it is both possible and allowable to use the alternative.

Received on Thursday, 23 June 2016 21:45:12 UTC