Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00

["Anne van Kesteren" <[e-mail]>]

On Sat, 10 Jul 2010 03:30:10 +0200, gabriel montenegro  
<[e-mail]> wrote:
> [gm] Hmmm... I was under the impression that the whole point was to
> start with HTTP and then via the Upgrade directive move into the
> WebSocket protocol. Or are you saying that there might be other ways
> to start other than HTTP?

Yes, but mostly I'm saying that the requirements document should not  
constrain the design to this level of detail.


>> Why should we constrain size in
>> the requirements?
>
> [gm] Please see my response to Greg's message.

Please see above. :-)


>> Suggest rewording as follows:
>>     REQ. 11:  During the
>> handshake ,the WebSocket Client MUST be able
>> to send one or more
>> WebSocket sub-protocol proposals to the server
>> so that the server can
>> select one.,This results in the use of a specific
>> WebSocket
>> sub-protocol.
>
> I don't think this is needed. It's also something that can
> easily be added later if application authors find a need for
> it.
>
> [gm] Are you disagreeing with the proposed rewording or with the original
> wording?:
>
> "   REQ. 11:  The WebSocket Client MUST be able to request the server,
>       during the handshake, to use a specific WebSocket sub-protocol.
> "
>
> The rewording did not change the basic requirement for sub-protocol  
> support, it was just adding more text as to how that might happen.

The rewording suggests the client transmits one or more sub-protocols. I  
don't think we necessarily need to go there (too complex for v1 and  
probably not needed at all) and the requirements document should not  
constrain that. Having said that, I'm not even sure it makes sense to talk  
about sub-protocols in the requirements document. Requirements should be  
high-level.


-- 
Anne van Kesteren
http://annevankesteren.nl/