source: draft-ietf-httpbis/latest/auth48/rfc7235.abdiff.txt @ 2692

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

editorial fixes (#553)

File size: 14.5 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2616 (if approved)                            J. Reschke, Ed.
8 Updates: 2617 (if approved)                                   greenbytes
9 Intended status: Standards Track                            May 25, 2014
10 Expires: November 26, 2014
11
12NEW:
13
14 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
15 Request for Comments: 7235                                         Adobe
16 Obsoletes: 2616                                          J. Reschke, Ed.
17 Updates: 2617                                                 greenbytes
18 Category: Standards Track                                       May 2014
19 ISSN: 2070-1721
20
21
22INTRODUCTION, paragraph 2:
23OLD:
24
25          Hypertext Transfer Protocol (HTTP/1.1): Authentication
26                    draft-ietf-httpbis-p7-auth-latest
27
28NEW:
29
30          Hypertext Transfer Protocol (HTTP/1.1): Authentication
31
32
33INTRODUCTION, paragraph 5:
34OLD:
35
36 Editorial Note (To be removed by RFC Editor)
37 
38    Discussion of this draft takes place on the HTTPBIS working group
39    mailing list (ietf-http-wg@w3.org), which is archived at
40    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
41 
42    The current issues list is at
43    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
44    documents (including fancy diffs) can be found at
45    <http://tools.ietf.org/wg/httpbis/>.
46 
47    _This is a temporary document for the purpose of tracking the
48    editorial changes made during the AUTH48 (RFC publication) phase._
49 
50 Status of This Memo
51
52NEW:
53
54 Status of This Memo
55
56
57INTRODUCTION, paragraph 6:
58OLD:
59
60    This Internet-Draft is submitted in full conformance with the
61    provisions of BCP 78 and BCP 79.
62 
63    Internet-Drafts are working documents of the Internet Engineering
64    Task Force (IETF).  Note that other groups may also distribute
65    working documents as Internet-Drafts.  The list of current Internet-
66    Drafts is at http://datatracker.ietf.org/drafts/current/.
67
68NEW:
69
70    This is an Internet Standards Track document.
71
72
73INTRODUCTION, paragraph 7:
74OLD:
75
76    Internet-Drafts are draft documents valid for a maximum of six months
77    and may be updated, replaced, or obsoleted by other documents at any
78    time.  It is inappropriate to use Internet-Drafts as reference
79    material or to cite them other than as "work in progress."
80
81NEW:
82
83    This document is a product of the Internet Engineering Task Force
84    (IETF).  It represents the consensus of the IETF community.  It has
85    received public review and has been approved for publication by the
86    Internet Engineering Steering Group (IESG).  Further information on
87    Internet Standards is available in Section 2 of RFC 5741.
88
89
90INTRODUCTION, paragraph 8:
91OLD:
92
93    This Internet-Draft will expire on November 26, 2014.
94
95NEW:
96
97    Information about the current status of this document, any errata,
98    and how to provide feedback on it may be obtained at
99    http://www.rfc-editor.org/info/rfc7235.
100
101
102INTRODUCTION, paragraph 14:
103OLD:
104
105    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
106      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
107      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
108    2.  Access Authentication Framework  . . . . . . . . . . . . . . .  4
109      2.1.  Challenge and Response . . . . . . . . . . . . . . . . . .  4
110      2.2.  Protection Space (Realm) . . . . . . . . . . . . . . . . .  6
111    3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  7
112      3.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  7
113      3.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  7
114    4.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  7
115      4.1.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  8
116      4.2.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  8
117      4.3.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  9
118      4.4.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  9
119    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
120      5.1.  Authentication Scheme Registry . . . . . . . . . . . . . . 10
121        5.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 10
122        5.1.2.  Considerations for New Authentication Schemes  . . . . 10
123      5.2.  Status Code Registration . . . . . . . . . . . . . . . . . 12
124      5.3.  Header Field Registration  . . . . . . . . . . . . . . . . 12
125    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
126      6.1.  Confidentiality of Credentials . . . . . . . . . . . . . . 13
127      6.2.  Authentication Credentials and Idle Clients  . . . . . . . 13
128      6.3.  Protection Spaces  . . . . . . . . . . . . . . . . . . . . 14
129    7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
130    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
131      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
132      8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
133    Appendix A.  Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16
134    Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 16
135    Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 16
136    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
137
138NEW:
139
140    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
141      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  3
142      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  3
143    2.  Access Authentication Framework  . . . . . . . . . . . . . . .  3
144      2.1.  Challenge and Response . . . . . . . . . . . . . . . . . .  3
145      2.2.  Protection Space (Realm) . . . . . . . . . . . . . . . . .  5
146    3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  6
147      3.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  6
148      3.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  6
149    4.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  6
150      4.1.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  7
151      4.2.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  7
152      4.3.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  8
153      4.4.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  8
154    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
155      5.1.  Authentication Scheme Registry . . . . . . . . . . . . . .  9
156        5.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . .  9
157        5.1.2.  Considerations for New Authentication Schemes  . . . .  9
158      5.2.  Status Code Registration . . . . . . . . . . . . . . . . . 11
159      5.3.  Header Field Registration  . . . . . . . . . . . . . . . . 11
160    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
161      6.1.  Confidentiality of Credentials . . . . . . . . . . . . . . 12
162      6.2.  Authentication Credentials and Idle Clients  . . . . . . . 12
163      6.3.  Protection Spaces  . . . . . . . . . . . . . . . . . . . . 13
164    7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
165    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
166      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
167      8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
168    Appendix A.  Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15
169    Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 15
170    Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 15
171    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
172
173
174Section 1., paragraph 1:
175OLD:
176
177    HTTP provides a general framework for access control and
178    authentication, via an extensible set of challenge-response
179    authentication schemes, which can be used by a server to challenge a
180    client request and by a client to provide authentication information.
181    This document defines HTTP/1.1 authentication in terms of the
182    architecture defined in [RFC7230], including the general framework
183    previously described in RFC 2617 and the related fields and status
184    codes previously defined in RFC 2616.
185
186NEW:
187
188    HTTP provides a general framework for access control and
189    authentication, via an extensible set of challenge-response
190    authentication schemes, which can be used by a server to challenge a
191    client request and by a client to provide authentication information.
192    This document defines HTTP/1.1 authentication in terms of the
193    architecture defined in [RFC7230], including the general framework
194    previously described in [RFC2617] and the related fields and status
195    codes previously defined in [RFC2616].
196
197
198Section 5.1., paragraph 1:
199OLD:
200
201    The "Hypertext Transfer Protocol (HTTP) Authentication Scheme
202    Registry" defines the namespace for the authentication schemes in
203    challenges and credentials.  It will has been created and is now
204    maintained at <http://www.iana.org/assignments/http-authschemes>.
205
206NEW:
207
208    The "HTTP Authentication Schemes" registry defines the name space for
209    the authentication schemes in challenges and credentials.  The
210    registry has been created and is now maintained at
211    <http://www.iana.org/assignments/http-authschemes>.
212
213
214Section 5.2., paragraph 1:
215OLD:
216
217    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
218    at <http://www.iana.org/assignments/http-status-codes> has been
219    updated with the registrations below:
220
221NEW:
222
223    The HTTP Status Code Registry located at
224    <http://www.iana.org/assignments/http-status-codes> shall be updated
225    with the registrations below:
226
227
228Section 5.3., paragraph 1:
229OLD:
230
231    HTTP header fields are registered within the "Message Headers"
232    registry maintained at
233    <http://www.iana.org/assignments/message-headers/>.
234
235NEW:
236
237    HTTP header fields are registered within the Message Header Field
238    Registry maintained at
239    <http://www.iana.org/assignments/message-headers>.
240
241
242Section 5.3., paragraph 2:
243OLD:
244
245    This document defines the following HTTP header fields, so the
246    "Permanent Message Header Field Names" registry has been updated
247    accordingly (see [BCP90]).
248
249NEW:
250
251    This document defines the following HTTP header fields, so their
252    associated registry entries have been updated according to the
253    permanent registrations below (see [BCP90]):
254
255
256Section 6.1., paragraph 2:
257OLD:
258
259    HTTP depends on the security properties of the underlying transport-
260    or session-level connection to provide confidential transmission of
261    header fields.  In other words, if a server limits access to
262    authenticated users using this framework, the server needs to ensure
263    that the connection is properly secured in accordance with the nature
264    of the authentication scheme used.  For example, services that depend
265    on individual user authentication often require a connection to be
266    secured with TLS ("Transport Layer Security", [RFC5246]) prior to
267    exchanging any credentials.
268
269NEW:
270
271    HTTP depends on the security properties of the underlying transport
272    or session-level connection to provide confidential transmission of
273    header fields.  In other words, if a server limits access to
274    authenticated users using this framework, the server needs to ensure
275    that the connection is properly secured in accordance with the nature
276    of the authentication scheme used.  For example, services that depend
277    on individual user authentication often require a connection to be
278    secured with TLS ("Transport Layer Security", [RFC5246]) prior to
279    exchanging any credentials.
280
281
282Section 8.1., paragraph 3:
283OLD:
284
285    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
286               Protocol (HTTP/1.1): Message Syntax and Routing",
287               draft-ietf-httpbis-p1-messaging-latest (work in progress),
288               May 2014.
289
290NEW:
291
292    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
293               Protocol (HTTP/1.1): Message Syntax and Routing",
294               RFC 7230, May 2014.
295
296
297Section 8.1., paragraph 4:
298OLD:
299
300    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
301               Protocol (HTTP/1.1): Semantics and Content",
302               draft-ietf-httpbis-p2-semantics-latest (work in progress),
303               May 2014.
304
305NEW:
306
307    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
308               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
309               May 2014.
310
311
312Section 8.1., paragraph 5:
313OLD:
314
315    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
316               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
317               draft-ietf-httpbis-p6-cache-latest (work in progress),
318               May 2014.
319
320NEW:
321
322    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
323               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
324               RFC 7234, May 2014.
325
326
327Section 1.2, paragraph 11:
328OLD:
329
330    4
331       401 Unauthorized (status code)  7
332       407 Proxy Authentication Required (status code)  7
333
334NEW:
335
336    4
337       401 Unauthorized (status code)  6
338       407 Proxy Authentication Required (status code)  6
339
340
341Section 1.2, paragraph 12:
342OLD:
343
344    A
345       Authorization header field  8
346
347NEW:
348
349    A
350       Authorization header field  7
351
352
353Section 1.2, paragraph 13:
354OLD:
355
356    C
357       Canonical Root URI  6
358
359NEW:
360
361    C
362       Canonical Root URI  5
363
364
365Section 1.2, paragraph 14:
366OLD:
367
368    G
369       Grammar
370          auth-param  5
371          auth-scheme  5
372          Authorization  8
373          challenge  5
374          credentials  6
375          Proxy-Authenticate  9
376          Proxy-Authorization  9
377          token68  5
378          WWW-Authenticate  8
379
380NEW:
381
382    G
383       Grammar
384          auth-param  4
385          auth-scheme  4
386          Authorization  7
387          challenge  4
388          credentials  5
389          Proxy-Authenticate  8
390          Proxy-Authorization  8
391          token68  4
392          WWW-Authenticate  7
393
394
395Section 1.2, paragraph 15:
396OLD:
397
398    P
399       Protection Space  6
400       Proxy-Authenticate header field  9
401       Proxy-Authorization header field  9
402
403NEW:
404
405    P
406       Protection Space  5
407       Proxy-Authenticate header field  8
408       Proxy-Authorization header field  8
409
410
411Section 1.2, paragraph 16:
412OLD:
413
414    R
415       Realm  6
416
417NEW:
418
419    R
420       Realm  5
421
422
423Section 1.2, paragraph 17:
424OLD:
425
426    W
427       WWW-Authenticate header field  8
428
429NEW:
430
431    W
432       WWW-Authenticate header field  7
433
Note: See TracBrowser for help on using the repository browser.