idnits 2.17.1
draft-reschke-http-get-location-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 774.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 785.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 792.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 798.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([2], [1]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (April 4, 2008) is 5857 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Obsolete informational reference (is this intentional?): RFC 2068
(Obsoleted by RFC 2616)
Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Reschke
3 Internet-Draft greenbytes
4 Intended status: Standards Track April 4, 2008
5 Expires: October 6, 2008
7 The Hypertext Transfer Protocol (HTTP) GET-Location header
8 draft-reschke-http-get-location-01
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on October 6, 2008.
35 Abstract
37 Several hypertext transfer protocol (HTTP) extensions use methods
38 other than GET to expose information. This has the drawback that
39 this kind of information is harder to identify (missing a URL to
40 which a GET request could be applied) and to cache.
42 This document specifies a simple extension header through which a
43 server can advertise a substitute URL that an HTTP client
44 subsequently can use with the GET method.
46 Editorial Note (To be removed by RFC Editor before publication)
48 Distribution of this document is unlimited. Please send comments to
49 the Hypertext Transfer Protocol (HTTP) mailing list at
50 ietf-http-wg@w3.org [1], which may be joined by sending a message
51 with subject "subscribe" to ietf-http-wg-request@w3.org [2].
53 Discussions of the HTTP working group are archived at
54 .
56 XML versions, latest edits and the issues list for this document are
57 available from
58 .
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
64 3. The 'GET-Location' Header . . . . . . . . . . . . . . . . . . 4
65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
70 7.2. Informative References . . . . . . . . . . . . . . . . . . 7
71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7
72 A.1. WebDAV Collection Membership . . . . . . . . . . . . . . . 7
73 A.2. WebDAV Custom Properties . . . . . . . . . . . . . . . . . 11
74 A.3. DeltaV Version History Report . . . . . . . . . . . . . . 13
75 Appendix B. Related HTTP features . . . . . . . . . . . . . . . . 14
76 B.1. Status 303 . . . . . . . . . . . . . . . . . . . . . . . . 14
77 B.2. Content-Location Header . . . . . . . . . . . . . . . . . 15
78 B.3. Location header . . . . . . . . . . . . . . . . . . . . . 15
79 Appendix C. Alternate Approaches . . . . . . . . . . . . . . . . 15
80 C.1. Link Relation . . . . . . . . . . . . . . . . . . . . . . 15
81 C.2. Multistatus Body Extension . . . . . . . . . . . . . . . . 16
82 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . . 17
83 D.1. Content Negotiation on GET-Location . . . . . . . . . . . 17
84 D.2. Using URI Templates rather than URIs . . . . . . . . . . . 17
85 D.3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 17
86 Appendix E. Change Log (to be removed by RFC Editor before
87 publication) . . . . . . . . . . . . . . . . . . . . 17
88 E.1. Since draft-reschke-http-get-location-00 . . . . . . . . . 18
89 Appendix F. Resolved issues (to be removed by RFC Editor
90 before publication) . . . . . . . . . . . . . . . . . 18
91 F.1. status-codes . . . . . . . . . . . . . . . . . . . . . . . 18
92 F.2. non-get . . . . . . . . . . . . . . . . . . . . . . . . . 18
93 Appendix G. Open issues (to be removed by RFC Editor prior to
94 publication) . . . . . . . . . . . . . . . . . . . . 18
95 G.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
96 G.2. content-location . . . . . . . . . . . . . . . . . . . . . 19
97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
98 Intellectual Property and Copyright Statements . . . . . . . . . . 20
100 1. Introduction
102 Several HTTP ([RFC2616]) extensions use methods other than GET to
103 expose information. This has the drawback that this kind of
104 information is harder to identify (missing a URL to which a GET
105 request could be applied) and to cache.
107 This document specifies a simple extension header through which a
108 server can advertise a substitute URL that an HTTP client
109 subsequently can use with the GET method.
111 2. Notational Conventions
113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL-NOT",
114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
115 document are to be interpreted as described in [RFC2119].
117 The terminology used here follows and extends that in the HTTP
118 specification [RFC2616].
120 3. The 'GET-Location' Header
122 The GET-Location entity header identifies a substitute resource that
123 can be used in subsequent requests for the same information, but
124 using the GET method.
126 Note that, by definition, the GET-Location header can only used on
127 responses to safe methods.
129 Syntax (using the the augmented Backus-Naur Form (BNF) defined in
130 Section 2.1 of [RFC2616]):
132 GET-Location = "GET-Location" ":" "<" Simple-ref ">"
133 *( ";" location-directive ) )
135 location-directive = "etag=" entity-tag
136 | "max-age" "=" delta-seconds
137 | location-extension
139 location-extension = token [ "=" ( token | quoted-string ) ]
141 Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )
143 absolute-URI =
144 delta-seconds =
145 entity-tag =
146 path-absolute =
147 quoted-string =
148 query =
149 token =
151 Where:
153 Simple-ref Contains either the URI or the absolute path of the
154 location.
156 etag The server can include the entity tag for the returned entity,
157 if it would have been retrieved by a GET request to the substitute
158 resource. Note that this is different from the value of the
159 "ETag" header which could also be included in the response, but
160 which would apply to the resource identified by the Request-URI.
162 max-age Specifies a lifetime for the information returned by this
163 header. A client MUST discard any information related to this
164 header after the specified amount of time.
166 The freshness lifetime for the information obtained from the GET-
167 Location header does not depend on the cacheability of the response
168 it was obtained from (which, in general, may not be cacheable at
169 all). The "max-age" directive allows the server to specify after how
170 many seconds a client should discard knowledge about the alternate
171 resource. In absence of that header, clients SHOULD discard the
172 information after 3600 seconds.
174 There is no direct relation between the status code of the HTTP
175 response that included GET-Location and the status codes for
176 subsequent GET requests on the substitute resource. For instance,
177 GET-Location could be included in a 207 response to PROPFIND
178 ([RFC4918], Section 9.1), but the response code for a succesful GET
179 on the substitute resource would usually be 200.
181 Note that servers may, but are not required to support methods other
182 than GET or head on the substitute resource.
184 4. Security Considerations
186 This specification introduces no new security considerations beyond
187 those discussed in Section 15 of [RFC2616].
189 5. IANA Considerations
191 This document specifies the new HTTP header listed below, to be added
192 to the permanent registry (see [RFC3864]).
194 Header field name: GET-Location
196 Applicable protocol: http
198 Status: standard
200 Author/Change controller: IETF
202 Specification document: Section 3 of this specification
204 6. Acknowledgments
206 This document has benefited from thoughtful discussion by Stefan
207 Eissing and Henrik Nordstrom.
209 7. References
211 7.1. Normative References
213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
214 Requirement Levels", BCP 14, RFC 2119, March 1997.
216 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
217 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
218 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
220 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
221 Resource Identifier (URI): Generic Syntax", RFC 3986,
222 January 2005.
224 7.2. Informative References
226 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
227 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
228 RFC 2068, January 1997.
230 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
231 Whitehead, "Versioning Extensions to WebDAV", RFC 3253,
232 March 2002.
234 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
235 Procedures for Message Header Fields", BCP 90, RFC 3864,
236 September 2004.
238 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
239 Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
241 [draft-gregorio-uritemplate]
242 Gregorio, J., Ed., Hadley, M., Ed., Nottingham, M., Ed.,
243 and D. Orchard, "URI Template",
244 draft-gregorio-uritemplate-03 (work in progress),
245 March 2008.
247 URIs
249 [1]
251 [2]
253 Appendix A. Examples
255 A.1. WebDAV Collection Membership
257 In this example the client uses the WebDAV PROPFIND method ("HTTP
258 Extensions for Web Distributed Authoring and Versioning", [RFC4918],
259 Section 9.1) to get a list of all collection members, along with
260 their DAV:resourcetype property ([RFC4918], Section 15.9):
262 >>Request
264 PROPFIND /collection/ HTTP/1.1
265 Host: example.com
266 Depth: 1
267 Content-Type: application/xml
269
270
271
272
273
275 The response contains the requested information, plus the GET-
276 Location header, identifying a separate resource which can provide
277 the same information using the HTTP GET method:
279 >>Response
281 HTTP/1.1 207 Multi-Status
282 Content-Type: application/xml
283 GET-Location: ; etag="123";
284 max-age=3600
286
287
288 /collection/
289
290
291
292
293 HTTP/1.1 200 OK
294
295
296
297 /collection/member
298
299
300
301
302 HTTP/1.1 200 OK
303
304
305
307 The response provided the URL of the substitute resource, so when the
308 client wishes to refresh the collection information, it uses that
309 URI. The response contained the entity tag for the data being
310 returned, so it can make the request conditional:
312 >>Request
314 GET /collection/;members HTTP/1.1
315 Host: example.com
316 Accept: application/xml
317 If-None-Match: "123"
319 The information did not change, so the server does not need to return
320 new data:
322 >>Response
324 HTTP/1.1 304 Not Modified
326 Later on, the client tries again. This time, however, a second
327 member has been added:
329 >>Request
331 GET /collection/;members HTTP/1.1
332 Host: example.com
333 Accept: application/xml
334 If-None-Match: "123"
335 >>Response
337 HTTP/1.1 200 OK
338 Content-Type: application/xml
339 ETag: "124"
341
342
343 /collection/
344
345
346
347
348 HTTP/1.1 200 OK
349
350
351
352 /collection/member
353
354
355
356
357 HTTP/1.1 200 OK
358
359
360
361 /collection/member2
362
363
364
365
366 HTTP/1.1 200 OK
367
368
369
371 Finally, the collection has been removed by somebody else. The
372 client tries a refresh:
374 >>Request
376 GET /collection/;members HTTP/1.1
377 Host: example.com
378 Accept: application/xml
379 If-None-Match: "124"
380 >>Response
382 HTTP/1.1 404 Not Found
384 Note that it may be hard to compute entity tags for more complex
385 PROPFIND responses. For instance, most properties depend on the
386 state of the collection member, not the state of the collection
387 itself, and thus the response will change even though the state of
388 the collection itself did not change.
390 This is why this extension leaves it to the server whether to return
391 a GET-Location at all, and if so, whether to return cache validators
392 along with it.
394 A.2. WebDAV Custom Properties
396 Here, the client uses the WebDAV PROPFIND method ([RFC4918], Section
397 9.1) to obtain a custom property:
399 >>Request
401 PROPFIND /collection/member HTTP/1.1
402 Host: example.com
403 Depth: 0
404 Content-Type: application/xml
406
407
408
409
410
411 >>Response
413 HTTP/1.1 207 Multi-Status
414 Content-Type: application/xml
415 GET-Location: ; etag="1"
417
418
419 /collection/member
420
421
422 Document Title
424
425 HTTP/1.1 200 OK
426
427
428
430 >>Request
432 GET /collection/member;prop=title HTTP/1.1
433 Host: example.com
434 If-None-Match: "1"
436 >>Response
438 HTTP/1.1 304 Not Modified
440 Later, the request is repeated after the title property indeed
441 changed...:
443 >>Request
445 GET /collection/member;prop=title HTTP/1.1
446 Host: example.com
447 If-None-Match: "1"
448 >>Response
450 HTTP/1.1 200 OK
451 Content-Type: application/xml
452 ETag: "2"
454
455
456 /collection/member
457
458
459 New Document Title
461
462 HTTP/1.1 200 OK
463
464
465
467 Although this example may look like every WebDAV property would need
468 a separate entity tag, this is of course not the case. For instance,
469 a server that stores all custom properties in a single place (like a
470 properties file) could use the same computation for the entity tag
471 for all properties. Also, it could implement resources representing
472 multiple custom property values the same way.
474 A.3. DeltaV Version History Report
476 Here, the client uses the DeltaV DAV:version-tree report ("Versioning
477 Extensions to WebDAV", [RFC3253], Section 3.7) to obtain the members
478 of the version history of a version-controlled resource.
480 >>Request
482 REPORT /collection/member HTTP/1.1
483 Host: example.com
484 Depth: 0
485 Content-Type: application/xml
487
488
489
490
491
492 >>Response
494 HTTP/1.1 207 Multi-Status
495 Content-Type: application/xml
496 GET-Location:
498
499
500 /version-storage/12345/V1
501
502
503
504
505 HTTP/1.1 200 OK
506
507
508
509 /version-storage/12345/V2
510
511
512
513
514 HTTP/1.1 200 OK
515
516
517
519 Note that in this case, the substitute resource can be almost
520 identical to the one from the PROPFIND/Depth:1 example: the only
521 difference being that the report result does not contain a DAV:
522 response element for the collection itself.
524 Appendix B. Related HTTP features
526 This section discusses some related HTTP features and explains why
527 the author feels that they can't be used for the given use case.
529 B.1. Status 303
531 Section 10.3.4 of [RFC2616] defines the status code 303 (See Other):
533 The response to the request can be found under a different URI and
534 SHOULD be retrieved using a GET method on that resource. This
535 method exists primarily to allow the output of a POST-activated
536 script to redirect the user agent to a selected resource. The new
537 URI is not a substitute reference for the originally requested
538 resource. The 303 response MUST NOT be cached, but the response
539 to the second (redirected) request might be cacheable.
541 On first glance, it may look as if this addresses exactly the given
542 use case. However:
544 1. It says: "The new URI is not a substitute reference for the
545 originally requested resource. The 303 response MUST NOT be
546 cached, but the response to the second (redirected) request might
547 be cacheable." That is, the information about the alternate
548 resource is not cacheable.
550 2. Servers returning a 303 status instead of the one expected by the
551 client, such as 207 Multistatus, would likely break existing
552 clients.
554 B.2. Content-Location Header
556 Section 14.14 of [RFC2616] states:
558 The Content-Location value is not a replacement for the original
559 requested URI; it is only a statement of the location of the
560 resource corresponding to this particular entity at the time of
561 the request. (...)
563 However, the purpose of "GET-Location" is to enable the server to
564 provide a permanent replacement URI.
566 B.3. Location header
568 Section 14.30 of [RFC2616] states:
570 The Location response-header field is used to redirect the
571 recipient to a location other than the Request-URI for completion
572 of the request or identification of a new resource. (...)
574 Neither of these cases ("redirect to a location for completion of the
575 request" and "identification of a new resource") matches the use case
576 "GET-Location" covers.
578 Appendix C. Alternate Approaches
580 C.1. Link Relation
582 An alternative to introducing a new header would be to re-use an
583 existing header, such as the Link header defined in Section 19.6.2 of
584 [RFC2068]. Note that this still would require registering a link
585 relation.
587 The example from Appendix A.1 would then read like this:
589 Link: ;
590 rel=getlocation; etag="123"; max-age=3600
592 C.2. Multistatus Body Extension
594 Observing that the whole proposal tries to deal with WebDAV related
595 shortcomings, it may make sense to constrain the solution to WebDAV
596 response bodies, thereby not having to introduce anything that would
597 be visible outside WebDAV.
599 A very simple approach would be to embed the information in the DAV:
600 multistatus ([RFC4918], Section 14.16) response body.
602 Re-using the example in Appendix A.1, this could look like this:
604 HTTP/1.1 207 Multi-Status
605 Content-Type: application/xml
607
608
610 /collection/;members
611 "123"
612 3600
613
615 /collection/
616
617
618
619
620 HTTP/1.1 200 OK
621
622
623
624 /collection/member
625
626
627
628
629 HTTP/1.1 200 OK
630
631
632
634 Appendix D. Open Issues
636 D.1. Content Negotiation on GET-Location
638 Should it be possible to use Content Negotiation on the resource
639 identified by GET-Location? A use case could be a metadata provider
640 that would support different formats, such as WebDAV's multistatus
641 format (MIME type missing!), RDF, JSON, whatever.
643 This could be done using a location-extension specifying the Accept
644 header for the GET operation.
646 D.2. Using URI Templates rather than URIs
648 Should we allow servers to return URI templates
649 ([draft-gregorio-uritemplate]), so that clients can compute
650 substitute URLs for other requests as well?
652 For instance, this could be done by allowing a URI template instead
653 of the Simple-ref, and to return another template specifying how to
654 derive the template variable from the Request-URI:
656 >>Request
658 PROPFIND /documents/a/b HTTP/1.1
659 Host: example.com
660 Depth: 0
661 Content-Type: application/xml
663 >>Response
665 HTTP/1.1 207 Multi-Status
666 Content-Type: application/xml
667 GET-Location: ; path-template=
669 ...
671 So in this case, the actual URI to be used would be
672 .
674 D.3. Extensions
676 Do we need a registry for new location-directive values?
678 Appendix E. Change Log (to be removed by RFC Editor before publication)
679 E.1. Since draft-reschke-http-get-location-00
681 Add and resolve issues "non-get" and "status-codes". Add issue
682 "content-location". Add "Acknowledgments" Section. Update uri-
683 template reference. Discuss more alternative approaches: Link
684 header, Multistatus body extension.
686 Appendix F. Resolved issues (to be removed by RFC Editor before
687 publication)
689 Issues that were either rejected or resolved in this version of this
690 document.
692 F.1. status-codes
694 In Section 3:
696 Type: edit
698 julian.reschke@greenbytes.de (2007-07-31): Explain the relation
699 between the status code GET-Location comes with, and the status codes
700 for GET requests on the substitute resource.
702 Resolution (2008-03-14): Add clarification.
704 F.2. non-get
706 In Section 3:
708 Type: edit
710 julian.reschke@greenbytes.de (2007-08-05): Say something about non
711 GET/HEAD requests to the substitute resource.
713 Resolution (2008-03-14): Add clarification.
715 Appendix G. Open issues (to be removed by RFC Editor prior to
716 publication)
718 G.1. edit
720 Type: edit
722 julian.reschke@greenbytes.de (2007-07-27): Umbrella issue for
723 editorial fixes/enhancements.
725 G.2. content-location
727 In Section B.2:
729 Type: edit
731 julian.reschke@greenbytes.de (2008-03-14):
733 In http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/
734 0184.html, Roy Fielding points out that the statement about Content-
735 Location is out-of context; and that Content-Location indeed should
736 be used for this use case.
738 In this case, other information defined in GET-Location would still
739 be missing, such as validatity and etag information (see response in
740 http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/
741 0195.html).
743 So would it make sense to use Content-Location instead, and move the
744 optional fields defined in GET-Location somewhere else? Or would
745 Content-Location alone be sufficient (which proper instructions how
746 to use it with methods like PROPFIND and REPORT)?
748 Author's Address
750 Julian F. Reschke
751 greenbytes GmbH
752 Hafenweg 16
753 Muenster, NW 48155
754 Germany
756 Phone: +49 251 2807760
757 Email: julian.reschke@greenbytes.de
758 URI: http://greenbytes.de/tech/webdav/
760 Full Copyright Statement
762 Copyright (C) The IETF Trust (2008).
764 This document is subject to the rights, licenses and restrictions
765 contained in BCP 78, and except as set forth therein, the authors
766 retain all their rights.
768 This document and the information contained herein are provided on an
769 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
770 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
771 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
772 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
773 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
774 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
776 Intellectual Property
778 The IETF takes no position regarding the validity or scope of any
779 Intellectual Property Rights or other rights that might be claimed to
780 pertain to the implementation or use of the technology described in
781 this document or the extent to which any license under such rights
782 might or might not be available; nor does it represent that it has
783 made any independent effort to identify any such rights. Information
784 on the procedures with respect to rights in RFC documents can be
785 found in BCP 78 and BCP 79.
787 Copies of IPR disclosures made to the IETF Secretariat and any
788 assurances of licenses to be made available, or the result of an
789 attempt made to obtain a general license or permission for the use of
790 such proprietary rights by implementers or users of this
791 specification can be obtained from the IETF on-line IPR repository at
792 http://www.ietf.org/ipr.
794 The IETF invites any interested party to bring to its attention any
795 copyrights, patents or patent applications, or other proprietary
796 rights that may cover technology that may be required to implement
797 this standard. Please address the information to the IETF at
798 ietf-ipr@ietf.org.