- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 22 Jan 98 14:06:08 PST
- To: "Scott Lawrence" <lawrence@agranat.com>
- Cc: ietf-http-ext@w3.org
Where 'Scooby: dooby' was defined by RFC4000 and the 'doo' extention was defined by RFC4100. What I want to express is that you should reject the request unless you understand RFC4100, not that you understand some older version of the Scooby header. So I would add: Man: http://ietf.org/rfcs/rfc4100.txt Or perhaps Man: urn:ietf:rfc:4100 if I've correctly understood the grammar proposed in "A URN Namespace for IETF Documents": ftp://ietf.org/internet-drafts/draft-ietf-urn-ietf-02.txt Somewhat verbose, alas, but a little more compact than a URL, and perhaps more robust. Note that this is still not quite enough, unless we make a rule that this means "unconditional compliance" to the referenced RFC. Which is not such a big deal; if RFC4100 has some SHOULDs as well as MUSTs, then one can write RFC4101, describing a particular profile of requirements from RFC4100, and then use urn:ietf:RFC:4101 instead. As for headers, it might be usefull for me to add: Vary: Scooby so that intervening proxies would understand that the response to this request also depends on the Scooby header - that way the proxy can do the right thing even if it does not implement 4100. Vary is undefined in a request. Maybe we need a more symmetrical mechanism? Or maybe we need a different mechanism. For example, either the response or response could say: Cache-Control: no-cache, except-if-man-ok where "except-if-man-ok" means "ignore no-cache if the caching agent implements the extensions listed in the Man header". This kind of overriding is explicitly allowed in HTTP/1.1, if I recall correctly. -Jeff
Received on Thursday, 22 January 1998 17:06:28 UTC