See a breakdown of terminology at:
https://github.com/http2/http2-spec/wiki/Encryption-Terminology

The description of this topic still only lists draft-nottingham-http2-encryption as an approach. Please add draft-hoffman-httpbis-minimal-unauth-enc, which does opportunistic encryption in a very different way than draft-nottingham-http2-encryption.

Discussed in Zurich; further discussion in London; mark and patrick to revise draft and experiment. However, this will not block HTTP/2 unless delay is minimal.

Notes from Zurich:

HTTP URIs over TLS

1. no

Authentication

1. unauthenticated
2. authenticated == HTTPS
3. not WebPKI-authenticated (TACK? DANE? ETC. ETC.) -- NOT US

Discovery

a. In-band Hint (header) - optional to use.

b. DNS -- not now.
I. SRV
II. TXT
III. SVCINFO
IV. HASTLS

c. use existing 443 connection for defaulted ports - some interest (esp. in addition to other mechanisms); needs refusal. SETTINGS indicator for support; refusal error code (?)

d. encryption inside HTTP/2 -- no

e. speculative connection -- we will say nothing about this

Add-ons

i. Refusal (you got the endpoint wrong)

ii. implicit shortcut

iii. pinning

See also:
https://tools.ietf.org/html/draft-miller-http-unauth-tls

It would be good if the community could acknowledge the differences between opportunistic (doing something good that wasn't asked for) and unauthenticated (a security state).

--Paul Hoffman

Discussed in London; support for documenting this.

See also: http://tools.ietf.org/html/draft-hoffman-uta-opportunistic-tls-00
which was discussed in UTA.

@mnot What are the fundamental difference between opportunistic TLS and RFC 2817?

@mcilvena take it to the mailing list? RFC2817 is quite different than the current Alt-Svc proposal. See http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03

https://tools.ietf.org/html/draft-nottingham-http2-encryption-03 is the latest proposal in this regard.

Discussed in NYC; agreed to adopt as WG Experimental. Martin to edit.