Old business: Terminology (Roy proposed resolution in mail; lets talk about it for 15 minutes today; I will decide and draft message). OPTIONS (is it ok as is?) (Roy to create example, no example has been seen to date) is 406 vs. 416 controversy settled? Did I do it right? (remove 416) Hit count, leave it in, or take it out? (Separate ID). IANAREG (LM's issue, need text.) New business Remove two-phase sends? (see message 1) (how much of this is misunderstanding, or real problems? How do we fix the language, which is way too complex right now? I think it says mostly the right things, but it is too complicated, and therefore error prone) (JG will try to rewrite) merge variant-ids and selecting opaque validators? See message included below. (YES) max-age vs. TTL. (JG to try to figure out if different than TTL). remove caching of mappings from selecting request headers to variants which were made by the origin server from http/1.1? (This is the `Second, ....' text in my Vary header section.) See message 2 included below. Remove accept-ranges? (make historical issues) Remove range-if? (Leave, JM to add undefined case.) Remove or rename if-unmodified-since? (Jeff will check with Ari) Take language/charset crud out of Warning header? (Jeff to get JG whatever changes) Has anyone had time to carefully review section 13 yet? (yes) What to do with 13.12 (cache keys)? Digest authentication docking. (Don't have editorial time to do right now...) Henryk Frystyk to figure out how to remove .9 references from the 1.1 document. (I moved requrirements part of language for .9 to appendix, anything else to do) (DONE) Simplification (some done; terminology and opaque selecting validator removed) Null request (Dave to send JG resolution) Paul to take out opaque selecting validators Paul to Produce plaintext version. Next week revisit spoofing issue.... Go over issues list to see which we believe have been closed and which might/should be deferred. Schedule (what can we realistically get done before Paris?) (fix terminology, reorganize document, remove what we can). Status reports: Persistent connections Caching Content negotiation Digest authentication Range retrieval State management (comments pending) Subject: Agenda items To: jg@w3.org Date: Thu, 25 Apr 1996 10:40:42 +0200 (MET DST) Cc: koen@win.tue.nl, klensin@mail1.reston.mci.net, mogul@pa.dec.com, fielding@avron.ics.uci.edu, masinter@parc.xerox.com, frystyk@w3.org, alex.hopmann@resnova.com, paulle%microsoft.com.ari@netscape.com, john@math.nwu.edu In-Reply-To: <9604250114.AA07876@zorch.w3.org> from "jg@w3.org" at Apr 24, 96 09:14:01 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 13685 jg@w3.org: > >We should discuss these and other such topics tomorrow. >As usual, send me agenda items. > - Jim Agenda items: Koen. ------- message 1: From: koen@win.tue.nl (Koen Holtman) Message-Id: <199604232010.WAA02883@wsooti06.win.tue.nl> Subject: Re: Variant-ID proposal To: fielding@avron.ICS.UCI.EDU (Roy T. Fielding) Date: Tue, 23 Apr 1996 22:10:04 +0200 (MET DST) Cc: koen@win.tue.nl, mogul@pa.dec.com, http-caching@pa.dec.com [Note for the reader: a discussion of a simplification to the current draft spec follows.] Roy T. Fielding: > >> Proxies will have to generate variant-IDs like >> "http://other.org/xx.gif" using a cached Alternates header sometimes, >> this is why I do not want variant-ids to be tokens. If they were >> tokens, we would need horrible string-to-token conversion rules in the >> content negotiation spec. > >Proxies must not generate variant-IDs -- there is no way that would >work in a system where the client is not always required to use the >same set of caches. I think we are are still some misunderstandings between us. I never proposed that proxies under plain 1.1 would be allowed to invent variant-IDs from scratch. The construction of variant-ids by proxies would be only allowed according to rules in the future content negotiation specification, and of course all proxies would be obliged to generate the same variant-ID that the origin server would generate. Here is what I am saying: - We currently have two mechanisms for use with If-Invalid and varying resources in the spec: mechanism 1: 3.15 Validator Sets Validator sets are used for doing conditional retrievals on varying resources; see section 13.8.4. validator-set = 1#validator-set-item validator-set-item = opaque-validator 13.8.4 Use of Selecting Opaque Validators If the origin server prefers not to provide variant-IDs, it MAY at its option use the _selecting opaque validator_ mechanism. A selecting opaque validator is an opaque validator whose value is unique across all variants of a resource. If the origin server cannot generate opaque validators that are guaranteed to be unique across all variants of a varying resource, it MUST NOT send any opaque validators for that resource. mechanism 2: 3.16 Variant Sets Validator sets are used for doing conditional retrievals on varying resources; see section 13.8.3. variant-set = 1#variant-set-item variant-set-item = opaque-validator ";" variant-id - Associated with these are two separate cases for the If-Invalid header and two separate rules for cache replacement. - If I understood you correctly in the past, you have expressed concerns that this is unnecessarily complex, and that we should just require there to be a variant-id if If-Invalid is to be used. - In the past, I have not been happy with a requirement to include variant-IDs if If-Invalid is to be used. I feared we could paint ourselves into a corner, content-negotiation wise, with this requirement, because this means that caches constructing pre-emptive responses on behalf of the origin server must sometimes do this by taking an earlier reactive response and adding a variant-ID. - Now, after having thought some more about this, I feel reasonably safe with the requirement that there always must be a variant-id if If-Invalid is to be used, as long as the variant-id is a quoted-string, not a token. - To summarize, I propose the following: - variant-IDs are quoted-strings - all responses from varying resources, whether they use Vary or Alternates, SHOULD include variant-ids - if a response from a varying resource does not include a variant-id, the resource author may not assume that caching services will be provided for the response. - When using If-Invalid in requests on on varying resources, only the Cval: header values of cached responses with variant-IDs can be included - Cache replacement (throwing old entity instances out of cache memory because fresher ones that replace them are received) happens using variant-ids, there is no talk about Content-Location headers - Plain 1.1 proxies are never allowed to add variant-IDs to cached responses which do not have them, but caches operating under a future content negotiation specification are allowed to construct the same variant-ID the origin server uses when constructing a 200 response out of separately cached components on behalf of the origin server. - If we do it this way, we can delete the sections 3.15 Validator Sets 13.8.4 Use of Selecting Opaque Validators and simplify the sections 10.48 If-Invalid 10.49 If-Valid 13.12 SLUSHY: Cache Keys 13.20 Cache Replacement for Varying Resources One could even convincingly argue that *not* doing this would make the protocol too complex. On the down side, if we do this, implementations of transparent content negotiation (defined by a future spec) will become slightly more complex, and slightly more bytes will be sent over the wire. Now, if you agree to the changes outlined above, and if Jeff agrees too, I would feel safe in drafting the required edits in private e-mail with Jeff and in asking Jim Gettys to perform the edits. > I suppose it makes just as much sense to have >quoted-strings to variant-ids as it does for change-indicators. Yes. ------- message 2: From: koen@win.tue.nl (Koen Holtman) Message-Id: <199604242328.BAA28634@wsooti04.win.tue.nl> Subject: Re: Expires and Vary To: klensin@mail1.reston.mci.net (John C Klensin) Date: Thu, 25 Apr 1996 01:28:45 +0200 (MET DST) Cc: koen@win.tue.nl, mogul@pa.dec.com, jg@w3.org, fielding@avron.ics.uci.edu John C Klensin: > [Note for all readers: I need opinions on whether we should do a particular simplification of the spec outlined below.] >[Koen Holtman] >>The storage of mappings from request headers to variants in caches >>seems very simple, _until_ you try to define how these mappings can >>expire and can be refreshed. > >Yes. If there were no caches, or caches were constrained to strict semantic >transparency (one query, one response, no intelligence in the proxy about >constructing answers), the problems here would revert, if not to "simple" at >least to "merely hard". Without those constraints (which, I agree, would >make the caches a great deal less useful) we have passed "hard" and gotten >to "very complex". > >>Maybe the complexity introduced by the >>caching of mappings is so great that that defining it in HTTP/1.1 is >>just not feasible. > >I fear that may be the case. I now feel sufficiently uneasy about 1) this caching of mappings mechanism being clear enough to get correct implementations 2) the decision to not provide explicit expiration information for the mappings being correct in the long run that I would prefer leaving this stuff out of the May 1.1 draft. What it we make storing of mappings a `not for 1.1 issue'? Jeff? Roy? Jim? This would mean that caches will always need to forward every request using the If-Invalid mechanism. It still improves over current practice, but eliminates lots of complexity. The 1.2 spec could later define a mapping caching mechanism with good lifetime and refreshing rules for the mappings. We would basically end up in the 1.1 spec with a Vary header section like this: [Warning!! Rough draft made while I should be sleeping] [I am awake now, but have no time to see if I can correct the draft below. Please compare it to the current draft text to see which parts were deleted] 10.52 Vary The Vary response-header field is used by an origin server to signal that the resource identified by the current request is a varying resource. A varying resource has multiple entities associated with it, all of which are representations of the content of the resource. If a GET or HEAD request on a varying resource is received, the origin server will select one of the associated entities as the entity best matching the request. Selection of this entity is based on the contents of particular header fields in the request message, or on other information pertaining to the request, like the network address of the sending client. If a resource is varying, this has an important effect on cache management, particularly for caching proxies which service a diverse set of user agents. All 200 (OK) responses from varying resources MUST contain at least one Vary header or Alternates header (Section 10.53) to signal variance. If no Vary headers and no Alternates headers are present in a 200 (OK) response, then caches may assume, as long as the response is fresh, that the resource in question is not varying, and has only one associated entity. Note however that this entity can still change through time, as possibly indicated by a Cache-Control response header (section 10.cc). After selection of the entity best matching the current request, the origin server will usually generate a 200 (OK) response, but it can also generate other responses like 206 (Partial Content) or 304 (Not modified) if headers which modify the semantics of the request, like Range (Section 10.ran) or If-Valid (Section 10.ifva), are present. An origin server need not be capable of selecting an entity for every possible incoming request on a varying resource; it can choose to generate a 3xx (redirection) or 4xx (client error) type response for some requests. | Vary = "Vary" ":" opaque-field | | opaque-field = field-value | A later specification will define the format and meaning of the | field, and will allow for more efficient caching as is possible | under this specification. 1.1 servers should always generate an | empty field with the Vary header. Servers which use access authentication are not obliged to send _Vary: Authorization_ headers in responses. It MUST be assumed that requests on authenticated resources can always produce different responses for different users. Note that servers can signal the absence of authentication by including a _Cache-Control: public_ header in the response. A cache MAY store and refresh 200 (OK) responses from a varying resource according to the rules in Section 13.7.2. The partial entities in 206 (Partial Content) responses from varying resources MAY also be used by the cache. When getting a request on a varying resource, a cache can only | return a cached 200 (OK) response to one of its clients after | contacting an upstream server in the following way. | If a cache gets a request on a varying resource for which it has cached one or more responses with Vary or Alternates headers, it can relay that request towards the origin server, adding an If-Invalid header listing the cval-info values in the CVal headers (Section 10.47) of the cached responses. If it then gets back a 304 (Not Modified) response with the cval-info of a cached 200 (OK) response in its CVal header, it can return this cached 200 (OK) response to its client, after merging in any of the 304 response headers as specified in Section 13.7.2. [...significant complexity deleted here...] | Note: a cache will have to contact the origin server every time | that a varying resource is accessed. A future specification may | allow caches select and serve one response from cache memory | without contacting the origin server. 10.53 Alternates The Alternates response-header field is used by origin servers to signal that the resource identified by the current request has the capability to send different responses depending on the accept headers in the request message. This has an important effect on cache management, particularly for caching proxies which service a diverse set of user agents. This effect is covered in Section 10.v. Alternates = "Alternates" ":" opaque-field opaque-field = field-value The Alternates header is included into HTTP/1.1 to make HTTP/1.1 caches compatible with a planned content negotiation mechanism. HTTP/1.1 allows a future content negotiation standard to define the format of the Alternates header field-value, as long as the defined format satisfies the general rules in Section 4.2. To ensure compatibility with future experimental or standardized software, caching HTTP/1.1 clients MUST treat all Alternates headers in a response as synonymous to the following Vary header: | Vary: and follow the caching rules associated with the presence of this Vary header, as covered in Section 10.v. HTTP/1.1 allows origin servers to send Alternates headers under experimental conditions. > --john Koen. To: Paul Leach Subject: Re: Terminology (was RE: Close to the Internet draft...) In-Reply-To: Your message of "Wed, 24 Apr 1996 15:32:14 PDT." Date: Thu, 25 Apr 1996 06:43:29 -0700 From: "Roy T. Fielding" Message-Id: <9604250643.aa19110@paris.ics.uci.edu> Content-Length: 5539 >>I am not entirely comfortable with "entity ID". To me it suggests a >>value >>that is unique among all entities provided by the server. > > I agree. One needs to read carefully that an entity is an instance of a > variant. > >> While in >>fact it is unique only among instances of variants of the particular >>resource >>associated with one URI. How on earth are you guys coming up with that interpretation? There is nothing about "identifier" that implies server uniqueness. Nor does it imply global uniqueness. An identifier is something that establishes identity within the context of its USE. In this case, the context of its use is the requested resource, which in turn was identified by the Request-URI and Host. "Paul" is a legitimate identifier for an individual within this editorial group. "John" is not, since we would need additional information to distinguish between John Franks and John Klensin. However, "John" is a suitable identifier if what you want to identify is both of them. The fact that these are not identifiers within a larger context is irrelevant. The problem described by all the verbiage in the discussion of ranges and validators is one of establishing identity given the available set of identifiers. Some identifiers are capable of identifying a specific sequence of octets, others are only capable of identifying a "semantically equivalent" set of such sequences. In all cases, however, we are dealing with a problem of identification! To avoid using the term "identifier" in such a situation is utterly absurd. We can use the following terminology: resource A network data object or service that can be identified by a URI. group-resource A service resource which acts as a negotiation port for a set of other resources. A resource MAY be a member of more than one group-resource. A group-resource MAY be a member of another group-resource. A GET or HEAD request on a group-resource MAY be applied to the group as a whole (resulting in a 300 or error response) or to one member of the set. In the latter case, the response MUST indicate which resource variant is responding to the GET or HEAD request. All other methods apply to the group as a whole. Content negotiation -- the mechanism for selecting the appropriate member of a group-resource when applying a request -- is described in Section XX. individual resource A resource that is not a group-resource. variant An individual resource that is a member of at least one group-resource. entity The set of information transferred as the payload of a request or response. An entity consists of metainformation in the form of Entity-Header fields and content in the form of an Entity-Body, as described in Section 7. resource entity A particular representation, rendition, encoding, or presentation of an individual resource that could be enclosed in a 200 response to a GET request on that resource. Likewise, the Entity-Header fields of a resource entity could be enclosed in a 200 response to a HEAD request, and parts of the Entity-Body of a resource entity could be enclosed in a 206 response to a partial GET request. An individual resource MUST be bound to a single resource entity at any instant in time. The EID entity-header field is used to assign an entity-id to a resource entity. EID = "EID" ":" entity-id An entity-id MAY be used to identify a particular resource entity, or a set of semantically equivalent resource entities, of the requested resource. In the latter case, the entity-id MUST be prefixed with the word "set". If an entity-id is assigned to the resource entity of a variant responding to a request on a group-resource, the entity-id must include a variant-id which is capable of identifying the variant within that group-resource. entity-id = ["set"] change-indicator [ ";" variant-id ] change-indicator = quoted-string variant-id = quoted-string The change-indicator is used to differentiate between resource entities which vary over time. The variant-id is necessary to differentiate between variants of a group-resource. Therefore, the entity-id identifies a specific instance of a resource entity, or a set of specific instances if prefixed by "set", within the context of the requested resource. If-EID = "If-EID" ":" ( "*" | 1#entity-id ) Unless-EID = "Unless-EID" ":" ( "*" | 1#entity-id ) The If-EID header field is a precondition which evaluates "true" if the current resource entity for the requested resource has an entity-id equal to one of those listed or, if "*" is given, has any defined entity-id. The Unless-EID header field is a precondition which evaluates "false" if the current resource entity for the requested resource has an entity-id equal to one of those listed or, if "*" is given, has any defined entity-id. Therefore, Unless-EID: * prevents application of a method to a resource entity which already exists and has a defined entity-id. The exact impact of a true or false precondition is dependent on the request method and should be described somewhere along with If-Modified-Since and Unless-Modified-Since. ...Roy T. Fielding Department of Information & Computer Science (fielding@ics.uci.edu) University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056 http://www.ics.uci.edu/~fielding/