Re: [hybi] #1: HTTP Compliance

[Ian Hickson <[e-mail]>]

On Mon, 17 May 2010, Greg Wilkins wrote:
>
> Also, in an attempt to move the conversation on, I'd like flip the 
> question around and ask if somebody can clearly state what is the down 
> side of adopting HTTP compliance other than it might force a breaking 
> change in the -76 draft.

There is an assumption in this question that I feel would lead us to make 
suboptimal design decisions: it assumes that the bytes being sent from one 
peer to another peer are intrinsically meaningful, as opposed to the 
reality, which is that it's the software that imbues them with meaning 
when interpreting them.

What matters is that we get interoperable behaviour. Everything else is 
secondary, IMHO. We should look at things from the point of view of the 
client and the point of view of the server, not from the point of view of 
the bytes on the wire. This has some implications for our requirements -- 
for example, it means that the server and client don't have to agree about 
what's going on, so long as the result is reliably interoperable. A client 
might think it's talking one protocol, while a server might think it's 
talking another protocol -- so long as the rules for generation on the 
client result in the right result when the server applies the rules for 
consumption, we've achieved the goal of interoperability.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'