source: wg_materials/ietf86/minutes.txt @ 2498

Last change on this file since 2498 was 2213, checked in by mnot@…, 10 years ago

update minutes
File size: 6.9 KB
Line 
1Minutes for HTTPbis - IETF 86 Orlando
2
3No bashes to agenda
4
5- HTTP 1.1
6Review of documents and tickets/changes. No responses on tickets post WGLC; to be closed.
7Action Mark: Will have a cross-document WGLC. Ending late April / early May.
8Action Mark/Philippe: Go talk to W3C re: specific items for them.
9
10- HTTP 2.0
11Agreement in Tokyo to get a first implementation draft - review of those minutes.
12Pointer to github - Reminder that IETF rules (aka "Note Well") apply to discussion and contributions
13in github
14Expect draft to be marked "ready for implementation" in the next 4-6 weeks
15
16Cyrus Daboo: Interop events upcoming?
17Mark: Yes. Should meet before Berlin (mid-June, SF Bay Area, around Velocity), in Berlin, and then
18interim right after also in Berlin. Could use some of that for test suite dev/interop.
19
20-- Martin Thomson's presentation:
21Stream identifier proposal: Make the frame header always contain a stream identifier
22   Hasan Farooq: We shouldn't add 4 bytes to every frame header.
23   Roberto Peon: Just send GOAWAY only once; otherwise neutral.
24   Martin: This makes the document simpler.
25   Roberto: We did this in SPDY4 as well.
26   Hasan: I suggest no change in the wire format, just change the doc to say frame header is smaller
27   and the ID is part of the frame header.
28   - Action: Martin and Hassan will come to agreement and suggest to the list
29
30Error code proposal: combine the two error spaces
31   Eliot Lear: This is basic IANA cleanup
32   - Agreement in the room.
33
34IANA Policies proposal
35   Agreement in room
36
37Framing layer common flags:  Define common flags for all frames
38   Will Chan: Same flag field, just reserving bits? Yes. Just convention, not formal in the registry.
39   Agreement in the room.
40
41Connection-based authentication: Propose remove the text and leave it as an open issue.
42   Agreement in the room
43
44Propose remove :version
45   Agreement in the room
46
47100-continue proposal: just send a HEADERS frame
48   Mark: I already have the action item, will start that discussion
49
50Multiple RST_STREAM proposal: just send one
51   Roberto: What do you do when you have stupid servers or clients that keep sending you stuff? This
52   will cost too much.
53   Mark: Can advise not to send.
54   Will: Also simpler to allow it.
55   Eliot: Won't you just end up sending 3, 4, 5...? Answer: Implementation choice for what to do then.
56   - Action: Martin to provide explanatory text (implementation advice)
57
58SETTINGS_CURRENT_CWND proposal: remove it
59   Roberto: Still a bit early to kill it; we haven't experimented yet
60   Mark: We have agreed to mark settings persistence "at risk". Note this too.
61   Gorry Fairhurst: We should talk to transport people.
62   Hasan: Defer discussion until we have data.
63   Jana Iyengar: This could change over time.
64   - Action: Mark this "at risk" as well.
65
66Data Compression proposal: remove the bit
67   Hasan: Removed in SPDY3.
68   Will: SPDY removed this because it didn't work.
69   Robert: This is vestigal, even in 2
70   Eliot: Partners are concerned about mandatory compression.
71   Mark: No, this is only *data* compression, not header.
72   Agreement in the room.
73
74- TLS
75   Mark: Discussing with EKR
76   Adam: Google has said that if ALPN is adopted in TLS WG then Google will deprecate NPN
77
78- Further research (Eliot)
79   Cisco is interested in funding some research in this area.
80
81Issue  discussion
82
83- Header Compression
84   Mark: In Tokyo, interest was in delta compression and headerdiff; comparing to gzip
85   Adam Langley: Was that normal gzip? Answer: Yes
86   Mark: Showed graph comparison
87   Roberto: (Describes delta2)
88   Mark: How do you map keys/values to header keys/values?
89   Roberto: Encode either as is, or preceded with a colon.
90   Adam: What was the window size for gzip in the graph? Roberto: Used max.
91   Phil Hallam-Baker: Using bearer tokens with Javascript is not a good security model. The problem
92   is cookies, not compression.
93   Roberto: But we do have to replace this part of the protocol, and we're not chartered to address
94   that issue.
95   Robby Simpson: Gzip (even with small window size) uses too much memory. How does memory usage
96   compare?
97   Roberto: We're trying to be relatively space efficient, but can send back error if size is too
98   large, though that adds a RT.
99   Jana: Is the dictionary entire connection or per stream?
100   Roberto: Entire connection. Can maintain even per host.
101   Jeff Hodges: More discussion of cookies.
102   Adam: Is it in scope to think about gzip for the content?
103
104   Hervé Ruellan: (Describes headerdiff)
105   Roberto: Prefix matching was done in delta, but not safe
106   Hervé: As we're doing it, the current CRIME attack doesn't work.
107   Adam: Are you saying it only applies client to server? It can work in the other direction too.
108   Martin: Cookies are controllable by clients in certain scenarios. Use of compression contexts for
109   same header doesn't protect you. Delta and deflate are bad for the same reasons.
110   Roberto: You never know where in the header field sensitive info might occur, so still risk.
111   Hasan: A graph for all 3 algorithms with equivalent buffer sizes would be helpful.
112   Mark: (Showing graphs)
113   Mark: How many folks have looked at these specs? (3-4 hands)
114   Mark: Because of CRIME concerns, delta is looking better in the room, but we need more discussion
115   Jana: I'd like to see numbers if we did compression per stream.
116   Roberto: Please try making mods to code and let us know.
117   Hervé: I will try to update propose to avoid CRIME attack.
118   - Action item: Please read specs; we'll discuss on list. (Reminder: We're just choosing a
119     starting point.)
120
121- Upgrade/Negotiation
122   Mark: 1. NPN / ALPN, 2. HTTP URIs, 3. DNS hints, 4. "magic"
123   Martin: (Describes what he added to draft)
124   Eliot: Added profile to DNS draft, updated examples. IAB also working on a draft.
125   Adam: 4-5% of our users can't do TXT lookups.
126   Mark: Is it safe to assume NPN & TLS? (Nodding heads yes)
127   Geoffrey Cooper: DNS puts a burden on the security proxy
128   Roberto: Worst is it adds a RT.
129   PHB: This is not a penalty on every HTTP connection. I don't think this is a big overhead.
130   Gabriel Montenegro: On the TLS negotiation: I don't know if TLS will decide in the next session.
131   Shouldn't we postpone until then?
132   Mark: We'll take whatever they do into account. This is just for implementation testing.
133   Andrei Popov: There is an open source implementation good for testing.
134
135- Startup state (Gabriel)
136   Gabriel: (Presents issues on unknown startup state)
137   Gabriel: Still could be in the response from server in the Upgrade case, so still a problem.
138   Gabriel: (Presents proposal to set startup state in negotiation)
139   Hasan: The asymmetry of paths is something we've thought about before. We should make it go away.
140   The client should be able to send a settings frame.
141   Mark: Not sure about doing it in TLS.
142   Gabriel: Probably best design in TLS.
143   Adam: This is *already* possible via opaque identifiers in NPN (and also in ALPN).
144   Mark: Let's keep this discussion going.
Note: See TracBrowser for help on using the repository browser.