- 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