Ignore:
Timestamp:
27/05/14 14:27:54 (6 years ago)
Author:
julian.reschke@…
Message:

updated AUTH48 version of RFC7234 (#553)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/auth48/rfc7234.abdiff.txt

    r2691 r2698  
    101101
    102102
    103 Section 4.2.1., paragraph 4:
    104 OLD:
    105 
    106     o  If the Expires response header field (Section 5.3) is present, use
    107        its value minus the value of the Date response header field, or
    108 
    109 NEW:
    110 
    111     o  If the Expires response header field (Section 5.3) is present, use
    112        its value minus the value of the Date response header field,
    113 
    114 
    115 Section 4.2.4., paragraph 2:
    116 OLD:
    117 
    118     A cache MUST NOT generate a stale response if it is prohibited by an
    119     explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
    120     cache directive, a "must-revalidate" cache-response-directive, or an
    121     applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
    122     see Section 5.2.2).
    123 
    124 NEW:
    125 
    126     A cache MUST NOT generate a stale response if it is prohibited by an
    127     explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
    128     cache directive, a "must-revalidate" cache-response-directive, or an
    129     applicable "s-maxage" or "proxy-revalidate" cache response directive;
    130     see Section 5.2.2).
    131 
    132 
    133 Section 5.2.1.3., paragraph 4:
    134 OLD:
    135 
    136     This directive uses the token form of the argument syntax: e.g.,
    137     'min-fresh=20' not 'min-fresh="20"'.  A sender SHOULD NOT generate
    138     the quoted-string form.
    139 
    140 NEW:
    141 
    142     This directive uses the token form of the argument syntax; e.g.,
    143     'min-fresh=20', not 'min-fresh="20"'.  A sender SHOULD NOT generate
    144     the quoted-string form.
    145 
    146 
    147 Section 5.2.2.6., paragraph 7:
    148 OLD:
    149 
    150     Note: This usage of the word "private" only controls where the
    151     response can be stored; it cannot ensure the privacy of the message
    152     content.  Also, private response directives with field-names are
    153     often handled by caches as if an unqualified private directive was
    154     received; i.e., the special handling for the qualified form is not
    155     widely implemented.
    156 
    157 NEW:
    158 
    159     Note: This use of the word "private" refers only to the control of
    160     the location in which the response can be stored; the privacy of the
    161     message content cannot be ensured.  Also, private response directives
    162     with field-names are often handled by caches as if an unqualified
    163     private directive was received; i.e., the special handling for the
    164     qualified form is not widely implemented.
    165 
    166 
    167 Section 7.1., paragraph 1:
    168 OLD:
    169 
    170     The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry"
    171     defines the namespace for the cache directives.  It has been created
    172     and is now maintained at
    173     <http://www.iana.org/assignments/http-cache-directives>.
    174 
    175 NEW:
    176 
    177     The "HTTP Cache Directive Registry" defines the name space for the
    178     cache directives.  It has been created and is now maintained at
    179     <http://www.iana.org/assignments/http-cache-directives>.
    180 
    181 
    182 Section 7.1.3., paragraph 1:
    183 OLD:
    184 
    185     The registry has been populated with the registrations below:
    186 
    187 NEW:
    188 
    189     The "HTTP Cache Directive Registry" shall be populated with the
    190     registrations below:
    191 
    192 
    193 Section 7.2., paragraph 1:
    194 OLD:
    195 
    196     The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines
    197     the namespace for warn codes.  It has been created and is now
    198     maintained at <http://www.iana.org/assignments/http-warn-codes>.
    199 
    200 NEW:
    201 
    202     The "HTTP Warn Codes" registry defines the name space for warn codes.
    203     It has been created and is now maintained at
    204     <http://www.iana.org/assignments/http-warn-codes>.
    205 
    206 
    207 Section 7.2.1., paragraph 5:
    208 OLD:
    209 
    210     Values to be added to this namespace require IETF Review (see
    211     [RFC5226], Section 4.1).
    212 
    213 NEW:
    214 
    215     Values to be added to this name pace require IETF Review (see
    216     [RFC5226], Section 4.1).
    217 
    218 
    219 Section 7.2.2., paragraph 1:
    220 OLD:
    221 
    222     The registry has been populated with the registrations below:
    223 
    224 NEW:
    225 
    226     The "HTTP Warn Codes" registry has been populated with the
    227     registrations below:
    228 
    229 
    230 Section 7.3., paragraph 1:
    231 OLD:
    232 
    233     HTTP header fields are registered within the "Message Headers"
    234     registry maintained at
    235     <http://www.iana.org/assignments/message-headers/>.
    236 
    237 NEW:
    238 
    239     HTTP header fields are registered within the Message Header Field
    240     Registry maintained at
    241     <http://www.iana.org/assignments/message-headers>.
    242 
    243 
    244 Section 7.3., paragraph 2:
    245 OLD:
    246 
    247     This document defines the following HTTP header fields, so the
    248     "Permanent Message Header Field Names" registry has been updated
    249     accordingly (see [BCP90]).
    250 
    251 NEW:
    252 
    253     This document defines the following HTTP header fields, so their
    254     associated registry entries have been updated according to the
    255     permanent registrations below (see [BCP90]):
    256 
    257 
    258103Section 10.1., paragraph 3:
    259104OLD:
     
    352197    (Section 4.2.3)
    353198
    354 
    355 Appendix A., paragraph 5:
    356 OLD:
    357 
    358     The algorithm for selecting a cached negotiated response to use has
    359     been clarified in several ways.  In particular, it now explicitly
    360     allows header-specific canonicalization when processing selecting
    361     header fields.  (Section 4.1)
    362 
    363 NEW:
    364 
    365     The algorithm for selecting a cached negotiated response to use has
    366     been clarified in several ways.  In particular, it now explicitly
    367     allows header-specific canonicalization when processing selecting
    368     header fields.  (Section 4.1).
    369 
    370 
    371 Appendix A., paragraph 15:
    372 OLD:
    373 
    374     This specification introduces the Cache Directive and Warn Code
    375     Registries, and defines considerations for new cache directives.
    376     (Section 7.1 and Section 7.2)
    377 
    378 NEW:
    379 
    380     This specification introduces the Cache Directive and Warn Code
    381     Registries, and defines considerations for new cache directives
    382     (Sections 7.1 and 7.2).
    383 
Note: See TracChangeset for help on using the changeset viewer.