source: wg_materials/ietf84/minutes.txt

Last change on this file was 1824, checked in by mnot@…, 8 years ago

add minutes from ietf84

File size: 30.2 KB
Line 
1httpbis minutes - ietf84
2========================
3
4Session One - Tuesday
5---------------------
6
7### agenda bashing
8
9None
10
11### httpbis -20  changes
12
13no comments.. ok to close tickets
14
15### http/1.1 status
16
17mnot: target wglc p 1+2 by end of august
18masinter: why not now
19mnot: go read parts 1 and 2 everyone.. 4 week lc window
20lear: are you publicizing we are going to lc? (mnot w3c is aware, and this is WGlc)
21
22### p1+p2 issues
23
24link idempotent - mark suggests unknown type.. roy says they are idempotent.. then a bunch of off mic conversation
25
26ticket 22 -
27roy: will resolve soon.
28mnot: unsure if it generic or etag specific..
29rajeev becker: ws exists where etag reflects the state of the object not the state of the response
30roy: etag will never reference content
31
32ticket 364 - allow blank idempotent registry value - no discussion
33
34#### wglc issues in p4 through p7
35
36effectively done except for editorial review
37no discussion
38
39#### http 2.0 authentication EOI summary
40
41review of 6 proposals
42mnot: not a lot of interest in any of them.. particularly with security AD and browser implementaitons.. lack of consensus. that means tieing this work to http/2 is risky. still impt to do this work. passwords cited as a specific problem. ad proposal take this set of drafts and use as input into new wg in security area perhaps for experimental rfcs. chair says the group owns http at its core and needs to stay vital, interoperational and secure and crossing the streams is a risk for core.
43jeff hodges: if we are doing http/2 what about allowing a hook for a blob to be defined later as an auth mechanism
44mnot: extensions to http/* don't need to be in the core. apps area wg?
45yoav: not sure apps wg drives browser adoption in the same way httpbis does
46mnot: not sure that if httpbis does something it means it gets implemented
47paul leach: if it is cleanly definable as an extension it should not be core.. but auth is not obviously clean. suggest this group makes sure it is possible to cleanly define extensions for authentication. p7 for http/2.0
48paul hoffman: idea of not doing these here is fine. security people aren't that interested in transport portions of http/2. p7 bis? proposals applicable to http/1 and 2
49oiwa: supports a framework in http/2 to tie authentication into protocol.. mark says semantically hard to make that http/1 compat
50wes hardaker: concerned that protocol won't support necessary mechanisms for security needs - mid stream reaut is an example
51jeff hodges: shares wes's concern
52ekr: one difficulty is that the alleged problem is unclear - shown by diversity of proposals. a number of the proposals don't meet any real needs
53roy: we tried to do this in 1994. security ad was supposed to take responsibility for that at that time. Maybe this belongs in appsarea instead of security, even if not httpbis
54roberto: world has realized that http is impt - motivations for doing this work have changed
55roy: in apps area - yes.. security maybe not
56ekr: web form is better ui.. fancy crypto does not add value.. http protocols don't elp with ui modalities
57leif jpnasson: everyone doesn't want the same thing.. webservice may want something different
58ekr: client certs keep failing to get market uptake
59oiwa: agrees there is a user interface issue.. comments or improvements on http auth extension draft (which trying to solve this) welcome
60lear: ui is crucial issue.. sad list has article on survey of all mechanisms in the field that is a good input
61mnot: we've discussed this a long time in the ietf and I haven't yet seen anything that convinces me we'll succeed. deserves experimental. w3c (and others) may also play a role here
62
63### Tim Bray - 451
64
65mnot: initally dismissive as a feel good activity using a constrained resource (status code). however, tomas roesseler mentioned a use case of web hosts making dmca takedowns could enable spidering/automatic/tracking of that kind of action
66barry hatless: what do you expect clients to do differently with 451 than 4xx?
67bray: browsers would have different default text
68stpeter] localization is hard [mnot: http has content negotiation
69hoffman: says there is a strong machine readable reason for doing this beyond end user ui
70alissa cooper: argument that ietf validates censorship isn't valid,more reflection of reality
71eric ??: how to differentiate between unavail to everyone vs unavail to _you_
72mnot: that messes with cache behavior
73???: geographic restrictions might be a use case
74lear: govts would take the view that the ietf is taking a position opposite to their own policies. also - is there a way this can be gamed?
75masinter: not fine grained enough.. probably shouldn't be done. governance can include regulatory activity.. defining when it applies is not something the IETF should be involved in
76bray: legal demand is clear
77mnot: what does 451 with same content as 200 mean?
78alyssa: legal demand is good line
79roberto peon: like the idea - concerned about secondary effects of misuse
80barry: extensible response body definition for a code so we don't need to burn a code for each use case
81wes hardaker: does this help the end user? yes! forget the misues
82ian fette: status code exhaustion not a serious problem
83
84mnot: 410 gone lack of adoption is concerning. link relations might be applicable.
85
86hum - is this worth pursuing (i.e. further discussion) and should we stop (options 1 and 2) - received very similar support
87
88
89Session Two - Wednesday
90-----------------------
91
92Where we are: last time we agreed to solicit for proposals, SPDY, S+M, Network-Friendly Upgrade came in.
93
94Today, we are here to discuss and work out how to move forward.
95But before that, a sanity check: ws-* seemed like a good idea at the time; pipelining is getting deployment
96We have a huge investment in things as they are; there are also opportunity costs.
97Mark is comfortable now, though he has gone back and forth on this.
98He believes that with these ideas and the current state, he is comfortable with the 2.0 work going forward now.
99
100Larry 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)
101
102Discussion 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.
103Mark believes that there is clear consensus that the basis of our approach should substantially be draft-mbelshe-httpbis-spdy
104Question to be how to structure it as the basis.
105just SPDY; pick-and-choose, start with HTTPbis p1; SPDY with instructions/caveats/inputs
106
107From 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
108His favorite: SPDY with instructions/caveats/inputs
109Any other thoughts?
110(Larry's opinion is solicited by the chair)
111Larry: starting with a starting point without knowing what you are optimizing and for whom is procedurally a mistake.
112Larry: 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.
113Mark: if we had more data, would we make a different choice?
114Larry: possibly, but not clear that the guidelines are well formed.
115Larry: example: sniffing; can we turn it off for 2.0
116Sean Turner: Maybe on of the things we can do is publish SPDY as an Informational, to get it out as a stable spec.
117Mark: I think SPDY is still evolving.
118Ian: 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.
119Pete Resnick, covering his dot: Agrees with Ian; publishing as informational is just delaying.
120Pete: Chair has two options: start with a new doc and take suggestion; start with a doc and take objections/diffs.
121Pete: Not seeing why the second is a concern.
122Pete: don't see why we shouldn't start with a base spec.
123Mark: 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.
124Eliot Lear: he has a mixed opinion.
125Eliot: He would like to start with a description of the problems/goals.
126Eliot: aim spdy at those goals.
127(discussion of encryption deferred)
128Next phase of this is the charter, concerns may be addressed there.
129Roy 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.
130Roy: 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.
131Roy: 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.
132Roberto: The idea behind what SPDY was: changes wire representation, but leaves everything else as it was for HTTP. That has had some benefit.
133Roberto: I believe what we are doing here is HTTP 2.0—same semantics
134Patrick 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.
135Mark: I think we should focus on what is p1, not revising in p2 or p3
136(is in p1).
137Mark: Roy reminded me of a discussion with Barry the other day in which it is good to have clarity on what the expectation.
138Mark: 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?
139Mark: there may be many things that we do not cover (interception proxies, backend systems).
140Mark: major orphaned use cases should be avoided. We should eventually (20 years) cover them all.
141Larry: I don't love interception proxies; people buy them and use them
142Mark: we will have a 5m conversation about interception proxies
143Ted: interception proxies are used because we don't offer an explicit way of solving the use case
144Larry: it should be a part of the charter then
145Ted: SPDY is nice as a starting point; it's nice to have that to frame the discussion.
146Ted: Not starting from a clean slate is important
147Ted: we'll make faster progress if we don't clean slate
148Mark: Ted reminded that we may need to take up other elements, like proxy.pac to get some elements of the work done.
149Salvatore: interception proxies are used in telephone networks a lot.
150Salvatore: having said that, we see some benefit from SPDY
151Sean Turner: starting at a blank slate will add a year to the process
152Salvatore: I sent out an expression of interest; he suggests pick and choose—picking mostly from SPDY
153Salvatore: even better, take the SPDY proposal and remove the controversial parts
154Mark: 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.
155Larry: I'd rather start with the caveats and instructions than the starting point
156Mark: we agreed in Paris to start with a starting parting.
157Larry: okay
158Eliot: The encryption issue is an elephant in the room; this starting point may have an impact on this
159Sean Turner: okay so I'm convinced don't both publishing spdy on inf
160Mike Belshe: proxies don't have a strong issue with SPDY, they have one with TLS, but SPDY doesn't mandate TLS
161Mark: Agreed, the document does not mandate SPDY
162Rob Trace: encryption issue is a distraction; focus on multiplexing and let's get going
163Rajeev Bector: can we talk about the goal
164Mark: get consensus
165Mark: maintain deployability
166mark: modernized security, ensure it's no more difficult to deploy
167Mark: improve security
168Mark: maintain all of the existing actors
169Mike Belshe: we have the same question: does this replace all of HTTP 1.1?
170Mike Belshe: everything that runs over 1.1 should be able to run 2.0. But that doesn't mean everyone will change.
171Mike Belshe: There may be cases where you can't make improvement for every uses.
172Mark: yes, but I don't want to drop use cases because "they can use 1.1"
173Mike Belshe: there are cases that are hard (youtube) where it may not fit the use case.
174Ted Hardie> Mark: remind folks of your affiliation
175Mike: I have not worked at Google for a year.
176Gabriel 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.
177Ian 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.
178Ian 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.
179Rajeev: 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.
180Sean Turner: it's in a WG draft by definition we don't have consensus on it
181Joe: 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.
182Joe: then, I am fine.
183Mark; that should be a given
184Joe: actually not; can be chartered other way
185Patrick: we will be actively pushing old versions of SPDY off the web; that's been clear during this phase.
186Mark: Just to clarify, backwards compatibility is a non-goal; will clarify in the charter.
187Leif: do we want to call consensus on that last point?
188Mark: will do so as part of charter discussion.
189Mark: now reviewing charter sent to the mailing list
190
191Adds a new work item for http 2.0,
192The Working Group's specification deliverables are:
193* A document (or set of documents) that is suitable to supersede RFC 2616 as
194  the definition of HTTP/1.1 and move RFC 2817 to Historic status
195* A document cataloguing the security properties of HTTP/1.1
196* A document (or set of documents) that specifies HTTP/2.0, an improved
197  binding of HTTP's semantics to an underlying transport.
198It is expected that HTTP/2.0 will:
199* Substantially and measurably improve end-user perceived latency in most
200  cases, over HTTP/1.1 using TCP.
201* Not require multiple connections to a server to enable parallelism.
202* Require no more configuration or tuning than current HTTP deployments;
203   preferably, less.
204* Retain the semantics of HTTP/1.1, leveraging existing documentation (see
205  above), including (but not limited to) HTTP methods, status codes, URIs, and
206  where appropriate, header fields.
207* Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in
208  intermediaries (both 2->1 and 1->2).
209* Clearly identify any new extensibility points and policy for their
210  appropriate use.
211
212Joe Hildebrand: Do we want to add something about congestion control, as a motivator?
213Mark: sure.
214
215Mark: "improving the use of TCP, especially regarding congestion control" to be wordsmithed
216The resulting specification(s) are expected to be meet these goals for common
217existing deployments of HTTP; in particular, Web browsing (desktop and
218mobile), Web serving (at a variety of scales), and intermediation (by proxies,
219corporate firewalls, "reverse" proxies and Content Delivery Networks).
220Note that this does not include uses of HTTP where non-specified behaviours
221are relied upon (e.g., connection state such as timeouts or client affinity,
222and "interception" proxies); these uses may or may not be enabled by the final
223product.
224
225Explicitly out-of-scope items include:
226* Specifying the use of alternate transport protocols. Note that it
227  is expected that the Working Group will define how the protocol is used
228  with the TLS protocol.
229* Specifying new semantics for HTTP (whether specific to HTTP/2 or not).
230  However, the Working Group may request a re-charter to start work on such
231  items (during or after work on HTTP/2.0), provided there is consensus to
232  do so, and it does not interfere with work on the "core" (both HTTP/1.x and
233  HTTP/2.0).
234
235Mark: Possibly adding a specific "out of scope" for p2-p7
236
237List of specific issues:
238Mandatory TLS
239Header Compression
240Upgrade/Handshake
241Server "push"
242Flow control
243Security properties
244
245Let's get out of the way the mandatory TLS issue
246Mark: we don't have consensus on this
247Mark: the current uses of spdy require the use of TLS
248Mark: discussing this with the authors and implementors, I think we may have a way around this
249Mark: if we take the approach that HTTPS URLs should work the same in the two versions, we're actually pretty close (modulo NPN)
250The issue is "http" not "https" URLs.
251Mark: a real negotiation may be needed, with "optimistic TLS" as a possibility
252This would block passive eavesdropping , but does not provide certificate-checking
253Mark: charter impact is to include negotiation mechanism, potential coordination with others, All* other discussion of topic out of scope
254Mark: how many people have read the "tussle" paper?
255Mark: it's a good explication of how these issues arise and might be resolved
256Larry: it was my impression was that the primary issue was a deployment issue
257Mark: some people have put that forth.
258Larry: I have heard it as significant issue. As stated, this would make deployment considerations out of scope. That's what this says to me.
259Mark: that's not the intent
260Larry: nowhere in the charter is there a mandate to document deployment considerations
261Mark: do you want to hear from Mike?
262Mike: of course deployment considerations are important. Even subtle things can be issues, so we understand this. Going over TLS is a deployment factor.
263Mike: there haven't be any ways to put new protocols over port 80. Even changes over TLS are hard.
264Mike: But it kind of doesn't matter from the protocol specification
265Jim Gettys: I think the primary motivation is fine.
266Jim: in some parts of the world, caching is a necessary thing; to the extent this hurts caching, this is an issue.
267Mark: 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.
268Yoav: NPN was not accepted by TLS
269Mark: don't want to discuss the politics of other groups.
270Yoav: don't see how that will work over port 80
271Mark: doesn't say port 80 there.
272Rajeeve: The site owner can't control when clients negotiation.
273Mark: This gives both sides power
274Rajeev: there are three parties here: clients, servers, content owner
275Rajeev: this will be an impediment to deployment
276Mark: impediment to "optimistic" TLS
277Rajeev: yes
278Mark: optimistic TLS will not show as secure in browser chrome etc.
279ekr: as chair, note TLS still has not accepted this work, so building on it a bit worrying
280ekr: 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.
281PHB: I don't like it when application layer protocols do a half-assed job of security.
282PHB: Why pick only one attack (passive attacker) and address only that?
283PHB: There is no web browser I'm aware of that doesn't have TLS today.
284PHB: those that don't have it have a different security model
285Mark: there is not a mandate here.
286PHB: if it is not mandatory, why is it called that?
287Mark: just slide title, that'a red herring
288PHB: Mandatory to implement?
289Mark: no
290PHB: head explodes
291Roberto: if we put a question mark in the title of the slide, it becomes accurate
292roberto: 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.
293Patrick: I want to re-iterate that making explicit proxies a bigger part of this; there are value-added services possible there.
294Patrick: that's both for wpad and pac; we need to serve better, we're not trying to eliminate them
295Patrick: it would be my preference for TLS everyhwere; if there is an actual person there, there needs are paramount
296Patrick: but this is a workable way to move forward.
297Tim: more or less plus 1; this is a reasonable compromise
298Elliot Lear: let's be clear on what we're getting: only sniffing problem
299Elliot: 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
300Paul Leech: I applaud the attempt to get out of the conundrum
301Paul: but I dont' think this is enough; the standard attack is an active attack, and this handles only passive attacks.
302Mark: there has to be knowledge that this is trivial to overcome with active attacks.
303Mark: but this is a building block
304Hannes: For a long time, I've gotten the impression that it is really difficult to change HTTP
305Hannes: now, for some reason, this is not a problem anymore. How did that happen?
306Hannes: I don't see how that can work unless tunneled on top of TLS.
307Hannes: Now folks are saying that we are not mandating TLS, but that makes it hard to see a road to deployment.
308Mark: folks have made that assertion, but I think that is worth re-examining. There may be multiple ways to upgrade HTTP
309Stephen: echoing a bit of PHB's comments. If people are arguing for privacy, you're undermining your own argument; it's not providing that.
310Ian: Some of these arguments are following the fallacy of perfect security.
311Sean Turner: +1 to raising the bar
312Ian: often we are just raising the bar; the perfect can be the enemy of the good.
313Ian: as to TLS, does TLS solve the upgrade problem?
314Ian: 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
315Ian: that could ossify too, but that's what we have now.
316Hannes: even if you use existing ports, you run into trouble
317Hannes: are you planning to fold that concept into the design? how do you see the bigger picture?
318Ian: wrt origin-bound certs, etc, we don't know if it's deployable yet
319Ian: so let's not put that in the starting point.
320Ian: if it's useful and deployable, we'd bring it here.
321Mark: cut the line
322Mark: we'll find a way to upgrade to 2.0
323Will/Google: clarification: one way to negotiate between client/server, "alternate-protocol" header
324will: hint to move to 443 w/ SPDY + NPN
325Will: if you want real security, use HTTPS
326Will: but doing http over SSL is reasonable (note: i didn't quite understand his point, obviously)
327Yutaka: we need to describe how protected/unprotected each of these mechanisms are
328Yutaka: ?
329Mark: self-signed certs would no longer set off all of the warning lights.
330Mark: that's more of a w3c issue. our job is to define a new mode of use for http
331roberto: s/optimistic/unauthenticated/
332roberto: NPN-like, not NPN, but whatever TLS wg comes up with
333Ted: charter item for explicit negotiation. if we add something else later, we can add it to the negotiation along w/ these 3
334Mark: we are really talking about negotiation, not mandating a specific TLS implementation
335Mark: now hum
336Two questions: who believes we should have language in our charter describing a negotiation mechanism (potentially encompassing choices beyond 1.1 and 2).
337Second: who believes we should not have such language in our charter.
338Larry: I'd like to have a deliverable on deployment and TLS
339Mark: I'm not against that, but many decisions would need to be made first.
340Elliot: I'd like a third choice "Even if the working group can agree on unauthenticated TLS, then we move forward".
341Mark: This is basically a "should we have a discussion on this"—everything is subject to the stuff working.
342Cullen: I didn't understand the humms; make them less fluffy, please?
343Mark shows the charter and suggests that the negotiation mechanism be discussed/addressed
344The definition of unauthenticate TLS with HTTP, along with a negotiation mechanism for it for HTTP URIs.
345Gabriel: I think the charter should have the negotiation mechanism, but the TLS method doesn't make sense to discuss here.
346Gabriel: this allows us to make use of those options.
347Mark: At the moment, there is a static binding between HTTP and HTTPS and their TLS state; we'd like to have more negotiation room.
348ekr: I don't mean to sound like boundary maintenance guy, but I will
349ekr: There's a number of things being discussed here: indicators to try TLS, new bindings, etc.
350ekr: I'm in favor of this work, but talking about it as a charter item is confusing, because it doesn't belong here.
351ekr: this should go into 2818bis. There's also impact in (inaudible)
352ekr: that said, the message to TLS that you want this done is received.
353Mike Belshe: are we still talking about mandatory TLS?
354Mike: we'd like to see that, but from the reality perspective, it may not happen here.
355Mike: but the proposal here is half-breed and it is going to have a lot of wholes.
356Sean Turner: and I think ekr agreed to work on 2818bis: https://www.ietf.org/mail-archive/web/tls/current/msg08844.html
357belshe: if we're not going to do mandatory tls, we don't have to talk about it
358mark: do you want this knob to tune?
359Mike: it's fine.
360ted: 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….
361Larry: When we talk about issues, we talk about problems to be solved.
362Larry: maybe we should do that, instead of talking about the proposal just given
363Larry: are we starting with SPDY as deployed or as documented?
364Roberto: as documented
365Mark: asks question about including this language in the charter.
366Hum in favor
367Hum against
368Mark calls strong hum for including in the charter.
369Mark: header compression—there has been discussion on the list.
370GZIP 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.
371Upgrade handshake has already been covered.
372Now, server push.
373Mark: 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.
374Joe Hildebrand: as long as there is a feature negotiation, this is fine.
375Mark: there are ways to do this: we can take it out later, put it in later, mark it as feature at risk.
376Roberto: 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.
377Roy: header compression/re-encoding/tokenization as alternate ways of handling that should be in the charter
378Gabriel: Server push could be client pull then
379Mark: isn't that get?
380Gabriel: but this can change?
381Mark: yes, but listing the SPDY feature here means we will talk about the need that feature meets.
382Mark: flow control will be discussed
383Jim: 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.
384Jim: it is vital, in my view, that this WG work with transport folks as much as possible
385Mark: can we address that by adding transport to the Coordination list?
386Jim: yes
387Jim: this needs to be a data driven approach
388Jim: things have to be validated in a serious way
389Jim: 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)
390Roberto: 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.
391Gabriel: +1 for coordination with transport
392Gabriel: multiplexing should not be taken lightly. It should be done once, not twice.
393Gabriel; e.g. websockets should be a customer of this work, not re-invent.
394Gabriel: come to hybi to discuss
395Ben: there is one issue nagging away at me: debuggability.
396Ben: 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.
397Ido Safruti: push certificates or dns-related data? That could be addressed
398Mark: don't see a need to add that to the charter as an issue; it will get discussed
399Roy: it seems odd that we don't have Head of Line blocking on there
400Mark: okay, sure;
401Roy: this is part of flow control
402Jim: SCTP can really solve that in the long run. That maps well to transport. This is part of why talking to transport important.
403Mark: The charter will go to the list.
404Larry: note that coordination items will not be in expressed in terms of changes to that document.
405Mark: will massage this text, removing "all"
406
407Now, "Security Properties" document. This must be finished before going to IETF LC on HTTPbis.
408Mark: I need editors
409Volunteers needed—it needs to move forward, and it is dead now.
410
411Related efforts: protocol lab? Test suite?
412Might include a content corpus
413I'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.
414Will get discussed as part of the process; will not get into the charter, but happy to help with setting it up.
415Mark: might end with this on github.
416
417Finally, Looking Ahead
418Review of schedule
419September for first draft of HTTP 2.0, presuming charter approved.
420Lucy reminds that we never did the "pick among" bit
421Mark asks for objections to putting SPDY into the XXX slot on the charter?
422Elliot: no objections, but concern that we remain conservative in our approach.
423Elliot: want to flag that.
424Elliot: need strong chair and area director control
425Mark: there will be change in control.
426Cullen: that wasn't the issue
427Cullen: the issue is whether assuming it currently has consensus and changes need consensus or whether it is the set of words for consensus decision
428Mark: Explains the way it will work
429Cullen: thumbs up
430No further objections
431
432Mark: this group will remain the locus of HTTP work in the IETF, so it may take on other work if required.
433Mark: These may be HTTP1.1
434Mark: This is because some HTTP work is going on in APPSAREA WG, but the locus of expertise is here.
435Barry: Assuming it makes it in the charter, if it becomes a flood, it will get pulled back out.
436Ben: I'm okay with this, but it might be useful to add a sentence
437Ben: Clarifying the process
438where the first port of call will be
439Barry: I don't need to put it in the charter; if it goes to APPSAREAWG, they will send it here
440Mark: the schedule is aspiration, but it will go to the list.
Note: See TracBrowser for help on using the repository browser.