IETF
httpbis
httpbis@jabber.ietf.org
Wednesday, 1 August 2012< ^ >
stpeter has set the subject to: IETF HTTPbis Working Group | IETF 84 | audio: http://ietf84streaming.dnsalias.net/ietf/ietf847.m3u
Room Configuration

GMT+0
[00:27:35] Eliot Lear joins the room
[00:29:11] tlr leaves the room
[00:34:40] wseltzer leaves the room
[00:59:25] Eliot Lear leaves the room
[00:59:44] Martin Thomson leaves the room
[01:48:44] wseltzer joins the room
[01:53:46] tlr joins the room
[02:27:29] tlr leaves the room
[02:41:21] wseltzer leaves the room
[02:53:07] wseltzer joins the room
[04:23:52] wseltzer leaves the room
[10:57:53] wseltzer joins the room
[11:51:55] wseltzer leaves the room
[11:58:24] tlr joins the room
[13:05:37] wseltzer joins the room
[13:20:27] wseltzer leaves the room
[14:31:06] tlr leaves the room
[14:37:22] tlr joins the room
[15:06:09] tlr leaves the room
[15:42:43] Martin Thomson joins the room
[15:53:05] Martin Thomson leaves the room
[16:03:17] Martin Thomson joins the room
[16:06:32] tlr joins the room
[16:36:14] tlr leaves the room
[16:44:01] tlr joins the room
[17:04:26] tlr leaves the room
[17:05:53] tlr joins the room
[18:22:59] Martin Thomson leaves the room
[18:29:15] tlr leaves the room
[19:20:47] bhaw joins the room
[19:34:59] tlr joins the room
[19:39:19] ylee joins the room
[19:48:22] christoffer.holmstedt joins the room
[19:48:53] tfossati joins the room
[19:53:37] kazubu joins the room
[19:55:32] Ted Hardie joins the room
[19:56:11] hildjj joins the room
[19:56:58] Ryan Sleevi joins the room
[19:57:47] m&m joins the room
[19:57:55] mcmanus joins the room
[19:59:05] stpeter joins the room
[19:59:30] stpeter has set the subject to: IETF HTTPbis Working Group | IETF 84 | audio: http://ietf84streaming.dnsalias.net/ietf/ietf848.m3u
[20:02:13] mcmanus leaves the room
[20:02:13] hildjj leaves the room
[20:02:13] kazubu leaves the room
[20:03:07] yuioku.yj joins the room
[20:03:35] <stpeter> heh, the audio for the first HTTPBIS session only played in the left channel, and the second session is playing only in the right channel :)
[20:04:07] <Ted Hardie> At the note well slide. We are using the short, hip version.
[20:04:20] <Ted Hardie> It's wearing dark glasses and riding a fixie.
[20:04:56] <stpeter> sigh, the only slides at https://datatracker.ietf.org/meeting/84/materials.html#wg-httpbis are for status code 451
[20:05:03] Michael Tüxen joins the room
[20:05:05] <Ted Hardie> BCPs have not changed; by being here, you agree to play by their rules (25, 78, 79)
[20:05:10] yoav.nir joins the room
[20:05:16] hildjj joins the room
[20:05:24] tlr leaves the room
[20:05:39] <Ted Hardie> Where we are: last time we agreed to solicit for proposals, SPDY, S+M, Network-Friendly Upgrade came in.
[20:05:48] mcmanus joins the room
[20:05:52] barryleiba joins the room
[20:05:56] <Ted Hardie> Today, we are here to discuss and work out how to move forward.
[20:06:11] <hildjj> If you'd like us to channel your comment into the room, please prefix your statement with "mic:"
[20:06:16] dthaler joins the room
[20:06:53] <Ted Hardie> But before that, a sanity check: ws-* seemed like a good idea at the time; pipelining is getting deployment
[20:07:10] <Ted Hardie> We have a huge investment in things as they are; there are also opportunity costs.
[20:07:23] <Ted Hardie> Mark is comfortable now, though he has gone back and forth on this.
[20:08:01] <Ted Hardie> He believes that with these ideas and the current state, he is comfortable with the 2.0 work going forward now.
[20:08:33] sludin joins the room
[20:08:44] <Ted Hardie> Larry Masinter: I think looking at the future of HTTP 2.0 is a great idea (the charter may not, but we're not discussing that now)
[20:09:04] sludin leaves the room
[20:09:25] <Ted Hardie> Discussion of expressions of interest, then charter drafting is today's agenda. Reminder: all decisions are ratified on the list. Charter draft must be ratified by the IESG.
[20:10:25] <Ted Hardie> Mark believes that there is clear consensus that the basis of our approach should substantially be draft-mbelshe-httpbis-spdy
[20:10:41] <Ted Hardie> Question to be how to structure it as the basis.
[20:11:07] <Ted Hardie> just SPDY; pick-and-choose, start with HTTPbis p1; SPDY with instructions/caveats/inputs
[20:11:17] kazubu joins the room
[20:11:52] <stpeter> :)
[20:11:57] christoffer.holmstedt leaves the room
[20:11:59] <Ted Hardie> From Mark's standpoint: he does not believe we should start from a clean slate. We don't need to have an incredibly restrictive charter—but the consensus should happen in the working group, not in the charter bashes
[20:12:04] sftcd joins the room
[20:12:16] <Ted Hardie> His favorite: SPDY with instructions/caveats/inputs
[20:12:20] <Ted Hardie> Any other thoughts?
[20:12:29] <Ted Hardie> (Larry's opinion is solicited by the chair)
[20:12:53] <stpeter> heh
[20:12:59] <Ted Hardie> Larry: starting with a starting point without knowing what you are optimizing and for whom is procedurally a mistake.
[20:13:01] christoffer.holmstedt joins the room
[20:13:42] <Ted Hardie> I'm happy with the process you've outlined, but the starting point is not clear: performance, reliability, privacy? For some of these there is not enough to make a choice.
[20:13:49] <Ted Hardie> (sorry, that was larry)
[20:14:08] <Ted Hardie> Mark: if we had more data, would we make a different choice?
[20:14:16] frodeki joins the room
[20:14:19] richard.barnes joins the room
[20:14:26] <Ted Hardie> Larry: possibly, but not clear that the guidelines are well formed.
[20:14:36] <Ted Hardie> Larry: example: sniffing; can we turn it off for 2.0
[20:14:40] <stpeter> .
[20:14:53] danwing joins the room
[20:14:57] <richard.barnes> cullen
[20:15:00] <stpeter> .
[20:15:08] <Ted Hardie> Sean Turner: Maybe on of the things we can do is publish SPDY as an Informational, to get it out as a stable spec.
[20:15:14] <stpeter> (sorry, testing audio lag, seems to be about 20 seconds)
[20:15:16] <Ted Hardie> Mark: I think SPDY is still evolving.
[20:15:32] lef.jpn joins the room
[20:15:38] Atarashi Yoshifumi joins the room
[20:15:54] <sftcd> @psa: did you just invent NTP/XMPP?
[20:16:05] christoffer.holmstedt leaves the room
[20:16:12] <Ted Hardie> Ian: No objection, but don't get what publishing SPDY would get you. People have access to SPDY if they want to implement. How does it help get us toward HTTP 2.0. Better to focus on what needs work, areas that we need to pay attention to.
[20:16:26] Sean Turner joins the room
[20:16:32] sludin joins the room
[20:16:32] Cullen Jennings joins the room
[20:16:36] <Ted Hardie> Pete Resnick, covering his dot. Agrees with Ian; publishing as informational is just delaying.
[20:17:02] christoffer.holmstedt joins the room
[20:17:05] <Ted Hardie> Pete: Chair has two options: start with a new doc and take suggestion; start with a doc and take objections/diffs.
[20:17:20] <Ted Hardie> Pete: Not seeing why the second is a concern.
[20:17:33] <Ted Hardie> Pete: don't see why we shouldn't start with a base spec.
[20:18:21] <Ted Hardie> Mark: I'm happy to start with a base document, adding incrementally and pulling from other documents. SPDY seems like it is hitting a lot of the right issues. The end document may look a lot different, but that's expected.
[20:18:34] <Ted Hardie> Eliot Lear: he has a mixed opinion.
[20:18:44] Martin Thomson joins the room
[20:18:59] Justin Uberti joins the room
[20:19:02] <Ted Hardie> Eliot: He would like to start with a description of the problems/goals.
[20:19:11] <Ted Hardie> Eliot: aim spdy at those goals.
[20:19:25] <Ted Hardie> (discussion of encryption deferred)
[20:19:37] <Ted Hardie> Next phase of this is the charter, concerns may be addressed there.
[20:20:02] <Ted Hardie> Roy Fielding: it would be good to work on SPDY as SPDY, as a mechanism for tunneling HTTP through to account based services; it is very good at that.
[20:20:42] <Ted Hardie> Roy: I think it is a mistake to design things to be generic from the start; HTTP did that and it has warts. If we want to make SPDY that ugly, we can, but not sure why we would want that.
[20:20:55] SM joins the room
[20:21:20] <Ted Hardie> Roy: would be better to have it focused on its use case; if other people want to start different efforts, those could be valuable to. SPDY could be a standard on its own, not as HTTP 2.0.
[20:21:49] <Ted Hardie> Roberto: The idea behind what SPDY was: changes wire representation, but leaves everything else as it was for HTTP. That has had some benefit.
[20:21:59] christoffer.holmstedt leaves the room
[20:22:10] <Ted Hardie> Roberto: I believe what we are doing here is HTTP 2.0—same semantics
[20:23:11] christoffer.holmstedt joins the room
[20:23:13] <Ted Hardie> Patrick McManus: I have implemented off many of these, and my opinion is that it doesn't really matter what we start with. There are advantages for starting as HTTPbis ; starting there as the scope may have the least confusion.
[20:23:34] Satoru Kanno joins the room
[20:23:35] <Ted Hardie> Mark: I think we should focus on what is p1, not revising in p2 or p3
[20:23:45] <Ted Hardie> (is in p1).
[20:24:08] <Ted Hardie> Mark: Roy reminded me of a discussion with Barry the other day in which it is good to have clarity on what the expectation.
[20:24:23] gmandyam joins the room
[20:25:07] Michael Tüxen leaves the room
[20:25:07] <Ted Hardie> Mark: is our thinking that http 1.1 and http 2.0 will coexist indefinitely, that 2.0 will cover the full suite of use cases covered in http 1.1?
[20:25:18] Michael Tüxen joins the room
[20:25:30] <Ted Hardie> Mark: there may be many things that we do not cover (interception proxies, backend systems).
[20:25:49] <Ted Hardie> Mark: major orphaned use cases should be avoided. We should eventually (20 years) cover them all.
[20:26:25] <Ted Hardie> Larry: I don't love interception proxies; people by them and use them
[20:26:37] christoffer.holmstedt leaves the room
[20:26:49] <hildjj> Mark: we will have a 5m conversation about interception proxies
[20:26:56] <m&m> Ted Hardie at the mic
[20:27:06] christoffer.holmstedt joins the room
[20:27:25] <hildjj> Ted: interception proxies are used because we don't offer an explicit way of solving the use case
[20:27:26] =JeffH joins the room
[20:27:33] <hildjj> Larry: it should be a part of the charter then
[20:28:05] <hildjj> Ted: SPDY is nice as a starting point; it's nice to have that to frame the discussion.
[20:28:12] <hildjj> Ted: Not starting from a clean slate is important
[20:28:14] Yves Lafon joins the room
[20:28:29] <hildjj> Ted: we'll make faster progress if we don't clean slate
[20:29:04] <Ted Hardie> Mark: Ted reminded that we may need to take up other elements, like proxy.pac to get some elements of the work done.
[20:29:16] <Ted Hardie> Saltvatore: interception proxies are used in telephone networks a lot.
[20:29:29] <Ted Hardie> Salvatore: having said that, we see some benefit from SPDY
[20:29:30] <Sean Turner> starting at a blank slate will add a year to the process
[20:29:57] <Ted Hardie> Salvatore: I sent out an expression of interest; he suggests pick and choose—picking mostly from SPDY
[20:30:19] <Ted Hardie> Salvatore: even better, take the SPDY proposal and remove the controversial parts
[20:31:32] <Ted Hardie> Mark: I see the difference between that and the SPDY with instructions as determining things before, versus determining as we go along. I think I'd rather we do it as we go.
[20:31:40] lef.jpn leaves the room
[20:31:55] <Ted Hardie> Larry: I'd rather start with the caveats and instructions than the starting point
[20:32:06] <Ted Hardie> Mark: we agreed in Paris to start with a starting parting.
[20:32:11] <Ted Hardie> Larry: okay
[20:32:42] <Ted Hardie> Eliot: The encryption issue is an elephant in the room; this starting point may have an impact on this
[20:32:59] <Sean Turner> okay so I'm convinced don't both publishing spdy on inf
[20:33:03] <Ted Hardie> Mike Belshe: proxies don't have a strong issue with SPDY, they have one with TLS, but SPDY doesn't mandate TLS
[20:33:18] <Ted Hardie> Mark: Agreed, the document does not mandate SPDY
[20:33:29] Martin Thomson leaves the room
[20:33:35] <hildjj> Speaker was Rob Trace from Microsoft
[20:33:38] yoav.nir leaves the room
[20:33:42] barryleiba leaves the room
[20:33:43] christoffer.holmstedt leaves the room
[20:33:50] <Ted Hardie> Rob Trace: encryption issue is a distraction; focus on multiplexing and let's get going
[20:33:54] =JeffH leaves the room
[20:33:55] hildjj leaves the room
[20:33:59] hildjj joins the room
[20:34:17] <Ted Hardie> Rajeev Bector: can we talk about the goal
[20:34:30] christoffer.holmstedt joins the room
[20:34:34] =JeffH joins the room
[20:34:39] Ryan Sleevi leaves the room
[20:34:52] <Ted Hardie> Mark: get consensu
[20:35:08] barryleiba joins the room
[20:35:10] <Ted Hardie> Mark: maintain deployability
[20:35:18] <hildjj> mark: modernized security, ensure it's no more difficult to deploy
[20:35:23] <Ted Hardie> Mark: improve security
[20:35:30] <hildjj> Mark: maintain all of the existing actors
[20:35:32] Ryan Sleevi joins the room
[20:35:44] richard.barnes leaves the room
[20:35:59] <Ted Hardie> Mike Belshe: we have the same question: does this replace all of HTTP 1.1?
[20:35:59] lef.jpn joins the room
[20:36:35] <Ted Hardie> Mike Belshe: everything that runs over 1.1 should be able to run 2.0. But that doesn't mean everyone will change.
[20:36:54] <Ted Hardie> Mike Belshe: There may be cases where you can't make improvement for every uses.
[20:37:08] <Ted Hardie> Mark: yes, but I don't want to drop use cases because "they can use 1.1"
[20:37:28] <Ted Hardie> Mike Belshe: there are cases that are hard (youtube) where it may not fit the use case.
[20:37:34] lef.jpn leaves the room
[20:37:43] <Ted Hardie> Mark: remind folks of your affiliation
[20:37:54] <Ted Hardie> Mike: I have not worked at Google for a year.
[20:38:16] richard.barnes joins the room
[20:38:26] lef.jpn joins the room
[20:39:02] <Ted Hardie> Gabriel Montegro: would still prefer from starting from a clean slate. If someone is asleep at the helm, you may not end up cutting things that actually are controversial. Add only as you need, rather than starting from really big and cutting down. He doesn't believe that works as well as starting only from what is justified and agreed upon.
[20:39:42] <Ted Hardie> Ian Fette: I think we may be talking past each other. There likely are things in the SPDY spec. that we do not have consensus on.
[20:39:43] resnick joins the room
[20:39:46] tlr joins the room
[20:40:08] lef.jpn leaves the room
[20:40:49] <Ted Hardie> Ian Fette: If we start with "pick and choose", we could do a patchwork (which might not read well) from multiple drafts to create an input draft. Or we can start from one and mark different sections as needing discussion. That seems to get us to a working draft much faster.
[20:41:09] lef.jpn joins the room
[20:41:16] <Sean Turner> +1 to what ian said
[20:41:32] <Ted Hardie> Rajeev: people who control their destiny are one user community; then there are user communities that depend on intermediaries. We need a balanced approach that covers all stakeholders.
[20:42:07] <Sean Turner> it's in a WG draft by definition we don't have consensus on it
[20:42:15] <Ted Hardie> Joe: I came up to agree with Ian, with the caveat that we must maintain backward compatibility with SPDY. As long as nobody is going to argue that.
[20:42:22] <Ted Hardie> Joe: then, I am fine.
[20:42:30] <Ted Hardie> Mark; that should be a given
[20:42:39] <Ted Hardie> Joe: actually not; can be chartered other way
[20:43:09] ylee leaves the room
[20:43:09] <Ted Hardie> Patrick: we will be actively pushing old versions of SPDY off the web; that's been clear during this phase.
[20:43:34] <Ted Hardie> Mark: Just to clarify, backwards compatibility is a non-goal; will clarify in the charter.
[20:44:16] <Ted Hardie> Leif: do we want to call consensus on that last point?
[20:44:24] <Ted Hardie> Mark: will do so as part of charter discussion.
[20:44:36] <Ted Hardie> Mark: now reviewing charter sent to the mailing list
[20:44:56] <Ted Hardie> Adds a new work item for http 2.0,
[20:45:17] barryleiba leaves the room
[20:45:33] barryleiba joins the room
[20:45:42] <Ted Hardie> The Working Group's specification deliverables are:
* A document (or set of documents) that is suitable to supersede RFC 2616 as
  the definition of HTTP/1.1 and move RFC 2817 to Historic status
* A document cataloguing the security properties of HTTP/1.1
* A document (or set of documents) that specifies HTTP/2.0, an improved
  binding of HTTP's semantics to an underlying transport.
[20:46:00] <Ted Hardie> It is expected that HTTP/2.0 will:
* Substantially and measurably improve end-user perceived latency in most
  cases, over HTTP/1.1 using TCP.
* Not require multiple connections to a server to enable parallelism.
* Require no more configuration or tuning than current HTTP deployments;
   preferably, less.
* Retain the semantics of HTTP/1.1, leveraging existing documentation (see
  above), including (but not limited to) HTTP methods, status codes, URIs, and
  where appropriate, header fields.
* Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in
  intermediaries (both 2->1 and 1->2).
* Clearly identify any new extensibility points and policy for their
  appropriate use.
[20:46:27] <Ted Hardie> Joe Hildebrand: Do we want to add something about congestion control, as a motivator?
[20:46:29] <Ted Hardie> Mark: sure.
[20:46:49] <Ted Hardie> Mark: "improving the use of TCP, especially regarding congestion control" to be wordsmithed
[20:47:12] <Ted Hardie> The resulting specification(s) are expected to be meet these goals for common
existing deployments of HTTP; in particular, Web browsing (desktop and
mobile), Web serving (at a variety of scales), and intermediation (by proxies,
corporate firewalls, "reverse" proxies and Content Delivery Networks).
Note that this does not include uses of HTTP where non-specified behaviours
are relied upon (e.g., connection state such as timeouts or client affinity,
and "interception" proxies); these uses may or may not be enabled by the final
product.
[20:47:29] <Ted Hardie> Explicitly out-of-scope items include:
* Specifying the use of alternate transport protocols. Note that it
  is expected that the Working Group will define how the protocol is used
  with the TLS protocol.
* Specifying new semantics for HTTP (whether specific to HTTP/2 or not).
  However, the Working Group may request a re-charter to start work on such
  items (during or after work on HTTP/2.0), provided there is consensus to
  do so, and it does not interfere with work on the "core" (both HTTP/1.x and
  HTTP/2.0).
[20:48:02] <Ted Hardie> Mark: Possibly adding a specific "out of scope" for p2-p7
[20:48:18] <Ted Hardie> List of specific issues:
[20:48:20] <Ted Hardie> Mandatory TLS
[20:48:23] <Ted Hardie> Header Compression
[20:48:28] <Ted Hardie> Upgrade/Handshake
[20:48:30] <Ted Hardie> Server "push"
[20:48:33] <Ted Hardie> Flow control
[20:48:36] <Ted Hardie> Security properties
[20:48:59] <Ted Hardie> Let's get out of the way the mandatory TLS issue
[20:49:09] <Ted Hardie> Mark: we don't have consensus on this
[20:49:19] <Ted Hardie> Mark: the current uses of spdy require the use of TLS
[20:49:34] <Ted Hardie> Mark: discussing this with the authors and implementors, I think we may have a way around this
[20:50:14] barryleiba leaves the room
[20:50:18] <Ted Hardie> Mark: if we take the approach that HTTPS URLs should work the same in the two versions, we're actually pretty close (modulo NPN)
[20:50:26] barryleiba joins the room
[20:50:29] <Ted Hardie> The issue is "http" not "https" URLs.
[20:51:04] <Ted Hardie> Mark: a real negotiation may be needed, with "optimistic TLS" as a possibility
[20:51:29] <Ted Hardie> This would block passive eavesdropping , but does not provide certificate-checking
[20:52:14] <Ted Hardie> Mark: charter impact is to include negotiation mechanism, potential coordination with others, All* other discussion of topic out of scope
[20:52:48] <Ted Hardie> Mark: how many people have read the "tussle" paper?
[20:53:09] <Ted Hardie> Mark: it's a good explication of how these issues arise and might be resolved
[20:53:21] Eliot Lear joins the room
[20:53:26] <Ted Hardie> Larry: it was my impression was that the primary issue was a deployment issue
[20:53:35] <Ted Hardie> Mark: some people have put that forth.
[20:53:52] danwing leaves the room
[20:54:14] <Ted Hardie> Larry: I have heard it as significant issue. As stated, this would make deployment considerations out of scope. That's what this says to me.
[20:54:17] <Ted Hardie> Mark: that's not the intent
[20:54:43] <Ted Hardie> Larry: nowhere in the charter is there a mandate to document deployment considerations
[20:54:44] danwing joins the room
[20:54:51] <Ted Hardie> Mark: do you want to hear from Mike?
[20:55:28] Cullen Jennings leaves the room
[20:55:30] <Ted Hardie> Mike: of course deployment considerations are important. Even subtle things can be issues, so we understand this. Going over TLS is a deployment factor.
[20:56:02] <Ted Hardie> Mike: there haven't be any ways to put new protocols over port 80. Even changes over TLS are hard.
[20:56:16] <Ted Hardie> Mike: But it kind of doesn't matter from the protocol specification
[20:56:39] <Ted Hardie> Jim Gettys: I think the primary motivation is fine.
[20:57:07] <Ted Hardie> Jim: in some parts of the world, caching is a necessary thing; to the extent this hurts caching, this is an issue.
[20:57:57] <Ted Hardie> Mark: One of my primary concerns is caching, but this still allows both configured and gateway proxies to cache. Interception proxies are not as useful, but that's not here.
[20:58:09] <Ted Hardie> Yoav: NPN was not accepted by TLS
[20:58:25] <Ted Hardie> Mark: don't want to discuss the politics of other groups.
[20:58:34] <Ted Hardie> Yoav: don't see how that will work over port 80
[20:58:39] <Ted Hardie> Mark: doesn't say port 80 there.
[20:59:05] yoav.nir joins the room
[20:59:06] <Ted Hardie> Rajeeve: The site owner can't control when clients negotiation.
[20:59:17] <Ted Hardie> Mark: This gives both sides power
[20:59:30] <Ted Hardie> Rajeev: there are three parties here: clients, servers, content owner
[20:59:45] <Ted Hardie> Rajeev: this will be an impediment to deployment
[21:00:08] <Ted Hardie> Mark: impediment to "optimistic" TLS
[21:00:13] <Ted Hardie> Rajeev: yes
[21:00:24] barryleiba leaves the room
[21:00:39] <Ted Hardie> Mark: optimistic TLS will not show as secure in browser chrome etc.
[21:01:04] <Ted Hardie> ekr: as chair, note TLS still has not accepted this work, so building on it a bit worrying
[21:01:34] barryleiba joins the room
[21:01:48] <Ted Hardie> ekr: as individiual, this might be used to break existing connections that are TLS protected; negotiation is a good idea, but this might not be it.
[21:02:16] <Ted Hardie> PHB: I don't like it when application layer protocols do a half-assed job of security.
[21:02:34] <Ted Hardie> PHB: Why pick only one attack (passive attacker) and address only that?
[21:02:48] <Ted Hardie> PHB: There is no web browser I'm aware of that doesn't have TLS today.
[21:03:06] <Ted Hardie> PHB: those that don't have it have a different security model
[21:03:14] <Ted Hardie> Mark: there is not a mandate here.
[21:03:32] <Ted Hardie> PHB: if it is not mandatory, why is it called that?
[21:03:41] <Ted Hardie> Mark: just slide title, that'a red herring
[21:03:59] <Ted Hardie> PHB: Mandatory to implement?
[21:04:01] <Ted Hardie> Mark: no
[21:04:12] <Ted Hardie> PHB: head explodes
[21:04:27] <Ted Hardie> Roberto: if we put a question mark in the title of the slide, it becomes accurate
[21:05:02] <Ted Hardie> roberto: on the caching thing, yes we do need to consider caching. Even under the SPDY work, we have been thinking of this; have an id out.
[21:05:30] <Ted Hardie> Patrick: I want to re-iterate that making explicit proxies a bigger part of this; there are value-added services possible there.
[21:05:48] <Ted Hardie> Patrick: that's both for wpad and pac; we need to serve better, we're not trying to eliminate them
[21:06:11] <Ted Hardie> Patrick: it would be my preference for TLS everyhwere; if there is an actual person there, there needs are paramount
[21:06:32] <Ted Hardie> Patrick: but this is a workable way to move forward.
[21:06:39] <sftcd> PHB is right that this is not privacy
[21:06:48] <Sean Turner> +1
[21:07:06] <Ted Hardie> Tim: more or less plus 1; this is a reasonable compromise
[21:07:25] <Ted Hardie> Elliot Lear: let's be clear on what we're getting: only sniffing problem
[21:07:56] <Ted Hardie> Elliot: I don't think that solves Mike's big problem—new feature. These things in the middle are the first things that need to negotiate
[21:08:08] <Ted Hardie> Paul Leech: I applaud the attempt to get out of the conundrum
[21:08:29] <Ted Hardie> Paul: but I dont' think this is enough; the standard attack is an active attack, and this handles only passive attacks.
[21:08:43] <Ted Hardie> Mark: there has to be knowledge that this is trivial to overcome with active attacks.
[21:08:51] <Ted Hardie> Mark: but this is a building block
[21:09:11] <Ted Hardie> Hannes: For a long time, I've gotten the impression that it is really difficult to change HTTP
[21:09:24] <Ted Hardie> Hannes: now, for some reason, this is not a problem anymore. How did that happen?
[21:09:40] danwing leaves the room
[21:09:43] <Ted Hardie> Hannes: I don't see how that can work unless tunneled on top of TLS.
[21:10:07] <Ted Hardie> Hannes: Now folks are saying that we are not mandating TLS, but that makes it hard to see a road to deployment.
[21:10:41] <Ted Hardie> Mark: folks have made that assertion, but I think that is worth re-examining. There may be multiple ways to upgrade HTTP
[21:11:29] <Ted Hardie> Stephen: echoing a bit of PHB's comments. If people are arguing for privacy, you're undermining your own argument; it's not providing that.
[21:11:52] <Ted Hardie> Ian: Some of these arguments are following the fallacy of perfect security.
[21:12:01] <Sean Turner> +1 to raising the bar
[21:12:06] <Ted Hardie> Ian: often we are just raising the bar; the perfect can be the enemy of the good.
[21:12:26] <Ted Hardie> Ian: as to TLS, does TLS solve the upgrade problem?
[21:12:51] <Ted Hardie> Ian: in a perfect world, we could use ports, but that's not the world we live in. At the moment "virtual ports" over 443 is where we are
[21:13:04] <Ted Hardie> Ian: that could ossify too, but that's what we have now.
[21:13:16] <Ted Hardie> Hannes: even if you use existing ports, you run into trouble
[21:14:07] <hildjj> Hannes: are you planning to fold that concept into the design? how do you see the bigger picture?
[21:14:29] <hildjj> Ian: wrt origin-bound certs, etc, we don't know if it's deployable yet
[21:14:39] <hildjj> Ian: so let's not put that in the starting point.
[21:14:49] <hildjj> Ian: if it's useful and deployable, we'd bring it here.
[21:15:02] <hildjj> Mark: cut the line
[21:15:02] fielding joins the room
[21:15:16] <hildjj> Mark: we'll find a way to upgrade to 2.0
[21:16:06] <hildjj> Will/Google: clarification: one way to negotiate between client/server, "alternate-protocol" header
[21:16:41] <richard.barnes> s/header/response code/
[21:16:46] <hildjj> thx
[21:16:54] <hildjj> will: hint to move to 443 w/ SPDY + NPN
[21:17:02] <Ryan Sleevi> richard-barnes: It's a header, not a response code
[21:17:10] <richard.barnes> ah, sorry, mis-heard
[21:17:41] <hildjj> Will: if you want real security, use HTTPS
[21:17:57] <hildjj> Will: but doing http over SSL is reasonable (note: i didn't quite understand his point, obviously)
[21:18:36] <hildjj> Yutaka: we need to describe how protected/unprotected each of these mechanisms are
[21:19:20] <hildjj> Yutaka: ?
[21:19:37] <hildjj> Mark: self-signed certs would no longer set off all of the warning lights.
[21:19:58] <hildjj> Mark: that's more of a w3c issue. our job is to define a new mode of use for http
[21:20:17] <hildjj> roberto: s/optimistic/unauthenticated/
[21:20:37] <hildjj> roberto: NPN-like, not NPN, but whatever TLS wg comes up with
[21:21:10] <hildjj> Ted: charter item for explicit negotiation. if we add something else later, we can add it to the negotiation along w/ these 3
[21:21:39] <Ted Hardie> Mark: we are really talking about negotiation, not mandating a specific TLS implementation
[21:21:43] <Ted Hardie> Mark: now hum
[21:21:53] danwing joins the room
[21:21:58] <fielding> I still think humming is a waste of time
[21:22:30] <Ted Hardie> Two questions: who believes we should have language in our charter describing a negotiation mechanism (potentially encompassing choices beyond 1.1 and 2).
[21:22:37] <resnick> @roy: I'll give you my dog and pony show on when humming is good if you like. (Beer may be required.) It is often misused.
[21:22:46] <Ted Hardie> Second: who believes we should not have such language in our charter.
[21:23:15] <Ted Hardie> Larry: I'd like to have a deliverable on deployment and TLS
[21:23:17] <resnick> (the humming is often misused; not the beer)
[21:23:32] dthaler leaves the room
[21:23:35] <Ted Hardie> Mark: I'm not against that, but many decisions would need to be made first.
[21:23:46] dthaler joins the room
[21:24:20] <Ted Hardie> Elliot: I'd like a third choice "Even if the working group can agree on unauthenticated TLS, then we move forward".
[21:24:33] barryleiba leaves the room
[21:24:46] <Ted Hardie> Mark: This is basically a "should we have a discussion on this"—everything is subject to the stuff working.
[21:25:02] <Ted Hardie> Cullen: I didn't understand the humms; make them less fluffy, please?
[21:25:17] <stpeter> resnick: what *is* consensus?!? ;-)
[21:25:37] <SM> When no man or woman is left standing in the battle field
[21:25:50] <Ted Hardie> Mark shows the charter and suggests that the negotiation mechanism be discussed/addressed
[21:26:38] <resnick> @psa: I'm getting better at explaining that this week (and am actually making progress on my document). When I explain it now, people don't immediately tell me I'm full of crap and then only agree with me after 1/2 hour; now I can convince them in < 5 minutes.
[21:26:39] <Ted Hardie> The definition of unauthenticate TLS with HTTP, along with a negotiation mechanism for it for HTTP URIs.
[21:27:07] <Ted Hardie> Gabriel: I think the charter should have the negotiation mechanism, but the TLS method doesn't make sense to discuss here.
[21:27:21] <Ted Hardie> Gabriel: this allows us to make use of those options.
[21:27:52] <Ted Hardie> Mark: At the moment, there is a static binding between HTTP and HTTPS and their TLS state; we'd like to have more negotiation room.
[21:28:07] <Ted Hardie> ekr: I don't mean to sound like boundary maintenance guy, but I will
[21:28:28] <Ted Hardie> ekr: There's a number of things being discussed here: indicators to try TLS, new bindings, etc.
[21:28:56] <Ted Hardie> ekr: I'm in favor of this work, but talking about it as a charter item is confusing, because it doesn't belong here.
[21:29:12] <Ted Hardie> ekr: this should go into 2818bis. There's also impact in (inaudible)
[21:29:51] <Ted Hardie> ekr: that said, the message to TLS that you want this done is received.
[21:30:06] <Ted Hardie> Mike Belshe: are we still talking about mandatory TLS?
[21:30:35] <Ted Hardie> Mike: we'd like to see that, but from the reality perspective, it may not happen here.
[21:30:58] <Ted Hardie> Mike: but the proposal here is half-breed and it is going to have a lot of wholes.
[21:31:07] <Sean Turner> and I think ekr agreed to work on 2818bis: https://www.ietf.org/mail-archive/web/tls/current/msg08844.html
[21:31:12] richard.barnes leaves the room
[21:31:19] <hildjj> belshe: if we're not going to do mandatory tls, we don't have to talk about it
[21:31:26] <hildjj> mark: do you want this knob to tune?
[21:31:31] <Ted Hardie> Mike: it's fine.
[21:31:44] Martin Thomson joins the room
[21:32:22] <Ted Hardie> ted: I was going to rise to say "keep the negotiation mechanism", even if we don't have a current thing to negotiate to. A better thing to negotiate to may arise….
[21:32:38] <Ted Hardie> Larry: When we talk about issues, we talk about problems to be solved.
[21:33:08] <Ted Hardie> Larry: maybe we should do that, instead of talking about the proposal just given
[21:33:19] <Ted Hardie> Larry: are we starting with SPDY as deployed or as documented?
[21:33:27] tlr leaves the room
[21:33:29] <Ted Hardie> Roberto: as documented
[21:34:11] <Ted Hardie> Mark: asks question about including this language in the charter.
[21:34:16] <Ted Hardie> Hum in favor:
[21:34:23] <Ted Hardie> Hum against
[21:34:36] <Ted Hardie> Mark calls strong hum for including in the charter.
[21:34:43] <fielding> yay!
[21:34:59] <Ted Hardie> Pete: brings dog and pony show?
[21:35:40] <Ted Hardie> (Don't understand that)
[21:36:00] <Ted Hardie> Mark: header compression—there has been discussion on the list.
[21:36:23] <resnick> It was a bad hum question. The question should have been if there are any further objections about the charter item.
[21:36:24] <Ted Hardie> GZIP may not be a slam-dunk, but we can address on list; he adds a bullet for header compression as a bullet on the charter.
[21:36:36] <Ted Hardie> Upgrade handshake has already been covered.
[21:36:39] <Ted Hardie> Now, server push.
[21:37:25] <Ted Hardie> Mark: we don't seem to have consensus that it should be part of the base protocol. He proposes we continue to discuss and get further data before putting it into the charter. It may be a feature at risk.
[21:37:57] <Ted Hardie> Joe Hildebrand: as long as there is a feature negotiation, this is fine.
[21:38:23] tlr joins the room
[21:38:32] <Ted Hardie> Mark: there are ways to do this: we can take it out later, put it in later, mark it as feature at risk.
[21:39:10] <Ted Hardie> Roberto: we're not talking about a negotiation mechanism at this point, we're talking about getting data about the mechanisms that might be needed to meet that need.
[21:39:48] <Ted Hardie> Roy: header compression/re-encoding/tokenization as alternate ways of handling that should be in the charter
[21:40:29] <Ted Hardie> Gabriel: Server push could be client pull then
[21:40:32] <Ted Hardie> Mark: isn't that get?
[21:40:41] <Ted Hardie> Gabriel: but this can change?
[21:41:03] <Ted Hardie> Mark: yes, but listing the SPDY feature here means we will talk about the need that feature meets.
[21:41:33] <Ted Hardie> Mark: flow control will be discussed
[21:42:15] <Ted Hardie> Jim: part of how the internet has gotten into this terrible mess is that HTTP was of the few things allowed to get through firewalls. People behind broken things shoved it over HTTP to get it through.
[21:42:50] <Ted Hardie> Jim: it is vital, in my view, that this WG work with transport folks as much as possible
[21:43:06] <Ted Hardie> Mark: can we address that by adding transport to the Coordination list?
[21:43:08] <Ted Hardie> Jim: yes
[21:43:17] <Ted Hardie> Jim: this needs to be a data driven approach
[21:43:57] <Ted Hardie> Jim: things have to be validated in a serious way
[21:44:48] <Ted Hardie> Jim: last comment: It's been really fascinating to watch content-centric networking. There could be interesting cross-fertilization (not a charter comment, just a pointer)
[21:45:43] <sftcd> there's an ICN research group for anyone interested in that (https://www.irtf.org/icnrg)
[21:46:02] <Ted Hardie> Roberto: I talk to Matt about these issues and certain level of transport interaction will be an important part of coordination. On data-driven, it is difficult to say what the datum of interest is. There still may be interpretation.
[21:46:15] <Ted Hardie> Gabriel: +1 for coordination with transport
[21:46:41] <Ted Hardie> Gabriel: multiplexing should not be taken lightly. It should be done once, not twice.
[21:46:57] <Ted Hardie> Gabriel; e.g. websockets should be a customer of this work, not re-invent.
[21:47:18] <Ted Hardie> Gabriel: come to hybi to discuss
[21:47:39] Sean Turner leaves the room
[21:48:21] <Ted Hardie> Speaker: there is one issue nagging away at me: debuggability.
[21:48:43] <sftcd> speaker = ben niven jenkins I think
[21:48:54] <Ted Hardie> Speaker: there are nice aspects to HTTP 1.1 for debugging; losing a lot of that as we go forward. We should think of it conciously.
[21:48:58] <Ted Hardie> sftcd: thanks
[21:49:26] =JeffH leaves the room: Logged out
[21:49:33] <Ted Hardie> Ido Safruti: push certificates or dns-related data? That could be addressed
[21:49:50] <Ted Hardie> Mark: don't see a need to add that to the charter as an issue; it will get discussed
[21:50:08] <Ted Hardie> Roy: it seems odd that we don't have Head of Line blocking on there
[21:50:13] <Ted Hardie> Mark: okay, sure;
[21:50:55] <Ted Hardie> Roy: this is part of flow control
[21:51:28] <Ted Hardie> Jim: SCTP can really solve that in the long run. That maps well to transport. This is part of why talking to transport important.
[21:51:31] <Ted Hardie> Mark
[21:51:52] frodeki leaves the room
[21:51:54] <Ted Hardie> Mark: The charter will go to the list.
[21:51:54] m&m leaves the room
[21:52:12] <Ted Hardie> Larry: note that coordination items will not be in expressed in terms of changes to that document.
[21:52:30] <Ted Hardie> Mark: will massage this text, removing "all"
[21:52:57] <Ted Hardie> Now, "Security Properties" document. This must be finished before going to IETF LC on HTTPbis.
[21:53:05] <Ted Hardie> Mark: I need editors
[21:53:25] <Ted Hardie> Volunteers needed—it needs to move forward, and it is dead now.
[21:53:45] <Ted Hardie> Related efforts: protocol lab? Test suite?
[21:53:58] <Ted Hardie> Might include a content corpus
[21:54:13] <hildjj> I'd note that if HTTP over TLS is defined by the security area, perhaps they should be responsible for the security analysis also. but if it's already in the charter, it's too late, i suppose.
[21:54:30] Eliot Lear leaves the room
[21:54:30] <Ted Hardie> Will get discussed as part of the process; will not get into the charter, but happy to help with setting it up.
[21:54:36] <Ted Hardie> Mark: might end with this on github.
[21:54:40] <Ted Hardie> Finally, Looking Ahead
[21:54:52] <Ted Hardie> Review of schedule
[21:55:21] <Ted Hardie> September for first draft of HTTP 2.0, presuming charter approved.
[21:56:01] <Ted Hardie> Lucy reminds that we never did the "pick among" bit
[21:57:01] <Ted Hardie> Mark asks for objections to putting SPDY into the XXX slot on the charter?
[21:57:27] <Ted Hardie> Elliot: no objections, but concern that we remain conservative in our approach.
[21:57:36] <Ted Hardie> Elliot: want to flag that.
[21:57:53] <Ted Hardie> Elliot: need strong chair and area director control
[21:58:19] <Ted Hardie> Mark: there will be change in control.
[21:58:36] <Ted Hardie> Cullen: that wasn't the issue
[21:59:09] sftcd leaves the room
[21:59:26] Eliot Lear joins the room
[21:59:32] <Ted Hardie> Cullen: the issue is whether assuming it currently has consensus and changes need consensus or whether it is the set of words for consensus decision
[21:59:44] <Ted Hardie> Mark: Explains the way it will work
[21:59:48] <Ted Hardie> Cullen: thumbs up
[22:00:12] <Ted Hardie> No further objections
[22:00:17] danwing leaves the room
[22:00:51] <Ted Hardie> Mark: this group will remain the locus of HTTP work in the IETF, so it may take on other work if required.
[22:00:58] danwing joins the room
[22:01:21] <Ted Hardie> Mark: These may be HTTP1.1
[22:01:39] christoffer.holmstedt leaves the room
[22:01:40] <Ted Hardie> Mark: This is because some HTTP work is going on in APPSAREA WG, but the locus of expertise is here.
[22:02:17] <Ted Hardie> Barry: Assuming it makes it in the charter, if it becomes a flood, it will get pulled back out.
[22:02:41] <Ted Hardie> Ben: I'm okay with this, but it might be useful to add a sentence
[22:02:54] Ryan Sleevi leaves the room
[22:02:59] yoav.nir leaves the room
[22:03:00] <Ted Hardie> Ben: Clarifying the process
[22:03:09] Satoru Kanno leaves the room
[22:03:15] tlr leaves the room
[22:03:22] <Ted Hardie> where the first port of call will be
[22:03:50] <Ted Hardie> Barry: I don't need to put it in the charter; if it goes to APPSAREAWG, they will send it here
[22:04:05] <Ted Hardie> Mark: the schedule is aspiration, but it will go to the list.
[22:04:07] lef.jpn leaves the room
[22:04:08] Ted Hardie leaves the room
[22:04:11] resnick leaves the room
[22:04:22] SM leaves the room
[22:04:27] Justin Uberti leaves the room
[22:04:30] Martin Thomson leaves the room
[22:04:39] Yves Lafon leaves the room
[22:04:39] kazubu leaves the room
[22:04:39] mcmanus leaves the room
[22:04:39] hildjj leaves the room
[22:05:09] Atarashi Yoshifumi leaves the room
[22:05:42] danwing leaves the room
[22:05:45] Sean Turner joins the room
[22:05:59] yuioku.yj leaves the room
[22:06:47] tfossati leaves the room
[22:07:23] richard.barnes joins the room
[22:07:50] Michael Tüxen leaves the room
[22:08:08] Eliot Lear leaves the room
[22:08:35] richard.barnes leaves the room
[22:09:48] bhaw leaves the room
[22:10:10] gmandyam leaves the room
[22:11:59] Justin Uberti joins the room
[22:12:26] Satoru Kanno joins the room
[22:13:39] fielding leaves the room
[22:13:42] sftcd joins the room
[22:13:56] Satoru Kanno leaves the room
[22:14:49] sftcd leaves the room
[22:16:33] hildjj joins the room
[22:17:13] danwing joins the room
[22:18:12] Sean Turner leaves the room
[22:18:12] danwing leaves the room
[22:18:17] hildjj leaves the room
[22:18:49] danwing joins the room
[22:19:22] lef.jpn joins the room
[22:23:05] Martin Thomson joins the room
[22:27:30] Martin Thomson leaves the room
[22:35:14] danwing leaves the room
[22:48:55] danwing joins the room
[22:50:31] tlr joins the room
[22:51:03] Justin Uberti leaves the room
[22:51:16] danwing leaves the room
[22:51:20] lef.jpn leaves the room
[22:51:29] Eliot Lear joins the room
[22:51:43] Justin Uberti joins the room
[22:52:39] lef.jpn joins the room
[22:53:37] danwing joins the room
[22:55:21] tlr leaves the room
[23:04:47] Eliot Lear leaves the room
[23:24:33] sludin leaves the room
[23:27:18] Eliot Lear joins the room
[23:28:27] Eliot Lear leaves the room
[23:28:33] Eliot Lear joins the room
[23:38:17] Eliot Lear leaves the room
[23:41:02] danwing leaves the room
[23:46:19] danwing joins the room
[23:50:08] danwing leaves the room
[23:54:26] Justin Uberti leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!