source: draft-ietf-httpbis/04/draft-ietf-httpbis-p7-auth-04.txt @ 839

Last change on this file since 839 was 559, checked in by fielding@…, 11 years ago

remove executable and set eol-style for earlier drafts

  • Property svn:eol-style set to native
File size: 25.4 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: March 2, 2009                                                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                                                         August 29, 2008
23
24
25                    HTTP/1.1, part 7: Authentication
26                     draft-ietf-httpbis-p7-auth-04
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 March 2, 2009.
52
53
54
55Fielding, et al.          Expires March 2, 2009                 [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7                 August 2008
58
59
60Abstract
61
62   The Hypertext Transfer Protocol (HTTP) is an application-level
63   protocol for distributed, collaborative, hypermedia information
64   systems.  HTTP has been in use by the World Wide Web global
65   information initiative since 1990.  This document is Part 7 of the
66   seven-part specification that defines the protocol referred to as
67   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 7 defines
68   HTTP Authentication.
69
70Editorial Note (To be removed by RFC Editor)
71
72   Discussion of this draft should take place on the HTTPBIS working
73   group mailing list (ietf-http-wg@w3.org).  The current issues list is
74   at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
75   documents (including fancy diffs) can be found at
76   <http://www.tools.ietf.org/wg/httpbis/>.
77
78   The changes in this draft are summarized in Appendix B.4.
79
80
81
82
83
84
85
86
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 March 2, 2009                 [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7                 August 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     5.1.  Message Header Registration  . . . . . . . . . . . . . . .  7
131   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
132     6.1.  Authentication Credentials and Idle Clients  . . . . . . .  8
133   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
134   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
135     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
136     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
137   Appendix A.  Compatibility with Previous Versions  . . . . . . . .  9
138     A.1.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . .  9
139   Appendix B.  Change Log (to be removed by RFC Editor before
140                publication)  . . . . . . . . . . . . . . . . . . . .  9
141     B.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 10
142     B.2.  Since draft-ietf-httpbis-p7-auth-00  . . . . . . . . . . . 10
143     B.3.  Since draft-ietf-httpbis-p7-auth-01  . . . . . . . . . . . 10
144     B.4.  Since draft-ietf-httpbis-p7-auth-02  . . . . . . . . . . . 10
145     B.5.  Since draft-ietf-httpbis-p7-auth-03  . . . . . . . . . . . 10
146   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
147   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
148   Intellectual Property and Copyright Statements . . . . . . . . . . 14
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167Fielding, et al.          Expires March 2, 2009                 [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7                 August 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 March 2, 2009                 [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7                 August 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 March 2, 2009                 [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7                 August 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 March 2, 2009                 [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7                 August 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
3815.1.  Message Header Registration
382
383   The Message Header Registry located at <http://www.iana.org/
384   assignments/message-headers/message-header-index.html> should be
385   updated with the permanent registrations below (see [RFC3864]):
386
387
388
389
390
391Fielding, et al.          Expires March 2, 2009                 [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7                 August 2008
394
395
396   +---------------------+----------+----------+-------------+
397   | Header Field Name   | Protocol | Status   | Reference   |
398   +---------------------+----------+----------+-------------+
399   | Authorization       | http     | standard | Section 4.1 |
400   | Proxy-Authenticate  | http     | standard | Section 4.2 |
401   | Proxy-Authorization | http     | standard | Section 4.3 |
402   | WWW-Authenticate    | http     | standard | Section 4.4 |
403   +---------------------+----------+----------+-------------+
404
405   The change controller is: "IETF (iesg@ietf.org) - Internet
406   Engineering Task Force".
407
408
4096.  Security Considerations
410
411   This section is meant to inform application developers, information
412   providers, and users of the security limitations in HTTP/1.1 as
413   described by this document.  The discussion does not include
414   definitive solutions to the problems revealed, though it does make
415   some suggestions for reducing security risks.
416
4176.1.  Authentication Credentials and Idle Clients
418
419   Existing HTTP clients and user agents typically retain authentication
420   information indefinitely.  HTTP/1.1 does not provide a method for a
421   server to direct clients to discard these cached credentials.  This
422   is a significant defect that requires further extensions to HTTP.
423   Circumstances under which credential caching can interfere with the
424   application's security model include but are not limited to:
425
426   o  Clients which have been idle for an extended period following
427      which the server might wish to cause the client to reprompt the
428      user for credentials.
429
430   o  Applications which include a session termination indication (such
431      as a `logout' or `commit' button on a page) after which the server
432      side of the application `knows' that there is no further reason
433      for the client to retain the credentials.
434
435   This is currently under separate study.  There are a number of work-
436   arounds to parts of this problem, and we encourage the use of
437   password protection in screen savers, idle time-outs, and other
438   methods which mitigate the security problems inherent in this
439   problem.  In particular, user agents which cache credentials are
440   encouraged to provide a readily accessible mechanism for discarding
441   cached credentials under user control.
442
443
444
445
446
447Fielding, et al.          Expires March 2, 2009                 [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7                 August 2008
450
451
4527.  Acknowledgments
453
454   [[anchor2: TBD.]]
455
456
4578.  References
458
4598.1.  Normative References
460
461   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
462              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
463              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
464              and Message Parsing", draft-ietf-httpbis-p1-messaging-04
465              (work in progress), August 2008.
466
467   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
468              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
469              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
470              draft-ietf-httpbis-p6-cache-04 (work in progress),
471              August 2008.
472
473   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
474              Requirement Levels", BCP 14, RFC 2119, March 1997.
475
476   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
477              Leach, P., Luotonen, A., and L. Stewart, "HTTP
478              Authentication: Basic and Digest Access Authentication",
479              RFC 2617, June 1999.
480
4818.2.  Informative References
482
483   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
484              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
485              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
486
487   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
488              Procedures for Message Header Fields", BCP 90, RFC 3864,
489              September 2004.
490
491
492Appendix A.  Compatibility with Previous Versions
493
494A.1.  Changes from RFC 2616
495
496
497Appendix B.  Change Log (to be removed by RFC Editor before publication)
498
499
500
501
502
503Fielding, et al.          Expires March 2, 2009                 [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7                 August 2008
506
507
508B.1.  Since RFC2616
509
510   Extracted relevant partitions from [RFC2616].
511
512B.2.  Since draft-ietf-httpbis-p7-auth-00
513
514   Closed issues:
515
516   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
517      and Informative references"
518
519B.3.  Since draft-ietf-httpbis-p7-auth-01
520
521   Ongoing work on ABNF conversion
522   (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
523
524   o  Explicitly import BNF rules for "challenge" and "credentials" from
525      RFC2617.
526
527   o  Add explicit references to BNF syntax and rules imported from
528      other parts of the specification.
529
530B.4.  Since draft-ietf-httpbis-p7-auth-02
531
532   Ongoing work on IANA Message Header Registration
533   (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>):
534
535   o  Reference RFC 3984, and update header registrations for headers
536      defined in this document.
537
538B.5.  Since draft-ietf-httpbis-p7-auth-03
539
540
541Index
542
543   4
544      401 Unauthorized (status code)  5
545      407 Proxy Authentication Required (status code)  5
546
547   A
548      Authorization header  5
549
550   G
551      Grammar
552         Authorization  5
553         challenge  4
554         credentials  4
555         Proxy-Authenticate  6
556
557
558
559Fielding, et al.          Expires March 2, 2009                [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7                 August 2008
562
563
564         Proxy-Authorization  7
565         WWW-Authenticate  7
566
567   H
568      Headers
569         Authorization  5
570         Proxy-Authenticate  6
571         Proxy-Authorization  7
572         WWW-Authenticate  7
573
574   P
575      Proxy-Authenticate header  6
576      Proxy-Authorization header  7
577
578   S
579      Status Codes
580         401 Unauthorized  5
581         407 Proxy Authentication Required  5
582
583   W
584      WWW-Authenticate header  7
585
586
587Authors' Addresses
588
589   Roy T. Fielding (editor)
590   Day Software
591   23 Corporate Plaza DR, Suite 280
592   Newport Beach, CA  92660
593   USA
594
595   Phone: +1-949-706-5300
596   Fax:   +1-949-706-5305
597   Email: fielding@gbiv.com
598   URI:   http://roy.gbiv.com/
599
600
601   Jim Gettys
602   One Laptop per Child
603   21 Oak Knoll Road
604   Carlisle, MA  01741
605   USA
606
607   Email: jg@laptop.org
608   URI:   http://www.laptop.org/
609
610
611
612
613
614
615Fielding, et al.          Expires March 2, 2009                [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7                 August 2008
618
619
620   Jeffrey C. Mogul
621   Hewlett-Packard Company
622   HP Labs, Large Scale Systems Group
623   1501 Page Mill Road, MS 1177
624   Palo Alto, CA  94304
625   USA
626
627   Email: JeffMogul@acm.org
628
629
630   Henrik Frystyk Nielsen
631   Microsoft Corporation
632   1 Microsoft Way
633   Redmond, WA  98052
634   USA
635
636   Email: henrikn@microsoft.com
637
638
639   Larry Masinter
640   Adobe Systems, Incorporated
641   345 Park Ave
642   San Jose, CA  95110
643   USA
644
645   Email: LMM@acm.org
646   URI:   http://larry.masinter.net/
647
648
649   Paul J. Leach
650   Microsoft Corporation
651   1 Microsoft Way
652   Redmond, WA  98052
653
654   Email: paulle@microsoft.com
655
656
657   Tim Berners-Lee
658   World Wide Web Consortium
659   MIT Computer Science and Artificial Intelligence Laboratory
660   The Stata Center, Building 32
661   32 Vassar Street
662   Cambridge, MA  02139
663   USA
664
665   Email: timbl@w3.org
666   URI:   http://www.w3.org/People/Berners-Lee/
667
668
669
670
671Fielding, et al.          Expires March 2, 2009                [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7                 August 2008
674
675
676   Yves Lafon (editor)
677   World Wide Web Consortium
678   W3C / ERCIM
679   2004, rte des Lucioles
680   Sophia-Antipolis, AM  06902
681   France
682
683   Email: ylafon@w3.org
684   URI:   http://www.raubacapeu.net/people/yves/
685
686
687   Julian F. Reschke (editor)
688   greenbytes GmbH
689   Hafenweg 16
690   Muenster, NW  48155
691   Germany
692
693   Phone: +49 251 2807760
694   Fax:   +49 251 2807761
695   Email: julian.reschke@greenbytes.de
696   URI:   http://greenbytes.de/tech/webdav/
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 March 2, 2009                [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 7                 August 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
774
775
776
777
778
779
780
781
782
783Fielding, et al.          Expires March 2, 2009                [Page 14]
784
Note: See TracBrowser for help on using the repository browser.