< draft-mogul-http-revalidate-00.txt		draft-mogul-http-revalidate-01.txt >
	HTTP Working Group J. C. Mogul, DECWRL		HTTP Working Group J. C. Mogul, DECWRL
	Internet-Draft 6 January 1997		Internet-Draft 27 May 1997
	Expires: 15 July 1997		Expires: 30 November 1997
	Forcing HTTP/1.1 proxies to revalidate responses		Forcing HTTP/1.1 proxies to revalidate responses
	draft-mogul-http-revalidate-00.txt		draft-mogul-http-revalidate-01.txt
	STATUS OF THIS MEMO		STATUS OF THIS MEMO
	This document is an Internet-Draft. Internet-Drafts are		This document is an Internet-Draft. Internet-Drafts are
	working documents of the Internet Engineering Task Force		working documents of the Internet Engineering Task Force
	(IETF), its areas, and its working groups. Note that other		(IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as		groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of		Internet-Drafts are draft documents valid for a maximum of
	skipping to change at page 1, line 53 ¶		skipping to change at page 1, line 53 ¶
	``proxy-revalidate'' Cache-control directive, which forces		``proxy-revalidate'' Cache-control directive, which forces
	a proxy to revalidate a stale response before using it in a		a proxy to revalidate a stale response before using it in a
	reply. There is no mechanism defined that forces a proxy,		reply. There is no mechanism defined that forces a proxy,
	but not an end-client, to revalidate a fresh response. The		but not an end-client, to revalidate a fresh response. The
	lack of such a mechanism is due to an error in drafting		lack of such a mechanism is due to an error in drafting
	RFC2068, and appears to create problems for use of the		RFC2068, and appears to create problems for use of the
	Authorization header, the Digest Access Authentication		Authorization header, the Digest Access Authentication
	extension [2], the State Management Mechanism [3], and		extension [2], the State Management Mechanism [3], and
	several other proposed extensions. This document discusses		several other proposed extensions. This document discusses
	the problem and several possible solutions, and proposes to		the problem and several possible solutions, and proposes to
	add a new ``proxy-maxage'' directive as the best available		add a new ``s-maxage'' directive as the best available
	solution.		solution.
	Internet-Draft HTTP proxy revalidation 6 January 1997 18:22		Internet-Draft HTTP proxy revalidation 27 May 1997 17:59
	TABLE OF CONTENTS		TABLE OF CONTENTS
	1 Introduction 2		1 Introduction 2
	2 Problems with proxy-revalidate 3		2 Problems with proxy-revalidate 3
	3 Possible alternatives 5		3 Possible alternatives 5
	3.1 Alternatives not requiring changes to RFC2068 5		3.1 Alternatives not requiring changes to RFC2068 5
	3.2 Alternatives that require changes to RFC2068 6		3.2 Alternatives that require changes to RFC2068 6
	4 Proposed solution 8		4 Proposed solution 8
	5 Security Considerations 10		5 Security Considerations 10
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	During the design of HTTP/1.1, it was realized that different		During the design of HTTP/1.1, it was realized that different
	revalidation policies might be applied to end-client caches (e.g., in		revalidation policies might be applied to end-client caches (e.g., in
	browsers) and to intermediate proxy caches. For example, a proxy		browsers) and to intermediate proxy caches. For example, a proxy
	cache might be shared between multiple users (raising security		cache might be shared between multiple users (raising security
	considerations), or it might be operated by someone whose interests		considerations), or it might be operated by someone whose interests
	in reducing transmission costs do not coincide with the interest of		in reducing transmission costs do not coincide with the interest of
	the ultimate client or origin server in preserving certain kinds of		the ultimate client or origin server in preserving certain kinds of
	application semantics.		application semantics.
	Internet-Draft HTTP proxy revalidation 6 January 1997 18:22		Internet-Draft HTTP proxy revalidation 27 May 1997 17:59
	It was also realized that in some cases, it might sometimes be		It was also realized that in some cases, it might sometimes be
	appropriate to configure a cache to be ``loose'' in its behavior for		appropriate to configure a cache to be ``loose'' in its behavior for
	stale responses. That is, in such a situation, the cache might		stale responses. That is, in such a situation, the cache might
	return a stale response without revalidating it. This might be done,		return a stale response without revalidating it. This might be done,
	for example, if the network connection between the cache and the		for example, if the network connection between the cache and the
	origin server is not working, or if the cost or delay for		origin server is not working, or if the cost or delay for
	revalidation is prohibitively high.		revalidation is prohibitively high.
	There is an obvious potential contradiction between the occasional		There is an obvious potential contradiction between the occasional
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	The fundamental problem with proxy-revalidate, as defined in RFC2068,		The fundamental problem with proxy-revalidate, as defined in RFC2068,
	is that it does not require a proxy cache to revalidate a fresh		is that it does not require a proxy cache to revalidate a fresh
	response before using it. However, there are several circumstances		response before using it. However, there are several circumstances
	in which it is desirable or necessary to force a proxy cache to		in which it is desirable or necessary to force a proxy cache to
	revalidate a response that, to an end-client cache, would appear to		revalidate a response that, to an end-client cache, would appear to
	be fresh.		be fresh.
	In section 14.8 of RFC2068, defining the ``Authorization'' header,		In section 14.8 of RFC2068, defining the ``Authorization'' header,
	this language appears:		this language appears:
	Internet-Draft HTTP proxy revalidation 6 January 1997 18:22		Internet-Draft HTTP proxy revalidation 27 May 1997 17:59
	1. If the response includes the "proxy-revalidate"		1. If the response includes the "proxy-revalidate"
	Cache-Control directive, the cache MAY use that response in		Cache-Control directive, the cache MAY use that response in
	replying to a subsequent request, but a proxy cache MUST		replying to a subsequent request, but a proxy cache MUST
	first revalidate it with the origin server, using the		first revalidate it with the origin server, using the
	request-headers from the new request to allow the origin		request-headers from the new request to allow the origin
	server to authenticate the new request.		server to authenticate the new request.
	While this could be read as modifying the definition of		While this could be read as modifying the definition of
	proxy-revalidate from section 14.9.4, it was in fact not intended as		proxy-revalidate from section 14.9.4, it was in fact not intended as
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	In section 4.2.3 of RFCXXXX [3] (the specification of the State		In section 4.2.3 of RFCXXXX [3] (the specification of the State
	Management Mechanism for HTTP/1.1), this language appears:		Management Mechanism for HTTP/1.1), this language appears:
	The origin server should send [one of] the following		The origin server should send [one of] the following
	additional HTTP/1.1 response headers, depending on		additional HTTP/1.1 response headers, depending on
	circumstances:		circumstances:
	* To suppress caching of a private document in shared caches:		* To suppress caching of a private document in shared caches:
	Cache-control: private.		Cache-control: private.
	Internet-Draft HTTP proxy revalidation 6 January 1997 18:22		Internet-Draft HTTP proxy revalidation 27 May 1997 17:59
	* To allow caching of a document and require that it be		* To allow caching of a document and require that it be
	validated before returning it to the client: Cache-control:		validated before returning it to the client: Cache-control:
	must-revalidate.		must-revalidate.
	* To allow caching of a document, but to require that proxy		* To allow caching of a document, but to require that proxy
	caches (not user agent caches) validate it before returning		caches (not user agent caches) validate it before returning
	it to the client: Cache-control: proxy-revalidate.		it to the client: Cache-control: proxy-revalidate.
	* To allow caching of a document and request that it be		* To allow caching of a document and request that it be
	skipping to change at page 5, line 31 ¶		skipping to change at page 5, line 31 ¶
	must-revalidate and proxy-revalidate cause revalidation even of fresh		must-revalidate and proxy-revalidate cause revalidation even of fresh
	responses.		responses.
	Finally, the proposed Hit-Metering extension to HTTP/1.1 [4] depends		Finally, the proposed Hit-Metering extension to HTTP/1.1 [4] depends
	on a mechanism whereby an origin server can require proxy caches to		on a mechanism whereby an origin server can require proxy caches to
	revalidate a response before every use, without requiring end-client		revalidate a response before every use, without requiring end-client
	caches to do the same thing (which would be prohibitively		caches to do the same thing (which would be prohibitively
	inefficient).		inefficient).
	In summary, there is a clear need for a Cache-control mechanism that		In summary, there is a clear need for a Cache-control mechanism that
	allows an origin server to specify that a proxy must always		allows an origin server to specify that a proxy cache (more
	revalidate a response, while allowing end-clients to cache it without		accurately, a shared cache) must always revalidate a response, while
	revalidation (perhaps for a limited period).		allowing end-clients (more accurately, private caches) to cache it
			without revalidation (perhaps for a limited period).
	3 Possible alternatives		3 Possible alternatives
	3.1 Alternatives not requiring changes to RFC2068		3.1 Alternatives not requiring changes to RFC2068
	Assuming that we do want a mechanism that allows an origin server to		Assuming that we do want a mechanism that allows an origin server to
	specify that a proxy must always revalidate a response, while		specify that a proxy must always revalidate a response, while
	allowing end-clients to cache it without revalidation, we could		allowing end-clients to cache it without revalidation, we could
	certainly do this by modifying the HTTP/1.1 specification proposed in		certainly do this by modifying the HTTP/1.1 specification proposed in
	RFC2068. Would it be possible to do this without modifying RFC2068,		RFC2068. Would it be possible to do this without modifying RFC2068,
	possibly by using a combination of existing Cache-control directives		possibly by using a combination of existing Cache-control directives
	skipping to change at page 5, line 56 ¶		skipping to change at page 6, line 4 ¶
	One solution would simply to use ``Cache-control: private''. This		One solution would simply to use ``Cache-control: private''. This
	would preserve any necessary semantics (because it would prevent any		would preserve any necessary semantics (because it would prevent any
	and all proxy caching of the response). However, it is much less		and all proxy caching of the response). However, it is much less
	efficient; because ``private'' prevents a shared cache from even		efficient; because ``private'' prevents a shared cache from even
	storing the response, it cannot do a conditional request for		storing the response, it cannot do a conditional request for
	subsequent references. Hence, this approach would lead to much		subsequent references. Hence, this approach would lead to much
	unnecessary transmission of entity bodies when we could be using 304		unnecessary transmission of entity bodies when we could be using 304
	(Not Modified) responses.		(Not Modified) responses.
	Another approach would be to use ``Cache-control: proxy-revalidate,		Another approach would be to use ``Cache-control: proxy-revalidate,
	max-age=0''. This allows proxies to store the response and forces
	Internet-Draft HTTP proxy revalidation 6 January 1997 18:22		Internet-Draft HTTP proxy revalidation 27 May 1997 17:59
			max-age=0''. This allows proxies to store the response and forces
	them to revalidate it on every reference. However, it also implies		them to revalidate it on every reference. However, it also implies
	that strict end-user caches should revalidate on every reference as		that strict end-user caches should revalidate on every reference as
	well, which could cause even more unnecessary traffic than		well, which could cause even more unnecessary traffic than
	``Cache-control: private'' would.		``Cache-control: private'' would.
	In short, there does not appear to be a way to use the existing		In short, there does not appear to be a way to use the existing
	RFC2068 mechanisms to preserve both the necessary semantics and		RFC2068 mechanisms to preserve both the necessary semantics and
	optimal cache performance.		optimal cache performance.
	3.2 Alternatives that require changes to RFC2068		3.2 Alternatives that require changes to RFC2068
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 34 ¶
	with no way to force loose caches to revalidate certain responses.		with no way to force loose caches to revalidate certain responses.
	The other proposals all involve adding one new Cache-control		The other proposals all involve adding one new Cache-control
	directive, while preserving the current meaning of the existing		directive, while preserving the current meaning of the existing
	proxy-revalidate directive:		proxy-revalidate directive:
	- proxy-mustcheck		- proxy-mustcheck
	This would mean that a proxy, but not an end-client, would		This would mean that a proxy, but not an end-client, would
	have to revalidate the response even it is fresh		have to revalidate the response even it is fresh
	- proxy-maxage=NNN		- s-maxage=NNN
	This would mean defining separate maximum ages for proxy		This would mean defining separate maximum ages for shared
	caches and for end-client caches. The existing max-age (or		(normally proxy) caches and for private (normally
	Expires) value would continue to apply to end-client		end-client) caches. The existing max-age (or Expires)
	caches, and would continue to apply to proxy caches if the		value would continue to apply to private caches, and would
	proxy-maxage directive were not present. However, if		continue to apply to shared caches if the s-maxage
	proxy-maxage is present, then it would override the max-age		directive were not present. However, if s-maxage is
	(or Expires) limit for proxies, but would be ignored by		present, then it would override the max-age (or Expires)
	end-clients.		limit for shared caches, but would be ignored by private
			caches.
	- agent-maxage=NNN		- agent-maxage=NNN
	This would also mean defining separate maximum ages for		This would also mean defining separate maximum ages for
	proxy caches and for end-client caches. The existing		proxy caches and for end-client caches. The existing
	max-age (or Expires) value would continue to apply to proxy		max-age (or Expires) value would continue to apply to proxy
	caches, and would continue to apply to end-client caches if		caches, and would continue to apply to end-client caches if
	the agent-maxage directive were not present. However, if		the agent-maxage directive were not present. However, if
	agent-maxage is present, then it would override the max-age		agent-maxage is present, then it would override the max-age
	(or Expires) limit for end-clients, but would be ignored by		(or Expires) limit for end-clients, but would be ignored by
	proxy caches.		proxy caches.
	One option would be to make either ``proxy-maxage'' or		One option would be to make either ``s-maxage'' or ``agent-maxage''
	``agent-maxage'' always strict: that is, they would imply that a		always strict: that is, they would imply that a proxy or end-client,
	proxy or end-client, respectively, would be required to revalidate a		respectively, (or shared and private caches, respectively) would be
	stale response. Alternatively, they could be combined with a
	``must-revalidate'' directive to force strict behavior, but would
	otherwise allow loose behavior.
	Internet-Draft HTTP proxy revalidation 6 January 1997 18:22		Internet-Draft HTTP proxy revalidation 27 May 1997 17:59
			required to revalidate a stale response. Alternatively, they could
			be combined with a ``must-revalidate'' directive to force strict
			behavior, but would otherwise allow loose behavior.
	Each of these proposals would solve the existing problem, would be		Each of these proposals would solve the existing problem, would be
	simple to specify, and would probably not require significant		simple to specify, and would probably not require significant
	implementation complexity or overhead. However, we should probably		implementation complexity or overhead. However, we should probably
	choose just one of these options; what are the relative merits?		choose just one of these options; what are the relative merits?
	The proxy-mustcheck approach is clearly the simplest, but gives up		The proxy-mustcheck approach is clearly the simplest, but gives up
	the possibility of separate control over proxy and end-client		the possibility of separate control over proxy and end-client
	expiration times. Since this orthogonality could potentially be		expiration times. Since this orthogonality could potentially be
	useful, it seems more useful to adopt the proxy-maxage or		useful, it seems more useful to adopt the s-maxage or agent-maxage
	agent-maxage proposals.		proposals.
	If one assumes that this change could be made to the HTTP/1.1		If one assumes that this change could be made to the HTTP/1.1
	specification before the permanent deployment of any HTTP/1.1		specification before the permanent deployment of any HTTP/1.1
	proxies, there at first seems to be no obvious reason to prefer one		proxies, there at first seems to be no obvious reason to prefer one
	to the other. That is, this header		to the other. That is, this header
	Cache-control: max-age=10,proxy-maxage=3		Cache-control: max-age=10,s-maxage=3
	and this one		and this one
	Cache-control: max-age=3,agent-maxage=10		Cache-control: max-age=3,agent-maxage=10
	both express the same semantics in the same number of bytes.		both express the same semantics in the same number of bytes.
	However, if we also adopt the rule that proxy-maxage implies the		However, if we also adopt the rule that s-maxage implies the presence
	presence of proxy-revalidate, then in order to express the semantics		of proxy-revalidate, then in order to express the semantics of
	of
	Cache-control: max-age=10,proxy-maxage=3		Cache-control: max-age=10,s-maxage=3
	the origin server would have to send		the origin server would have to send
	Cache-control: max-age=3,agent-maxage=10,proxy-revalidate		Cache-control: max-age=3,agent-maxage=10,proxy-revalidate
	which is somewhat more expensive.		which is somewhat more expensive.
	Also, if we do adopt the Hit-metering proposal [4], the proxy-maxage		Also, if we do adopt the Hit-metering proposal [4], the s-maxage
	approach seems preferable, because it would allow the necessary		approach seems preferable, because it would allow the necessary
	header rewriting to be accomplished by simple addition of a		header rewriting to be accomplished by simple addition of a
	directive, rather than more elaborate rewriting. For example, if the		directive, rather than more elaborate rewriting. For example, if the
	origin server sends a hit-metered response with		origin server sends a hit-metered response with
	Cache-control: max-age=10		Cache-control: max-age=10
	then it would be rewritten (at the appropriate proxy, if necessary;		then it would be rewritten (at the appropriate proxy, if necessary;
	see [4] for details) as		see [4] for details) as
	Cache-control: max-age=10,proxy-maxage=0		Internet-Draft HTTP proxy revalidation 27 May 1997 17:59
	using the proxy-maxage alternative, but would have to be rewritten as		Cache-control: max-age=10,s-maxage=0
	Internet-Draft HTTP proxy revalidation 6 January 1997 18:22		using the s-maxage alternative, but would have to be rewritten as
	Cache-control: max-age=0,agent-maxage=10		Cache-control: max-age=0,agent-maxage=10
	using the agent-maxage proposal.		using the agent-maxage proposal.
	On the other hand, if we cannot make the necessary change to the		On the other hand, if we cannot make the necessary change to the
	specification before the deployment of HTTP/1.1 proxies, then the		specification before the deployment of HTTP/1.1 proxies, then the
	agent-maxage proposal is somewhat safer in terms of semantics. That		agent-maxage proposal is somewhat safer in terms of semantics. That
	is, if HTTP/1.1 proxies are deployed that do not understand the		is, if HTTP/1.1 proxies are deployed that do not understand the
	proxy-maxage directive, the use of agent-maxage will not cause these		s-maxage directive, the use of agent-maxage will not cause these
	proxies to avoid revalidating fresh responses. This is because they		proxies to avoid revalidating fresh responses. This is because they
	will presumably carry a ``max-age=0'' directive, and so not appear to		will presumably carry a ``max-age=0'' directive, and so not appear to
	be fresh to these proxies.		be fresh to these proxies.
	Unfortunately, if we fail to change the specification before the		Unfortunately, if we fail to change the specification before the
	permanent deployment of HTTP/1.1 end-clients, then we may face a		permanent deployment of HTTP/1.1 end-clients, then we may face a
	performance problem with the use of agent-maxage: clients that do		performance problem with the use of agent-maxage: clients that do
	not understand this new directive might do many more revalidations		not understand this new directive might do many more revalidations
	than necessary, and so cause excessive network and server loading, as		than necessary, and so cause excessive network and server loading, as
	well as unnecessary delays.		well as unnecessary delays.
	Ultimately, therefore, it would be best if we made this specification		Ultimately, therefore, it would be best if we made this specification
	change before any permanent deployment of HTTP/1.1 proxies or		change before any permanent deployment of HTTP/1.1 proxies or
	clients. If we do so, then it seems more efficient to use the		clients. If we do so, then it seems more efficient to use the
	proxy-maxage mechanism.		s-maxage mechanism.
	4 Proposed solution		4 Proposed solution
	The HTTP/1.1 specification in RFC2068 should be changed, in section		The HTTP/1.1 specification in RFC2068 should be changed, in section
	14.9 (Cache-Control), in the following ways:		14.9 (Cache-Control), in the following ways:
	- The grammar for cache-response-directive should include a		- The grammar for cache-response-directive should include a
	new alternative:		new alternative:
	| "proxy-maxage" "=" delta-seconds		| "s-maxage" "=" delta-seconds
	There is no need for a corresponding change to the grammar		There is no need for a corresponding change to the grammar
	for cache-request-directive.		for cache-request-directive.
	- Section 14.9.3 should include, after the second paragraph		- Section 14.9.3 should include, after the second paragraph
	(which starts with ``If a response includes ...''), this		(which starts with ``If a response includes ...''), this
	new paragraph:		new paragraph:
	If a response includes a proxy-maxage directive,		If a response includes a s-maxage directive, then
	then for a proxy cache (but not for an end-client		for a shared cache (but not for a private cache),
	cache), the maximum age specified by this directive		the maximum age specified by this directive
	overrides the maximum age specified by either the		overrides the maximum age specified by either the
	max-age directive or the Expires header. The
	proxy-maxage directive also implies the semantics
	of the proxy-revalidate directive (see section
	14.9.4), i.e., that the proxy MUST NOT use the
	Internet-Draft HTTP proxy revalidation 6 January 1997 18:22		Internet-Draft HTTP proxy revalidation 27 May 1997 17:59
	entry after it becomes stale to respond to a		max-age directive or the Expires header. The
			s-maxage directive also implies the semantics of
			the proxy-revalidate directive (see section
			14.9.4), i.e., that the shared cache MUST NOT use
			the entry after it becomes stale to respond to a
	subsequent request without first revalidating it		subsequent request without first revalidating it
	with the origin server. The proxy-maxage directive		with the origin server. The s-maxage directive is
	is always ignored by an end-client.		always ignored by a private cache.
	- In section 13.4, the list of response headers and		- In section 13.4, the list of response headers and
	directives implicitly allowing cachability should include		directives implicitly allowing cachability should include
	``proxy-maxage'' after ``max-age''.		``s-maxage'' after ``max-age''.
	- In section 14.8 (Authorization), this paragraph:		- In section 14.8 (Authorization), this paragraph:
	1. If the response includes the "proxy-revalidate"		1. If the response includes the "proxy-revalidate"
	Cache-Control directive, the cache MAY use that		Cache-Control directive, the cache MAY use that
	response in replying to a subsequent request, but a		response in replying to a subsequent request, but a
	proxy cache MUST first revalidate it with the		proxy cache MUST first revalidate it with the
	origin server, using the request-headers from the		origin server, using the request-headers from the
	new request to allow the origin server to		new request to allow the origin server to
	authenticate the new request.		authenticate the new request.
	skipping to change at page 9, line 56 ¶		skipping to change at page 10, line 5 ¶
	should become		should become
	2. If the response includes the "must-revalidate"		2. If the response includes the "must-revalidate"
	Cache-Control directive, the cache MAY use that		Cache-Control directive, the cache MAY use that
	response in replying to a subsequent request, but		response in replying to a subsequent request, but
	if the response is stale, all caches MUST first		if the response is stale, all caches MUST first
	revalidate it with the origin server, using the		revalidate it with the origin server, using the
	request-headers from the new request to allow the		request-headers from the new request to allow the
	origin server to authenticate the new request.		origin server to authenticate the new request.
			Internet-Draft HTTP proxy revalidation 27 May 1997 17:59
	Additionally, RFC2069 [2] and RFCXXXX [3] should probably be modified		Additionally, RFC2069 [2] and RFCXXXX [3] should probably be modified
	to suggest the use of ``proxy-maxage=0'' and/or ``max-age=0,		to suggest the use of ``s-maxage=0'' and/or ``max-age=0,
	must-revalidate'' to force proxies to revalidate a response.		must-revalidate'' to force proxies to revalidate a response.
	Internet-Draft HTTP proxy revalidation 6 January 1997 18:22
	5 Security Considerations		5 Security Considerations
	The proposed Digest Access Authentication extension [2] depends upon		The proposed Digest Access Authentication extension [2] depends upon
	a mechanism to force proxies to always revalidate certain responses.		a mechanism to force proxies to always revalidate certain responses.
	Whether or not the proposal in this document is adopted, the Digest		Whether or not the proposal in this document is adopted, the Digest
	Access Authentication extension requires modification to reflect the		Access Authentication extension requires modification to reflect the
	option chosen (unless the HTTP/1.1 specification is revised to make		option chosen (unless the HTTP/1.1 specification is revised to make
	``proxy-revalidate'' apply to fresh as well as to stale responses.)		``proxy-revalidate'' apply to fresh as well as to stale responses.)
	6 Acknowledgements		6 Acknowledgements
	Several people contributed to my understanding of this issue,		Several people contributed to my understanding of this issue,
	including Koen Holtman, Paul Leach, Ingrid Melve, and Anselm		including Roy Fielding, Koen Holtman, Paul Leach, Ingrid Melve, and
	Baird-Smith. However, the proposal in this document is my fault		Anselm Baird-Smith. However, the proposal in this document is my
	alone.		fault alone.
	7 References		7 References
	1. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk		1. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk
	Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol --		Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol --
	HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997.		HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997.
	2. J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen,		2. J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen,
	E. Sink, L. Stewart. An Extension to HTTP: Digest Access		E. Sink, L. Stewart. An Extension to HTTP: Digest Access
	Authentication. RFC 2069, HTTP Working Group, January, 1997.		Authentication. RFC 2069, HTTP Working Group, January, 1997.
	3. D. Kristol, L. Montulli. HTTP State Management Mechanism. RFC		3. D. Kristol, L. Montulli. HTTP State Management Mechanism. RFC
	XXXX, HTTP Working Group, January, 1997.		2109, HTTP Working Group, February, 1997.
	draft-ietf-http-state-mgmt-05.txt; approved by the IESG, not yet
	assigned an RFC number..
	4. J. Mogul and P. Leach. Simple Hit-Metering for HTTP. Internet		4. J. Mogul and P. Leach. Simple Hit-Metering and Usage-Limiting
	Draft draft-mogul-http-hit-metering-01.txt, HTTP Working Group,		for HTTP. Internet Draft draft-ietf-http-hit-metering-02.txt, HTTP
	December, 1996. This is a work in progress..		Working Group, March, 1997. This is a work in progress.
	8 Author's address		8 Author's address
	Jeffrey C. Mogul		Jeffrey C. Mogul
	Western Research Laboratory		Western Research Laboratory
	Digital Equipment Corporation		Digital Equipment Corporation
	250 University Avenue		250 University Avenue
	Palo Alto, California, 94305, USA		Palo Alto, California, 94305, USA
	Email: mogul@wrl.dec.com		Email: mogul@wrl.dec.com
End of changes. 37 change blocks.
	67 lines changed or deleted		67 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/