source: draft-ietf-httpbis/02/draft-ietf-httpbis-p7-auth-02.txt @ 377

Last change on this file since 377 was 219, checked in by julian.reschke@…, 12 years ago

Prepare for release of draft 02 on Monday, Feb 24.

  • Property svn:executable set to *
File size: 25.1 KB
Line 
1
2
3
4Network 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: August 27, 2008                                              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                                                       February 24, 2008
23
24
25                    HTTP/1.1, part 7: Authentication
26                     draft-ietf-httpbis-p7-auth-02
27
28Status of this Memo
29
30   By submitting this Internet-Draft, each author represents that any
31   applicable patent or other IPR claims of which he or she is aware
32   have been or will be disclosed, and any of which he or she becomes
33   aware will be disclosed, in accordance with Section 6 of BCP 79.
34
35   Internet-Drafts are working documents of the Internet Engineering
36   Task Force (IETF), its areas, and its working groups.  Note that
37   other groups may also distribute working documents as Internet-
38   Drafts.
39
40   Internet-Drafts are draft documents valid for a maximum of six months
41   and may be updated, replaced, or obsoleted by other documents at any
42   time.  It is inappropriate to use Internet-Drafts as reference
43   material or to cite them other than as "work in progress."
44
45   The list of current Internet-Drafts can be accessed at
46   http://www.ietf.org/ietf/1id-abstracts.txt.
47
48   The list of Internet-Draft Shadow Directories can be accessed at
49   http://www.ietf.org/shadow.html.
50
51   This Internet-Draft will expire on August 27, 2008.
52
53
54
55Fielding, et al.         Expires August 27, 2008                [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7               February 2008
58
59
60Copyright Notice
61
62   Copyright (C) The IETF Trust (2008).
63
64Abstract
65
66   The Hypertext Transfer Protocol (HTTP) is an application-level
67   protocol for distributed, collaborative, hypermedia information
68   systems.  HTTP has been in use by the World Wide Web global
69   information initiative since 1990.  This document is Part 7 of the
70   seven-part specification that defines the protocol referred to as
71   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 7 defines
72   HTTP Authentication.
73
74Editorial Note (To be removed by RFC Editor)
75
76   Discussion of this draft should take place on the HTTPBIS working
77   group mailing list (ietf-http-wg@w3.org).  The current issues list is
78   at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
79   documents (including fancy diffs) can be found at
80   <http://www.tools.ietf.org/wg/httpbis/>.
81
82   This draft incorporates those issue resolutions that were either
83   collected in the original RFC2616 errata list
84   (<http://purl.org/NET/http-errata>), or which were agreed upon on the
85   mailing list between October 2006 and November 2007 (as published in
86   "draft-lafon-rfc2616bis-03").
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.         Expires August 27, 2008                [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7               February 2008
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
120   2.  Notational Conventions and Generic Grammar . . . . . . . . . .  4
121   3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  5
122     3.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  5
123     3.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  5
124   4.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  5
125     4.1.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  5
126     4.2.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  6
127     4.3.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  7
128     4.4.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  7
129   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
130   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
131     6.1.  Authentication Credentials and Idle Clients  . . . . . . .  8
132   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
133   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
134     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
135     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
136   Appendix A.  Compatibility with Previous Versions  . . . . . . . .  9
137     A.1.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . .  9
138   Appendix B.  Change Log (to be removed by RFC Editor before
139                publication)  . . . . . . . . . . . . . . . . . . . .  9
140     B.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . .  9
141     B.2.  Since draft-ietf-httpbis-p7-auth-00  . . . . . . . . . . .  9
142     B.3.  Since draft-ietf-httpbis-p7-auth-01  . . . . . . . . . . .  9
143   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
144   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
145   Intellectual Property and Copyright Statements . . . . . . . . . . 14
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167Fielding, et al.         Expires August 27, 2008                [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7               February 2008
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
206
2072.  Notational Conventions and Generic Grammar
208
209   This specification uses the ABNF syntax defined in Section 2.1 of
210   [Part1]. [[abnf.dep: ABNF syntax and basic rules will be adopted from
211   RFC 5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]]
212
213   The ABNF rules below are defined in other specifications:
214
215     challenge   = <challenge, defined in [RFC2617], Section 1.2>
216     credentials = <credentials, defined in [RFC2617], Section 1.2>
217
218
219
220
221
222
223Fielding, et al.         Expires August 27, 2008                [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7               February 2008
226
227
2283.  Status Code Definitions
229
2303.1.  401 Unauthorized
231
232   The request requires user authentication.  The response MUST include
233   a WWW-Authenticate header field (Section 4.4) containing a challenge
234   applicable to the requested resource.  The client MAY repeat the
235   request with a suitable Authorization header field (Section 4.1).  If
236   the request already included Authorization credentials, then the 401
237   response indicates that authorization has been refused for those
238   credentials.  If the 401 response contains the same challenge as the
239   prior response, and the user agent has already attempted
240   authentication at least once, then the user SHOULD be presented the
241   entity that was given in the response, since that entity might
242   include relevant diagnostic information.  HTTP access authentication
243   is explained in "HTTP Authentication: Basic and Digest Access
244   Authentication" [RFC2617].
245
2463.2.  407 Proxy Authentication Required
247
248   This code is similar to 401 (Unauthorized), but indicates that the
249   client must first authenticate itself with the proxy.  The proxy MUST
250   return a Proxy-Authenticate header field (Section 4.2) containing a
251   challenge applicable to the proxy for the requested resource.  The
252   client MAY repeat the request with a suitable Proxy-Authorization
253   header field (Section 4.3).  HTTP access authentication is explained
254   in "HTTP Authentication: Basic and Digest Access Authentication"
255   [RFC2617].
256
257
2584.  Header Field Definitions
259
260   This section defines the syntax and semantics of HTTP/1.1 header
261   fields related to authentication.
262
2634.1.  Authorization
264
265   A user agent that wishes to authenticate itself with a server--
266   usually, but not necessarily, after receiving a 401 response--does so
267   by including an Authorization request-header field with the request.
268   The Authorization field value consists of credentials containing the
269   authentication information of the user agent for the realm of the
270   resource being requested.
271
272     Authorization  = "Authorization" ":" credentials
273
274   HTTP access authentication is described in "HTTP Authentication:
275   Basic and Digest Access Authentication" [RFC2617].  If a request is
276
277
278
279Fielding, et al.         Expires August 27, 2008                [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7               February 2008
282
283
284   authenticated and a realm specified, the same credentials SHOULD be
285   valid for all other requests within this realm (assuming that the
286   authentication scheme itself does not require otherwise, such as
287   credentials that vary according to a challenge value or using
288   synchronized clocks).
289
290   When a shared cache (see Section 9 of [Part6]) receives a request
291   containing an Authorization field, it MUST NOT return the
292   corresponding response as a reply to any other request, unless one of
293   the following specific exceptions holds:
294
295   1.  If the response includes the "s-maxage" cache-control directive,
296       the cache MAY use that response in replying to a subsequent
297       request.  But (if the specified maximum age has passed) a proxy
298       cache MUST first revalidate it with the origin server, using the
299       request-headers from the new request to allow the origin server
300       to authenticate the new request.  (This is the defined behavior
301       for s-maxage.)  If the response includes "s-maxage=0", the proxy
302       MUST always revalidate it before re-using it.
303
304   2.  If the response includes the "must-revalidate" cache-control
305       directive, the cache MAY use that response in replying to a
306       subsequent request.  But if the response is stale, all caches
307       MUST first revalidate it with the origin server, using the
308       request-headers from the new request to allow the origin server
309       to authenticate the new request.
310
311   3.  If the response includes the "public" cache-control directive, it
312       MAY be returned in reply to any subsequent request.
313
3144.2.  Proxy-Authenticate
315
316   The Proxy-Authenticate response-header field MUST be included as part
317   of a 407 (Proxy Authentication Required) response.  The field value
318   consists of a challenge that indicates the authentication scheme and
319   parameters applicable to the proxy for this Request-URI.
320
321     Proxy-Authenticate  = "Proxy-Authenticate" ":" 1#challenge
322
323   The HTTP access authentication process is described in "HTTP
324   Authentication: Basic and Digest Access Authentication" [RFC2617].
325   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
326   only to the current connection and SHOULD NOT be passed on to
327   downstream clients.  However, an intermediate proxy might need to
328   obtain its own credentials by requesting them from the downstream
329   client, which in some circumstances will appear as if the proxy is
330   forwarding the Proxy-Authenticate header field.
331
332
333
334
335Fielding, et al.         Expires August 27, 2008                [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7               February 2008
338
339
3404.3.  Proxy-Authorization
341
342   The Proxy-Authorization request-header field allows the client to
343   identify itself (or its user) to a proxy which requires
344   authentication.  The Proxy-Authorization field value consists of
345   credentials containing the authentication information of the user
346   agent for the proxy and/or realm of the resource being requested.
347
348     Proxy-Authorization     = "Proxy-Authorization" ":" credentials
349
350   The HTTP access authentication process is described in "HTTP
351   Authentication: Basic and Digest Access Authentication" [RFC2617].
352   Unlike Authorization, the Proxy-Authorization header field applies
353   only to the next outbound proxy that demanded authentication using
354   the Proxy-Authenticate field.  When multiple proxies are used in a
355   chain, the Proxy-Authorization header field is consumed by the first
356   outbound proxy that was expecting to receive credentials.  A proxy
357   MAY relay the credentials from the client request to the next proxy
358   if that is the mechanism by which the proxies cooperatively
359   authenticate a given request.
360
3614.4.  WWW-Authenticate
362
363   The WWW-Authenticate response-header field MUST be included in 401
364   (Unauthorized) response messages.  The field value consists of at
365   least one challenge that indicates the authentication scheme(s) and
366   parameters applicable to the Request-URI.
367
368     WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
369
370   The HTTP access authentication process is described in "HTTP
371   Authentication: Basic and Digest Access Authentication" [RFC2617].
372   User agents are advised to take special care in parsing the WWW-
373   Authenticate field value as it might contain more than one challenge,
374   or if more than one WWW-Authenticate header field is provided, the
375   contents of a challenge itself can contain a comma-separated list of
376   authentication parameters.
377
378
3795.  IANA Considerations
380
381   [[anchor2: TBD.]]
382
383
3846.  Security Considerations
385
386   This section is meant to inform application developers, information
387   providers, and users of the security limitations in HTTP/1.1 as
388
389
390
391Fielding, et al.         Expires August 27, 2008                [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7               February 2008
394
395
396   described by this document.  The discussion does not include
397   definitive solutions to the problems revealed, though it does make
398   some suggestions for reducing security risks.
399
4006.1.  Authentication Credentials and Idle Clients
401
402   Existing HTTP clients and user agents typically retain authentication
403   information indefinitely.  HTTP/1.1 does not provide a method for a
404   server to direct clients to discard these cached credentials.  This
405   is a significant defect that requires further extensions to HTTP.
406   Circumstances under which credential caching can interfere with the
407   application's security model include but are not limited to:
408
409   o  Clients which have been idle for an extended period following
410      which the server might wish to cause the client to reprompt the
411      user for credentials.
412
413   o  Applications which include a session termination indication (such
414      as a `logout' or `commit' button on a page) after which the server
415      side of the application `knows' that there is no further reason
416      for the client to retain the credentials.
417
418   This is currently under separate study.  There are a number of work-
419   arounds to parts of this problem, and we encourage the use of
420   password protection in screen savers, idle time-outs, and other
421   methods which mitigate the security problems inherent in this
422   problem.  In particular, user agents which cache credentials are
423   encouraged to provide a readily accessible mechanism for discarding
424   cached credentials under user control.
425
426
4277.  Acknowledgments
428
429   TBD.
430
431
4328.  References
433
4348.1.  Normative References
435
436   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
437              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
438              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
439              and Message Parsing", draft-ietf-httpbis-p1-messaging-02
440              (work in progress), February 2008.
441
442   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
443              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
444
445
446
447Fielding, et al.         Expires August 27, 2008                [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7               February 2008
450
451
452              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
453              draft-ietf-httpbis-p6-cache-02 (work in progress),
454              February 2008.
455
456   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
457              Requirement Levels", BCP 14, RFC 2119, March 1997.
458
459   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
460              Leach, P., Luotonen, A., and L. Stewart, "HTTP
461              Authentication: Basic and Digest Access Authentication",
462              RFC 2617, June 1999.
463
4648.2.  Informative References
465
466   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
467              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
468              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
469
470
471Appendix A.  Compatibility with Previous Versions
472
473A.1.  Changes from RFC 2616
474
475
476Appendix B.  Change Log (to be removed by RFC Editor before publication)
477
478B.1.  Since RFC2616
479
480   Extracted relevant partitions from [RFC2616].
481
482B.2.  Since draft-ietf-httpbis-p7-auth-00
483
484   Closed issues:
485
486   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
487      and Informative references"
488
489B.3.  Since draft-ietf-httpbis-p7-auth-01
490
491   Ongoing work on ABNF conversion
492   (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
493
494   o  Explicitly import BNF rules for "challenge" and "credentials" from
495      RFC2617.
496
497   o  Add explicit references to BNF syntax and rules imported from
498      other parts of the specification.
499
500
501
502
503Fielding, et al.         Expires August 27, 2008                [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7               February 2008
506
507
508Index
509
510   4
511      401 Unauthorized (status code)  5
512      407 Proxy Authentication Required (status code)  5
513
514   A
515      Authorization header  5
516
517   G
518      Grammar
519         Authorization  5
520         challenge  4
521         credentials  4
522         Proxy-Authenticate  6
523         Proxy-Authorization  7
524         WWW-Authenticate  7
525
526   H
527      Headers
528         Authorization  5
529         Proxy-Authenticate  6
530         Proxy-Authorization  7
531         WWW-Authenticate  7
532
533   P
534      Proxy-Authenticate header  6
535      Proxy-Authorization header  7
536
537   S
538      Status Codes
539         401 Unauthorized  5
540         407 Proxy Authentication Required  5
541
542   W
543      WWW-Authenticate header  7
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559Fielding, et al.         Expires August 27, 2008               [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7               February 2008
562
563
564Authors' Addresses
565
566   Roy T. Fielding (editor)
567   Day Software
568   23 Corporate Plaza DR, Suite 280
569   Newport Beach, CA  92660
570   USA
571
572   Phone: +1-949-706-5300
573   Fax:   +1-949-706-5305
574   Email: fielding@gbiv.com
575   URI:   http://roy.gbiv.com/
576
577
578   Jim Gettys
579   One Laptop per Child
580   21 Oak Knoll Road
581   Carlisle, MA  01741
582   USA
583
584   Email: jg@laptop.org
585   URI:   http://www.laptop.org/
586
587
588   Jeffrey C. Mogul
589   Hewlett-Packard Company
590   HP Labs, Large Scale Systems Group
591   1501 Page Mill Road, MS 1177
592   Palo Alto, CA  94304
593   USA
594
595   Email: JeffMogul@acm.org
596
597
598   Henrik Frystyk Nielsen
599   Microsoft Corporation
600   1 Microsoft Way
601   Redmond, WA  98052
602   USA
603
604   Email: henrikn@microsoft.com
605
606
607
608
609
610
611
612
613
614
615Fielding, et al.         Expires August 27, 2008               [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7               February 2008
618
619
620   Larry Masinter
621   Adobe Systems, Incorporated
622   345 Park Ave
623   San Jose, CA  95110
624   USA
625
626   Email: LMM@acm.org
627   URI:   http://larry.masinter.net/
628
629
630   Paul J. Leach
631   Microsoft Corporation
632   1 Microsoft Way
633   Redmond, WA  98052
634
635   Email: paulle@microsoft.com
636
637
638   Tim Berners-Lee
639   World Wide Web Consortium
640   MIT Computer Science and Artificial Intelligence Laboratory
641   The Stata Center, Building 32
642   32 Vassar Street
643   Cambridge, MA  02139
644   USA
645
646   Email: timbl@w3.org
647   URI:   http://www.w3.org/People/Berners-Lee/
648
649
650   Yves Lafon (editor)
651   World Wide Web Consortium
652   W3C / ERCIM
653   2004, rte des Lucioles
654   Sophia-Antipolis, AM  06902
655   France
656
657   Email: ylafon@w3.org
658   URI:   http://www.raubacapeu.net/people/yves/
659
660
661
662
663
664
665
666
667
668
669
670
671Fielding, et al.         Expires August 27, 2008               [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7               February 2008
674
675
676   Julian F. Reschke (editor)
677   greenbytes GmbH
678   Hafenweg 16
679   Muenster, NW  48155
680   Germany
681
682   Phone: +49 251 2807760
683   Fax:   +49 251 2807761
684   Email: julian.reschke@greenbytes.de
685   URI:   http://greenbytes.de/tech/webdav/
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727Fielding, et al.         Expires August 27, 2008               [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 7               February 2008
730
731
732Full Copyright Statement
733
734   Copyright (C) The IETF Trust (2008).
735
736   This document is subject to the rights, licenses and restrictions
737   contained in BCP 78, and except as set forth therein, the authors
738   retain all their rights.
739
740   This document and the information contained herein are provided on an
741   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
742   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
743   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
744   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
745   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
746   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
747
748
749Intellectual Property
750
751   The IETF takes no position regarding the validity or scope of any
752   Intellectual Property Rights or other rights that might be claimed to
753   pertain to the implementation or use of the technology described in
754   this document or the extent to which any license under such rights
755   might or might not be available; nor does it represent that it has
756   made any independent effort to identify any such rights.  Information
757   on the procedures with respect to rights in RFC documents can be
758   found in BCP 78 and BCP 79.
759
760   Copies of IPR disclosures made to the IETF Secretariat and any
761   assurances of licenses to be made available, or the result of an
762   attempt made to obtain a general license or permission for the use of
763   such proprietary rights by implementers or users of this
764   specification can be obtained from the IETF on-line IPR repository at
765   http://www.ietf.org/ipr.
766
767   The IETF invites any interested party to bring to its attention any
768   copyrights, patents or patent applications, or other proprietary
769   rights that may cover technology that may be required to implement
770   this standard.  Please address the information to the IETF at
771   ietf-ipr@ietf.org.
772
773
774Acknowledgment
775
776   Funding for the RFC Editor function is provided by the IETF
777   Administrative Support Activity (IASA).
778
779
780
781
782
783Fielding, et al.         Expires August 27, 2008               [Page 14]
784
Note: See TracBrowser for help on using the repository browser.