
INTRODUCTION, paragraph 1:
OLD:

 HTTPbis Working Group                                   R. Fielding, Ed.
 Internet-Draft                                                     Adobe
 Obsoletes: 2616 (if approved)                         M. Nottingham, Ed.
 Intended status: Standards Track                                  Akamai
 Expires: December 8, 2014                                J. Reschke, Ed.
                                                               greenbytes
                                                             June 6, 2014

NEW:

 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
 Request for Comments: 7234                                         Adobe
 Obsoletes: 2616                                       M. Nottingham, Ed.
 Category: Standards Track                                         Akamai
 ISSN: 2070-1721                                          J. Reschke, Ed.
                                                               greenbytes
                                                                June 2014


INTRODUCTION, paragraph 2:
OLD:

             Hypertext Transfer Protocol (HTTP/1.1): Caching
                    draft-ietf-httpbis-p6-cache-latest

NEW:

             Hypertext Transfer Protocol (HTTP/1.1): Caching


INTRODUCTION, paragraph 5:
OLD:

 Editorial Note (To be removed by RFC Editor)
 
    Discussion of this draft takes place on the HTTPBIS working group
    mailing list (ietf-http-wg@w3.org), which is archived at
    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
 
    The current issues list is at
    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
    documents (including fancy diffs) can be found at
    <http://tools.ietf.org/wg/httpbis/>.
 
    _This is a temporary document for the purpose of tracking the
    editorial changes made during the AUTH48 (RFC publication) phase._
 
 Status of This Memo

NEW:

 Status of This Memo


INTRODUCTION, paragraph 6:
OLD:

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

NEW:

    This is an Internet Standards Track document.


INTRODUCTION, paragraph 7:
OLD:

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.

NEW:

    This document is a product of the Internet Engineering Task Force
    (IETF).  It represents the consensus of the IETF community.  It has
    received public review and has been approved for publication by the
    Internet Engineering Steering Group (IESG).  Further information on
    Internet Standards is available in Section 2 of RFC 5741.


INTRODUCTION, paragraph 8:
OLD:

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
    This Internet-Draft will expire on December 8, 2014.

NEW:

    Information about the current status of this document, any errata,
    and how to provide feedback on it may be obtained at
    http://www.rfc-editor.org/info/rfc7234.


INTRODUCTION, paragraph 14:
OLD:

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
        1.2.1.  Delta Seconds  . . . . . . . . . . . . . . . . . . . .  5
    2.  Overview of Cache Operation  . . . . . . . . . . . . . . . . .  5
    3.  Storing Responses in Caches  . . . . . . . . . . . . . . . . .  6
      3.1.  Storing Incomplete Responses . . . . . . . . . . . . . . .  7
      3.2.  Storing Responses to Authenticated Requests  . . . . . . .  7
      3.3.  Combining Partial Content  . . . . . . . . . . . . . . . .  8
    4.  Constructing Responses from Caches . . . . . . . . . . . . . .  8
      4.1.  Calculating Secondary Keys with Vary . . . . . . . . . . .  9
      4.2.  Freshness  . . . . . . . . . . . . . . . . . . . . . . . . 10
        4.2.1.  Calculating Freshness Lifetime . . . . . . . . . . . . 12
        4.2.2.  Calculating Heuristic Freshness  . . . . . . . . . . . 12
        4.2.3.  Calculating Age  . . . . . . . . . . . . . . . . . . . 13
        4.2.4.  Serving Stale Responses  . . . . . . . . . . . . . . . 15
      4.3.  Validation . . . . . . . . . . . . . . . . . . . . . . . . 15
        4.3.1.  Sending a Validation Request . . . . . . . . . . . . . 15
        4.3.2.  Handling a Received Validation Request . . . . . . . . 16
        4.3.3.  Handling a Validation Response . . . . . . . . . . . . 17
        4.3.4.  Freshening Stored Responses upon Validation  . . . . . 18
        4.3.5.  Freshening Responses via HEAD  . . . . . . . . . . . . 19
      4.4.  Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19
    5.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 20
      5.1.  Age  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
      5.2.  Cache-Control  . . . . . . . . . . . . . . . . . . . . . . 21
        5.2.1.  Request Cache-Control Directives . . . . . . . . . . . 21
        5.2.2.  Response Cache-Control Directives  . . . . . . . . . . 23
        5.2.3.  Cache Control Extensions . . . . . . . . . . . . . . . 26
      5.3.  Expires  . . . . . . . . . . . . . . . . . . . . . . . . . 27
      5.4.  Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28
      5.5.  Warning  . . . . . . . . . . . . . . . . . . . . . . . . . 29
        5.5.1.  Warning: 110 - "Response is Stale" . . . . . . . . . . 30
        5.5.2.  Warning: 111 - "Revalidation Failed" . . . . . . . . . 31
        5.5.3.  Warning: 112 - "Disconnected Operation"  . . . . . . . 31
        5.5.4.  Warning: 113 - "Heuristic Expiration"  . . . . . . . . 31
        5.5.5.  Warning: 199 - "Miscellaneous Warning" . . . . . . . . 31
        5.5.6.  Warning: 214 - "Transformation Applied"  . . . . . . . 31
        5.5.7.  Warning: 299 - "Miscellaneous Persistent Warning"  . . 31
    6.  History Lists  . . . . . . . . . . . . . . . . . . . . . . . . 31
    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 32
      7.1.  Cache Directive Registry . . . . . . . . . . . . . . . . . 32
        7.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 32
        7.1.2.  Considerations for New Cache Control Directives  . . . 32
        7.1.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 32
      7.2.  Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33
        7.2.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 33
        7.2.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 33
      7.3.  Header Field Registration  . . . . . . . . . . . . . . . . 34
    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
    9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 35
    10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
      10.1. Normative References . . . . . . . . . . . . . . . . . . . 35
      10.2. Informative References . . . . . . . . . . . . . . . . . . 36
    Appendix A.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 36
    Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 38
    Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 38
    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

NEW:

    1. Introduction ....................................................4
       1.1. Conformance and Error Handling .............................4
       1.2. Syntax Notation ............................................4
            1.2.1. Delta Seconds .......................................5
    2. Overview of Cache Operation .....................................5
    3. Storing Responses in Caches .....................................6
       3.1. Storing Incomplete Responses ...............................7
       3.2. Storing Responses to Authenticated Requests ................7
       3.3. Combining Partial Content ..................................8
    4. Constructing Responses from Caches ..............................8
       4.1. Calculating Secondary Keys with Vary .......................9
       4.2. Freshness .................................................11
            4.2.1. Calculating Freshness Lifetime .....................12
            4.2.2. Calculating Heuristic Freshness ....................13
            4.2.3. Calculating Age ....................................13
            4.2.4. Serving Stale Responses ............................15
       4.3. Validation ................................................16
            4.3.1. Sending a Validation Request .......................16
            4.3.2. Handling a Received Validation Request .............16
            4.3.3. Handling a Validation Response .....................18
            4.3.4. Freshening Stored Responses upon Validation ........18
            4.3.5. Freshening Responses via HEAD ......................19
       4.4. Invalidation ..............................................20
    5. Header Field Definitions .......................................21
       5.1. Age .......................................................21
       5.2. Cache-Control .............................................21
            5.2.1. Request Cache-Control Directives ...................22
            5.2.2. Response Cache-Control Directives ..................24
            5.2.3. Cache Control Extensions ...........................27
       5.3. Expires ...................................................28
       5.4. Pragma ....................................................29
       5.5. Warning ...................................................29
            5.5.1. Warning: 110 - "Response is Stale" .................31
            5.5.2. Warning: 111 - "Revalidation Failed" ...............31
            5.5.3. Warning: 112 - "Disconnected Operation" ............31
            5.5.4. Warning: 113 - "Heuristic Expiration" ..............31
            5.5.5. Warning: 199 - "Miscellaneous Warning" .............32
            5.5.6. Warning: 214 - "Transformation Applied" ............32
            5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" ..32
    6. History Lists ..................................................32
    7. IANA Considerations ............................................32
       7.1. Cache Directive Registry ..................................32
            7.1.1. Procedure ..........................................32
            7.1.2. Considerations for New Cache Control Directives ....33
            7.1.3. Registrations ......................................33
       7.2. Warn Code Registry ........................................34
            7.2.1. Procedure ..........................................34
            7.2.2. Registrations ......................................34
       7.3. Header Field Registration .................................34
    8. Security Considerations ........................................35
    9. Acknowledgments ................................................36
    10. References ....................................................36
       10.1. Normative References .....................................36
       10.2. Informative References ...................................37
    Appendix A. Changes from RFC 2616 .................................38
    Appendix B. Imported ABNF .........................................39
    Appendix C. Collected ABNF ........................................39
    Index .............................................................41


Section 1.2.1., paragraph 3:
OLD:

    A recipient parsing a delta-seconds value and converting it to binary
    form ought to use an arithmetic type of at least 31 bits of non-
    negative integer range.  If a cache receives a delta-seconds value
    greater than the greatest integer it can represent, or if any of its
    subsequent calculations overflows, the cache MUST consider the value
    to be either 2147483648 (2^31) or the greatest positive integer it
    can conveniently represent.

NEW:

    A recipient parsing a delta-seconds value and converting it to binary
    form ought to use an arithmetic type of at least 31 bits of
    non-negative integer range.  If a cache receives a delta-seconds
    value greater than the greatest integer it can represent, or if any
    of its subsequent calculations overflows, the cache MUST consider the
    value to be either 2147483648 (2^31) or the greatest positive integer
    it can conveniently represent.


Section 3.3., paragraph 3:
OLD:

    o  delete any Warning header fields in the stored response with warn-
       code 1xx (see Section 5.5);

NEW:

    o  delete any Warning header fields in the stored response with
       warn-code 1xx (see Section 5.5);


Section 3.3., paragraph 4:
OLD:

    o  retain any Warning header fields in the stored response with warn-
       code 2xx; and,

NEW:

    o  retain any Warning header fields in the stored response with
       warn-code 2xx; and,


Section 4.2., paragraph 13:
OLD:

    o  Although all date formats are specified to be case-sensitive, a
       cache recipient SHOULD match day, week, and time-zone names case-
       insensitively.

NEW:

    o  Although all date formats are specified to be case-sensitive, a
       cache recipient SHOULD match day, week, and time-zone names
       case-insensitively.


Section 4.2.4., paragraph 3:
OLD:

    A cache MUST NOT send stale responses unless it is disconnected
    (i.e., it cannot contact the origin server or otherwise find a
    forward path) or doing so is explicitly allowed (e.g., by the max-
    stale request directive; see Section 5.2.1).

NEW:

    A cache MUST NOT send stale responses unless it is disconnected
    (i.e., it cannot contact the origin server or otherwise find a
    forward path) or doing so is explicitly allowed (e.g., by the
    max-stale request directive; see Section 5.2.1).


Section 4.3.1., paragraph 2:
OLD:

    One such validator is the timestamp given in a Last-Modified header
    field (Section 2.2 of [RFC7232]), which can be used in an If-
    Modified-Since header field for response validation, or in an If-
    Unmodified-Since or If-Range header field for representation
    selection (i.e., the client is referring specifically to a previously
    obtained representation with that timestamp).

NEW:

    One such validator is the timestamp given in a Last-Modified header
    field (Section 2.2 of [RFC7232]), which can be used in an
    If-Modified-Since header field for response validation, or in an
    If-Unmodified-Since or If-Range header field for representation
    selection (i.e., the client is referring specifically to a previously
    obtained representation with that timestamp).


Section 4.3.2., paragraph 3:
OLD:

    The proper evaluation of conditional requests by a cache depends on
    the received precondition header fields and their precedence, as
    defined in Section 6 of [RFC7232].  The If-Match and If-Unmodified-
    Since conditional header fields are not applicable to a cache.

NEW:

    The proper evaluation of conditional requests by a cache depends on
    the received precondition header fields and their precedence, as
    defined in Section 6 of [RFC7232].  The If-Match and
    If-Unmodified-Since conditional header fields are not applicable to a
    cache.


Section 4.3.2., paragraph 6:
OLD:

    If an If-None-Match header field is not present, a request containing
    an If-Modified-Since header field (Section 3.3 of [RFC7232])
    indicates that the client wants to validate one or more of its own
    stored responses by modification date.  A cache recipient SHOULD
    generate a 304 (Not Modified) response (using the metadata of the
    selected stored response) if one of the following cases is true: 1)
    the selected stored response has a Last-Modified field-value that is
    earlier than or equal to the conditional timestamp; 2) no Last-
    Modified field is present in the selected stored response, but it has
    a Date field-value that is earlier than or equal to the conditional
    timestamp; or, 3) neither Last-Modified nor Date is present in the
    selected stored response, but the cache recorded it as having been
    received at a time earlier than or equal to the conditional
    timestamp.

NEW:

    If an If-None-Match header field is not present, a request containing
    an If-Modified-Since header field (Section 3.3 of [RFC7232])
    indicates that the client wants to validate one or more of its own
    stored responses by modification date.  A cache recipient SHOULD
    generate a 304 (Not Modified) response (using the metadata of the
    selected stored response) if one of the following cases is true: 1)
    the selected stored response has a Last-Modified field-value that is
    earlier than or equal to the conditional timestamp; 2) no
    Last-Modified field is present in the selected stored response, but
    it has a Date field-value that is earlier than or equal to the
    conditional timestamp; or, 3) neither Last-Modified nor Date is
    present in the selected stored response, but the cache recorded it as
    having been received at a time earlier than or equal to the
    conditional timestamp.


Section 4.3.4., paragraph 7:
OLD:

    o  delete any Warning header fields in the stored response with warn-
       code 1xx (see Section 5.5);

NEW:

    o  delete any Warning header fields in the stored response with
       warn-code 1xx (see Section 5.5);


Section 4.3.4., paragraph 8:
OLD:

    o  retain any Warning header fields in the stored response with warn-
       code 2xx; and,

NEW:

    o  retain any Warning header fields in the stored response with
       warn-code 2xx; and,


Section 4.3.5., paragraph 3:
OLD:

    For each of the stored responses that could have been selected, if
    the stored response and HEAD response have matching values for any
    received validator fields (ETag and Last-Modified) and, if the HEAD
    response has a Content-Length header field, the value of Content-
    Length matches that of the stored response, the cache SHOULD update
    the stored response as described below; otherwise, the cache SHOULD
    consider the stored response to be stale.

NEW:

    For each of the stored responses that could have been selected, if
    the stored response and HEAD response have matching values for any
    received validator fields (ETag and Last-Modified) and, if the HEAD
    response has a Content-Length header field, the value of
    Content-Length matches that of the stored response, the cache SHOULD
    update the stored response as described below; otherwise, the cache
    SHOULD consider the stored response to be stale.


Section 4.3.5., paragraph 5:
OLD:

    o  delete any Warning header fields in the stored response with warn-
       code 1xx (see Section 5.5);

NEW:

    o  delete any Warning header fields in the stored response with
       warn-code 1xx (see Section 5.5);


Section 4.3.5., paragraph 6:
OLD:

    o  retain any Warning header fields in the stored response with warn-
       code 2xx; and,

NEW:

    o  retain any Warning header fields in the stored response with
       warn-code 2xx; and,


Section 5.2., paragraph 5:
OLD:

    Cache directives are identified by a token, to be compared case-
    insensitively, and have an optional argument, that can use both token
    and quoted-string syntax.  For the directives defined below that
    define arguments, recipients ought to accept both forms, even if one
    is documented to be preferred.  For any directive not defined by this
    specification, a recipient MUST accept both forms.

NEW:

    Cache directives are identified by a token, to be compared
    case-insensitively, and have an optional argument, that can use both
    token and quoted-string syntax.  For the directives defined below
    that define arguments, recipients ought to accept both forms, even if
    one is documented to be preferred.  For any directive not defined by
    this specification, a recipient MUST accept both forms.


Section 5.2.1.5., paragraph 1:
OLD:

    The "no-store" request directive indicates that a cache MUST NOT
    store any part of either this request or any response to it.  This
    directive applies to both private and shared caches.  "MUST NOT
    store" in this context means that the cache MUST NOT intentionally
    store the information in non-volatile storage, and MUST make a best-
    effort attempt to remove the information from volatile storage as
    promptly as possible after forwarding it.

NEW:

    The "no-store" request directive indicates that a cache MUST NOT
    store any part of either this request or any response to it.  This
    directive applies to both private and shared caches.  "MUST NOT
    store" in this context means that the cache MUST NOT intentionally
    store the information in non-volatile storage, and MUST make a
    best-effort attempt to remove the information from volatile storage
    as promptly as possible after forwarding it.


Section 5.2.2.2., paragraph 7:
OLD:

    Note: Although it has been back-ported to many implementations, some
    HTTP/1.0 caches will not recognize or obey this directive.  Also, no-
    cache response directives with field-names are often handled by
    caches as if an unqualified no-cache directive was received; i.e.,
    the special handling for the qualified form is not widely
    implemented.

NEW:

    Note: Although it has been back-ported to many implementations, some
    HTTP/1.0 caches will not recognize or obey this directive.  Also,
    no-cache response directives with field-names are often handled by
    caches as if an unqualified no-cache directive was received; i.e.,
    the special handling for the qualified form is not widely
    implemented.


Section 5.2.2.3., paragraph 1:
OLD:

    The "no-store" response directive indicates that a cache MUST NOT
    store any part of either the immediate request or response.  This
    directive applies to both private and shared caches.  "MUST NOT
    store" in this context means that the cache MUST NOT intentionally
    store the information in non-volatile storage, and MUST make a best-
    effort attempt to remove the information from volatile storage as
    promptly as possible after forwarding it.

NEW:

    The "no-store" response directive indicates that a cache MUST NOT
    store any part of either the immediate request or response.  This
    directive applies to both private and shared caches.  "MUST NOT
    store" in this context means that the cache MUST NOT intentionally
    store the information in non-volatile storage, and MUST make a
    best-effort attempt to remove the information from volatile storage
    as promptly as possible after forwarding it.


Section 5.5., paragraph 15:
OLD:

    If a recipient that uses, evaluates, or displays Warning header
    fields receives a warn-date that is different from the Date value in
    the same message, the recipient MUST exclude the warning-value
    containing that warn-date before storing, forwarding, or using the
    message.  This allows recipients to exclude warning-values that were
    improperly retained after a cache validation.  If all of the warning-
    values are excluded, the recipient MUST exclude the Warning header
    field as well.

NEW:

    If a recipient that uses, evaluates, or displays Warning header
    fields receives a warn-date that is different from the Date value in
    the same message, the recipient MUST exclude the warning-value
    containing that warn-date before storing, forwarding, or using the
    message.  This allows recipients to exclude warning-values that were
    improperly retained after a cache validation.  If all of the
    warning-values are excluded, the recipient MUST exclude the Warning
    header field as well.


Section 5.5.6., paragraph 1:
OLD:

    This Warning code MUST be added by a proxy if it applies any
    transformation to the representation, such as changing the content-
    coding, media-type, or modifying the representation data, unless this
    Warning code already appears in the response.

NEW:

    This Warning code MUST be added by a proxy if it applies any
    transformation to the representation, such as changing the
    content-coding, media-type, or modifying the representation data,
    unless this Warning code already appears in the response.


Section 7.1.1., paragraph 2:
OLD:

    o  Cache Directive Name
 
    o  Pointer to specification text

NEW:

    o  Cache Directive Name
    o  Pointer to specification text


Section 10.1., paragraph 4:
OLD:

    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Semantics and Content",
               draft-ietf-httpbis-p2-semantics-latest (work in progress),
               June 2014.

NEW:

    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
               June 2014.


Section 10.1., paragraph 5:
OLD:

    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Conditional Requests",
               draft-ietf-httpbis-p4-conditional-latest (work in
               progress), June 2014.

NEW:

    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
               June 2014.


Section 10.1., paragraph 6:
OLD:

    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
               draft-ietf-httpbis-p5-range-latest (work in progress),
               June 2014.

NEW:

    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
               RFC 7233, June 2014.


Section 10.1., paragraph 7:
OLD:

    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Authentication",
               draft-ietf-httpbis-p7-auth-latest (work in progress),
               June 2014.

NEW:

    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.


Appendix A., paragraph 2:
OLD:

    The conditions under which an authenticated response can be cached
    have been clarified.  (Section 3.2)
    New status codes can now define that caches are allowed to use
    heuristic freshness with them.  Caches are now allowed to calculate
    heuristic freshness for URIs with query components.  (Section 4.2.2)

NEW:

    The conditions under which an authenticated response can be cached
    have been clarified.  (Section 3.2)
 
    New status codes can now define that caches are allowed to use
    heuristic freshness with them.  Caches are now allowed to calculate
    heuristic freshness for URIs with query components.  (Section 4.2.2)


Appendix A., paragraph 11:
OLD:

    The "no-cache" response directive's meaning has been clarified.
    (Section 5.2.2.2)
 
    The one-year limit on Expires header field values has been removed;
    instead, the reasoning for using a sensible value is given.
    (Section 5.3)

NEW:

    The "no-cache" response directive's meaning has been clarified.
    (Section 5.2.2.2)
    The one-year limit on Expires header field values has been removed;
    instead, the reasoning for using a sensible value is given.
    (Section 5.3)


Appendix A., paragraph 12:
OLD:

    The Pragma header field is now only defined for backwards
    compatibility; future pragmas are deprecated.  (Section 5.4)
    Some requirements regarding production and processing of the Warning
    header fields have been relaxed, as it is not widely implemented.
    Furthermore, the Warning header field no longer uses RFC 2047
    encoding, nor does it allow multiple languages, as these aspects were
    not implemented.  (Section 5.5)

NEW:

    The Pragma header field is now only defined for backwards
    compatibility; future pragmas are deprecated.  (Section 5.4)
 
    Some requirements regarding production and processing of the Warning
    header fields have been relaxed, as it is not widely implemented.
    Furthermore, the Warning header field no longer uses RFC 2047
    encoding, nor does it allow multiple languages, as these aspects were
    not implemented.  (Section 5.5)


Section 1.2, paragraph 18:
OLD:

    1
       110 (warn-code)  30
       111 (warn-code)  31
       112 (warn-code)  31
       113 (warn-code)  31
       199 (warn-code)  31

NEW:

    1
       110 (warn-code)  31
       111 (warn-code)  31
       112 (warn-code)  31
       113 (warn-code)  31
       199 (warn-code)  32


Section 1.2, paragraph 19:
OLD:

    2
       214 (warn-code)  31
       299 (warn-code)  31

NEW:

    2
       214 (warn-code)  32
       299 (warn-code)  32


Section 1.2, paragraph 20:
OLD:

    A
       age  10
       Age header field  20

NEW:

    A
       age  11
       Age header field  21


Section 1.2, paragraph 23:
OLD:

    E
       Expires header field  27
       explicit expiration time  10

NEW:

    E
       Expires header field  28
       explicit expiration time  11


Section 1.2, paragraph 24:
OLD:

    F
       fresh  10
       freshness lifetime  10

NEW:

    F
       fresh  11
       freshness lifetime  11


Section 1.2, paragraph 25:
OLD:

    G
       Grammar
          Age  20
          Cache-Control  21
          cache-directive  21
          delta-seconds  5
          Expires  27
          extension-pragma  28
          Pragma  28
          pragma-directive  28
          warn-agent  29
          warn-code  29
          warn-date  29
          warn-text  29
          Warning  29
          warning-value  29

NEW:

    G
       Grammar
          Age  21
          Cache-Control  22
          cache-directive  22
          delta-seconds  5
          Expires  28
          extension-pragma  29
          Pragma  29
          pragma-directive  29
          warn-agent  29
          warn-code  29
          warn-date  29
          warn-text  29
          Warning  29
          warning-value  29


Section 1.2, paragraph 26:
OLD:

    H
       Heuristic Expiration (warn-text)  31
       heuristic expiration time  10
 
    M
       max-age (cache directive)  21, 26
       max-stale (cache directive)  22
       min-fresh (cache directive)  22
       Miscellaneous Persistent Warning (warn-text)  31
       Miscellaneous Warning (warn-text)  31
       must-revalidate (cache directive)  23

NEW:

    H
       Heuristic Expiration (warn-text)  31
       heuristic expiration time  11
    M
       max-age (cache directive)  22, 26
       max-stale (cache directive)  22
       min-fresh (cache directive)  22
       Miscellaneous Persistent Warning (warn-text)  32
       Miscellaneous Warning (warn-text)  32
       must-revalidate (cache directive)  24


Section 1.2, paragraph 27:
OLD:

    N
       no-cache (cache directive)  22, 24
       no-store (cache directive)  22, 24
       no-transform (cache directive)  23, 25

NEW:

    N
       no-cache (cache directive)  23, 25
       no-store (cache directive)  23, 24
       no-transform (cache directive)  23, 25


Section 1.2, paragraph 29:
OLD:

    P
       Pragma header field  28
       private (cache directive)  25
       private cache  4
       proxy-revalidate (cache directive)  26
       public (cache directive)  25

NEW:

    P
       Pragma header field  29
       private (cache directive)  25
       private cache  4
       proxy-revalidate (cache directive)  26
       public (cache directive)  25


Section 1.2, paragraph 31:
OLD:

    S
       s-maxage (cache directive)  26
       shared cache  4
       stale  10
       strong validator  18

NEW:

    S
       s-maxage (cache directive)  27
       shared cache  4
       stale  11
       strong validator  18


Section 1.2, paragraph 32:
OLD:

    T
       Transformation Applied (warn-text)  31

NEW:

    T
       Transformation Applied (warn-text)  32


Section 1.2, paragraph 33:
OLD:

    V
       validator  15

NEW:

    V
       validator  16

