| draft-ietf-httpbis-p4-conditional-03.txt |  | draft-ietf-httpbis-p4-conditional-04.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network 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 |
| Intended status: Standards Track One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Expires: December 19, 2008 J. Mogul |  | Expires: March 2, 2009 J. Mogul |
| HP |  | 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 |
| June 17, 2008 |  | August 29, 2008 |
| HTTP/1.1, part 4: Conditional Requests |  | HTTP/1.1, part 4: Conditional Requests |
| draft-ietf-httpbis-p4-conditional-03 |  | draft-ietf-httpbis-p4-conditional-04 |
| 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 49 |  | 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 December 19, 2008. |  | This Internet-Draft will expire on March 2, 2009. |
| 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 4 of the |  | information initiative since 1990. This document is Part 4 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 4 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines |
| request header fields for indicating conditional requests and the |  | request header fields for indicating conditional requests and the |
| skipping to change at page 3, line 18 |  | skipping to change at page 3, line 18 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 |  | 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 |
| 3. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 3. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |  | 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |
| 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5 |  | 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5 |
| 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6 |  | 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6 |
| 5. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 6 |  | 5. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 6 |
| 6. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 |  | 6. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 |
| 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 |  | 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 |
| 7.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 7.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 7.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 7.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 7.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 |  | 7.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 |
| 7.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 |  | 7.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 |
| 7.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 15 |  | 7.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 |
| 7.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16 |  | 7.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16 |
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 |  | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 |
| 8.1. Message Header Registration . . . . . . . . . . . . . . . 17 |  | 8.1. Message Header Registration . . . . . . . . . . . . . . . 17 |
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 |  | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 |
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 |  | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 |
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 |  | 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 |
| Appendix A. Compatibility with Previous Versions . . . . . . . . 18 |  | Appendix A. Compatibility with Previous Versions . . . . . . . . 18 |
| A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18 |  | A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18 |
| Appendix B. Change Log (to be removed by RFC Editor before |  | Appendix B. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 19 |  | publication) . . . . . . . . . . . . . . . . . . . . 19 |
| B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19 |  | B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19 |
| B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 19 |  | B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 19 |
| B.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 19 |  | B.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 19 |
| B.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 19 |  | B.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 19 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | B.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 19 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
|  |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 24 |  | Intellectual Property and Copyright Statements . . . . . . . . . . 24 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 response metadata for indicating |  | This document defines HTTP/1.1 response metadata for indicating |
| potential changes to payload content, including modification time |  | potential changes to payload content, including modification time |
| stamps and opaque entity-tags, and the HTTP conditional request |  | stamps and opaque entity-tags, and the HTTP conditional request |
| mechanisms that allow preconditions to be placed on a request method. |  | mechanisms that allow preconditions to be placed on a request method. |
| Conditional GET requests allow for efficient cache updates. Other |  | Conditional GET requests allow for efficient cache updates. Other |
| conditional request methods are used to protect against overwriting |  | conditional request methods are used to protect against overwriting |
| skipping to change at page 6, line 5 |  | skipping to change at page 6, line 5 |
| 4.1. 304 Not Modified |  | 4.1. 304 Not Modified |
| If the client has performed a conditional GET request and access is |  | If the client has performed a conditional GET request and access is |
| allowed, but the document has not been modified, the server SHOULD |  | allowed, but the document has not been modified, the server SHOULD |
| respond with this status code. The 304 response MUST NOT contain a |  | respond with this status code. The 304 response MUST NOT contain a |
| message-body, and thus is always terminated by the first empty line |  | message-body, and thus is always terminated by the first empty line |
| after the header fields. |  | after the header fields. |
| The response MUST include the following header fields: |  | The response MUST include the following header fields: |
| o Date, unless its omission is required by Section 8.3.1 of [Part1] |  | o Date, unless its omission is required by Section 8.3.1 of [Part1]. |
| If a clockless origin server obeys these rules, and proxies and |  | If a clockless origin server obeys these rules, and proxies and |
| clients add their own Date to any response received without one (as |  | clients add their own Date to any response received without one |
| already specified by [RFC2068], Section 14.19), caches will operate |  | (as already specified by Section 8.3 of [Part1], caches will |
| correctly. |  | operate correctly. |
| o ETag and/or Content-Location, if the header would have been sent |  | o ETag and/or Content-Location, if the header would have been sent |
| in a 200 response to the same request |  | in a 200 response to the same request. |
| o Expires, Cache-Control, and/or Vary, if the field-value might |  | o Expires, Cache-Control, and/or Vary, if the field-value might |
| differ from that sent in any previous response for the same |  | differ from that sent in any previous response for the same |
| variant |  | variant. |
| If the conditional GET used a strong cache validator (see Section 5), |  | If the conditional GET used a strong cache validator (see Section 5), |
| the response SHOULD NOT include other entity-headers. Otherwise |  | the response SHOULD NOT include other entity-headers. Otherwise |
| (i.e., the conditional GET used a weak validator), the response MUST |  | (i.e., the conditional GET used a weak validator), the response MUST |
| NOT include other entity-headers; this prevents inconsistencies |  | NOT include other entity-headers; this prevents inconsistencies |
| between cached entity-bodies and updated headers. |  | between cached entity-bodies and updated headers. |
| If a 304 response indicates an entity not currently cached, then the |  | If a 304 response indicates an entity not currently cached, then the |
| cache MUST disregard the response and repeat the request without the |  | cache MUST disregard the response and repeat the request without the |
| conditional. |  | conditional. |
| skipping to change at page 7, line 47 |  | skipping to change at page 7, line 47 |
| range retrieval, since otherwise the client might end up with an |  | range retrieval, since otherwise the client might end up with an |
| internally inconsistent entity. |  | internally inconsistent entity. |
| Clients MUST NOT use weak validators in range requests ([Part5]). |  | Clients MUST NOT use weak validators in range requests ([Part5]). |
| The only function that HTTP/1.1 defines on validators is comparison. |  | The only function that HTTP/1.1 defines on validators is comparison. |
| There are two validator comparison functions, depending on whether |  | There are two validator comparison functions, depending on whether |
| the comparison context allows the use of weak validators or not: |  | the comparison context allows the use of weak validators or not: |
| o The strong comparison function: in order to be considered equal, |  | o The strong comparison function: in order to be considered equal, |
| both validators MUST be identical in every way, and both MUST NOT |  | both opaque-tags MUST be identical character-by-character, and |
| be weak. |  | both MUST NOT be weak. |
| o The weak comparison function: in order to be considered equal, |  | o The weak comparison function: in order to be considered equal, |
| both validators MUST be identical in every way, but either or both |  | both opaque-tags MUST be identical character-by-character. |
| of them MAY be tagged as "weak" without affecting the result. |  |  |
|  |  | The example below shows the results for a set of entity tag pairs, |
|  |  | and both the weak and strong comparison function results: |
|  |  | +--------+--------+-------------------+-----------------+ |
|  |  | | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | |
|  |  | +--------+--------+-------------------+-----------------+ |
|  |  | | W/"1" | W/"1" | no match | match | |
|  |  | | W/"1" | W/"2" | no match | no match | |
|  |  | | W/"1" | "1" | no match | match | |
|  |  | | "1" | "1" | match | match | |
|  |  | +--------+--------+-------------------+-----------------+ |
| An entity tag is strong unless it is explicitly tagged as weak. |  | An entity tag is strong unless it is explicitly tagged as weak. |
| Section 3 gives the syntax for entity tags. |  | Section 3 gives the syntax for entity tags. |
| A Last-Modified time, when used as a validator in a request, is |  | A Last-Modified time, when used as a validator in a request, is |
| implicitly weak unless it is possible to deduce that it is strong, |  | implicitly weak unless it is possible to deduce that it is strong, |
| using the following rules: |  | using the following rules: |
| o The validator is being compared by an origin server to the actual |  | o The validator is being compared by an origin server to the actual |
| current validator for the entity and, |  | current validator for the entity and, |
| skipping to change at page 9, line 42 |  | skipping to change at page 10, line 4 |
| o SHOULD send a Last-Modified value if it is feasible to send one, |  | o SHOULD send a Last-Modified value if it is feasible to send one, |
| unless the risk of a breakdown in semantic transparency that could |  | unless the risk of a breakdown in semantic transparency that could |
| result from using this date in an If-Modified-Since header would |  | result from using this date in an If-Modified-Since header would |
| lead to serious problems. |  | lead to serious problems. |
| In other words, the preferred behavior for an HTTP/1.1 origin server |  | In other words, the preferred behavior for an HTTP/1.1 origin server |
| is to send both a strong entity tag and a Last-Modified value. |  | is to send both a strong entity tag and a Last-Modified value. |
| In order to be legal, a strong entity tag MUST change whenever the |  | In order to be legal, a strong entity tag MUST change whenever the |
| associated entity value changes in any way. A weak entity tag SHOULD |  | associated entity changes in any way. A weak entity tag SHOULD |
| change whenever the associated entity changes in a semantically |  | change whenever the associated entity changes in a semantically |
| significant way. |  | significant way. |
| Note: in order to provide semantically transparent caching, an |  | Note: in order to provide semantically transparent caching, an |
| origin server must avoid reusing a specific strong entity tag |  | origin server must avoid reusing a specific strong entity tag |
| value for two different entities, or reusing a specific weak |  | value for two different entities, or reusing a specific weak |
| entity tag value for two semantically different entities. Cache |  | entity tag value for two semantically different entities. Cache |
| entries might persist for arbitrarily long periods, regardless of |  | entries might persist for arbitrarily long periods, regardless of |
| expiration times, so it might be inappropriate to expect that a |  | expiration times, so it might be inappropriate to expect that a |
| cache will never again attempt to validate an entry using a |  | cache will never again attempt to validate an entry using a |
| skipping to change at page 18, line 10 |  | skipping to change at page 18, line 14 |
| 10. Acknowledgments |  | 10. Acknowledgments |
| 11. References |  | 11. References |
| 11.1. Normative References |  | 11.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-03 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-04 |
| (work in progress), June 2008. |  | (work in progress), August 2008. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] 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 5: Range Requests and |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| Partial Responses", draft-ietf-httpbis-p5-range-03 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-04 (work |
| in progress), June 2008. |  | in progress), August 2008. |
| [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., |
| and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-03 (work in progress), |  | draft-ietf-httpbis-p6-cache-04 (work in progress), |
| June 2008. |  | August 2008. |
| [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. |
| 11.2. Informative References |  | 11.2. Informative References |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |  |  |
| Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |  |  |
| RFC 2068, January 1997. |  |  |
| [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. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
| Appendix A. Compatibility with Previous Versions |  | Appendix A. Compatibility with Previous Versions |
| skipping to change at page 19, line 43 |  | skipping to change at page 19, line 43 |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak |
| ETags on non-GET requests" |  | ETags on non-GET requests" |
| Ongoing work on IANA Message Header Registration |  | Ongoing work on IANA Message Header Registration |
| (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>): |  | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>): |
| o Reference RFC 3984, and update header registrations for headers |  | o Reference RFC 3984, and update header registrations for headers |
| defined in this document. |  | defined in this document. |
|  |  | B.5. Since draft-ietf-httpbis-p4-conditional-03 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples |
|  |  | for ETag matching" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity |
|  |  | value' undefined" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus |
|  |  | 2068 Date header reference" |
| Index |  | Index |
| 3 |  | 3 |
| 304 Not Modified (status code) 5 |  | 304 Not Modified (status code) 5 |
| 4 |  | 4 |
| 412 Precondition Failed (status code) 6 |  | 412 Precondition Failed (status code) 6 |
| E |  | E |
| ETag header 11 |  | ETag header 11 |
| G |  | G |
| Grammar |  | Grammar |
| entity-tag 5 |  | entity-tag 5 |
| ETag 11 |  | ETag 11 |
| If-Match 12 |  | If-Match 12 |
| If-Modified-Since 13 |  | If-Modified-Since 13 |
| If-None-Match 14 |  | If-None-Match 15 |
| If-Unmodified-Since 16 |  | If-Unmodified-Since 16 |
| Last-Modified 16 |  | Last-Modified 16 |
| opaque-tag 5 |  | opaque-tag 5 |
| weak 5 |  | weak 5 |
| H |  | H |
| Headers |  | Headers |
| ETag 11 |  | ETag 11 |
| If-Match 11 |  | If-Match 12 |
| If-Modified-Since 13 |  | If-Modified-Since 13 |
| If-None-Match 14 |  | If-None-Match 14 |
| If-Unmodified-Since 15 |  | If-Unmodified-Since 16 |
| Last-Modified 16 |  | Last-Modified 16 |
| I |  | I |
| If-Match header 11 |  | If-Match header 12 |
| If-Modified-Since header 13 |  | If-Modified-Since header 13 |
| If-None-Match header 14 |  | If-None-Match header 14 |
| If-Unmodified-Since header 15 |  | If-Unmodified-Since header 16 |
| L |  | L |
| Last-Modified header 16 |  | Last-Modified header 16 |
| S |  | S |
| Status Codes |  | Status Codes |
| 304 Not Modified 5 |  | 304 Not Modified 5 |
| 412 Precondition Failed 6 |  | 412 Precondition Failed 6 |
| Authors' Addresses |  | Authors' Addresses |
End of changes. 25 change blocks.
| 35 lines changed or deleted |  | 55 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/