Re: Adjusting our spec names

In message <A90E6D81-FA41-4316-8650-5CB16158AE76@mnot.net>, Mark Nottingham wri
tes:

>We can discuss the problem of date generation/parsing. In a 2.0-only 
>chain, it would indeed be nice if we could dispense with this altogether 
>(e.g., with a separate set of headers to replace 
>date/last-modified/expires that get transformed to them on a 1.x hop 
>only). Let's discuss that.

Yes, we absolutely need to do that.

But there are things we should think about before that, such as

"Why do we even need a Date: header in the first place" ?

It's not like we're talking store-and-forward messaging...


My preference for how to shape the WG progress, would be to set up
a number of straw-man scenarios, and work through them to understand
where it is HTTP/1.1 come up short, and what HTTP/2.0 needs to do
better.


For example, if one of the strawmen is "1 Tb/s HTTP served on
a single IP#" we will probably end up with an analysis like:

	The first thing our incoming requests sees is a
	load-balancer/director gadget, which would much more precisely
	be named a "HTTP-router"

	Typically requests are distributed to backend HTTP servers
	based on relatively crude metrics, typically:

		Host:
		URI suffix (".jpg" vs. ".html")
		Session(-cookies)
		Extrinsic information (server load, etc.)

	While compression in general is a desirable thing, there
	may be a compelling argument for at least making it possible
	to avoid/prevent compression of these "envelope-fields" in
	order to reduce the amount of work a http-router has to do.

	The parallels to flow-routing should certainly be explored,
	in particular with respect to a session-concept that doesn't
	rely on cookies.

Ohh, so having a robust session-mechanism is important at the
second-lowest level of HTTP transport ?

Hmm, maybe we should pay some attention to that, rather than have
people kludge it with cookies.


And so on...

HTTP/2.0 needs to be a visionary standard, otherwise we'll just
be slowing down progress.

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

Received on Saturday, 31 March 2012 12:14:03 UTC