BiDirectional or Server-Initiated HTTP Minutes Meeting : IETF78, Friday 30 July, 2010 Location: MECC, Maastricht, Berlin, 13:00 to 15:15 Chairs : Salvatore Loreto , Joe Hildebrand Minutes : S. Moonesamy Version 0.1 AGENDA A. Administrative / Agenda bash B. Way of working, how to measure consensus, drafts ownership C. Requirements: open discussion on the Active tickets D. the opportunity to have different framing/encoding E. Design discussion for WebSocket SubProtocols Meeting Report A. Administrative / Agenda bash Salvatore Loreto and Joe Hildebrand chaired the IETF78 HyBi Working Group meeting in Maastricht, Netherlands. S. Moonesamy was the scribe. Thomas Roessler, Julian Reschke and Cyrus Daboo were the Jabber scribes. Salvatore Loreto, WG Chair, brought the Note Well to the attention of the meeting participants and asked them to sign the blue sheets. S. Moonesamy will be acting as Working Group Secretary and Gabriel Montenegro will be the new editor of the Requirements draft. B. Way of working, how to measure consensus, drafts ownership Joe Hildebrand, WG Chair, explained that the goal is basically to get the drafts moving forward again and make forward progress towards a solution. Work on the Requirements document is going to be done in parallel with the Protocol draft. There isn't any gating; the documents will be synchronished upon publication. There has not been any decision yet on whether the Requirements draft will be published as a RFC. C. Requirements: open discussion on the Active tickets Gabriel Montenegro from Microsoft did a presentation on the Requirements draft issues. The focus was on fundamental issues. Four issues were addressed: (i) HTTP compliance (ii) Support for binary data (iii) Size of messages (iv) Sub-protocol support The WG Chair declared that there was consensus about HTTP compliance. The Web socket protocol will be HTTP compliant until the Upgrade exchange is completed. The focus is on leveraging existing HTTP based infrastructure. That does not mean couldn't investigate other alternatives, barring a rechartering. Anne van Kesteren from Opera Software commented on a note sent by Ian Hickson about doing the handshake for TLS baed on the TLS next protocol. That seemed in conflict with this. Martin Thompson mentioned that there is no need to worry about this for now. Ian Fette from Google asked whether this outlaws things like next protocol negotiation. Joe Hildebrand pointed out that is not the intent of the statement from the Chairs. Gabriel Montenegro discussed about HTTP upgrade in relation to the Websockets protocol. It is HTTP up to the HTTP upgrade; then it is Websockets. The WG Chair stated that there will be an announcement on the mailing list about the formal declaration of consensus. The second issue (#8) is about support for binary data in addition to textual data. There was no formal declaration of consensus on this issue yet. Binary support will be required by JS APIs by the time the WG is done with the protocol. There will be a requirement to use this for non-browser scenarios. The next issue (#7) was size of message and/or total message size. Gabriel mentioned that there was some confusion when he read the original Requirements document. There is lots of interest in having chunking for the contenanation of the chunk mechanism. Assuming that we do binary support, it would be pretty complex not to support a length for the binary case. People seem to want one frame that will accommodate both. Anne van Kesteren commented that that it would be nice to know how binary will be done before finalizing the protocol bit. He would like to know what would be exposed to Javascript. He stated that he can understand the non-browser case. Julian Reschke answered a question from Dave Cridland by saying that the API does not have to lead the protocol in all cases. Joe, speaking from the floor, agrees with having a difference between the API and the wire protocol defined in the specification. He is sensitive to the fact that there are needs for the API as long as we know the things that have to be signalled. Martin Thompson disagreed with Joe and pointed that the client and server understand what each other is talking about at the apps layer. He also mentione dthat there is no concept of textual frame. Whether the content is text or not depends on the application semantics. Ian Fette disagreed with Anne's original statement. There was a requirement from a large number of people in the room to send binary data. Joe mentioned that the binary needs some type of length encoding and escaping the sentinel has not been one of the best solutions and asked whether two wire encoding were needed. Jack Moffitt didn't think it needs to be required that both representations be supported in an specific implementation. Gabriel moved to the last issue (#9) about sub-protocol support. It should be possible to support other protocols by using the sub-protocol mechanism rather than HTTP upgrade. Joe asked whether there was anything else from a requirements standpoint. Peter St Andre as Area Director stated that we do not want to modify HTTP. Mark Nottingham pointed out that identifying sub-protocols is a huge discussion. Joe asked for a show of hands on whether the group should start talking about the framing mechanism or sub-protocol. Joe, as individual, mentioned that he has seen some good proposals about counted length and network-order integers on front. Going through the different possibilities, if octets are not counted properly, let's put a sentinel at the end. Ian Fette said that it should not be hard to do that. Eric Rescorla mentioned that it is not an issue if people are too stupid to count. Having one way of doing things is really nice. Cullen pointed out that no one can ever agree on how to do sentinels. Joe mentioned that most languages have a difference between UTF-8 and octets. Jack Moffitt said that high level languages often have a length() which is characters. Yngve Pettersen perferred to have the sender learn to count or do chunked encoding. The Chairs asked for a hum on: (a) Do we want to support binary data and nothing else (b) Should we disallow binary data? The sense of the room was to support binary data and nothing else. There were a discussion about whether a protocol can be used for evil and Henning mentioned that people that want to be evil will use base64. The Chair asked for a raise of hands if people think that a rehum is needed before declaring that there was pretty strong consensus in the room. The Chair asked whether to have a sentinel based mechanism and a length count mechanism. Dave Cridland was of the view that marking UTF-8 and binary distinctively might well be important. Ralph Meijer pointed out that if we rely on the sentinel to fix stuff, then there is something wrong. Doug Otis raised an issue about TCP checksum failures and the Chair declared that fixing TCP was out of scope. Anne mentioned that a colleague raised a concern out of band that if we just dismiss Hixie's concerns with a learn to count, we reach an impasse. It was pointed out that it is particular important on who's concerns are raised. The Chair asked for a hmm on should we have both a length based and sentinel based approach and asked the following questions: (a) Should we have a single mechanism? (b) Should we have two separate mechanisms? There was strong consensus in the room for the first. It was the strongest sense in the Jabber room as well. The Chair asked whether the group should talk about what the mechanism is. Yngve Pettersen commented on how length should be indicated; there are a couple of options. One is TLS. Another option is to have length line followed by number of bytes. He thinks that three byte length is more than enough. Eric Rescorla did not see any sense in having chuncks and frames. Ian Fette commented on the implicit assumption regarding relationship between frames and messages and said that it is not clear to him at this point whether there is a one to one relationship. Mark Nottingham mentioned that in HTTP design, there is a lot of implicit assumptions. According to Jack, chunking also buys you reduced latency. Large messages prevent small messages from getting through. If they are all chunked small, the little things will make it reasonable quickly. Example: avatars in-band in XMPP prevent presence reception, etc. Yngve Pettersen asked whether message concept should be above the websocket frame. According to Joe, message-based was a W3C requirement. The second session started with a discussion about sub-protocols. Is the assumption that the sub-protocol require negotiation before the upgrade event? Eric Rescorla asked whether sub-protocols are layered or orthogonal. Ian Fette pointed out that round trips are very expensive. Anne stated that sub-protocols are application layer. He asked why it was considered controversial to have chunked encoding. In response to a question from Mark, Joe said that we may want to have miultiple frames that make up one message. He then asked whether there any more discusion about whether we should use a contant or variable lenght field. Ian Fette was very much against saying that messages are a fixed size that is reasonably small. According to Joe, the intent from an API pespective when you get one notiification it contains only one message in it. The Chair asked for a hmm on the following: - "Message" is a protocol unit with an end - A message may be composed of one or more "frame"s - Each frame has a length indication, encoded in a fixed number of bits (where that lengths is fixed in the specification to be written) The consensus of the room was for the above. There was a hum on: (a) whether a message should be made of one or more frames? (b) whether each message should be composed on precisely one frame The sense of the room was for the first question. The Chair asked for a hum on: Should the message has a length? Each frame has a length indication encoded in a fixed number of bits (where the length is fixed in the specification to be written). and it was the room consensus. The Chair asked Anne to list his concerns. Sentinel framing and normal framing was one. Anne mentioned that several browsers are already shipping their implementation. We can do some breakage. The quicker the protocol is settled the better for us. He also mentioned that he will follow what other browsers do. There was some discussion about a four week timing for framing, handshake and compression. There was a hom on whether it could be specified within the next month and it had the consensus of the room. The Chair stated that the group has made a ton of progress and the decisions will be taken to the list. Alexey Melnikov, Area Director, suggested a separate message for each consensus call. The Working Group session ended at 15:15.