Changeset 2205


Ignore:
Timestamp:
Mar 17, 2013, 11:28:03 AM (6 years ago)
Author:
mnot@…
Message:

clean up minutes

File:
1 edited

Legend:

Unmodified
Added
Removed
  • wg_materials/ietf86/minutes.txt

    r2203 r2205  
    1 Minutes for HTTPBIS
     1Minutes for HTTPbis - IETF 86 Orlando
    22
    33No bashes to agenda
     
    1010- HTTP 2.0
    1111Agreement in Tokyo to get a first implementation draft - review of those minutes.
    12 Pointer to github - Reminder that IETF rules (aka "Note Well") apply to discussion and contributions in github
     12Pointer to github - Reminder that IETF rules (aka "Note Well") apply to discussion and contributions
     13in github
    1314Expect draft to be marked "ready for implementation" in the next 4-6 weeks
    1415
    15 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.
     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.
    1619
    1720-- Martin Thomson's presentation:
     
    2124   Martin: This makes the document simpler.
    2225   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.
     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.
    2428   - Action: Martin and Hassan will come to agreement and suggest to the list
    2529
     
    4549
    4650Multiple 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.
     51   Roberto: What do you do when you have stupid servers or clients that keep sending you stuff? This
     52   will cost too much.
    4853   Mark: Can advise not to send.
    4954   Will: Also simpler to allow it.
     
    8489   Roberto: Encode either as is, or preceded with a colon.
    8590   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.
     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.
    9099   Jana: Is the dictionary entire connection or per stream?
    91100   Roberto: Entire connection. Can maintain even per host.
     
    97106   Hervé: As we're doing it, the current CRIME attack doesn't work.
    98107   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.
     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.
    100110   Roberto: You never know where in the header field sensitive info might occur, so still risk.
    101111   Hasan: A graph for all 3 algorithms with equivalent buffer sizes would be helpful.
     
    106116   Roberto: Please try making mods to code and let us know.
    107117   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.)
     118   - Action item: Please read specs; we'll discuss on list. (Reminder: We're just choosing a
     119     starting point.)
    109120
    110121- Upgrade/Negotiation
     
    117128   Roberto: Worst is it adds a RT.
    118129   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?
     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?
    120132   Mark: We'll take whatever they do into account. This is just for implementation testing.
    121133   Andrei Popov: There is an open source implementation good for testing.
     
    126138   Gabriel: Still could be in the response from server, so still a problem.
    127139   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.
     140   Hasan: The asymmetry of paths is something we've thought about before. We should make it go away.
     141   The client should be able to send a settings frame.
    129142   Mark: Not sure about doing it in TLS.
    130143   Gabriel: Probably best design in TLS.
Note: See TracChangeset for help on using the changeset viewer.