draft-ietf-webdav-redirectref-protocol-11.txt		draft-ietf-webdav-redirectref-protocol-12.txt
	WEBDAV Working Group J. Whitehead		WEBDAV Working Group J. Whitehead
	Internet-Draft U.C. Santa Cruz		Internet-Draft U.C. Santa Cruz
	Expires: August 13, 2005 G. Clemm		Expires: November 8, 2005 G. Clemm
	IBM		IBM
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	February 9, 2005		May 7, 2005
	Web Distributed Authoring and Versioning (WebDAV) Redirect Reference		Web Distributed Authoring and Versioning (WebDAV) Redirect Reference
	Resources		Resources
	draft-ietf-webdav-redirectref-protocol-11		draft-ietf-webdav-redirectref-protocol-12
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that any
	of Section 3 of RFC 3667. By submitting this Internet-Draft, each		applicable patent or other IPR claims of which he or she is aware
	author represents that any applicable patent or other IPR claims of		have been or will be disclosed, and any of which he or she becomes
	which he or she is aware have been or will be disclosed, and any of		aware will be disclosed, in accordance with Section 6 of BCP 79.
	which he or she become aware will be disclosed, in accordance with
	RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 13, 2005.		This Internet-Draft will expire on November 8, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This specification defines redirect reference resources. A redirect		This specification defines redirect reference resources. A redirect
	reference resource is a resource whose default response is an HTTP/		reference resource is a resource whose default response is an
	1.1 3xx (Redirection) status code (see RFC2616, Section 10.3),		HTTP/1.1 3xx (Redirection) status code (see RFC2616, Section 10.3),
	redirecting the client to a different resource, the target resource.		redirecting the client to a different resource, the target resource.
	A redirect reference makes it possible to access the target resource		A redirect reference makes it possible to access the target resource
	indirectly, through any URI mapped to the redirect reference		indirectly, through any URI mapped to the redirect reference
	resource. There are no integrity guarantees associated with redirect		resource. There are no integrity guarantees associated with redirect
	reference resources.		reference resources.
	Editorial Note (To be removed by RFC Editor before publication)		Editorial Note (To be removed by RFC Editor before publication)
	Distribution of this document is unlimited. Please send comments to		Distribution of this document is unlimited. Please send comments to
	the Distributed Authoring and Versioning (WebDAV) working group at		the Distributed Authoring and Versioning (WebDAV) working group at
	<mailto:w3c-dist-auth@w3.org>, which may be joined by sending a		<mailto:w3c-dist-auth@w3.org>, which may be joined by sending a
	skipping to change at page 3, line 20		skipping to change at page 3, line 20
	4. Overview of Redirect Reference Resources . . . . . . . . . . 7		4. Overview of Redirect Reference Resources . . . . . . . . . . 7
	5. Operations on Redirect Reference Resources . . . . . . . . . 8		5. Operations on Redirect Reference Resources . . . . . . . . . 8
	6. MKREDIRECTREF Method . . . . . . . . . . . . . . . . . . . . 8		6. MKREDIRECTREF Method . . . . . . . . . . . . . . . . . . . . 8
	6.1 Example: Creating a Redirect Reference Resource with		6.1 Example: Creating a Redirect Reference Resource with
	MKREDIRECTREF . . . . . . . . . . . . . . . . . . . . . . 10		MKREDIRECTREF . . . . . . . . . . . . . . . . . . . . . . 10
	7. UPDATEREDIRECTREF Method . . . . . . . . . . . . . . . . . . 10		7. UPDATEREDIRECTREF Method . . . . . . . . . . . . . . . . . . 10
	7.1 Example: Updating a Redirect Reference Resource with		7.1 Example: Updating a Redirect Reference Resource with
	UPDATEREDIRECTREF . . . . . . . . . . . . . . . . . . . . 12		UPDATEREDIRECTREF . . . . . . . . . . . . . . . . . . . . 12
	8. Operations on Collections That Contain Redirect Reference		8. Operations on Collections That Contain Redirect Reference
	Resources . . . . . . . . . . . . . . . . . . . . . . . . . 12		Resources . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1 LOCK on a Collection That Contains Redirect References . . 12		8.1 LOCK on a Collection That Contains Redirect References . . 13
	8.2 Example: PROPFIND on a Collection with Redirect		8.2 Example: PROPFIND on a Collection with Redirect
	Reference Resources . . . . . . . . . . . . . . . . . . . 13		Reference Resources . . . . . . . . . . . . . . . . . . . 13
	8.3 Example: PROPFIND with Apply-To-Redirect-Ref on a		8.3 Example: PROPFIND with Apply-To-Redirect-Ref on a
	Collection with Redirect Reference Resources . . . . . . . 15		Collection with Redirect Reference Resources . . . . . . . 15
	8.4 Example: COPY on a Collection That Contains a Redirect		8.4 Example: COPY on a Collection That Contains a Redirect
	Reference Resource . . . . . . . . . . . . . . . . . . . . 16		Reference Resource . . . . . . . . . . . . . . . . . . . . 16
	8.5 Example: LOCK on a Collection That Contains a Redirect		8.5 Example: LOCK on a Collection That Contains a Redirect
	Reference Resource . . . . . . . . . . . . . . . . . . . . 17		Reference Resource . . . . . . . . . . . . . . . . . . . . 17
	9. Operations on Targets of Redirect Reference Resources . . . 19		9. Operations on Targets of Redirect Reference Resources . . . 19
	10. Relative references in DAV:reftarget . . . . . . . . . . . . 19		10. Relative references in DAV:reftarget . . . . . . . . . . . . 19
	skipping to change at page 3, line 48		skipping to change at page 3, line 48
	13.1 DAV:redirect-lifetime (protected) . . . . . . . . . . . 22		13.1 DAV:redirect-lifetime (protected) . . . . . . . . . . . 22
	13.2 DAV:reftarget (protected) . . . . . . . . . . . . . . . 23		13.2 DAV:reftarget (protected) . . . . . . . . . . . . . . . 23
	14. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 23		14. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 23
	14.1 redirectref XML Element . . . . . . . . . . . . . . . . 23		14.1 redirectref XML Element . . . . . . . . . . . . . . . . 23
	15. Extensions to the DAV:response XML Element for		15. Extensions to the DAV:response XML Element for
	Multi-Status Responses . . . . . . . . . . . . . . . . . . . 23		Multi-Status Responses . . . . . . . . . . . . . . . . . . . 23
	16. Capability Discovery . . . . . . . . . . . . . . . . . . . . 23		16. Capability Discovery . . . . . . . . . . . . . . . . . . . . 23
	16.1 Example: Discovery of Support for Redirect Reference		16.1 Example: Discovery of Support for Redirect Reference
	Resources . . . . . . . . . . . . . . . . . . . . . . . 24		Resources . . . . . . . . . . . . . . . . . . . . . . . 24
	17. Security Considerations . . . . . . . . . . . . . . . . . . 24		17. Security Considerations . . . . . . . . . . . . . . . . . . 24
	17.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 25		17.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 24
	17.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . 25		17.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . 25
	17.3 Redirect Reference Resources and Denial of Service . . . 25		17.3 Redirect Reference Resources and Denial of Service . . . 25
	17.4 Revealing Private Locations . . . . . . . . . . . . . . 25		17.4 Revealing Private Locations . . . . . . . . . . . . . . 25
	18. Internationalization Considerations . . . . . . . . . . . . 25		18. Internationalization Considerations . . . . . . . . . . . . 25
	19. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26		19. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
	20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26		20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
	21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26		21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	22. Normative References . . . . . . . . . . . . . . . . . . . . 26		22. Normative References . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
	A. Changes to the WebDAV Document Type Definition . . . . . . . 27		A. Change Log (to be removed by RFC Editor before
	B. Change Log (to be removed by RFC Editor before		publication) . . . . . . . . . . . . . . . . . . . . . . . . 27
	publication) . . . . . . . . . . . . . . . . . . . . . . . . 28		A.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 27
	B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 28		A.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 27
	B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 28		A.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 28
	B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 28		A.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 28
	B.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 28		A.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 28
	B.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 28		A.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 28
	B.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 29		A.7 Since draft-ietf-webdav-redirectref-protocol-08 . . . . . 28
	B.7 Since draft-ietf-webdav-redirectref-protocol-08 . . . . . 29		A.8 Since draft-ietf-webdav-redirectref-protocol-09 . . . . . 29
	B.8 Since draft-ietf-webdav-redirectref-protocol-09 . . . . . 29		A.9 Since draft-ietf-webdav-redirectref-protocol-10 . . . . . 29
	B.9 Since draft-ietf-webdav-redirectref-protocol-10 . . . . . 29		A.10 Since draft-ietf-webdav-redirectref-protocol-11 . . . . 29
	C. Resolved issues (to be removed by RFC Editor before		B. Open issues (to be removed by RFC Editor prior to
	publication) . . . . . . . . . . . . . . . . . . . . . . . . 29		publication) . . . . . . . . . . . . . . . . . . . . . . . . 29
	C.1 abnf . . . . . . . . . . . . . . . . . . . . . . . . . . . 29		B.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	C.2 rfc2396bis . . . . . . . . . . . . . . . . . . . . . . . . 30		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	C.3 13_allprop . . . . . . . . . . . . . . . . . . . . . . . . 30		Intellectual Property and Copyright Statements . . . . . . . 32
	D. Open issues (to be removed by RFC Editor prior to
	publication) . . . . . . . . . . . . . . . . . . . . . . . . 30
	D.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	D.2 old_clients . . . . . . . . . . . . . . . . . . . . . . . 30
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	Intellectual Property and Copyright Statements . . . . . . . 34
	1. Introduction		1. Introduction
	This specification extends the Web Distributed Authoring Protocol		This specification extends the Web Distributed Authoring Protocol
	(WebDAV) to enable clients to create new access paths to existing		(WebDAV) to enable clients to create new access paths to existing
	resources. This capability is useful for several reasons:		resources. This capability is useful for several reasons:
	WebDAV makes it possible to organize HTTP resources into hierarchies,		WebDAV makes it possible to organize HTTP resources into hierarchies,
	placing them into groupings, known as collections, which are more		placing them into groupings, known as collections, which are more
	easily browsed and manipulated than a single flat collection.		easily browsed and manipulated than a single flat collection.
	skipping to change at page 6, line 24		skipping to change at page 6, line 24
	Sections 9 through 11 discuss several other issues raised by the		Sections 9 through 11 discuss several other issues raised by the
	existence of redirect reference resources. Sections 12 through 15		existence of redirect reference resources. Sections 12 through 15
	define the new headers, properties, and XML elements required to		define the new headers, properties, and XML elements required to
	support redirect reference resources. Section 16 discusses		support redirect reference resources. Section 16 discusses
	capability discovery. Sections 17 through 19 present the security,		capability discovery. Sections 17 through 19 present the security,
	internationalization, and IANA concerns raised by this specification.		internationalization, and IANA concerns raised by this specification.
	The remaining sections provide a variety of supporting information.		The remaining sections provide a variety of supporting information.
	2. Notational Conventions		2. Notational Conventions
			Since this document describes a set of extensions to the WebDAV
			Distributed Authoring Protocol [RFC2518], itself an extension to the
			HTTP/1.1 protocol, the augmented BNF used here to describe protocol
			elements is exactly the same as described in Section 2.1 of
			[RFC2616]. Since this augmented BNF uses the basic production rules
			provided in Section 2.2 of [RFC2616], 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].
	This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [RFC2234].
	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 [RFC2518]. Definitions		Distributed Authoring Protocol specification [RFC2518]. Definitions
	of the terms resource, Uniform Resource Identifier (URI), and Uniform		of the terms resource, Uniform Resource Identifier (URI), and Uniform
	Resource Locator (URL) are provided in [RFC3986].		Resource Locator (URL) are provided in [RFC3986].
	Redirect Reference Resource		Redirect Reference Resource
	A resource created to redirect all requests made to it, using an		A resource created to redirect all requests made to it, using an
	skipping to change at page 7, line 14		skipping to change at page 7, line 20
	This document uses the terms "precondition", "postcondition" and		This document uses the terms "precondition", "postcondition" and
	"protected property" as defined in [RFC3253]. Servers MUST report		"protected property" as defined in [RFC3253]. Servers MUST report
	pre-/postcondition failures as described in section 1.6 of this		pre-/postcondition failures as described in section 1.6 of this
	document.		document.
	4. Overview of Redirect Reference Resources		4. Overview of Redirect Reference Resources
	For all operations submitted to a redirect reference resource, the		For all operations submitted to a redirect reference resource, the
	default response is a 302 (Found), accompanied by the Redirect-Ref		default response is a 302 (Found), accompanied by the Redirect-Ref
	header (defined in Section 12.1 below) and the Location header set to		header (defined in Section 12.1 below) and the Location header
	the URI of the target resource. With this information, the client		([RFC2616], Section 14.30) set to the URI of the target resource.
	can resubmit the request to the URI of the target resource.		With this information, the client can resubmit the request to the URI
			of the target resource.
	A redirect reference resource never automatically forwards requests		A redirect reference resource never automatically forwards requests
	to its target resource. Redirect resources bring the same benefits		to its target resource. Redirect resources bring the same benefits
	as links in HTML documents. They can be created and maintained		as links in HTML documents. They can be created and maintained
	without the involvement or even knowledge of their target resource.		without the involvement or even knowledge of their target resource.
	This reduces the cost of linking between resources.		This reduces the cost of linking between resources.
	If the client is aware that it is operating on a redirect reference		If the client is aware that it is operating on a redirect reference
	resource, it can resolve the reference by retrieving the reference		resource, it can resolve the reference by retrieving the reference
	resource's DAV:reftarget property (defined in Section 13.2 below),		resource's DAV:reftarget property (defined in Section 13.2 below),
	skipping to change at page 8, line 17		skipping to change at page 8, line 23
	Although non-referencing-aware clients cannot create reference		Although non-referencing-aware clients cannot create reference
	resources, they should be able to submit requests through the		resources, they should be able to submit requests through the
	reference resources created by reference-aware WebDAV clients. They		reference resources created by reference-aware WebDAV clients. They
	should be able to follow any references to their targets. To make		should be able to follow any references to their targets. To make
	this possible, a server that receives any request made via a redirect		this possible, a server that receives any request made via a redirect
	reference resource MUST return a 3xx range (Redirection) status code,		reference resource MUST return a 3xx range (Redirection) status code,
	unless the request includes an Apply-To-Redirect-Ref header		unless the request includes an Apply-To-Redirect-Ref header
	specifying "T". The client and server MUST follow [RFC2616] Section		specifying "T". The client and server MUST follow [RFC2616] Section
	10.3, but with these additional rules:		10.3, but with these additional rules:
	o The Location response header MUST contain an absolute URI that		o The Location response header MUST contain an URI (see [RFC3986],
	identifies the target of the reference resource.		Section 3) that identifies the target of the reference resource.
	o The response MUST include the Redirect-Ref header. This header		o The response MUST include the Redirect-Ref header. This header
	allows reference-aware WebDAV clients to recognize the resource as		allows reference-aware WebDAV clients to recognize the resource as
	a reference resource and understand the reason for the		a reference resource and understand the reason for the
	redirection.		redirection.
	A reference-aware WebDAV client can, like a non-referencing client,		A reference-aware WebDAV client can, like a non-referencing client,
	resubmit the request to the URI in the Location header in order to		resubmit the request to the URI in the Location header in order to
	operate on the target resource. Alternatively, it can resubmit the		operate on the target resource. Alternatively, it can resubmit the
	request to the URI of the redirect reference resource with the		request to the URI of the redirect reference resource with the
	skipping to change at page 9, line 12		skipping to change at page 9, line 17
	The request body MUST be a DAV:mkredirectref XML element.		The request body MUST be a DAV:mkredirectref XML element.
	<!ELEMENT mkredirectref (reftarget, redirect-lifetime?)>		<!ELEMENT mkredirectref (reftarget, redirect-lifetime?)>
	<!ELEMENT reftarget (href)>		<!ELEMENT reftarget (href)>
	<!ELEMENT redirect-lifetime (permanent | temporary)>		<!ELEMENT redirect-lifetime (permanent | temporary)>
	<!ELEMENT permanent EMPTY>		<!ELEMENT permanent EMPTY>
	<!ELEMENT temporary EMPTY>		<!ELEMENT temporary EMPTY>
	The DAV:href element is defined in [RFC2518] (Section 12.3) and		The DAV:href element is defined in [RFC2518] (Section 12.3) and
	MUST contain either an absolute-URI or a relative-ref (without		MUST contain either an URI or a relative-ref (see [RFC3986],
	fragment), see [RFC3986], Sections 4.2 and 4.3).		Sections 3 and 4.2).
	If no DAV:redirect-lifetime element is specified, the server MUST		If no DAV:redirect-lifetime element is specified, the server MUST
	behave as if a value of DAV:temporary was specified.		behave as if a value of DAV:temporary was specified.
	If the request succeeds, the server MUST return 201 (Created)		If the request succeeds, the server MUST return 201 (Created)
	status.		status.
	If a response body for a successful request is included, it MUST		If a response body for a successful request is included, it MUST
	be a DAV:mkredirectref-response XML element. Note that this		be a DAV:mkredirectref-response XML element. Note that this
	document does not define any elements for the MKREDIRECTREF		document does not define any elements for the MKREDIRECTREF
	skipping to change at page 9, line 50		skipping to change at page 10, line 10
	(DAV:locked-update-allowed): If the collection identified by the		(DAV:locked-update-allowed): If the collection identified by the
	Request-URI minus the last path segment is write-locked, then the		Request-URI minus the last path segment is write-locked, then the
	appropriate token MUST be specified in an If request header.		appropriate token MUST be specified in an If request header.
	(DAV:redirect-lifetime-supported): If the request body contains a		(DAV:redirect-lifetime-supported): If the request body contains a
	DAV:redirect-lifetime element, the server MUST support the		DAV:redirect-lifetime element, the server MUST support the
	specified lifetime. Support for DAV:temporary is REQUIRED, while		specified lifetime. Support for DAV:temporary is REQUIRED, while
	support for DAV:permanent is OPTIONAL.		support for DAV:permanent is OPTIONAL.
			(DAV:legal-reftarget): The specified is a legal URI or relative-
			ref.
	Postconditions:		Postconditions:
	(DAV:new-redirectref): a new redirect reference resource is		(DAV:new-redirectref): a new redirect reference resource is
	created whose DAV:reftarget property has the value specified in		created whose DAV:reftarget property has the value specified in
	the request body.		the request body.
	6.1 Example: Creating a Redirect Reference Resource with MKREDIRECTREF		6.1 Example: Creating a Redirect Reference Resource with MKREDIRECTREF
	>> Request:		>> Request:
	skipping to change at page 11, line 41		skipping to change at page 11, line 50
	(DAV:must-be-redirectref): the resource identified by the Request-		(DAV:must-be-redirectref): the resource identified by the Request-
	URI must be a redirect reference resource as defined by this		URI must be a redirect reference resource as defined by this
	specification.		specification.
	(DAV:redirect-lifetime-supported): see Section 6.		(DAV:redirect-lifetime-supported): see Section 6.
	(DAV:redirect-lifetime-update-supported): servers MAY support		(DAV:redirect-lifetime-update-supported): servers MAY support
	changing the DAV:redirect-lifetime property; if they don't, this		changing the DAV:redirect-lifetime property; if they don't, this
	condition code can be used to signal failure.		condition code can be used to signal failure.
			(DAV:legal-reftarget): see Section 6.
	Postconditions:		Postconditions:
	(DAV:redirectref-updated): the DAV:reftarget and DAV:redirect-		(DAV:redirectref-updated): the DAV:reftarget and DAV:redirect-
	lifetime properties of the redirect reference have been updated		lifetime properties of the redirect reference have been updated
	accordingly.		accordingly.
	7.1 Example: Updating a Redirect Reference Resource with		7.1 Example: Updating a Redirect Reference Resource with
	UPDATEREDIRECTREF		UPDATEREDIRECTREF
	>> Request:		>> Request:
	skipping to change at page 22, line 15		skipping to change at page 22, line 15
	Note: the behavior described above may have a very serious impact		Note: the behavior described above may have a very serious impact
	on the efficiency of mapping Request-URIs to resources in HTTP		on the efficiency of mapping Request-URIs to resources in HTTP
	request processing. Therefore servers MAY respond with a 404		request processing. Therefore servers MAY respond with a 404
	status code if the cost of checking all leading path segments for		status code if the cost of checking all leading path segments for
	redirect references seems prohibitive.		redirect references seems prohibitive.
	12. Headers		12. Headers
	12.1 Redirect-Ref Response Header		12.1 Redirect-Ref Response Header
	Redirect-Ref = "Redirect-Ref:" (absolute-URI |		Redirect-Ref = "Redirect-Ref:" (URI | relative-ref)
	relative-part [ "?" query ])		; URI: see [RFC3986], Section 3
	; absolute-URI: see [RFC3986], section 4.3		; relative-ref: see [RFC3986], Section 4.2
	; query: see [RFC3986], section 3.4
	; relative-part: see [RFC3986], section 4.2
	The Redirect-Ref header is used in all 3xx responses from redirect		The Redirect-Ref header is used in all 3xx responses from redirect
	reference resources. The value is the link target as specified		reference resources. The value is the link target as specified
	during redirect reference resource creation.		during redirect reference resource creation.
	12.2 Apply-To-Redirect-Ref Request Header		12.2 Apply-To-Redirect-Ref Request Header
	Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F")		Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F")
	The optional Apply-To-Redirect-Ref header can be used on any request		The optional Apply-To-Redirect-Ref header can be used on any request
	skipping to change at page 26, line 34		skipping to change at page 26, line 33
	Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry		Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry
	Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen		Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen
	Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John		Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John
	Stracke, John Tigue, John Turner, Kevin Wiggen, and others.		Stracke, John Tigue, John Turner, Kevin Wiggen, and others.
	22. Normative References		22. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, November 1997.
	[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.		[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
	Jensen, "HTTP Extensions for Distributed Authoring --		Jensen, "HTTP Extensions for Distributed Authoring --
	WEBDAV", RFC 2518, February 1999.		WEBDAV", RFC 2518, February 1999.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.		[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
	Whitehead, "Versioning Extensions to WebDAV (Web		Whitehead, "Versioning Extensions to WebDAV (Web
	skipping to change at page 27, line 35		skipping to change at page 27, line 34
	greenbytes GmbH		greenbytes GmbH
	Salzmannstrasse 152		Salzmannstrasse 152
	Muenster, NW 48159		Muenster, NW 48159
	Germany		Germany
	Phone: +49 251 2807760		Phone: +49 251 2807760
	Fax: +49 251 2807761		Fax: +49 251 2807761
	Email: julian.reschke@greenbytes.de		Email: julian.reschke@greenbytes.de
	URI: http://greenbytes.de/tech/webdav/		URI: http://greenbytes.de/tech/webdav/
	Appendix A. Changes to the WebDAV Document Type Definition		Appendix A. Change Log (to be removed by RFC Editor before publication)
	<!-- Property Elements from Section 13 -->
	<!ELEMENT reftarget href>
	<!ELEMENT location href>
	<!-- XML Elements from Section 14 -->
	<!ELEMENT redirectref EMPTY >
	<!-- Changes to the DAV:response Element from Section 15 -->
	<!ELEMENT response (href, ((href*, status)|(propstat+)),
	responsedescription?, location?) >
	<!ELEMENT location (href) >
	Appendix B. Change Log (to be removed by RFC Editor before publication)
	B.1 Since draft-ietf-webdav-redirectref-protocol-02		A.1 Since draft-ietf-webdav-redirectref-protocol-02
	Julian Reschke takes editorial role (added to authors list). Cleanup		Julian Reschke takes editorial role (added to authors list). Cleanup
	XML indentation. Start adding all unresolved last call issues.		XML indentation. Start adding all unresolved last call issues.
	Update some author's contact information. Update references, split		Update some author's contact information. Update references, split
	into "normative" and "informational". Remove non-RFC2616 headers		into "normative" and "informational". Remove non-RFC2616 headers
	("Public") from examples. Fixed width problems in artwork. Start		("Public") from examples. Fixed width problems in artwork. Start
	resolving editorial issues.		resolving editorial issues.
	B.2 Since draft-ietf-webdav-redirectref-protocol-03		A.2 Since draft-ietf-webdav-redirectref-protocol-03
	Added Joe Orton and Juergen Reuter to Acknowledgements section.		Added Joe Orton and Juergen Reuter to Acknowledgements section.
	Close more editorial issues. Remove dependencies on BIND spec.		Close more editorial issues. Remove dependencies on BIND spec.
	B.3 Since draft-ietf-webdav-redirectref-protocol-04		A.3 Since draft-ietf-webdav-redirectref-protocol-04
	More editorial fixes. Clarify that MKRESOURCE can only be used to		More editorial fixes. Clarify that MKRESOURCE can only be used to
	create redirect references (switch to new method in a future draft).		create redirect references (switch to new method in a future draft).
	Clarify that redirect references do not have bodies.		Clarify that redirect references do not have bodies.
	B.4 Since draft-ietf-webdav-redirectref-protocol-05		A.4 Since draft-ietf-webdav-redirectref-protocol-05
	Close (accept) issue "lc-79-accesscontrol". Add issue "rfc2606-		Close (accept) issue "lc-79-accesscontrol". Add issue "rfc2606-
	compliance". Close issues "lc-50-blindredirect", "lc-71-relative",		compliance". Close issues "lc-50-blindredirect", "lc-71-relative",
	"lc-74-terminology". Update contact info for Geoff Clemm. Moved		"lc-74-terminology". Update contact info for Geoff Clemm. Moved
	some of the original authors names to new Contributors section. Add		some of the original authors names to new Contributors section. Add
	and close issue "9-MKRESOURCE-vs-relative-URI". Close issue "lc-72-		and close issue "9-MKRESOURCE-vs-relative-URI". Close issue "lc-72-
	trailingslash". Close issue "lc-60-ex". Update issue "lc-85-301"		trailingslash". Close issue "lc-60-ex". Update issue "lc-85-301"
	with proposal. Close issue "lc-06-reftarget-relative" (9-MKRESOURCE-		with proposal. Close issue "lc-06-reftarget-relative" (9-MKRESOURCE-
	vs-relative-URI was a duplicate of this one). Also remove section		vs-relative-URI was a duplicate of this one). Also remove section
	9.1 (example for MKRESOURCE vs relative URIs). Add and resolve issue		9.1 (example for MKRESOURCE vs relative URIs). Add and resolve issue
	"11.2-apply-to-redirect-ref-syntax" (header now has values "T" and		"11.2-apply-to-redirect-ref-syntax" (header now has values "T" and
	"F"). Also some cleanup for "rfc2606-compliance". Typo fixes. Add		"F"). Also some cleanup for "rfc2606-compliance". Typo fixes. Add
	and resolve "15.1-options-response".		and resolve "15.1-options-response".
	B.5 Since draft-ietf-webdav-redirectref-protocol-06		A.5 Since draft-ietf-webdav-redirectref-protocol-06
	Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang", "lc-		Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang", "lc-
	44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move", "lc-80-i18n"		44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move", "lc-80-i18n"
	and "rfc2606-compliance". Start work on index. Add new issue		and "rfc2606-compliance". Start work on index. Add new issue
	"old_clients".		"old_clients".
	B.6 Since draft-ietf-webdav-redirectref-protocol-07		A.6 Since draft-ietf-webdav-redirectref-protocol-07
	Closed issue "lc-38-not-hierarchical". Cleaned up DTD fragments in		Closed issue "lc-38-not-hierarchical". Cleaned up DTD fragments in
	appendix. Close (reject) issues "lc-55-iana" and "lc-41-no-webdav".		appendix. Close (reject) issues "lc-55-iana" and "lc-41-no-webdav".
	Add issue "5_mkresource" and start work on MKREDIRECTREF (issue		Add issue "5_mkresource" and start work on MKREDIRECTREF (issue
	closed, but more work on MKREDIRECTREF needs to be done for updates		closed, but more work on MKREDIRECTREF needs to be done for updates
	and status codes other than 302). Start resolution of "lc-85-301",		and status codes other than 302). Start resolution of "lc-85-301",
	replacing "302" by more generic language. Update issue "lc-57-		replacing "302" by more generic language. Update issue "lc-57-
	noautoupdate". Close issue "lc-37-integrity" (duplicate of "lc-57-		noautoupdate". Close issue "lc-37-integrity" (duplicate of "lc-57-
	autoupdate"). Started work on "lc-85-301". Add L. Dusseault and S.		autoupdate"). Started work on "lc-85-301". Add L. Dusseault and S.
	Eissing to Acknowledgments section.		Eissing to Acknowledgments section.
	B.7 Since draft-ietf-webdav-redirectref-protocol-08		A.7 Since draft-ietf-webdav-redirectref-protocol-08
	Fix index entries for conditions. Open and resolve issue		Fix index entries for conditions. Open and resolve issue
	"specify_safeness". Rewrite editorial section and parts of intro.		"specify_safeness". Rewrite editorial section and parts of intro.
	Add more clarifications for issue "lc-85-301" and close it.		Add more clarifications for issue "lc-85-301" and close it.
	B.8 Since draft-ietf-webdav-redirectref-protocol-09		A.8 Since draft-ietf-webdav-redirectref-protocol-09
	Resolve issues "lc-33-forwarding", "lc-36-server" and "lc-57-		Resolve issues "lc-33-forwarding", "lc-36-server" and "lc-57-
	noautoupdate". Close issues "lc-48-s6", "12.1-property-name", "3-		noautoupdate". Close issues "lc-48-s6", "12.1-property-name",
	terminology-redirectref" and "lc-58-update". Rearrange section 5 and		"3-terminology-redirectref" and "lc-58-update". Rearrange section 5
	6. Add some more terms to index (no change tracking).		and 6. Add some more terms to index (no change tracking).
	B.9 Since draft-ietf-webdav-redirectref-protocol-10		A.9 Since draft-ietf-webdav-redirectref-protocol-10
	Add and resolve issues "13_allprop" and "rfc2396bis". Use the term		Add and resolve issues "13_allprop" and "rfc2396bis". Use the term
	"Request-URI" throughout (this is what RFC2616 defines). Center some		"Request-URI" throughout (this is what RFC2616 defines). Center some
	of the artwork. Add and resolve issue "abnf".		of the artwork. Add and resolve issue "abnf".
	Appendix C. Resolved issues (to be removed by RFC Editor before		A.10 Since draft-ietf-webdav-redirectref-protocol-11
	publication)
	Issues that were either rejected or resolved in this version of this
	document.
	C.1 abnf
	Type: change
	julian.reschke@greenbytes.de (2005-02-09): Use ABNF syntax from
	RFC2234.
	Resolution (2005-02-09): Done.
	C.2 rfc2396bis
	Type: change
	julian.reschke@greenbytes.de (2004-10-22): Update to RFC2396bis (this
	needs to be done carefully because we are using the term "relative
	URI reference" which does not exist in RFC2396bis anymore).
	Resolution (2005-01-25): Agreed (draft-rfc2396bis has been published
	as RFC3986).
	C.3 13_allprop
	Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/
	0051.html>
	julian.reschke@greenbytes.de (2004-11-13): Make the spec consistent
	with RFC3253, RFC3648 and RFC3744 (new properties not returned upon
	PROPFIND/allprop requests).
	Resolution (2004-11-13): Add statement about PROPFIND/allprop		Re-open and close issue "anbf" (implied LWS). Raise and close issue
	behaviour.		"frag_in_target". Add precondition name for legal reftarget element
			contents. Enhance index. Add and close issue "dtd-changes".
	Appendix D. Open issues (to be removed by RFC Editor prior to		Appendix B. Open issues (to be removed by RFC Editor prior to
	publication)		publication)
	D.1 edit		B.1 edit
	Type: edit		Type: edit
	julian.reschke@greenbytes.de (2004-10-03): Umbrella issue for		julian.reschke@greenbytes.de (2004-10-03): Umbrella issue for
	editorial changes.		editorial changes.
	D.2 old_clients
	Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/
	0180.html>
	julian.reschke@greenbytes.de (2003-11-10): There are (at least) two
	major design goals, but unfortunately both are in direct
	contradiction: #1: Maximum consistency with HTTP/1.1 (RFC2616). This
	means that any request that addresses a redirect reference resource
	MUST result in a 3xx status code (obviously the whole point is that
	GET MUST result in a redirection, and if it does, it's hard to say
	why other methods such as PUT or DELETE should behave differently).
	Therefore, the redirect reference protocol introduces a new request
	header ("Apply-To-Redirect-Ref") through which a client can indicate
	that the request indeed should be applied to the redirect reference
	resource itself. #2: Maximum usability with existing clients. For
	instance, the Microsoft Webfolder client will not be able to DELETE a
	redirect reference resource unless the server deviates from #1.
	Right now I'm not sure about the best way to resolve this. Currently
	the spec chooses #1 (back when this decision was made, there was
	probably the assumption that existing clients would quickly be
	updated -- something that probably isn't true today). However this
	may result in implementers either just ignoring these rules, or
	adding special workarounds based on "User Agent" detection.
	Index		Index
	A		A
	Apply-To-Redirect-Ref header 22		Apply-To-Redirect-Ref header 22
	C		C
	Condition Names		Condition Names
			DAV:legal-reftarget (pre) 10-11
	DAV:locked-update-allowed (pre) 9, 11		DAV:locked-update-allowed (pre) 9, 11
	DAV:must-be-redirectref (pre) 11		DAV:must-be-redirectref (pre) 11
	DAV:name-allowed (pre) 9		DAV:name-allowed (pre) 9
	DAV:new-redirectref (post) 10		DAV:new-redirectref (post) 10
	DAV:parent-resource-must-be-non-null (pre) 9		DAV:parent-resource-must-be-non-null (pre) 9
	DAV:redirect-lifetime-supported (pre) 9, 11		DAV:redirect-lifetime-supported (pre) 10-11
	DAV:redirect-lifetime-update-supported (pre) 11		DAV:redirect-lifetime-update-supported (pre) 11
	DAV:redirectref-updated (post) 11		DAV:redirectref-updated (post) 12
	DAV:resource-must-be-null (pre) 9		DAV:resource-must-be-null (pre) 9
	D		D
	DAV header		DAV header
	compliance class 'redirectrefs' 23		compliance class 'redirectrefs' 23
			DAV:legal-reftarget precondition 10-11
	DAV:locked-update-allowed precondition 9, 11		DAV:locked-update-allowed precondition 9, 11
			DAV:mkdirectref XML element 9
			DAV:mkredirectref-response XML element 9
	DAV:must-be-redirectref precondition 11		DAV:must-be-redirectref precondition 11
	DAV:name-allowed precondition 9		DAV:name-allowed precondition 9
	DAV:new-redirectref postcondition 10		DAV:new-redirectref postcondition 10
	DAV:parent-resource-must-be-non-null precondition 9		DAV:parent-resource-must-be-non-null precondition 9
			DAV:permanent XML element 9, 22
	DAV:redirect-lifetime property 22		DAV:redirect-lifetime property 22
	DAV:redirect-lifetime-supported precondition 9, 11		DAV:redirect-lifetime XML element 9, 22
			DAV:redirect-lifetime-supported precondition 10-11
	DAV:redirect-lifetime-update-supported precondition 11		DAV:redirect-lifetime-update-supported precondition 11
	DAV:redirectref resource type 23		DAV:redirectref resource type 23
	DAV:redirectref-updated postcondition 11		DAV:redirectref-updated postcondition 12
	DAV:reftarget property 23		DAV:reftarget property 23
			DAV:reftarget XML element 9
	DAV:resource-must-be-null precondition 9		DAV:resource-must-be-null precondition 9
			DAV:temporary XML element 9, 22
			DAV:updateredirectref-response XML element 11
	H		H
	Headers		Headers
	Apply-To-Redirect-Ref 22		Apply-To-Redirect-Ref 22
	Redirect-Ref 22		Redirect-Ref 22
	M		M
	Methods		Methods
	MKREDIRECTREF 8		MKREDIRECTREF 8
	UPDATEREDIRECTREF 10		UPDATEREDIRECTREF 10
	skipping to change at page 33, line 9		skipping to change at page 31, line 18
	N		N
	Non-Reference Resource 6		Non-Reference Resource 6
	P		P
	Properties		Properties
	DAV:redirect-lifetime 22		DAV:redirect-lifetime 22
	DAV:reftarget 23		DAV:reftarget 23
	R		R
			Redirect Reference Resource 6
	Redirect-Ref header 22		Redirect-Ref header 22
	Rediret Reference Resource 6
	Resource Types		Resource Types
	DAV:redirectref 23		DAV:redirectref 23
	T		T
	Target Resource 6		Target Resource 7
	U		U
	UPDATEREDIRECTREF method 10		UPDATEREDIRECTREF method 10
			X
			XML elements
			DAV:mkdirectref 9
			DAV:mkredirectref-response 9
			DAV:permanent 9, 22
			DAV:redirect-lifetime 9, 22
			DAV:reftarget 9
			DAV:temporary 9, 22
			DAV:updateredirectref-response 11
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/