--- 1/draft-ietf-webdav-redirectref-protocol-12.txt 2006-02-04 17:24:57.000000000 +0100
+++ 2/draft-ietf-webdav-redirectref-protocol-13.txt 2006-02-04 17:24:57.000000000 +0100
@@ -1,22 +1,22 @@
WEBDAV Working Group J. Whitehead
Internet-Draft U.C. Santa Cruz
-Expires: November 8, 2005 G. Clemm
+Expires: April 15, 2006 G. Clemm
IBM
J. Reschke, Ed.
greenbytes
- May 7, 2005
+ October 12, 2005
Web Distributed Authoring and Versioning (WebDAV) Redirect Reference
Resources
- draft-ietf-webdav-redirectref-protocol-12
+ draft-ietf-webdav-redirectref-protocol-13
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
@@ -27,21 +27,21 @@
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on November 8, 2005.
+ This Internet-Draft will expire on April 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This specification defines redirect reference resources. A redirect
reference resource is a resource whose default response is an
HTTP/1.1 3xx (Redirection) status code (see RFC2616, Section 10.3),
@@ -74,73 +74,76 @@
4. Overview of Redirect Reference Resources . . . . . . . . . . 7
5. Operations on Redirect Reference Resources . . . . . . . . . 8
6. MKREDIRECTREF Method . . . . . . . . . . . . . . . . . . . . 8
6.1 Example: Creating a Redirect Reference Resource with
MKREDIRECTREF . . . . . . . . . . . . . . . . . . . . . . 10
7. UPDATEREDIRECTREF Method . . . . . . . . . . . . . . . . . . 10
7.1 Example: Updating a Redirect Reference Resource with
UPDATEREDIRECTREF . . . . . . . . . . . . . . . . . . . . 12
8. Operations on Collections That Contain Redirect Reference
Resources . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 8.1 LOCK on a Collection That Contains Redirect References . . 13
- 8.2 Example: PROPFIND on a Collection with Redirect
+ 8.1 Example: PROPFIND on a Collection with Redirect
Reference Resources . . . . . . . . . . . . . . . . . . . 13
- 8.3 Example: PROPFIND with Apply-To-Redirect-Ref on a
- Collection with Redirect Reference Resources . . . . . . . 15
- 8.4 Example: COPY on a Collection That Contains a Redirect
- Reference Resource . . . . . . . . . . . . . . . . . . . . 16
- 8.5 Example: LOCK on a Collection That Contains a Redirect
- Reference Resource . . . . . . . . . . . . . . . . . . . . 17
- 9. Operations on Targets of Redirect Reference Resources . . . 19
- 10. Relative references in DAV:reftarget . . . . . . . . . . . . 19
+ 8.2 Example: PROPFIND with Apply-To-Redirect-Ref on a
+ Collection with Redirect Reference Resources . . . . . . . 16
+ 9. Operations on Targets of Redirect Reference Resources . . . 17
+ 10. Relative references in DAV:reftarget . . . . . . . . . . . . 17
10.1 Example: Resolving a Relative Reference in a
- Multi-Status Response . . . . . . . . . . . . . . . . . 19
- 11. Redirect References to Collections . . . . . . . . . . . . . 20
- 12. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 22
- 12.1 Redirect-Ref Response Header . . . . . . . . . . . . . . 22
- 12.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . 22
- 13. Redirect Reference Resource Properties . . . . . . . . . . . 22
- 13.1 DAV:redirect-lifetime (protected) . . . . . . . . . . . 22
- 13.2 DAV:reftarget (protected) . . . . . . . . . . . . . . . 23
- 14. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 23
- 14.1 redirectref XML Element . . . . . . . . . . . . . . . . 23
+ Multi-Status Response . . . . . . . . . . . . . . . . . 18
+ 11. Redirect References to Collections . . . . . . . . . . . . . 19
+ 12. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 12.1 Redirect-Ref Response Header . . . . . . . . . . . . . . 21
+ 12.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . 21
+ 13. Redirect Reference Resource Properties . . . . . . . . . . . 21
+ 13.1 DAV:redirect-lifetime (protected) . . . . . . . . . . . 21
+ 13.2 DAV:reftarget (protected) . . . . . . . . . . . . . . . 22
+ 14. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 14.1 redirectref XML Element . . . . . . . . . . . . . . . . 22
15. Extensions to the DAV:response XML Element for
- Multi-Status Responses . . . . . . . . . . . . . . . . . . . 23
- 16. Capability Discovery . . . . . . . . . . . . . . . . . . . . 23
+ Multi-Status Responses . . . . . . . . . . . . . . . . . . . 22
+ 16. Capability Discovery . . . . . . . . . . . . . . . . . . . . 22
16.1 Example: Discovery of Support for Redirect Reference
- Resources . . . . . . . . . . . . . . . . . . . . . . . 24
- 17. Security Considerations . . . . . . . . . . . . . . . . . . 24
- 17.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 24
- 17.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . 25
- 17.3 Redirect Reference Resources and Denial of Service . . . 25
- 17.4 Revealing Private Locations . . . . . . . . . . . . . . 25
- 18. Internationalization Considerations . . . . . . . . . . . . 25
- 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
- 20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
- 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
+ Resources . . . . . . . . . . . . . . . . . . . . . . . 23
+ 17. Security Considerations . . . . . . . . . . . . . . . . . . 23
+ 17.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 23
+ 17.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . 24
+ 17.3 Redirect Reference Resources and Denial of Service . . . 24
+ 17.4 Revealing Private Locations . . . . . . . . . . . . . . 24
+ 18. Internationalization Considerations . . . . . . . . . . . . 24
+ 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
+ 19.1 HTTP headers . . . . . . . . . . . . . . . . . . . . . . 25
+ 19.1.1 Redirect-Ref . . . . . . . . . . . . . . . . . . . . 25
+ 19.1.2 Apply-To-Redirect-Ref . . . . . . . . . . . . . . . 25
+ 20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
22. Normative References . . . . . . . . . . . . . . . . . . . . 26
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . 27
A.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 27
A.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 27
- A.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 28
- A.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 28
+ A.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 27
+ A.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 27
A.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 28
A.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 28
A.7 Since draft-ietf-webdav-redirectref-protocol-08 . . . . . 28
- A.8 Since draft-ietf-webdav-redirectref-protocol-09 . . . . . 29
- A.9 Since draft-ietf-webdav-redirectref-protocol-10 . . . . . 29
- A.10 Since draft-ietf-webdav-redirectref-protocol-11 . . . . 29
- B. Open issues (to be removed by RFC Editor prior to
+ A.8 Since draft-ietf-webdav-redirectref-protocol-09 . . . . . 28
+ A.9 Since draft-ietf-webdav-redirectref-protocol-10 . . . . . 28
+ A.10 Since draft-ietf-webdav-redirectref-protocol-11 . . . . 28
+ A.11 Since draft-ietf-webdav-redirectref-protocol-12 . . . . 28
+ B. Resolved issues (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . 29
- B.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
+ B.1 8.1_deep_lock_complexity . . . . . . . . . . . . . . . . . 29
+ B.2 headerreg . . . . . . . . . . . . . . . . . . . . . . . . 29
+ C. Open issues (to be removed by RFC Editor prior to
+ publication) . . . . . . . . . . . . . . . . . . . . . . . . 29
+ C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . 32
1. Introduction
This specification extends the Web Distributed Authoring Protocol
(WebDAV) to enable clients to create new access paths to existing
resources. This capability is useful for several reasons:
WebDAV makes it possible to organize HTTP resources into hierarchies,
@@ -499,58 +502,64 @@
HTTP/1.1 200 OK
This request has updated the redirect reference's DAV:reftarget
property to "/i-d/draft-webdav-protocol-08b.txt", and has not changed
the DAV:redirect-lifetime value. Note that the "Apply-To-Redirect-
Ref" request header must be used, otherwise the request would result
in a redirect (3xx) response status.
8. Operations on Collections That Contain Redirect Reference Resources
- Consistent with the rules in Section 5, the response for each
- redirect reference encountered while processing a collection MUST be
- a 3xx (Redirection) unless a "Apply-To-Redirect-Ref: T" header is
- included with the request. The overall response will therefore be a
- 207 (Multi-Status). For each DAV:response element representing a
- redirect reference, the server MUST include an additional DAV:
- location element, specifying the value of the "Location" header that
- would be returned otherwise. The extension is defined in Section 15
- below.
-
- The Apply-To-Redirect-Ref header (defined in Section 12.2) MAY be
- used with any request on a collection. If present, it will be
- applied to all redirect reference resources encountered while
- processing the collection.
-
-8.1 LOCK on a Collection That Contains Redirect References
+ According to [RFC2518], Section 9.2, methods that have defined
+ interactions with the "Depth" request header should apply all other
+ request headers to each resource in scope. However, applying this
+ principle to the "Apply-To-Redirect-Ref" header uniformly would make
+ it impractical to implement this specification on top of existing
+ servers and also would result in unexpected server behaviour for
+ clients that do not take the existence of redirect references into
+ account. On the other hand, the definition of the "Depth" header
+ allows to explicitly define alternate behaviours.
- An attempt to lock (with Depth: infinity) a collection that contains
- redirect references without specifying "Apply-To-Redirect-Ref: T"
- will always fail. The Multi-Status response will contain a 3xx
- response for each redirect reference.
+ For this reason, this specification defines the interaction between
+ "Depth" and "Apply-To-Redirect-Ref" request headers on a case-by-case
+ basis, and also provides a default for methods not mentioned here
+ that do not specify the behaviour themselves.
- Reference-aware clients can lock the collection by using Apply-To-
- Redirect-Ref, and, if desired, lock the targets of the redirect
- references individually.
+ +-------------+-----------------+------------------+-----------+
+ | method name | defined in | supported depths | behaviour |
+ +-------------+-----------------+------------------+-----------+
+ | COPY | [RFC2518], 8.9 | 0, infinity | "T" |
+ | DELETE | [RFC2518], 8.7 | infinity | "T" |
+ | LOCK | [RFC2518], 8.11 | 0, infinity | "T" |
+ | MOVE | [RFC2518], 8.10 | 0, infinity | "T" |
+ | PROPFIND | [RFC2518], 8.2 | 0, 1, infinity | inherit |
+ | REPORT | [RFC3253], 3.6 | 0, 1, infinity | inherit |
+ | default | | | "T" |
+ +-------------+-----------------+------------------+-----------+
- Non-referencing clients must resort to locking each resource
- individually.
+ When the behaviour is defined to be "inherit", the method should
+ follow RFC2518's default behaviour for "Depth" operations, which
+ means applying the value given for "Apply-To-Redirect-Ref" to each
+ resource in scope. On the other hand, when it is defined to be "T",
+ the method should behave as if a "Apply-To-Redirect-Ref: T" header
+ was specified for each operation on child resources. The latter
+ ensures that "Depth: infinity" operations will not fail unexpectedly
+ just because there was a redirect reference resource in scope.
-8.2 Example: PROPFIND on a Collection with Redirect Reference Resources
+8.1 Example: PROPFIND on a Collection with Redirect Reference Resources
Suppose a PROPFIND request with Depth: infinity is submitted to the
following collection, with the members shown here:
/MyCollection/
(non-reference resource) diary.html
(redirect reference resource) nunavut
-
>> Request:
PROPFIND /MyCollection/ HTTP/1.1
Host: example.com
Depth: infinity
Apply-To-Redirect-Ref: F
Content-Type: text/xml
Content-Length: xxxx
@@ -601,21 +610,21 @@
To-Redirect-Ref header is set to "F". The collection contains one
URI that identifies a redirect reference resource. The response
element for the redirect reference resource has a status of 302
(Found), and includes a DAV:location extension element to allow
clients to retrieve the properties of its target resource. (The
response element for the redirect reference resource does not include
the requested properties. The client can submit another PROPFIND
request to the URI in the DAV:location pseudo-property to retrieve
those properties.)
-8.3 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with
+8.2 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with
Redirect Reference Resources
Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth:
infinity is submitted to the following collection, with the members
shown here:
/MyCollection/
(non-reference resource) diary.html
(redirect reference resource) nunavut
@@ -689,121 +698,20 @@
HTTP/1.1 200 OK
Since the "Apply-To-Redirect-Ref: T" header is present, the response
shows the properties of the redirect reference resource in the
collection rather than reporting a 302 status.
-8.4 Example: COPY on a Collection That Contains a Redirect Reference
- Resource
-
- Suppose a COPY request is submitted to the following collection, with
- the members shown:
-
- /MyCollection/
- (non-reference resource) diary.html
- (redirect reference resource) nunavut with target
- /Someplace/nunavut.map
-
- >> Request:
-
- COPY /MyCollection/ HTTP/1.1
- Host: example.com
- Depth: infinity
- Destination: http://example.com/OtherCollection/
-
- >> Response:
-
- HTTP/1.1 207 Multi-Status
- Content-Type: text/xml; charset="utf-8"
- Content-Length: xxx
-
-
-
-
- /MyCollection/nunavut
- HTTP/1.1 302 Found
-
- http://example.com//Someplace/nunavut.map
-
-
-
-
- In this case, since /MyCollection/nunavut is a redirect reference
- resource, the COPY operation was only a partial success. The
- redirect reference resource was not copied, but a 302 response was
- returned for it. So the resulting collection is as follows:
-
- /OtherCollection/
- (non-reference resource) diary.html
-
-8.5 Example: LOCK on a Collection That Contains a Redirect Reference
- Resource
-
- Suppose a LOCK request is submitted to the following collection, with
- the members shown:
-
- /MyCollection/
- (non-reference resource) diary.html
- (redirect reference resource) nunavut
- >> Request:
-
- LOCK /MyCollection/ HTTP/1.1
- Host: example.com
- Apply-To-Redirect-Ref: F
- Content-Type: text/xml
-
-
-
-
-
-
-
- >> Response:
-
- HTTP/1.1 207 Multi-Status
- Content-Type: text/xml
- Content-Length: nnnn
-
-
-
-
- /MyCollection/
- HTTP/1.1 424 Failed Dependency
-
-
- /MyCollection/diary.html
- HTTP/1.1 424 Failed Dependency
-
-
- /MyCollection/nunavut
- HTTP/1.1 302 Found
-
- http://example.ca/art/inuit/
-
-
-
-
- The server returns a 302 response code for the redirect reference
- resource in the collection. Consequently, neither the collection nor
- any of the resources identified by its internal member URIs were
- locked. A referencing-aware client can submit a separate LOCK
- request to the URI in the DAV:location element returned for the
- redirect reference resource, and can resubmit the LOCK request with
- the Apply-To-Redirect-Ref header to the collection. At that point
- both the reference resource and its target resource will be locked
- (as well as the collection and all the resources identified by its
- other members).
-
9. Operations on Targets of Redirect Reference Resources
Operations on targets of redirect reference resources have no effect
on the reference resource.
10. Relative references in DAV:reftarget
The URI in the href in a DAV:reftarget property MAY be a relative
reference. In this case, the base URI to be used for resolving it to
absolute form is the URI used in the HTTP message to identify the
@@ -1117,20 +1025,48 @@
18. Internationalization Considerations
All internationalization considerations mentioned in [RFC2518] also
apply to this document.
19. IANA Considerations
All IANA considerations mentioned in [RFC2518] also apply to this
document.
+19.1 HTTP headers
+
+ This document specifies the two new HTTP headers listed below.
+
+19.1.1 Redirect-Ref
+
+ Header field name: Redirect-Ref
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document: this specification (Section 12.1)
+
+19.1.2 Apply-To-Redirect-Ref
+
+ Header field name: Apply-To-Redirect-Ref
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document: this specification (Section 12.2)
+
20. Contributors
Many thanks to Jason Crawford, Jim Davis, Chuck Fay and Judith Slein
who can take credit for big parts of the original design of this
specification.
21. Acknowledgements
This document has benefited from thoughtful discussion by Jim Amsden,
Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen,
@@ -1267,111 +1202,150 @@
Add and resolve issues "13_allprop" and "rfc2396bis". Use the term
"Request-URI" throughout (this is what RFC2616 defines). Center some
of the artwork. Add and resolve issue "abnf".
A.10 Since draft-ietf-webdav-redirectref-protocol-11
Re-open and close issue "anbf" (implied LWS). Raise and close issue
"frag_in_target". Add precondition name for legal reftarget element
contents. Enhance index. Add and close issue "dtd-changes".
-Appendix B. Open issues (to be removed by RFC Editor prior to
+A.11 Since draft-ietf-webdav-redirectref-protocol-12
+
+ Remove RFC2616 reference from abstract. Add and resolve issue
+ 8.1_deep_lock_complexity. Add and resolve issue headerreg (reg.
+
+ template for new HTTP headers in IANA considerations section).
+
+Appendix B. Resolved issues (to be removed by RFC Editor before
publication)
-B.1 edit
+ Issues that were either rejected or resolved in this version of this
+ document.
+
+B.1 8.1_deep_lock_complexity
+
+ Type: change
+
+
+
+ jbaumgarten@apple.com (2005-06-27): ...In particular, the failure of
+ locking methods that contain redirected resources would confuse our
+ clients. Instead, we have decided to implement a simpler redirect
+ capability via a custom property (not a WebDAV resource type) that is
+ only activated when indicated by the client request.
+
+ julian.reschke@greenbytes.de (2005-07-03): Analysis of issue in http:
+ //lists.w3.org/Archives/Public/w3c-dist-auth/2005JulSep/0005.html.
+
+ Resolution (2005-10-01): Make all methods except PROPFIND and REPORT
+ default to "Apply-To-Redirect-Ref: T".
+
+B.2 headerreg
+
+ Type: change
+
+ julian.reschke@greenbytes.de (2005-08-24): Add RFC3864 registrations
+ for new HTTP headers.
+
+Appendix C. Open issues (to be removed by RFC Editor prior to
+ publication)
+
+C.1 edit
Type: edit
julian.reschke@greenbytes.de (2004-10-03): Umbrella issue for
editorial changes.
Index
A
- Apply-To-Redirect-Ref header 22
+ Apply-To-Redirect-Ref header 21
C
Condition Names
DAV:legal-reftarget (pre) 10-11
DAV:locked-update-allowed (pre) 9, 11
DAV:must-be-redirectref (pre) 11
DAV:name-allowed (pre) 9
DAV:new-redirectref (post) 10
DAV:parent-resource-must-be-non-null (pre) 9
DAV:redirect-lifetime-supported (pre) 10-11
DAV:redirect-lifetime-update-supported (pre) 11
DAV:redirectref-updated (post) 12
DAV:resource-must-be-null (pre) 9
D
DAV header
- compliance class 'redirectrefs' 23
+ compliance class 'redirectrefs' 22
DAV:legal-reftarget precondition 10-11
DAV:locked-update-allowed precondition 9, 11
DAV:mkdirectref XML element 9
DAV:mkredirectref-response XML element 9
DAV:must-be-redirectref precondition 11
DAV:name-allowed precondition 9
DAV:new-redirectref postcondition 10
DAV:parent-resource-must-be-non-null precondition 9
- DAV:permanent XML element 9, 22
- DAV:redirect-lifetime property 22
- DAV:redirect-lifetime XML element 9, 22
+ DAV:permanent XML element 9, 21
+ DAV:redirect-lifetime property 21
+ DAV:redirect-lifetime XML element 9, 21
DAV:redirect-lifetime-supported precondition 10-11
DAV:redirect-lifetime-update-supported precondition 11
- DAV:redirectref resource type 23
+ DAV:redirectref resource type 22
DAV:redirectref-updated postcondition 12
- DAV:reftarget property 23
+ DAV:reftarget property 22
DAV:reftarget XML element 9
DAV:resource-must-be-null precondition 9
- DAV:temporary XML element 9, 22
+ DAV:temporary XML element 9, 21
DAV:updateredirectref-response XML element 11
H
Headers
- Apply-To-Redirect-Ref 22
- Redirect-Ref 22
+ Apply-To-Redirect-Ref 21
+ Redirect-Ref 21
M
Methods
MKREDIRECTREF 8
UPDATEREDIRECTREF 10
MKREDIRECTREF method 8
N
Non-Reference Resource 6
P
Properties
- DAV:redirect-lifetime 22
- DAV:reftarget 23
+ DAV:redirect-lifetime 21
+ DAV:reftarget 22
R
Redirect Reference Resource 6
- Redirect-Ref header 22
+ Redirect-Ref header 21
Resource Types
- DAV:redirectref 23
+ DAV:redirectref 22
T
Target Resource 7
U
UPDATEREDIRECTREF method 10
X
XML elements
DAV:mkdirectref 9
DAV:mkredirectref-response 9
- DAV:permanent 9, 22
- DAV:redirect-lifetime 9, 22
+ DAV:permanent 9, 21
+ DAV:redirect-lifetime 9, 21
DAV:reftarget 9
- DAV:temporary 9, 22
+ DAV:temporary 9, 21
DAV:updateredirectref-response 11
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information