draft-ietf-httpbis-p7-auth-09.txt		draft-ietf-httpbis-p7-auth-10.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Updates: 2617 (if approved) One Laptop per Child		Updates: 2617 (if approved) Alcatel-Lucent
	Intended status: Standards Track J. Mogul		Intended status: Standards Track J. Mogul
	Expires: September 9, 2010 HP		Expires: January 13, 2011 HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	March 8, 2010		July 12, 2010
	HTTP/1.1, part 7: Authentication		HTTP/1.1, part 7: Authentication
	draft-ietf-httpbis-p7-auth-09		draft-ietf-httpbis-p7-auth-10
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 7 of the		information initiative since 1990. This document is Part 7 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines
	HTTP Authentication.		HTTP Authentication.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is		group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related		at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.10.		The changes in this draft are summarized in Appendix C.11.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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		This Internet-Draft will expire on January 13, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	skipping to change at page 3, line 32		skipping to change at page 3, line 32
	4.1. Status Code Registration . . . . . . . . . . . . . . . . . 8		4.1. Status Code Registration . . . . . . . . . . . . . . . . . 8
	4.2. Message Header Registration . . . . . . . . . . . . . . . 8		4.2. Message Header Registration . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	5.1. Authentication Credentials and Idle Clients . . . . . . . 9		5.1. Authentication Credentials and Idle Clients . . . . . . . 9
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Appendix A. Compatibility with Previous Versions . . . . . . . . 10		Appendix A. Compatibility with Previous Versions . . . . . . . . 10
	A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 10		A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 10
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 11		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 10
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 11		publication) . . . . . . . . . . . . . . . . . . . . 11
	C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 11		C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 11
	C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 11		C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 11
	C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 11		C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 11
	C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 12		C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 11
	C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 12		C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 11
	C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 12		C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 11
	C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 12		C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 12
	C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 12		C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 12
	C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 12		C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 12
	C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 13		C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 12
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		C.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 access control and authentication.		This document defines HTTP/1.1 access control and authentication.
	Right now it includes the extracted relevant sections of RFC 2616		Right now it includes the extracted relevant sections of RFC 2616
	with only minor changes. The intention is to move the general		with only minor changes. The intention is to move the general
	framework for HTTP authentication here, as currently specified in		framework for HTTP authentication here, as currently specified in
	[RFC2617], and allow the individual authentication mechanisms to be		[RFC2617], and allow the individual authentication mechanisms to be
	defined elsewhere. This introduction will be rewritten when that		defined elsewhere. This introduction will be rewritten when that
	occurs.		occurs.
	skipping to change at page 4, line 31		skipping to change at page 4, line 31
	This specification adopts the definitions of "challenge" and		This specification adopts the definitions of "challenge" and
	"credentials" from that specification.		"credentials" from that specification.
	1.1. Requirements		1.1. Requirements
	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].
	An implementation is not compliant if it fails to satisfy one or more		An implementation is not compliant if it fails to satisfy one or more
	of the MUST or REQUIRED level requirements for the protocols it		of the "MUST" or "REQUIRED" level requirements for the protocols it
	implements. An implementation that satisfies all the MUST or		implements. An implementation that satisfies all the "MUST" or
	REQUIRED level and all the SHOULD level requirements for its		"REQUIRED" level and all the "SHOULD" level requirements for its
	protocols is said to be "unconditionally compliant"; one that		protocols is said to be "unconditionally compliant"; one that
	satisfies all the MUST level requirements but not all the SHOULD		satisfies all the "MUST" level requirements but not all the "SHOULD"
	level requirements for its protocols is said to be "conditionally		level requirements for its protocols is said to be "conditionally
	compliant."		compliant".
	1.2. Syntax Notation		1.2. Syntax Notation
	This specification uses the ABNF syntax defined in Section 1.2 of		This specification uses the ABNF syntax defined in Section 1.2 of
	[Part1] (which extends the syntax defined in [RFC5234] with a list		[Part1] (which extends the syntax defined in [RFC5234] with a list
	rule). Appendix B shows the collected ABNF, with the list rule		rule). Appendix B shows the collected ABNF, with the list rule
	expanded.		expanded.
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	skipping to change at page 6, line 52		skipping to change at page 6, line 52
	request-headers from the new request to allow the origin server		request-headers from the new request to allow the origin server
	to authenticate the new request.		to authenticate the new request.
	3. If the response includes the "public" cache-control directive, it		3. If the response includes the "public" cache-control directive, it
	MAY be returned in reply to any subsequent request.		MAY be returned in reply to any subsequent request.
	3.2. Proxy-Authenticate		3.2. Proxy-Authenticate
	The "Proxy-Authenticate" response-header field consists of a		The "Proxy-Authenticate" response-header field consists of a
	challenge that indicates the authentication scheme and parameters		challenge that indicates the authentication scheme and parameters
	applicable to the proxy for this request-target. It MUST be included		applicable to the proxy for this Effective Request URI (Section 4.3
	as part of a 407 (Proxy Authentication Required) response.		of [Part1]). It MUST be included as part of a 407 (Proxy
			Authentication Required) response.
	Proxy-Authenticate = "Proxy-Authenticate" ":" OWS		Proxy-Authenticate = "Proxy-Authenticate" ":" OWS
	Proxy-Authenticate-v		Proxy-Authenticate-v
	Proxy-Authenticate-v = 1#challenge		Proxy-Authenticate-v = 1#challenge
	The HTTP access authentication process is described in "HTTP		The HTTP access authentication process is described in "HTTP
	Authentication: Basic and Digest Access Authentication" [RFC2617].		Authentication: Basic and Digest Access Authentication" [RFC2617].
	Unlike WWW-Authenticate, the Proxy-Authenticate header field applies		Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
	only to the current connection and SHOULD NOT be passed on to		only to the current connection and SHOULD NOT be passed on to
	downstream clients. However, an intermediate proxy might need to		downstream clients. However, an intermediate proxy might need to
	skipping to change at page 7, line 46		skipping to change at page 7, line 47
	chain, the Proxy-Authorization header field is consumed by the first		chain, the Proxy-Authorization header field is consumed by the first
	outbound proxy that was expecting to receive credentials. A proxy		outbound proxy that was expecting to receive credentials. A proxy
	MAY relay the credentials from the client request to the next proxy		MAY relay the credentials from the client request to the next proxy
	if that is the mechanism by which the proxies cooperatively		if that is the mechanism by which the proxies cooperatively
	authenticate a given request.		authenticate a given request.
	3.4. WWW-Authenticate		3.4. WWW-Authenticate
	The "WWW-Authenticate" response-header field consists of at least one		The "WWW-Authenticate" response-header field consists of at least one
	challenge that indicates the authentication scheme(s) and parameters		challenge that indicates the authentication scheme(s) and parameters
	applicable to the request-target. It MUST be included in 401		applicable to the Effective Request URI (Section 4.3 of [Part1]). It
	(Unauthorized) response messages.		MUST be included in 401 (Unauthorized) response messages.
	WWW-Authenticate = "WWW-Authenticate" ":" OWS WWW-Authenticate-v		WWW-Authenticate = "WWW-Authenticate" ":" OWS WWW-Authenticate-v
	WWW-Authenticate-v = 1#challenge		WWW-Authenticate-v = 1#challenge
	The HTTP access authentication process is described in "HTTP		The HTTP access authentication process is described in "HTTP
	Authentication: Basic and Digest Access Authentication" [RFC2617].		Authentication: Basic and Digest Access Authentication" [RFC2617].
	User agents are advised to take special care in parsing the WWW-		User agents are advised to take special care in parsing the WWW-
	Authenticate field value as it might contain more than one challenge,		Authenticate field value as it might contain more than one challenge,
	or if more than one WWW-Authenticate header field is provided, the		or if more than one WWW-Authenticate header field is provided, the
	contents of a challenge itself can contain a comma-separated list of		contents of a challenge itself can contain a comma-separated list of
	skipping to change at page 9, line 44		skipping to change at page 9, line 42
	[[acks: TBD.]]		[[acks: TBD.]]
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-09		and Message Parsing", draft-ietf-httpbis-p1-messaging-10
	(work in progress), March 2010.		(work in progress), July 2010.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part		Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
	6: Caching", draft-ietf-httpbis-p6-cache-09 (work in		6: Caching", draft-ietf-httpbis-p6-cache-10 (work in
	progress), March 2010.		progress), July 2010.
	[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.
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,		[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP		Leach, P., Luotonen, A., and L. Stewart, "HTTP
	Authentication: Basic and Digest Access Authentication",		Authentication: Basic and Digest Access Authentication",
	RFC 2617, June 1999.		RFC 2617, June 1999.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	skipping to change at page 13, line 9		skipping to change at page 12, line 34
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA		o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
	registrations for optional status codes"		registrations for optional status codes"
	C.10. Since draft-ietf-httpbis-p7-auth-08		C.10. Since draft-ietf-httpbis-p7-auth-08
	No significant changes.		No significant changes.
			C.11. Since draft-ietf-httpbis-p7-auth-09
			Partly resolved issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
			requested resource's URI"
	Index		Index
	4		4
	401 Unauthorized (status code) 5		401 Unauthorized (status code) 5
	407 Proxy Authentication Required (status code) 5		407 Proxy Authentication Required (status code) 5
	A		A
	Authorization header 6		Authorization header 6
	G		G
	skipping to change at page 14, line 15		skipping to change at page 13, line 43
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Day Software		Day Software
	23 Corporate Plaza DR, Suite 280		23 Corporate Plaza DR, Suite 280
	Newport Beach, CA 92660		Newport Beach, CA 92660
	USA		USA
	Phone: +1-949-706-5300		Phone: +1-949-706-5300
	Fax: +1-949-706-5305		Fax: +1-949-706-5305
	Email: fielding@gbiv.com		EMail: fielding@gbiv.com
	URI: http://roy.gbiv.com/		URI: http://roy.gbiv.com/
	Jim Gettys		Jim Gettys
	One Laptop per Child		Alcatel-Lucent Bell Labs
	21 Oak Knoll Road		21 Oak Knoll Road
	Carlisle, MA 01741		Carlisle, MA 01741
	USA		USA
	Email: jg@laptop.org		EMail: jg@freedesktop.org
	URI: http://www.laptop.org/		URI: http://gettys.wordpress.com/
	Jeffrey C. Mogul		Jeffrey C. Mogul
	Hewlett-Packard Company		Hewlett-Packard Company
	HP Labs, Large Scale Systems Group		HP Labs, Large Scale Systems Group
	1501 Page Mill Road, MS 1177		1501 Page Mill Road, MS 1177
	Palo Alto, CA 94304		Palo Alto, CA 94304
	USA		USA
	Email: JeffMogul@acm.org		EMail: JeffMogul@acm.org
	Henrik Frystyk Nielsen		Henrik Frystyk Nielsen
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	USA		USA
	Email: henrikn@microsoft.com		EMail: henrikn@microsoft.com
	Larry Masinter		Larry Masinter
	Adobe Systems, Incorporated		Adobe Systems, Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	Email: LMM@acm.org		EMail: LMM@acm.org
	URI: http://larry.masinter.net/		URI: http://larry.masinter.net/
	Paul J. Leach		Paul J. Leach
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	Email: paulle@microsoft.com		EMail: paulle@microsoft.com
	Tim Berners-Lee		Tim Berners-Lee
	World Wide Web Consortium		World Wide Web Consortium
	MIT Computer Science and Artificial Intelligence Laboratory		MIT Computer Science and Artificial Intelligence Laboratory
	The Stata Center, Building 32		The Stata Center, Building 32
	32 Vassar Street		32 Vassar Street
	Cambridge, MA 02139		Cambridge, MA 02139
	USA		USA
	Email: timbl@w3.org		EMail: timbl@w3.org
	URI: http://www.w3.org/People/Berners-Lee/		URI: http://www.w3.org/People/Berners-Lee/
	Yves Lafon (editor)		Yves Lafon (editor)
	World Wide Web Consortium		World Wide Web Consortium
	W3C / ERCIM		W3C / ERCIM
	2004, rte des Lucioles		2004, rte des Lucioles
	Sophia-Antipolis, AM 06902		Sophia-Antipolis, AM 06902
	France		France
	Email: ylafon@w3.org		EMail: ylafon@w3.org
	URI: http://www.raubacapeu.net/people/yves/		URI: http://www.raubacapeu.net/people/yves/
	Julian F. Reschke (editor)		Julian F. Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster, NW 48155		Muenster, NW 48155
	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/
End of changes. 34 change blocks.
	52 lines changed or deleted		54 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/