ROUGH minutes for Tuesday's session are attached.
Those for Wednesday are available at:
http://www.ietf.org/jabber/logs/httpbis/2012-08-01.html
I'll clean them up and get them recorded ASAP.
Thanks,
httpbis note taking tuesday session
agenda bashing - none
httpbis -20 changes.. no comments.. ok to close tickets
http/1.1 status..
[mnot] target wglc p 1+2 by end of august
[masinter] why not now
[mnot] go read parts 1 and 2 everyone.. 4 week lc window
[lear] are you publicizing we are going to lc? (mnot w3c is aware, and this is WGlc)
p1+p2 issues
[projector offline]
link idempotent.. mark suggests unknown type.. roy says they are idempotent.. then a bunch of off mic conversation
ticket 22 - [roy] will resolve soon. [mnot] unsure if it generic or etag specific.. [rajeev becker] ws exists where etag reflects the state of the object not the state of te response [roy] etag will never reference content
ticket 364 - allow blank idempotent registry value - no discussion
[projector back]
wglc issues in p4 through p7
effectively done except for editorial review
no discussion
http 2.0 authentication EOI summary
review of 6 proposals
[mnot] not a lot of interest in any of them.. particularly with security AD and browser implementaitons.. lack of consensus. that means tieing this work to http/2 is risky. still impt to do this work. passwords cited as a specific problem. ad proposal take this set of drafts and use as input into new wg in security area perhaps for experimental rfcs. chair says the group owns http at its core and needs to stay vital, interoperational and secure and crossing the streams is a risk for core.
[jeff hodges] if we are doing http/2 what about allowing a hook for a blob to be defined later as an auth mechanism
[mnot] extensions to http/* don't need to be in the core. apps area wg?
[yoav] not sure apps wg drives browser adoption in the same way httpbis does
[mnot] not sure that if httpbis does something it means it gets implemented
[paul leach] if it is cleanly definable as an extension it should not be core.. but auth is not obviously clean. suggest this group makes sure it is possible to cleanly define extensions for authentication. p7 for http/2.0
[paul hoffman] idea of not doing these here is fine. security people aren't that interested in transport portions of http/2. p7 bis? proposals applicable to http/1 and 2
[author of one of the drafts ??? mutual auth oiwa] supports a framework in http/2 to tie authentication into protocol.. mark says semantically hard to make that http/1 compat
[wes hardaker] concerned that protocol won't support necessary mechanisms for security needs - mid stream reaut is an example
[jeff hodges] shares wes's concern
[ekr] one difficulty is that the alleged problem is unclear - shown by diversity of proposals. a number of the proposals don't meet any real needs
[roy] we tried to do this in 1994. security ad was supposed to take responsibility for that at that time. Maybe this belongs in appsarea instead of security, even if not httpbis
[roberto] world has realized that http is impt - motivations for doing this work have changed
[roy] in apps area - yes.. security maybe not
[ekr] web form is better ui.. fancy crypto does not add value.. http protocols don't elp with ui modalities
[leif jpnasson] everyone doesn't want the same thing.. webservice may want something different
[ekr] client certs keep failing to get market uptake
[oiwa] agrees there is a user interface issue.. comments or improvements on http mutual auth welcome
[lear] ui is crucial issue.. sad list has article on survey of all mechanisms in the field that is a good input
[mnot] we've discussed this a long time in the ietf and I haven't yet seen anything that convinces me we'll succeed. deserves experimental. w3c (and others) may also play a role here
Tim Bray - 451
[mnot] initally dismissive as a feel good activity using a constrained resource (status code). however, tomas roesseler mentioned a use case of web hosts making dmca takedowns could enable spidering/automatic/tracking of that kind of action
[barry hatless] what do you expect clients to do differently with 451 than 4xx?
[bray] browsers would have different default text
[stpeter] localization is hard [mnot] http has content negotiation
[hoffman] says there is a strong machine readable reason for doing this beyond end user ui
[alissa cooper] argument that ietf validates censorship isn't valid,more reflection of reality
[eric ??] how to differentiate between unavail to everyone vs unavail to _you_
[mnot] that messes with cache behavior
[???] geographic restrictions might be a use case
[lear] govts would take the view that the ietf is taking a position opposite to their own policies. also - is there a way this can be gamed?
[masinter] not fine grained enough.. probably shouldn't be done. governance can include regulatory activity.. defining when it applies is not something the IETF should be involved in
[bray] legal demand is clear
[mnot] what does 451 with same content as 200 mean?
[alyssa] legal demand is good line
[roberto peon] like the idea - concerned about secondary effects of misuse
[barry] extensible response body definition for a code so we don't need to burn a code for each use case
[wes hardaker] does this help the end user? yes! forget the misues
[ian fette] status code exhaustion not a serious problem
[mnot] 410 gone lack of adoption is concerning. link relations might be applicable.
hum - is this worth pursuing (i.e. further discussion) and should we stop (options 1 and 2) - received very similar support
--
Mark Nottingham
http://www.mnot.net/