RE: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard: request for max frame size

2011-07-14 Thread Len Holgate
Francis, Ok, It shouldn't be a negotiation but an indication to accommodate communication to each party. Fair point. Ok, it is important to note the peer is limiting max frame size not the message size which may be still infinite in practical terms (63 bits)and we have fragmentation

Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard: request for max frame size

2011-07-13 Thread Greg Wilkins
Francis et al, not also that the protocol does support fragmentation and a 1004 frame too large error. Even the 1004 error does not carry an indication of what an acceptable size is, so the client/tool/intermediary that receives a 1004 will either have to fail or guess a smaller frames size -

RE: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard: request for max frame size

2011-07-13 Thread Len Holgate
Francis, I agree with your points and would welcome a max frame size negotiation header. However, whilst an intermediary might legitimately change the fragmentation of a frame it cannot merge complete messages. If, in your example, your client limited itself to messages of a certain size then it

RE: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard: request for max frame size

2011-07-13 Thread Len Holgate
I agree that this would be very useful. Would this be one frame size for both directions, or could it be specified in each direction? I'm a little wary of intermediaries being allowed to adjust this unless they're only allowed to reduce the amount... Len www.lenholgate.com -Original

RE: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard: request for max frame size

2011-07-13 Thread Francis Brosnan Blazquez
Hi Len, I agree that this would be very useful. Would this be one frame size for both directions, or could it be specified in each direction? It should be done in both directions, assuming each party may have different requirements.. I'm a little wary of intermediaries being allowed to

RE: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard: request for max frame size

2011-07-13 Thread Len Holgate
Would this be one frame size for both directions, or could it be specified in each direction? It should be done in both directions, assuming each party may have different requirements.. That was my feeling on it. I'm a little wary of intermediaries being allowed to adjust this

RE: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard: request for max frame size

2011-07-13 Thread Francis Brosnan Blazquez
Francis, Hi Len, I agree with your points and would welcome a max frame size negotiation header. Ok, It shouldn't be a negotiation but an indication to accommodate communication to each party. However, whilst an intermediary might legitimately change the fragmentation of a frame it cannot

Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard: request for max frame size

2011-07-12 Thread Francis Brosnan Blazquez
Hi, Recently, I posted [1] that websocket protocol should include an indication about max frame size that is willing to accept the connecting peer. Many pointed this is not an issue because you could use a stream oriented API (like TCP send/recv and others), but that only bypasses the problem