Re: [hybi] Comments to draft-ietf-hybi-thewebsocketprotocol-05

[Iñaki Baz Castillo <[e-mail]>]

2011/2/24 Ian Fette (イアンフェッティ) <[e-mail]>:
>> Really? so what is this draft? a "HOWTO" for developing software?. A
>> specification describing a protocol must include extensive information
>> about the reasoning for its design, even more when it aims to become a
>> standard. You are describing a *protocol*, not a guide for a lazy
>> implementor. Could you please check *any* other RFC describing any
>> other protocol?
>>
>
> If RFC2616 had to list out the full history of every debate of every feature
> in HTTP it would be unreadable and worthless. The protocol is a guide to
> what you must do if you want to create software that can interoperate with
> other WS endpoints, in that sense yes, it is something of a howto. You do
> not need a transcription of months of arguments that led to what it is. I am
> sure that back in the 90s people were debating about whether Accept-Lang:
> en, de; q=0.8 was more understandable or less understandable than en;
> de,q=0.8, but at the end of the day one won out, and the history doesn't
> really matter as if I want it to work, I need to send en,de;q=0.8.

You are comparing a format/grammar rule with a security design.

I don't expect (neither I desire) that this draft explains why
Sec-WebSocket-1 is called as it is rather than "Security-WS-A", even
if you all spent 5 weeks discussing about it.
But if the draft defines a exotic handshake it must argue it. If it
requires masking just for client-to-server communication it must argue
it ("avoid confusing network intermediaries, such as intercepting
proxies" is not enough).

Also -05 seems to be HTTP compliant but I still don't know how should
a websocket client react if it receives a 302 when performing the
handshake. Same as a "real" HTTP client? or not? Initially the
protocol was just "similar" to HTTP (but not HTTP) so it's hard to
figure how is currently defined to behave without explicit mention in
the draft.

If the protocol is HTTP compliant, why is the draft full of phrases
like the following?:

   Headers in the handshake are sent by the client in a random order;
   the order is not meaningful.

This is obvious in HTTP! order of different headers never matter, so
why to include it in this draft? Is it not clear that a WebSocket
implementor must know HTTP protocol? Wouldn't be better to remove such
unnecessary information from the draft and, instead, include useful
information (as technical rationale)? maybe you still save space :)


Regards.



-- 
Iñaki Baz Castillo
<[e-mail]>