source: draft-ietf-httpbis/latest/auth48/rfc7234.abdiff.txt @ 2678

Last change on this file since 2678 was 2678, checked in by julian.reschke@…, 7 years ago

add RFC7234-to-be and RFC7235-to-be (#553)

File size: 23.7 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2616 (if approved)                         M. Nottingham, Ed.
8 Intended status: Standards Track                                  Akamai
9 Expires: November 17, 2014                               J. Reschke, Ed.
10                                                               greenbytes
11                                                             May 16, 2014
12
13NEW:
14
15 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
16 Request for Comments: 7234                                         Adobe
17 Obsoletes: 2616                                       M. Nottingham, Ed.
18 Category: Standards Track                                         Akamai
19 ISSN: 2070-1721                                          J. Reschke, Ed.
20                                                               greenbytes
21                                                                 May 2014
22
23
24INTRODUCTION, paragraph 2:
25OLD:
26
27             Hypertext Transfer Protocol (HTTP/1.1): Caching
28                    draft-ietf-httpbis-p6-cache-latest
29
30NEW:
31
32             Hypertext Transfer Protocol (HTTP/1.1): Caching
33
34
35INTRODUCTION, paragraph 5:
36OLD:
37
38 Editorial Note (To be removed by RFC Editor)
39 
40    Discussion of this draft takes place on the HTTPBIS working group
41    mailing list (ietf-http-wg@w3.org), which is archived at
42    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
43 
44    The current issues list is at
45    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
46    documents (including fancy diffs) can be found at
47    <http://tools.ietf.org/wg/httpbis/>.
48 
49    _This is a temporary document for the purpose of tracking the
50    editorial changes made during the AUTH48 (RFC publication) phase._
51 
52 Status of This Memo
53
54NEW:
55
56 Status of This Memo
57
58
59INTRODUCTION, paragraph 6:
60OLD:
61
62    This Internet-Draft is submitted in full conformance with the
63    provisions of BCP 78 and BCP 79.
64
65NEW:
66
67    This is an Internet Standards Track document.
68
69
70INTRODUCTION, paragraph 7:
71OLD:
72
73    Internet-Drafts are working documents of the Internet Engineering
74    Task Force (IETF).  Note that other groups may also distribute
75    working documents as Internet-Drafts.  The list of current Internet-
76    Drafts is at http://datatracker.ietf.org/drafts/current/.
77
78NEW:
79
80    This document is a product of the Internet Engineering Task Force
81    (IETF).  It represents the consensus of the IETF community.  It has
82    received public review and has been approved for publication by the
83    Internet Engineering Steering Group (IESG).  Further information on
84    Internet Standards is available in Section 2 of RFC 5741.
85
86
87INTRODUCTION, paragraph 8:
88OLD:
89
90    Internet-Drafts are draft documents valid for a maximum of six months
91    and may be updated, replaced, or obsoleted by other documents at any
92    time.  It is inappropriate to use Internet-Drafts as reference
93    material or to cite them other than as "work in progress."
94    This Internet-Draft will expire on November 17, 2014.
95
96NEW:
97
98    Information about the current status of this document, any errata,
99    and how to provide feedback on it may be obtained at
100    http://www.rfc-editor.org/info/rfc7234.
101
102
103Section 3.1., paragraph 1:
104OLD:
105
106    A response message is considered complete when all of the octets
107    indicated by the message framing ([RFC7230]) are received prior to
108    the connection being closed.  If the request method is GET, the
109    response status code is 200 (OK), and the entire response header
110    section has been received, a cache MAY store an incomplete response
111    message body if the cache entry is recorded as incomplete.  Likewise,
112    a 206 (Partial Content) response MAY be stored as if it were an
113    incomplete 200 (OK) cache entry.  However, a cache MUST NOT store
114    incomplete or partial content responses if it does not support the
115    Range and Content-Range header fields or if it does not understand
116    the range units used in those fields.
117
118NEW:
119
120    A response message is considered complete when all of the octets
121    indicated by the message framing ([RFC7230]) are received prior to
122    the connection being closed.  If the request method is GET, the
123    response status code is 200 (OK), and the entire response header
124    section has been received, a cache MAY store an incomplete response
125    message body if the cache entry is recorded as incomplete.  Likewise,
126    a 206 (Partial Content) response MAY be stored as if it were an
127    incomplete 200 (OK) cache entry.  However, a cache MUST NOT store
128    incomplete or partial-content responses if it does not support the
129    Range and Content-Range header fields or if it does not understand
130    the range units used in those fields.
131
132
133Section 3.2., paragraph 2:
134OLD:
135
136    In this specification, the following Cache-Control response
137    directives (Section 5.2.2) have such an effect: must-revalidate,
138    public, s-maxage.
139
140NEW:
141
142    In this specification, the following Cache-Control response
143    directives (Section 5.2.2) have such an effect: must-revalidate,
144    public, and s-maxage.
145
146
147Section 4., paragraph 14:
148OLD:
149
150    Also, note that unsafe requests might invalidate already stored
151    responses; see Section 4.4.
152
153NEW:
154
155    Also, note that unsafe requests might invalidate already-stored
156    responses; see Section 4.4.
157
158
159Section 4.1., paragraph 5:
160OLD:
161
162    o  normalizing both header field values in a way that is known to
163       have identical semantics, according to the header field's
164       specification (e.g., re-ordering field values when order is not
165       significant; case-normalization, where values are defined to be
166       case-insensitive)
167
168NEW:
169
170    o  normalizing both header field values in a way that is known to
171       have identical semantics, according to the header field's
172       specification (e.g., reordering field values when order is not
173       significant; case-normalization, where values are defined to be
174       case-insensitive)
175
176
177Section 4.2., paragraph 13:
178OLD:
179
180    o  Although all date formats are specified to be case-sensitive, a
181       cache recipient SHOULD match day, week, and timezone names case-
182       insensitively.
183
184NEW:
185
186    o  Although all date formats are specified to be case-sensitive, a
187       cache recipient SHOULD match day, week, and time-zone names case-
188       insensitively.
189
190
191Section 4.2.1., paragraph 1:
192OLD:
193
194    A cache can calculate the freshness lifetime (denoted as
195    freshness_lifetime) of a response by using the first match of:
196
197NEW:
198
199    A cache can calculate the freshness lifetime (denoted as
200    freshness_lifetime) of a response by using the first match using of
201    the following:
202
203
204Section 4.2.1., paragraph 4:
205OLD:
206
207    o  If the Expires response header field (Section 5.3) is present, use
208       its value minus the value of the Date response header field, or
209
210NEW:
211
212    o  If the Expires response header field (Section 5.3) is present, use
213       its value minus the value of the Date response header field,
214
215
216Section 4.2.3., paragraph 7:
217OLD:
218
219    now
220       The term "now" means "the current value of the clock at the host
221       performing the calculation".  A host ought to use NTP ([RFC5905])
222       or some similar protocol to synchronize its clocks to Coordinated
223       Universal Time.
224
225NEW:
226
227    now
228 
229       The term "now" means "the current value of the clock at the host
230       performing the calculation".  A host ought to use NTP ([RFC5905])
231       or some similar protocol to synchronize its clocks to Coordinated
232       Universal Time.
233
234
235Section 4.3.2., paragraph 4:
236OLD:
237
238    A request containing an If-None-Match header field (Section 3.2 of
239    [RFC7232]) indicates that the client wants to validate one or more of
240    its own stored responses in comparison to whichever stored response
241    is selected by the cache.  If the field-value is "*", or if the
242    field-value is a list of entity-tags and at least one of them match
243    the entity-tag of the selected stored response, a cache recipient
244    SHOULD generate a 304 (Not Modified) response (using the metadata of
245    the selected stored response) instead of sending that stored
246    response.
247
248NEW:
249
250    A request containing an If-None-Match header field (Section 3.2 of
251    [RFC7232]) indicates that the client wants to validate one or more of
252    its own stored responses in comparison to whichever stored response
253    is selected by the cache.  If the field-value is "*", or if the
254    field-value is a list of entity-tags and at least one of them matches
255    the entity-tag of the selected stored response, a cache recipient
256    SHOULD generate a 304 (Not Modified) response (using the metadata of
257    the selected stored response) instead of sending that stored
258    response.
259
260
261Section 4.3.4., paragraph 2:
262OLD:
263
264    The stored response to update is identified by using the first match
265    (if any) of:
266
267NEW:
268
269    The stored response to update is identified by using the first match
270    (if any) of the following:
271
272
273Section 4.4., paragraph 1:
274OLD:
275
276    Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as
277    PUT, POST or DELETE have the potential for changing state on the
278    origin server, intervening caches can use them to keep their contents
279    up-to-date.
280
281NEW:
282
283    Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as
284    PUT, POST or DELETE have the potential for changing state on the
285    origin server, intervening caches can use them to keep their contents
286    up to date.
287
288
289Section 4.4., paragraph 5:
290OLD:
291
292    Here, a "non-error response" is one with a 2xx (Successful) or 3xx
293    (Redirection) status code.  "Invalidate" means that the cache will
294    either remove all stored responses related to the effective request
295    URI, or will mark these as "invalid" and in need of a mandatory
296    validation before they can be sent in response to a subsequent
297    request.
298
299NEW:
300
301    Here, a "non-error response" is one with a 2xx (Successful) or 3xx
302    (Redirection) status code.  "Invalidate" means that the cache will
303    either remove all stored responses related to the effective request
304    URI or will mark these as "invalid" and in need of a mandatory
305    validation before they can be sent in response to a subsequent
306    request.
307
308
309Section 5.2.1.1., paragraph 4:
310OLD:
311
312    This directive uses the token form of the argument syntax; e.g.,
313    'max-age=5', not 'max-age="5"'.  A sender SHOULD NOT generate the
314    quoted-string form.
315
316NEW:
317
318    This directive uses the token form of the argument syntax: e.g.,
319    'max-age=5' not 'max-age="5"'.  A sender SHOULD NOT generate the
320    quoted-string form.
321
322
323Section 5.2.1.2., paragraph 4:
324OLD:
325
326    This directive uses the token form of the argument syntax; e.g.,
327    'max-stale=10', not 'max-stale="10"'.  A sender SHOULD NOT generate
328    the quoted-string form.
329
330NEW:
331
332    This directive uses the token form of the argument syntax: e.g.,
333    'max-stale=10' not 'max-stale="10"'.  A sender SHOULD NOT generate
334    the quoted-string form.
335
336
337Section 5.2.2.6., paragraph 7:
338OLD:
339
340    Note: This usage of the word "private" only controls where the
341    response can be stored; it cannot ensure the privacy of the message
342    content.  Also, private response directives with field-names are
343    often handled by caches as if an unqualified private directive was
344    received; i.e., the special handling for the qualified form is not
345    widely implemented.
346
347NEW:
348
349    Note: This use of the word "private" refers only to the control of
350    the location in which the response can be stored; the privacy of the
351    message content cannot be ensured.  Also, private response directives
352    with field-names are often handled by caches as if an unqualified
353    private directive was received; i.e., the special handling for the
354    qualified form is not widely implemented.
355
356
357Section 5.2.2.8., paragraph 4:
358OLD:
359
360    This directive uses the token form of the argument syntax; e.g.,
361    'max-age=5', not 'max-age="5"'.  A sender SHOULD NOT generate the
362    quoted-string form.
363
364NEW:
365
366    This directive uses the token form of the argument syntax: e.g.,
367    'max-age=5' not 'max-age="5"'.  A sender SHOULD NOT generate the
368    quoted-string form.
369
370
371Section 5.2.2.9., paragraph 4:
372OLD:
373
374    This directive uses the token form of the argument syntax; e.g.,
375    's-maxage=10', not 's-maxage="10"'.  A sender SHOULD NOT generate the
376    quoted-string form.
377
378NEW:
379
380    This directive uses the token form of the argument syntax: e.g.,
381    's-maxage=10' not 's-maxage="10"'.  A sender SHOULD NOT generate the
382    quoted-string form.
383
384
385Section 5.5., paragraph 10:
386OLD:
387
388    o  1xx warn-codes describe the freshness or validation status of the
389       response, and so MUST be deleted by a cache after validation.
390       They can only be generated by a cache when validating a cached
391       entry, and MUST NOT be generated in any other situation.
392
393NEW:
394
395    o  1xx warn-codes describe the freshness or validation status of the
396       response, and so they MUST be deleted by a cache after validation.
397       They can only be generated by a cache when validating a cached
398       entry, and MUST NOT be generated in any other situation.
399
400
401Section 5.5., paragraph 11:
402OLD:
403
404    o  2xx warn-codes describe some aspect of the representation that is
405       not rectified by a validation (for example, a lossy compression of
406       the representation) and MUST NOT be deleted by a cache after
407       validation, unless a full response is sent, in which case they
408       MUST be.
409
410NEW:
411
412    o  2xx warn-codes describe some aspect of the representation that is
413       not rectified by a validation (for example, a lossy compression of
414       the representation) and they MUST NOT be deleted by a cache after
415       validation, unless a full response is sent, in which case they
416       MUST be.
417
418
419Section 5.5.5., paragraph 1:
420OLD:
421
422    The warning text can include arbitrary information to be presented to
423    a human user, or logged.  A system receiving this warning MUST NOT
424    take any automated action, besides presenting the warning to the
425    user.
426
427NEW:
428
429    The warning text can include arbitrary information to be presented to
430    a human user or logged.  A system receiving this warning MUST NOT
431    take any automated action, besides presenting the warning to the
432    user.
433
434
435Section 5.5.6., paragraph 1:
436OLD:
437
438    MUST be added by a proxy if it applies any transformation to the
439    representation, such as changing the content-coding, media-type, or
440    modifying the representation data, unless this Warning code already
441    appears in the response.
442
443NEW:
444
445    This Warning code MUST be added by a proxy if it applies any
446    transformation to the representation, such as changing the content-
447    coding, media-type, or modifying the representation data, unless this
448    Warning code already appears in the response.
449
450
451Section 5.5.7., paragraph 1:
452OLD:
453
454    The warning text can include arbitrary information to be presented to
455    a human user, or logged.  A system receiving this warning MUST NOT
456    take any automated action.
457
458NEW:
459
460    The warning text can include arbitrary information to be presented to
461    a human user or logged.  A system receiving this warning MUST NOT
462    take any automated action.
463
464
465Section 6., paragraph 2:
466OLD:
467
468    The freshness model (Section 4.2) does not necessarily apply to
469    history mechanisms.  I.e., a history mechanism can display a previous
470    representation even if it has expired.
471
472NEW:
473
474    The freshness model (Section 4.2) does not necessarily apply to
475    history mechanisms.  That is, a history mechanism can display a
476    previous representation even if it has expired.
477
478
479Section 6., paragraph 3:
480OLD:
481
482    This does not prohibit the history mechanism from telling the user
483    that a view might be stale, or from honoring cache directives (e.g.,
484    Cache-Control: no-store).
485
486NEW:
487
488    This does not prohibit the history mechanism from telling the user
489    that a view might be stale or from honoring cache directives (e.g.,
490    Cache-Control: no-store).
491
492
493Section 7.1., paragraph 1:
494OLD:
495
496    The HTTP Cache Directive Registry defines the namespace for the cache
497    directives.  It will be created and maintained at (the suggested URI)
498    <http://www.iana.org/assignments/http-cache-directives>.
499
500NEW:
501
502    The "HTTP Cache Directive Registry" defines the name space for the
503    cache directives.  It has been created and is now maintained at
504    <http://www.iana.org/assignments/http-cache-directives>.
505
506
507Section 7.1.3., paragraph 1:
508OLD:
509
510    The HTTP Cache Directive Registry has been populated with the
511    registrations below:
512
513NEW:
514
515    The "HTTP Cache Directive Registry" shall be populated with the
516    registrations below:
517
518
519Section 7.2., paragraph 1:
520OLD:
521
522    The HTTP Warn Code Registry defines the namespace for warn codes.  It
523    will be created and maintained at (the suggested URI)
524    <http://www.iana.org/assignments/http-warn-codes>.
525
526NEW:
527
528    The "HTTP Warn Codes" registry defines the name space for warn codes.
529    It has been created and is now maintained at
530    <http://www.iana.org/assignments/http-warn-codes>.
531
532
533Section 7.2.1., paragraph 5:
534OLD:
535
536    Values to be added to this namespace require IETF Review (see
537    [RFC5226], Section 4.1).
538
539NEW:
540
541    Values to be added to this name pace require IETF Review (see
542    [RFC5226], Section 4.1).
543
544
545Section 7.2.2., paragraph 1:
546OLD:
547
548    The HTTP Warn Code Registry has been populated with the registrations
549    below:
550
551NEW:
552
553    The "HTTP Warn Codes" registry has been populated with the
554    registrations below:
555
556
557Section 7.3., paragraph 1:
558OLD:
559
560    HTTP header fields are registered within the "Message Headers"
561    registry maintained at
562    <http://www.iana.org/assignments/message-headers/>.
563
564NEW:
565
566    HTTP header fields are registered within the Message Header Field
567    Registry maintained at
568    <http://www.iana.org/assignments/message-headers>.
569
570
571Section 7.3., paragraph 2:
572OLD:
573
574    This document defines the following HTTP header fields, so the
575    "Permanent Message Header Field Names" registry has been updated
576    accordingly (see [BCP90]).
577
578NEW:
579
580    This document defines the following HTTP header fields, so their
581    associated registry entries have been updated according to the
582    permanent registrations below (see [BCP90]):
583
584
585Section 10.1., paragraph 3:
586OLD:
587
588    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
589               Protocol (HTTP/1.1): Message Syntax and Routing",
590               draft-ietf-httpbis-p1-messaging-latest (work in progress),
591               May 2014.
592
593NEW:
594
595    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
596               Protocol (HTTP/1.1): Message Syntax and Routing",
597               RFC 7230, May 2014.
598
599
600Section 10.1., paragraph 4:
601OLD:
602
603    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
604               Protocol (HTTP/1.1): Semantics and Content",
605               draft-ietf-httpbis-p2-semantics-latest (work in progress),
606               May 2014.
607
608NEW:
609
610    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
611               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
612               May 2014.
613
614
615Section 10.1., paragraph 5:
616OLD:
617
618    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
619               Protocol (HTTP/1.1): Conditional Requests",
620               draft-ietf-httpbis-p4-conditional-latest (work in
621               progress), May 2014.
622
623NEW:
624
625    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
626               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
627               May 2014.
628
629
630Section 10.1., paragraph 6:
631OLD:
632
633    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
634               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
635               draft-ietf-httpbis-p5-range-latest (work in progress),
636               May 2014.
637
638NEW:
639
640    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
641               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
642               RFC 7233, May 2014.
643
644
645Section 10.1., paragraph 7:
646OLD:
647
648    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
649               Protocol (HTTP/1.1): Authentication",
650               draft-ietf-httpbis-p7-auth-latest (work in progress),
651               May 2014.
652
653NEW:
654
655    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
656               Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014.
657
658
659Appendix A., paragraph 3:
660OLD:
661
662    New status codes can now define that caches are allowed to use
663    heuristic freshness with them.  Caches are now allowed to calculate
664    heuristic freshness for URIs with query components.  (Section 4.2.2)
665 
666    The algorithm for calculating age is now less conservative.  Caches
667    are now required to handle dates with timezones as if they're
668    invalid, because it's not possible to accurately guess.
669    (Section 4.2.3)
670
671NEW:
672
673    New status codes can now define that caches are allowed to use
674    heuristic freshness with them.  Caches are now allowed to calculate
675    heuristic freshness for URIs with query components.  (Section 4.2.2)
676    The algorithm for calculating age is now less conservative.  Caches
677    are now required to handle dates with timezones as if they're
678    invalid, because it's not possible to accurately guess.
679    (Section 4.2.3)
680
681
682Appendix A., paragraph 5:
683OLD:
684
685    The algorithm for selecting a cached negotiated response to use has
686    been clarified in several ways.  In particular, it now explicitly
687    allows header-specific canonicalization when processing selecting
688    header fields.  (Section 4.1)
689
690NEW:
691
692    The algorithm for selecting a cached negotiated response to use has
693    been clarified in several ways.  In particular, it now explicitly
694    allows header-specific canonicalization when processing selecting
695    header fields.  (Section 4.1).
696
697
698Appendix A., paragraph 9:
699OLD:
700
701    The "no-store" request directive doesn't apply to responses; i.e., a
702    cache can satisfy a request with no-store on it, and does not
703    invalidate it.  (Section 5.2.1.5)
704
705NEW:
706
707    The "no-store" request directive doesn't apply to responses; i.e., a
708    cache can satisfy a request with no-store on it and does not
709    invalidate it.  (Section 5.2.1.5)
710
711
712Appendix A., paragraph 10:
713OLD:
714
715    The qualified forms of the private and no-cache cache directives are
716    noted to not be widely implemented; e.g., "private=foo" is
717    interpreted by many caches as simply "private".  Additionally, the
718    meaning of the qualified form of no-cache has been clarified.
719    (Section 5.2.2)
720
721NEW:
722
723    The qualified forms of the private and no-cache cache directives are
724    noted to not be widely implemented; for example, "private=foo" is
725    interpreted by many caches as simply "private".  Additionally, the
726    meaning of the qualified form of no-cache has been clarified.
727    (Section 5.2.2)
728
729
730Appendix A., paragraph 14:
731OLD:
732
733    Some requirements regarding production and processing of the Warning
734    header fields have been relaxed, as it is not widely implemented.
735    Furthermore, the Warning header field no longer uses RFC 2047
736    encoding, nor allows multiple languages, as these aspects were not
737    implemented.  (Section 5.5)
738
739NEW:
740
741    Some requirements regarding production and processing of the Warning
742    header fields have been relaxed, as it is not widely implemented.
743    Furthermore, the Warning header field no longer uses RFC 2047
744    encoding, nor does it allow multiple languages, as these aspects were
745    not implemented.  (Section 5.5)
746
747
748Appendix A., paragraph 15:
749OLD:
750
751    This specification introduces the Cache Directive and Warn Code
752    Registries, and defines considerations for new cache directives.
753    (Section 7.1 and Section 7.2)
754
755NEW:
756
757    This specification introduces the Cache Directive and Warn Code
758    Registries, and defines considerations for new cache directives
759    (Sections 7.1 and 7.2).
760
Note: See TracBrowser for help on using the repository browser.