HTTPBIS WG, IETF 83 SESSION 1 (TUESDAY) __Julian on -19 revision of httpbis presented changes made in p1-p5, p7-auth mention of new status code draft, soon to be RFC mention of 308 code draft, soon to be RFC Mark observed that the problem of on-the-wire bits being turned into uris is now a problem for someone else Larry masinter challenges the assertion that iri are working on this Mark/stpeter note that this is simply not a problem for _this_ working group Mark covers p6-caching changes Barry asks about changes to registry policies. If the changes are for consistency, if made for that reason alone, that is insufficient justification Mark provides some clarification - some cases have their own justification, others move away from the idea that a designated expert is required (and the difficulties associated with providing guidance are difficult to resolve) Eliot lear observes that "ietf review" is dangerous Mark suggests that a revisit later is probably wise, particularly since things might change on the 5226 front __Mark on WGLC status Larry masinter asks about interop reports Stpeter notes that RFC 6410 doesn't require these now Sean turner points out that interop reports are as easy as you want them to be Barry leiba: interop reports do uncover issues Mark: is comfortable with the status of interop, though issues continue to be found, would be happy to look at work if someone did an interop report On the question of the number of parts Carsten bormann[spelling?] advocates for one part speaker? advocates for part zero if the document is multiple parts Yngve suggests the split should be different to what currently exists, or a single document Larry asks for hums Mark says hums bad for this __open design issues #247 Andrew sullivan asks about maintenance plan for this sort of "status" field Mark describes a role that might be created for "curating" this sort of field Andrew asks for this issue to be deferred Eliot does like the idea #322 Plan is to close this one - no objections or discussion #266 Move outside and deal with it separately #340 Roy fielding this is already horribly broken if it appears Mark suggests that the spec text is adequate #312 done with 308 #347 already incorporated question from Carsten: does many include zero? answer: no #22 Roy describes that some types of responses contain things other than the resource, or the thing that you would get if you made a GET request to the request target; things like etag apply to the "selected representation" Mark asks if some sort of categorization is useful for these headers Roy says that these headers are marked as "selected representation metadata" and the changes touch p2, p3, p4 __WGLC tickets #241 Roy has added notes on how Apache implements this. order is most specific to least specific #350 Julian knows of some frameworks that make it difficult to do the right thing #307 Julian is concerned about special cases in Cache-Control; we can't change that #348 Addition to security considerations #349 Barry is OK with avoiding caps, as long as the right guidance is present __impromptu discussion on one part vs. 8 Murray K.: making a single, separate security considerations document could be used as a referenceable spec Barry: the IESG would have to review everything together anyway Roy: people should reference the considerations that apply to them, not like draft-snell-http-prefer-12, to pick on someone Roberto peon: not concerned about division Martin: http insiders aren't your audience, p0 is good for something else Willy: index is really important, wants security to be everywhere __new status Patrick mcmanus: have you talked to captive portal implementers? Mark: some people are implementing this __not HTTP/2.0 Peter: describe how thursday is going to work Mark: explains process for process for discussion of process SESSION 2 (THURSDAY) MN = Mark Nottingham (WG Chair) LE = Lars Eggert SF = Stephen Farrell PH = Paul Hoffman 1. Charter Review MN: What is 2.0? Basically, not wire-compatible with HTTP/1.x. But not "everything you might have ever wanted to do with HTTP. MN: In addition to 2.0 proposals, we want to solicit proposals for new authentication schemes. LE: There is the possibility of doing work at the IRTF, if appropriate. SF: If we do things in the Security Area, more likely to be Experimental RFCs PH: Clarifying question: do you want ones that work in the current framework, or you open to ones which would change the framework. Chair: There are a couple of questions to unpack there. My intuition is that if it does not work in 1.1, it is probably a show stopper. Existing practice is some of the reason we have problems, though, so it might happen. MN: We're chartered to develop output, not rubber stamp any input. MN: (1) Define a new serialization of HTTP on the wire MN: Make sure it could replace HTTP 1.1 MN: Define one or more new authentication schemes, or explain why not MN: Success Criteria... MN: Implementers have reasons to switch. Ways we can FAIL JH: Would you like a bigger list of risks? One thing to avoid is internationalization issues in URIs. MN: I'd like to not try to do too much. Step 1. Call for Proposals Asking for new serializations of HTTP semantcs & new authentication schemes., taking into account our charter reqs++ PH: I've heard "if WG chooses one proposal, I'll implement it, if more then one then not". Not sure that fits into this structure. MN: I think that applies to auth but not 2.0, different situation. Eliot Lear (EL): How does deployment fit in? Larry Masinter (LM): Perhaps might make sense to give deployment even higher priority over implementation. Salvatore Loreto (SL): Please also consider deployment in wireless environments. Tony Hansen (TH): I think implementation is a good way of vetting what's workable. Another good criteria is what is deploy*able*. Harald Alvestrand (HA): Also: "I have deployed it (and nothing bad happened)", and "I would not deploy it because X". Eric Rescorla (ekr): There is some possibility that stuff HTTPBIS wants to do will have ripple effects throughout the IETF. This might be the right place to gauge that. MN: Fair enough. This is when we would do liaison-type activity. MN: Exit criteria is one of the elements of re-chartering.] MN: This aggressive, but we don't want to spend our time spinning our wheels on this. MN: Would like to be able to talk about this around IETF 84 in Vancouver. Gabriel Montenegro (GM): Does the current charter talk about this timeframe? Peter St. Andre (PSA): The understanding between the IESG and the chair at this point was that we would not start with one of the proposals right now, but first establish the scope and requirements. Then re-charter to do the work. SL: Just to clarify, the consensus about the proposals will happen on the mailing list. MN: Yes, this will all be done on the mailing list. MN: Does this make sense? EKR: You had a timeline: the upcoming charter will not say "we will work on this protocol"? MN: It will establish a starting point, and the set of requirements. Roy Fielding (RF): Not a real believer in committee based protocol design; I would prefer a bake-off, rather than a committee based design. MN: We can have some elements of that. MN: This is not the bakeoff engineering task force. RF: I think we don't need to agree on one before rechartering. We could have multiple documents and then remove them one by one. MN: HUM: Instead of one starting point, multiple starting points? HUM: Some support. MN: HUM: And one starting point before rechartering? HUM: More support. Ted Hardie (TH): Might be good to publish some of the non-starting points as experimental specs. EL: (1) Might we have more than one endpoint? For example, purpose-built protocols for particular use cases? (2) Is it possible that one outcome could be zero proposals? MN: That is true, but I tend to think that other outputs would be done elsewhere. Concerned about working on multiple approaches, from a management perspective. Yoav Nir (YN): I think it would be much better if we had just one proposal to go with the next charter. If we have multiple at the time we go to recharter, we may have to decide to either delay or decide to start with multiples. LM: I can't imagine a less than 10 year period for 1.1 to go away. So software will gateway 1.1. Thus we're talking about an addition to 1.1, not a replacement. Thus there might be different profiles / protocols for different use cases. MN: We should steal some language from the security ADs. MN: It is a goal to start from a single one, but if we end up with multiple, we can work that out at the time. Ian Fette (IF): As the editor of web sockets, I certainly understand the problems with design by committee. But I think it may be a moot point. At some point we have to get to a point where there is a single document. IF: We already have four starting points (four documents). At some point we need to get to one document. I think it is fine to have a goal to get to that one document; if we can't, we can't, but it is a good goal. PSA: It will focus the mind. SL: My preference is a single starting point. It will be a mess otherwise, especially for people working on intermediaries and middleboxes. EKR: I am not sure why we are acting like this is something we have never done before; this is what we do all the time. Sometimes we put an artificial deadline, sometimes we do not. Of course, this is what we are going to do. This charter time is just accounting, and I don't care about that at all. We won't know until we see all the proposals. HA: Might want to let proposals go forward cleanly, not do lots of grafting and crafting. But this did not work too well with IPv6 and IKEv2. Better to kill off the candidates earlier rather than later. MN: This is the plan going forward, I think. Presentations... [see slides for most of the content] P1. SPDY (Mike Belshe) MB points out that Google, firefox/mozilla, other spdy contributors are committed to doing what's necessary to making the protocol meet needs of "broader community" EKR: How does this compare to TLS compression? MB: Does not compress the bodies. Only the headers, and it tries to avoid double compression of things like JPEG. EL: What does "domain" mean here? MB: It's a complicated answer. Basically what I meant by it, is where you would have had a connection pool. There is an exception to this, where people are doing domain sharding--splitting resources across multiple hostnames, in order to open up a bunch of connections, which is really one host. We've also added IP connection pooling, which allows us to bundle those under one connection. Roberto Peon (RP): Having one connection for mobile keeps the connection open longer for productive work. Richard Barnes: Also a problem with secure protocols that have broken authentication etc. Disambiguate types of security. P2. Speed + Mobility (Gabriel Montenegro) [No questions.] P3. Intermediary Requirements (Willy Tarreau) [No questions, time running short.] P4. Waka (Roy Fielding) Hannes Tschofenig: Even if we optimize the headers, that doesn't do anything for the payloads.Are you going to cover that? RF: Not in the next five minutes. :) SUMMARY MN: We have a lot to do in a reasonable amount of time. Focused, structured discussion on the list. Be constructive. Need people to work on proposals and metrics. I'm expecting TLS everywhere, interception proxies, header compression, how we upgrade from 1.x and roundtripping. New folks, please look at the Tao of the IETF list. We don't do voting. See the WG page on ietf.org. The editors are focused on 1.1, that is our top priority. Please prefix your subject lines to the list. I'm sure we'll meet in Vancouver. TH: Any chance for an interim meeting? MN: Yes.