Old business: Henryk Frystyk to figure out how to remove .9 references from the 1.1 document. (Henryk has done so, at least first cut). JG talked to John Klensin, who recommended that we draft a statement for the IAB to ratify. JG took a first cut at writing such a document. Any volunteers to take a second cut at it? (JG to circulate to the editorial list; DK may volunteer) JG talked to Rohit about Wrapped; wrapped has been removed from the draft. What to do about Multipart in document (Roy to review to see if anything is an issue.) Section 1.3 problem about connections. (JG to fix wording) Are we now closed on content-MD5 wording? Post final version... (seems closed; famous last words). New issues: Altavista issue. Robot id for indexing. (defer to separate draft). Caching proposals: Jeff's design vs. Roy's design. We need to choose one and run with it. (rough group consensus was that: 1)"weak validator" terminology was confusing; we need to try to figure out better terminology. The real concept is whether the validator is usable for range retrevals or not. 2) gut feel was that weak validators were worth a try, given that text exists describing it, and experience that relaxing coherency requirements in caches has generally been a long term win.) Digest auth v.s. caching. See mail below. Content encoding problem. See mail below. (RF Content issues (may be in last weeks mail from Roy.).). IANAREG issue needs to be assigned. (JG will work with LM to get assigned). Editorial questions Trivia: implementor vs. implementer (implementer) browser vs. user agent (user agent; ref. browser up front, JG to make editorial pass to find occurances. MUST/SHOULD vs. must/should, vs. other typographical convention. (Caps will be the convention. JG to make pass through document to make 1.1 conform) character set vs. charset. (check at end of process). Go over issues list to see which we believe we might/should still close out before freeze for 1.1, and which might/should be deferred. Schedule (my sense is that we're running a week late, folks). (JG asked everyone to get him ASAP their text, in whatever state it is in, to be integrated over this weekend. New ID will be issued ASAP once that is done. We expect one more ID after this, so it will likely be somewhat spotty still.) Status reports: Persistent connections (Jeff has done quick review, looked OK. JG will attempt integration). Caching (see discussion above) Content negotiation What is state of Vary and Alternates? (Jeff to send KH some mail; KH will be sending JG mail with updated words in the next couple days). Digest authentication (Draft done, about to be issued, some questions answered.) Range retrieval (technical agreement, tables match, but text will change to make it understandable). Accept-ranges. Issue: multipart type writeup for IANA registry. State management (near to new ID draft; hope get it out the next couple working days). Date: Tue, 9 Apr 1996 11:00:06 -0500 (CDT) From: John Franks To: Paul Leach , mogul@pa.dec.com, jg@w3.org Subject: Digest Auth and caching In-Reply-To: Paul, I agree with your sentiment. Here's where I have a problem. The "Note" at the end of the material below really needs to be in the caching part of the HTTP/1.1 spec. The digest auth spec is not the place to tell caches what they can or cannot do. If the caching subgroup is agreeable to this or something like this for the 1.1 spec then I agree with you completely. I think it is a good idea to get some input from others on this -- especially those involved with caching. I will CC Jim Gettys on this to make it an item for the Thursday agenda. John Franks Dept of Math. Northwestern University john@math.nwu.edu ------------------------------------------------------------------- On Mon, 8 Apr 1996, Paul Leach wrote: > Here's an updated section. > ====== > > entity-digest = "entity" "=" entity-digest-value > > entity-digest-value = > > <"> H(H(A1) ":" nonce-value ":" Method ":" > > entity-info ":" H(entity-body)) <"> > > > > entity-info = H( > > digest-uri-value ":" > > media-type ":" ; see section 3.7 of [2] > > *DIGIT ":" ; content length -- see 10.12 of [2] > > content-coding ":" ; see section 3.5 of [2] > > last-modified ; last modified date - see section 10.25 of [2] > > expires ; expiration date; see section 10.19 of [2] > > ) > > last-modified = rfc1123-date ; see section 3.2.1 of [2] > > expires = rfc1123-date > > > where, except for the blank after the comma in "rfc1123-date", there > >must be no white space between "words" and "tspecials", and exactly one > blank between "words" (see section 2.2) in the values in "entity-info". > > Note: If a header is not present, its associated value in the > "entity-info" is the null string. Also, caches can't modify > any of the headers involved in "entity-info" if the origin-server > provided an entity-digest (which proves that the entity hasn't been > > modified since it left the origin-server). > To: guillaum@clipper.ens.fr Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com In-Reply-To: Florent Guillaume's message of Wed, 10 Apr 1996 07:21:18 -0700 <199604101421.QAA07421@clipper.ens.fr> Subject: Re: Several Content-Encodings From: Larry Masinter Sender: Larry Masinter [David] > HTTP/1.0 does not support multiple content-encodings. > HTTP/1.1 suggests an implementation of multiple content-encodings which > is broken; the ordering of the encodings is not defined. I'm sure I > mentioned this on http-wg, but I can't remeber the outcome. Roy? [Florent] > Can Section 4.2 make an exception about ordering for the Content-Encoding > headers, or is this too ugly ? If we're going to make exceptions, it would be more usual to say that 'Content-Encoding' can only occur once, and that if there are multiple encodings, they must appear ordered and comma separated in a single header. In any case, if HTTP/1.1 is going to support multiple content-encodings, this must be resolved, else we'll revert to the 1.0 situation and try again in 1.2. I'll make sure this gets on the issues list. From: guillaum@clipper.ens.fr (Florent Guillaume) Date: Wed, 10 Apr 1996 16:21:18 +0200 (MET DST) Message-Id: <199604101421.QAA07421@clipper.ens.fr> To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com Subject: Several Content-Encodings Resent-Message-Id: <"VinNF3.0.RX5.XqyQn"@cuckoo> Resent-From: http-wg@cuckoo.hpl.hp.com X-Mailing-List: archive/latest/208 X-Loop: http-wg@cuckoo.hpl.hp.com Precedence: list Resent-Sender: http-wg-request@cuckoo.hpl.hp.com Content-Length: 1328 The Apache mailing list stumbled on this problem when discussing multiple Content-Encodings in a document. [David] > HTTP/1.0 does not support multiple content-encodings. > HTTP/1.1 suggests an implementation of multiple content-encodings which > is broken; the ordering of the encodings is not defined. I'm sure I > mentioned this on http-wg, but I can't remeber the outcome. Roy? That is, the ordering *is* defined if it appears in a single Content-Encoding header, but the spec leaves some margin if you have several ones that you want to collapse. draft-ietf-http-v11-spec-01.txt says [section 10.10] If multiple encodings have been applied to a resource, the content codings must be listed in the order in which they were applied. But, as Brian pointed out, it also says [section 4.2] The order in which header fields are received is not significant. and It must be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. Which is clearly broken, the semantics *is* changed. Has this been resolved/discussed ? Can Section 4.2 make an exception about ordering for the Content-Encoding headers, or is this too ugly ? -- Florent