source: wg_materials/ietf83/minutes.txt @ 1882

Last change on this file since 1882 was 1655, checked in by mnot@…, 11 years ago

initial go at the minutes for ietf83

File size: 11.8 KB
5__Julian on -19 revision of httpbis
7presented changes made in p1-p5, p7-auth
8mention of new status code draft, soon to be RFC
9mention of 308 code draft, soon to be RFC
11Mark observed that the problem of on-the-wire bits being turned into uris is
12  now a problem for someone else
13Larry masinter challenges the assertion that iri are working on this
14Mark/stpeter note that this is simply not a problem for _this_ working group
16Mark covers p6-caching changes
18Barry asks about changes to registry policies. If the changes are for
19  consistency, if made for that reason alone, that is insufficient
20  justification
21Mark provides some clarification - some cases have their own justification,
22  others move away from the idea that a designated expert is required (and the
23  difficulties associated with providing guidance are difficult to resolve)
24Eliot lear observes that "ietf review" is dangerous
25Mark suggests that a revisit later is probably wise, particularly since things
26  might change on the 5226 front
28__Mark on WGLC status
29Larry masinter asks about interop reports
30Stpeter notes that RFC 6410 doesn't require these now
31Sean turner points out that interop reports are as easy as you want them to be
32Barry leiba: interop reports do uncover issues
33Mark: is comfortable with the status of interop, though issues continue to be
34  found, would be happy to look at work if someone did an interop report
36On the question of the number of parts
37Carsten bormann[spelling?] advocates for one part
38speaker? advocates for part zero if the document is multiple parts
39Yngve suggests the split should be different to what currently exists, or a
40  single document
41Larry asks for hums
42Mark says hums bad for this
44__open design issues
47Andrew sullivan asks about maintenance plan for this sort of "status" field
48Mark describes a role that might be created for "curating" this sort of field
49Andrew asks for this issue to be deferred
50Eliot does like the idea
53Plan is to close this one - no objections or discussion
56Move outside and deal with it separately
59Roy fielding this is already horribly broken if it appears
60Mark suggests that the spec text is adequate
63done with 308
66already incorporated
67question from Carsten: does many include zero? answer: no
70Roy describes that some types of responses contain things other than the
71  resource, or the thing that you would get if you made a GET request to the
72  request target; things like etag apply to the "selected representation"
73Mark asks if some sort of categorization is useful for these headers
74Roy says that these headers are marked as "selected representation metadata"
75  and the changes touch p2, p3, p4
77__WGLC tickets
80Roy has added notes on how Apache implements this. order is most specific to
81  least specific
84Julian knows of some frameworks that make it difficult to do the right thing
87Julian is concerned about special cases in Cache-Control; we can't change that
90Addition to security considerations
93Barry is OK with avoiding caps, as long as the right guidance is present
95__impromptu discussion on one part vs. 8
96Murray K.: making a single, separate security considerations document could be
97  used as a referenceable spec
98Barry: the IESG would have to review everything together anyway
99Roy: people should reference the considerations that apply to them, not like
100  draft-snell-http-prefer-12, to pick on someone
101Roberto peon: not concerned about division
102Martin: http insiders aren't your audience, p0 is good for something else
103Willy: index is really important, wants security to be everywhere
105__new status
106Patrick mcmanus: have you talked to captive portal implementers?
107Mark: some people are implementing this
110__not HTTP/2.0
111Peter: describe how thursday is going to work
112Mark: explains process for process for discussion of process
117MN = Mark Nottingham (WG Chair)
118LE = Lars Eggert
119SF = Stephen Farrell
120PH = Paul Hoffman
1221. Charter Review
124MN: What is 2.0? Basically, not wire-compatible with HTTP/1.x. But not
125    "everything you might have ever wanted to do with HTTP.
126MN: In addition to 2.0 proposals, we want to solicit proposals for new
127    authentication schemes.
128LE: There is the possibility of doing work at the IRTF, if appropriate.
129SF: If we do things in the Security Area, more likely to be Experimental RFCs
130PH: Clarifying question: do you want ones that work in the current framework,
131    or you open to ones which would change the framework.
132Chair: There are a couple of questions to unpack there. My intuition is that
133    if it does not work in 1.1, it is probably a show stopper. Existing
134    practice is some of the reason we have problems, though, so it might
135    happen.
136MN: We're chartered to develop output, not rubber stamp any input.
137MN: (1) Define a new serialization of HTTP on the wire
138MN: Make sure it could replace HTTP 1.1
139MN: Define one or more new authentication schemes, or explain why not
140MN: Success Criteria...
141MN: Implementers have reasons to switch.
143Ways we can FAIL
144JH: Would you like a bigger list of risks? One thing to avoid is
145    internationalization issues in URIs.
146MN: I'd like to not try to do too much.
148Step 1.  Call for Proposals
149Asking for new serializations of HTTP semantcs & new authentication schemes.,
150 taking into account our charter reqs++
152PH: I've heard "if WG chooses one proposal, I'll implement it, if more then
153    one then not". Not sure that fits into this structure.
154MN: I think that applies to auth but not 2.0, different situation.
155Eliot Lear (EL): How does deployment fit in?
156Larry Masinter (LM): Perhaps might make sense to give deployment even higher
157    priority over implementation.
158Salvatore Loreto (SL): Please also consider deployment in wireless
159    environments.
160Tony Hansen (TH): I think implementation is a good way of vetting what's
161    workable. Another good criteria is what is deploy*able*.
162Harald Alvestrand (HA): Also: "I have deployed it (and nothing bad happened)",
163    and "I would not deploy it because X".
164Eric Rescorla (ekr): There is some possibility that stuff HTTPBIS wants to do
165    will have ripple effects throughout the IETF. This might be the right
166    place to gauge that.
167MN: Fair enough.  This is when we would do liaison-type activity.
168MN: Exit criteria is one of the elements of re-chartering.]
169MN: This aggressive, but we don't want to spend our time spinning our wheels
170    on this.
171MN: Would like to be able to talk about this around IETF 84 in Vancouver.
172Gabriel Montenegro (GM): Does the current charter talk about this timeframe?
173Peter St. Andre (PSA): The understanding between the IESG and the chair at
174    this point was that we would not start with one of the proposals right
175    now, but first establish the scope and requirements. Then re-charter to do
176    the work.
177SL: Just to clarify, the consensus about the proposals will happen on the
178    mailing list.
179MN: Yes, this will all be done on the mailing list.
180MN: Does this make sense?
181EKR: You had a timeline: the upcoming charter will not say "we will work on
182    this protocol"?
183MN:  It will establish a starting point, and the set of requirements.
184Roy Fielding (RF): Not a real believer in committee based protocol design; I
185    would prefer a bake-off, rather than a committee based design.
186MN: We can have some elements of that.
187MN: This is not the bakeoff engineering task force.
188RF: I think we don't need to agree on one before rechartering. We could have
189    multiple documents and then remove them one by one.
190MN: HUM: Instead of one starting point, multiple starting points?
191HUM: Some support.
192MN: HUM: And one starting point before rechartering?
193HUM: More support.
194Ted Hardie (TH): Might be good to publish some of the non-starting points as
195    experimental specs.
196EL: (1) Might we have more than one endpoint? For example, purpose-built
197    protocols for particular use cases? (2) Is it possible that one outcome
198    could be zero proposals?
199MN: That is true, but I tend to think that other outputs would be done
200    elsewhere. Concerned about working on multiple approaches, from a
201    management perspective.
202Yoav Nir (YN): I think it would be much better if we had just one proposal to
203    go with the next charter. If we have multiple at the time we go to
204    recharter, we may have to decide to either delay or decide to start with
205    multiples.
206LM: I can't imagine a less than 10 year period for 1.1 to go away. So software
207    will gateway 1.1. Thus we're talking about an addition to 1.1, not a
208    replacement. Thus there might be different profiles / protocols for
209    different use cases.
210MN:  We should steal some language from the security ADs.
211MN: It is a goal to start from a single one, but if we end up with multiple,
212    we can work that out at the time.
213Ian Fette (IF): As the editor of web sockets, I certainly understand the
214    problems with design by committee. But I think it may be a moot point. At
215    some point we have to get to a point where there is a single document.
216IF: We already have four starting points (four documents). At some point we
217    need to get to one document. I think it is fine to have a goal to get to
218    that one document; if we can't, we can't, but it is a good goal.
219PSA:  It will focus the mind.
220SL: My preference is a single starting point. It will be a mess otherwise,
221    especially for people working on intermediaries and middleboxes.
222EKR: I am not sure why we are acting like this is something we have never done
223    before; this is what we do all the time. Sometimes we put an artificial
224    deadline, sometimes we do not. Of course, this is what we are going to do.
225    This charter time is just accounting, and I don't care about that at all.
226    We won't know until we see all the proposals.
227HA: Might want to let proposals go forward cleanly, not do lots of grafting
228    and crafting. But this did not work too well with IPv6 and IKEv2. Better
229    to kill off the candidates earlier rather than later.
230MN:  This is the plan going forward, I think.
233[see slides for most of the content]
235P1. SPDY (Mike Belshe)
236MB points out that Google, firefox/mozilla, other spdy contributors are
237   committed to doing what's necessary to making the protocol meet needs of
238   "broader community"
239EKR:  How does this compare to TLS compression?
240MB: Does not compress the bodies. Only the headers, and it tries to avoid
241    double compression of things like JPEG.
242EL: What does "domain" mean here?
243MB: It's a complicated answer. Basically what I meant by it, is where you
244    would have had a connection pool. There is an exception to this, where
245    people are doing domain sharding--splitting resources across multiple
246    hostnames, in order to open up a bunch of connections, which is really one
247    host. We've also added IP connection pooling, which allows us to bundle
248    those under one connection.
249Roberto Peon (RP): Having one connection for mobile keeps the connection open
250    longer for productive work.
251Richard Barnes: Also a problem with secure protocols that have broken
252    authentication etc. Disambiguate types of security.
254P2. Speed + Mobility (Gabriel Montenegro)
256[No questions.]
258P3. Intermediary Requirements (Willy Tarreau)
260[No questions, time running short.]
262P4. Waka (Roy Fielding)
264Hannes Tschofenig: Even if we optimize the headers, that doesn't do anything
265    for the payloads.Are you going to cover that?
266RF: Not in the next five minutes. :)
270MN: We have a lot to do in a reasonable amount of time. Focused, structured
271    discussion on the list. Be constructive. Need people to work on proposals
272    and metrics. I'm expecting TLS everywhere, interception proxies, header
273    compression, how we upgrade from 1.x and roundtripping. New folks, please
274    look at the Tao of the IETF list. We don't do voting. See the WG page on
275 The editors are focused on 1.1, that is our top priority. Please
276    prefix your subject lines to the list. I'm sure we'll meet in Vancouver.
277TH: Any chance for an interim meeting?
278MN: Yes.
Note: See TracBrowser for help on using the repository browser.