source: draft-ietf-httpbis/09/draft-ietf-httpbis-p7-auth-09.txt @ 772

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

Prepare publication of -09 drafts on March 08

  • Property svn:executable set to *
File size: 29.8 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Updates: 2617 (if approved)                         One Laptop per Child
8Intended status: Standards Track                                J. Mogul
9Expires: September 9, 2010                                            HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                           March 8, 2010
23
24
25                    HTTP/1.1, part 7: Authentication
26                     draft-ietf-httpbis-p7-auth-09
27
28Abstract
29
30   The Hypertext Transfer Protocol (HTTP) is an application-level
31   protocol for distributed, collaborative, hypermedia information
32   systems.  HTTP has been in use by the World Wide Web global
33   information initiative since 1990.  This document is Part 7 of the
34   seven-part specification that defines the protocol referred to as
35   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 7 defines
36   HTTP Authentication.
37
38Editorial Note (To be removed by RFC Editor)
39
40   Discussion of this draft should take place on the HTTPBIS working
41   group mailing list (ietf-http-wg@w3.org).  The current issues list is
42   at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
43   documents (including fancy diffs) can be found at
44   <http://tools.ietf.org/wg/httpbis/>.
45
46   The changes in this draft are summarized in Appendix C.10.
47
48Status of this Memo
49
50   This Internet-Draft is submitted to IETF in full conformance with the
51   provisions of BCP 78 and BCP 79.
52
53
54
55Fielding, et al.        Expires September 9, 2010               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7                  March 2010
58
59
60   Internet-Drafts are working documents of the Internet Engineering
61   Task Force (IETF), its areas, and its working groups.  Note that
62   other groups may also distribute working documents as Internet-
63   Drafts.
64
65   Internet-Drafts are draft documents valid for a maximum of six months
66   and may be updated, replaced, or obsoleted by other documents at any
67   time.  It is inappropriate to use Internet-Drafts as reference
68   material or to cite them other than as "work in progress."
69
70   The list of current Internet-Drafts can be accessed at
71   http://www.ietf.org/ietf/1id-abstracts.txt.
72
73   The list of Internet-Draft Shadow Directories can be accessed at
74   http://www.ietf.org/shadow.html.
75
76   This Internet-Draft will expire on September 9, 2010.
77
78Copyright Notice
79
80   Copyright (c) 2010 IETF Trust and the persons identified as the
81   document authors.  All rights reserved.
82
83   This document is subject to BCP 78 and the IETF Trust's Legal
84   Provisions Relating to IETF Documents
85   (http://trustee.ietf.org/license-info) in effect on the date of
86   publication of this document.  Please review these documents
87   carefully, as they describe your rights and restrictions with respect
88   to this document.  Code Components extracted from this document must
89   include Simplified BSD License text as described in Section 4.e of
90   the Trust Legal Provisions and are provided without warranty as
91   described in the BSD License.
92
93   This document may contain material from IETF Documents or IETF
94   Contributions published or made publicly available before November
95   10, 2008.  The person(s) controlling the copyright in some of this
96   material may not have granted the IETF Trust the right to allow
97   modifications of such material outside the IETF Standards Process.
98   Without obtaining an adequate license from the person(s) controlling
99   the copyright in such materials, this document may not be modified
100   outside the IETF Standards Process, and derivative works of it may
101   not be created outside the IETF Standards Process, except to format
102   it for publication as an RFC or to translate it into languages other
103   than English.
104
105
106
107
108
109
110
111Fielding, et al.        Expires September 9, 2010               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7                  March 2010
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
120     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
121       1.2.1.  Core Rules . . . . . . . . . . . . . . . . . . . . . .  5
122       1.2.2.  ABNF Rules defined in other Parts of the
123               Specification  . . . . . . . . . . . . . . . . . . . .  5
124   2.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  5
125     2.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  5
126     2.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  5
127   3.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  5
128     3.1.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  6
129     3.2.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  6
130     3.3.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  7
131     3.4.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  7
132   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
133     4.1.  Status Code Registration . . . . . . . . . . . . . . . . .  8
134     4.2.  Message Header Registration  . . . . . . . . . . . . . . .  8
135   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
136     5.1.  Authentication Credentials and Idle Clients  . . . . . . .  9
137   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
138   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
139     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
140     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
141   Appendix A.  Compatibility with Previous Versions  . . . . . . . . 10
142     A.1.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 10
143   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 11
144   Appendix C.  Change Log (to be removed by RFC Editor before
145                publication)  . . . . . . . . . . . . . . . . . . . . 11
146     C.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 11
147     C.2.  Since draft-ietf-httpbis-p7-auth-00  . . . . . . . . . . . 11
148     C.3.  Since draft-ietf-httpbis-p7-auth-01  . . . . . . . . . . . 11
149     C.4.  Since draft-ietf-httpbis-p7-auth-02  . . . . . . . . . . . 12
150     C.5.  Since draft-ietf-httpbis-p7-auth-03  . . . . . . . . . . . 12
151     C.6.  Since draft-ietf-httpbis-p7-auth-04  . . . . . . . . . . . 12
152     C.7.  Since draft-ietf-httpbis-p7-auth-05  . . . . . . . . . . . 12
153     C.8.  Since draft-ietf-httpbis-p7-auth-06  . . . . . . . . . . . 12
154     C.9.  Since draft-ietf-httpbis-p7-auth-07  . . . . . . . . . . . 12
155     C.10. Since draft-ietf-httpbis-p7-auth-08  . . . . . . . . . . . 13
156   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
157   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
158
159
160
161
162
163
164
165
166
167Fielding, et al.        Expires September 9, 2010               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7                  March 2010
170
171
1721.  Introduction
173
174   This document defines HTTP/1.1 access control and authentication.
175   Right now it includes the extracted relevant sections of RFC 2616
176   with only minor changes.  The intention is to move the general
177   framework for HTTP authentication here, as currently specified in
178   [RFC2617], and allow the individual authentication mechanisms to be
179   defined elsewhere.  This introduction will be rewritten when that
180   occurs.
181
182   HTTP provides several OPTIONAL challenge-response authentication
183   mechanisms which can be used by a server to challenge a client
184   request and by a client to provide authentication information.  The
185   general framework for access authentication, and the specification of
186   "basic" and "digest" authentication, are specified in "HTTP
187   Authentication: Basic and Digest Access Authentication" [RFC2617].
188   This specification adopts the definitions of "challenge" and
189   "credentials" from that specification.
190
1911.1.  Requirements
192
193   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
194   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
195   document are to be interpreted as described in [RFC2119].
196
197   An implementation is not compliant if it fails to satisfy one or more
198   of the MUST or REQUIRED level requirements for the protocols it
199   implements.  An implementation that satisfies all the MUST or
200   REQUIRED level and all the SHOULD level requirements for its
201   protocols is said to be "unconditionally compliant"; one that
202   satisfies all the MUST level requirements but not all the SHOULD
203   level requirements for its protocols is said to be "conditionally
204   compliant."
205
2061.2.  Syntax Notation
207
208   This specification uses the ABNF syntax defined in Section 1.2 of
209   [Part1] (which extends the syntax defined in [RFC5234] with a list
210   rule).  Appendix B shows the collected ABNF, with the list rule
211   expanded.
212
213   The following core rules are included by reference, as defined in
214   [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
215   (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
216   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
217   sequence of data), SP (space), VCHAR (any visible USASCII character),
218   and WSP (whitespace).
219
220
221
222
223Fielding, et al.        Expires September 9, 2010               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7                  March 2010
226
227
2281.2.1.  Core Rules
229
230   The core rules below are defined in Section 1.2.2 of [Part1]:
231
232     OWS         = <OWS, defined in [Part1], Section 1.2.2>
233
2341.2.2.  ABNF Rules defined in other Parts of the Specification
235
236   The ABNF rules below are defined in other specifications:
237
238     challenge   = <challenge, defined in [RFC2617], Section 1.2>
239     credentials = <credentials, defined in [RFC2617], Section 1.2>
240
241
2422.  Status Code Definitions
243
2442.1.  401 Unauthorized
245
246   The request requires user authentication.  The response MUST include
247   a WWW-Authenticate header field (Section 3.4) containing a challenge
248   applicable to the requested resource.  The client MAY repeat the
249   request with a suitable Authorization header field (Section 3.1).  If
250   the request already included Authorization credentials, then the 401
251   response indicates that authorization has been refused for those
252   credentials.  If the 401 response contains the same challenge as the
253   prior response, and the user agent has already attempted
254   authentication at least once, then the user SHOULD be presented the
255   entity that was given in the response, since that entity might
256   include relevant diagnostic information.  HTTP access authentication
257   is explained in "HTTP Authentication: Basic and Digest Access
258   Authentication" [RFC2617].
259
2602.2.  407 Proxy Authentication Required
261
262   This code is similar to 401 (Unauthorized), but indicates that the
263   client must first authenticate itself with the proxy.  The proxy MUST
264   return a Proxy-Authenticate header field (Section 3.2) containing a
265   challenge applicable to the proxy for the requested resource.  The
266   client MAY repeat the request with a suitable Proxy-Authorization
267   header field (Section 3.3).  HTTP access authentication is explained
268   in "HTTP Authentication: Basic and Digest Access Authentication"
269   [RFC2617].
270
271
2723.  Header Field Definitions
273
274   This section defines the syntax and semantics of HTTP/1.1 header
275   fields related to authentication.
276
277
278
279Fielding, et al.        Expires September 9, 2010               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7                  March 2010
282
283
2843.1.  Authorization
285
286   The "Authorization" request-header field allows a user agent to
287   authenticate itself with a server -- usually, but not necessarily,
288   after receiving a 401 (Unauthorized) response.  Its value consists of
289   credentials containing information of the user agent for the realm of
290   the resource being requested.
291
292     Authorization   = "Authorization" ":" OWS Authorization-v
293     Authorization-v = credentials
294
295   HTTP access authentication is described in "HTTP Authentication:
296   Basic and Digest Access Authentication" [RFC2617].  If a request is
297   authenticated and a realm specified, the same credentials SHOULD be
298   valid for all other requests within this realm (assuming that the
299   authentication scheme itself does not require otherwise, such as
300   credentials that vary according to a challenge value or using
301   synchronized clocks).
302
303   When a shared cache (see Section 1.2 of [Part6]) receives a request
304   containing an Authorization field, it MUST NOT return the
305   corresponding response as a reply to any other request, unless one of
306   the following specific exceptions holds:
307
308   1.  If the response includes the "s-maxage" cache-control directive,
309       the cache MAY use that response in replying to a subsequent
310       request.  But (if the specified maximum age has passed) a proxy
311       cache MUST first revalidate it with the origin server, using the
312       request-headers from the new request to allow the origin server
313       to authenticate the new request.  (This is the defined behavior
314       for s-maxage.)  If the response includes "s-maxage=0", the proxy
315       MUST always revalidate it before re-using it.
316
317   2.  If the response includes the "must-revalidate" cache-control
318       directive, the cache MAY use that response in replying to a
319       subsequent request.  But if the response is stale, all caches
320       MUST first revalidate it with the origin server, using the
321       request-headers from the new request to allow the origin server
322       to authenticate the new request.
323
324   3.  If the response includes the "public" cache-control directive, it
325       MAY be returned in reply to any subsequent request.
326
3273.2.  Proxy-Authenticate
328
329   The "Proxy-Authenticate" response-header field consists of a
330   challenge that indicates the authentication scheme and parameters
331   applicable to the proxy for this request-target.  It MUST be included
332
333
334
335Fielding, et al.        Expires September 9, 2010               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7                  March 2010
338
339
340   as part of a 407 (Proxy Authentication Required) response.
341
342     Proxy-Authenticate   = "Proxy-Authenticate" ":" OWS
343                            Proxy-Authenticate-v
344     Proxy-Authenticate-v = 1#challenge
345
346   The HTTP access authentication process is described in "HTTP
347   Authentication: Basic and Digest Access Authentication" [RFC2617].
348   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
349   only to the current connection and SHOULD NOT be passed on to
350   downstream clients.  However, an intermediate proxy might need to
351   obtain its own credentials by requesting them from the downstream
352   client, which in some circumstances will appear as if the proxy is
353   forwarding the Proxy-Authenticate header field.
354
3553.3.  Proxy-Authorization
356
357   The "Proxy-Authorization" request-header field allows the client to
358   identify itself (or its user) to a proxy which requires
359   authentication.  Its value consists of credentials containing the
360   authentication information of the user agent for the proxy and/or
361   realm of the resource being requested.
362
363     Proxy-Authorization   = "Proxy-Authorization" ":" OWS
364                             Proxy-Authorization-v
365     Proxy-Authorization-v = credentials
366
367   The HTTP access authentication process is described in "HTTP
368   Authentication: Basic and Digest Access Authentication" [RFC2617].
369   Unlike Authorization, the Proxy-Authorization header field applies
370   only to the next outbound proxy that demanded authentication using
371   the Proxy-Authenticate field.  When multiple proxies are used in a
372   chain, the Proxy-Authorization header field is consumed by the first
373   outbound proxy that was expecting to receive credentials.  A proxy
374   MAY relay the credentials from the client request to the next proxy
375   if that is the mechanism by which the proxies cooperatively
376   authenticate a given request.
377
3783.4.  WWW-Authenticate
379
380   The "WWW-Authenticate" response-header field consists of at least one
381   challenge that indicates the authentication scheme(s) and parameters
382   applicable to the request-target.  It MUST be included in 401
383   (Unauthorized) response messages.
384
385     WWW-Authenticate   = "WWW-Authenticate" ":" OWS WWW-Authenticate-v
386     WWW-Authenticate-v = 1#challenge
387
388
389
390
391Fielding, et al.        Expires September 9, 2010               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7                  March 2010
394
395
396   The HTTP access authentication process is described in "HTTP
397   Authentication: Basic and Digest Access Authentication" [RFC2617].
398   User agents are advised to take special care in parsing the WWW-
399   Authenticate field value as it might contain more than one challenge,
400   or if more than one WWW-Authenticate header field is provided, the
401   contents of a challenge itself can contain a comma-separated list of
402   authentication parameters.
403
404
4054.  IANA Considerations
406
4074.1.  Status Code Registration
408
409   The HTTP Status Code Registry located at
410   <http://www.iana.org/assignments/http-status-codes> should be updated
411   with the registrations below:
412
413   +-------+-------------------------------+-------------+
414   | Value | Description                   | Reference   |
415   +-------+-------------------------------+-------------+
416   | 401   | Unauthorized                  | Section 2.1 |
417   | 407   | Proxy Authentication Required | Section 2.2 |
418   +-------+-------------------------------+-------------+
419
4204.2.  Message Header Registration
421
422   The Message Header Registry located at <http://www.iana.org/
423   assignments/message-headers/message-header-index.html> should be
424   updated with the permanent registrations below (see [RFC3864]):
425
426   +---------------------+----------+----------+-------------+
427   | Header Field Name   | Protocol | Status   | Reference   |
428   +---------------------+----------+----------+-------------+
429   | Authorization       | http     | standard | Section 3.1 |
430   | Proxy-Authenticate  | http     | standard | Section 3.2 |
431   | Proxy-Authorization | http     | standard | Section 3.3 |
432   | WWW-Authenticate    | http     | standard | Section 3.4 |
433   +---------------------+----------+----------+-------------+
434
435   The change controller is: "IETF (iesg@ietf.org) - Internet
436   Engineering Task Force".
437
438
4395.  Security Considerations
440
441   This section is meant to inform application developers, information
442   providers, and users of the security limitations in HTTP/1.1 as
443   described by this document.  The discussion does not include
444
445
446
447Fielding, et al.        Expires September 9, 2010               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7                  March 2010
450
451
452   definitive solutions to the problems revealed, though it does make
453   some suggestions for reducing security risks.
454
4555.1.  Authentication Credentials and Idle Clients
456
457   Existing HTTP clients and user agents typically retain authentication
458   information indefinitely.  HTTP/1.1 does not provide a method for a
459   server to direct clients to discard these cached credentials.  This
460   is a significant defect that requires further extensions to HTTP.
461   Circumstances under which credential caching can interfere with the
462   application's security model include but are not limited to:
463
464   o  Clients which have been idle for an extended period following
465      which the server might wish to cause the client to reprompt the
466      user for credentials.
467
468   o  Applications which include a session termination indication (such
469      as a "logout" or "commit" button on a page) after which the server
470      side of the application "knows" that there is no further reason
471      for the client to retain the credentials.
472
473   This is currently under separate study.  There are a number of work-
474   arounds to parts of this problem, and we encourage the use of
475   password protection in screen savers, idle time-outs, and other
476   methods which mitigate the security problems inherent in this
477   problem.  In particular, user agents which cache credentials are
478   encouraged to provide a readily accessible mechanism for discarding
479   cached credentials under user control.
480
481
4826.  Acknowledgments
483
484   [[acks: TBD.]]
485
486
4877.  References
488
4897.1.  Normative References
490
491   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
492              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
493              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
494              and Message Parsing", draft-ietf-httpbis-p1-messaging-09
495              (work in progress), March 2010.
496
497   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
498              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
499              Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
500
501
502
503Fielding, et al.        Expires September 9, 2010               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7                  March 2010
506
507
508              6: Caching", draft-ietf-httpbis-p6-cache-09 (work in
509              progress), March 2010.
510
511   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
512              Requirement Levels", BCP 14, RFC 2119, March 1997.
513
514   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
515              Leach, P., Luotonen, A., and L. Stewart, "HTTP
516              Authentication: Basic and Digest Access Authentication",
517              RFC 2617, June 1999.
518
519   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
520              Specifications: ABNF", STD 68, RFC 5234, January 2008.
521
5227.2.  Informative References
523
524   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
525              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
526              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
527
528   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
529              Procedures for Message Header Fields", BCP 90, RFC 3864,
530              September 2004.
531
532
533Appendix A.  Compatibility with Previous Versions
534
535A.1.  Changes from RFC 2616
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559Fielding, et al.        Expires September 9, 2010              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7                  March 2010
562
563
564Appendix B.  Collected ABNF
565
566   Authorization = "Authorization:" OWS Authorization-v
567   Authorization-v = credentials
568
569   OWS = <OWS, defined in [Part1], Section 1.2.2>
570
571   Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v
572   Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
573    challenge ] )
574   Proxy-Authorization = "Proxy-Authorization:" OWS
575    Proxy-Authorization-v
576   Proxy-Authorization-v = credentials
577
578   WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v
579   WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
580    challenge ] )
581
582   challenge = <challenge, defined in [RFC2617], Section 1.2>
583   credentials = <credentials, defined in [RFC2617], Section 1.2>
584
585   ABNF diagnostics:
586
587   ; Authorization defined but not used
588   ; Proxy-Authenticate defined but not used
589   ; Proxy-Authorization defined but not used
590   ; WWW-Authenticate defined but not used
591
592
593Appendix C.  Change Log (to be removed by RFC Editor before publication)
594
595C.1.  Since RFC2616
596
597   Extracted relevant partitions from [RFC2616].
598
599C.2.  Since draft-ietf-httpbis-p7-auth-00
600
601   Closed issues:
602
603   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
604      Informative references"
605
606C.3.  Since draft-ietf-httpbis-p7-auth-01
607
608   Ongoing work on ABNF conversion
609   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
610
611
612
613
614
615Fielding, et al.        Expires September 9, 2010              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7                  March 2010
618
619
620   o  Explicitly import BNF rules for "challenge" and "credentials" from
621      RFC2617.
622
623   o  Add explicit references to BNF syntax and rules imported from
624      other parts of the specification.
625
626C.4.  Since draft-ietf-httpbis-p7-auth-02
627
628   Ongoing work on IANA Message Header Registration
629   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
630
631   o  Reference RFC 3984, and update header registrations for headers
632      defined in this document.
633
634C.5.  Since draft-ietf-httpbis-p7-auth-03
635
636C.6.  Since draft-ietf-httpbis-p7-auth-04
637
638   Ongoing work on ABNF conversion
639   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
640
641   o  Use "/" instead of "|" for alternatives.
642
643   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
644      whitespace ("OWS") and required whitespace ("RWS").
645
646   o  Rewrite ABNFs to spell out whitespace rules, factor out header
647      value format definitions.
648
649C.7.  Since draft-ietf-httpbis-p7-auth-05
650
651   Final work on ABNF conversion
652   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
653
654   o  Add appendix containing collected and expanded ABNF, reorganize
655      ABNF introduction.
656
657C.8.  Since draft-ietf-httpbis-p7-auth-06
658
659   None.
660
661C.9.  Since draft-ietf-httpbis-p7-auth-07
662
663   Closed issues:
664
665   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
666      registrations for optional status codes"
667
668
669
670
671Fielding, et al.        Expires September 9, 2010              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7                  March 2010
674
675
676C.10.  Since draft-ietf-httpbis-p7-auth-08
677
678   No significant changes.
679
680
681Index
682
683   4
684      401 Unauthorized (status code)  5
685      407 Proxy Authentication Required (status code)  5
686
687   A
688      Authorization header  6
689
690   G
691      Grammar
692         Authorization  6
693         Authorization-v  6
694         challenge  5
695         credentials  5
696         Proxy-Authenticate  7
697         Proxy-Authenticate-v  7
698         Proxy-Authorization  7
699         Proxy-Authorization-v  7
700         WWW-Authenticate  7
701         WWW-Authenticate-v  7
702
703   H
704      Headers
705         Authorization  6
706         Proxy-Authenticate  6
707         Proxy-Authorization  7
708         WWW-Authenticate  7
709
710   P
711      Proxy-Authenticate header  6
712      Proxy-Authorization header  7
713
714   S
715      Status Codes
716         401 Unauthorized  5
717         407 Proxy Authentication Required  5
718
719   W
720      WWW-Authenticate header  7
721
722
723
724
725
726
727Fielding, et al.        Expires September 9, 2010              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 7                  March 2010
730
731
732Authors' Addresses
733
734   Roy T. Fielding (editor)
735   Day Software
736   23 Corporate Plaza DR, Suite 280
737   Newport Beach, CA  92660
738   USA
739
740   Phone: +1-949-706-5300
741   Fax:   +1-949-706-5305
742   Email: fielding@gbiv.com
743   URI:   http://roy.gbiv.com/
744
745
746   Jim Gettys
747   One Laptop per Child
748   21 Oak Knoll Road
749   Carlisle, MA  01741
750   USA
751
752   Email: jg@laptop.org
753   URI:   http://www.laptop.org/
754
755
756   Jeffrey C. Mogul
757   Hewlett-Packard Company
758   HP Labs, Large Scale Systems Group
759   1501 Page Mill Road, MS 1177
760   Palo Alto, CA  94304
761   USA
762
763   Email: JeffMogul@acm.org
764
765
766   Henrik Frystyk Nielsen
767   Microsoft Corporation
768   1 Microsoft Way
769   Redmond, WA  98052
770   USA
771
772   Email: henrikn@microsoft.com
773
774
775
776
777
778
779
780
781
782
783Fielding, et al.        Expires September 9, 2010              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 7                  March 2010
786
787
788   Larry Masinter
789   Adobe Systems, Incorporated
790   345 Park Ave
791   San Jose, CA  95110
792   USA
793
794   Email: LMM@acm.org
795   URI:   http://larry.masinter.net/
796
797
798   Paul J. Leach
799   Microsoft Corporation
800   1 Microsoft Way
801   Redmond, WA  98052
802
803   Email: paulle@microsoft.com
804
805
806   Tim Berners-Lee
807   World Wide Web Consortium
808   MIT Computer Science and Artificial Intelligence Laboratory
809   The Stata Center, Building 32
810   32 Vassar Street
811   Cambridge, MA  02139
812   USA
813
814   Email: timbl@w3.org
815   URI:   http://www.w3.org/People/Berners-Lee/
816
817
818   Yves Lafon (editor)
819   World Wide Web Consortium
820   W3C / ERCIM
821   2004, rte des Lucioles
822   Sophia-Antipolis, AM  06902
823   France
824
825   Email: ylafon@w3.org
826   URI:   http://www.raubacapeu.net/people/yves/
827
828
829
830
831
832
833
834
835
836
837
838
839Fielding, et al.        Expires September 9, 2010              [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 7                  March 2010
842
843
844   Julian F. Reschke (editor)
845   greenbytes GmbH
846   Hafenweg 16
847   Muenster, NW  48155
848   Germany
849
850   Phone: +49 251 2807760
851   Fax:   +49 251 2807761
852   Email: julian.reschke@greenbytes.de
853   URI:   http://greenbytes.de/tech/webdav/
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895Fielding, et al.        Expires September 9, 2010              [Page 16]
896
Note: See TracBrowser for help on using the repository browser.