[00:01:02] --- jack.bates has joined
[01:13:15] --- jack.bates has left
[13:48:19] --- julian.reschke has joined
[14:55:52] --- LOGGING STARTED
[15:22:27] --- julian.reschke has joined
[15:22:27] --- julian.reschke has left: Lost connection
[15:28:53] --- julian.reschke has joined
[16:11:09] --- julian.reschke has left
[17:31:15] --- frank has joined
[17:31:25] --- frank has left
[17:31:43] --- frank has joined
[17:31:50] --- julian.reschke has joined
[18:10:41] --- mnot has joined
[18:26:38] --- cyrus_daboo has joined
[18:26:59] --- tlyu@jis.mit.edu has joined
[18:28:01] <julian.reschke> - agenda bashing
[18:28:22] <julian.reschke> - issues list
[18:28:23] --- cnewman@jabber.org has joined
[18:28:26] --- ekr has joined
[18:28:33] <julian.reschke> - security properties document
[18:29:38] <julian.reschke> Alexey Melnikov: "Security properties of HTTP and its associated mechanisms"
[18:30:12] <julian.reschke> AM: overview of what's there
[18:30:57] <julian.reschke> AM: existing mechanisms from RFC 2617 - Basic, Digest
[18:31:20] <julian.reschke> AM: Negotiate (RFC 455)9
[18:31:44] <julian.reschke> AM: others being proposed: NTLM, SRP, Mutua, etc
[18:32:09] --- stpeter has joined
[18:32:14] <julian.reschke> AM: second group based on Cookies
[18:32:27] <julian.reschke> AM: RFC2109, RFC2965, Netscape spec
[18:32:29] --- Lisa has joined
[18:32:47] <julian.reschke> AM: + HTML forms
[18:33:11] <julian.reschke> Paul Hoffmann: Cookies not an auth mechanism per se
[18:34:29] <julian.reschke> Discussion about Cookies are in scope for this WG
[18:34:51] --- Jabber-Wile has joined
[18:35:33] <julian.reschke> AM: Cookies not part of the partitioned spec, not in the charter
[18:36:31] <julian.reschke> Jeff Hodges: Cookies are just state maintenance
[18:37:04] <julian.reschke> MNot reminds us about the charter
[18:37:40] <julian.reschke> Robert Sayre: Digest includes state management as well, let's not split hairs
[18:37:41] --- bernard.desruisseaux has joined
[18:37:47] <julian.reschke> AM: third group: TLS
[18:38:31] <julian.reschke> AM: not interested in web services security mechanisms
[18:38:40] --- justin.erenkrantz@joost.com has joined
[18:38:49] <julian.reschke> AM: Connection integrity & confidentiality
[18:39:05] <julian.reschke> AM: Digest...
[18:39:36] <julian.reschke> AM: ...TLS (various mechanisms RFC2818, RFC2817, CONNECT method)
[18:39:46] <julian.reschke> AM: Q: include connect into RFC2616bis?
[18:40:18] <julian.reschke> Lisa Dusseault: thinks it's required
[18:40:44] <julian.reschke> AM: proposes to include the definition by copy, not reference
[18:40:55] <julian.reschke> AM: next steps:
[18:40:59] <julian.reschke> AM: find editors
[18:41:06] <julian.reschke> AM: use draft-sayre as base
[18:41:21] <julian.reschke> AM: other questions
[18:41:34] --- =JeffH has joined
[18:41:37] <julian.reschke> AM: not chartered for new mechanisms
[18:42:04] --- YvesLafon has joined
[18:42:11] <julian.reschke> AM: move the frameworks parts of RFC2617 into RFC2616bis?
[18:43:14] <julian.reschke> AM: fix I18N in Basic? fix multi-roundtrip auth? specify a set of reqs for new auth methods?
[18:44:08] <julian.reschke> Yngwe Petterson: Opera supports message integrity checks in Digest, but not really supported by servers
[18:44:20] <julian.reschke> AM: document what does work and what doesn't
[18:44:39] --- Jabber-Wile has left
[18:45:08] --- Jabber-Wile has joined
[18:47:58] <YvesLafon> Larry: you should identify in the spec what is broken (like i18n). that's the minimum required
[18:48:25] --- bernard.desruisseaux has left
[18:48:55] --- julian.reschke has left
[18:49:03] --- julian.reschke has joined
[18:49:09] --- ekr has left
[18:49:51] <julian.reschke> Jeff H: not the right people in the room
[18:50:10] <=JeffH> huh?
[18:50:38] <julian.reschke> Paul H: do not specify requirements unless we actually implement something ourselves
[18:50:45] <=JeffH> that was Leif Johansson
[18:50:53] <=JeffH> who said not right folks in room
[18:51:11] <julian.reschke> sorry
[18:53:33] <julian.reschke> Yutaka oiwa: keep in mind that different auth mechanisms have very varying properties
[18:53:43] <julian.reschke> ...: so general guidelines may be hard
[18:54:47] <julian.reschke> ...: but provide guidelines about things like request smuggling threads etc
[18:56:15] <julian.reschke> Paul H: HTML dependencies/specific considerations?
[18:56:33] <julian.reschke> (missed what Robert Sayre said)
[18:57:07] <julian.reschke> MNot: when defining auth schemes keep in mind that intermediates may be in place
[18:57:25] <julian.reschke> MNot: how read draft-sayre
[18:57:31] <julian.reschke> Mnot: only few
[18:57:39] <julian.reschke> MNot: Q:use as basis? Yes.
[18:58:40] <julian.reschke> Paul H: whether to revise Cookies is much bigger than the other questions
[18:58:53] --- Jabber-Wile has left
[18:59:05] <julian.reschke> MNot: revise RFC2617 may be limited scope and feasible
[18:59:50] <julian.reschke> Roy F: let's actually do something instead of making things out-of-scope
[19:00:32] <julian.reschke> MNot: concerned about editorial capacity for revving RFC2617
[19:00:52] <julian.reschke> MNot: ...and sufficient people to review it.
[19:01:23] <julian.reschke> Paul H: there's no agreement to touch 2617
[19:01:36] <julian.reschke> Paul H: documenting sec properties is something else
[19:02:08] <julian.reschke> MNot: only few issues reported against 2617
[19:02:55] <julian.reschke> Paul H: no value in trying to fix Digest or Basic I18N
[19:04:04] <frank> Disagree with "no value in fixing Digest"
[19:05:35] <justin.erenkrantz@joost.com> frank: I guess that's more of an inter-op issue than fixing the spec.
[19:05:53] <julian.reschke> Roy F: rfc2616bis needs to define the framework
[19:07:04] <julian.reschke> Roy F: the remainder will also have to be included or referenced to
[19:07:34] <cnewman@jabber.org> Frank: are you volunteering to fix Digest?
[19:07:40] <julian.reschke> (discussion about Digest is fixable)
[19:07:54] <julian.reschke> between PaulH and LisaD.
[19:08:08] <frank> Chris: copying Alexey's ABNF?
[19:08:37] <julian.reschke> Robert Sayre: document how I18N in Basic works in practice today (IE behavior)
[19:10:08] <julian.reschke> Larry M: sounds like a charter discussion?
[19:11:01] <julian.reschke> Larry M: are these things important for the success of httpbis?
[19:11:58] <julian.reschke> Kurt Zeilenga: reminds us that the charter does not speak about updating/clarifying RFC2617.
[19:13:15] <frank> Kurt: ABNF version of 2831bis exists
[19:13:26] <julian.reschke> Lisa D: says IESG wants some level of auth/security coverage
[19:14:06] --- julian.reschke has left
[19:14:33] --- julian.reschke has joined
[19:14:45] <Lisa> More importantly, I think that normatively referencing or otherwise including authentication and confidentiality is *the right thing* because we need those for the Web to work properly!
[19:15:16] <julian.reschke> Kurt Z: focus on RFC2616bis for now; think about 2617bis later
[19:15:44] <julian.reschke> MNot: points to draft-p7-auth; do people have problems with that.
[19:16:12] <julian.reschke> MNot: keep that for now
[19:16:29] <=JeffH> ok, i b scribe now
[19:16:30] <=JeffH> watch out
[19:16:54] <=JeffH> mnot: three editors: jullian, lisa, roy
[19:17:04] <=JeffH> use ietf toolset
[19:17:04] <justin.erenkrantz@joost.com> yves
[19:17:07] <YvesLafon> s/lisa/yves/
[19:17:08] <=JeffH> yves
[19:17:10] <=JeffH> k
[19:17:11] <=JeffH> thx
[19:17:29] <=JeffH> will have -00 out very soon -- direct 2616 so we can diff it
[19:17:37] <=JeffH> then a -01 that's partitioned
[19:17:53] <=JeffH> hope is we can get -01 out by newyears (so much for xmas)
[19:18:18] <=JeffH> comments in ( ) are the scribe's
[19:18:35] <=JeffH> it is 1640h
[19:18:56] <=JeffH> ok, so issue disc is left
[19:19:06] <=JeffH> mnot not committed to spending entire hour on it
[19:19:08] <=JeffH> 'em
[19:19:59] <=JeffH> mnot wants to frame prob on 2616bis issue #22 AKA i22
[19:20:10] <YvesLafon> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i22 (for now)
[19:20:26] <=JeffH> cyrus daboo presenting his slides from the preso he did in chicago
[19:20:41] <=JeffH> issue is an Etag on a PUT? what's it mean, really?
[19:20:45] <julian.reschke> talking about http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i22
[19:20:53] <=JeffH> k
[19:20:58] <=JeffH> slide 2
[19:21:12] <=JeffH> is his preso from chi on the web?
[19:21:20] <=JeffH> "why do we care" ?
[19:21:25] <=JeffH> (i won't type in the slides)
[19:21:54] <=JeffH> thx for help julian
[19:22:03] <=JeffH> slide 3 -- solutions?
[19:22:10] <=JeffH> 4 options
[19:23:02] <=JeffH> there's a possible solution written up: -reschke-http-etag-on-write-07
[19:23:18] <=JeffH> it's fourth item on slide
[19:23:20] <justin.erenkrantz@joost.com> http://www.tools.ietf.org/wg/http/draft-reschke-http-etag-on-write-08.txt
[19:23:46] <=JeffH> something about two things are incompat
[19:23:59] <stpeter> audio gone?
[19:24:47] <=JeffH> with caldav -- we require if a strong etag is retd in a response that etag refer to data that is stored by the server
[19:25:05] <=JeffH> and then there's an atompub variation on that, that's apparently in conflict
[19:25:14] <=JeffH> PH: reads the atompub language.....
[19:25:35] <=JeffH> rfc 5023 section 9.5.1, it's an example
[19:26:29] <=JeffH> LM: remembers disc wrt etags, we didn't think about etags on PUT resps, cuz it was a content descp of the entity being retgurned in the msg, so shud clarify it as "not defined" in 2616
[19:27:00] <=JeffH> lm: so if yer doing caldav u shud note that the clarif of 2616 is that this is "not defined"
[19:27:32] <=JeffH> so if something is def'd in mult ways by diff parties, trying to pick winner will lead to troble
[19:28:14] <=JeffH> trouble
[19:28:14] <=JeffH> (where's dwim when i need it)
[19:28:14] <=JeffH> RF: disagrees w/larry
[19:29:02] <=JeffH> rf: we had lots of disc on this, and after several yrs it got merged into etag, and that's why it is listed as a resp header not an entity tag, and so if you read it one way it doesn't indicate the content that's responded to, but can read it another way as instruc to client -- so i (rf) have no trouble just picking one
[19:29:16] <=JeffH> rf: doesn't think it'd break anyone
[19:30:06] <=JeffH> julian: in xcap, the etag must be returned unless it was changed by the server, so doesn't want to break that and wants to use generic libs to impl this stuff
[19:30:28] <=JeffH> rf: well i gave my comments to the xcap wg and they ignored me so..... tough
[19:31:12] <=JeffH> lm: can you cache the put and on a get.........(something horked)....then on a get u don't get what you expect ..... that'd be bad
[19:31:33] <=JeffH> lm: think here that the advice for new clients is that diff servers will give u diff results
[19:32:08] <=JeffH> lm: for proxies.....(lost it)....(it's slightly diff).......not tell folks about xcap etag specifics.......
[19:32:35] <=JeffH> mnot summaries: rf thinks is fine as is...clarif of current behav is ok.....
[19:33:23] <=JeffH> lm: add an admonition to client implementors that handling of etags on part of servers isn't uniform, that mdight be ok
[19:33:40] <=JeffH> nmot: threads on list r verbose, kinda scary
[19:34:22] <=JeffH> julian: from current spec, it isn't clear how etags are dealt with
[19:35:08] <=JeffH> mnot: way fwd is to clarify current txt in 2616 is that etag is resp header, add admonitions to implementors
[19:35:16] <=JeffH> ok, done with i22 & etags
[19:35:29] <=JeffH> mnot: ....onto i69.....
[19:35:37] <YvesLafon> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i69
[19:35:45] <=JeffH> mnot: spec uses "requested variant" .......
[19:35:45] <=JeffH> thx julian
[19:35:49] <=JeffH> oops thx wes
[19:36:03] <=JeffH> i69 from julian
[19:36:17] <=JeffH> "clarify 'requested variant'"
[19:36:28] <=JeffH> 16 jul 2007
[19:37:25] <=JeffH> julian: this came up in conj with attempt to fix web ? methods and caching..... the ques is....
[19:37:40] <=JeffH> is the defn of the requested variant dep on request method?
[19:37:56] <mnot> relevant discussion: http://www.w3.org/mid/46C59F5C.6000702@gmx.de
[19:38:00] <YvesLafon> http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/thread.html#msg305 (thread where the issue was discussed)
[19:38:10] <=JeffH> (the details are in relevant disc ptd to above)
[19:38:11] <=JeffH> thx
[19:39:41] <=JeffH> mnot: this needs to go back to list -- there's something there that RF proposed.....
[19:39:47] <=JeffH> mnot: not i77
[19:39:50] <=JeffH> now i77
[19:40:04] <=JeffH> mnot: header line folding
[19:40:12] <=JeffH> wes: link?
[19:41:03] <YvesLafon> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i81
[19:41:07] <=JeffH> mnot: content negotiation of media types -- larry ?
[19:41:09] <=JeffH> lm: @mic
[19:41:34] <=JeffH> lm: limited applicability of accept headers in browsers that can accept hundreds of content types
[19:41:55] <=JeffH> lm: tho useful in some situations, volunteered to write some wording, need to follow thru on that
[19:42:40] <=JeffH> ? @ mike: seem to 'member....... how to handle accept values that have same qval ..... and how to prioritize 'em
[19:42:50] <=JeffH> mnot: that's client expressing pref, so is up to server
[19:42:57] <justin.erenkrantz@joost.com> jeffh: yngve @ mic
[19:43:46] <=JeffH> ?: there's same qval .... perhaps shd be spec'd who is making selection when two values are at "same level"
[19:43:51] <=JeffH> RF: is always case
[19:44:15] <=JeffH> yngve: but it's messily handled (?)
[19:44:30] <=JeffH> mnot: it's server-driven negotiation
[19:44:59] <=JeffH> mnot: (back to larry) ? - driven negotiatn, is it useful to try to clarify?
[19:45:12] <=JeffH> lisa: see choices given to user all the time......
[19:45:32] <=JeffH> lisa: except for the neg thats present to user.....
[19:45:52] <=JeffH> mnot: there's no format (mumble)......
[19:45:57] <=JeffH> lisa: ok (sits down)
[19:47:55] <=JeffH> lm @ mic: so ie did something wrt active client, and mebbe might be useful to borrow descp of this....... can see prot level wasn't right place to do this...... factors into why folks use FORMs for authn....... ie they have control over presentation of info....... so we tried to sorta put stuff into http that influenced preso of into to user, and mebbe doing it at http level isn't the right place
[19:48:05] <=JeffH> mnot: larry u will do text?
[19:48:07] <=JeffH> lm: yes
[19:48:19] <=JeffH> mnot -- now i93
[19:48:30] <=JeffH> talk briefly about this
[19:48:40] <YvesLafon> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i93
[19:48:45] <=JeffH> idea is http defines error behavior in some contexts
[19:48:48] <=JeffH> ths
[19:48:50] <=JeffH> thx
[19:49:24] <=JeffH> but doesn't in some context, eg "mult msg header fields"
[19:49:37] <=JeffH> clarification needed arguably
[19:50:00] <=JeffH> discussing this could help estab precedence for figuring out how to clarify such stuff
[19:50:21] <=JeffH> lm: linear white space is an example......
[19:50:59] <=JeffH> lm: if u see mult headers, and u writing new service, the u prob shud send back error
[19:51:25] <=JeffH> lm: once u make it "normative" are the things that r out there are now non-compliant?
[19:52:06] <=JeffH> lisa: sez ther's no rule that we can't make a new rule that breaks old impls -- cuz we have a new rfc #, and we can make new reqs going fwd
[19:54:04] <=JeffH> ?: xfer encoding header ....... (mumble)
[19:54:49] <=JeffH> yngve: in newer cases we think the first one we see is correct one (content type)
[19:55:40] <=JeffH> yngve: comething about cookies
[19:55:44] <=JeffH> mnot: that's orthog
[19:56:25] <=JeffH> yng: wud like clarification wrt significance of order of content types
[19:56:45] <=JeffH> otherwise say it is up to client to figger it out or declare what it is.....
[19:57:25] <=JeffH> RF: some impls suck, that's life, we get errors on wire, we need to spec what's an error and what's not, but not how to handle every one,
[19:58:18] <=JeffH> julian: another SDO complained that http-wg doesn't care about these edge cases, so we shud figger out these edge cases -- as an overall philosophy
[19:58:37] <=JeffH> ?: client shudn't try to be smarter than the user
[19:58:56] <=JeffH> ?: giving some error recovery choices to user is ok
[19:59:26] <=JeffH> lm: 2616 isn't vague on error responses, more than one is an error
[19:59:26] <justin.erenkrantz@joost.com> JeffH: that was yves
[19:59:31] <=JeffH> thx
[19:59:40] <=JeffH> in itself
[20:00:01] <=JeffH> mnot: there's a lot of philosophy that readers of present spec just don't get
[20:01:56] <=JeffH> lm: there's diffs btwn intermeds and clients, the former might get confused where clients wont, eg do i cache this? so he doesn't think shud mandate how to recover from bugs, cuz there's much subtlety here
[20:02:03] <=JeffH> mnot: wants lm to write this down
[20:02:15] <=JeffH> phoff: this is good, we need to say stuff like this
[20:02:55] <=JeffH> lm: if you don't know how to recover from a bug, we give u some things u can do, but unless u don't knwo better, u shud just do what (we say in spec?)
[20:03:22] <=JeffH> ie. don't try to be *too* clever (?)
[20:04:08] <=JeffH> julian: giving an example, browser doesn't want to give too much detailed garbage to common user
[20:04:27] <=JeffH> mnot: yeah, and when I'm doing mach-to-mach stuff, i want lots of data
[20:04:40] <=JeffH> lm: (something in support of mnot)
[20:04:58] <=JeffH> lm: us mandating behavior doesn't always hold, so no point in doing it
[20:05:05] --- Lisa has left
[20:05:36] <=JeffH> lm: we can't mandate anything that wud make situation better
[20:05:43] <=JeffH> sayre: essentially agrees
[20:06:12] <=JeffH> lm: if u get two headers, u shud note both are unreliable, cuz likely the impl ur dealing with is broken and broken in other ways too
[20:06:22] <=JeffH> sayre: so agrees
[20:07:22] <=JeffH> david morris: this was orig written cuz some fields can be folded and some can't -- so if some one blindly folds headers, they assume if they see a dup header, they fold it (errors cascade)
[20:07:50] <=JeffH> dm: it isn't a "narrow problem" it's part of a broader issue
[20:08:42] <=JeffH> dm: i get lots of popups wrt broken javascript, and they are from namebrand sites i have to do biz with
[20:08:46] <=JeffH> mnot: end of issues disc
[20:09:12] <=JeffH> mnot: summarizes what we're trying to do in near term.
[20:09:12] <=JeffH> if u have other issues pls bring to list
[20:09:27] --- jack.bates has joined
[20:09:52] <=JeffH> bakeoffs and such -- mihgt have apps area iop testing for a day at next ietf
[20:09:58] <=JeffH> @ philly
[20:10:33] <=JeffH> lm: certainly can facilitate by documenting what the test frmwk will be and all -- that's in scope if the testing isn't in scope-
[20:10:56] <=JeffH> mnot: agrees, wants to get started in this work
[20:11:42] <=JeffH> so wrt f2f ietf meetings, we use that time for gnarly disc like this and iop if we do the latter
[20:11:47] <=JeffH> ok, we're done
[20:11:48] <=JeffH> !!!
[20:12:01] <=JeffH> oh oh oh
[20:12:19] <=JeffH> meet at msg bd at 1800h tonite for disc of http authn stuff
[20:12:28] <=JeffH> gonna finish by 2000h
[20:12:33] --- cyrus_daboo has left
[20:12:38] --- tlyu@jis.mit.edu has left: Disconnected
[20:12:40] --- =JeffH has left
[20:12:45] --- YvesLafon has left
[20:13:59] --- justin.erenkrantz@joost.com has left
[20:16:10] --- cnewman@jabber.org has left
[20:16:14] --- frank has left
[20:20:34] --- mnot has left
[20:25:42] --- stpeter has left
[20:31:44] --- jack.bates has left