W3C home > Mailing lists > Public > ietf-http-ext@w3.org > January to March 1998

Re: First reactions to mandatory draft

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 22 Jan 98 14:06:08 PST
Message-Id: <9801222206.AA13922@acetes.pa.dec.com>
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":


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

Received on Thursday, 22 January 1998 17:06:28 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 15:49:07 UTC