[11:58:52] Yves Lafon joins the room [12:28:16] Yves Lafon leaves the room [13:03:41] Yves Lafon joins the room [13:05:54] Yves Lafon leaves the room [13:06:00] Yves Lafon joins the room [13:07:58] Yves Lafon leaves the room [13:08:03] Yves Lafon joins the room [13:11:57] http://tools.ietf.org/wg/httpbis/agenda?item=agenda78.html [13:19:08] Anne joins the room [13:19:09] alexey.melnikov joins the room [13:19:20] Hello World [13:19:26] it works [13:19:36] hello Maastricht [13:19:46] maastricht, 10 points [13:20:54] mtcarrasco joins the room [13:21:08] Ping [13:21:10] Barry Leiba joins the room [13:21:50] cyrus joins the room [13:22:15] http://videolab.uoregon.edu/events/ietf/ietf781.m3u for audio [13:22:38] martin.thomson joins the room [13:22:45] do we have etherpad? [13:23:09] Yves will scribe [13:23:48] (agenda bashing) [13:24:53] =JeffH joins the room [13:24:59] Alexey, do we need to talk about rechartering? (thinking of HTTP Timeout) [13:25:00] I can only hear mnot [13:25:07] mnot: not now [13:25:23] -- httpbis status -- (see slides) [13:25:53] David Cooper joins the room [13:26:24] tonyhansen joins the room [13:26:32] anne: alexey was talking before - off mic [13:26:56] I'll slap him if he starts to do that again [13:27:13] I scribed Alexey's question for the benefit of the remotees [13:27:55] mnot: want to have LC in ~3 monthes [13:31:00] new workflow allows editors to incorporate uncontroversial changes directly in the spec [13:31:10] and keep state in trac [13:34:13] Hyong-Jong Paik joins the room [13:34:23] Julian: previous drafts done before IETF meetings, -11 will be published soon as we made enough progress [13:34:45] [13:38:14] roy.fielding joins the room [13:38:44] spromano joins the room [13:40:11] Julian joins the room [13:40:40] Question? -> none [13:40:59] roy, can you hear us? [13:41:01] -- RFC2817 -- [13:41:16] yes [13:42:17] mnot: how much of 2817 can be moved to httpbis (CONNECT? Upgrade?) [13:42:43] can we obsolete 2817 if we move these parts into httpbis? [13:42:46] Alexey: thumbs up [13:42:57] Bjoern Hoehrmann joins the room [13:42:58] works for me [13:43:02] Adam barth: obsoleting it would be fine [13:43:02] (Adam Barth) [13:43:42] Alexey: changes are in the spirit of the WG charter [13:44:32] Cyrus: one active draft reference 2817, See 4825 and wrap [13:44:45] Julian: might be only the status code registry [13:45:15] Martin: 4825 suggest that people use Upgrade to TLS [13:45:57] Alexey: in practise we do that all the time, if there is an upgrade to xcap, it will fix the link [13:46:49] -- RFC2617 -- [13:47:19] mnot: part7 is the http auth framework, the meat of auth (basic and digest) is in 2617 [13:47:59] issues like i18n auth scheme registry might be addressed [13:48:32] a path could be to have basic and digest in one or two drafts, framework in p7 [13:49:05] Alexey: seems to be the right thing to do, having the framework in p7 is fine, other two documents will need a recharter [13:49:52] mnot: no changes needed as a first step to produce new documents, only i18n will require changes [13:50:28] Alexey: reopening digest could be controversial [13:50:28] Cyrus: I don't see that draft-ietf-vwrap-type-system has any ref to RFC 2617. Checking whether I got the right doc when you said that. [13:50:54] Never mind... 2817, not 2617. [13:51:18] dwd joins the room [13:52:33] mnot: if the recharter says that only editorial changes are made, it could help. [13:52:53] Cyrus: not sure IESG will accept Digest as-is [13:53:10] Joonhyung Lim joins the room [13:53:37] Alexey: moving to historic might help. If somebody want to reopen Basic and Digest, it would be better if it was in a WG [13:53:53] Cyrus: Mutual Auth is there as an example of new auth [13:54:06] mnot: we are not a security-related WG [13:54:10] How about defining a registry for auth schemes? [13:54:42] Alexey: that is a good idea (in response to Roy's comment) [13:55:17] -- Registration Policies -- [13:56:30] Alexey: does it mean that every RFC can define new method? [13:56:52] Julian looking at the relevant text [13:57:00] IETF Review: "New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]" [13:57:01] HTTP has historically been a gateway protocol -- arbitrary methods are supported but we have no registry for sharing. [13:57:03] mnot: most important are methofs and status code [13:57:07] test [13:57:16] Julian leaves the room [13:57:22] Julian joins the room [13:57:24] suggestion: Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG. [13:58:48] Alexey: Informational is allowed by the definition [13:59:09] Martin Thomson: Standards Action seems in order [13:59:36] Alexey: we just need a gatekeeper [13:59:48] Martin: IETF review also has a gatekeeper [14:00:31] Julian: Specification required + expert review. Do we want to allow other bodies like W3C to register new methods? [14:01:33] Martin: we are looking at a higher bar than just IETF review [14:01:50] Alexey: How about IETF review + expert review ? [14:02:30] Martin: I think that IETF review imply expert review [14:02:51] => IETF Review indeed seems to cover the case [14:02:58] requiring an RFC for a new HTTP method? [14:03:17] Zhen Tsao joins the room [14:03:19] mnot: yes (response to Anne) [14:03:28] sounds like overkill to me [14:04:45] mnot: probably a higher bar for auth scheme [14:04:55] Alexey: you want to allow experimentaiton as well [14:05:54] Martin: point of order, spec required implies expert review, no need to specify it [14:07:22] Cyrus: why TC and CC don't require IETF review while Range would get it ? [14:07:34] mnot: because we already have entries in the registry [14:08:14] adam: is there spam protection for upgrade tokens? [14:08:16] mnot: yes [14:08:39] sam johnston: any plan to have a user-editable resitry for link ? [14:08:49] mnot: not in scope of this wg, will talk offline [14:10:03] mnot: when you get question about what status code to use and you point to let's say a Webdav-defined status code, it is common to have a "it's webdav, not an HTTP status code", what can we do to clear up that perception ? [14:10:29] Anne, just for the record: the RFC requirement for methods isn't new [14:11:03] kk [14:11:15] can be fixed in the registration text, also in the registration procedure we can require specific document to register the status code. [14:11:52] what would people think to require specific document to register status code ? [14:12:46] Julian: depends on how litteral you take that, if you have 3, do you need 3 docs ? [14:12:49] mnot: no [14:13:14] Julian: also the shouldn't be a need to split status code and methods [14:13:55] martin: maybe you want to include guidance in the registry to define what you want to put in those [14:14:26] mnot: just opened new methods about guidance to define extensions like methods etc... [14:14:36] -- Content-Disposition -- [14:15:06] [14:18:06] Julian: people interested in security consideration for Content-Disposition are welcomed to contact me [14:18:25] -- Active Issues -- [14:19:18] http://trac.tools.ietf.org/wg/httpbis/trac/query?status=assigned&status=new&status=reopened&group=component&col=id&col=summary&col=priority&priority=!blocked&priority=!later&milestone=unassigned&report=17&order=priority&type=design [14:19:47] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/224 [14:19:54] Header Classification [14:20:29] do we want to rethink header classification ? [14:21:44] Martin: good suggestion from Roy to keep only connection and end-to-end headers. [14:22:12] mnot: general vs entity is a confusing concept [14:22:29] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/225 [14:22:47] contradiction between p2 and p6 text [14:23:34] conclusion was to invalidate [14:23:35] people slightly in favor of invalidating [14:24:18] need text for #100 about DNS spoofing, contributions welcomed [14:24:35] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/213 [14:24:48] The only thing left for #109 is "entity-header" classification, which we just agreed to remove. [14:25:06] the spec define 1xx to 5xx while grammar allow 3 digits, is 016 or 913 allowed? [14:25:31] Julian: 016 or 913 require IETF review anyway, so IANA should never see those [14:26:05] mnot: also do we want to reserve a range for local use? [14:27:01] adam: clarify 0xx and 6+xx in which direction ? [14:27:49] mnot: clarify that they are reserved, and cannot for now be registered. [14:28:03] Alexey: is thighening the ABNF discussed [14:28:25] mnot: not yet, perhaps in the future a new class will be added [14:29:03] Julian: if we change the ABNF if will change a semantical error in a parsing error. Do we want to do that? [14:29:24] Alexey: I will check what SMPT did [14:29:36] and do the opposite ;-) [14:30:33] 'effective request URI', editors are talking about using 'target URI'. [14:31:39] In SMTP: Reply-code = %x32-35 %x30-35 %x30-39 [14:31:49] So this is more restrictive than 3DIGIT [14:32:08] Jeff: Effective Request URI implies that it is not serialized on the wire. It might be good to keep the explanation in the spec [14:32:24] perhaps using ERU as an acronym [14:32:30] no no no [14:32:55] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/221 [14:33:35] Should Effective Request URI consider HTTP/1.0 ? [14:33:59] Jeff: that should be noted in the spec [14:34:19] mnot: but no need to define an algorithm for HTTP/1.0 [14:34:32] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/222 [14:35:35] yeah, but the whole purpose of * is not to be a URI [14:35:41] Julian: we need to come up with an URI, we need to state what that textual representation is [14:36:32] Julian: if we don't define target URI for OPTIONS, there are other places in the spec where we have that issue [14:36:48] those places already are special-cased for * (they must be) [14:36:50] Adam: you need to have an URI for everything at the security layer. [14:37:43] Martin: is * in the http scheme at all? Would a specific scheme be ok ? like "*" ? [14:37:55] Alexey: nice hack, but might be difficult to register [14:38:09] nope [14:38:30] Adam: in CORS, "*" represent "any URI" [14:38:49] => continue on the mailing list [14:39:01] suggestion wasn't serious :) [14:39:14] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/233 [14:39:28] is * only usable for OPTIONS ? [14:39:44] some nodding heads [14:40:03] Julian: OPTIONS is used a lot OPTIONS * almost never [14:40:07] (in WebDAV) [14:40:29] Martin: should we kill the star ? [14:40:50] It works fine for me. [14:41:02] I see no reason to stop implementing OPPTION * [14:41:22] use case? [14:41:24] for OPTIONS [14:41:27] yes [14:41:30] stpeter joins the room [14:41:33] for OPTIONS * [14:41:34] OPTIONS * specifically [14:41:42] mnot => continue on the list [14:41:43] for server OPTIONS [14:42:01] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/158 [14:42:06] maybe define KA in an appendix [14:43:37] yngwe: we use proxy-connection to indicate ka to the proxy. don't remember why [14:44:01] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/79 [14:44:43] On OPTIONS *: If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof). [14:45:58] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/203 [14:46:20] The advantage of OPTIONS * is that it makes a request without identifying a specific URI, thus allowing some security issues to be discovered before revealing the traget of the next request. It also does not impact hit rates. [14:46:22] Max-Forwards usable only for OPTIONS and TRACE ? [14:46:53] some nodding [14:47:21] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/232 [14:49:02] issue is about adding prose to avoid transforming UA in an Accept, with too much details [14:49:11] whereas it used to be a MUST NOT? [14:49:28] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160 [14:50:03] Zhen Tsao leaves the room [14:50:43] yngwe: there are some site that were broken while redirecting on 301/302 on POST [14:51:04] Adam: is this linked to 307 and user prompting ? [14:51:24] mnot: it is a different one, we should open an issue on user prompting [14:51:42] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/178 [14:52:01] still needs discussion, a partial proposal in upcoming -11 [14:52:40] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/235 [14:52:41] I did not addess 178 yet ... just changed terms to make existing text clearer for content-md5 [14:53:03] we should consider deprecating content-md5 in general [14:54:09] Active Design ticket list [14:54:29] the "interesting" ones are marked 'later' [14:54:58] hardest issues are #20 and #22 [14:55:13] http://trac.tools.ietf.org/wg/httpbis/trac/report/9 [14:55:24] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/22 [14:56:16] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/20 [14:56:25] long history, difficult to reach consensus [14:57:24] Adam: do you need data for what browsers do wrt #20 ? [14:57:39] mnot: more data welcomed, as browser changed [14:59:21] -- Memento presentation -- [15:00:40] [15:00:41] Yves Lafon leaves the room [15:00:56] Yves Lafon joins the room [15:00:56] Yves Lafon leaves the room [15:00:57] Yves Lafon joins the room [15:00:57] Yves Lafon leaves the room [15:00:57] Yves Lafon joins the room [15:00:57] Yves Lafon leaves the room [15:00:57] Yves Lafon joins the room [15:01:13] Yves Lafon leaves the room [15:01:54] Yves Lafon joins the room [15:01:55] Slide: Memento Framework [15:04:18] should look for overlap with http://greenbytes.de/tech/webdav/rfc5829.html [15:06:29] Joonhyung Lim leaves the room [15:06:35] stpeter: is the whole flow depending on having the original URI being active ? (including DNS) [15:07:19] herbert: it can happen from the archive [15:08:01] Julian: recent registered 'Link' relationships might overlap [15:09:41] carrasco: we have the same issue in the language dimension [15:10:42] martin: how do I do "monitoring state between date d1 and d2" ? [15:11:14] herbert: there are multiple relationships, one pointing to the first or the last and there is a discovery API to get a list of mementos with associated dates [15:11:35] martin: wanting for the drafts [15:11:41] http://www.mementoweb.org/ [15:12:19] and http://www.mementoweb.org/guide/http/ has some details [15:12:23] running code! [15:12:26] herbert: there are plugins for mediawiki, a mozilla plugin, and more to come [15:12:56] mnot: the earlier the discussion starts the better, in case the protocol ahs to change [15:13:05] David Cooper leaves the room [15:13:15] -- ADJOURNED -- [15:13:20] mtcarrasco leaves the room [15:13:21] cyrus leaves the room [15:13:34] martin.thomson leaves the room [15:13:45] Julian leaves the room: Computer went to sleep [15:13:51] =JeffH leaves the room [15:14:06] Barry Leiba leaves the room [15:14:19] Yves Lafon leaves the room [15:16:29] alexey.melnikov leaves the room [15:17:07] stpeter leaves the room: Computer went to sleep [15:21:14] roy.fielding leaves the room [15:38:41] tonyhansen leaves the room [15:41:38] tonyhansen joins the room [15:43:31] Zash joins the room [15:43:59] Zash leaves the room: offline [15:44:54] stpeter joins the room [15:48:37] martin.thomson joins the room [15:50:40] martin.thomson leaves the room [15:58:58] stpeter leaves the room [16:01:33] Hyong-Jong Paik leaves the room [16:02:08] spromano leaves the room [16:20:08] Julian joins the room [16:20:13] Julian leaves the room [17:22:17] tonyhansen leaves the room