draft-ietf-webdav-redirectref-protocol-09.txt		draft-ietf-webdav-redirectref-protocol-10.txt
	WEBDAV Working Group J. Whitehead		WEBDAV Working Group J. Whitehead
	Internet-Draft U.C. Santa Cruz		Internet-Draft U.C. Santa Cruz
	Expires: April 5, 2005 G. Clemm		Expires: April 21, 2005 G. Clemm
	IBM		IBM
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	October 5, 2004		October 21, 2004
	Web Distributed Authoring and Versioning (WebDAV) Redirect Reference		Web Distributed Authoring and Versioning (WebDAV) Redirect Reference
	Resources		Resources
	draft-ietf-webdav-redirectref-protocol-latest-09		draft-ietf-webdav-redirectref-protocol-10
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any applicable patent or other IPR claims of
	which he or she is aware have been or will be disclosed, and any of		which he or she is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	skipping to change at page 1, line 40		skipping to change at page 1, line 39
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 5, 2005.		This Internet-Draft will expire on April 21, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	This specification defines redirect reference resources. A redirect		This specification defines redirect reference resources. A redirect
	reference resource is a resource whose default response is an		reference resource is a resource whose default response is an
	HTTP/1.1 3xx (Redirection) status code (see RFC2616, Section 10.3),		HTTP/1.1 3xx (Redirection) status code (see RFC2616, Section 10.3),
	skipping to change at page 3, line 11		skipping to change at page 3, line 11
	from		from
	<http://greenbytes.de/tech/webdav/#draft-ietf-webdav-redirectref-prot		<http://greenbytes.de/tech/webdav/#draft-ietf-webdav-redirectref-prot
	ocol>.		ocol>.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . 6		2. Notational Conventions . . . . . . . . . . . . . . . . . . . 6
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Overview of Redirect Reference Resources . . . . . . . . . . 7		4. Overview of Redirect Reference Resources . . . . . . . . . . 7
	5. MKREDIRECTREF Method . . . . . . . . . . . . . . . . . . . . 8		5. Operations on Redirect Reference Resources . . . . . . . . . 8
	5.1 Example: Creating a Redirect Reference Resource with		6. MKREDIRECTREF Method . . . . . . . . . . . . . . . . . . . . 8
	MKREDIRECTREF . . . . . . . . . . . . . . . . . . . . . . 9		6.1 Example: Creating a Redirect Reference Resource with
	6. Operations on Redirect Reference Resources . . . . . . . . . 10		MKREDIRECTREF . . . . . . . . . . . . . . . . . . . . . . 10
	7. Operations on Collections That Contain Redirect Reference		7. UPDATEREDIRECTREF Method . . . . . . . . . . . . . . . . . . 10
	Resources . . . . . . . . . . . . . . . . . . . . . . . . . 10		7.1 Example: Updating a Redirect Reference Resource with
	7.1 LOCK on a Collection That Contains Redirect References . . 11		UPDATEREDIRECTREF . . . . . . . . . . . . . . . . . . . . 12
	7.2 Example: PROPFIND on a Collection with Redirect		8. Operations on Collections That Contain Redirect Reference
	Reference Resources . . . . . . . . . . . . . . . . . . . 11		Resources . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.3 Example: PROPFIND with Apply-To-Redirect-Ref on a		8.1 LOCK on a Collection That Contains Redirect References . . 12
	Collection with Redirect Reference Resources . . . . . . . 13		8.2 Example: PROPFIND on a Collection with Redirect
	7.4 Example: COPY on a Collection That Contains a Redirect		Reference Resources . . . . . . . . . . . . . . . . . . . 13
	Reference Resource . . . . . . . . . . . . . . . . . . . . 14		8.3 Example: PROPFIND with Apply-To-Redirect-Ref on a
	7.5 Example: LOCK on a Collection That Contains a Redirect		Collection with Redirect Reference Resources . . . . . . . 15
	Reference Resource . . . . . . . . . . . . . . . . . . . . 15		8.4 Example: COPY on a Collection That Contains a Redirect
	8. Operations on Targets of Redirect Reference Resources . . . 17		Reference Resource . . . . . . . . . . . . . . . . . . . . 16
	9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 17		8.5 Example: LOCK on a Collection That Contains a Redirect
	9.1 Example: Resolving a Relative URI in a Multi-Status		Reference Resource . . . . . . . . . . . . . . . . . . . . 17
	Response . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. Operations on Targets of Redirect Reference Resources . . . 19
	10. Redirect References to Collections . . . . . . . . . . . . . 18		10. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 19
	11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 20		10.1 Example: Resolving a Relative URI in a Multi-Status
	11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . 20		Response . . . . . . . . . . . . . . . . . . . . . . . . 19
	11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . 20		11. Redirect References to Collections . . . . . . . . . . . . . 20
	12. Redirect Reference Resource Properties . . . . . . . . . . . 20		12. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	12.1 DAV:redirect-lifetime (protected) . . . . . . . . . . . 20		12.1 Redirect-Ref Response Header . . . . . . . . . . . . . . 22
	12.2 DAV:reftarget (protected) . . . . . . . . . . . . . . . 21		12.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . 22
	13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 21		13. Redirect Reference Resource Properties . . . . . . . . . . . 22
	13.1 redirectref XML Element . . . . . . . . . . . . . . . . 21		13.1 DAV:redirect-lifetime (protected) . . . . . . . . . . . 22
	14. Extensions to the DAV:response XML Element for		13.2 DAV:reftarget (protected) . . . . . . . . . . . . . . . 23
	Multi-Status Responses . . . . . . . . . . . . . . . . . . . 21		14. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 23
	15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 21		14.1 redirectref XML Element . . . . . . . . . . . . . . . . 23
	15.1 Example: Discovery of Support for Redirect Reference		15. Extensions to the DAV:response XML Element for
	Resources . . . . . . . . . . . . . . . . . . . . . . . 22		Multi-Status Responses . . . . . . . . . . . . . . . . . . . 23
	16. Security Considerations . . . . . . . . . . . . . . . . . . 22		16. Capability Discovery . . . . . . . . . . . . . . . . . . . . 23
	16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 22		16.1 Example: Discovery of Support for Redirect Reference
	16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . 23		Resources . . . . . . . . . . . . . . . . . . . . . . . 24
	16.3 Redirect Reference Resources and Denial of Service . . . 23		17. Security Considerations . . . . . . . . . . . . . . . . . . 24
	16.4 Revealing Private Locations . . . . . . . . . . . . . . 23		17.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 24
	17. Internationalization Considerations . . . . . . . . . . . . 23		17.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . 25
	18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24		17.3 Redirect Reference Resources and Denial of Service . . . 25
	19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24		17.4 Revealing Private Locations . . . . . . . . . . . . . . 25
	20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24		18. Internationalization Considerations . . . . . . . . . . . . 25
	21. Normative References . . . . . . . . . . . . . . . . . . . . 24		19. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25		20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
	A. Changes to the WebDAV Document Type Definition . . . . . . . 25		21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
			22. Normative References . . . . . . . . . . . . . . . . . . . . 26
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
			A. Changes to the WebDAV Document Type Definition . . . . . . . 27
	B. Change Log (to be removed by RFC Editor before		B. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . . . . . 26		publication) . . . . . . . . . . . . . . . . . . . . . . . . 28
	B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 26		B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 28
	B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 26		B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 28
	B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 26		B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 28
	B.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 26		B.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 28
	B.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 26		B.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 28
	B.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 26		B.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 28
	B.7 Since draft-ietf-webdav-redirectref-protocol-08 . . . . . 27		B.7 Since draft-ietf-webdav-redirectref-protocol-08 . . . . . 29
			B.8 Since draft-ietf-webdav-redirectref-protocol-09 . . . . . 29
	C. Resolved issues (to be removed by RFC Editor before		C. Resolved issues (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . . . . . 27		publication) . . . . . . . . . . . . . . . . . . . . . . . . 29
	C.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . 27		C.1 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . 29
	C.2 specify_safeness . . . . . . . . . . . . . . . . . . . . . 28		C.2 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . 29
			C.3 3-terminology-redirectref . . . . . . . . . . . . . . . . 30
			C.4 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . 30
			C.5 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . 31
			C.6 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . 31
			C.7 12.1-property-name . . . . . . . . . . . . . . . . . . . . 31
	D. Open issues (to be removed by RFC Editor prior to		D. Open issues (to be removed by RFC Editor prior to
	publication) . . . . . . . . . . . . . . . . . . . . . . . . 28		publication) . . . . . . . . . . . . . . . . . . . . . . . . 32
	D.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		D.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	D.2 old_clients . . . . . . . . . . . . . . . . . . . . . . . 28		D.2 old_clients . . . . . . . . . . . . . . . . . . . . . . . 32
	D.3 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . 29		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	D.4 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . 29		Intellectual Property and Copyright Statements . . . . . . . 35
	D.5 3-terminology-redirectref . . . . . . . . . . . . . . . . 29
	D.6 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . 29
	D.7 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . 30
	D.8 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . 30
	D.9 12.1-property-name . . . . . . . . . . . . . . . . . . . . 30
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	Intellectual Property and Copyright Statements . . . . . . . 33
	1. Introduction		1. Introduction
	This specification extends the Web Distributed Authoring Protocol		This specification extends the Web Distributed Authoring Protocol
	(WebDAV) to enable clients to create new access paths to existing		(WebDAV) to enable clients to create new access paths to existing
	resources. This capability is useful for several reasons:		resources. This capability is useful for several reasons:
	WebDAV makes it possible to organize HTTP resources into hierarchies,		WebDAV makes it possible to organize HTTP resources into hierarchies,
	placing them into groupings, known as collections, which are more		placing them into groupings, known as collections, which are more
	easily browsed and manipulated than a single flat collection.		easily browsed and manipulated than a single flat collection.
	skipping to change at page 5, line 29		skipping to change at page 5, line 29
	collection. Ideally, the description should be accessible from both.		collection. Ideally, the description should be accessible from both.
	Allowing clients to create new URIs that access the existing resource		Allowing clients to create new URIs that access the existing resource
	lets them put that resource into multiple collections.		lets them put that resource into multiple collections.
	Hierarchies also make resource sharing more difficult, since		Hierarchies also make resource sharing more difficult, since
	resources that have utility across many collections are still forced		resources that have utility across many collections are still forced
	into a single collection. For example, the mathematics department at		into a single collection. For example, the mathematics department at
	one university might create a collection of information on fractals		one university might create a collection of information on fractals
	that contains bindings to some local resources, but also provides		that contains bindings to some local resources, but also provides
	access to some resources at other universities. For many reasons, it		access to some resources at other universities. For many reasons, it
	may be undesirable to make physical copies of the shared resources on		may be undesirable to make physical copies of the shared resources:
	the local server: to conserve disk space, to respect copyright		to conserve disk space, to respect copyright constraints, or to make
	constraints, or to make any changes in the shared resources visible		any changes in the shared resources visible automatically. Being
	automatically. Being able to create new access paths to existing		able to create new access paths to existing resources in other
	resources in other collections or even on other servers is useful for		collections or even on other unrelated systems is useful for this
	this sort of case.		sort of case.
	The redirect reference resources defined here provide a mechanism for		The redirect reference resources defined here provide a mechanism for
	creating alternative access paths to existing resources. A redirect		creating alternative access paths to existing resources. A redirect
	reference resource is a resource in one collection whose purpose is		reference resource is a resource in one collection whose purpose is
	to forward requests to another resource (its target), possibly in a		to redirect requests to another resource (its target), possibly in a
	different collection. In this way, it allows clients to submit		different collection. In this way, it allows clients to submit
	requests to the target resource from another collection. It		requests to the target resource from another collection. It
	redirects most requests to the target resource using a HTTP status		redirects most requests to the target resource using a HTTP status
	code from the 3xx range (Redirection), thereby providing a form of		code from the 3xx range (Redirection), thereby providing a form of
	mediated access to the target resource.		mediated access to the target resource.
	A redirect reference is a resource with properties but no body of its		A redirect reference is a resource with properties but no body of its
	own. Properties of a redirect reference resource can contain such		own. Properties of a redirect reference resource can contain such
	information as who created the reference, when, and why. Since		information as who created the reference, when, and why. Since
	redirect reference resources are implemented using HTTP 3xx		redirect reference resources are implemented using HTTP 3xx
	responses, it generally takes two round trips to submit a request to		responses, it generally takes two round trips to submit a request to
	the intended resource. Redirect references work equally well for		the intended resource. Redirect references work equally well for
	local resources and for resources that reside on a different server		local resources and for resources that reside on a different system
	from the reference.		from the reference.
	The remainder of this document is structured as follows: Section 3		The remainder of this document is structured as follows: Section 3
	defines terms that will be used throughout the specification.		defines terms that will be used throughout the specification.
	Section 4 provides an overview of redirect reference resources.		Section 4 provides an overview of redirect reference resources.
	Section 5 discusses how to create a redirect reference resource.		Section 5 defines the semantics of existing methods when applied to
	Section 6 defines the semantics of existing methods when applied to		redirect reference resources. Section 6 discusses how to create a
	redirect reference resources, and Section 7 discusses their semantics		redirect reference resource, and Section 7 discusses updating
	when applied to collections that contain redirect reference		redirect references. Section 8 discusses their semantics when
	resources. Sections 8 through 10 discuss several other issues raised		applied to collections that contain redirect reference resources.
	by the existence of redirect reference resources. Sections 11		Sections 9 through 11 discuss several other issues raised by the
	through 14 define the new headers, properties, and XML elements		existence of redirect reference resources. Sections 12 through 15
	required to support redirect reference resources. Section 15		define the new headers, properties, and XML elements required to
	discusses capability discovery. Sections 16 through 18 present the		support redirect reference resources. Section 16 discusses
	security, internationalization, and IANA concerns raised by this		capability discovery. Sections 17 through 19 present the security,
	specification. The remaining sections provide a variety of		internationalization, and IANA concerns raised by this specification.
	supporting information.		The remaining sections provide a variety of supporting information.
	2. Notational Conventions		2. Notational Conventions
	Since this document describes a set of extensions to the WebDAV		Since this document describes a set of extensions to the WebDAV
	Distributed Authoring Protocol [RFC2518], itself an extension to the		Distributed Authoring Protocol [RFC2518], itself an extension to the
	HTTP/1.1 protocol, the augmented BNF used here to describe protocol		HTTP/1.1 protocol, the augmented BNF used here to describe protocol
	elements is exactly the same as described in Section 2.1 of		elements is exactly the same as described in Section 2.1 of
	[RFC2616]. Since this augmented BNF uses the basic production rules		[RFC2616]. Since this augmented BNF uses the basic production rules
	provided in Section 2.2 of [RFC2616], these rules apply to this		provided in Section 2.2 of [RFC2616], these rules apply to this
	document as well.		document as well.
	skipping to change at page 7, line 7		skipping to change at page 7, line 7
	A resource created to redirect all requests made to it, using an		A resource created to redirect all requests made to it, using an
	HTTP status code from the 3xx range, to a defined target resource.		HTTP status code from the 3xx range, to a defined target resource.
	Non-Reference Resource		Non-Reference Resource
	A resource that is not a reference to another resource.		A resource that is not a reference to another resource.
	Target Resource		Target Resource
	The resource to which requests are forwarded by a reference		The resource to which requests are redirected by a redirect
	resource. A target resource can be anything that can be		reference resource. A target resource can be anything that can be
	identified by an absolute URI (see [RFC2396], "absoluteURI").		identified by an absolute URI (see [RFC2396], "absoluteURI").
	This document uses the terms "precondition", "postcondition" and		This document uses the terms "precondition", "postcondition" and
	"protected property" as defined in [RFC3253]. Servers MUST report		"protected property" as defined in [RFC3253]. Servers MUST report
	pre-/postcondition failures as described in section 1.6 of this		pre-/postcondition failures as described in section 1.6 of this
	document.		document.
	4. Overview of Redirect Reference Resources		4. Overview of Redirect Reference Resources
	For all operations submitted to a redirect reference resource, the		For all operations submitted to a redirect reference resource, the
	default response is a 302 (Found), accompanied by the Redirect-Ref		default response is a 302 (Found), accompanied by the Redirect-Ref
	header (defined in Section 11.1 below) and the Location header set to		header (defined in Section 12.1 below) and the Location header set to
	the URI of the target resource. With this information, the client		the URI of the target resource. With this information, the client
	can resubmit the request to the URI of the target resource.		can resubmit the request to the URI of the target resource.
	A redirect reference resource never automatically forwards requests		A redirect reference resource never automatically forwards requests
	to its target resource. Redirect resources bring the same benefits		to its target resource. Redirect resources bring the same benefits
	as links in HTML documents. They can be created and maintained		as links in HTML documents. They can be created and maintained
	without the involvement or even knowledge of their target resource.		without the involvement or even knowledge of their target resource.
	This reduces the cost of linking between resources."		This reduces the cost of linking between resources.
	If the client is aware that it is operating on a redirect reference		If the client is aware that it is operating on a redirect reference
	resource, it can resolve the reference by retrieving the reference		resource, it can resolve the reference by retrieving the reference
	resource's DAV:reftarget property (defined in Section 12.2 below),		resource's DAV:reftarget property (defined in Section 13.2 below),
	whose value contains the URI of the target resource. It can then		whose value contains the URI of the target resource. It can then
	submit requests to the target resource.		submit requests to the target resource.
	A redirect reference resource is a new type of resource. To		A redirect reference resource is a new type of resource. To
	distinguish redirect reference resources from non-reference		distinguish redirect reference resources from non-reference
	resources, a new value of the DAV:resourcetype property (defined in		resources, a new value of the DAV:resourcetype property (defined in
	[RFC2518]), DAV:redirectref, is defined in Section 13.1 below.		[RFC2518]), DAV:redirectref, is defined in Section 14.1 below.
	Since a redirect reference resource is a resource, methods can be		Since a redirect reference resource is a resource, methods can be
	applied to the reference resource as well as to its target resource.		applied to the reference resource as well as to its target resource.
	The Apply-To-Redirect-Ref request header (defined in Section 11.2		The Apply-To-Redirect-Ref request header (defined in Section 12.2
	below) is provided so that referencing-aware clients can control		below) is provided so that referencing-aware clients can control
	whether an operation is applied to the redirect reference resource or		whether an operation is applied to the redirect reference resource or
	standard HTTP/WebDAV behaviour (redirection with a 3xx status code)		standard HTTP/WebDAV behaviour (redirection with a 3xx status code)
	should occur. The Apply-To-Redirect-Ref header can be used with most		should occur. The Apply-To-Redirect-Ref header can be used with most
	requests to redirect reference resources. This header is		requests to redirect reference resources. This header is
	particularly useful with PROPFIND, to retrieve the reference		particularly useful with PROPFIND, to retrieve the reference
	resource's own properties.		resource's own properties.
	5. MKREDIRECTREF Method		Implementation Note: Operations on the target of a redirect reference
			usually do not affect the redirect reference itself. However,
			clients should not rely on this behaviour (for instance, some servers
			may update redirect references as a result of namespace operations on
			the reference's target).
			5. Operations on Redirect Reference Resources
			Although non-referencing-aware clients cannot create reference
			resources, they should be able to submit requests through the
			reference resources created by reference-aware WebDAV clients. They
			should be able to follow any references to their targets. To make
			this possible, a server that receives any request made via a redirect
			reference resource MUST return a 3xx range (Redirection) status code,
			unless the request includes an Apply-To-Redirect-Ref header
			specifying "T". The client and server MUST follow [RFC2616] Section
			10.3, but with these additional rules:
			o The Location response header MUST contain an absolute URI that
			identifies the target of the reference resource.
			o The response MUST include the Redirect-Ref header. This header
			allows reference-aware WebDAV clients to recognize the resource as
			a reference resource and understand the reason for the
			redirection.
			A reference-aware WebDAV client can, like a non-referencing client,
			resubmit the request to the URI in the Location header in order to
			operate on the target resource. Alternatively, it can resubmit the
			request to the URI of the redirect reference resource with the
			"Apply-To-Redirect-Ref: T" header in order to operate on the
			reference resource itself. In this case, the request MUST be applied
			to the reference resource itself, and a 3xx response MUST NOT be
			returned.
			As redirect references do not have bodies, GET and PUT requests with
			"Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden).
			6. MKREDIRECTREF Method
	The MKREDIRECTREF method requests the creation of a redirect		The MKREDIRECTREF method requests the creation of a redirect
	reference resource.		reference resource.
	If a MKREDIRECTREF request fails, the server state preceding the		If a MKREDIRECTREF request fails, the server state preceding the
	request MUST be restored.		request MUST be restored.
	Responses from a MKREDIRECTREF request MUST NOT be cached, as		Responses from a MKREDIRECTREF request MUST NOT be cached, as
	MKREDIRECTREF has non-idempotent and non-safe semantics (see		MKREDIRECTREF has non-idempotent and non-safe semantics (see
	[RFC2616], section 9.1)..		[RFC2616], section 9.1).
	Marshalling:		Marshalling:
	The request body MUST be a DAV:mkredirectref XML element.		The request body MUST be a DAV:mkredirectref XML element.
	<!ELEMENT mkredirectref (reftarget, redirect-lifetime?)>		<!ELEMENT mkredirectref (reftarget, redirect-lifetime?)>
	<!ELEMENT reftarget (href)>		<!ELEMENT reftarget (href)>
	<!ELEMENT redirect-lifetime (permanent | temporary)>		<!ELEMENT redirect-lifetime (permanent | temporary)>
	<!ELEMENT permanent EMPTY>		<!ELEMENT permanent EMPTY>
	<!ELEMENT temporary EMPTY>		<!ELEMENT temporary EMPTY>
	skipping to change at page 8, line 42		skipping to change at page 9, line 30
	behave as if a value of DAV:temporary was specified.		behave as if a value of DAV:temporary was specified.
	If the request succeeds, the server MUST return 201 (Created)		If the request succeeds, the server MUST return 201 (Created)
	status.		status.
	If a response body for a successful request is included, it MUST		If a response body for a successful request is included, it MUST
	be a DAV:mkredirectref-response XML element. Note that this		be a DAV:mkredirectref-response XML element. Note that this
	document does not define any elements for the MKREDIRECTREF		document does not define any elements for the MKREDIRECTREF
	response body, but the DAV:mkredirectref-response element is		response body, but the DAV:mkredirectref-response element is
	defined to ensure interoperability between future extensions that		defined to ensure interoperability between future extensions that
	do define elements for the MKREDIRECTREF response body.		do define elements for the response body.
	<!ELEMENT mkredirectref-response ANY>		<!ELEMENT mkredirectref-response ANY>
	Preconditions:		Preconditions:
	(DAV:resource-must-be-null): A resource MUST NOT exist at the		(DAV:resource-must-be-null): A resource MUST NOT exist at the
	request-URL.		request-URL.
	(DAV:parent-resource-must-be-non-null): The request-URL minus the		(DAV:parent-resource-must-be-non-null): The request-URL minus the
	last past segment MUST identify a collection.		last past segment MUST identify a collection.
	skipping to change at page 9, line 23		skipping to change at page 10, line 11
	DAV:redirect-lifetime element, the server MUST support the		DAV:redirect-lifetime element, the server MUST support the
	specified lifetime. Support for DAV:temporary is REQUIRED, while		specified lifetime. Support for DAV:temporary is REQUIRED, while
	support for DAV:permanent is OPTIONAL.		support for DAV:permanent is OPTIONAL.
	Postconditions:		Postconditions:
	(DAV:new-redirectref): a new redirect reference resource is		(DAV:new-redirectref): a new redirect reference resource is
	created whose DAV:reftarget property has the value specified in		created whose DAV:reftarget property has the value specified in
	the request body.		the request body.
	5.1 Example: Creating a Redirect Reference Resource with MKREDIRECTREF		6.1 Example: Creating a Redirect Reference Resource with MKREDIRECTREF
	>> Request:		>> Request:
	MKREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1		MKREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:mkredirectref xmlns:D="DAV:">		<D:mkredirectref xmlns:D="DAV:">
	skipping to change at page 10, line 5		skipping to change at page 10, line 40
	This request resulted in the creation of a new redirect reference		This request resulted in the creation of a new redirect reference
	resource at http://www.example.com/~whitehead/dav/spec08.ref, which		resource at http://www.example.com/~whitehead/dav/spec08.ref, which
	points to the resource identified by the DAV:reftarget property. In		points to the resource identified by the DAV:reftarget property. In
	this example, the target resource is identified by the URI		this example, the target resource is identified by the URI
	http://www.example.com/i-d/draft-webdav-protocol-08.txt. The		http://www.example.com/i-d/draft-webdav-protocol-08.txt. The
	redirect reference resource's DAV:resourcetype property is set to		redirect reference resource's DAV:resourcetype property is set to
	DAV:redirectref and it's DAV:redirect-lifetime property has the value		DAV:redirectref and it's DAV:redirect-lifetime property has the value
	DAV:temporary.		DAV:temporary.
	6. Operations on Redirect Reference Resources		7. UPDATEREDIRECTREF Method
	Although non-referencing-aware clients cannot create reference		The UPDATEREDIRECTREF method requests the update of a redirect
	resources, they should be able to submit requests through the		reference resource.
	reference resources created by reference-aware WebDAV clients. They
	should be able to follow any references to their targets. To make
	this possible, a server that receives any request made via a redirect
	reference resource MUST return a 3xx range (Redirection) status code,
	unless the request includes an Apply-To-Redirect-Ref header
	specifying "T". The client and server MUST follow [RFC2616] Section
	10.3, but with these additional rules:
	o The Location response header MUST contain an absolute URI that		If a UPDATEREDIRECTREF request fails, the server state preceding the
	identifies the target of the reference resource.		request MUST be restored.
	o The response MUST include the Redirect-Ref header. This header		Responses from a UPDATEREDIRECTREF request MUST NOT be cached, as
	allows reference-aware WebDAV clients to recognize the resource as		UPDATEREDIRECTREF has non-safe semantics (see [RFC2616], section
	a reference resource and understand the reason for the		9.1).
	redirection.
	A reference-aware WebDAV client can, like a non-referencing client,		Marshalling:
	resubmit the request to the URI in the Location header in order to
	operate on the target resource. Alternatively, it can resubmit the
	request to the URI of the redirect reference resource with the
	"Apply-To-Redirect-Ref: T" header in order to operate on the
	reference resource itself. In this case, the request MUST be applied
	to the reference resource itself, and a 3xx response MUST NOT be
	returned.
	As redirect references do not have bodies, GET and PUT requests with		The request body MUST be a DAV:updateredirectref XML element.
	"Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden).
	7. Operations on Collections That Contain Redirect Reference Resources		<!ELEMENT updateredirectref (reftarget?, redirect-lifetime?)>
			See Section 6 for a definition of DAV:reftarget and
			DAV:redirect-lifetime.
	Consistent with the rules in Section 6, the response for each		If no DAV:reftarget element is specified, the server MUST NOT
			change the target of the redirect reference.
			If no DAV:redirect-lifetime element is specified, the server MUST
			NOT change the lifetime of the redirect reference.
			If a response body for a successful request is included, it MUST
			be a DAV:updateredirectref-response XML element. Note that this
			document does not define any elements for the UPDATEREDIRECTREF
			response body, but the DAV:updateredirectref-response element is
			defined to ensure interoperability between future extensions that
			do define elements for the response body.
			<!ELEMENT updateredirectref-response ANY>
			Preconditions:
			(DAV:locked-update-allowed): if the resource is write-locked, then
			the appropriate token MUST be specified in an If request header.
			(DAV:must-be-redirectref): the resource identified by the
			request-URI must be a redirect reference resource as defined by
			this specification.
			(DAV:redirect-lifetime-supported): see Section 6.
			(DAV:redirect-lifetime-update-supported): servers MAY support
			changing the DAV:redirect-lifetime property; if they don't, this
			condition code can be used to signal failure.
			Postconditions:
			(DAV:redirectref-updated): the DAV:reftarget and
			DAV:redirect-lifetime properties of the redirect reference have
			been updated accordingly.
			7.1 Example: Updating a Redirect Reference Resource with
			UPDATEREDIRECTREF
			>> Request:
			UPDATEREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1
			Host: www.example.com
			Apply-To-Redirect-Ref: T
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:updateredirectref xmlns:D="DAV:">
			<D:reftarget>
			<D:href>/i-d/draft-webdav-protocol-08b.txt</D:href>
			</D:reftarget>
			</D:updateredirectref>
			>> Response:
			HTTP/1.1 200 OK
			This request has updated the redirect reference's DAV:reftarget
			property to "/i-d/draft-webdav-protocol-08b.txt", and has not changed
			the DAV:redirect-lifetime value. Note that the
			"Apply-To-Redirect-Ref" request header must be used, otherwise the
			request would result in a redirect (3xx) response status.
			8. Operations on Collections That Contain Redirect Reference Resources
			Consistent with the rules in Section 5, the response for each
	redirect reference encountered while processing a collection MUST be		redirect reference encountered while processing a collection MUST be
	a 3xx (Redirection) unless a "Apply-To-Redirect-Ref: T" header is		a 3xx (Redirection) unless a "Apply-To-Redirect-Ref: T" header is
	included with the request. The overall response will therefore be a		included with the request. The overall response will therefore be a
	207 (Multi-Status). For each DAV:response element representing a		207 (Multi-Status). For each DAV:response element representing a
	redirect reference, the server MUST include an additional		redirect reference, the server MUST include an additional
	DAV:location element, specifying the value of the "Location" header		DAV:location element, specifying the value of the "Location" header
	that would be returned otherwise. The extension is defined in		that would be returned otherwise. The extension is defined in
	Section 14 below.		Section 15 below.
	The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be		The Apply-To-Redirect-Ref header (defined in Section 12.2) MAY be
	used with any request on a collection. If present, it will be		used with any request on a collection. If present, it will be
	applied to all redirect reference resources encountered while		applied to all redirect reference resources encountered while
	processing the collection.		processing the collection.
	7.1 LOCK on a Collection That Contains Redirect References		8.1 LOCK on a Collection That Contains Redirect References
	An attempt to lock (with Depth: infinity) a collection that contains		An attempt to lock (with Depth: infinity) a collection that contains
	redirect references without specifying "Apply-To-Redirect-Ref: T"		redirect references without specifying "Apply-To-Redirect-Ref: T"
	will always fail. The Multi-Status response will contain a 3xx		will always fail. The Multi-Status response will contain a 3xx
	response for each redirect reference.		response for each redirect reference.
	Reference-aware clients can lock the collection by using		Reference-aware clients can lock the collection by using
	Apply-To-Redirect-Ref, and, if desired, lock the targets of the		Apply-To-Redirect-Ref, and, if desired, lock the targets of the
	redirect references individually.		redirect references individually.
	Non-referencing clients must resort to locking each resource		Non-referencing clients must resort to locking each resource
	individually.		individually.
	7.2 Example: PROPFIND on a Collection with Redirect Reference Resources		8.2 Example: PROPFIND on a Collection with Redirect Reference Resources
	Suppose a PROPFIND request with Depth: infinity is submitted to the		Suppose a PROPFIND request with Depth: infinity is submitted to the
	following collection, with the members shown here:		following collection, with the members shown here:
	/MyCollection/		/MyCollection/
	(non-reference resource) diary.html		(non-reference resource) diary.html
	(redirect reference resource) nunavut		(redirect reference resource) nunavut
	>> Request:		>> Request:
	skipping to change at page 13, line 5		skipping to change at page 15, line 5
	Apply-To-Redirect-Ref header is set to "F". The collection contains		Apply-To-Redirect-Ref header is set to "F". The collection contains
	one URI that identifies a redirect reference resource. The response		one URI that identifies a redirect reference resource. The response
	element for the redirect reference resource has a status of 302		element for the redirect reference resource has a status of 302
	(Found), and includes a DAV:location extension element to allow		(Found), and includes a DAV:location extension element to allow
	clients to retrieve the properties of its target resource. (The		clients to retrieve the properties of its target resource. (The
	response element for the redirect reference resource does not include		response element for the redirect reference resource does not include
	the requested properties. The client can submit another PROPFIND		the requested properties. The client can submit another PROPFIND
	request to the URI in the DAV:location pseudo-property to retrieve		request to the URI in the DAV:location pseudo-property to retrieve
	those properties.)		those properties.)
	7.3 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with		8.3 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with
	Redirect Reference Resources		Redirect Reference Resources
	Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth:		Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth:
	infinity is submitted to the following collection, with the members		infinity is submitted to the following collection, with the members
	shown here:		shown here:
	/MyCollection/		/MyCollection/
	(non-reference resource) diary.html		(non-reference resource) diary.html
	(redirect reference resource) nunavut		(redirect reference resource) nunavut
	skipping to change at page 14, line 44		skipping to change at page 16, line 44
	</D:prop>		</D:prop>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
	Since the "Apply-To-Redirect-Ref: T" header is present, the response		Since the "Apply-To-Redirect-Ref: T" header is present, the response
	shows the properties of the redirect reference resource in the		shows the properties of the redirect reference resource in the
	collection rather than reporting a 302 status.		collection rather than reporting a 302 status.
	7.4 Example: COPY on a Collection That Contains a Redirect Reference		8.4 Example: COPY on a Collection That Contains a Redirect Reference
	Resource		Resource
	Suppose a COPY request is submitted to the following collection, with		Suppose a COPY request is submitted to the following collection, with
	the members shown:		the members shown:
	/MyCollection/		/MyCollection/
	(non-reference resource) diary.html		(non-reference resource) diary.html
	(redirect reference resource) nunavut with target		(redirect reference resource) nunavut with target
	/Someplace/nunavut.map		/Someplace/nunavut.map
	skipping to change at page 15, line 39		skipping to change at page 17, line 39
	</D:multistatus>		</D:multistatus>
	In this case, since /MyCollection/nunavut is a redirect reference		In this case, since /MyCollection/nunavut is a redirect reference
	resource, the COPY operation was only a partial success. The		resource, the COPY operation was only a partial success. The
	redirect reference resource was not copied, but a 302 response was		redirect reference resource was not copied, but a 302 response was
	returned for it. So the resulting collection is as follows:		returned for it. So the resulting collection is as follows:
	/OtherCollection/		/OtherCollection/
	(non-reference resource) diary.html		(non-reference resource) diary.html
	7.5 Example: LOCK on a Collection That Contains a Redirect Reference		8.5 Example: LOCK on a Collection That Contains a Redirect Reference
	Resource		Resource
	Suppose a LOCK request is submitted to the following collection, with		Suppose a LOCK request is submitted to the following collection, with
	the members shown:		the members shown:
	/MyCollection/		/MyCollection/
	(non-reference resource) diary.html		(non-reference resource) diary.html
	(redirect reference resource) nunavut		(redirect reference resource) nunavut
	>> Request:		>> Request:
	skipping to change at page 17, line 5		skipping to change at page 19, line 5
	resource in the collection. Consequently, neither the collection nor		resource in the collection. Consequently, neither the collection nor
	any of the resources identified by its internal member URIs were		any of the resources identified by its internal member URIs were
	locked. A referencing-aware client can submit a separate LOCK		locked. A referencing-aware client can submit a separate LOCK
	request to the URI in the DAV:location element returned for the		request to the URI in the DAV:location element returned for the
	redirect reference resource, and can resubmit the LOCK request with		redirect reference resource, and can resubmit the LOCK request with
	the Apply-To-Redirect-Ref header to the collection. At that point		the Apply-To-Redirect-Ref header to the collection. At that point
	both the reference resource and its target resource will be locked		both the reference resource and its target resource will be locked
	(as well as the collection and all the resources identified by its		(as well as the collection and all the resources identified by its
	other members).		other members).
	8. Operations on Targets of Redirect Reference Resources		9. Operations on Targets of Redirect Reference Resources
	Operations on targets of redirect reference resources have no effect		Operations on targets of redirect reference resources have no effect
	on the reference resource.		on the reference resource.
	9. Relative URIs in DAV:reftarget		10. Relative URIs in DAV:reftarget
	The URI in the href in a DAV:reftarget property MAY be a relative		The URI in the href in a DAV:reftarget property MAY be a relative
	URI. In this case, the base URI to be used for resolving the		URI. In this case, the base URI to be used for resolving the
	relative URI to absolute form is the URI used in the HTTP message to		relative URI to absolute form is the URI used in the HTTP message to
	identify the redirect reference resource to which the DAV:reftarget		identify the redirect reference resource to which the DAV:reftarget
	property belongs.		property belongs.
	When DAV:reftarget appears in the context of a Multi-Status response,		When DAV:reftarget appears in the context of a Multi-Status response,
	it is in a DAV:response element that contains a single DAV:href		it is in a DAV:response element that contains a single DAV:href
	element. The value of this DAV:href element serves as the base URI		element. The value of this DAV:href element serves as the base URI
	for resolving a relative URI in DAV:reftarget. The value of DAV:href		for resolving a relative URI in DAV:reftarget. The value of DAV:href
	may itself be relative, in which case it must be resolved first in		may itself be relative, in which case it must be resolved first in
	order to serve as the base URI for the relative URI in DAV:reftarget.		order to serve as the base URI for the relative URI in DAV:reftarget.
	If the DAV:href element is relative, its base URI is constructed from		If the DAV:href element is relative, its base URI is constructed from
	the scheme component "http", the value of the Host header in the		the scheme component "http", the value of the Host header in the
	request, and the request-URI.		request, and the request-URI.
	9.1 Example: Resolving a Relative URI in a Multi-Status Response		10.1 Example: Resolving a Relative URI in a Multi-Status Response
	>> Request:		>> Request:
	PROPFIND /geog/ HTTP/1.1		PROPFIND /geog/ HTTP/1.1
	Host: example.com		Host: example.com
	Apply-To-Redirect-Ref: T		Apply-To-Redirect-Ref: T
	Depth: 1		Depth: 1
	Content-Type: text/xml		Content-Type: text/xml
	Content-Length: nnn		Content-Length: nnn
	skipping to change at page 18, line 47		skipping to change at page 20, line 47
	</D:multistatus>		</D:multistatus>
	In this example, the relative URI statistics/population/1997.html is		In this example, the relative URI statistics/population/1997.html is
	returned as the value of reftarget for the reference resource		returned as the value of reftarget for the reference resource
	identified by href /geog/stats.html. The href is itself a relative		identified by href /geog/stats.html. The href is itself a relative
	URI, which resolves to http://example.com/geog/stats.html. This is		URI, which resolves to http://example.com/geog/stats.html. This is
	the base URI for resolving the relative URI in reftarget. The		the base URI for resolving the relative URI in reftarget. The
	absolute URI of reftarget is		absolute URI of reftarget is
	http://example.com/geog/statistics/population/1997.html.		http://example.com/geog/statistics/population/1997.html.
	10. Redirect References to Collections		11. Redirect References to Collections
	In a Request-URI /segment1/segment2/segment3, any of the three		In a Request-URI /segment1/segment2/segment3, any of the three
	segments may identify a redirect reference resource. (See [RFC2396],		segments may identify a redirect reference resource. (See [RFC2396],
	Section 3.3, for definitions of "path" and "segment".) If any		Section 3.3, for definitions of "path" and "segment".) If any
	segment in a Request-URI identifies a redirect reference resource,		segment in a Request-URI identifies a redirect reference resource,
	the response SHOULD be a 3xx. The value of the Location header in		the response SHOULD be a 3xx. The value of the Location header in
	the response is as follows:		the response is as follows:
	The leftmost path segment of the request-URI that identifies a		The leftmost path segment of the request-URI that identifies a
	redirect reference resource, together with all path segments and		redirect reference resource, together with all path segments and
	skipping to change at page 20, line 11		skipping to change at page 22, line 11
	resubmits the request to /b/z.html. The server responds to this		resubmits the request to /b/z.html. The server responds to this
	request with a 3xx with Location: /c/d.html, and the client resubmits		request with a 3xx with Location: /c/d.html, and the client resubmits
	the request to /c/d.html. This final request succeeds.		the request to /c/d.html. This final request succeeds.
	Note: the behavior described above may have a very serious impact		Note: the behavior described above may have a very serious impact
	on the efficiency of mapping Request-URIs to resources in HTTP		on the efficiency of mapping Request-URIs to resources in HTTP
	request processing. Therefore servers MAY respond with a 404		request processing. Therefore servers MAY respond with a 404
	status code if the cost of checking all leading path segments for		status code if the cost of checking all leading path segments for
	redirect references seems prohibitive.		redirect references seems prohibitive.
	11. Headers		12. Headers
	11.1 Redirect-Ref Response Header		12.1 Redirect-Ref Response Header
	Redirect-Ref = "Redirect-Ref:" (absoluteURI | relativeURI)		Redirect-Ref = "Redirect-Ref:" (absoluteURI | relativeURI)
	; see sections 3 and 5 of [RFC2396]		; see sections 3 and 5 of [RFC2396]
	The Redirect-Ref header is used in all 3xx responses from redirect		The Redirect-Ref header is used in all 3xx responses from redirect
	reference resources. The value is the (possibly relative) URI of the		reference resources. The value is the (possibly relative) URI of the
	link target as specified during redirect reference resource creation.		link target as specified during redirect reference resource creation.
	11.2 Apply-To-Redirect-Ref Request Header		12.2 Apply-To-Redirect-Ref Request Header
	Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F")		Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F")
	The optional Apply-To-Redirect-Ref header can be used on any request		The optional Apply-To-Redirect-Ref header can be used on any request
	to a redirect reference resource. When it is present and set to "T",		to a redirect reference resource. When it is present and set to "T",
	the request MUST be applied to the reference resource itself, and a		the request MUST be applied to the reference resource itself, and a
	3xx response MUST NOT be returned.		3xx response MUST NOT be returned.
	If the Apply-To-Redirect-Ref header is used on a request to any other		If the Apply-To-Redirect-Ref header is used on a request to any other
	sort of resource besides a redirect reference resource, the server		sort of resource besides a redirect reference resource, the server
	MUST ignore it.		MUST ignore it.
	12. Redirect Reference Resource Properties		13. Redirect Reference Resource Properties
	The properties defined below are REQUIRED on redirect reference		The properties defined below are REQUIRED on redirect reference
	resources.		resources.
	12.1 DAV:redirect-lifetime (protected)		13.1 DAV:redirect-lifetime (protected)
	This property provides information about the lifetime of a redirect.		This property provides information about the lifetime of a redirect.
	It can either be DAV:permanent (HTTP status 301) or DAV:temporary		It can either be DAV:permanent (HTTP status 301) or DAV:temporary
	(HTTP status 302). Future protocols MAY define additional values.		(HTTP status 302). Future protocols may define additional values.
	<!ELEMENT redirect-lifetime (permanent | temporary)>		<!ELEMENT redirect-lifetime (permanent | temporary)>
	<!ELEMENT permanent EMPTY>		<!ELEMENT permanent EMPTY>
	<!ELEMENT temporary EMPTY>		<!ELEMENT temporary EMPTY>
	12.2 DAV:reftarget (protected)		13.2 DAV:reftarget (protected)
	This property provides an efficient way for clients to discover the		This property provides an efficient way for clients to discover the
	URI of the target resource. This is a read-only property after its		URI of the target resource. This is a read-only property after its
	initial creation. Its value can only be set in a MKREDIRECTREF		initial creation. Its value can only be set in a MKREDIRECTREF
	request. The value is a DAV:href element containing the URI of the		request. The value is a DAV:href element containing the URI of the
	target resource.		target resource.
	<!ELEMENT reftarget href >		<!ELEMENT reftarget href >
	13. XML Elements		14. XML Elements
	13.1 redirectref XML Element		14.1 redirectref XML Element
	Name: redirectref		Name: redirectref
	Namespace: DAV:		Namespace: DAV:
	Purpose: Used as the value of the DAV:resourcetype property to		Purpose: Used as the value of the DAV:resourcetype property to
	specify that the resource type is a redirect reference resource.		specify that the resource type is a redirect reference resource.
	<!ELEMENT redirectref EMPTY >		<!ELEMENT redirectref EMPTY >
	14. Extensions to the DAV:response XML Element for Multi-Status		15. Extensions to the DAV:response XML Element for Multi-Status
	Responses		Responses
	As described in Section 7, the DAV:location element may be returned		As described in Section 8, the DAV:location element may be returned
	in the DAV:response element of a 207 Multi-Status response, to allow		in the DAV:response element of a 207 Multi-Status response, to allow
	clients to resubmit their requests to the target resource of a		clients to resubmit their requests to the target resource of a
	redirect reference resource.		redirect reference resource.
	Consequently, the definition of the DAV:response XML element changes		Consequently, the definition of the DAV:response XML element changes
	to the following:		to the following:
	<!ELEMENT response (href, ((href*, status)|(propstat+)),		<!ELEMENT response (href, ((href*, status)|(propstat+)),
	responsedescription?, location?) >		responsedescription?, location?) >
	<!ELEMENT location (href) >		<!ELEMENT location (href) >
	15. Capability Discovery		16. Capability Discovery
	Sections 9.1 and 15 of [RFC2518] describe the use of compliance		Sections 9.1 and 15 of [RFC2518] describe the use of compliance
	classes with the DAV header in responses to OPTIONS, to indicate		classes with the DAV header in responses to OPTIONS, to indicate
	which parts of the WebDAV Distributed Authoring protocols the		which parts of the WebDAV Distributed Authoring protocols the
	resource supports. This specification defines an OPTIONAL extension		resource supports. This specification defines an OPTIONAL extension
	to [RFC2518]. It defines a new compliance class, called		to [RFC2518]. It defines a new compliance class, called
	redirectrefs, for use with the DAV header in responses to OPTIONS		redirectrefs, for use with the DAV header in responses to OPTIONS
	requests. If a resource does support redirect references, its		requests. If a resource does support redirect references, its
	response to an OPTIONS request may indicate that it does, by listing		response to an OPTIONS request may indicate that it does, by listing
	the new redirectrefs compliance class in the DAV header and by		the new redirectrefs compliance class in the DAV header and by
	listing the MKREDIRECTREF method as one it supports.		listing the MKREDIRECTREF method as one it supports.
	When responding to an OPTIONS request, any type of resource can		When responding to an OPTIONS request, any type of resource can
	include redirectrefs in the value of the DAV header. Doing so		include redirectrefs in the value of the DAV header. Doing so
	indicates that the server permits a redirect reference resource at		indicates that the server permits a redirect reference resource at
	the request URI.		the request URI.
	15.1 Example: Discovery of Support for Redirect Reference Resources		16.1 Example: Discovery of Support for Redirect Reference Resources
	>> Request:		>> Request:
	OPTIONS /somecollection/someresource HTTP/1.1		OPTIONS /somecollection/someresource HTTP/1.1
	Host: example.org		Host: example.org
	>> Response:		>> Response:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE		Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
	Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREDIRECTREF		Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREDIRECTREF
	DAV: 1, 2, redirectrefs		DAV: 1, 2, redirectrefs
	The DAV header in the response indicates that the resource		The DAV header in the response indicates that the resource
	/somecollection/someresource is level 1 and level 2 compliant, as		/somecollection/someresource is level 1 and level 2 compliant, as
	defined in [RFC2518]. In addition, /somecollection/someresource		defined in [RFC2518]. In addition, /somecollection/someresource
	supports redirect reference resources. The Allow header indicates		supports redirect reference resources. The Allow header indicates
	that MKREDIRECTREF requests can be submitted to		that MKREDIRECTREF requests can be submitted to
	/somecollection/someresource.		/somecollection/someresource.
	16. Security Considerations		17. Security Considerations
	This section is provided to make applications that implement this		This section is provided to make applications that implement this
	protocol aware of the security implications of this protocol.		protocol aware of the security implications of this protocol.
	All of the security considerations of HTTP/1.1 and the WebDAV		All of the security considerations of HTTP/1.1 and the WebDAV
	Distributed Authoring Protocol specification also apply to this		Distributed Authoring Protocol specification also apply to this
	protocol specification. In addition, redirect reference resources		protocol specification. In addition, redirect reference resources
	introduce several new security concerns and increase the risk of some		introduce several new security concerns and increase the risk of some
	existing threats. These issues are detailed below.		existing threats. These issues are detailed below.
	16.1 Privacy Concerns		17.1 Privacy Concerns
	By creating redirect reference resources on a trusted server, it is		By creating redirect reference resources on a trusted server, it is
	possible for a hostile agent to induce users to send private		possible for a hostile agent to induce users to send private
	information to a target on a different server. This risk is		information to a target on an unrelated system. This risk is
	mitigated somewhat, since clients are required to notify the user of		mitigated somewhat, since clients are required to notify the user of
	the redirection for any request other than GET or HEAD. (See		the redirection for any request other than GET or HEAD. (See
	[RFC2616], Section 10.3.3 302 Found.)		[RFC2616], Section 10.3.3 302 Found.)
	16.2 Redirect Loops		17.2 Redirect Loops
	Although redirect loops were already possible in HTTP 1.1, the		Although redirect loops were already possible in HTTP 1.1, the
	introduction of the MKREDIRECTREF method creates a new avenue for		introduction of the MKREDIRECTREF method creates a new avenue for
	clients to create loops accidentally or maliciously. If the		clients to create loops accidentally or maliciously. If the
	reference resource and its target are on the same server, the server		reference resource and its target are on the same server, the server
	may be able to detect MKREDIRECTREF requests that would create loops.		may be able to detect MKREDIRECTREF requests that would create loops.
	See also [RFC2616], Section 10.3 "Redirection 3xx."		See also [RFC2616], Section 10.3 "Redirection 3xx."
	16.3 Redirect Reference Resources and Denial of Service		17.3 Redirect Reference Resources and Denial of Service
	Denial of service attacks were already possible by posting URLs that		Denial of service attacks were already possible by posting URLs that
	were intended for limited use at heavily used Web sites. The		were intended for limited use at heavily used Web sites. The
	introduction of MKREDIRECTREF creates a new avenue for similar denial		introduction of MKREDIRECTREF creates a new avenue for similar denial
	of service attacks. Clients can now create redirect reference		of service attacks. Clients can now create redirect reference
	resources at heavily used sites to target locations that were not		resources at heavily used sites to target locations that were not
	designed for heavy usage.		designed for heavy usage.
	16.4 Revealing Private Locations		17.4 Revealing Private Locations
	There are several ways that redirect reference resources may reveal		There are several ways that redirect reference resources may reveal
	information about collection structures. First, the DAV:reftarget		information about collection structures. First, the DAV:reftarget
	property of every redirect reference resource contains the URI of the		property of every redirect reference resource contains the URI of the
	target resource. Anyone who has access to the reference resource can		target resource. Anyone who has access to the reference resource can
	discover the collection path that leads to the target resource. The		discover the collection path that leads to the target resource. The
	owner of the target resource may have wanted to limit knowledge of		owner of the target resource may have wanted to limit knowledge of
	this collection structure.		this collection structure.
	Sufficiently powerful access control mechanisms can control this risk		Sufficiently powerful access control mechanisms can control this risk
	to some extent. Property-level access control could prevent users		to some extent. Property-level access control could prevent users
	from examining the DAV:reftarget property. (The Location header		from examining the DAV:reftarget property. (The Location header
	returned in responses to requests on redirect reference resources		returned in responses to requests on redirect reference resources
	reveals the same information, however.)		reveals the same information, however.)
	This risk is no greater than the similar risk posed by HTML links.		This risk is no greater than the similar risk posed by HTML links.
	17. Internationalization Considerations		18. Internationalization Considerations
	All internationalization considerations mentioned in [RFC2518] also		All internationalization considerations mentioned in [RFC2518] also
	apply to this document.		apply to this document.
	18. IANA Considerations		19. IANA Considerations
	All IANA considerations mentioned in [RFC2518] also apply to this		All IANA considerations mentioned in [RFC2518] also apply to this
	document.		document.
	19. Contributors		20. Contributors
	Many thanks to Jason Crawford, Jim Davis, Chuck Fay and Judith Slein		Many thanks to Jason Crawford, Jim Davis, Chuck Fay and Judith Slein
	who can take credit for big parts of the original design of this		who can take credit for big parts of the original design of this
	specification.		specification.
	20. Acknowledgements		21. Acknowledgements
	This document has benefited from thoughtful discussion by Jim Amsden,		This document has benefited from thoughtful discussion by Jim Amsden,
	Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen,		Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen,
	Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand,		Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand,
	Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Fred		Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Fred
	Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj		Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj
	Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry		Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry
	Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen		Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen
	Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John		Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John
	Stracke, John Tigue, John Turner, Kevin Wiggen, and others.		Stracke, John Tigue, John Turner, Kevin Wiggen, and others.
	21 Normative References		22 Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform		[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
	Resource Identifiers (URI): Generic Syntax", RFC 2396,		Resource Identifiers (URI): Generic Syntax", RFC 2396,
	August 1998.		August 1998.
	[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.		[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
	Jensen, "HTTP Extensions for Distributed Authoring --		Jensen, "HTTP Extensions for Distributed Authoring --
	skipping to change at page 25, line 36		skipping to change at page 27, line 36
	Muenster, NW 48159		Muenster, NW 48159
	Germany		Germany
	Phone: +49 251 2807760		Phone: +49 251 2807760
	Fax: +49 251 2807761		Fax: +49 251 2807761
	EMail: julian.reschke@greenbytes.de		EMail: julian.reschke@greenbytes.de
	URI: http://greenbytes.de/tech/webdav/		URI: http://greenbytes.de/tech/webdav/
	Appendix A. Changes to the WebDAV Document Type Definition		Appendix A. Changes to the WebDAV Document Type Definition
	<!-- Property Elements from Section 12 -->		<!-- Property Elements from Section 13 -->
	<!ELEMENT reftarget href>		<!ELEMENT reftarget href>
	<!ELEMENT location href>		<!ELEMENT location href>
	<!-- XML Elements from Section 13 -->		<!-- XML Elements from Section 14 -->
	<!ELEMENT redirectref EMPTY >		<!ELEMENT redirectref EMPTY >
	<!-- Changes to the DAV:response Element from Section 14 -->		<!-- Changes to the DAV:response Element from Section 15 -->
	<!ELEMENT response (href, ((href*, status)|(propstat+)),		<!ELEMENT response (href, ((href*, status)|(propstat+)),
	responsedescription?, location?) >		responsedescription?, location?) >
	<!ELEMENT location (href) >		<!ELEMENT location (href) >
	Appendix B. Change Log (to be removed by RFC Editor before publication)		Appendix B. Change Log (to be removed by RFC Editor before publication)
	B.1 Since draft-ietf-webdav-redirectref-protocol-02		B.1 Since draft-ietf-webdav-redirectref-protocol-02
	Julian Reschke takes editorial role (added to authors list). Cleanup		Julian Reschke takes editorial role (added to authors list). Cleanup
	skipping to change at page 27, line 19		skipping to change at page 29, line 19
	"lc-57-noautoupdate". Close issue "lc-37-integrity" (duplicate of		"lc-57-noautoupdate". Close issue "lc-37-integrity" (duplicate of
	"lc-57-autoupdate"). Started work on "lc-85-301". Add L. Dusseault		"lc-57-autoupdate"). Started work on "lc-85-301". Add L. Dusseault
	and S. Eissing to Acknowledgments section.		and S. Eissing to Acknowledgments section.
	B.7 Since draft-ietf-webdav-redirectref-protocol-08		B.7 Since draft-ietf-webdav-redirectref-protocol-08
	Fix index entries for conditions. Open and resolve issue		Fix index entries for conditions. Open and resolve issue
	"specify_safeness". Rewrite editorial section and parts of intro.		"specify_safeness". Rewrite editorial section and parts of intro.
	Add more clarifications for issue "lc-85-301" and close it.		Add more clarifications for issue "lc-85-301" and close it.
			B.8 Since draft-ietf-webdav-redirectref-protocol-09
			Resolve issues "lc-33-forwarding", "lc-36-server" and
			"lc-57-noautoupdate". Close issues "lc-48-s6", "12.1-property-name",
			"3-terminology-redirectref" and "lc-58-update". Rearrange section 5
			and 6. Add some more terms to index (no change tracking).
	Appendix C. Resolved issues (to be removed by RFC Editor before		Appendix C. Resolved issues (to be removed by RFC Editor before
	publication)		publication)
	Issues that were either rejected or resolved in this version of this		Issues that were either rejected or resolved in this version of this
	document.		document.
	C.1 lc-85-301		C.1 lc-36-server
	Type: change
	ejw@cse.ucsc.edu (2000-01-03): Support creation of other than 302
	redirects, especially 301.
	julian.reschke@greenbytes.de (2003-10-13): HTTP seems to distinguish
	the following use cases: (a) permanent redirect (301), (b) temporary
	redirect (302 or 307), (c) redirect to a GET location after POST
	(303) and (d) agent-driven negotiation (300). Among these, (a) and
	(b) seem to be well understood, so we should support both. (c)
	doesn't seem to be applicable. (d) may become interesting when user
	agents start supporting it, so the spec should be flexible enough to
	support a feature extension for that. For now I propose that the
	client is able to specify the redirection type as a resource type,
	such as "DAV:permanent-redirect-reference" and
	"DAV:temporary-redirect-reference". This spec would only define the
	behaviour for these two resource types and would allow future
	extensions using new resource types and suggested response codes.
	Resolution (2004-10-05): Support creation of both permanent (301,
	optional) and temporary (302, required) redirects. Keep protocol
	extensible for other types. Make lifetime visible as protected
	property.
	C.2 specify_safeness
	Type: edit
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0196.ht
	ml>
	julian.reschke@greenbytes.de (2004-09-19): Specify safeness and
	idempotence of new methods.
	Resolution (2004-09-20): Done.
	Appendix D. Open issues (to be removed by RFC Editor prior to
	publication)
	D.1 edit
	Type: edit
	julian.reschke@greenbytes.de (2004-10-03): Umbrella issue for
	editorial changes.
	D.2 old_clients
	Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0180.ht
	ml>
	julian.reschke@greenbytes.de (2003-11-10): There are (at least) two
	major design goals, but unfortunately both are in direct
	contradiction: #1: Maximum consistency with HTTP/1.1 (RFC2616). This
	means that any request that addresses a redirect reference resource
	MUST result in a 3xx status code (obviously the whole point is that
	GET MUST result in a redirection, and if it does, it's hard to say
	why other methods such as PUT or DELETE should behave differently).
	Therefore, the redirect reference protocol introduces a new request
	header ("Apply-To-Redirect-Ref") through which a client can indicate
	that the request indeed should be applied to the redirect reference
	resource itself. #2: Maximum usability with existing clients. For
	instance, the Microsoft Webfolder client will not be able to DELETE a
	redirect reference resource unless the server deviates from #1.
	Right now I'm not sure about the best way to resolve this. Currently
	the spec chooses #1 (back when this decision was made, there was
	probably the assumption that existing clients would quickly be
	updated -- something that probably isn't true today). However this
	may result in implementers either just ignoring these rules, or
	adding special workarounds based on "User Agent" detection.
	D.3 lc-36-server
	Type: change		Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0285.ht		<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0285.ht
	ml>		ml>
	yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server"		yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server"
	with "unrelated system" throughout.		with "unrelated system" throughout.
	Resolution: Try replacing "server" with "host" in some contexts,		Resolution (2004-10-06): Originally proposed resolution: Try
	rephrasing in passive voice in others. See also issue 40.		replacing "server" with "host" in some contexts, rephrasing in
			passive voice in others. See also issue 40. Actual resolution:
			replace or remove on a case-by-case basis; use "system" or "unrelated
			system" (host in RFC2616 terminology is something different).
	D.4 lc-33-forwarding		C.2 lc-33-forwarding
	Type: change		Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0284.ht		<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0284.ht
	ml>		ml>
	yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace		yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace
	"forward" with "redirect" throughout.		"forward" with "redirect" throughout.
	Resolution: Use "redirect" for the behavior redirect resources do		Resolution (2004-10-07): Original Resolution: Use "redirect" for the
	exhibit. Use "forward" for the contrasting behavior (passing a		behavior redirect resources do exhibit. Use "forward" for the
	method on to the target with no client action needed). Define these		contrasting behavior (passing a method on to the target with no
	two terms. See also issue 40.		client action needed). Define these two terms. See also issue 40.
			Actual Resolution: change the text so that it always says "redirect"
			when we mean "redirect" and "forward" when we mean "forward"; do not
			add new definitions, though.
	D.5 3-terminology-redirectref		C.3 3-terminology-redirectref
	Type: change		Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0290.ht		<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0290.ht
	ml>		ml>
	julian.reschke@greenbytes.de (2003-07-27): Consider global rename of		julian.reschke@greenbytes.de (2003-07-27): Consider global rename of
	"redirect reference resource" to "redirect resource".		"redirect reference resource" to "redirect resource".
	D.6 lc-58-update		Resolution (2004-10-08): Retracted (see
			http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0009.htm
			l).
			C.4 lc-57-noautoupdate
	Type: change		Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0308.ht		<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0307.ht
	ml>		ml>
	yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way		yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid
	to update the target of a redirect reference.		servers from automatically updating redirect resources when their
			targets move.
	Resolution: Agreed. See also issues 6, 43.		julian.reschke@greenbytes.de (2004-01-05): I don't think we can
			forbid that. This spec consists of (a) clarifications of how a
			server that supports redirects should behave for specific WebDAV
			methods, and (b) extensions to explicitly create them (or to apply a
			method to the redirect itself). As such, we shouldn't add any
			requirements that HTTP doesn't add. What we could do is (1) note why
			auto-update may be a bad idea, and possibly (2) define that redirects
			created by MKREDIRECTREF should not behave that way (or alternatively
			define more specific resource types).
	D.7 lc-48-s6		Resolution (2004-10-07): State that operations on the target of a
			redirect reference usually will not affect the redirect itself; but
			also that clients should not rely on that in general (see also
			http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0004.htm
			l).
			C.5 lc-48-s6
	Type: change		Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0298.ht		<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0298.ht
	ml>		ml>
	yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6		yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6
	with just this: A redirect resource, upon receiving a request without		with just this: A redirect resource, upon receiving a request without
	an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found)		an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found)
	response. The 302 (Found) response MUST include a location header		response. The 302 (Found) response MUST include a location header
	identifying the target and a Redirect-Ref header. If a redirect		identifying the target and a Redirect-Ref header. If a redirect
	resource receives a request with an Apply-To-Redirect-Ref header then		resource receives a request with an Apply-To-Redirect-Ref header then
	the redirect reference resource MUST apply the method to itself		the redirect reference resource MUST apply the method to itself
	rather than blindly returning a 302 (Found) response.		rather than blindly returning a 302 (Found) response.
	Resolution: Keep a summary along the lines of Yaron's proposal (don't		Resolution (2004-10-06): Original resolution: Keep a summary along
	use the word "blindly"). Keep the bullets detailing the headers to		the lines of Yaron's proposal (don't use the word "blindly"). Keep
	be returned. Delete the rest, including the examples. See also		the bullets detailing the headers to be returned. Delete the rest,
	issue 28, 29, 30, 31, 32.		including the examples. See also issue 28, 29, 30, 31, 32. Actual
			resolution: the current wording seems to be in line with what Yaron
			proposed back in 2000.
	D.8 lc-57-noautoupdate		C.6 lc-58-update
	Type: change		Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0307.ht		<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0308.ht
	ml>		ml>
	yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid		yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way
	servers from automatically updating redirect resources when their		to update the target of a redirect reference.
	targets move.
	julian.reschke@greenbytes.de (2004-01-05): I don't think we can		Resolution (2004-10-19): Agreed. See also issues 6, 43. See new
	forbid that. This spec consists of (a) clarifications of how a		method UPDATEREDIRECTREF.
	server that supports redirects should behave for specific WebDAV
	methods, and (b) extensions to explicitly create them (or to apply a
	method to the redirect itself). As such, we shouldn't add any
	requirements that HTTP doesn't add. What we could do is (1) note why
	auto-update may be a bad idea, and possibly (2) define that redirects
	created by MKREDIRECTREF should not behave that way (or alternatively
	define more specific resource types).
	D.9 12.1-property-name		C.7 12.1-property-name
	Type: change		Type: change
	julian.reschke@greenbytes.de (2003-10-06): Sync names for		julian.reschke@greenbytes.de (2003-10-06): Sync names for
	DAV:reftarget property and "Redirect-Ref" response headers.		DAV:reftarget property and "Redirect-Ref" response headers.
			Resolution (2004-10-08): Retracted (see
			http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0010.htm
			l).
			Appendix D. Open issues (to be removed by RFC Editor prior to
			publication)
			D.1 edit
			Type: edit
			julian.reschke@greenbytes.de (2004-10-03): Umbrella issue for
			editorial changes.
			D.2 old_clients
			Type: change
			<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0180.ht
			ml>
			julian.reschke@greenbytes.de (2003-11-10): There are (at least) two
			major design goals, but unfortunately both are in direct
			contradiction: #1: Maximum consistency with HTTP/1.1 (RFC2616). This
			means that any request that addresses a redirect reference resource
			MUST result in a 3xx status code (obviously the whole point is that
			GET MUST result in a redirection, and if it does, it's hard to say
			why other methods such as PUT or DELETE should behave differently).
			Therefore, the redirect reference protocol introduces a new request
			header ("Apply-To-Redirect-Ref") through which a client can indicate
			that the request indeed should be applied to the redirect reference
			resource itself. #2: Maximum usability with existing clients. For
			instance, the Microsoft Webfolder client will not be able to DELETE a
			redirect reference resource unless the server deviates from #1.
			Right now I'm not sure about the best way to resolve this. Currently
			the spec chooses #1 (back when this decision was made, there was
			probably the assumption that existing clients would quickly be
			updated -- something that probably isn't true today). However this
			may result in implementers either just ignoring these rules, or
			adding special workarounds based on "User Agent" detection.
	Index		Index
	A		A
	Apply-To-Redirect-Ref header 20		Apply-To-Redirect-Ref header 22
	C		C
	Condition Names		Condition Names
	DAV:locked-update-allowed (pre) 9		DAV:locked-update-allowed (pre) 9, 11
			DAV:must-be-redirectref (pre) 11
	DAV:name-allowed (pre) 9		DAV:name-allowed (pre) 9
	DAV:new-redirectref (post) 9		DAV:new-redirectref (post) 10
	DAV:parent-resource-must-be-non-null (pre) 8		DAV:parent-resource-must-be-non-null (pre) 9
	DAV:redirect-lifetime-supported (pre) 9		DAV:redirect-lifetime-supported (pre) 9, 11
	DAV:resource-must-be-null (pre) 8		DAV:redirect-lifetime-update-supported (pre) 11
			DAV:redirectref-updated (post) 11
			DAV:resource-must-be-null (pre) 9
	D		D
	DAV header		DAV header
	compliance class 'redirectrefs' 21		compliance class 'redirectrefs' 23
	DAV:locked-update-allowed precondition 9		DAV:locked-update-allowed precondition 9, 11
			DAV:must-be-redirectref precondition 11
	DAV:name-allowed precondition 9		DAV:name-allowed precondition 9
	DAV:new-redirectref postcondition 9		DAV:new-redirectref postcondition 10
	DAV:parent-resource-must-be-non-null precondition 8		DAV:parent-resource-must-be-non-null precondition 9
	DAV:redirect-lifetime property 20		DAV:redirect-lifetime property 22
	DAV:redirect-lifetime-supported precondition 9		DAV:redirect-lifetime-supported precondition 9, 11
	DAV:redirectref resource type 21		DAV:redirect-lifetime-update-supported precondition 11
	DAV:reftarget property 21		DAV:redirectref resource type 23
	DAV:resource-must-be-null precondition 8		DAV:redirectref-updated postcondition 11
			DAV:reftarget property 23
			DAV:resource-must-be-null precondition 9
	H		H
	Headers		Headers
	Apply-To-Redirect-Ref 20		Apply-To-Redirect-Ref 22
	Redirect-Ref 20		Redirect-Ref 22
	M		M
	Methods		Methods
	MKREDIRECTREF 8		MKREDIRECTREF 8
			UPDATEREDIRECTREF 10
	MKREDIRECTREF method 8		MKREDIRECTREF method 8
			N
			Non-Reference Resource 6
	P		P
	Properties		Properties
	DAV:redirect-lifetime 20		DAV:redirect-lifetime 22
	DAV:reftarget 21		DAV:reftarget 23
	R		R
	Redirect-Ref header 20		Redirect-Ref header 22
			Rediret Reference Resource 6
	Resource Types		Resource Types
	DAV:redirectref 21		DAV:redirectref 23
			T
			Target Resource 7
			U
			UPDATEREDIRECTREF method 10
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/