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

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

editorial fixes (#553)

File size: 11.6 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 24, 2014                               J. Reschke, Ed.
10                                                               greenbytes
11                                                             May 23, 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 24, 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 4.2.1., paragraph 4:
104OLD:
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
109NEW:
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
115Section 4.2.4., paragraph 2:
116OLD:
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
124NEW:
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
133Section 5.2.1.3., paragraph 4:
134OLD:
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
140NEW:
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
147Section 5.2.2.6., paragraph 7:
148OLD:
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
157NEW:
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
167Section 7.1., paragraph 1:
168OLD:
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
175NEW:
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
182Section 7.1.3., paragraph 1:
183OLD:
184
185    The registry has been populated with the registrations below:
186
187NEW:
188
189    The "HTTP Cache Directive Registry" shall be populated with the
190    registrations below:
191
192
193Section 7.2., paragraph 1:
194OLD:
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
200NEW:
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
207Section 7.2.1., paragraph 5:
208OLD:
209
210    Values to be added to this namespace require IETF Review (see
211    [RFC5226], Section 4.1).
212
213NEW:
214
215    Values to be added to this name pace require IETF Review (see
216    [RFC5226], Section 4.1).
217
218
219Section 7.2.2., paragraph 1:
220OLD:
221
222    The registry has been populated with the registrations below:
223
224NEW:
225
226    The "HTTP Warn Codes" registry has been populated with the
227    registrations below:
228
229
230Section 7.3., paragraph 1:
231OLD:
232
233    HTTP header fields are registered within the "Message Headers"
234    registry maintained at
235    <http://www.iana.org/assignments/message-headers/>.
236
237NEW:
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
244Section 7.3., paragraph 2:
245OLD:
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
251NEW:
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
258Section 10.1., paragraph 3:
259OLD:
260
261    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
262               Protocol (HTTP/1.1): Message Syntax and Routing",
263               draft-ietf-httpbis-p1-messaging-latest (work in progress),
264               May 2014.
265
266NEW:
267
268    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
269               Protocol (HTTP/1.1): Message Syntax and Routing",
270               RFC 7230, May 2014.
271
272
273Section 10.1., paragraph 4:
274OLD:
275
276    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
277               Protocol (HTTP/1.1): Semantics and Content",
278               draft-ietf-httpbis-p2-semantics-latest (work in progress),
279               May 2014.
280
281NEW:
282
283    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
284               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
285               May 2014.
286
287
288Section 10.1., paragraph 5:
289OLD:
290
291    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
292               Protocol (HTTP/1.1): Conditional Requests",
293               draft-ietf-httpbis-p4-conditional-latest (work in
294               progress), May 2014.
295
296NEW:
297
298    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
299               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
300               May 2014.
301
302
303Section 10.1., paragraph 6:
304OLD:
305
306    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
307               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
308               draft-ietf-httpbis-p5-range-latest (work in progress),
309               May 2014.
310
311NEW:
312
313    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
314               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
315               RFC 7233, May 2014.
316
317
318Section 10.1., paragraph 7:
319OLD:
320
321    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
322               Protocol (HTTP/1.1): Authentication",
323               draft-ietf-httpbis-p7-auth-latest (work in progress),
324               May 2014.
325
326NEW:
327
328    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
329               Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014.
330
331
332Appendix A., paragraph 3:
333OLD:
334
335    New status codes can now define that caches are allowed to use
336    heuristic freshness with them.  Caches are now allowed to calculate
337    heuristic freshness for URIs with query components.  (Section 4.2.2)
338 
339    The algorithm for calculating age is now less conservative.  Caches
340    are now required to handle dates with time zones as if they're
341    invalid, because it's not possible to accurately guess.
342    (Section 4.2.3)
343
344NEW:
345
346    New status codes can now define that caches are allowed to use
347    heuristic freshness with them.  Caches are now allowed to calculate
348    heuristic freshness for URIs with query components.  (Section 4.2.2)
349    The algorithm for calculating age is now less conservative.  Caches
350    are now required to handle dates with time zones as if they're
351    invalid, because it's not possible to accurately guess.
352    (Section 4.2.3)
353
354
355Appendix A., paragraph 5:
356OLD:
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
363NEW:
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
371Appendix A., paragraph 15:
372OLD:
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
378NEW:
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 TracBrowser for help on using the repository browser.