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/ |