draft-ietf-webdav-redirectref-protocol-00.txt		draft-ietf-webdav-redirectref-protocol-01.txt
	WEBDAV Working Group J. Slein, Xerox		WEBDAV Working Group J. Slein, Xerox
	INTERNET DRAFT E.J. Whitehead Jr., UC Irvine		INTERNET DRAFT E.J. Whitehead Jr., UC Irvine
	<draft-ietf-webdav-redirectref-protocol-00.txt> J. Davis, CourseNet		<draft-ietf-webdav-redirectref-protocol-01.txt> J. Davis, CourseNet
	G. Clemm, Rational		G. Clemm, Rational
	C. Fay, FileNet		C. Fay, FileNet
	J. Crawford, IBM		J. Crawford, IBM
	T. Chihaya, DataChannel		T. Chihaya, DataChannel
	August 20, 1999		October 15, 1999
	Expires February 20, 2000		Expires April 15, 2000
	WebDAV Redirect Reference Resources		WebDAV Redirect Reference Resources
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC2026. Internet-Drafts are working		provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas, and		documents of the Internet Engineering Task Force (IETF), its areas, and
	its working groups. Note that other groups may also distribute working		its working groups. Note that other groups may also distribute working
	documents as Internet-Drafts.		documents as Internet-Drafts.
	skipping to change at line 52		skipping to change at line 52
	The WebDAV Distributed Authoring Protocol provides basic support for		The WebDAV Distributed Authoring Protocol provides basic support for
	collections, offering the ability to create and list unordered		collections, offering the ability to create and list unordered
	collections.		collections.
	This specification is one of a group of three specifications that		This specification is one of a group of three specifications that
	supplement the WebDAV Distributed Authoring Protocol to increase the		supplement the WebDAV Distributed Authoring Protocol to increase the
	power of WebDAV collections. This specification defines redirect		power of WebDAV collections. This specification defines redirect
	reference resources, one mechanism for allowing a single resource to		reference resources, one mechanism for allowing a single resource to
	appear in more than one collection. A redirect reference resource is a		appear in more than one collection. A redirect reference resource is a
	resource in one collection that responds to most requests by redirecting		resource in one collection that responds to most requests by redirecting
	the request (using an HTTP 1.1 302 Moved Temporarily response) to a		the request (using an HTTP 1.1 302 Found response) to a different
	different resource, possibly in a different collection. [B] defines		resource, possibly in a different collection. "WebDAV Bindings"[B]
	bindings, another approach to allowing a single resource to be accessed		defines bindings, another approach to allowing a single resource to be
	from multiple collections. [OC] provides ordered collections.		accessed from multiple collections. "WebDAV Ordered Collections
			Protocol"[OC] provides ordered collections.
	Table of Contents		Table of Contents
	1 Notational Conventions.......................................3		1 Notational Conventions.......................................3
	2 Introduction.................................................3
	3 Terminology..................................................4		2 Introduction.................................................3
			3 Terminology..................................................5
	4 Overview of Redirect Reference Resources.....................5		4 Overview of Redirect Reference Resources.....................5
	5 MKREF Method.................................................5		5 Creating a Redirect Reference Resource.......................6
	5.1 Overview of MKREF............................................5		5.1 MKRESOURCE...................................................6
	5.2 Status Codes.................................................6		5.2 Status Codes.................................................8
	5.3 Example: MKREF...............................................6		5.3 Example: Creating a Redirect Reference Resource with
	6 Listing the Redirect Reference Resources in a Collection.....6		MKRESOURCE...................................................8
	6.1 Example: PROPFIND on a Collection with Redirect Reference		6 Operations on Redirect Reference Resources...................8
	Resources....................................................7		6.1 Example: GET on a Redirect Reference Resource................9
	6.2 Example: PROPFIND with Passthrough: F on a Collection with		6.2 Example: PUT on a Redirect Reference Resource with
	Redirect Reference Resources.................................9		"Passthrough: F"............................................10
	7 Copying Redirect Reference Resources........................10		6.3 Example: PROPPATCH on a Redirect Reference Resource.........10
	7.1 Example: COPY on a Redirect Reference Resource..............11		7 Operations on Collections That Contain Redirect Reference
	7.2 Example: COPY on a Collection That Contains a Redirect		Resources...................................................11
	Reference Resource..........................................11		7.1 MOVE and DELETE on Collections That Contain Redirect
	8 Deleting and Moving Redirect Reference Resources............12		References..................................................12
	9 Locking Redirect Reference Resources........................12		7.2 LOCK on a Collection That Contains Redirect References......12
	9.1 Example: LOCK on a Redirect Reference Resource..............14		7.3 Example: PROPFIND on a Collection with Redirect Reference
	9.2 Example: LOCK on a Collection That Contains a Redirect		Resources...................................................12
	Reference Resource, with Passthrough: T.....................15		7.4 Example: PROPFIND with Passthrough: F on a Collection with
	10 Other Operations on Redirect Reference Resources............16		Redirect Reference Resources................................13
	10.1 Example: GET on a Redirect Reference Resource...............17		7.5 Example: COPY on a Collection That Contains a Redirect
	10.2 Example: PUT on a Redirect Reference Resource with		Reference Resource..........................................15
	"Passthrough: F"............................................18		7.6 Example: LOCK on a Collection That Contains a Redirect
	10.3 Example: PROPPATCH on a Redirect Reference Resource.........18		Reference Resource, with Passthrough: T.....................16
	11 Operations on Targets of Redirect Reference Resources.......19		8 Operations on Targets of Redirect Reference Resources.......17
	12 Relative URIs in Ref-Target and DAV:reftarget...............19		9 Relative URIs in DAV:reftarget..............................17
	12.1 Example: Resolving a Relative URI in Ref-Target.............19		9.1 Example: Resolving a Relative URI in a MKRESOURCE Request...18
	12.2 Example: Resolving a Relative URI in DAV:reftarget..........20		9.2 Example: Resolving a Relative URI in a Multi-Status Response.18
	13 Redirect References to Collections..........................21		10 Redirect References to Collections..........................19
	14 Headers.....................................................21		11 Status Codes................................................20
	14.1 Ref-Target Entity Header....................................21		11.1 509 Dangling References Forbidden...........................20
	14.2 Resource-Type Entity Header.................................22		12 Headers.....................................................20
	14.3 Passthrough Request Header..................................22		12.1 Redirect-Ref Response Header................................20
	15 Properties..................................................22		12.2 Passthrough Request Header..................................20
	15.1 reftarget Property..........................................22		13 Properties..................................................21
	15.2 location Pseudo-Property....................................23		13.1 reftarget Property..........................................21
	16 XML Elements................................................23		13.2 location Pseudo-Property....................................21
	16.1 redirectref XML Element.....................................23		14 XML Elements................................................21
	17 Extensions to the DAV:response XML Element for Multi-Status		14.1 redirectref XML Element.....................................21
	Responses...................................................23		15 Extensions to the DAV:response XML Element for Multi-Status
	18 Capability Discovery........................................23		Responses...................................................22
	18.1 Example: Discovery of Support for Redirect Reference		16 Capability Discovery........................................22
	Resources...................................................24		16.1 Example: Discovery of Support for Redirect Reference
	19 Security Considerations.....................................24		Resources...................................................22
	19.1 Privacy Concerns............................................24		17 Security Considerations.....................................23
	19.2 Redirect Loops..............................................25		17.1 Privacy Concerns............................................23
	19.3 Redirect Reference Resources and Denial of Service..........25		17.2 Redirect Loops..............................................23
	19.4 Private Locations May Be Revealed...........................25		17.3 Redirect Reference Resources and Denial of Service..........23
	20 Internationalization Considerations.........................25		17.4 Private Locations May Be Revealed...........................23
	21 IANA Considerations.........................................26		18 Internationalization Considerations.........................24
	22 Copyright...................................................26		19 IANA Considerations.........................................24
	23 Intellectual Property.......................................26		20 Copyright...................................................24
	24 Acknowledgements............................................26		21 Intellectual Property.......................................24
	25 References..................................................26
	26 Authors' Addresses..........................................27		22 Acknowledgements............................................25
	27 Appendices..................................................28		23 References..................................................25
	27.1 Appendix 1: Extensions to the WebDAV Document Type		24 Authors' Addresses..........................................25
	Definition..................................................28		25 Appendices..................................................26
			25.1 Appendix 1: Extensions to the WebDAV Document Type
			Definition..................................................26
	1 Notational Conventions		1 Notational Conventions
	Since this document describes a set of extensions to the HTTP/1.1		Since this document describes a set of extensions to the WebDAV
	protocol, the augmented BNF used here to describe protocol elements is		Distributed Authoring Protocol [WebDAV], itself an extension to the
	exactly the same as described in Section 2.1 of [HTTP]. Since this		HTTP/1.1 protocol, the augmented BNF used here to describe protocol
	augmented BNF uses the basic production rules provided in Section 2.2 of		elements is exactly the same as described in Section 2.1 of [HTTP].
	[HTTP], these rules apply to this document as well.		Since this augmented BNF uses the basic production rules provided in
			Section 2.2 of [HTTP], these rules apply to this document as well.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2 Introduction		2 Introduction
	The simple collections that the WebDAV Distributed Authoring Protocol		The simple collections that the WebDAV Distributed Authoring Protocol
	specification supports are powerful enough to be widely useful. They		specification supports are powerful enough to be widely useful. They
	provide for the hierarchical organization of resources, with mechanisms		provide for the hierarchical organization of resources, with mechanisms
	for creating and deleting collections, copying and moving them, locking		for creating and deleting collections, copying and moving them, locking
	them, adding members to them and removing members from them, and getting		them, adding members to them and removing members from them, and getting
	listings of their members. Delete, copy, move, list, and lock		listings of their members. Delete, copy, move, list, and lock
	operations can be applied recursively, so that a client can operate on		operations can be applied recursively, so that a client can operate on
	whole hierarchies with a single request.		whole hierarchies with a single request.
	This specification is one of a family of three specifications that build		This specification is one of a family of three specifications that build
	on the infrastructure defined in [HTTP] and [WebDAV] to extend the		on the infrastructure defined in [HTTP] and [WebDAV] to extend the
	capabilities of collections. The companion specification [OC] defines		capabilities of collections. The companion specification "WebDAV
	protocol extensions to support ordered collections. The present		Ordered Collections Protocol"[OC] defines protocol extensions to support
	specification and the companion specification [B] define mechanisms for		ordered collections. The present specification and the companion
	allowing the same resource to appear in multiple collections. This		specification "WebDAV Bindings"[B] define mechanisms for allowing the
	capability is useful for several reasons:		same resource to appear in multiple collections. This capability is
			useful for several reasons:
	Organizing resources into hierarchies places them into smaller		Organizing resources into hierarchies places them into smaller
	groupings, known as collections, which are more easily browsed and		groupings, known as collections, which are more easily browsed and
	manipulated than a flat namespace. However, hierarchies require		manipulated than a flat namespace. However, hierarchies require
	categorization decisions that locate resources at a single location in		categorization decisions that locate resources at a single location in
	the hierarchy, a drawback when a resource has multiple valid categories.		the hierarchy, a drawback when a resource has multiple valid categories.
	For example, in a hierarchy of vehicle descriptions containing		For example, in a hierarchy of vehicle descriptions containing
	collections for cars and boats, a description of a combination car/boat		collections for cars and boats, a description of a combination car/boat
	vehicle could belong in either collection. Ideally, the description		vehicle could belong in either collection. Ideally, the description
	should be accessible from both.		should be accessible from both.
	skipping to change at line 189		skipping to change at line 194
	space, the BIND method also has the effect of adding the resource to a		space, the BIND method also has the effect of adding the resource to a
	collection. As new URIs are associated with the resource, it appears in		collection. As new URIs are associated with the resource, it appears in
	additional collections.		additional collections.
	The redirect reference resources defined here are a different mechanism		The redirect reference resources defined here are a different mechanism
	for allowing a single resource to appear in multiple collections. A		for allowing a single resource to appear in multiple collections. A
	redirect reference resource is a resource in one collection whose		redirect reference resource is a resource in one collection whose
	purpose is to forward requests to another resource (its target), usually		purpose is to forward requests to another resource (its target), usually
	in a different collection. In this way, it allows clients to submit		in a different collection. In this way, it allows clients to submit
	requests to the target resource from another collection. It redirects		requests to the target resource from another collection. It redirects
	most requests to the target resource using the HTTP 302 (Moved		most requests to the target resource using the HTTP 302 (Found) status
	Temporarily) status code, thereby providing a form of mediated access to		code, thereby providing a form of mediated access to the target
	the target resource.		resource.
	These two approaches to allowing clients to add a single resource to		These two approaches to allowing clients to add a single resource to
	multiple collections have very different characteristics:		multiple collections have very different characteristics:
	A redirect reference is a resource, and so can have properties of its		A redirect reference is a resource, and so can have properties of its
	own. Such information as who created the reference, when, and why can		own. Such information as who created the reference, when, and why can
	be stored on the redirect reference resource. Since redirect references		be stored on the redirect reference resource. Since redirect references
	are implemented using HTTP 302 responses, it generally takes two round		are implemented using HTTP 302 responses, it generally takes two round
	trips to submit a request to the intended resource. Servers are not		trips to submit a request to the intended resource. Servers are not
	required to enforce the integrity of redirect references. Redirect		required to enforce the integrity of redirect references. Redirect
	skipping to change at line 214		skipping to change at line 219
	By contrast, a BIND request does not create a new resource, but simply		By contrast, a BIND request does not create a new resource, but simply
	makes available a new URI for submitting requests to an existing		makes available a new URI for submitting requests to an existing
	resource. The new URI can be used like any other URI to submit a		resource. The new URI can be used like any other URI to submit a
	request to a resource. Only one round trip is needed to submit a		request to a resource. Only one round trip is needed to submit a
	request to the intended target. Servers are required to enforce the		request to the intended target. Servers are required to enforce the
	integrity of the relationships between the new URIs clients create and		integrity of the relationships between the new URIs clients create and
	the resources associated with them. Consequently, it is unlikely that		the resources associated with them. Consequently, it is unlikely that
	servers will support BIND requests that cross server boundaries.		servers will support BIND requests that cross server boundaries.
			The remainder of this document is structured as follows: Section 3
			defines terms that will be used throughout the specification. Section 4
			provides an overview of redirect reference resources. Section 5
			discusses how to create a redirect reference resource. Section 6
			defines the semantics of existing methods when applied to redirect
			reference resources, and Section 7 discusses their semantics when
			applied to collections that contain redirect reference resources.
			Sections 8 through 10 discuss several other issues raised by the
			existence of redirect reference resources. Sections 11 through 15
			define the new status codes, headers, properties, and XML elements
			required to support redirect reference resources. Section 16 discusses
			capability discovery. Sections 17 through 19 present the security,
			internationalization, and IANA concerns raised by this specification.
			The remaining sections provide a variety of supporting information.
	3 Terminology		3 Terminology
	The terminology used here follows and extends that in the WebDAV		The terminology used here follows and extends that in the WebDAV
	Distributed Authoring Protocol specification [WebDAV]. Definitions of		Distributed Authoring Protocol specification [WebDAV]. Definitions of
	the terms resource, Uniform Resource Identifier (URI), and Uniform		the terms resource, Uniform Resource Identifier (URI), and Uniform
	Resource Locator (URL) are provided in [URI].		Resource Locator (URL) are provided in [URI].
	Reference Resource		Reference Resource
	A resource whose purpose is to forward requests to another		A resource whose purpose is to forward requests to another
	resource. Reference resources are an alternative mechanism to		resource. Reference resources are an alternative mechanism to
	bindings (defined in [B]) for allowing clients to create multiple		bindings (defined in [B]) for allowing clients to create multiple
	URIs that can be used to submit requests to the same resource.		URIs that can be used to submit requests to the same resource.
	Redirect Reference Resource		Redirect Reference Resource
	A resource that forwards requests to another resource using the		A resource that allows clients to forward requests to another
	HTTP 1.1 302 (Moved Temporarily) response mechanism. The client		resource using the HTTP 1.1 302 (Found) response mechanism. The
	is aware that this type of reference resource is mediating between		client is aware that this type of reference resource is mediating
	it and the target resource.		between it and the target resource.
			Direct Reference Resource
			Direct Reference Resources are out of scope for this
			specification, but are defined here for contrast with redirect
			reference resources. A direct reference resource automatically
			forwards requests to another resource, in a way that is
			transparent to the client.
	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 forwarded by a reference
	resource.		resource.
	4 Overview of Redirect Reference Resources		4 Overview of Redirect Reference Resources
	For most operations submitted to a redirect reference resource, the		For all operations submitted to a redirect reference resource, the
	response is a 302 (Moved Temporarily), accompanied by the Resource-Type		default response is a 302 (Found), accompanied by the Redirect-Ref
	header (defined in Section 14.2 below) set to "DAV:redirectref" and the		header (defined in Section 12.1 below) and the Location header set to
	Location header set to the URI of the target resource. With this		the URI of the target resource. With this information, the client can
	information, the client can resubmit the request to the URI of the		resubmit the request to the URI of the target resource.
	target resource. The methods COPY (for collections containing redirect
	reference resources), DELETE, MOVE, and LOCK, for reasons that will be		A redirect reference resource never automatically forwards requests to
	explained, are exceptions to this general behavior. These exceptional		its target resource. It is this characteristic that distinguishes
	operations are applied to the reference resource itself and do not		redirect reference resource from direct reference resources and from
	result in a 302 response.		bindings. It is also what insures that redirect reference resources
			will be simple to implement and that cross-server references will be
			possible. If the redirect reference resource were required to forward
			requests automatically, the server would need proxy capabilities in
			order to support cross-server references.
	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 15.1 below), whose		resource's DAV:reftarget property (defined in Section 13.1 below), whose
	value contains the URI of the target resource. It can then submit		value contains the URI of the target resource. It can then submit
	requests to the target resource.		requests to the target resource.
	A redirect reference resource is a new type of resource. To distinguish		A redirect reference resource is a new type of resource. To distinguish
	redirect reference resources from non-reference resources, a new value		redirect reference resources from non-reference resources, a new value
	of the DAV:resourcetype property (defined in [WebDAV]), DAV:redirectref,		of the DAV:resourcetype property (defined in [WebDAV]), DAV:redirectref,
	is defined in Section 16.1 below.		is defined in Section 14.1 below.
	Since a redirect reference resource is a resource, it is possible to		Since a redirect reference resource is a resource, it is possible to
	apply methods to the reference resource rather than to its target		apply methods to the reference resource rather than to its target
	resource. The Passthrough request header (defined in Section 14.3		resource. The Passthrough request header (defined in Section 12.2
	below) is provided so that referencing-aware clients can control whether		below) is provided so that referencing-aware clients can control whether
	an operation is applied to the redirect reference resource or to its		an operation is applied to the redirect reference resource or to its
	target resource. The Passthrough header can be used with most requests		target resource. The Passthrough header can be used with most requests
	to redirect reference resources. This header is particularly useful		to redirect reference resources. This header is particularly useful
	with PROPFIND, to retrieve the reference resource's own properties.		with PROPFIND, to retrieve the reference resource's own properties.
	5 MKREF Method		5 Creating a Redirect Reference Resource
	5.1 Overview of MKREF		The MKRESOURCE method is used to create new redirect reference
			resources. The values of two properties must be set in the body of the
			MKRESOURCE request. The value of DAV:resourcetype MUST be set to
			DAV:redirectref, a new value of DAV:resourcetype defined in Section
			14.1. The value of DAV:reftarget MUST be set to the URI of the target
			resource.
	The MKREF method creates a redirect reference resource identified by the		Used in this way, the MKRESOURCE method creates a redirect reference
	Request-URI, whose target is identified by the REQUIRED Ref-Target		resource whose target is identified by the DAV:reftarget property. It
	header. MKREF sets the value of the REQUIRED DAV:reftarget property to		creates a new binding between the new redirect reference resource and
	the value of the Ref-Target header.		the last path segment of the Request-URI. The new binding is added to
			its parent collection, identified by the Request-URI minus its trailing
			slash (if present) and final segment.
	The MKREF method creates a new binding between the new redirect		5.1 MKRESOURCE
	reference resource and the last path segment of the Request-URI. The		The MKRESOURCE method requests the creation of a resource and
	new binding is added to its parent collection, identified by the		initialization of its properties. It allows resources other than
	Request-URI minus its trailing slash (if present) and final segment.		standard data containers and collections to be created and their
			properties initialized in one atomic operation.
	MKREF requests MAY include an entity body. This specification does not		Preconditions:
	define the action to be taken if a request entity body is present, but
	allows it for extensibility.
	By default, if the Request-URI of the MKREF request identifies an		If the Overwrite header is not present or is set to 'F', a resource MUST
	existing resource, the request MUST fail with a 405 (Method Not Allowed)		NOT exist at the Request-URI.
	response code. This default behavior can be overridden using the
	Overwrite header defined in Section 9.6 of [WebDAV].
	5.2 Status Codes		Marshalling:
	201 (Created): The redirect reference resource was successfully created.		The location of the new resource to be created is specified by the
			Request-URI. The Overwrite header MAY be specified. The request body
			of the MKRESOURCE method is the same as the request body for PROPPATCH,
			that is, it MUST contain the DAV:propertyupdate XML element defined in
			Section 12.13 of [WebDAV].
	400 (Bad Request): The client set an invalid value for the Ref-Target		Semantics:
	header.
	405 (Method Not Allowed): A resource already exists at the Request-URI.		Creation of the resource and initialization of its properties MUST both
			occur, or neither occurs. Property initialization is carried out using
			PROPPATCH semantics. The type of resource to create is specified by the
			DAV:resourcetype property. If the DAV:resourcetype property is not
			specified, the resource created will be a standard data container.
	409 (Conflict): Several conditions may produce this response. There may		If the Overwrite header is set to 'T' and MKRESOURCE is applied to an
	be no resource at the location specified in Ref-Target, on a server that		existing resource, the existing resource is deleted using DELETE
	prohibits dangling reference resources. The request may be attempting		semantics prior to MKRESOURCE processing. If deletion or resource
	to create the reference resource in a collection that does not exist.		creation cannot be completed, the entire operation fails and the
			existing resource MUST be left unaffected. Since existing resources are
			deleted, MKRESOURCE cannot be used to change the DAV:resourcetype of a
			resource.
	412 (Precondition Failed): The Overwrite header is "F" or absent, and a		Postconditions:
	resource already exists at the request-URI.
	5.3 Example: MKREF		After the successful execution of MKRESOURCE, a new resource exists.
			The body of the new resource is empty, while the initial values of the
			properties of the new resource are those specified in the property
			update directives in the request body.
			Response Marshalling:
			Results from a MKRESOURCE request SHOULD NOT be cached, as MKRESOURCE
			has non-idempotent semantics.
			The following status codes can be expected in responses to MKRESOURCE:
			201 (Created): The new resource was successfully created.
			207 (Multi-Status): This response is generated if (1) the deletion of a
			resource other than the one identified by the Request-URI could not be
			completed, in which case the response is as defined in Section 8.6.2 of
			[WebDAV], or (2) an error was encountered while initializing the
			properties of the resource, in which case the response is as defined in
			Section 8.2.1 of [WebDAV].
			403 (Forbidden): The server does not allow the creation of the requested
			resource type at the requested location, or the parent collection of the
			Request-URI exists but cannot accept members.
			409 (Conflict): A resource cannot be created at the Request-URI until
			one or more intermediate collections have been created.
			412 (Precondition Failed): The Overwrite header is not present or is set
			to 'F', and a resource exists at the Request-URI.
			423 (Locked): A locked resource exists at the Request-URI and the lock
			token was not passed in with the request.
			507 (Insufficient Storage): The server does not have sufficient space to
			record the state of the resource.
			5.2 Status Codes
			In addition to the common status codes returned by MKRESOURCE, the
			following special case can arise when creating a redirect reference
			resource:
			509 (Dangling References Forbidden): Some servers may have a policy that
			forbids dangling references. These servers will respond with 509 if
			there is no resource at the location specified in the DAV:reftarget
			property.
			5.3 Example: Creating a Redirect Reference Resource with MKRESOURCE
	>> Request:		>> Request:
	MKREF /~whitehead/dav/spec08.ref HTTP/1.1		MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1
	Host: www.ics.uci.edu		Host: www.ics.uci.edu
	Ref-Target: </i-d/draft-webdav-protocol-08.txt>		Content-Type: text/xml; charset="utf-8"
			Content-Length: xxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:propertyupdate xmlns:D="DAV:">
			<D:set>
			<D:prop>
			<D:resourcetype><D:redirectref/></D:resourcetype>
			<D:reftarget>
			<D:href>/i-d/draft-webdav-protocol-08.txt</D:href>
			</D:reftarget>
			</D:prop>
			</D:set>
			</D:propertyupdate>
	>> Response:		>> Response:
	HTTP/1.1 201 Created		HTTP/1.1 201 Created
	This request resulted in the creation of a new redirect reference		This request resulted in the creation of a new redirect reference
	resource at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to		resource at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to
	the resource identified by the Ref-Target header. In this example, the		the resource identified by the DAV:reftarget property. In this example,
	target resource of the referential resource is identified by the URI		the target resource is identified by the URI http://www.ics.uci.edu/i-
	http://www.ics.uci.edu/~whitehead/dav/i-d/draft-webdav-protocol-08.txt.		d/draft-webdav-protocol-08.txt. The redirect reference resource's
	The referential resource's DAV:resourcetype property is set to		DAV:resourcetype property is set to DAV:redirectref.
	DAV:redirectref. Its DAV:reftarget property is set to the value of the
	Ref-Target header, "/i-d/draft-webdav-protocol-08.txt".
	6 Listing the Redirect Reference Resources in a Collection		6 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 302 (Found) status code, unless the request
			includes a Passthrough header with a value of "F". The client and server
			MUST follow [HTTP] Section 10.3.3 "302 Found," but with these additional
			rules:
			o The Location response header MUST contain the absolute target URI 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 act on this response in one of two
			ways. It 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 Passthrough header set to "F" in
			order to operate on the reference resource itself. If the Passthrough
			header is present with a value of "F", the request MUST be applied to
			the reference resource itself, and a 302 response MUST NOT be returned.
			A reference-aware client may know before submitting its request that the
			Request-URI identifies a redirect reference resource. In this case, if
			the client wants to apply the method to the reference resource, it can
			save the round trip caused by the 302 response by using "Passthrough: F"
			in its initial request to the URI.
			A few methods need additional explanation:
			"Passthrough: F" can be used with GET or HEAD to retrieve the entity
			headers of a redirect reference resource. When "Passthrough: F" is used
			with GET or HEAD, the Redirect-Ref entity header MUST be returned, along
			with all HTTP headers that make sense for reference resources (for
			example, Cache-Control, Age, ETag, Expires, and Last-Modified).
			"Passthrough: F" can be used with PUT to replace the redirect reference
			resource with a non-reference resource.
			Clients MUST NOT use "Passthrough: F" with POST. Since a reference
			resource cannot accept another entity as its subordinate, an attempt to
			POST to a reference resource with "Passthrough: F" will also fail. If a
			server receives a POST request with "Passthrough: F" on a redirect
			reference resource, it MUST fail the request with a 400 (Bad Request)
			status code.
			Since MKCOL and MKRESOURCE fail when applied to existing resources, if
			the client attempts to resubmit the request to the target resource, the
			request MUST fail (unless the reference resource is a dangling
			reference). Similarly, if the client attempts to resubmit the request
			to the reference resource with "Passthrough: F", the request MUST fail.
			Since ORDERPATCH applies only to collections, an ORDERPATCH request with
			a Passthrough header with the value "F" on a redirect reference resource
			MUST fail.
			6.1 Example: GET on a Redirect Reference Resource
			>> Request:
			GET /bar.html HTTP/1.1
			Host: www.foo.com
			>> Response:
			HTTP/1.1 302 Found
			Location: http://www.svr.com/Internet/xxspec08.html
			Redirect-Ref:
			Since /bar.html is a redirect reference resource and the Passthrough
			header is not included in the request, the response is a 302 (Found).
			The Redirect-Ref header informs a reference-aware client that this is
			not an ordinary HTTP 1.1 redirect, but is a redirect reference resource.
			The URI of the target resource is provided in the Location header so
			that the client can resubmit the request to the target resource.
			6.2 Example: PUT on a Redirect Reference Resource with "Passthrough: F"
			>> Request:
			PUT /bar.html HTTP/1.1
			Host: www.foo.com
			Passthrough: F
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxxx
			. . . some content . . .
			>> Response:
			HTTP/1.1 200 OK
			Although /bar.html is a redirect reference resource, the presence of the
			"Passthrough: F" header prevents a 302 response, and instead causes the
			request to be applied to the reference resource. The result in this
			case is that the reference resource is replaced by a non-reference
			resource having the content submitted with the request.
			6.3 Example: PROPPATCH on a Redirect Reference Resource
			>> Request:
			PROPPATCH /bar.html HTTP/1.1
			Host: www.foo.com
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:propertyupdate xmlns:D="DAV:"
			xmlns:Z="http://www.w3.com/standards/z39.50/">
			<D:set>
			<D:prop>
			<Z:authors>
			<Z:Author>Jim Whitehead</Z:Author>
			<Z:Author>Roy Fielding</Z:Author>
			</Z:authors>
			</D:prop>
			</D:set>
			<D:remove>
			<D:prop><Z:Copyright-Owner/></D:prop>
			</D:remove>
			</D:propertyupdate>
			>> Response:
			HTTP/1.1 302 Found
			Location: http://www.svr.com/Internet/xxspec08.html
			Redirect-Ref:
			Since /bar.html is a redirect reference resource and the Passthrough
			header is not included in the request, the response is a 302 (Found).
			The Redirect-Ref header informs a reference-aware client that this is
			not an ordinary HTTP 1.1 redirect, but is a redirect reference resource.
			The URI of the target resource is provided in the Location header so
			that the client can resubmit the request to the target resource.
			7 Operations on Collections That Contain Redirect Reference Resources
	A URI of a redirect reference resource can be an internal member URI of		A URI of a redirect reference resource can be an internal member URI of
	a collection just as the URI of a non-reference resource can. A listing		a collection just as the URI of a non-reference resource can. Any
			operation on a collection with Depth: 1 or Depth: infinity applies to
			redirect reference resources in the collection just as it applies to any
			other resources in the collection. The methods that can accept a Depth
			header are PROPFIND, COPY, MOVE, DELETE, and LOCK.
	of the internal member URIs of a collection shows all of the URIs that		Consistent with the rules in Section 6, the response for each redirect
	are internal members of the collection, whether they identify redirect		reference encountered while processing a collection MUST be a 302
	reference resources or non-reference resources. That is, a WebDAV		(Found) unless a Passthrough header with the value "F" is included with
	PROPFIND request on a collection resource with the Depth header set to 1		the request. The overall response will therefore be a 207 (Multi-
	or infinity MUST return a response XML element for each member URI in		Status). Since a Location header and Redirect-Ref header cannot be
	the collection, whether it identifies a non-reference resource or a		returned for each redirect reference encountered, the same information
	redirect reference resource.		must be provided using properties in the response elements for those
			resources. The DAV:location pseudo-property and the DAV:resourcetype
			property MUST be included with the 302 status code. This necessitates
			an extension to the syntax of the DAV:response element that was defined
			in [WebDAV]. The extension is defined in Section 15 below.
	For each redirect reference resource, the response element MUST contain		A referencing-aware client can tell from the DAV:resourcetype property
	a 302 (Moved Temporarily) status code unless a Passthrough header with
	the value "F" is included with the PROPFIND request. The DAV:location
	pseudo-property and the DAV:resourcetype property MUST be included with
	the 302 status code, extending the syntax of the DAV:response element
	that was defined in [WebDAV] as described in Section 17 below. A
	referencing-aware client can tell from the DAV:resourcetype property
	that the collection contains a redirect reference resource. The		that the collection contains a redirect reference resource. The
	DAV:location pseudo-property contains the absolute URI of the target		DAV:location pseudo-property contains the absolute URI of the target
	resource. A referencing-aware client can either use the URI value of		resource. A referencing-aware client can either use the URI value of
	the DAV:location pseudo-property to retrieve the properties of the		the DAV:location pseudo-property to resubmit its request to the target
	target resource, or it can submit a PROPFIND to the redirect reference		resource, or it can submit the request to the redirect reference
	resource with "Passthrough: F" to retrieve its properties. It is		resource with "Passthrough: F".
	recommended that future editors of [WebDAV] define the DAV:location
	pseudo-property in [WebDAV], so that non-referencing clients will also
	be able to use the response to retrieve the properties of the target
	resource.
	If the Depth header is set to infinity in the PROPFIND request, the		It is recommended that future editors of [WebDAV] define the
	server MUST NOT follow redirect reference resources into any collections		DAV:location pseudo-property in [WebDAV], so that non-referencing
	to which they may refer.		clients will also be able to use the response to operate on the target
			resource. (This will also enable clients to operate on traditional
			HTTP/1.1 302 responses in Multi-Status responses.) Until then, non-
	The Passthrough header (defined in Section 14.3) MAY be used with a		referencing clients will not be able to process 302 responses from
	PROPFIND request on a collection.		redirect reference resources encountered while processing a collection.
	6.1 Example: PROPFIND on a Collection with Redirect Reference Resources		The Passthrough header (defined in Section 12.2) MAY be used with any
			request on a collection. If present, it will be applied to all redirect
			reference resources encountered while processing the collection.
			7.1 MOVE and DELETE on Collections That Contain Redirect References
			DELETE removes the binding that corresponds to the Request-URI. MOVE
			removes that binding and creates a new binding to the same resource. In
			cases where DELETE and MOVE are applied to a collection, these
			operations affect all the descendents of the collection, but they do so
			indirectly. There is no need to visit each descendent in order to
			process the request. Consequently, even if there are redirect reference
			resources in a tree that is being deleted or moved, there will be no 302
			responses from the redirect reference resources.
			7.2 LOCK on a Collection That Contains Redirect References
			LOCK poses special problems because it is atomic. An attempt to lock
			(with Depth: infinity) a collection that contains redirect references
			will always fail. The Multi-Status response will contain a 302 response
			for each redirect reference.
			Reference-aware clients can lock the collection by using Passthrough: F,
			and, if desired, lock the targets of the redirect references
			individually.
			Non-referencing clients must resort to locking each resource
			individually.
			7.3 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:
	http://www.svr.com/MyCollection/		http://www.svr.com/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 line 429		skipping to change at line 705
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:resourcetype/>		<D:resourcetype/>
	<J:keywords>diary, travel, family, history</J:keywords>		<J:keywords>diary, travel, family, history</J:keywords>
	</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:response>		<D:response>
	<D:href>http://www.svr.com/MyCollection/nunavut</D:href>		<D:href>http://www.svr.com/MyCollection/nunavut</D:href>
	<D:status>HTTP/1.1 302 Moved Temporarily</D:status>		<D:status>HTTP/1.1 302 Found</D:status>
	<D:prop>		<D:prop>
	<D:location>		<D:location>
	<D:href>http://www.inac.gc.ca/art/inuit/</D:href>		<D:href>http://www.inac.gc.ca/art/inuit/</D:href>
	</D:location>		</D:location>
	<D:resourcetype><D:redirectref/></D:resourcetype>		<D:resourcetype><D:redirectref/></D:resourcetype>
	</D:prop>		</D:prop>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
	In this example the Depth header is set to infinity, and the Passthrough		In this example the Depth header is set to infinity, and the Passthrough
	header is not used. The collection contains one URI that identifies a		header is not used. The collection contains one URI that identifies a
	redirect reference resource. The response element for the redirect		redirect reference resource. The response element for the redirect
	reference resource has a status of 302 (Moved Temporarily), and includes		reference resource has a status of 302 (Found), and includes a DAV:prop
	a DAV:prop element with the DAV:location pseudo-property and the		element with the DAV:location pseudo-property and the DAV:resourcetype
	DAV:resourcetype property to allow clients to retrieve the properties of		property to allow clients to retrieve the properties of its target
	its target resource. (The response element for the redirect reference		resource. (The response element for the redirect reference resource
	resource does not include the requested properties. The client can		does not include the requested properties. The client can submit
	submit another PROPFIND request to the URI in the DAV:location pseudo-		another PROPFIND request to the URI in the DAV:location pseudo-property
	property to retrieve those properties.)		to retrieve those properties.)
			7.4 Example: PROPFIND with Passthrough: F on a Collection with Redirect
	6.2 Example: PROPFIND with Passthrough: F on a Collection with Redirect
	Reference Resources		Reference Resources
	Suppose a PROPFIND request with Passthrough = F and Depth = infinity is		Suppose a PROPFIND request with Passthrough = F and Depth = infinity is
	submitted to the following collection, with the members shown here:		submitted to the 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 line 531		skipping to change at line 808
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
	Since the Passthrough header has the value "F", the response shows the		Since the Passthrough header has the value "F", the response shows the
	properties of the redirect reference resource in the collection rather		properties of the redirect reference resource in the collection rather
	than the properties of its target. The value of the Passthrough header		than the properties of its target. The value of the Passthrough header
	also prevents a 302 response from being returned for the redirect		also prevents a 302 response from being returned for the redirect
	reference resource.		reference resource.
	7 Copying Redirect Reference Resources		7.5 Example: COPY on a Collection That Contains a Redirect Reference
	A client's intent in performing a COPY operation is to create a new
	resource that is similar to the original resource and behaves like the
	original resource, and that can be modified without affecting the
	original resource. For a COPY request to a redirect reference resource,
	the expectation would be a 302 response that the client could use to
	copy the target resource. This would yield an independent resource that
	could be modified without affecting the original resource. For COPY
	requests to collections that contain redirect reference resources, the
	situation is less clear. There is tension between two expectations. On
	the one hand, the client may expect the new copy of the collection to
	behave like the old one (which implies having reference resources where
	the old one had reference resources). On the other hand, the client may
	expect that it will be possible to modify the resources in the new
	collection without affecting the resources in the old collection (which
	implies having copies of the target resources where the original
	collection had reference resources).
	For a COPY request on an individual reference resource, the response
	MUST be a 302 (Moved Temporarily) status code, with the URI of the
	target resource in the Location header, and "Resource-Type:
	DAV:redirectref" to distinguish the response from an ordinary HTTP
	redirect. This is the normal behavior for redirect reference resources,
	allowing the client to resubmit the request to the target resource
	identified in the Location header. This also yields intuitively correct
	behavior for a COPY request to an individual reference resource.
	Reference-aware clients can use the Passthrough header with the value
	"F" to copy the redirect reference resource itself.
	For COPY on a collection containing redirect reference resources,
	different semantics may be desirable in different scenarios.
	Consequently, this specification makes a fairly arbitrary choice to take
	the simplest path. When a COPY request is submitted to a collection
	containing redirect reference resources, the server MUST copy the
	redirect reference resources to the new collection rather than returning
	302 status codes for them. This will result in a new collection that
	behaves like the old one, and avoids responding with multiple 302 status
	codes, each of which the client would have to process separately.
	Reference-aware clients can force the server to respond with 302 status
	codes rather than copying the reference resources by using the
	Passthrough header with the value "T".
	7.1 Example: COPY on a Redirect Reference Resource
	>> Request:
	COPY /MyCollection/tuva HTTP/1.1
	Host: www.svr.com
	Destination: http://www.svr.com/OtherCollection/tuva.html
	>> Response:
	HTTP/1.1 302 Moved Temporarily
	Location: http://www.svr.com/Asia/History/tuva.html
	Resource-Type: DAV:redirectref
	In this example, the request-URI identifies a redirect reference
	resource whose target resource is identified by
	http://www.svr.com/Asia/History/tuva.html. In this case, the server
	responded with a 302, and provided the URL of the target resource in the
	Location header. The Resource-Type header indicates to a reference-
	aware client that this is not an HTTP 1.1 redirect, but a reference to
	the resource identified by the Location header. The client can now
	resubmit the COPY request to the target resource, producing the desired
	result: a duplicate of the original target resource that can be modified
	independently of the original.
	7.2 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
	>> Request:		>> Request:
	COPY /MyCollection/ HTTP/1.1		COPY /MyCollection/ HTTP/1.1
	Host: www.svr.com		Host: www.svr.com
	Destination: http://www.svr.com/OtherCollection/		Destination: http://www.svr.com/OtherCollection/
	>> Response:		>> Response:
	HTTP/1.1 201 Created		HTTP/1.1 207 Multi-Status
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:multistatus xmlns:D="DAV:">
			<D:response>
			<D:href>http://www.svr.com/MyCollection/nunavut</D:href>
			<D:status>HTTP/1.1 302 Found</D:status>
			<D:prop>
			<D:location>
			<D:href>
			http://www.svr.com//Someplace/nunavut.map
			</D:href>
			</D:location>
			<D:resourcetype><D:redirectref/></D:resourcetype>
			</D:prop>
			</D:response>
			</D:multistatus>
	In this case, since /MyCollection/nunavut is a redirect reference		In this case, since /MyCollection/nunavut is a redirect reference
	resource, the reference resource itself, and not its target resource,		resource, the COPY operation was only a partial success. The redirect
	was copied into the new collection. So the resulting collection is as		reference resource was not copied, but a 302 response was returned for
	follows:		it. So the resulting collection is as follows:
	/OtherCollection/		/OtherCollection/
	(non-reference resource) diary.html		(non-reference resource) diary.html
	(redirect reference resource) nunavut with target
	/Someplace/nunavut.map
	8 Deleting and Moving Redirect Reference Resources
	The DELETE method is used to delete bindings to redirect reference
	resources. DELETE MUST affect bindings to the reference resource itself,
	unless "Passthrough: T" is used, in which case it generates a 302 (Moved
	Temporarily) response. Similarly, when a DELETE on a collection
	encounters a redirect reference resource in the subtree under that
	collection, it MUST delete bindings to the reference resource, unless
	"Passthrough: T" is used, in which case it generates a 302 (Moved
	Temporarily) response. Whether deleting an individual resource or a
	collection, DELETE on a redirect reference resource does not affect the
	target of the reference resource.
	A MOVE operation on a redirect reference resource MUST move the
	reference resource to a different location, and MUST NOT change the
	location of its target resource, unless "Passthrough: T" is used, in
	which case a 302 (Moved Temporarily) response is generated. The
	DAV:reftarget property is unchanged after a MOVE. Similarly, when a
	MOVE on a collection encounters a redirect reference resource in the
	subtree under that collection, it MUST move the reference resource, and
	not its target, unless "Passthrough: T" is used, in which case a 302
	(Moved Temporarily) response is generated.
	DELETE and MOVE differ from other methods in that they do not alter the
	resource that is being deleted or moved, but rather the collection that
	contains its binding. They change the membership of that collection.
	When a redirect reference resource is added to a collection, the aim is
	to make it look as if the target resource were a member of that
	collection. When the reference resource is removed from that
	collection, the aim is to change the membership of that collection.
	Membership of the target resource in any other collections, either
	internally or by reference, should not be affected. Consequently,
	DELETE and MOVE do not follow the normal rules of behavior for reference
	resources. Instead, they are applied by default to the reference
	resource itself, not to its target resource, and by default do not
	result in 302 status codes.
	9 Locking Redirect Reference Resources
	The semantics of LOCK described here resulted from balancing a set of
	incompatible considerations:
	o Ideally, a LOCK on a redirect reference resource should lock both the
	reference resource and its target resource. The owner of an
	exclusive write lock, for example, would be surprised if anyone else
	could modify the content of the target resource while he held the
	lock. He would also be surprised if anyone else could delete the
	reference to it, or replace the reference resource with one pointing
	to a different target resource.
	o Non-referencing clients should be able to use redirect reference
	resources without encountering surprising results.
	o The basic characteristics of redirect reference resources should be
	honored. Redirect reference resources should be simple for servers
	to implement. In particular, a server should never have to resolve a
	redirect reference. A server should not have to provide proxy
	capabilities in order to implement redirect references.
	o There should be consistency between the behavior of LOCK on a single
	redirect reference resource and the behavior of LOCK on a collection
	that contains redirect reference resources.
	o The behavior of all requests to redirect reference resources should
	be as consistent as possible. In the absence of a Passthrough header,
	all methods should return a 302 when sent to a redirect reference
	resource.
	o LOCK semantics for redirect reference resources should be consistent
	with the LOCK semantics defined in [WebDAV].
	We have compromised the intuitive locking behavior and support for non-
	referencing clients in order to preserve various sorts of consistency.
	The behavior of LOCK for redirect reference resources was determined by
	what is possible for the case of locking collections that contain
	redirect reference resources.
	The default behavior for any operation on a redirect reference resource
	is that a 302 (Moved Temporarily) response will be returned, unless the
	Passthrough header with a value of "F" is used. However, this policy
	has unacceptable consequences when locking a collection that contains
	redirect reference resources. Since [WebDAV] requires LOCK on a
	collection to be an atomic operation, if a 302 response is received for
	any member of the collection, the entire LOCK must fail. This would
	make it impossible to lock any collection that contained a redirect
	reference resource.
	To avoid this result, a LOCK with Depth > 0 on a collection MUST lock
	any redirect reference resources it encounters, and not return 302
	responses for them, unless the Passthrough header with a value of "T" is
	used. Use of the Passthrough header with a value of "T" in a LOCK
	request on a collection will cause the entire lock to fail if a redirect
	reference resource is encountered.
	This gives part of the expected default lock behavior without forcing
	the server to resolve the redirect reference or become a proxy server in
	cases where the target resides on a different server.
	There will be no hint in any response code that there are redirect
	reference resources whose targets need to be locked. The client will
	most likely not lock any target resources until it attempts an operation
	on the target resource and gets a 302 response. It is possible that a
	non-referencing client may never realize that the reference resource's
	target has not been locked.
	Clearly, a LOCK with Depth = infinity on a collection MUST NOT follow
	any redirect reference resources whose targets are collections into the
	target collections; it MUST NOT cause any resources in those target
	collections to be locked.
	The behavior of LOCK for individual redirect reference resources is
	designed to be consistent with LOCK behavior for collections that
	contain redirect reference resources. By default a LOCK on a redirect
	reference resource MUST lock only the reference resource, not its target
	resource, and it MUST NOT return a 302 response. A reference-aware
	client can use the Passthrough header with a value of "T" to get a 302
	response with the URI of the target resource in the Location header.
	UNLOCK behaves as specified in [WebDAV], unlocking all resources
	included in the lock identified by the Lock-Token header.
	9.1 Example: LOCK on a Redirect Reference Resource		7.6 Example: LOCK on a Collection That Contains a Redirect Reference
	>> Request:
	LOCK /MyCollection/tuva HTTP/1.1
	Host: www.svr.com
	Content-Type: text/xml
	Content-Length: nnnn
	Authorizaton: Digest username="jas",
	realm=jas@webdav.sb.aol.com, nonce=". . . ",
	uri="/MyCollection/tuva",
	response=". . . ", opaque=". . . "
	<?xml version="1.0" ?>
	<D:lockinfo xmlns:D="DAV:">
	<D:lockscope><D:exclusive/></D:lockscope>
	<D:locktype><D:write/></D:locktype>
	<D:owner>
	<D:href>http://www.svr.com/~jas/contact.html</D:href>
	</D:owner>
	</D:lockinfo>
	>> Response:
	HTTP/1.1 200 OK
	Content-Type: text/xml
	Content-Length: nnnn
	<?xml version="1.0" ?>
	<D:prop xmlns:D="DAV:">
	<D:lockdiscovery>
	<D:activelock>
	<D:lockscope><D:exclusive/></D:lockscope>
	<D:locktype><D:write/></D:locktype>
	<D:depth>0</D:depth>
	<D:owner>
	<D:href>http://www.svr.com/~jas/contact.html</D:href>
	</D:owner>
	<D:locktoken>
	opaquelocktoken:e71dfae-5dec-22d6-fea5-00a0c91e6be4
	</D:locktoken>
	</D:activelock>
	</D:lockdiscovery>
	</D:prop>
	The request and response look exactly as specified in [WebDAV]. In this
	example, the request-URI, http://www.svr.com/MyCollection/tuva,
	identifies a redirect reference resource, which was successfully locked.
	The target resource of the redirect reference resource is not locked.
	9.2 Example: LOCK on a Collection That Contains a Redirect Reference
	Resource, with Passthrough: T		Resource, with Passthrough: T
	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 line 850		skipping to change at line 908
	<D:prop><D:lockdiscovery/></D:prop>		<D:prop><D:lockdiscovery/></D:prop>
	<D:status>HTTP/1.1 424 Failed Dependency</D:status>		<D:status>HTTP/1.1 424 Failed Dependency</D:status>
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	<D:response>		<D:response>
	<D:href>http://www.svr.com/MyCollection/diary.html</D:href>		<D:href>http://www.svr.com/MyCollection/diary.html</D:href>
	<D:status>HTTP/1.1 424 Failed Dependency</D:status>		<D:status>HTTP/1.1 424 Failed Dependency</D:status>
	</D:response>		</D:response>
	<D:response>		<D:response>
	<D:href>http://www.svr.com/MyCollection/nunavut</D:href>		<D:href>http://www.svr.com/MyCollection/nunavut</D:href>
	<D:status>HTTP/1.1 302 Moved Temporarily</D:status>		<D:status>HTTP/1.1 302 Found</D:status>
	<D:prop>		<D:prop>
	<D:location>		<D:location>
	<D:href>http://www.inac.gc.ca/art/inuit/</D:href>		<D:href>http://www.inac.gc.ca/art/inuit/</D:href>
	</D:location>		</D:location>
	<D:resourcetype><D:redirectref/></D:resourcetype>		<D:resourcetype><D:redirectref/></D:resourcetype>
	</D:prop>		</D:prop>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
	The "Passthrough: T" header caused the server to return a 302 response		The "Passthrough: T" header caused the server to return a 302 response
	code for the redirect reference resource in the collection.		code for the redirect reference resource in the collection.
	Consequently, neither the collection nor any of the resources identified		Consequently, neither the collection nor any of the resources identified
	by its internal member URIs were locked. A referencing-aware client can		by its internal member URIs were locked. A referencing-aware client can
	submit a separate LOCK request to the URI in the DAV:location pseudo-		submit a separate LOCK request to the URI in the DAV:location pseudo-
	property returned for the redirect reference resource, and can resubmit		property returned for the redirect reference resource, and can resubmit
	the LOCK request with "Passthrough: F" to the collection. At that point		the LOCK request with "Passthrough: F" to the collection. At that point
	both the reference resource and its target resource will be locked (as		both the reference resource and its target resource will be locked (as
	well as the collection and all the resources identified by its other		well as the collection and all the resources identified by its other
	members).		members).
	10 Other Operations on Redirect Reference Resources		8 Operations on Targets of 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 a GET, HEAD, PUT, POST, OPTIONS, PROPFIND,
	PROPPATCH, MKCOL, MKREF, BIND, or ORDERPATCH request made via a redirect
	reference resource MUST return a 302 (Moved Temporarily) status code.
	The client and server MUST follow [HTTP] Section 10.3.3 "302 Moved
	Temporarily," but with these additional rules:
	o The Location response header MUST contain the absolute target URI of		Operations on targets of redirect reference resources have no effect on
	the reference resource.		the reference resource.
	o The response MUST include the Resource-Type header. This header		9 Relative URIs in DAV:reftarget
	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 act on this response in one of two
	ways. It 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 Passthrough header set to "F" in
	order to operate on the reference resource itself. If the Passthrough
	header is present with a value of "F", the request MUST be applied to
	the reference resource itself, and a 302 response MUST NOT be returned.
	If a reference-aware client knows before submitting its request that the
	request-URI identifies a redirect reference resource, and if the client
	wants to apply the method to the reference resource, it can save the
	round trip caused by the 302 response by using "Passthrough: F" in its
	initial request to the URI.
	"Passthrough: F" can be used with GET or HEAD to retrieve the entity
	headers of a redirect reference resource. When "Passthrough: F" is used
	with GET or HEAD, the referencing entity headers (Ref-Type and Ref-
	Target) MUST be returned, along with all HTTP headers that make sense
	for reference resources (for example, Cache-Control, Age, ETag, Expires,
	and Last-Modified).
	"Passthrough: F" can be used with PUT to replace the redirect reference
	resource with a non-reference resource. It can be used with OPTIONS to
	retrieve the capabilities of a redirect reference resource.
	Clients MUST NOT, however, use "Passthrough: F" with POST. Since a
	reference resource cannot accept another entity as its subordinate, an
	attempt to POST to a reference resource with "Passthrough: F" will also
	fail. If a server receives a POST request with "Passthrough: F" on a
	redirect reference resource, it MUST fail the request with a 400 (Bad
	Request) status code.
	Since MKCOL fails when applied to existing resources, if the client
	attempts to resubmit the request to the target resource, the request
	MUST fail (unless the reference resource is a dangling reference).
	Similarly, if the client attempts to resubmit the request to the
	reference resource with "Passthrough: F", the request MUST fail.
	Since ORDERPATCH applies only to collections, an ORDERPATCH request with
	a Passthrough header with the value "F" on a redirect reference resource
	MUST fail.
	10.1 Example: GET on a Redirect Reference Resource
	>> Request:
	GET /bar.html HTTP/1.1		The URI in the href in a DAV:reftarget property MAY be a relative URI.
	Host: www.foo.com		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 identify the
			redirect reference resource to which the DAV:reftarget property belongs.
	>> Response:		When DAV:reftarget occurs in the body of a MKRESOURCE request, the base
			URI is constructed as follows: Its scheme component is "http", its
			authority component is the value of the Host header in the request, and
			its path component is the Request-URI in the request. See Section 5 of
			[URI] for a discussion of relative URI references and how to resolve
			them.
	HTTP/1.1 302 Moved Temporarily		When DAV:reftarget appears in the context of a Multi-Status response, it
	Location: http://www.svr.com/Internet/xxspec08.html
	Resource-Type: DAV:redirectref
	Since /bar.html is a redirect reference resource and the Passthrough		is in a DAV:response element that contains a single DAV:href element.
	header is not included in the request, the response is a 302 (Moved		The value of this DAV:href element serves as the base URI for resolving
	Temporarily). The Resource-Type header informs a reference-aware client		a relative URI in DAV:reftarget. The value of DAV:href may itself be
	that this is not an ordinary HTTP 1.1 redirect, but is a redirect		relative, in which case it must be resolved first in order to serve as
	reference resource. The URI of the target resource is provided in the		the base URI for the relative URI in DAV:reftarget. If the DAV:href
	Location header so that the client can resubmit the request to the		element is relative, its base URI is constructed from the scheme
	target resource.		component "http", the value of the Host header in the request, and the
			request-URI.
	10.2 Example: PUT on a Redirect Reference Resource with "Passthrough: F"		9.1 Example: Resolving a Relative URI in a MKRESOURCE Request
	>> Request:		>> Request:
	PUT /bar.html HTTP/1.1		MKRESOURCE /north/inuvik HTTP/1.1
	Host: www.foo.com		Host: www.somehost.edu
	Passthrough: F
	Content-Type: text/xml; charset="utf-8"
	Content-Length: xxxx
	. . . some content . . .
	>> Response:
	HTTP/1.1 200 OK
	Although /bar.html is a redirect reference resource, the presence of the
	"Passthrough: F" header prevents a 302 response, and instead causes the
	request to be applied to the reference resource. The result in this
	case is that the reference resource is replaced by a non-reference
	resource having the content submitted with the request.
	10.3 Example: PROPPATCH on a Redirect Reference Resource
	Request:
	PROPPATCH /bar.html HTTP/1.1
	Host: www.foo.com
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:propertyupdate xmlns:D="DAV:"		<D:propertyupdate xmlns:D="DAV:">
	xmlns:Z="http://www.w3.com/standards/z39.50/">
	<D:set>		<D:set>
	<D:prop>		<D:prop>
	<Z:authors>		<D:resourcetype><D:redirectref/></D:resourcetype>
	<Z:Author>Jim Whitehead</Z:Author>		<D:reftarget>
	<Z:Author>Roy Fielding</Z:Author>		<D:href>mapcollection/inuvik.gif</D:href>
	</Z:authors>		</D:reftarget>
	</D:prop>		</D:prop>
	</D:set>		</D:set>
	<D:remove>
	<D:prop><Z:Copyright-Owner/></D:prop>
	</D:remove>
	</D:propertyupdate>		</D:propertyupdate>
	Response:
	HTTP/1.1 302 Moved Temporarily
	Location: http://www.svr.com/Internet/xxspec08.html
	Resource-Type: DAV:redirectref
	Since /bar.html is a redirect reference resource and the Passthrough
	header is not included in the request, the response is a 302 (Moved
	Temporarily). The Resource-Type header informs a reference-aware client
	that this is not an ordinary HTTP 1.1 redirect, but is a redirect
	reference resource. The URI of the target resource is provided in the
	Location header so that the client can resubmit the request to the
	target resource.
	11 Operations on Targets of Redirect Reference Resources
	Operations on targets of redirect reference resources have no effect on
	the reference resource.
	12 Relative URIs in Ref-Target and DAV:reftarget
	The URI in a Ref-Target header MAY be a relative URI. Similarly, the
	href in a DAV:reftarget property MAY be a relative URI. In both cases,
	the base URI to be used for resolving the relative URI to absolute form
	is the URI used in the HTTP message to identify the redirect reference
	resource to which the Ref-Target entity header or DAV:reftarget property
	belongs.
	In the case of a Ref-Target header, the base URI is constructed as
	follows: Its scheme component is "http", its authority component is the
	value of the Host header in the request, and its path component is the
	request-URI in the request. See Section 5 of [URI] for a discussion of
	relative URI references and how to resolve them.
	The DAV:reftarget property appears in the protocol in the context of a
	Multi-Status response, in a DAV:response element that contains a single
	DAV:href 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 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.
	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
	request, and the request-URI.
	12.1 Example: Resolving a Relative URI in Ref-Target
	>> Request:
	MKREF /north/inuvik HTTP/1.1
	Host: www.somehost.edu
	Ref-Target: <mapcollection/inuvik.gif>
	>> Response:		>> Response:
	HTTP/1.1 201 Created		HTTP/1.1 201 Created
	In this example, the base URI is http://www.somehost.edu/north/inuvik.		In this example, the base URI is http://www.somehost.edu/north/inuvik.
	Then, following the rules in [URI] Section 5, the relative URI in Ref-		Then, following the rules in [URI] Section 5, the relative URI in
	Target resolves to the absolute URI		DAV:reftarget resolves to the absolute URI
	http://www.somehost.edu/north/mapcollection/inuvik.gif.		http://www.somehost.edu/north/mapcollection/inuvik.gif.
	12.2 Example: Resolving a Relative URI in DAV:reftarget		9.2 Example: Resolving a Relative URI in a Multi-Status Response
	>> Request:		>> Request:
	PROPFIND /geog/ HTTP/1.1		PROPFIND /geog/ HTTP/1.1
	Host: www.xxsvr.com		Host: www.xxsvr.com
	Passthrough: F		Passthrough: F
	Depth: 1		Depth: 1
	Content-Type: text/xml		Content-Type: text/xml
	Content-Length: nnn		Content-Length: nnn
	skipping to change at line 1122		skipping to change at line 1049
	</D:response>		</D:response>
	</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 identified		returned as the value of reftarget for the reference resource identified
	by href /geog/stats.html. The href is itself a relative URI, which		by href /geog/stats.html. The href is itself a relative URI, which
	resolves to http://www.xxsrv.com/geog/stats.html. This is the base URI		resolves to http://www.xxsrv.com/geog/stats.html. This is the base URI
	for resolving the relative URI in reftarget. The absolute URI of		for resolving the relative URI in reftarget. The absolute URI of
	reftarget is http://www.xxsrv.com/geog/statistics/population/1997.html.		reftarget is http://www.xxsrv.com/geog/statistics/population/1997.html.
	13 Redirect References to Collections		10 Redirect References to Collections
	In a Request-URI /segment1/segment2/segment3, any of the three segments		In a Request-URI /segment1/segment2/segment3, any of the three segments
	may identify a redirect reference resource. (See [URI], Section 3.3,		may identify a redirect reference resource. (See [URI], Section 3.3,
	for definitions of "path" and "segment".) If any segment in a Request-		for definitions of "path" and "segment".) If any segment in a Request-
	URI identifies a redirect reference resource, the response is a 302.		URI identifies a redirect reference resource, the response is a 302.
	The value of the Location header in the 302 response is as follows:		The value of the Location header in the 302 response is as follows:
	The leftmost path segment of the request-URI that identifies a redirect		The leftmost path segment of the request-URI that identifies a redirect
	reference resource, together with all path segments and separators to		reference resource, together with all path segments and separators to
	the left of it, is replaced by the value of the redirect reference		the left of it, is replaced by the value of the redirect reference
	skipping to change at line 1160		skipping to change at line 1088
	In this case the client must follow up three separate 302 responses		In this case the client must follow up three separate 302 responses
	before finally reaching the target resource. The server responds to the		before finally reaching the target resource. The server responds to the
	initial request with a 302 with Location: /a/y/z.html, and the client		initial request with a 302 with Location: /a/y/z.html, and the client
	resubmits the request to /a/y/z.html. The server responds to this		resubmits the request to /a/y/z.html. The server responds to this
	request with a 302 with Location: /b/z.html, and the client resubmits		request with a 302 with Location: /b/z.html, and the client resubmits
	the request to /b/z.html. The server responds to this request with a		the request to /b/z.html. The server responds to this request with a
	302 with Location: /c/d.html, and the client resubmits the request to		302 with Location: /c/d.html, and the client resubmits the request to
	/c/d.html. This final request succeeds.		/c/d.html. This final request succeeds.
	14 Headers		11 Status Codes
	14.1 Ref-Target Entity Header
	Ref-Target = "Ref-Target" ":" Generic-Coded-url		11.1 509 Dangling References Forbidden
	Generic-Coded-url = "<" (absoluteURI | relativeURI) ">"		The server has a policy forbidding dangling references, and the request
	absoluteURI is defined in Section 3 of [URI].		would have created a dangling reference. For example, if there is no
	relativeURI is defined in Section 5 of [URI].		resource at the location specified by the DAV:reftarget property of a
			MKRESOURCE request, the request would create a dangling reference.
	The Ref-Target header is defined primarily for use with MKREF requests		12 Headers
	to identify the target resource of the new redirect reference resource
	being created.
	14.2 Resource-Type Entity Header		12.1 Redirect-Ref Response Header
	Resource-Type = "Resource-Type" ":" ("DAV:redirectref" |		Redirect-Ref = "Redirect-Ref:"
	ext-resource-type)
	ext-resource-type = coded-URL
	The Resource-Type header is defined primarily for use in 302 responses,		The Redirect-Ref header is used in all 302 responses from redirect
	to allow reference-aware clients to distinguish between HTTP 1.1		reference resources. Its presence informs reference-aware clients that
	redirects and 302 responses for redirect reference resources. The		the response is not a plain HTTP/1.1 redirect, but is a response from a
	possible values of this header are DAV:redirectref, and ext-resource-		redirect reference resource.
	type. The ext-resource-type production is provided for extensibility.
	14.3 Passthrough Request Header		12.2 Passthrough Request Header
	Passthrough = "Passthrough" ":" ("T" | "F")		Passthrough = "Passthrough" ":" ("T" | "F")
	The optional Passthrough header can be used on any request to a redirect		The optional Passthrough header can be used on any request to a redirect
	reference resource. If the Passthrough header has the value "F", the		reference resource. If the Passthrough header has the value "F", the
	request MUST be applied to the reference resource itself, and a 302		request MUST be applied to the reference resource itself, and a 302
	response MUST NOT be returned. If the Passthrough header has the value		response MUST NOT be returned. If the Passthrough header has the value
	"T", a 302 response MUST be returned, with the URI of the target		"T", a 302 response MUST be returned, with the URI of the target
	resource in the Location header and the Resource-Type header with a		resource in the Location header and the Redirect-Ref header.
	value "DAV:redirectref".
	If the Passthrough header is used on a request to any other sort of		If the Passthrough header is used on a request to any other sort of
	resource besides a reference resource, the server SHOULD ignore it. If		resource besides a reference resource, the server SHOULD ignore it. If
	the Passthrough header with the value "F" appears in a POST or		the Passthrough header with the value "F" appears in a POST or
	ORDERPATCH request to a reference resource, the server MUST respond with		ORDERPATCH request to a reference resource, the server MUST respond with
	a 400 (Bad Request).		a 400 (Bad Request).
	15 Properties		13 Properties
	15.1 reftarget Property		13.1 reftarget Property
	Name: reftarget		Name: reftarget
	Namespace: DAV:		Namespace: DAV:
	Purpose: A property of redirect reference resources that provides an		Purpose: A property of redirect reference resources that provides an
	efficient way for clients to discover the URI of the target		efficient way for clients to discover the URI of the target
	resource. This is a read-only property, whose value can		resource. This is a read-only property after its initial
	only be set by using the Ref-Target header with a MKREF		creation. Its value can only be set in a MKRESOURCE request.
	request.
	Value: href containing the URI of the target resource. This value		Value: href containing the URI of the target resource. This value
	MAY be a relative URI. The reftarget property can occur in		MAY be a relative URI. The reftarget property can occur in
	the entity bodies of responses to PROPFIND requests.		the entity bodies of MKRESOURCE requests and of responses to
			PROPFIND requests.
	<!ELEMENT reftarget href >		<!ELEMENT reftarget href >
	15.2 location Pseudo-Property		13.2 location Pseudo-Property
	Name: location		Name: location
	Namespace: DAV:		Namespace: DAV:
	Purpose: For use with 302 (Moved Temporarily) response codes in		Purpose: For use with 302 (Found) response codes in Multi-Status
	Multi-Status responses. It contains the absolute URI of the		responses. It contains the absolute URI of the temporary
	temporary location of the resource. In the context of		location of the resource. In the context of redirect
	redirect reference resources, this value is the absolute URI		reference resources, this value is the absolute URI of the
	of the target resource. It is analogous to the Location		target resource. It is analogous to the Location header in
	header in HTTP 302 responses defined in [HTTP] Section		HTTP 302 responses defined in [HTTP] Section 10.3.3 "302
	10.3.3 "302 Moved Temporarily." Including the location		Found." Including the location pseudo-property in a Multi-
	pseudo-property in a Multi-Status response requires an		Status response requires an extension to the syntax of the
	extension to the syntax of the DAV:response element defined		DAV:response element defined in [WebDAV], which is defined
	in [WebDAV], which is defined in Section 17 below. This		in Section 15 below. This pseudo-property is not expected
	pseudo-property is not expected to be stored on the		to be stored on the reference resource. It is modeled as a
	reference resource. It is modeled as a property only so that		property only so that it can be returned inside a DAV:prop
	it can be returned inside a DAV:prop element in a Multi-		element in a Multi-Status response.
	Status response.
	Value: href containing the absolute URI of the target resource.		Value: href containing the absolute URI of the target resource.
	<!ELEMENT location href >		<!ELEMENT location href >
	16 XML Elements		14 XML Elements
	16.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		specify that the resource type is a redirect reference
	resource.		resource.
	<!ELEMENT redirectref EMPTY >		<!ELEMENT redirectref EMPTY >
	17 Extensions to the DAV:response XML Element for Multi-Status Responses		15 Extensions to the DAV:response XML Element for Multi-Status Responses
	As described in Sections 6 and 9, the DAV:location pseudo-property and		As described in Sections 7 and 0, the DAV:location pseudo-property and
	the DAV:reftype property may be returned in the DAV:response element of		the DAV:reftype property may be returned in the DAV:response element of
	a 207 Multi-Status response, to allow clients to resubmit their requests		a 207 Multi-Status response, to allow clients to resubmit their requests
	to the target resource of a redirect reference resource.		to the target resource of a redirect reference resource.
	Whenever these properties are included in a Multi-Status response, they		Whenever these properties are included in a Multi-Status response, they
	are placed in a DAV:prop element associated with the href to which they		are placed in a DAV:prop element associated with the href to which they
	apply. This structure provides a framework for future extensions by		apply. This structure provides a framework for future extensions by
	other standards that may need to include additional properties in their		other standards that may need to include additional properties in their
	responses.		responses.
	Consequently, the definition of the DAV:response XML element changes to		Consequently, the definition of the DAV:response XML element changes to
	the following:		the following:
	<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)),		<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)),
	responsedescription?) >		responsedescription?) >
	18 Capability Discovery		16 Capability Discovery
	Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes		Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes
	with the DAV header in responses to OPTIONS, to indicate which parts of		with the DAV header in responses to OPTIONS, to indicate which parts of
	the Web Distributed Authoring protocols the resource supports. This		the Web Distributed Authoring protocols the resource supports. This
	specification defines an OPTIONAL extension to [WebDAV]. It defines a		specification defines an OPTIONAL extension to [WebDAV]. It defines a
	new compliance class, called redirectrefs, for use with the DAV header		new compliance class, called redirectrefs, for use with the DAV header
	in responses to OPTIONS requests. If a resource does support redirect		in responses to OPTIONS requests. If a resource does support redirect
	references, its response to an OPTIONS request MUST indicate that it		references, its response to an OPTIONS request MUST indicate that it
	does, by listing the new MKREF method as one it supports, and by listing		does, by listing the new redirectrefs compliance class in the DAV
	the new redirectrefs compliance class in the DAV header.		header. It MUST also list the MKRESOURCE method as one it supports.
	When responding to an OPTIONS request, any type of resource can include		When responding to an OPTIONS request, any type of resource can include
	redirectrefs in the value of the DAV header. Doing so indicates that		redirectrefs in the value of the DAV header. Doing so indicates that
	the server permits a redirect reference resource at the request URI.		the server permits a redirect reference resource at the request URI.
	18.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: somehost.org		HOST: somehost.org
	>> Response:		>> Response:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Date: Tue, 20 Jan 1998 20:52:29 GMT		Date: Tue, 20 Jan 1998 20:52:29 GMT
	Connection: close		Connection: close
	Accept-Ranges: none		Accept-Ranges: none
	Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,		Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,
	PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREF		PROPFIND, PROPPATCH, LOCK, UNLOCK, MKRESOURCE
	Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,		Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,
	PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH
			PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKRESOURCE, ORDERPATCH
	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 [WebDAV]. In addition, /somecollection/someresource supports		defined in [WebDAV]. In addition, /somecollection/someresource supports
	redirect reference resources. The Allow header indicates that MKREF		redirect reference resources. The Allow header indicates that
	requests can be submitted to /somecollection/someresource. The Public		MKRESOURCE requests can be submitted to /somecollection/someresource.
	header shows that other Request-URIs on the server support additional		The Public header shows that other Request-URIs on the server support
	methods.		additional methods.
	19 Security Considerations		17 Security Considerations
	This section is provided to make WebDAV applications aware of the		This section is provided to make WebDAV applications aware of the
	security implications of this protocol.		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 protocol		Distributed Authoring Protocol specification also apply to this protocol
	specification. In addition, redirect reference resources introduce		specification. In addition, redirect reference resources introduce
	several new security concerns and increase the risk of some existing		several new security concerns and increase the risk of some existing
	threats. These issues are detailed below.		threats. These issues are detailed below.
	19.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 information		possible for a hostile agent to induce users to send private information
	to a target on a different server. This risk is mitigated somewhat,		to a target on a different server. This risk is mitigated somewhat,
	since clients are required to notify the user of the redirection for any		since clients are required to notify the user of the redirection for any
	request other than GET or HEAD. (See [HTTP], Section 10.3.3 Moved		request other than GET or HEAD. (See [HTTP], Section 10.3.3 302 Found.)
	Temporarily.)
	19.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 MKREF method creates a new avenue for clients to		introduction of the MKRESOURCE method creates a new avenue for clients
	create loops accidentally or maliciously. If the reference resource and		to create loops accidentally or maliciously. If the reference resource
	its target are on the same server, the server may be able to detect		and its target are on the same server, the server may be able to detect
	MKREF requests that would create loops. See also [HTTP], Section 10.3		MKRESOURCE requests that would create loops. See also [HTTP], Section
	"Redirection 3xx."		10.3 "Redirection 3xx."
	19.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 MKREF creates a new avenue for similar denial of service		introduction of MKRESOURCE creates a new avenue for similar denial of
	attacks. Clients can now create redirect reference resources at heavily		service attacks. Clients can now create redirect reference resources at
	used sites to target locations that were not designed for heavy usage.		heavily used sites to target locations that were not designed for heavy
			usage.
	19.4 Private Locations May Be Revealed		17.4 Private Locations May Be Revealed
	There are several ways that redirect reference resources may reveal		There are several ways that redirect reference resources may reveal
	information about directory structures. First, the DAV:reftarget		information about directory 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 directory path that leads to the target resource. The		discover the directory path that leads to the target resource. The
	owner of the target resource may have wanted to limit knowledge of this		owner of the target resource may have wanted to limit knowledge of this
	directory structure.		directory structure.
	Sufficiently powerful access control mechanisms can control this risk to		Sufficiently powerful access control mechanisms can control this risk to
	some extent. Property-level access control could prevent users from		some extent. Property-level access control could prevent users from
	examining the DAV:reftarget property. (The Ref-Target and Location		examining the DAV:reftarget property. (The Location header returned in
	headers, which are returned in some responses to requests on redirect		responses to requests on redirect reference resources reveals the same
	reference resources, reveal the same information, however.) In some		information, however.) In some environments, the owner of a resource
	environments, the owner of a resource might be able to use access		might be able to use access control to prevent others from creating
	control to prevent others from creating references to that resource.		references to that resource.
	20 Internationalization Considerations		18 Internationalization Considerations
	This specification follows the practices of [WebDAV] in encoding all		This specification follows the practices of [WebDAV] in encoding all
	human-readable content using XML [XML] and in the treatment of names.		human-readable content using XML [XML] and in the treatment of names.
	Consequently, this specification complies with the IETF Character Set		Consequently, this specification complies with the IETF Character Set
	Policy [Alvestrand].		Policy [Alvestrand].
	WebDAV applications MUST support the character set tagging, character		WebDAV applications MUST support the character set tagging, character
	set encoding, and the language tagging functionality of the XML		set encoding, and the language tagging functionality of the XML
	specification. This constraint ensures that the human-readable content		specification. This constraint ensures that the human-readable content
	of this specification complies with [Alvestrand].		of this specification complies with [Alvestrand].
	skipping to change at line 1402		skipping to change at line 1323
	For error reporting, [WebDAV] follows the convention of HTTP/1.1 status		For error reporting, [WebDAV] follows the convention of HTTP/1.1 status
	codes, including with each status code a short, English description of		codes, including with each status code a short, English description of
	the code (e.g., 423 Locked). Internationalized applications will ignore		the code (e.g., 423 Locked). Internationalized applications will ignore
	this message, and display an appropriate message in the user's language		this message, and display an appropriate message in the user's language
	and character set.		and character set.
	For rationales for these decisions and advice for application		For rationales for these decisions and advice for application
	implementors, see [WebDAV].		implementors, see [WebDAV].
	21 IANA Considerations		19 IANA Considerations
	This document uses the namespaces defined by [WebDAV] for properties and		This document uses the namespaces defined by [WebDAV] for properties and
	XML elements. All other IANA considerations mentioned in [WebDAV] also		XML elements. All other IANA considerations mentioned in [WebDAV] also
	apply to this document.		apply to this document.
	22 Copyright		In addition, this document defines a new HTTP/1.1 status code, 509
			(Dangling References Forbidden) defined in Section 11.1.
			20 Copyright
	To be supplied by the RFC Editor.		To be supplied by the RFC Editor.
	23 Intellectual Property		21 Intellectual Property
	To be supplied by the RFC Editor.		To be supplied by the RFC Editor.
	24 Acknowledgements		22 Acknowledgements
	This draft has benefited from thoughtful discussion by Jim Amsden, Steve		This draft has benefited from thoughtful discussion by Jim Amsden, Steve
	Carter, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day,		Carter, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day,
	Rajiv Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred Hitt, Alex		Rajiv Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred Hitt, Alex
	Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare,		Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare,
	Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra		Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra
	Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John		Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John
	Stracke, John Tigue, John Turner, and others.		Stracke, John Tigue, John Turner, and others.
	25 References		23 References
	[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource		[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
	Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine,		Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine,
	Xerox. August, 1998.		Xerox. August, 1998.
	[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement		[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement
	Levels." RFC 2119, BCP 14. Harvard University. March, 1997.		Levels." RFC 2119, BCP 14. Harvard University. March, 1997.
	[XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup		[XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup
	Language (XML)." World Wide Web Consortium Recommendation REC-xml-		Language (XML)." World Wide Web Consortium Recommendation REC-xml-
	skipping to change at line 1457		skipping to change at line 1381
	[B] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.		[B] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.
	Crawford, T. Chihaya, "WebDAV Bindings." Internet Draft (work in		Crawford, T. Chihaya, "WebDAV Bindings." Internet Draft (work in
	progress) draft-ietf-webdav-binding-protocol-00. Xerox, UC Irvine,		progress) draft-ietf-webdav-binding-protocol-00. Xerox, UC Irvine,
	CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999.		CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999.
	[OC] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.		[OC] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.
	Crawford, T. Chihaya, "WebDAV Ordered Collections." Internet Draft (work		Crawford, T. Chihaya, "WebDAV Ordered Collections." Internet Draft (work
	in progress) draft-ietf-webdav-ordering-protocol-00. Xerox, UC Irvine,		in progress) draft-ietf-webdav-ordering-protocol-00. Xerox, UC Irvine,
	CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999.		CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999.
	26 Authors' Addresses		24 Authors' Addresses
	J. Slein		J. Slein
	Xerox Corporation		Xerox Corporation
	800 Phillips Road, 105-50C		800 Phillips Road, 105-50C
	Webster, NY 14580		Webster, NY 14580
	Email: jslein@crt.xerox.com		Email: jslein@crt.xerox.com
	E. J. Whitehead, Jr.		E. J. Whitehead, Jr.
	Dept. of Information and Computer Science		Dept. of Information and Computer Science
	University of California, Irvine		University of California, Irvine
	skipping to change at line 1499		skipping to change at line 1423
	J. Crawford		J. Crawford
	IBM		IBM
	Email: ccjason@us.ibm.com		Email: ccjason@us.ibm.com
	T. Chihaya		T. Chihaya
	DataChannel, Inc.		DataChannel, Inc.
	155 108th Ave. N.E., Suite 400		155 108th Ave. N.E., Suite 400
	Bellevue, WA 98004		Bellevue, WA 98004
	Email: Tyson@DataChannel.com		Email: Tyson@DataChannel.com
	27 Appendices		25 Appendices
	27.1 Appendix 1: Extensions to the WebDAV Document Type Definition		25.1 Appendix 1: Extensions to the WebDAV Document Type Definition
	<!--============= XML Elements from Section 16 ================-->		<!--============= XML Elements from Section 14 ================-->
	<!ELEMENT redirectref EMPTY >		<!ELEMENT redirectref EMPTY >
	<!--============= Property Elements from Section 15 =================-->		<!--============= Property Elements from Section 13 =================-->
	<!ELEMENT reftarget href>		<!ELEMENT reftarget href>
	<!ELEMENT location href>		<!ELEMENT location href>
	<!--====== Changes to the DAV:response Element from Section 17 ====-->		<!--====== Changes to the DAV:response Element from Section 15 ====-->
	<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)),		<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)),
	responsedescription?) >		responsedescription?) >
	Expires February 20, 2000		Expires April 15, 2000
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/