Re: Gen-ART last call review of draft-ietf-hybi-thewebsocketprotocol-10
On 25 July 2011 05:11, Richard L. Barnes wrote: > It seems like this gets you around the threat that masking is supposed to > address -- the proxy won't see anything mid-stream that looks like HTTP, > since it's just acting as a tunnel at that point. It's a little weird to use > CONNECT end-to-end, but that doesn't seem bad enough to be a blocking issue. One concern expressed was that existing infrastructure may have special handling that triggers on the CONNECT method. Eg. code that will look at only the first HTTP request on a connection before becoming a bit pipe. Such proxies will work with websockets when GET is used, but will fail with CONNECT because it will trigger special handling to look for the destination server, which will not be present in the handshake. If the concern with using GET is that we are changing established semantics, then surely that concern must also apply to changing the semantics of CONNECT. If changed semantics is the concern, then using an entirely new method would be applicable. However, my reading of the discussion resulting to Roy's objection to the use of GET, is that he was mostly concerned that the 101 response not be consider the final response to the GET, and that semantically there is still a request to be responded to that is related to the specific URL passed in the GET.If semantically the WS stream is considered the response to the GET for the URI, then I think's Roy's issues are resolved. (NB. I've misread Roy's concerns a few times... so confirmation that I've got it right this time would be good). cheers ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: (The WebSocket protocol) to Proposed Standard
I agree that DNS SRV is a matter outside the scope of websockets, which (for better or for worse) use a connection that is established via a HTTP request. Thus I do not think that the establishment of a HTTP connection for websockets should differ in any way from the name resolution handling of other HTTP connections made by a user-agent. If the advocates of DNS SRV wish for websocket to use it, then they need to convince HTTPbis (I think that is the right WG?) to adopt it for all of HTTP and then websockets will inherit that feature. If in future, there is a proposal to directly establish websocket connections without a HTTP upgrade (as David Endicott has alluded to), then I think DNS SRV should definitely be supported. regards ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: (The WebSocket protocol) to Proposed Standard: request for max frame size
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 - potentially binary chopping down to find an acceptable size, which might be sub optimal. I simple optional header in the handshake declaring the max frame size (which intermediaries could adjust) would be very complimentary to the existing fragmentation and 1004 features and I can't think of any significant down side. regards On 13 July 2011 00:13, Francis Brosnan Blazquez wrote: > 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 (in some cases) not solves it. > > Websocket protocol is frame based and every frame based protocol > designed until now has/need such feature or similar. Even TCP, for those > that proposes to use a stream oriented API as a solution, includes a > more complex mechanism than a simple max frame size (window based ack), > so each party can control/inform the sender. This is critical. > > A good example for this would be the next. Let suppose you have a > constrained memory device (either because it is small or because it > accepts a large amount of connections). On that device you deploy a > websocket app that only accepts small messages (< 512 bytes, let's > say). > > In this context, you can hard code at your web app (javascript) that > must not send messages larger than this size (so you control websocket > payload size) and in the case you need to, you must split them > properly. > > However, even with this mechanism, you have no warranty that the browser > or an intermediary will join those messages into a single frame, causing > your device to receive a bigger message/frame than expected. > > Assuming this I think we would require either to include a > Max-Frame-Size indication (or a really poor solution: to explicitly > state on the draft that frames must not be coalesced by intermediaries > or browsers). > > Regards, > > [1] http://www.ietf.org/mail-archive/web/hybi/current/msg07641.html > -- > Francis Brosnan Blázquez > ASPL > 91 134 14 22 - 91 134 14 45 - 91 116 07 57 > > AVISO LEGAL > > Este mensaje se dirige exclusivamente a su destinatario. Los datos > incluidos en el presente correo son confidenciales y sometidos a secreto > profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si > usted no lo es y lo ha recibido por error o tiene conocimiento del mismo > por cualquier motivo, le rogamos que nos lo comunique por este medio y > proceda a destruirlo o borrarlo. > > En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de > diciembre, de Protección de Datos de Carácter Personal, le informamos de > que sus datos de carácter personal, recogidos de fuentes accesibles al > público o datos que usted nos ha facilitado previamente, proceden de > bases de datos propiedad de Advanced Software Production Line, S.L. > (ASPL). No obstante, usted puede ejercitar sus derechos de acceso, > rectificación, cancelación y oposición dispuestos en la mencionada Ley > Orgánica, notificándolo por escrito a: > ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de > Henares (Madrid). > > ___ > hybi mailing list > h...@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Repetitions and consensus
On 13 July 2011 08:51, Martin Rex wrote: > Trying to gauge "(rough) consensus" by counting voiced opinions when an > issue has not been reliably determined to be non-technical and > non-procedural _is_ inappropriate. Note that the point of the paper is saying that people "feel" that there is a widely held opinion, even if it comes from few repeated voices and even if they are intellectually aware of the actual count. So even if there is no actual conscious opinion counting going on, our brains are doing it for us and it does influence us. I think there is an important message there for the IETF, because the establishment of consensus is not by any objective measure and this science says that subjective measures can be influenced by repetition and even if chairs/ADs are aware of this fact. It shows that subjective measures are subject to manipulation. I think there is an important message there for the IETF, because the establishment of consensus is not by any objective measure and this science says that subjective measures can be influenced by repetition and even if chairs/ADs are aware of this fact. It shows that subjective measures are subject to manipulation. I think there is an important message there for the IETF, because the establishment of consensus is not by any objective measure and this science says that subjective measures can be influenced by repetition and even if chairs/ADs are aware of this fact. It shows that subjective measures are subject to manipulation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (The WebSocket protocol) to Proposed Standard
For the benefit of the wider ietf@ietf.org audience, I'd like to summaries an unresolved issue from the Hybi WG with the websocket draft protocol. Draft 10 if this document contains the "deflate-stream" extension in section 9.2.1 This extension does not comply with any of the anticipated uses of extensions listed in section 4.8, at best this makes it a poor exemplar of an extension, as worst it makes it an unexpected total change to the framing seen on the wire. Because the extension changes the framing of bytes on the wire, this will force all tools and intermediaries that wish to observe the frame boundaries, to implement this extension, making it non optional. For example, intermediaries that do not implement this extension will be unable to buffer/forward on frame boundaries. Because default-stream is applied after the masking of client sent frames, it is highly inefficient, with little or no compression being achieved due to the random masking keys and the masking of any regular patterns in the payload. The intent of masking was to prevent bytes sent on the wire being being controlled by an attacker. However, a security concern has been raised that the predictability of the deflate algorithm to convert byte patterns into shorter bit sequences may allow a payload to be crafted that would predictably produce bytes on the wire regardless of the masking applied. A reasonable alternative has been proposed that does not apply deflation to the stream. Rather it applies it only to the application data before masking, while keeping the compression dictionary between frames. This alternative proposal is a good exemplar extension (in line with 4.8), provides efficient compression and does not suffer from the security concern raised. Since draft -7, there have been many voices in the WG calling for the withdrawal of deflate-stream and nobody has spoken in favour of the retention of deflate-stream on any grounds other than it is already implemented/deployed. I fail to understand why a non essential feature that was put into draft-3 without discussion or consensus, that has demonstrable deficiencies, security concerns and vocal opponents has been left in the draft all the way to final call? regards Greg Wilkins ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
