| draft-ietf-httpbis-p7-auth-00.txt |  | draft-ietf-httpbis-p7-auth-01.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2068, 2616 J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| (if approved) One Laptop per Child |  | Updates: 2617 (if approved) One Laptop per Child |
| Updates: 2617 (if approved) J. Mogul |  | Intended status: Standards Track J. Mogul |
| Intended status: Standards Track HP |  | Expires: July 15, 2008 HP |
| Expires: June 22, 2008 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 |
| December 20, 2007 |  | Y. Lafon, Ed. |
|  |  | W3C |
|  |  | J. Reschke, Ed. |
|  |  | greenbytes |
|  |  | January 12, 2008 |
| HTTP/1.1, part 7: Authentication |  | HTTP/1.1, part 7: Authentication |
| draft-ietf-httpbis-p7-auth-00 |  | draft-ietf-httpbis-p7-auth-01 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | By submitting this Internet-Draft, each author represents that any |
| applicable patent or other IPR claims of which he or she is aware |  | applicable patent or other IPR claims of which he or she is aware |
| have been or will be disclosed, and any of which he or she becomes |  | have been or will be disclosed, and any of which he or she becomes |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that |
| skipping to change at page 1, line 45 |  | skipping to change at page 1, line 49 |
| 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 June 22, 2008. |  | This Internet-Draft will expire on July 15, 2008. |
| Copyright Notice |  | Copyright Notice |
| Copyright (C) The IETF Trust (2007). |  | Copyright (C) The IETF Trust (2008). |
| 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) |
| This version of the HTTP specification contains only minimal |  |  |
| editorial changes from [RFC2616] (abstract, introductory paragraph, |  |  |
| and authors' addresses). All other changes are due to partitioning |  |  |
| the original into seven mostly independent parts. The intent is for |  |  |
| readers of future drafts to able to use draft 00 as the basis for |  |  |
| comparison when the WG makes later changes to the specification text. |  |  |
| This draft will shortly be followed by draft 01 (containing the first |  |  |
| round of changes that have already been agreed to on the mailing |  |  |
| list). There is no point in reviewing this draft other than to |  |  |
| verify that the partitioning has been done correctly. Roy T. |  |  |
| Fielding, Yves Lafon, and Julian Reschke will be the editors after |  |  |
| draft 00 is submitted. |  |  |
| 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://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related |  | at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://www3.tools.ietf.org/wg/httpbis/>. |  | <http://www.tools.ietf.org/wg/httpbis/>. |
|  |  | This draft incorporates those issue resolutions that were either |
|  |  | collected in the original RFC2616 errata list |
|  |  | (<http://purl.org/NET/http-errata>), or which were agreed upon on the |
|  |  | mailing list between October 2006 and November 2007 (as published in |
|  |  | "draft-lafon-rfc2616bis-03"). |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
|  |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 2. Status Code Definitions . . . . . . . . . . . . . . . . . . . 4 |  | 2. Status Code Definitions . . . . . . . . . . . . . . . . . . . 4 |
| 2.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 4 |  | 2.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 4 |
| 2.2. 407 Proxy Authentication Required . . . . . . . . . . . . 4 |  | 2.2. 407 Proxy Authentication Required . . . . . . . . . . . . 5 |
| 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 5 |  | 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 5 |
| 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 5 |  | 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 5 |
| 3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 6 |  | 3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 6 |
| 3.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 6 |  | 3.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 6 |
| 3.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 6 |  | 3.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7 |
| 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 |  | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 |
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 |  | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 |
| 5.1. Authentication Credentials and Idle Clients . . . . . . . 7 |  | 5.1. Authentication Credentials and Idle Clients . . . . . . . 7 |
| 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 11 |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 9 |
|  |  | A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 9 |
|  |  | Appendix B. Change Log (to be removed by RFC Editor before |
|  |  | publication) . . . . . . . . . . . . . . . . . . . . 9 |
|  |  | B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 9 |
|  |  | B.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 9 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 |
|  |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 13 |
| 1. Introduction |  | 1. Introduction |
| This document will define aspects of HTTP related to access control |  | This document defines HTTP/1.1 access control and authentication. |
| and authentication. Right now it only includes the extracted |  | Right now it includes the extracted relevant sections of RFC 2616 |
| relevant sections of RFC 2616 [RFC2616] with only minor edits. |  | with only minor changes. The intention is to move the general |
|  |  | framework for HTTP authentication here, as currently specified in |
|  |  | [RFC2617], and allow the individual authentication mechanisms to be |
|  |  | defined elsewhere. This introduction will be rewritten when that |
|  |  | occurs. |
| HTTP provides several OPTIONAL challenge-response authentication |  | HTTP provides several OPTIONAL challenge-response authentication |
| mechanisms which can be used by a server to challenge a client |  | mechanisms which can be used by a server to challenge a client |
| request and by a client to provide authentication information. The |  | request and by a client to provide authentication information. The |
| general framework for access authentication, and the specification of |  | general framework for access authentication, and the specification of |
| "basic" and "digest" authentication, are specified in "HTTP |  | "basic" and "digest" authentication, are specified in "HTTP |
| Authentication: Basic and Digest Access Authentication" [RFC2617]. |  | Authentication: Basic and Digest Access Authentication" [RFC2617]. |
| 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 |
|  |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
|  |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
|  |  | document are to be interpreted as described in [RFC2119]. |
|  |  | An implementation is not compliant if it fails to satisfy one or more |
|  |  | of the MUST or REQUIRED level requirements for the protocols it |
|  |  | implements. An implementation that satisfies all the MUST or |
|  |  | REQUIRED level and all the SHOULD level requirements for its |
|  |  | protocols is said to be "unconditionally compliant"; one that |
|  |  | satisfies all the MUST level requirements but not all the SHOULD |
|  |  | level requirements for its protocols is said to be "conditionally |
|  |  | compliant." |
| 2. Status Code Definitions |  | 2. Status Code Definitions |
| 2.1. 401 Unauthorized |  | 2.1. 401 Unauthorized |
| The request requires user authentication. The response MUST include |  | The request requires user authentication. The response MUST include |
| a WWW-Authenticate header field (Section 3.4) containing a challenge |  | a WWW-Authenticate header field (Section 3.4) containing a challenge |
| applicable to the requested resource. The client MAY repeat the |  | applicable to the requested resource. The client MAY repeat the |
| request with a suitable Authorization header field (Section 3.1). If |  | request with a suitable Authorization header field (Section 3.1). If |
| the request already included Authorization credentials, then the 401 |  | the request already included Authorization credentials, then the 401 |
| response indicates that authorization has been refused for those |  | response indicates that authorization has been refused for those |
| skipping to change at page 5, line 7 |  | skipping to change at page 5, line 22 |
| client must first authenticate itself with the proxy. The proxy MUST |  | client must first authenticate itself with the proxy. The proxy MUST |
| return a Proxy-Authenticate header field (Section 3.2) containing a |  | return a Proxy-Authenticate header field (Section 3.2) containing a |
| challenge applicable to the proxy for the requested resource. The |  | challenge applicable to the proxy for the requested resource. The |
| client MAY repeat the request with a suitable Proxy-Authorization |  | client MAY repeat the request with a suitable Proxy-Authorization |
| header field (Section 3.3). HTTP access authentication is explained |  | header field (Section 3.3). HTTP access authentication is explained |
| in "HTTP Authentication: Basic and Digest Access Authentication" |  | in "HTTP Authentication: Basic and Digest Access Authentication" |
| [RFC2617]. |  | [RFC2617]. |
| 3. Header Field Definitions |  | 3. Header Field Definitions |
| This section defines the syntax and semantics of all standard |  | This section defines the syntax and semantics of HTTP/1.1 header |
| HTTP/1.1 header fields. For entity-header fields, both sender and |  | fields related to authentication. |
| recipient refer to either the client or the server, depending on who |  |  |
| sends and who receives the entity. |  |  |
| 3.1. Authorization |  | 3.1. Authorization |
| A user agent that wishes to authenticate itself with a server-- |  | A user agent that wishes to authenticate itself with a server-- |
| usually, but not necessarily, after receiving a 401 response--does so |  | usually, but not necessarily, after receiving a 401 response--does so |
| by including an Authorization request-header field with the request. |  | by including an Authorization request-header field with the request. |
| The Authorization field value consists of credentials containing the |  | The Authorization field value consists of credentials containing the |
| authentication information of the user agent for the realm of the |  | authentication information of the user agent for the realm of the |
| resource being requested. |  | resource being requested. |
| Authorization = "Authorization" ":" credentials |  | Authorization = "Authorization" ":" credentials |
| HTTP access authentication is described in "HTTP Authentication: |  | HTTP access authentication is described in "HTTP Authentication: |
| Basic and Digest Access Authentication" [RFC2617]. If a request is |  | Basic and Digest Access Authentication" [RFC2617]. If a request is |
| authenticated and a realm specified, the same credentials SHOULD be |  | authenticated and a realm specified, the same credentials SHOULD be |
| valid for all other requests within this realm (assuming that the |  | valid for all other requests within this realm (assuming that the |
| authentication scheme itself does not require otherwise, such as |  | authentication scheme itself does not require otherwise, such as |
| credentials that vary according to a challenge value or using |  | credentials that vary according to a challenge value or using |
| synchronized clocks). |  | synchronized clocks). |
| When a shared cache (see Section 2.7 of [Part6]) receives a request |  | When a shared cache (see Section 8 of [Part6]) receives a request |
| containing an Authorization field, it MUST NOT return the |  | containing an Authorization field, it MUST NOT return the |
| corresponding response as a reply to any other request, unless one of |  | corresponding response as a reply to any other request, unless one of |
| the following specific exceptions holds: |  | the following specific exceptions holds: |
| 1. If the response includes the "s-maxage" cache-control directive, |  | 1. If the response includes the "s-maxage" cache-control directive, |
| the cache MAY use that response in replying to a subsequent |  | the cache MAY use that response in replying to a subsequent |
| request. But (if the specified maximum age has passed) a proxy |  | request. But (if the specified maximum age has passed) a proxy |
| cache MUST first revalidate it with the origin server, using the |  | cache MUST first revalidate it with the origin server, using the |
| 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. (This is the defined behavior |  | to authenticate the new request. (This is the defined behavior |
| skipping to change at page 7, line 30 |  | skipping to change at page 7, line 46 |
| This section is meant to inform application developers, information |  | This section is meant to inform application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| described by this document. The discussion does not include |  | described by this document. The discussion does not include |
| definitive solutions to the problems revealed, though it does make |  | definitive solutions to the problems revealed, though it does make |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| 5.1. Authentication Credentials and Idle Clients |  | 5.1. Authentication Credentials and Idle Clients |
| Existing HTTP clients and user agents typically retain authentication |  | Existing HTTP clients and user agents typically retain authentication |
| information indefinitely. HTTP/1.1. does not provide a method for a |  | information indefinitely. HTTP/1.1 does not provide a method for a |
| server to direct clients to discard these cached credentials. This |  | server to direct clients to discard these cached credentials. This |
| is a significant defect that requires further extensions to HTTP. |  | is a significant defect that requires further extensions to HTTP. |
| Circumstances under which credential caching can interfere with the |  | Circumstances under which credential caching can interfere with the |
| application's security model include but are not limited to: |  | application's security model include but are not limited to: |
| o Clients which have been idle for an extended period following |  | o Clients which have been idle for an extended period following |
| which the server might wish to cause the client to reprompt the |  | which the server might wish to cause the client to reprompt the |
| user for credentials. |  | user for credentials. |
| o Applications which include a session termination indication (such |  | o Applications which include a session termination indication (such |
| skipping to change at page 8, line 8 |  | skipping to change at page 8, line 25 |
| This is currently under separate study. There are a number of work- |  | This is currently under separate study. There are a number of work- |
| arounds to parts of this problem, and we encourage the use of |  | arounds to parts of this problem, and we encourage the use of |
| password protection in screen savers, idle time-outs, and other |  | password protection in screen savers, idle time-outs, and other |
| methods which mitigate the security problems inherent in this |  | methods which mitigate the security problems inherent in this |
| problem. In particular, user agents which cache credentials are |  | problem. In particular, user agents which cache credentials are |
| encouraged to provide a readily accessible mechanism for discarding |  | encouraged to provide a readily accessible mechanism for discarding |
| cached credentials under user control. |  | cached credentials under user control. |
| 6. Acknowledgments |  | 6. Acknowledgments |
| Based on an XML translation of RFC 2616 by Julian Reschke. |  | TBD. |
| 7. References |  | 7. References |
|  |  | 7.1. Normative References |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| progress), December 2007. |  | draft-ietf-httpbis-p6-cache-01 (work in progress), |
|  |  | January 2008. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  |  |
| [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. |
|  |  | 7.2. Informative References |
|  |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
|  |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
|  |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
|  |  | Appendix A. Compatibility with Previous Versions |
|  |  | A.1. Changes from RFC 2616 |
|  |  | Appendix B. Change Log (to be removed by RFC Editor before publication) |
|  |  | B.1. Since RFC2616 |
|  |  | Extracted relevant partitions from [RFC2616]. |
|  |  | B.2. Since draft-ietf-httpbis-p7-auth-00 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative |
|  |  | and Informative references" |
| Index |  | Index |
| 4 |  | 4 |
| 401 Unauthorized (status code) 4 |  | 401 Unauthorized (status code) 4 |
| 407 Proxy Authentication Required (status code) 4 |  | 407 Proxy Authentication Required (status code) 5 |
| A |  | A |
| Authorization header 5 |  | Authorization header 5 |
| G |  | G |
| Grammar |  | Grammar |
| Authorization 5 |  | Authorization 5 |
| Proxy-Authenticate 6 |  | Proxy-Authenticate 6 |
| Proxy-Authorization 6 |  | Proxy-Authorization 6 |
| WWW-Authenticate 7 |  | WWW-Authenticate 7 |
| H |  | H |
| Headers |  | Headers |
| Authorization 5 |  | Authorization 5 |
| Proxy-Authenticate 6 |  | Proxy-Authenticate 6 |
| Proxy-Authorization 6 |  | Proxy-Authorization 6 |
| WWW-Authenticate 6 |  | WWW-Authenticate 7 |
| P |  | P |
| Proxy-Authenticate header 6 |  | Proxy-Authenticate header 6 |
| Proxy-Authorization header 6 |  | Proxy-Authorization header 6 |
| S |  | S |
| Status Codes |  | Status Codes |
| 401 Unauthorized 4 |  | 401 Unauthorized 4 |
| 407 Proxy Authentication Required 4 |  | 407 Proxy Authentication Required 5 |
| W |  | W |
| WWW-Authenticate header 6 |  | WWW-Authenticate header 7 |
| 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 |
| skipping to change at page 11, line 4 |  | skipping to change at page 12, line 4 |
| 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) |
|  |  | World Wide Web Consortium |
|  |  | W3C / ERCIM |
|  |  | 2004, rte des Lucioles |
|  |  | Sophia-Antipolis, AM 06902 |
|  |  | France |
|  |  | Email: ylafon@w3.org |
|  |  | URI: http://www.raubacapeu.net/people/yves/ |
|  |  | Julian F. Reschke (editor) |
|  |  | greenbytes GmbH |
|  |  | Hafenweg 16 |
|  |  | Muenster, NW 48155 |
|  |  | Germany |
|  |  | Phone: +49 251 2807760 |
|  |  | Fax: +49 251 2807761 |
|  |  | Email: julian.reschke@greenbytes.de |
|  |  | URI: http://greenbytes.de/tech/webdav/ |
| Full Copyright Statement |  | Full Copyright Statement |
| Copyright (C) The IETF Trust (2007). |  | Copyright (C) The IETF Trust (2008). |
| This document is subject to the rights, licenses and restrictions |  | This document is subject to the rights, licenses and restrictions |
| contained in BCP 78, and except as set forth therein, the authors |  | contained in BCP 78, and except as set forth therein, the authors |
| retain all their rights. |  | retain all their rights. |
| This document and the information contained herein are provided on an |  | This document and the information contained herein are provided on an |
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |  | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |  | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |
| THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |  | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |
| OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |  | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |
End of changes. 28 change blocks.
| 50 lines changed or deleted |  | 119 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/