HyBi wg, Anaheim ================================== Meeting: Location: Hilton Anaheim, Redondo room, 1300-1515 Chairs: Joe Hildebrand, Salvatore Loreto Minutes: using "EtherPad" http://etherpad.com/FWABRLTLpK There were about 45-50 attendees + remotely attendees JH = Joe HIldebrand *Chair SL = Salvatore Loreto *Chair GW = Greg Wilkins IH = Ian HIckson AM = Alexey Melnikov A = Anne TH: Ted Hardie FS = Frank Salim MP = Mark Pauley JM = Jack Moffit PR = Pete Resnick JE = Justin Erenkrantz Agenda ------ Agenda: http://tools.ietf.org/wg/hybi/agenda Agenda not bashed WebSocket Protocol draft discussion ----------------------------------- Ian has volunteered to edit the WS draft, the chair's intent is to make this a WG draft shortly after the meeting. Greg Wilkins at the mic suggests that the draft that matches the working code is used as a baseline JH : it seems that some people think that the -75 version has a security problem JH: if we need to make changes that break, then we should do that GW: the new changes were just one person's idea IH: 75 hasn't gone through the process either AM: start with -00 that matches what people shipped, changes are cheap JH*: start with -75 and we can discuss what is in -01 SL: implementation status: several implementations JH*: there will be breaking changes and it will not interoperate in future, we'll take this to the list A: how many implementations? GW: chrome, kaazing, mozilla, jetty JH: will take the idea to the list of starting at 00 reprinting what has been shipped Tracker experiment ------------------ http://trac.tools.ietf.org/wg/hybi/trac/report/1 AM: we should agree on who is allowed to create and close issues JH*: tight control to start with, then later submissions can be made by all; state changes will be controlled by the chairs always Requirements ------------ *) req: Internationalization / utf-8 AM: it doesn't hurt if we are explicit about this JH: (from floor) we could leave this up to a sub-protocol; this is specific to the text-only kind of things that have been specified up to now; PR: what is the use case? this textual stuff sounds like a sub-protocol JH: opinion is divided GW: utf-8 is excessive TH: utf-8 doesn't get you i18n, languages and locales are also part of that; if you punt i18n, you punt to every application JH: try to get as close to TCP as possible, but utf-8 is further from that than people might have expected PR: make this a pipe, because I don't understand how text+other co-exist JH: agree, but there is history, which constrains some of these choices GW: we can make breaking changes -( so can break existing utf-8 framing) PR: if you push this, then you don't need an i18n considerations section. at all. JH: current framing relies on invalid utf-8 to mark end of frame FS: we shouldn't be constrained by javascript implementations, browsers will have binary functions JH*: let's move on *) req: The WebSockets protocol MUST run directly on a transport protocol TH: I assume that this doesn't mean that this can't be TLS; rephrase to describe the minimum, to allow for other documents to expand - which opens possibilities - and use mandatory to implement to get interoperability JH: we need guaranteed delivery, I think TH: there would be problems if you use datagram with congestion control, etc... *) req DATA MANAGEMENT MT: no use jcase for large messages JH: (individual) agrees JM: arbitrarily large messages will cause problems for latency and performance, pick a size GW: we need better error handling if that's the case MT: pick a size and that problem goes away JM: agrees and requirement becomes for fixed size JH: does there need to be any negotiation, or something for intermediaries? GW: there's a distinction between frame and message, frames can be fixed size but sub-protocol can do this JM: use initial header to negotiate JE: servers do like to write as soon as they have data (stream stuff out) JH: it's possible to deal with that at the sub-protocol FS: suggests byte streams JH: desire on receive side to have some sort of boundary indication IH: mentions problem with octet length and string length that lead to the current design JH: we might use utf-32; we've moved on from talking about ascii protocols, from my perspective GW: strange to consider that a programmer can't work out octet length JM: the missing requirement is that it perhaps that it should be easy to implement on client side GW: IH is more concerned with server side implementations and less with clients (which are browsers) JH*: can we get some input from the encodings gurus (TH, PR) PR: hasn't so much background, but...doesn't know what layer of protocol is being built JH*: confusion exists IH: you don't have a "buffer of utf-8" in most scripting languages -- you have a string, that happens to serialize to utf-8 by default JM: that shouldn't be a problem JH: there's a distinction between bytes and unicode code points JH: some folks want to use strings, others bytes GW: how can we expect something dealing with strings to not have to encode if they are sending data IH: any opportunity for error will be exploited GW: big debate is on the point of implementer abilities and what responsibilities are expected of them JM: stuff gets fixed if it is wrong IH: disagrees PR: if you use octet framing, then you contain the damage; otherwise you let the damage leak JH*: one group wants bytes and layers, another want strings, some are happy for a mix GW: draft currently has both, but binary says not to use it JH: ^ is because javascript doesn't support binary JM: errors get fixed, not a big deal IH: wants to protect implementers from themselves JH*: let's talk about the requirement GW: can we have IH's audience text put in terms of a requirement JH*: let's go to the list - propose requirements text about the audience IH: we should have a requirement to the effect that implementors on the server side should not ever have to distinguish character string length and byte string length JH: ? TH: two groups: transport and transport+sugar; suggests marriage JH: I am ordained TH: happy family suggestion; work out what we can do first, because it appears that one can't be done in the present without the other PR: in order to transfer strings, you need to have buffers anyway, so use buffers because strings are icky, you probably need some semantic sugar JH: thanks for translation, seems useful JH*: any objections GW: will marry either PR or TH *) req HANDSHAKE requirement GW: we need to talk about versions in the document, particularly if we are making breaking changes JH: that's BCP *) req HTTP -> WS requirement (port sharing) GW: likes "compliant" better than "compatible" JH*: anyone else? BL: yes GW: opens a range of options, redirect, error status, etc... no guarantee that these are understood, but clients should at least behave JM: there is another case here, which is how the upgrade is done - whether it is done with a GET a CONNECT or an Upgrade header. We should try to reuse the HTTP semantics A: seems like an undue burden on pure websocket servers IH: does this mean that WS servers need conneg? that seems a bit much GW: old versions are pretty well-compatible, new versions are worse JR: might be a resource that is not subject to content negotiation JE: WS shouldn't add constraints to HTTP before the upgrade is complete IH: what does it mean for the WS server to support HTTP? GW: no big deal, but with "compatible", server's choices are constrained; doesn't want to burden WS implementations, but must coexist IH: agree that this should not constrain HTTP servers and this might just need to be clarified GW: would it be OK if a server challenged a request with a 401? IH: he has thought about this, draft makes statements about ws _client_ behaviour only GW: not saying that clients need to support anything (401, etc...) JH*: moving on *) req GRACEFUL CLOSE requirement do we also need a requirement for *ungraceful* close? GW: no way to distinguish between graceful and other closes IH: that's in the API now, -76 has 0xff 0x00 close frame now JH*: with API support, we have consensus for this feature *) req EXTENSIONS requirement(s) and how we deal with this - in protocol, or in upper layers? GW: we need to understand what extensions are; I think that most are going to be implemented by frameworks; nothing in the current protocol to support extensions _below_ the layer provided by the API JH: we might need some examples of examples GW: has a BWTP extension to WS that he will provide JH: please offer a few examples (i.e. compression) GW: would like more than the 7 lower order bits in the frame type octet SL: we should ensure that extensions don't affect operation of the base protocol for those who don't care; backward compatibility *) req SUB-PROTOCOL requirement JE: sub-protocol as a term doesn't seem to make sense, but this might fall within the extension mechanism *) req SECURITY requirements JeffHodges: same origin is not documented or defined anywhere; idea is that mobile code that requests a web socket follows same origin policy JH: there are also non-browser cases that don't have these constraints JM: does CORS provide sufficient definition? that's my interpretation GW: this isn't a protocol requirement, this is more like that IH: http://tools.ietf.org/html/draft-abarth-origin JR: defines the notion of origin, not a definition for the same origin policy JeffH: the definition is used in CORS, origin draft doesn't have a home http://www.w3.org/TR/cors/ JeffH: there are lots of specs in this, which might motivate a new WG JH: let's talk about that on app area [ JeffH will post to apparea list on the topic ] maciej: HTML5 defines the term "same origin" http://dev.w3.org/html5/spec/Overview.html#same-origin GW: the origin model is the obvious one to use, but it is at a layer above that has to be communicated by the protocol LD: need to make assumptions clear in any requirements document, such as "this is often used from within a browser", using that context might be helpful *) req cross protocol attacks JH*: points those who are confused about this to the messages on the list SL*: need a voluteer to become editor of the draft GW: IETF newcomers would appreciate someone showing an example