[06:22:16] Julian Reschke joins the room [06:50:23] roy.fielding joins the room [06:54:07] julian: are you in the real room? [06:55:04] Hi Roy. No, I'm still in my hotel room. The meeting will start in 65 minutes. [06:55:45] I know ... trying to stay up late here in Calif. [06:55:58] Ack. [07:33:11] roy.fielding leaves the room [07:34:44] Julian Reschke leaves the room [07:48:28] roy.fielding joins the room [07:51:34] Julian Reschke joins the room [07:54:48] lellel joins the room [08:02:15] somebody test the audio? [08:02:25] Barry Leiba joins the room [08:02:33] cyrus joins the room [08:02:48] Anyone on the audio feed? [08:02:48] roy - can you hear? [08:02:52] Chris Newman joins the room [08:02:58] very faint [08:03:10] will go get headphones [08:03:32] xmlscott joins the room [08:04:10] mhp joins the room [08:05:09] agenda bashing [08:05:44] huguei joins the room [08:05:51] Chris Newman leaves the room [08:06:18] Thomas Roessler joins the room [08:06:37] mnot: agenda review [08:06:47] Chris Newman joins the room [08:06:56] Topic: draft overview (Julian) [08:07:41] audio is working great [08:08:15] julian: summary ...some issues harder than we thought [08:08:29] ... tracker on tools.ietf.org ... [08:08:37] ... no changes without there being an issue for the change .. [08:08:51] ... for design issues, mailing list discussion first ... [08:08:59] ... if consensus to open issue in tracker, then Mark does that ... [08:09:05] ... use svn on tools.ietf.org ... [08:09:08] ... drafts checked in there ... [08:09:23] ... check-ins are linked to issues; you can easily find out what each change of the spec relates to ... [08:09:32] ... diffs available, too ... [08:10:00] ... WG started in YVR ... [08:10:21] ... draft-00 was rfc 2616, partitioned ... [08:10:46] (Julian tries to recount the 7 drafts from memory) [08:11:27] julian: authenticaiton draft is only the framework, not basic and digest [08:11:59] ... draft-01 had original list of changes ... [08:12:07] ... draft-02 before Philadelphia ... [08:13:06] ... BNF to ABNF fixes, housekeeping ... [08:13:12] ... draft-03, last month ... [08:14:11] ... minor clarifications, IANA considerations, move status code registry from TLS, lots of minor clarifications ... [08:14:37] ... rewrite of 303 (in view of httpRange-14 and cacheability) ... [08:14:49] ... 305 is deprecated ... [08:15:06] ... make weak ETags more useful for methods other than GET ... [08:15:11] ... can use them in more complex operations ... [08:15:29] ... there is an unpublished draft with more minor clarifications and introduces HTTP method registry ... [08:15:51] ... modeled after status code registry ... [08:16:05] ... will now go through some open issues ... [08:16:19] ... header registry ... [08:16:33] ... include additional information, e.g., list syntax? [08:16:39] ... i18n question -- RFC 2047 encoding? [08:17:11] ... if we demand that, do we modify the registration process, or do we just hint? [08:17:45] ... mostly done with reference updates ... [08:17:54] ... compression specs -- informational or proposed standards ... [08:18:09] ... we call these downrefs out in the document and claim they are not a problem ... [08:18:33] ... welcome review of that from people who understand the compression specs ... [08:18:48] ... still referencing historic URI specs; expect that to change and expect Roy to fix that ... [08:19:12] RFC 1950 and 1952 are Informational [08:19:29] ... IANA status code registry -- RFC 2817; move into httpbis ... [08:19:32] ... require IETF review ... [08:19:44] julian: message registry is new, not in the public draft; will be in -04 ... [08:19:50] ... requirements same as for status codes ... [08:19:56] ... looking at what additional info is required .. [08:20:07] ... safeness! ... [08:20:25] ... more required fields to put in? ... [08:20:42] ... moved registration for existing other messages into separate (not yet published) document ... [08:21:11] ... BNF migration to ABNF ... [08:21:44] ... LWSP is one critical difference, also list production that makes it easier to write grammar for comma-separated lists ... [08:21:58] ... turns out that some 2616 definitions are a bit vague ... [08:22:08] huguei leaves the room [08:22:08] ... look at every instance in BNF to see what we do ... [08:22:27] ... want to get rid of some places where LWSP is allowed, but shouldn't be ... [08:22:34] ... e.g., between header name and colon; lot of work ... [08:22:48] ... fixed errors that couldn't be parsed ... [08:22:57] ... get rid of English productions ... [08:23:07] ... use 5234 core rules ... [08:23:55] ... string constants in BNF are insensitive -- need octet sequence for case-sensitive ... [08:24:29] bortzmeyer joins the room [08:24:30] ... using hacked version of Fenner's parser to convert from RFC 2616 BNF ... [08:24:34] ... i18n ... [08:24:42] ... RFC 2616 has text production that's used in some headers ... [08:24:52] ... claims that things can be encoded based on RFC 2047 ... [08:25:00] ... we think that nobody implements this ... [08:25:11] ... spec isn't clear where text production is used -- sometimes only mentioned in prose ... [08:25:21] ... go through all headers, decide what to do ... [08:25:42] ... observation: don't need internationalized versions at all except for Content-Disposition ... [08:26:07] ... also, Atom came up with another way to encode, using utf-8 and percent-encoding ... [08:26:16] ... not aware of anything that uses RFC 2047 successfully ... [08:26:24] ... one thought about content-disposition .... [08:26:40] ... 2616 mentions it, but "it's not part of the standard", not mentioned in the previous version ... [08:26:49] ... lacks some information that makes it possible to implement it ... [08:27:00] ... need to read many additional RFCs to get an implementation right ... [08:27:16] ... either update and expand the section, or move to separate document ... [08:27:44] mnot: so, move on to discussion, based on Julian's question [08:28:30] pass me the blue sheet [08:28:44] [08:28:57] mnot: header registration -- not specific to HTTP; is message header registry [08:29:06] cary joins the room [08:29:10] ... don't think we want to have format-specific stuff in registration procedure ... [08:29:18] ... field in registration template for addtl information ... [08:29:26] ... thought was to use that for protocol -specific things ... [08:29:38] ... slight concern that people will come along, read that, not read spec ... [08:29:55] my comment: Content-Disposition should be owned by MIME, not defined by HTTP [08:30:29] julian: idea was that if there's information that would be useful for generic libraries, we could put that into the registry [08:30:36] mnot: make the library discover it in the registry? [08:30:40] julian: no, but its author [08:31:09] ... e.g., it would be useful for people to say whether or not header is list type -- repeatable means that it needs that syntax ... [08:31:12] ylafon joins the room [08:31:23] AlekseyMelnikov: create a second registry with expanded information? [08:31:38] ... provide in description field, impose extra requirement ... [08:31:49] julian: Remind IESG when they review? [08:31:56] barry: [08:32:32] julian: see people getting it wrong in HTTP. Need to write up addtl info that's needed to get Content-Disposition right in HTTP [08:32:42] PaulHoffmann: Second registry model has failed before. Don't do it. [08:32:57] Chris Newman: on additional checks -- current header registry is expert review ... [08:33:05] ... instructions for expert reviewer would be great ... [08:33:26] ... having expert reviewer check things is probably more reliable than having iesg do that ... [08:34:24] ScottLawrence: list-type flag in registry -- in SIP, if syntax says "list of things", then it's repeatable [08:34:37] julian: Well, we're getting rid of the list production [08:34:52] ... that makes it hard to see whether the header has that structure ... [08:35:03] ... so, related question is whether it's a good idea to get rid of that production ... [08:35:08] ... it makes the current spec very readable ... [08:35:16] mnot: any more comments about header registry? [08:35:30] ... template in 3864 ... [08:35:35] ... "related information" field ... [08:35:42] ... so, we had content-disposition and list rule ... [08:35:47] ... content-disposition now ... [08:36:03] mnot: so, taking content-disposition out of HTTP would be useful/ [08:36:16] julian: sounds like Roy is agreeing to remove it from HTTP RFC alltogether [08:36:20] yes [08:36:33] mnot: change reference in the registry to NNNN [08:36:43] cyrus leaves the room [08:36:49] julian: from personal experience, know that UA vendors get it wrong (MS, Apple) [08:37:00] ... was discussing that with them on HTML mailing list ... [08:37:09] ... they said it would be good if spec was clearer ... [08:37:19] ... could be short RFC that defines use of Content-Disposition in HTTP ... [08:37:32] ... not redefining, but saying how to use it ... [08:37:37] mnot: normative reqs or BCP? [08:37:45] julian: clarification. The RFCs are all out there ... [08:37:52] UA vendors get lots of things wrong. *shrug* [08:38:05] ... some of what the RFC says is unnecessary, e.g., line folding ... [08:38:35] mnot: First step - keep 2616 text on content-disposition? [08:38:41] julian: In current form, text causes confusion. [08:39:02] ... first, it's not part of this spec, then defines it, then says "lots of security considerations", but not giving any ... [08:39:09] ... that's not helpful, removing would be a good idea ... [08:39:46] mnot: pull it and wait for text to come, or update current text? [08:39:59] julian: fixing current text would cause dependencies on even more RFCs. [08:40:09] Removing it is okay. Creating a separate spec of "How to use CD in HTTP" is okay. I do not believe there are any interoperable spec of CD right now. [08:40:57] julian: yes, indeed. One concern is whether we spend WG time on it... [08:41:13] ... doesn't matter whether it's individual submission as long as it can get on the standards track ... [08:41:39] mnot: inclined to go ahead and remove; don't see WG focusing on it at this point. [08:41:57] ... open issue, take it on the mailing list, go forward from there ... [08:42:35] mnot: i18n -- content-disposition is the place where it's used; people feel there were other places [08:42:46] ... the other place are the comment fields in warning headers ... [08:42:59] julian: warn values, status lines, comments [08:43:04] the old useless From header as well [08:43:15] Chris Newman: authentication header (Digest) [08:43:17] authorization cookie in basic/digest (but 2617) [08:43:31] mnot: if such a thing was to specify its use, which might be useful [08:43:51] ... 2047 is the way to encode internationalized text where a text production occurs ... [08:43:58] ... we're removing text productions ... [08:44:09] ... minimize text production ... [08:45:16] ... 2616 language on warn-text is calling out 2047 explicitly ... [08:45:31] ... plan to call out 2047 explicitly if it's used, remove generic rule ... [08:45:44] julian: agree [08:45:48] mnot: what else on i18n? [08:46:07] ... constraint on what a header may contain? (character set?) ... [08:46:14] ... loosely, header can contain anything ... [08:46:28] julian: whether we could allow new header definitions to state "encoding of header value is utf-8" [08:46:53] ... there is a concern from people writing generic http code that, in general, this code parses messages and then provides API to access header values, at which point they have been decoded ... [08:47:04] ... at this point, these libraries use iso-8859-1 as default ... [08:47:11] ... such APIs would mis-interpret UTF-8 values ... [08:47:47] mnot: notion is whether we can restrict header values to iso-8859-1, looking at roy [08:47:50] Roy, did you get the question? [08:48:02] spoken against 8859-1? [08:48:04] julian: to what extent are iso-8859-1 characters outside the ASCII Range used in practice [08:48:12] s/julian/chris/ [08:48:20] chris: if not used, then could deprecate [08:48:33] mnot: file names in content-disposition, warning (hardly used), that's about it [08:48:44] paul: every time I see a file name from European come in ... [08:48:55] ... if I read it in 3 different MUAs, it will each time look different ... [08:49:01] ... suspect browsers are in similar shape [08:49:14] mnot: can we profile http headers down even further than 8859-1 [08:49:26] ... interesting, since in ML discussions a bunch of people wanted to go the other direction [08:49:36] Question is whether we can restrict headers to ISO8859-1, and even whether we can restrict them further. [08:49:42] yngveP: have seen a lot of file names in content-disposition that are in non-ASCII range [08:49:49] ... not just ISO, but also other languages ... [08:49:57] paul: you mean, not even 8859-1? [08:50:02] yngve: yes [08:50:07] julian: using 2231 encoding? [08:50:29] yngve: no; have to use information from charset on the content-type and other places to guess what the bytes actually mean? [08:50:40] julian: not interoperable; firefox follows RFC [08:50:42] in other words, CD is not interoperably implemented -- never has been. [08:50:47] right [08:50:55] yngve: we're seeing this stuff; we have 2231 support, but not much used [08:51:06] julian: I hear that this is broken and needs to be fixed [08:51:10] mnot: specifically C-D? [08:51:14] julian: yes [08:51:32] chris: you can do transition plan. Say "us-ascii is interoperable subset at this point" [08:51:48] HTTP/1.2 [08:51:48] ... "if you want to be liberal in what you accept, utf-8 is easy to recognize" ... [08:51:59] ... that is an option, has been done in IMAP [08:52:12] barry: hasn't worked in IMAP [08:52:33] mnot: re HTTP/1.2, wondering about protocol versioning [08:52:59] mnot: would like to get sense of room re profiling down to ASCII [08:53:01] paul: in 1.1? [08:53:12] mnot: that's a necessary precondition [08:53:35] paul: how could we specify which character set we're using? [08:53:44] IESG, amybe, but there is no technical reason to avoid a version bump. [08:53:56] mnot: why we're having that discussion is extension headers [08:54:00] s/amybe/maybe/ [08:54:02] ... there's nothing that constrains that in HTTP ... [08:54:25] paul: so we would come up with standard way -- [08:54:39] ... [08:54:48] barry: [08:54:54] bortzmeyer leaves the room [08:54:56] mnot: Roy suggesting HTTP/1.2? [08:55:03] not 2.0 [08:55:04] paul: 2.0? [08:55:11] chris: Let's spec HTTP5 over IPv8 [08:55:13] cyrus joins the room [08:55:55] chris: if we look at what RFC 2822 did with its BNF, there is a big chunk of obsolete grammar [08:56:10] ... e.g., if you put whitespace here, then that's a really bad idea ... [08:56:25] ... propose putting 8859-1 into obsolete corner, don't generate [08:56:29] PHB joins the room [08:56:35] mnot: To be more concrete (since we're talking to extension authors) ... [08:56:53] ... section 4.2 ... [08:57:23] ... talking about either prose here or changing grammar ... [08:57:27] ... include advice on character sets ... [08:57:50] bortzmeyer joins the room [08:58:01] Barry: not channeling Roy, are we saying "SHOULD accept 8859-1, SHOULD accept utf-8, SHOULD (MUST?) generate ASCII" [08:58:37] ... tell people that utf-8 is a desirable future ... [08:59:14] mnot: Who would support adding such advice to the spec, whereby people would be cautioned to be liberal with respect to utf-8 and ASCII, people minting new headers only use ASCII, using SHOULD [08:59:16] *hummmm* [08:59:20] mnot: concerns? [08:59:21] *silence* [08:59:43] mnot: hearing strong humm in favor [08:59:54] ... there will be details to work out ... [09:00:34] topic: BNF [09:01:12] mnot: LWS [09:01:26] julian: somewhere in the syntax, it states where implicit LWS is allowed [09:01:37] ... trying to automate process of expanding that in BNF based on what BNF definition failed .. [09:01:49] s/on what BNF definition failed/on what BNF definition said" [09:01:54] ... that attempt failed ... [09:02:09] ... unreliable header parsing, allow people to put things there that shouldn't be? [09:02:20] mnot: Can we identify the places where we would need to make that decision? [09:02:28] julian: tried, couldn't get it to work, can try again [09:02:34] ... got output from BNF parser ... [09:02:49] ... try to automate, so we know every instance in the grammar ... [09:03:07] mnot: way forward: identify, give editors some leeway for obvious cases, then make WG decision [09:03:14] ... sounds painful but doable ... [09:03:24] I'd rather just make the changes, place LWS where we think it belongs and BWS where we think it would be allowed in 2616 but should not be, and then only discuss the controversial one... just ditto what Mark just said. [09:03:43] julian: ... [09:03:55] Barry: [09:04:06] thanks Barry [09:04:13] Any time. [09:04:22] mnot: editorial work, then back to WG [09:04:34] julian: related discussion is list production... [09:05:14] ... expanding it is nasty ... [09:05:18] ... 2822? ... [09:05:30] chris: 2822 replaces concept of LWSP with comment-full whitespace [09:05:37] s/comment-full/comment-folding/ [09:05:56] chris: it is different from whitespace in that you can't have whitespace-only lines [09:06:02] ... comment-folding whitespace very low in the grammar ... [09:06:57] s/comment-folding/comma-folding/ [09:07:24] julian: any precedent for re-adding the list production? [09:08:16] chris: would encourage to not re-add list production [09:08:34] ... history why it was dropped is specs saying "list production, but with space" [09:08:51] julian: would it be ok to have list production as short-hand, and appendix with expanded rules [09:09:03] chris: would I do a blocking discuss over that? probably not. Interesting idea. [09:09:17] julian: alternative would be that prose says "this is the real BNF, and that is a list of this production" [09:09:29] chris: Lists didn't end up that awkward in 2822 [09:09:35] mnot: There are lots of list based headers [09:10:06] chris: lot of the ugliness gets fixed by getting rid of LWSP where it shouldn't be [09:10:21] paulH: quick comment on obsolete grammar -- it really helped [09:10:57] julian: obsolete grammar is MAY? [09:11:02] paulH: as MAY as it gets [09:11:11] chris: technically, in 2822 it's MUST, but MUST NOT generate [09:11:23] ... but when talk about it: unless you look at old mail archives, don't need to do that [09:11:28] paulH: 2821? [09:11:31] I don't see how an obsolete grammar has any impact at all on list fields [09:11:53] mnot: worried that there are some unique mechanisms used by end user scripts [09:12:04] ... that's the same set of people generating HTML, so... [09:12:09] barry: [09:12:23] i.e., the list fields are NOT obsolete [09:12:32] julian: obsolete LWS in parts of the list production [09:12:51] mnot: line folding still allowed; can't find any widely used implementation that supports that [09:12:59] ... deprecate that? [09:13:24] ... I see Chris nodding [09:13:32] Apache does support it. I am happy to deprecate it *except* when HTTP is used over SMTP. [09:13:43] chris: fan of simplicity; like deprecating stuff that doesn't interoperate well [09:14:12] Barry: [09:14:16] Paul: On-the-record laughter [09:14:21] there are implementations consuming continuation, but I don't know any producing them. [09:14:31] Yngve: Support line folding in Opera, don't generate it [09:14:42] mnot: intermediaries don't necessarily support it [09:14:56] julian: header folding is useful when writing RFCs that are constrained to 72 characters per line [09:15:03] Barry: [09:15:12] mnot: deprecate such that we can use it in the spec, but not on the wire [09:15:19] paul: .. [09:15:29] mnot: not bothering with a humm on this [09:15:30] thx Barry [09:16:08] mnot: Have a plan for list version -- use appendix with expanded versions of productions [09:16:19] ... need to articulate expectations for header authors ... [09:16:28] ... need to make them do the right thing, or provide mechanical translation tool [09:16:42] chris: let's try in the spec you define list construct, you put it there, should be possible to mechanically convert [09:16:56] ... compare the two, get rough consensus, ... [09:17:07] mnot: my m4 is rusty, can anybody write a macro for this? [09:17:19] chris: could write a sed script to do that! [09:17:23] paul: old school [09:17:26] mnot: ruby is required [09:18:07] (funny thing is that the audio stream is slower than the jabber scribe) [09:18:17] mnot: anything else to discuss... email from Yves [09:18:21] Kudos to Thomas, then. [09:18:48] I always noticed a little lag on audio when I was remote. [09:19:00] Barry: [09:19:01] way cool [09:19:03] mnot: it's less data! [09:19:45] mnot: pulling the issues list on screen wouldn't be a good idea ... [09:19:51] ... btw, here's the WG's tools page ... [09:20:05] http://tools.ietf.org/wg/httpbis/ [http://tools.ietf.org/wg/httpbis/] [09:20:10] ... yesterday, Julian and mnot spent some time on some issues ... [09:20:27] ... bulk of the work has to occur for messaging, payload ... [09:20:32] ... suspect some more on caching ... [09:20:47] julian: default character set for media types (text/*)? [09:20:51] aleksey: oh gosh [09:20:54] mnot: wary of this [09:21:58] mnot: [09:22:08] mnot: well, the issue is... [09:22:25] julian: the issue is when you look in different RFCs for default encoding of text/*, you get different answers [09:22:33] ... text registration, text/xml registration, HTTP text [09:22:37] ... wouldn't know which one is normative ... [09:22:59] ... were close to getting rid of ISO-8859-1, but then Roy stepped in ... [09:23:11] ... if we can't make normative change, might be useful to phrase this in a way that makes clear what's going on ... [09:23:15] mnot: issue-20 [09:23:47] ... proposed tetx suggests that we override defaults ... [09:24:00] ... relationship between the two isn't clear -- which takes precedence ... [09:24:04] ... this is confusing people ... [09:24:08] ... we had a proposal that we backed out ... [09:24:26] mnot: roy, did you have a proposal for this that you remember? [09:24:32] It was a deliberate decision to override MIME. Lots of discussion way back then. [09:24:42] barry: [09:24:48] not that I can remember .. will search [09:25:25] julian: If it was deliberate discussion to override MIME, should we now override text/...? [09:25:44] mnot: remember there were historical reasons for iso-8859-1 [09:25:51] right, Mosaic puked on charset parameter [09:26:06] julian: problem is that default is harmful for formats that carry their own charset info [09:26:23] ... at least for text/xml, should document what's implemented in practice ... [09:26:40] mnot: document [09:26:55] ACTION: mnot to research previous discussion, and restate so we can get going again [09:27:42] yngve: how well is gzip deflate transfer-encoding used? do something about that? [09:27:46] mnot: how often? [09:27:50] yngve: at all? [09:28:01] ... can't say I've seen error reports about it ... [09:28:06] mnot: content-encoding? [09:28:09] yngve: transfer-encoding? [09:28:28] yngve: gzip is used for content-encoding, haven't seen it for transfer-encoding except in test scenarios [09:28:46] mnot: can be negotiated, therefore hesitant to deprecate [09:28:51] see discussion on charset in January 20-23, 2008 [09:28:52] yngve: opera is the only larger browser [09:29:02] mnot: interop concern? [09:29:11] yngve: q is whether or not it should be removed in Opera [09:29:20] Transfer-Encoding is vital to HTTP [09:29:24] ... for gzip deflate ... [09:29:32] ... basically, which headers can we cut? [09:29:47] mnot: product decision, can't see reason to cut it unless there were specific interop reasons [09:29:57] yngve: ok [09:30:05] barry: [09:30:52] yngve: a minor one -- noticed that T-E header isn't mentioned in section 4 or 5 with the header list [09:30:59] mnot: 2616 or current drafts? [09:31:03] yngve: latest draft [09:31:12] mnot: seem to remember issue; if there is none, propose one to the list [09:31:35] [ scribe running low on energy, would welcome somebody else to take over] [09:31:49] topic: security considerations [09:32:13] [No one could possibly step into current scribes shoes!] [09:32:22] paul: there's that document that nobody is paying attention to... [09:32:35] ... kind of pro forma, but would like to double-check ... [09:32:42] ... did get some comments on first draft ... [09:32:49] ... this started off as rant from Rob Sayre, well-positioned rant .. [09:32:57] bortzmeyer leaves the room [09:32:58] ... essentially, "everybody is required to use security requirements" ... [09:33:08] ... why not we? we never talk about what we do ... [09:33:14] ... two revisions, based on comments from list ... [09:33:21] ... none of revisions terribly interested ... [09:33:28] ... added note about connection confidentiality with TLS ... [09:34:00] ... open issues -- didn't suggest splitting things into "browser-like" vs "automation-like" [09:34:16] [ noting to barry that flattery is a really cheap way to try to make people do work ] [09:34:45] paul: if you're in a browser and you ant to do persistent authentication, then you do web form and keep cookies; in automation scenarios you do basic and digest [09:35:00] ... you don't really do basic and digest with humans; forms are much prettier ... [09:35:30] HTTP auth still far outnumbers use of forms. [09:36:14] paul: browser vs automation like stuff isn't that important to document itself unless we talk much about forms ... [09:36:22] ... not appropriate to talk much about forms here ... [09:36:43] ... found a developer who put up forms in flash to prevent auto-completion ... [09:37:06] chris; I like form auto-fill as a security feature [09:37:21] ... I do not have to visually inspect domain name. Browser octet-compares domain name ... [09:37:27] ... in taht context, more secure when I have auto-fill ... [09:37:47] paul: this is not an HTTP feature [09:38:06] ... if somebody is really big on this split, would like to hear more as to why it is needed [09:38:11] ... it's not HTTP or security thing per se [09:38:16] ... you can use cookies with basic auth [09:38:25] [ scribe will take break ] [09:38:34] barry, why don't you pick up for a bit? [09:38:44] I'll try....... [09:38:46] thx [09:39:11] marK talking about web services is a waste of time in this context. [09:39:58] bob morgan: would split into browser-like, non-browser-like [09:40:26] not sure why there's text about forms & cookies [09:40:36] Paul: doc is supposed to be about the way people to things with http [09:40:51] if we talk about these, should we also talk about other things, such as DAV? [09:41:23]