Subject: agenda/charter brainstorming

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jun 2014 10:43:38 +0200

Hi there,

here are some ideas for what the WG could/should work on in the 
post-HTTP2-LC time:

1) Revise RFC 7230..5

- collect errata

- collect suggested improvements, such as those which would make the 
interface to the HTTP/2 spec clearer

- continue the process of checking the spec against reality, and in case 
of disagreements, see whether we need either to fix the spec, or fix 
implementations (no-transform comes to mind from recent discussions)

- with the current charter, we couldn't adopt new stuff - I think the 
revision should be allowed to pull in minor extension specs (which would 
need to be proposed standards as well)

- progress from "proposed" to "standard"

2) Maintenance

- RFC 7238 ("The Hypertext Transfer Protocol Status Code 308 (Permanent 
Redirect)") from "experimental" to "proposed" (this wasn't a WG item)

- RFC 5987 ("Character Set and Language Encoding for Hypertext Transfer 
Protocol (HTTP) Header Field Parameters") from "proposed" to "standard" 
(this wasn't a WG item) - see 
<http://greenbytes.de/tech/webdav/draft-reschke-rfc5987bis-latest.html>

- RFC 6266 ("Use of the Content-Disposition Header Field in the 
Hypertext Transfer Protocol (HTTP)") from "proposed" to "standard"

3) New stuff

- "Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding" 
(<http://greenbytes.de/tech/webdav/draft-reschke-http-cice-latest.html>)

- Analyzing the issue of range requests vs compression (we should at 
least write down what the problem is, so we don't have to have the whole 
discussion again)

- Another thing that comes up again and again is GET vs POST, and why 
there isn't a generic safe retrieval operation that takes a request body 
(describe the problem, document pros and cons, define an experimental 
new method?)

- Header field syntax is something people continue to struggle with; 
maybe define how to use JSON in header fields to make things easier for 
new header field definitions

4) Session handling (or "avoiding cookies")

...in case we find people, energy, and implementer interest.

5) WebDAV related (if people are interested)

- internet media types for WebDAV payloads (and maybe link relations)

- splitting out COPY/MOVE so they become more generic

- maybe even a JSON mapping

- notifications (HTTP/2 push?)

and finally...:

6) Proxies

- describe the current situation (adopt 
draft-nottingham-http-proxy-problem as a WG item for publication as 
informational document)

- while working on the above, make decisions about which of the problems 
described in the document we want to work on in this WG (or 
alternatively find alternative venues, such as TLS or a httpproxy WG)

Feedback appreciated,

Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 23 Jun 2014 09:06:21 +0000

>here are some ideas for what the WG could/should work on in the 

HTTP/3.0
--------

A non-backwards compatible, heavily cleaned up HTTP and much simpler
HTTP protocol for the longer future:

Goals:

    Scale towards Tbit/s speeds on contemporary silicon
	Fiber to the home is coming, we need to deal
	with it.

    Improve privacy in ways which does not force a crypto-arms-race.
	Indiscriminately adding crypto in the face of laws
	just means that the crypto will be circumvented or trojaned.
	We need to pay the king his shilling, in a way that means
	he doesn't have to take the entire pound.

    Reduce cruft and simplify the semantics of HTTP.
	HTTP has become too complex through accumulation of
	successive "convenient quick fixes" many of which
	nobody uses and most of which don't work reliably
	end-to-end any more.

Means:

    Define "routing-envelope" fields always sent in plaintext
	This enables load-balancing, also of otherwise secured
	transactions.  Eliminates need for certs on load-balancers

    Reduce the number of headers proxies need to pay attention to
	For speed and privacy.
	
    Replace cookies with client chosen session identifiers
	This increases transmission performance a LOT and
	solves the problem EU's "cookie directive" tried to
	address.

    Allow privacy protected and plaintext requests on the same connection.
	Less connection-churn when upgrading.
	Better connection-aggregation by proxies.

Consequences:

    Semantic changes will force website designers to think more
    clearly about privacy and thus this will not be a direct
    "invisible" upgrade from prior HTTP versions.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: James M Snell <[email-masked]>
Date: Mon, 23 Jun 2014 08:53:53 -0700

On Mon, Jun 23, 2014 at 1:43 AM, Julian Reschke <[email-masked]> wrote:
> [snip]
> [snip]
> - Another thing that comes up again and again is GET vs POST, and why there
> isn't a generic safe retrieval operation that takes a request body (describe
> the problem, document pros and cons, define an experimental new method?)
>

+0.5 ... I'm not entirely convinced yet that this is necessary but I
have seen the use case crop up fairly often, particularly in API
discussions. A Payload-bearing GET (PGET?) would, at the very least,
make for a worthwhile experiment, if only to prove or disprove it's
utility. I'm certainly willing to help write something up.

> - Header field syntax is something people continue to struggle with; maybe
> define how to use JSON in header fields to make things easier for new header
> field definitions
>

+1 ... but I would frame the problem differently: Existing header
syntax is inefficient, inconsistent and incomplete at best. We need
efficient binary encodings, UTF-8 support and reliable extensibility.
Introducing JSON-based headers would be a mistake. Again, I'm willing
to continue the previous work I did around BOHE and help write this
up.

> ...in case we find people, energy, and implementer interest.

+1.

- James

>[snip]
> and finally...:
>
> 6) Proxies
>
> - describe the current situation (adopt draft-nottingham-http-proxy-problem
> as a WG item for publication as informational document)
>
> described in the document we want to work on in this WG (or alternatively
> find alternative venues, such as TLS or a httpproxy WG)
>
>
> Feedback appreciated,
>
> Julian
>
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jun 2014 18:01:05 +0200

On 2014-06-23 17:53, James M Snell wrote:
> ...

Same here. It's one of these questions that come up every few weeks. It 
would be good to have a document that explains the situations, the 
advantages and drawbacks, and offers a new method to experiment with.

> to continue the previous work I did around BOHE and help write this

I'm looking for something that works across all HTTP versions, so binary 
IMHO is out.

> ...

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 23 Jun 2014 17:44:22 +0000

>> syntax is inefficient, inconsistent and incomplete at best. [...]

>I'm looking for something that works across all HTTP versions, so binary 

As long as a loss-less conversion exists, that's needlessly strict.

For instance Date: can trivially be converted to an integer and back
without any loss of information.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jun 2014 20:23:16 +0200

> without any loss of information.

We're talking past each other.

I'm talking about a generic field format for new header fields. You are 
talking about different ways to serialize existing header fields.

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Mon, 23 Jun 2014 16:06:22 -0700

On Jun 23, 2014 11:23 AM, "Julian Reschke" <[email-masked]> wrote:
[snip]

These are not mutually exclusive.

- James

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Jun 2014 11:06:49 +1000

Hi PHK,

Glad you brought that up. People have been quietly talking about this in the background. While it's still too early to talk about this for any great length of time in the WG, I do think that we should start discussing what HTTP/3 might look like. 

We'll likely talk about this *briefly* in Toronto; I'm still thinking about how to make the effort productive and representative.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Jun 2014 15:42:19 +1000

Hi Julian,

On 23 Jun 2014, at 6:43 pm, Julian Reschke <[email-masked]> wrote:

> Hi there,
> 
> here are some ideas for what the WG could/should work on in the post-HTTP2-LC time:
> 
> 
> 1) Revise RFC 7230..5
> 
> - collect errata
> 
> - collect suggested improvements, such as those which would make the interface to the HTTP/2 spec clearer
> 
> - continue the process of checking the spec against reality, and in case of disagreements, see whether we need either to fix the spec, or fix implementations (no-transform comes to mind from recent discussions)

Yes. 

> 
> - with the current charter, we couldn't adopt new stuff - I think the revision should be allowed to pull in minor extension specs (which would need to be proposed standards as well)

Our current charter explicitly allows us to do this.

> - progress from "proposed" to "standard"

Yes. 

I have 10 minutes on my current plan for discussing HTTP/1.1 status.

> 
> 
> 2) Maintenance
> 
> - RFC 7238 ("The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)") from "experimental" to "proposed" (this wasn't a WG item)

Do you want to give an update?

> - RFC 5987 ("Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters") from "proposed" to "standard" (this wasn't a WG item) - see <http://greenbytes.de/tech/webdav/draft-reschke-rfc5987bis-latest.html>

Ditto.

> - RFC 6266 ("Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)") from "proposed" to "standard"

Can be folded into HTTP/1.1 discussion.

> 3) New stuff
> 
> - "Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding" (<http://greenbytes.de/tech/webdav/draft-reschke-http-cice-latest.html>)

15 minutes enough?

> - Analyzing the issue of range requests vs compression (we should at least write down what the problem is, so we don't have to have the whole discussion again)

Draft?

> - Another thing that comes up again and again is GET vs POST, and why there isn't a generic safe retrieval operation that takes a request body (describe the problem, document pros and cons, define an experimental new method?)

That seems like an item for 1.1 full standard. However, if we didn't explain it well enough in bis, I wonder what makes us think we can satisfy everyone now...

> - Header field syntax is something people continue to struggle with; maybe define how to use JSON in header fields to make things easier for new header field definitions

Draft?

> ...in case we find people, energy, and implementer interest.

That sounds very speculative. Draft?

> 5) WebDAV related (if people are interested)

No. :)

> - notifications (HTTP/2 push?)

We've talked about things like this before. I'm still interested to some degree, but I wonder about the reward we'll see for the effort expended... What do others think?

> and finally...:
> 
> 6) Proxies
> 
> - describe the current situation (adopt draft-nottingham-http-proxy-problem as a WG item for publication as informational document)
> 
> - while working on the above, make decisions about which of the problems described in the document we want to work on in this WG (or alternatively find alternative venues, such as TLS or a httpproxy WG)

See separate thread.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Tue, 24 Jun 2014 07:55:50 +0200

> Do you want to give an update?

Yes. 1 minute.

>> - RFC 5987 ("Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters") from "proposed" to "standard" (this wasn't a WG item) - see <http://greenbytes.de/…

Yes. 2 minutes.

> Can be folded into HTTP/1.1 discussion.

Probably.

>> - "Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding" (<http://greenbytes.de/tech/webdav/draft-reschke-http-cice-latest.html>)

If we don't extend the scope 10 minutes should be sufficient.

>> - Analyzing the issue of range requests vs compression (we should at least write down what the problem is, so we don't have to have the whole discussion again)

Yes, we ought to have a draft, but I'm not going to be able to write it 
in the next few weeks.

> That seems like an item for 1.1 full standard. However, if we didn't explain it well enough in bis, I wonder what makes us think we can satisfy everyone now...

a) I don't think we even tried.

b) The goal is not to satisfy everyone, but to improve the situation 
(people being confused, and trying to put payloads into GET).

>> - Header field syntax is something people continue to struggle with; maybe define how to use JSON in header fields to make things easier for new header field definitions

Maybe, but not probably not before the submission deadline.

> That sounds very speculative. Draft?

303 :-)

> We've talked about things like this before. I'm still interested to some degree, but I wonder about the reward we'll see for the effort expended... What do others think?

I'll move this topic into a separate thread.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 24 Jun 2014 19:06:15 +1200

> On 23 Jun 2014, at 6:43 pm, Julian Reschke <[email-masked]> wrote:
<snip>
> We've talked about things like this before. I'm still interested to some degree, but I wonder about the reward we'll see for the effort expended... What do others think?

I think bandwidth saving proxies will largely drop or not relay PUSH. So
relying on it in a protocol like WebDAV will kill that other protocol.

Amos

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Jun 2014 22:32:41 +0300

> That sounds very speculative. Draft?

http://tools.ietf.org/html/draft-williams-websec-session-continue-prob-00
http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-00
http://tools.ietf.org/html/draft-abarth-cake-01
http://tools.ietf.org/html/draft-hallambaker-httpsession-02
http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02
http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05

I could probably dig up a few more if I put my mind to it.

So people is easy, energy we might be able to find. Implementer interest?  I’m not sure it’s there.

Interesting reads on the subject: http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

Yoav

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Jun 2014 00:48:17 +1200

On 25/06/2014 7:32 a.m., Yoav Nir wrote:
> 
> On Jun 24, 2014, at 8:42 AM, Mark Nottingham wrote:
> 
>> Hi Julian,
>>
>> On 23 Jun 2014, at 6:43 pm, Julian Reschke wrote:
>>
>>>

Some here from Squid. I have been watching Hallam's work with some
interest, will be needing proxy support but otherwise there is a lot of
promise there.

> Interesting reads on the subject: http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

A must read for all web developers IMHO. Thanks for the reminder.

Amos

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Jun 2014 16:31:03 +0300

> interest, will be needing proxy support but otherwise there is a lot of

As makers of middle-boxes, we’re just along for the ride. Unless Facebook/the bank/the bloggers/the dog-food over the Internet people want a new session management scheme, and unless the browsers are willing to provide it, we can’t push a new technology. And the dogfood over the Internet people do not participate in the working group, and the browser people have so far been silent about this.

You can browse the archives of websec to see my totally unsuccessful attempts to bring this to the IETF. Doesn’t mean it won’t succeed somewhere else.

Yoav

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 25 Jun 2014 16:47:55 +0000

In message <[email-masked]>, Yoav Nir writes:

>As makers of middle-boxes, we're just along for the ride. Unless 
>Facebook/the bank/the bloggers/the dog-food over the Internet people 
>want a new session management scheme, [...]

Don't forget:  /legislatures

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Jun 2014 21:11:49 +0300

> Don't forget:  /legislatures

Nope. They’re not posting on the list or coming to the meetings either.

And they, like the oracle, are so vague that they require interpreters, and those don’t come to our meetings either.

They still use cookies in Europe, don’t they?

Yoav

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 25 Jun 2014 19:15:46 +0000

In message <[email-masked]>, Yoav Nir writes:

>Nope. They're not posting on the list or coming to the meetings either.

That's exactly the snobby attitude which lead directly to NSA's
Global War on Privacy, and if we keep it up, it won't be long before
countries start to implement mandatory key-escrow and other shit
which eliminates privacy in toto.

Until IETF can muster an army, it pays to be ahead of the legislatures
so they don't need to do something stupid later on.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 26 Jun 2014 11:47:54 +1000

Hi Yoav,

I'm not sure we'll have the right people in Toronto for this, and we already have a pretty crowded agenda. My inclination is to hold off for now, but I think it would make for some interesting hallway conversations...

Cheers,

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Jun 2014 08:35:30 +0300

On Jun 26, 2014, at 4:47 AM, Mark Nottingham <[email-masked]> wrote:

> Hi Yoav,
> 
> I'm not sure we'll have the right people in Toronto for this, and we already have a pretty crowded agenda. My inclination is to hold off for now, but I think it would make for some interesting hallway conversations…

Perhaps carrying over into a bar.  

One of the problems with this subject is that you can get a lot of people to tell you why cookies are bad, but they’ll be saying different things, finding different faults with cookies, and therefore prescribing different remedies. I think we’re at the bar BoF lever, not quite ready for the BoF level.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 Jun 2014 10:57:12 +0100

On 26/06/14 06:35, Yoav Nir wrote:
>> I'm not sure we'll have the right people in Toronto for this, and
>> we already have a pretty crowded agenda. My inclination is to hold
>> off for now, but I think it would make for some interesting hallway
>> conversations…
> 
> One of the problems with this subject is that you can get a lot of
> people to tell you why cookies are bad, but they’ll be saying
> different things, finding different faults with cookies, and
> therefore prescribing different remedies. I think we’re at the bar
> BoF lever, not quite ready for the BoF level.

I agree. FWIW, if this does get to the stage where it looks like
it'd work out (i.e. a sensible technical approach with a good
chance of being deployed) and if the IETF is the right place to
do that work, I'd be happy to help with getting a BoF to happen
(or a WG formed without a BoF, if its sufficiently obviously the
right thing to do).

Cheers,
S.