idnits 2.17.1 draft-harrison-regext-rdap-redirect-with-content-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 1, 2020) is 1270 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 7483 (Obsoleted by RFC 9083) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7484 (Obsoleted by RFC 9224) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Harrison 3 Internet-Draft G. Michaelson 4 Intended status: Standards Track APNIC 5 Expires: May 5, 2021 November 1, 2020 7 RDAP Redirect with Content 8 draft-harrison-regext-rdap-redirect-with-content-00 10 Abstract 12 The Registration Data Access Protocol (RDAP) is used by Regional 13 Internet Registries (RIRs) and Domain Name Registries (DNRs) to 14 provide access to their resource registration information. When an 15 RDAP service operator has delegated authority for a resource to a 16 third party, the operator will configure its RDAP service to redirect 17 requests for that resource to the third party. However, the client 18 may be interested in the resource registration data that the first 19 service operator has in its own right, for various reasons. This 20 document defines a conformance code that a service operator can use 21 to indicate that when redirecting requests, it will also include as 22 the body of the response the RDAP object (if any) that it has in its 23 own right for the requested resource. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 5, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 61 2. Implementation . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 67 6.2. Informative References . . . . . . . . . . . . . . . . . 4 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 The Registration Data Access Protocol (RDAP) [RFC7480] is used by 73 Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) 74 to provide access to their resource registration information. For a 75 client, this typically involves following the bootstrap process 76 [RFC7484] to determine the base URL for the query. When the service 77 operator for the base URL has delegated authority for a resource to a 78 third party, the operator will configure its RDAP service to redirect 79 requests accordingly. 81 The client may also be interested in the registration data that the 82 original service operator has, though. For example: 84 the original service operator's responses may be in conformance 85 with an externally-defined RDAP profile, such that the client 86 finds them easier or more useful to deal with than the responses 87 provided by the delegated service operator; 89 the original service operator's responses may provide useful 90 information about larger delegations of resources to delegated 91 service operators; 93 where both service operators record information about the same 94 delegation (e.g. the same specific IP network), the delegated 95 operator may omit some information recorded by the original 96 operator which is useful to the client; or 97 the delegated service may be unavailable for some reason, and the 98 client may be content to rely on the data from the original 99 service operator in that situation. 101 It is already open to a service operator to return an RDAP object as 102 the body of a redirect response: see section 6.4 of [RFC7231] and 103 section 5.2 of [RFC7480], neither of which prohibits this behaviour. 104 However, because this is unusual both in the RDAP context and more 105 generally, this document defines the parameters of this behaviour, as 106 well as a conformance code that can be used to signal that this 107 behaviour is supported. 109 1.1. Conventions Used in This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 2. Implementation 119 An RDAP service operator that implements this specification MUST 120 include an RDAP object ([RFC7483]) as the body of any non-permanent 121 (HTTP 302, 303, or 307) redirect response that it returns, whenever 122 it records data in its own right about the requested resource, or 123 about a resource for which a response may be validly returned for the 124 requested resource (for example, a less-specific IP network object). 126 An RDAP service operator that implements this specification MUST 127 include the string literal "redirect_with_content" in the 128 rdapConformance array of a "/help" response, as well as any redirect 129 response that includes an RDAP object as its body. The service 130 operator MAY include this string literal in other responses. 132 3. Security Considerations 134 [RFC7481] describes security requirements and considerations for RDAP 135 generally. This specification does not introduce any new 136 requirements/considerations past those defined in that document. 138 4. IANA Considerations 140 IANA is requested to register the following values in the RDAP 141 Extensions Registry: 143 Extension identifier: redirect_with_content 144 Registry operator: Any 146 Published specification: This document. 148 Contact: IETF 150 5. Acknowledgements 152 TBD 154 6. References 156 6.1. Normative References 158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 159 Requirement Levels", BCP 14, RFC 2119, 160 DOI 10.17487/RFC2119, March 1997, 161 . 163 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 164 Registration Data Access Protocol (RDAP)", RFC 7481, 165 DOI 10.17487/RFC7481, March 2015, 166 . 168 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 169 Registration Data Access Protocol (RDAP)", RFC 7483, 170 DOI 10.17487/RFC7483, March 2015, 171 . 173 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 174 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 175 May 2017, . 177 6.2. Informative References 179 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 180 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 181 DOI 10.17487/RFC7231, June 2014, 182 . 184 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 185 Registration Data Access Protocol (RDAP)", RFC 7480, 186 DOI 10.17487/RFC7480, March 2015, 187 . 189 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 190 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 191 2015, . 193 Authors' Addresses 195 Tom Harrison 196 Asia-Pacific Network Information Centre 197 6 Cordelia St 198 South Brisbane, QLD 4101 199 Australia 201 Email: tomh@apnic.net 203 George G. Michaelson 204 Asia-Pacific Network Information Centre 205 6 Cordelia St 206 South Brisbane, QLD 4101 207 Australia 209 Email: ggm@apnic.net