source: wg_materials/ietf86/minutes.txt @ 2203

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

first draft of IETF86 minutes

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