Changeset 2205 for wg_materials/ietf86

Timestamp:

17/03/13 18:28:03 (10 years ago)

Author:

mnot@…

Message:

clean up minutes

File:

• wg_materials/ietf86/minutes.txt (modified) (9 diffs)

wg_materials/ietf86/minutes.txt

@@ -1 @@
-Minutes for HTTPBIS
+Minutes for HTTPbis - IETF 86 Orlando
 
 No bashes to agenda
@@ -10 +10 @@
 - HTTP 2.0
 Agreement in Tokyo to get a first implementation draft - review of those minutes.
-Pointer to github - Reminder that IETF rules (aka "Note Well") apply to discussion and contributions in github
+Pointer to github - Reminder that IETF rules (aka "Note Well") apply to discussion and contributions
+in github
 Expect draft to be marked "ready for implementation" in the next 4-6 weeks
 
-Cyrus 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.
+Cyrus 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.
 
 -- Martin Thomson's presentation:
@@ -21 +24 @@
    Martin: This makes the document simpler.
    Roberto: We did this in SPDY4 as well.
-   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.
+   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.
    - Action: Martin and Hassan will come to agreement and suggest to the list
 
@@ -45 +49 @@
 
 Multiple RST_STREAM proposal: just send one
-   Roberto: What do you do when you have stupid servers or clients that keep sending you stuff? This will cost too much.
+   Roberto: What do you do when you have stupid servers or clients that keep sending you stuff? This
+   will cost too much.
    Mark: Can advise not to send.
    Will: Also simpler to allow it.
@@ -84 +89 @@
    Roberto: Encode either as is, or preceded with a colon.
    Adam: What was the window size for gzip in the graph? Roberto: Used max.
-   Phil Hallam-Baker: Using bearer tokens with Javascript is not a good security model. The problem is cookies, not compression.
-   Roberto: But we do have to replace this part of the protocol, and we're not chartered to address that issue.
-   Robby Simpson: Gzip (even with small window size) uses too much memory. How does memory usage compare?
-   Roberto: We're trying to be relatively space efficient, but can send back error if size is too large, though that adds a RT.
+   Phil Hallam-Baker: Using bearer tokens with Javascript is not a good security model. The problem
+   is cookies, not compression.
+   Roberto: But we do have to replace this part of the protocol, and we're not chartered to address
+   that issue.
+   Robby Simpson: Gzip (even with small window size) uses too much memory. How does memory usage
+   compare?
+   Roberto: We're trying to be relatively space efficient, but can send back error if size is too
+   large, though that adds a RT.
    Jana: Is the dictionary entire connection or per stream?
    Roberto: Entire connection. Can maintain even per host.
@@ -97 +106 @@
    Hervé: As we're doing it, the current CRIME attack doesn't work.
    Adam: Are you saying it only applies client to server? It can work in the other direction too.
-   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.
+   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.
    Roberto: You never know where in the header field sensitive info might occur, so still risk.
    Hasan: A graph for all 3 algorithms with equivalent buffer sizes would be helpful.
@@ -106 +116 @@
    Roberto: Please try making mods to code and let us know.
    Hervé: I will try to update propose to avoid CRIME attack.
-   - Action item: Please read specs; we'll discuss on list. (Reminder: We're just choosing a starting point.)
+   - Action item: Please read specs; we'll discuss on list. (Reminder: We're just choosing a
+     starting point.)
 
 - Upgrade/Negotiation
@@ -117 +128 @@
    Roberto: Worst is it adds a RT.
    PHB: This is not a penalty on every HTTP connection. I don't think this is a big overhead.
-   Gabriel Montenegro: On the TLS negotiation: I don't know if TLS will decide in the next session. Shouldn't we postpone until then?
+   Gabriel Montenegro: On the TLS negotiation: I don't know if TLS will decide in the next session.
+   Shouldn't we postpone until then?
    Mark: We'll take whatever they do into account. This is just for implementation testing.
    Andrei Popov: There is an open source implementation good for testing.
@@ -126 +138 @@
    Gabriel: Still could be in the response from server, so still a problem.
    Gabriel: (Presents proposal to set startup state in negotiation)
-   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.
+   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.
    Mark: Not sure about doing it in TLS.
    Gabriel: Probably best design in TLS.