HyBi BOF - IETF 76 in Hiroshima
TUESDAY, November 10, 2009, 1300-1500, Cattleya 1
HyBi BOF Chairs:
Joe Hildebrand, Salvatore Loreto
Notetakers:
Andrew McGregor, Spencer Dawkins
NOTEs from Andrew McGregor:
--------------------------
1 - Chairs
Agenda bash / Goal and Purpose of the BoF
2 - Peter Saint-Andre
Design Space
draft-loreto-design-space-bidirectional-00.txt
Markus Isomaki: URIs on client. Are those only supposed to be reachable from the server, or are we talking about rendezvous?
JH: That's not yet covered in the requirements
PSA: (paraphrase) Let's think about that
Ian Fette: What sort of data being transmitted would you expect intermediaries to add value for, if they could inspect the data?
PSA: This is being thought of as realtime data. But say you're doing IRC, why not do room history?
JH: SSL or TLS termination. Possibilities exist, let's talk about it
(some discussion missed... Larry Masinter commented)
PSA: The idea is not to tell intermediaries to go away, rather let's see what can be done.
3 - Chairs
Charter Proposal Overview
Proposed Charter (rev.3)
4 - Greg Wilkins
Short Term and Requirements Input
draft-loreto-http-bidirectional-01
Lucy Yong: Define hints or new requests?
GW: Provide extra headers in those requests to give notification that it will be long lived.
LY: So this is end to end, or for intermediaries as well?
GW: It will have to be carefully designed for hop to hop considerations.
5 - Michael Smith
W3C / WebSocket Prospective
draft-hixie-thewebsocketprotocol-54
- Christopher Blizzard (WebSocket API)
- Jeff Hodges: Is websocket intended to replace xmlhttp requests? (no) Could you delineate the differences? (it would take a while... read the draft)
- Ian Fette (google Chrome)
6 - Lisa Dusseault
WebSocket protocol in IETF
Dave Crocker: This sounds like a task and a topic and a protocol area that the IETF has worked on, that being BEEP.
BEEP really worked hard on solving problems that needed solved, and the criticism could be that it's too complicated and features could be removed.
Many features we think we don't need for simple initial cases, turn out to be essential.
Cullen Jennings: I'm glad BEEP got bought up, because that's an example of a protocol that probably won't get much deployment.
We need to figure out why that is. This isn't a poke at BEEP, BTW... we're good at adding complexity to the point things fail.
Greg Wilkins: Some of us are trying to take inspiration from BEEP.
Douglas Otis: We deal with a lot of infections on the net, and almost invariably the source is a compromised web server.
This seems like a major security hazard.
JH: It is an IETF expectation that security considerations be covered.
DO: That's still scary.
7 - Greg Wilkins
Other protocols and related use-cases
draft-wilkins-hybi-bwtp-00
Jeff Hodges: There are security issues with having sockets available in browsers. We have a paper about one particular issue, will forward to the list.
Ian Fette: This does not allow arbitrary socket connections; it's not quite that simple.
8 - All
Discussions
Greg W: Difference between XHR and websocket. XHR is definitely part of the browser environment, interacts with cache, etc.
Whereas websocket is something else, on purpose. On the security question, my concern is that with the websockets not being able to open an
arbitrary socket, people will likely create proxies... and that's something that should be in the security considerations, that's dangerous.
Chris Blizzard (missed comment)
Joe H: There's lots of stuff about http that not everyone knows, lets collect that.
?: What was previously mentioned was 'cores', a w3c webapps draft.
9 - ADs
Calling the questions
Barry Leba: Is the goal of a wg to come up with one way to do bidirectional stuff around http, or would multiple solutions be great?
Lisa/JH: this is discussed in the charter
Larry Masinter: I'm increasingly concerned about protocol work in the w3c that does not see sufficient ietf input, and I'm happy to see more collaboration.
Normally in a charter with short term and long term, the short term is a step to the long term... but this isn't, and looks like two wgs.
Lisa: If you separate semantic vs raw, and short term vs long term, we don't have 4 wgs, rather an intertwined system with overlapping concerns.
LM: If BEEP is too complicated, why not make it simpler, rather than layer complexity on something simple.
Ian Fette: I somewhat agree with Larry. Short term / long term, in terms of small changes, websockets are coming out any minute...
so the long term is really short term, do we have an inversion in the charter?
JH (individual mode): Certainly the wording can be tweaked; the intent was to separate things requiring browser changes from things that don't.
For things that don't, we have probably scoped things down far enough, and those things might be useful for browser changes too.
Barry Leba: Even when we're done, we might want multiple protocols, one solving the complex problem, one simple. Should we allow for that?
Lisa: I believe it should do so... improve the text!
Greg W: long term vs short term is confusing (especially since long term is imminent). The 'short term' solutions address different problems, though.
We should certainly address the commonality.
Lisa: WG should have two or three deliverables.
Lars Eggert: Two proposals, neither can die... classic problem
Lisa: drastically different
Lars: Do we need both?
Larry M: Maybe websockets is short term for shipping, long term for working. There were certain things put up in the critique as to requirements.
I don't think there will be total consensus, but there is value in documenting where each requirement actually applies.
And, some analysis of where complexity arises from requirements has value (transactional consistency)
Lisa: Does the problem space and use cases draft start to cover that?
Larry: Is there a decision point as to whether protocols meet agreed requirements? Because that might decide if there are one or two protocols?
Ted Hardie: (jabber) There were several +1s for two protocols. Also, this isn't about BEEP, this is about port 80.
We're already talking about two strands of evolution coming from HTTP, if they all run on one port we will likely run into complexity.
One requirement seems to be that two protocols look enough like HTTP that they can both run on the same port.
If we can't change ports, then we need one working group, and maybe one more complex protocol, because there is interoperability on port 80 to resolve.
If there is an easy way to split it out so there is only a need for subsets of the interop, then that's cool, but probably someone doesn't get port 80.
If everyone needs to run on port 80, then it's a different problem, and then we need the answer as to which it is.
JH: Since security considerations is presently blank, we can suggest that we not run on 80. Would that be enough?
Ted: I don't know.
JH: there's probably a way to do this that is secure and deployable.
Mark Nottingham (jabber): I would point out that WebSockets uses HTTP's Upgrade mechanism. Ted, are you saying that it needs to have equivalent semantics to do that?
Ted: Darn good question. I suspect we need to retain compatibility with on-path middleboxen, as that seems to be a requirement.
Spencer: Ted seems to be saying that we need this discussion at charter time.
Tim Shepard: Would you say all the middleboxen?
JH: The draft says how to talk to proxies, and that should work.
Lisa: Ironically, TLS punched a big hole in firewalls.
Barry L: At some level we're saying all apps are heading for 80 because of firewalls. This is worrying. We haven't done this in the IETF, and it's bothering to set that precedent.
Greg W: I believe these apps talk on 80 because they're web apps talking to a web server, and that they need bidirectional comms should not drive me away from port 80.
Ian Ferry: I really have no love or hate of 80 or 443, that doesn't matter. It just has to get through. It will be years before the intermediaries comply... sad, but pragmatic.
JH: You would be shocked at the number of XMPP servers on 443. The problem is not avoiding firewall policy, it's giving bidirectional comms to a browser programming environment
Lisa: there's a lot a wg could discuss about ports and recommendations; forcing everyone to use it is unlikely to fly
Hum: sad but pragmatic about port 80 (silence for against, strong for for)
JH: If there is a wg, chair can rule port number out of scope
Hum: port out of scope (clearly against)
Hum: websockets for IETF wg (for)
Lisa: long polling and hanging gets, so called short term
JH: describe and/or document?
Hum: long polling and hanging gets descriptive (weak for, weak against)
Lisa: Prescriptive means new behaviour to specify
Jon Petersen: which track?
Jon: Is this an endorsement?
Barry L: I would be against a standards track document that documents something known to be broken.
Cullen: Are we talking about giving advice as to how to use present hacks, and putting it on standards track?
JH: Current practice seems informational.
Mark Nottingham (jabber): hums lightly against the short term work; I think it can go in an independent doc, or even httpbis.
Hum: wg should not take on prop. std work on long polling and hanging gets (hum for, no support for against)
Barry: suggested in ietf, but not in the websockets wg
Hum: should the wg take on a longer-term higher level protocol than websockets as a second work item (weak for, not taken as conclusive)
John Klensin: Trying to interpret: maybe people are tired, but maybe the group has a clear understanding on one problem, and not on others. Therefore charter for one, leave others for later
Hum: wg for websockets (strong hum)
Hands for documents and/or wg chairs: Sufficient Some +1s from jabber.
NOTEs from Spencer Dawkins:
--------------------------
1 - Agenda bash / Goal and Purpose of the BoF
Chairs
Any agenda bashing? None observed.
Several presentations, please stay in your speaker's slots.
Want to defer non-clarification questions until open discussions later in the meeting.
2 - Design Space
Peter Saint-Andre
draft-loreto-design-space-bidirectional-00.txt
Want to do an architectural context that supports short-term solutions ("hacks") (Comet, BOSH, etc.) and
long-term solutions (WebSocket, BWTP, and Reverse HTTP) with native support for a bi-directional communications channel.
Need to remember that not all clients are browsers and not all servers are web servers - and there's a range of intermediaries.
We're changing HTTP patterns - server requests to clients, URIs on the client, message passing becoming part of REST style.
Is there interest in doing standard HTTP with plug-ins?
Are there clients supporting HTTP with extensions? Clients invoking non-HTTP transports? Don't think so yet, but we're looking.
Not just proxies - gateways, caching servers, load balancers, etc. Need to reach out to people who work in these spaces and get them involved.
Tunneling non-HTTP transport over HTTP CONNECT - is this abusive?
Upgraded intermediaries that might support for relaying of transports that invoke non-HTTP methods.
Are client resources only reachable from servers, or from third parties? Don't know yet, just raising this as an issue.
What sort of data being transmitted would an intermediary be adding value to?
IRC interactions might have room history of last 100 messages, for example. Might want to do SSL/TLS termination.
There are lots of possibilities here, need to have a discussion with these people in a room.
Need to at least add guidance about getting out of the way if you're not adding value.
3 - Charter Proposal Overview
Chairs
Proposed Charter (rev.3)
* Characterize design space
* Add new web browser feature (long-term)
* Minimize long-poll impact (short-term)
Follow-on work might include higher-level protocols with multiplexing and resource access, but that's not in the proposed charter now.
4 - Short Term and Requirements Input
Greg Wilkins
draft-loreto-http-bidirectional-01
Long polling is legal, but there are some overheads. Streaming is efficient, but isn't strictly "legal" HTTP.
Some mechanisms even do both (with fallbacks).
Why wasn't W3C Server-Sent Events successful?
Current mechanisms are widely deployed and successful, but there are significant problems - Bidirectional breaks HTTP Connection pooling.
Reserves a shared resource, starves because resource is limited, queue or pipeline behind a bidirectional request.
And the pool is often shared between frames/tabs/windows, and it's hard for the applications to share these resources.
Hard to know whether streaming will work (can't discover caching or buffering). Undisclosed idle timeouts that you can't recover from.
And it's hard to detect a closed connection.
Lots of headers aren't redundant for these connections. Pipelining isn't usable, and it's difficult to scale in intermediaries and servers
(they allocate resources per-connection, not per-active-connection).
Want to document best practices today.
Want to provide "hints" for bidirectional requests.
Hints would be part of normal requests and would identify long-lived connections.
5 - W3C / WebSocket Prospective
Michael Smith
draft-hixie-thewebsocketprotocol-54
W3C does support formation of this working group.
Do have implementations of both client side and server side.
WebSocket takes an HTTP stream and turns it into "something else" - no framing, no headers, ...
No way to send binary data - this is an active work item.
Would WebSocket replace HTTP request? No.
Very short draft, very simple. Will make this the default in Google Chrome on Friday.
Without WebSocket, character-at-a-time echoing turns into a kilobyte of data per character.
6 - RealWorld WebSockets
John Fallows
Using Java Messaging Server with unified programming model, scaling to 100,000 clients.
Using XMPP over WebSocket, again with 100,000 connections.
TCP for now, SCTP maybe later.
7 - WebSocket protocol in IETF
Lisa Dusseault
Think WebSocket really looks like IETF work. W3C giving favorable response on this.
Not even sure we can bind a working group to satisfy an existing APIJ. We'll need people to participate in W3C and maybe even publish documents there.
8 - Pent-up Questions?
Dave Crocker - Want dialog, not making recommendation. "Standing on each other's feet", instead of standing on the shoulders of giants.
This sounds like a topic that IETF has worked on before - why isn't this BEEP? Or why isn't BEEP this?
Need to be careful that we add enough - simple cases that we start with may get more complicated quickly.
Cullen - need to make sure we don't do what we did that caused BEEP to get so little deployment.
We're good at adding complexity to protocols until they fail.
Greg - will talk about BEEP in later presentation.
Doug Otis - is this a design for website compromise that will open up avenues of attack?
Where is the content of the security considerations section?
This is one of the things that a working group would actually think about.
9 - Other protocols and related use-cases
Greg Wilkins
draft-wilkins-hybi-bwtp-00
Greg has serious concerns about WebSocket protocol. Don't think it solves the problems he's having today.
See manifesto/rant on the mailing list.
Some client developers have very different perspectives than other developers (client/server/middlebox).
Don't think incremental improvements to HTTP is the right way to go. BEEP? Bidirectional Web Transport Protocol?
"Better" depends on perspective.
BWTP is inspired by BEEP, but it's a new protocol. Intermediaries are explicitly part of the architecture.
Make WebSocket better? Security, Shutdown, i18n, etc.
Make WebSocket more extensible? Needs extension points. Self-describing content, opaque to intermediaries, IANA allocation of frame times, SPI between application and protocol...
May have to do all of the above - "one size does not fit all".
There are some easy HTTP hints, we can make WebSocket extensible, and standardizing layered extensions.
Jeff Hodges - security issues. Have issues with making sockets available to a browser. Jeff will send a note to the list.
Security section would be a priority before WebSockets comes out of the working group.
Greg - WebSocket isn't talking about the same resources as HTTP, and that's intentional. If you can't open a WebSocket directly, people will create proxies themselves.
Joe - there are a lot of things about HTTP that some people know, but many people don't.
10 - Discussions
Should WebSocket become an application protocol?
"Upgrade" likely to mislead us.
Security considerations shouldn't be blank, and the working group wouldn't leave it blank - right?
Working group would bring together strange bedfellows - short, long-term, WebSocket vs something else...
there are multiple problems going on, would be a challenge for one working group but was OK in a BOF.
Barry Leiba - is a working group supposed to come up with one way, or multiple ways? Charter says "multiple".
Larry Masinter - not speaking for W3C, but have become increasingly concerned about W3C protocol work that hasn't gotten the right kind of review.
This short term isn't a step towards the long term - that's weird, recipe for deciding we need two working groups.
We don't have four working groups. We have a collection that covers much of four quadrants.
Why not make BEEP simpler, rather than start with something simple and start adding complexity?
Ian Fette - everyone is shipping WebSocket or at least seriously looking at it - does the short-term work have any legs?
Joe - tweak charter wording but intent was "things that require browser changes" vs. "things that don't". May have scoped "things that don't" down to a BCPish specification.
Barry Leiba - may want two protocols that we put together, one more complex than the other.
Lisa agrees ("improve the text").
Greg Wilkins - long term hitting the web in days. Short term solutions capture needs of people who need semantics in the exchange - long term solutions don't address that.
Lisa would love to hear about ways to simplify the work and its organization.
Lars Eggert - do we have two proposals that can't die, and now we need to decide which one should die?
Larry Masinter - maybe WebSockets ships short-term and works long-term?
Some requirements from the critique - not sure we have consensus,
but it would be good to write them down and figure out when these requirements apply (and what led to BEEP having complexity that you don't need).
Intermediate connections closing, etc. You don't need a complicated protocol until you actually need it to work.
Does Sal's document begin to address this?
Larry - is there a decision point on whether protocols proposed meet the requirements we're working on?
Ted Hardie - jabber room has several people +1ing for two protocols. This isn't about BEEP, it's about port 80.
This is two strands of evolution running on the same port - may run into complexity here. Is it OK if at least one protocol gets a new port number? If so, bueno.
If not, we may need one working group and maybe even one more complicated protocol. If there's a good way to split these, cool, but the result may be that someone doesn't get to use port 80 any more.
Joe - no security concerns in document at all yet, that's a good place to address Ted's concerns.
Ted is actually asking for the port 80 decision closer to the charter than to the security considerations section of the document. Spencer Dawkins agreed.
(Missed Tim Shepherd on firewalls)
Barry Leiba - we haven't said "we're gonna run stuff on port 80 because we have to" in the IETF yet, and it bothers me that we're headed that way now.
Greg - but it's still a web application.
Barry - but that doesn't mean it's an HTTP application.
Ian Fette - don't care about port 80, prefer 443, whatever works. It will be years before the intermediaries catch up with our recommendations and we'll use 443 in the meantime.
Joe - the goal is providing a bidirectional programming model, not punching holes in firewalls.
11 - Calling the questions
There are a lot of things that a working group could work on, but we have to accept reality. If we feel sad about using port 80, can we still be pragmatic?
Hum was "yes" with no opposition.
Larry Masinter - make port number out of scope until you're finished with the protocol.
Joe - chair would use that as a management technique.
Hums about making port number discussion out of scope were completely against.
Is WebSockets something a hypothetical working group should take on? Hum in the room was strongly yes.
Work on long polling/hanging GETs? (Define or document what's out there today?) Weak hums about being prescriptive (hints to do something new) in addition to descriptive.
Jon Peterson - are we going to describe, or endorse?
Barry - would be vehemently against a standards-track document that says what it is when we know it should have been better.
Cullen - give people advice about making a hack work in the best way possible as standards track?
Joe - that sounds more Informational than standards track.
Put this in HTTPbis? Lisa needs someone to make a proposal about what this working group should/should not do.
Mark Nottingham via jabber - this could be an AD-sponsored doc, or in HTTPbis.
Should not take on work on long polling/hanging GET? Hums were that no one thought that we should.
Larry - happen in the IETF, just not in the same working group.
Lisa - but we're not asking that today.
Should working group take on a second, longer-term, semantic higher-level-than-WebSocket deliverable? Hums were inconclusive.
John Klensin - energy to hum doesn't exist? Group has focus and agreement to do one of these items, but not to do the other?
Create a working group to do WebSockets? Strongly humming yes.
People to do the work, participate in multiple reviews, chair the working group? Think the energy level is barely sufficient, but it is sufficient.