source: draft-ietf-httpbis/05/draft-ietf-httpbis-p7-auth-05.txt @ 559

Last change on this file since 559 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: 26.3 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: May 20, 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                                                       November 16, 2008
23
24
25                    HTTP/1.1, part 7: Authentication
26                     draft-ietf-httpbis-p7-auth-05
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 May 20, 2009.
52
53
54
55Fielding, et al.          Expires May 20, 2009                  [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7               November 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://tools.ietf.org/wg/httpbis/trac/report/11> and related
75   documents (including fancy diffs) can be found at
76   <http://tools.ietf.org/wg/httpbis/>.
77
78   The changes in this draft are summarized in Appendix B.6.
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 May 20, 2009                  [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7               November 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  . . . . . . . . . . . . . . .  8
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  . . . . . . . . 10
138     A.1.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 10
139   Appendix B.  Change Log (to be removed by RFC Editor before
140                publication)  . . . . . . . . . . . . . . . . . . . . 10
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     B.6.  Since draft-ietf-httpbis-p7-auth-04  . . . . . . . . . . . 10
147   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
148   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
149   Intellectual Property and Copyright Statements . . . . . . . . . . 15
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167Fielding, et al.          Expires May 20, 2009                  [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7               November 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].
211
212   The ABNF rules below are defined in other specifications:
213
214     OWS           = <OWS, defined in [Part1], Section 2.2>
215
216
217     challenge   = <challenge, defined in [RFC2617], Section 1.2>
218     credentials = <credentials, defined in [RFC2617], Section 1.2>
219
220
221
222
223Fielding, et al.          Expires May 20, 2009                  [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7               November 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 field "Authorization" 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" ":" OWS Authorization-v
273     Authorization-v = credentials
274
275   HTTP access authentication is described in "HTTP Authentication:
276
277
278
279Fielding, et al.          Expires May 20, 2009                  [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7               November 2008
282
283
284   Basic and Digest Access Authentication" [RFC2617].  If a request is
285   authenticated and a realm specified, the same credentials SHOULD be
286   valid for all other requests within this realm (assuming that the
287   authentication scheme itself does not require otherwise, such as
288   credentials that vary according to a challenge value or using
289   synchronized clocks).
290
291   When a shared cache (see Section 9 of [Part6]) receives a request
292   containing an Authorization field, it MUST NOT return the
293   corresponding response as a reply to any other request, unless one of
294   the following specific exceptions holds:
295
296   1.  If the response includes the "s-maxage" cache-control directive,
297       the cache MAY use that response in replying to a subsequent
298       request.  But (if the specified maximum age has passed) a proxy
299       cache MUST first revalidate it with the origin server, using the
300       request-headers from the new request to allow the origin server
301       to authenticate the new request.  (This is the defined behavior
302       for s-maxage.)  If the response includes "s-maxage=0", the proxy
303       MUST always revalidate it before re-using it.
304
305   2.  If the response includes the "must-revalidate" cache-control
306       directive, the cache MAY use that response in replying to a
307       subsequent request.  But if the response is stale, all caches
308       MUST first revalidate it with the origin server, using the
309       request-headers from the new request to allow the origin server
310       to authenticate the new request.
311
312   3.  If the response includes the "public" cache-control directive, it
313       MAY be returned in reply to any subsequent request.
314
3154.2.  Proxy-Authenticate
316
317   The response-header field "Proxy-Authenticate" MUST be included as
318   part of a 407 (Proxy Authentication Required) response.  The field
319   value consists of a challenge that indicates the authentication
320   scheme and parameters applicable to the proxy for this Request-URI.
321
322     Proxy-Authenticate   = "Proxy-Authenticate" ":" OWS
323                            Proxy-Authenticate-v
324     Proxy-Authenticate-v = 1#challenge
325
326   The HTTP access authentication process is described in "HTTP
327   Authentication: Basic and Digest Access Authentication" [RFC2617].
328   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
329   only to the current connection and SHOULD NOT be passed on to
330   downstream clients.  However, an intermediate proxy might need to
331   obtain its own credentials by requesting them from the downstream
332
333
334
335Fielding, et al.          Expires May 20, 2009                  [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7               November 2008
338
339
340   client, which in some circumstances will appear as if the proxy is
341   forwarding the Proxy-Authenticate header field.
342
3434.3.  Proxy-Authorization
344
345   The request-header field "Proxy-Authorization" allows the client to
346   identify itself (or its user) to a proxy which requires
347   authentication.  The Proxy-Authorization field value consists of
348   credentials containing the authentication information of the user
349   agent for the proxy and/or realm of the resource being requested.
350
351     Proxy-Authorization   = "Proxy-Authorization" ":" OWS
352                             Proxy-Authorization-v
353     Proxy-Authorization-v = credentials
354
355   The HTTP access authentication process is described in "HTTP
356   Authentication: Basic and Digest Access Authentication" [RFC2617].
357   Unlike Authorization, the Proxy-Authorization header field applies
358   only to the next outbound proxy that demanded authentication using
359   the Proxy-Authenticate field.  When multiple proxies are used in a
360   chain, the Proxy-Authorization header field is consumed by the first
361   outbound proxy that was expecting to receive credentials.  A proxy
362   MAY relay the credentials from the client request to the next proxy
363   if that is the mechanism by which the proxies cooperatively
364   authenticate a given request.
365
3664.4.  WWW-Authenticate
367
368   The WWW-Authenticate response-header field MUST be included in 401
369   (Unauthorized) response messages.  The field value consists of at
370   least one challenge that indicates the authentication scheme(s) and
371   parameters applicable to the Request-URI.
372
373     WWW-Authenticate   = "WWW-Authenticate" ":" OWS WWW-Authenticate-v
374     WWW-Authenticate-v = 1#challenge
375
376   The HTTP access authentication process is described in "HTTP
377   Authentication: Basic and Digest Access Authentication" [RFC2617].
378   User agents are advised to take special care in parsing the WWW-
379   Authenticate field value as it might contain more than one challenge,
380   or if more than one WWW-Authenticate header field is provided, the
381   contents of a challenge itself can contain a comma-separated list of
382   authentication parameters.
383
384
3855.  IANA Considerations
386
387
388
389
390
391Fielding, et al.          Expires May 20, 2009                  [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7               November 2008
394
395
3965.1.  Message Header Registration
397
398   The Message Header Registry located at <http://www.iana.org/
399   assignments/message-headers/message-header-index.html> should be
400   updated with the permanent registrations below (see [RFC3864]):
401
402   +---------------------+----------+----------+-------------+
403   | Header Field Name   | Protocol | Status   | Reference   |
404   +---------------------+----------+----------+-------------+
405   | Authorization       | http     | standard | Section 4.1 |
406   | Proxy-Authenticate  | http     | standard | Section 4.2 |
407   | Proxy-Authorization | http     | standard | Section 4.3 |
408   | WWW-Authenticate    | http     | standard | Section 4.4 |
409   +---------------------+----------+----------+-------------+
410
411   The change controller is: "IETF (iesg@ietf.org) - Internet
412   Engineering Task Force".
413
414
4156.  Security Considerations
416
417   This section is meant to inform application developers, information
418   providers, and users of the security limitations in HTTP/1.1 as
419   described by this document.  The discussion does not include
420   definitive solutions to the problems revealed, though it does make
421   some suggestions for reducing security risks.
422
4236.1.  Authentication Credentials and Idle Clients
424
425   Existing HTTP clients and user agents typically retain authentication
426   information indefinitely.  HTTP/1.1 does not provide a method for a
427   server to direct clients to discard these cached credentials.  This
428   is a significant defect that requires further extensions to HTTP.
429   Circumstances under which credential caching can interfere with the
430   application's security model include but are not limited to:
431
432   o  Clients which have been idle for an extended period following
433      which the server might wish to cause the client to reprompt the
434      user for credentials.
435
436   o  Applications which include a session termination indication (such
437      as a `logout' or `commit' button on a page) after which the server
438      side of the application `knows' that there is no further reason
439      for the client to retain the credentials.
440
441   This is currently under separate study.  There are a number of work-
442   arounds to parts of this problem, and we encourage the use of
443   password protection in screen savers, idle time-outs, and other
444
445
446
447Fielding, et al.          Expires May 20, 2009                  [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7               November 2008
450
451
452   methods which mitigate the security problems inherent in this
453   problem.  In particular, user agents which cache credentials are
454   encouraged to provide a readily accessible mechanism for discarding
455   cached credentials under user control.
456
457
4587.  Acknowledgments
459
460   [[anchor2: TBD.]]
461
462
4638.  References
464
4658.1.  Normative References
466
467   [Part1]    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 1: URIs, Connections,
470              and Message Parsing", draft-ietf-httpbis-p1-messaging-05
471              (work in progress), November 2008.
472
473   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
474              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
475              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
476              draft-ietf-httpbis-p6-cache-05 (work in progress),
477              November 2008.
478
479   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
480              Requirement Levels", BCP 14, RFC 2119, March 1997.
481
482   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
483              Leach, P., Luotonen, A., and L. Stewart, "HTTP
484              Authentication: Basic and Digest Access Authentication",
485              RFC 2617, June 1999.
486
4878.2.  Informative References
488
489   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
490              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
491              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
492
493   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
494              Procedures for Message Header Fields", BCP 90, RFC 3864,
495              September 2004.
496
497
498
499
500
501
502
503Fielding, et al.          Expires May 20, 2009                  [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7               November 2008
506
507
508Appendix A.  Compatibility with Previous Versions
509
510A.1.  Changes from RFC 2616
511
512
513Appendix B.  Change Log (to be removed by RFC Editor before publication)
514
515B.1.  Since RFC2616
516
517   Extracted relevant partitions from [RFC2616].
518
519B.2.  Since draft-ietf-httpbis-p7-auth-00
520
521   Closed issues:
522
523   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
524      Informative references"
525
526B.3.  Since draft-ietf-httpbis-p7-auth-01
527
528   Ongoing work on ABNF conversion
529   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
530
531   o  Explicitly import BNF rules for "challenge" and "credentials" from
532      RFC2617.
533
534   o  Add explicit references to BNF syntax and rules imported from
535      other parts of the specification.
536
537B.4.  Since draft-ietf-httpbis-p7-auth-02
538
539   Ongoing work on IANA Message Header Registration
540   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
541
542   o  Reference RFC 3984, and update header registrations for headers
543      defined in this document.
544
545B.5.  Since draft-ietf-httpbis-p7-auth-03
546
547B.6.  Since draft-ietf-httpbis-p7-auth-04
548
549   Ongoing work on ABNF conversion
550   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
551
552   o  Use "/" instead of "|" for alternatives.
553
554   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
555      whitespace ("OWS") and required whitespace ("RWS").
556
557
558
559Fielding, et al.          Expires May 20, 2009                 [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7               November 2008
562
563
564   o  Rewrite ABNFs to spell out whitespace rules, factor out header
565      value format definitions.
566
567
568Index
569
570   4
571      401 Unauthorized (status code)  5
572      407 Proxy Authentication Required (status code)  5
573
574   A
575      Authorization header  5
576
577   G
578      Grammar
579         Authorization  5
580         Authorization-v  5
581         challenge  4
582         credentials  4
583         Proxy-Authenticate  6
584         Proxy-Authenticate-v  6
585         Proxy-Authorization  7
586         Proxy-Authorization-v  7
587         WWW-Authenticate  7
588         WWW-Authenticate-v  7
589
590   H
591      Headers
592         Authorization  5
593         Proxy-Authenticate  6
594         Proxy-Authorization  7
595         WWW-Authenticate  7
596
597   P
598      Proxy-Authenticate header  6
599      Proxy-Authorization header  7
600
601   S
602      Status Codes
603         401 Unauthorized  5
604         407 Proxy Authentication Required  5
605
606   W
607      WWW-Authenticate header  7
608
609
610
611
612
613
614
615Fielding, et al.          Expires May 20, 2009                 [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7               November 2008
618
619
620Authors' Addresses
621
622   Roy T. Fielding (editor)
623   Day Software
624   23 Corporate Plaza DR, Suite 280
625   Newport Beach, CA  92660
626   USA
627
628   Phone: +1-949-706-5300
629   Fax:   +1-949-706-5305
630   Email: fielding@gbiv.com
631   URI:   http://roy.gbiv.com/
632
633
634   Jim Gettys
635   One Laptop per Child
636   21 Oak Knoll Road
637   Carlisle, MA  01741
638   USA
639
640   Email: jg@laptop.org
641   URI:   http://www.laptop.org/
642
643
644   Jeffrey C. Mogul
645   Hewlett-Packard Company
646   HP Labs, Large Scale Systems Group
647   1501 Page Mill Road, MS 1177
648   Palo Alto, CA  94304
649   USA
650
651   Email: JeffMogul@acm.org
652
653
654   Henrik Frystyk Nielsen
655   Microsoft Corporation
656   1 Microsoft Way
657   Redmond, WA  98052
658   USA
659
660   Email: henrikn@microsoft.com
661
662
663
664
665
666
667
668
669
670
671Fielding, et al.          Expires May 20, 2009                 [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7               November 2008
674
675
676   Larry Masinter
677   Adobe Systems, Incorporated
678   345 Park Ave
679   San Jose, CA  95110
680   USA
681
682   Email: LMM@acm.org
683   URI:   http://larry.masinter.net/
684
685
686   Paul J. Leach
687   Microsoft Corporation
688   1 Microsoft Way
689   Redmond, WA  98052
690
691   Email: paulle@microsoft.com
692
693
694   Tim Berners-Lee
695   World Wide Web Consortium
696   MIT Computer Science and Artificial Intelligence Laboratory
697   The Stata Center, Building 32
698   32 Vassar Street
699   Cambridge, MA  02139
700   USA
701
702   Email: timbl@w3.org
703   URI:   http://www.w3.org/People/Berners-Lee/
704
705
706   Yves Lafon (editor)
707   World Wide Web Consortium
708   W3C / ERCIM
709   2004, rte des Lucioles
710   Sophia-Antipolis, AM  06902
711   France
712
713   Email: ylafon@w3.org
714   URI:   http://www.raubacapeu.net/people/yves/
715
716
717
718
719
720
721
722
723
724
725
726
727Fielding, et al.          Expires May 20, 2009                 [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 7               November 2008
730
731
732   Julian F. Reschke (editor)
733   greenbytes GmbH
734   Hafenweg 16
735   Muenster, NW  48155
736   Germany
737
738   Phone: +49 251 2807760
739   Fax:   +49 251 2807761
740   Email: julian.reschke@greenbytes.de
741   URI:   http://greenbytes.de/tech/webdav/
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783Fielding, et al.          Expires May 20, 2009                 [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 7               November 2008
786
787
788Full Copyright Statement
789
790   Copyright (C) The IETF Trust (2008).
791
792   This document is subject to the rights, licenses and restrictions
793   contained in BCP 78, and except as set forth therein, the authors
794   retain all their rights.
795
796   This document and the information contained herein are provided on an
797   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
798   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
799   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
800   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
801   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
802   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
803
804
805Intellectual Property
806
807   The IETF takes no position regarding the validity or scope of any
808   Intellectual Property Rights or other rights that might be claimed to
809   pertain to the implementation or use of the technology described in
810   this document or the extent to which any license under such rights
811   might or might not be available; nor does it represent that it has
812   made any independent effort to identify any such rights.  Information
813   on the procedures with respect to rights in RFC documents can be
814   found in BCP 78 and BCP 79.
815
816   Copies of IPR disclosures made to the IETF Secretariat and any
817   assurances of licenses to be made available, or the result of an
818   attempt made to obtain a general license or permission for the use of
819   such proprietary rights by implementers or users of this
820   specification can be obtained from the IETF on-line IPR repository at
821   http://www.ietf.org/ipr.
822
823   The IETF invites any interested party to bring to its attention any
824   copyrights, patents or patent applications, or other proprietary
825   rights that may cover technology that may be required to implement
826   this standard.  Please address the information to the IETF at
827   ietf-ipr@ietf.org.
828
829
830
831
832
833
834
835
836
837
838
839Fielding, et al.          Expires May 20, 2009                 [Page 15]
840
Note: See TracBrowser for help on using the repository browser.