idnits 2.17.1 draft-fregly-regext-rdap-search-regex-02.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 (May 10, 2017) is 2514 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 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7482 (Obsoleted by RFC 9082) ** Obsolete normative reference: RFC 7483 (Obsoleted by RFC 9083) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Fregly 3 Internet-Draft S. Sheth 4 Intended status: Standards Track S. Hollenbeck 5 Expires: November 11, 2017 Verisign Labs 6 May 10, 2017 8 Registration Data Access Protocol (RDAP) Search Using POSIX Regular 9 Expressions 10 draft-fregly-regext-rdap-search-regex-02 12 Abstract 14 The Registration Data Access Protocol (RDAP) provides limited search 15 functionality based on pattern matching. This document describes an 16 RDAP query extension that provides additional search functionality 17 using POSIX extended regular expressions. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 11, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 55 2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 3 56 2.1. Domain Search . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Name Server Search . . . . . . . . . . . . . . . . . . . 5 58 2.3. Entity Search . . . . . . . . . . . . . . . . . . . . . . 6 59 2.4. Future Path Segments . . . . . . . . . . . . . . . . . . 7 60 3. Search Pattern Syntax . . . . . . . . . . . . . . . . . . . . 7 61 4. Query Processing . . . . . . . . . . . . . . . . . . . . . . 8 62 5. Internationalization Considerations . . . . . . . . . . . . . 9 63 6. Implementation Considerations . . . . . . . . . . . . . . . . 9 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 66 8.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 11 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 71 11.2. Informative References . . . . . . . . . . . . . . . . . 14 72 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 The search patterns for Registration Data Access Protocol (RDAP) 78 search as described in RFC 7482 [RFC7482] are limited. The protocol 79 described in this specification extends RDAP search capabilities by 80 adding path segments for RDAP search functions using a RESTful web 81 service and POSIX [IEEE.1003.1_2013_EDITION] extended regular 82 expressions. The service is implemented using the Hypertext Transfer 83 Protocol (HTTP) [RFC7230] and the conventions described in RFC 7480 84 [RFC7480]. 86 1.1. Conventions Used in This Document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. RDAP Path Segment Specification 94 The path segments defined in this section are OPTIONAL extensions of 95 path segments defined in RFC 7482 [RFC7482]. The resource type path 96 segments for search are: 98 o 'domains': Used to identify a domain name information search using 99 a pattern to match a fully-qualified domain name. 100 o 'nameservers': Used to identify a name server information search 101 using a pattern to match a host name. 102 o 'entities': Used to identify an entity information search using a 103 pattern to match a string identifier. 105 The search patterns in the path segments MUST be POSIX extended 106 regular expressions. Non-URL-safe characters in Search patterns MUST 107 be percent-encoded. Percent-encoding MUST be as described in section 108 2.1 of RFC 3986 [RFC3986]. Percent-encoding will eliminate errors 109 that might occur due to web-servier or app-server interpretation of 110 certain unsafe characters and will eliminate errors due to 111 inconsistent encoding and decoding semantics for certain characters. 112 For instance, the space character may be encoded as "+" when 113 submitted through a HTML form and encoded as "%20" when submitted 114 through the address bar of a Web browser. Detailed results can be 115 retrieved using the HTTP GET method and the path segments specified 116 here. 118 This document defines an RDAP query parameter, "searchtype", that is 119 used to identify search requests that require specialized processing 120 beyond the limited functionality described in RFC 7482 [RFC7482]. 121 Search processing using POSIX [IEEE.1003.1_2013_EDITION] extended 122 regular expressions is indicated with a query string parameter value 123 of "regex", e.g. "searchtype=regex". Other forms of search 124 processing are possible and can be described in other specifications 125 using other values for the "searchtype" query parameter. See 126 Section 2.4 for additional information. 128 2.1. Domain Search 130 Syntax: domains?name=&searchtype=regex 132 Syntax: domains?nsLdhName=&searchtype=regex 134 Syntax: domains?nsIp=&searchtype=regex 136 Searches for domain information by name are specified using this 137 form: 139 domains?name=XXXX&searchtype=regex 140 If the URL query string parameter "searchtype" has a value of 141 "regex", then XXXX MUST be a POSIX extended regular expression. Non- 142 URL-safe characters in XXXX MUST be percent-encoded. Percent- 143 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 144 The supplied regular expression will be matched against domains in a 145 name space administered by the server operator. Domain names are as 146 defined by RFC 5890 [RFC5890] in "letters, digits, hyphen" format. 147 The following URL would be used to find information for domain names 148 matching the "e[a-z]ample\.com" pattern: 150 https://example.com/rdap/domains?name=e%5Ba- 151 z%5Dample%5C.com&searchtype=regex 153 Internationalized Domain Names (IDNs) in U-label format [RFC5890] can 154 also be matched by POSIX extended regular expression search patterns. 155 Search patterns for these names are of the form 156 /domains?name=XXXX&searchtype=regex, where XXXX is a POSIX extended 157 regular expression. Non-URL-safe characters in XXXX MUST be percent- 158 encoded. Percent-encoding MUST be as described in section 2.1 of RFC 159 3986 [RFC3986]. The supplied regular expression will be matched 160 against domain names in U-label format. See section 6.1 of RFC 7482 161 [RFC7482] for information describing U-label character encoding. See 162 Section 5 for other considerations relative to regular expression 163 matching of IDNs. 165 Searches for domain information by name server name are specified 166 using this form: 168 domains?nsLdhName=YYYY&searchtype=regex 170 If the URL query string parameter "searchtype" has a value of 171 "regex", then YYYY MUST be a POSIX extended regular expression. Non- 172 URL-safe characters in YYYY MUST be percent-encoded. Percent- 173 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 174 The supplied regular expression will be matched against host names in 175 a name space administered by the server operator. Host names are as 176 defined by RFC 5890 [RFC5890] in "letters, digits, hyphen" format. 177 The following URL would be used to search for domains delegated to 178 name servers matching the "ns[1-9]\.e[a-z]ample\.com" pattern: 180 https://example.com/rdap/domains?nsLdhName=ns%5B1-9%5D%5C.e%5Ba- 181 z%5Dample%5C.com&searchtype=regex 183 Searches for domain information by name server IP address are 184 specified using this form: 186 domains?nsIp=ZZZZ&searchtype=regex 187 If the URL query string parameter "searchtype" has a value of 188 "regex", then ZZZZ MUST be a POSIX extended regular expression. Non- 189 URL-safe characters in ZZZZ MUST be percent-encoded. Percent- 190 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 191 The supplied regular expression will be matched against IPv4 192 addresses [RFC1166] and IPv6 addresses [RFC5952] associated with 193 specific name servers. The following URL would be used to search for 194 domains that have been delegated to name servers that have IP 195 addresses matching the "192\.0\.[1-9]\.0" pattern: 197 https://example.com/rdap/ 198 domains?nsIp=192%5C.0%5C.%5B1-9%5D%5C.0&searchtype=regex 200 2.2. Name Server Search 202 Syntax: nameservers?name=&searchtype=regex 205 Syntax: nameservers?ip=&searchtype=regex 207 Searches for name server information by name server name are 208 specified using this form: 210 nameservers?name=XXXX&searchtype=regex 212 If the URL query string parameter "searchtype" has a value of 213 "regex", then XXXX MUST be a POSIX extended regular expression. Non- 214 URL-safe characters in XXXX MUST be percent-encoded. Percent- 215 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 216 The supplied regular expression will be matched against name server 217 names in a name space administered by the server operator. Name 218 server names are as defined in RFC 5890 [RFC5890] in "letters, 219 digits, hyphen" format. Matches will return information for the 220 matching name servers. The following URL would be used to find 221 information for name server names matching the 222 "ns[1-9]\.e[a-z]ample\.com" pattern: 224 https://example.com/rdap/nameservers?name=ns%5B1-9%5D%5C.e%5Ba- 225 z%5Dample%5C.com&searchtype=regex 227 Internationalized name server names in U-label format [RFC5890] can 228 also be matched by POSIX extended regular expression search patterns. 229 Search patterns for these names are of the form 230 /nameservers?name=XXXX&searchtype=regex, where XXXX is a POSIX 231 extended regular expression. Non-URL-safe characters in XXXX MUST be 232 percent-encoded. Percent-encoding MUST be as described in section 233 2.1 of RFC 3986 [RFC3986]. The supplied regular expression will be 234 matched against name server names in U-label format. See section 6.1 235 of RFC 7482 [RFC7482] for information describing U-label character 236 encoding. See Section 5 for other considerations relative to regular 237 expression matching of U-labels. 239 Searches for name server information by name server IP address are 240 specified using this form: 242 nameservers?ip=YYYY&searchtype=regex 244 If the URL query string parameter "searchtype" has a value of 245 "regex", then YYYY MUST be a POSIX extended regular expression. Non- 246 URL-safe characters in YYYY MUST be percent-encoded. Percent- 247 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 248 The supplied regular expression will be matched against IPv4 249 addresses [RFC1166] and IPv6 addresses [RFC5952] associated with 250 specific name servers. The following URL would be used to search for 251 name server names that resolve to addresses matching the 252 "192\.0\.[1-9]\.0" pattern: 254 https://example.com/rdap/ 255 nameservers?ip=192%5C.0%5C.%5B1-9%5D%5C.0&searchtype=regex 257 2.3. Entity Search 259 Syntax: entities?fn=&searchtype=regex 261 Syntax: entities?handle=&searchtype=regex 264 Searches for entity information by name are specified using this 265 form: 267 entities?fn=XXXX&searchtype=regex 269 If the URL query string parameter "searchtype" has a value of 270 "regex", then XXXX MUST be a POSIX extended regular expression. Non- 271 URL-safe characters in XXXX MUST be percent-encoded. Percent- 272 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 273 The supplied regular expression will be matched against the "FN" 274 property of an entity (such as a contact, registrant, or registrar) 275 name as specified in Section 5.1 of RFC 7483 [RFC7483]. The 276 following URL would be used to find information for entity names 277 matching the "Bobby[[:space:]]Joe[a-z]*" pattern: 279 https://example.com/rdap/ 280 entities?fn=Bobby%5B%5B%3Aspace%3A%5D%5DJoe%5Ba- 281 z%5D%2A&searchtype=regex 282 Searches for entity information by handle are specified using this 283 form: 285 entities?handle=XXXX&searchtype=regex 287 If the URL query string parameter "searchtype" has a value of 288 "regex", then XXXX MUST be a POSIX extended regular expression. Non- 289 URL-safe characters in XXXX MUST be percent-encoded. Percent- 290 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 291 The supplied regular expression will be matched against an entity 292 (such as a contact, registrant, or registrar) identifier whose syntax 293 is specific to the registration provider. The following URL would be 294 used to find information for entity handles matching the "CID- 295 4[0-9]*" pattern: 297 https://example.com/rdap/entities?handle=CID- 298 4%5B0-9%5D%2A&searchtype=regex 300 2.4. Future Path Segments 302 OPTIONAL extensions to new RDAP path segments defined in future RDAP 303 specifications MAY be implemented to support POSIX extended regular 304 expressions search capability. The syntax for such OPTIONAL 305 extensions MUST be modeled on the syntax defined in Section 2.1, 306 Section 2.2, and Section 2.3. The following syntax template MUST be 307 followed: 309 Syntax: {path_segment}?{property}=XXXX&searchtype=regex 311 If the URL query string parameter "searchtype" has a value of 312 "regex", then XXXX MUST be a POSIX extended regular expression. Non- 313 URL-safe characters in XXXX MUST be percent-encoded. Percent- 314 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 315 The supplied regular expression will be matched against the property 316 specified by {property} for the path segment specified by 317 {path_segment}. For example, if a new RDAP path segment "foo" is 318 defined and has a property "bar", the following URL would be used to 319 find information for the "foo" resource type with a "bar" property 320 matching the "widget:.*mech.*" pattern: 322 https://example.com/rdap/ 323 foo?bar=widget%3A.%2Amech.%2A&searchtype=regex 325 3. Search Pattern Syntax 327 POSIX extended regular expression search pattern syntax is defined in 328 Section 9 of IEEE Std 1003.1, 2013 Edition 329 [IEEE.1003.1_2013_EDITION]. An RDAP service implementation MAY 330 implement a subset of the extended regular expression syntax and 331 capabilities defined by the specification. An RDAP service 332 implementation MUST specify the regular expression syntax and 333 capabilities it supports in response to a query to the /help path 334 segment as specified in section 3.1.6 of RFC 7482 [RFC7482]. 336 Characters within a regular expression search pattern may be URI 337 reserved characters. To avoid ambiguity in parsing a URL containing 338 a regular expression search pattern, non-URL-safe character in the 339 regular expression search pattern MUST be percent-encoded as 340 described in RFC 3986 [RFC3986]. 342 4. Query Processing 344 RDAP clients using regular expression search patterns MUST percent- 345 encode non-URL-safe characters in the regular expression search 346 pattern as described in RFC 3986 [RFC3986]. The regular expression 347 SHOULD be consistent with the regular expression syntax and 348 capabilities supported by the RDAP service implementation that is 349 being queried in order to provide predictable results. The use of a 350 regular expression that is not consistent with the capabilities of 351 the RDAP service implementation MUST result in the return of an HTTP 352 400 response code as described in section 5.4 of RFC 7480 [RFC7480]. 354 An RDAP service implementation will receive regular expressions 355 search patterns that contain percent-encoded characters. Prior to 356 processing a regular expression, the RDAP service MUST decode the 357 received percent-encoded characters in regular expressions as 358 described in RFC 3986 [RFC3986]. After decoding the received regular 359 expression, the regular expression MUST be matched as described in 360 Section 2.1, Section 2.2 and Section 2.3. Matching records related 361 to the search are then returned in the client. 363 The POSIX regular expression specification [IEEE.1003.1_2013_EDITION] 364 allows implementations to provide case insensitive searching. RDAP 365 service implementations SHOULD implement case insensitive searching 366 as described in the specification. This will allow for consistency 367 in search results regardless of the case of the RDAP data being 368 searched. For example, some RDAP service implementations may 369 represent domain names in upper case during searching while other 370 RDAP service implementations may represent domain names in lower case 371 or mixed case during searching. Case insensitive searching will 372 alleviate the need for search clients to know how each RDAP service 373 implementation represents the case of searchable data. RDAP service 374 implementations that do not perform case insensitive searching may 375 produce unexpected search results for entities that are not aware of 376 how the service represents the case of searchable data. 378 An RDAP service implementation MUST specify its support or lack of 379 support for case insensitive searching in response to a query to the 380 /help path segment as specified in section 3.1.6 of RFC 7482 381 [RFC7482]. 383 Servers indicate the success or failure of query processing of a 384 regular expression search pattern by returning an appropriate HTTP 385 response code to the client. Response codes not specifically 386 identified in this document are described in RFC 7480 [RFC7480]. 388 5. Internationalization Considerations 390 An RDAP service implementation that supports regular expression 391 search patterns MUST support pattern construction and pattern 392 matching using UTF-8 encoded character strings. Other character 393 encoding considerations are described in section 6.1 of RFC 7482 394 [RFC7482]. 396 6. Implementation Considerations 398 The set of related records that may be returned in response to a 399 search with a regular expression search pattern are subject to the 400 constraints specified in section 4.2 of RFC 7482 [RFC7482]. 402 An RDAP service implementation MAY choose to limit the scope of 403 searches to RDAP data that is managed by the RDAP service 404 implementation. For example, an RDAP response to a query that could 405 be matched against multiple TLDs or data in related RDAP repositories 406 (such as those distributed between domain registry and domain 407 registrar) need only return matches for the data managed by the RDAP 408 service implementation. 410 Implementators should take care to ensure that decoding of percent- 411 encoded characters in a received regular expression is only performed 412 once. Standard APIs for processing HTTP requests will likely perform 413 decoding of percent-encoded characters prior to providing a recieved 414 regular expression to the RDAP service implementation code. In such 415 case case, the RDAP service implementation code should not attempt to 416 perform decoding for percent-encoded characters. 418 Regular expression matching results for some search patterns may vary 419 based on the regular expression search engine used, the version of 420 the engine used, and configuration of the search engine. For 421 example, POSIX [IEEE.1003.1_2013_EDITION] defines different semantics 422 based on whether a search is using Basic Regular Expressions (BRE) or 423 Extended Regular Expressions (ERE). Search mechanisms that perform 424 search processing compliant with Perl Compatible Regular Expressions 425 (PCRE) as defined by pcre.org [PCRE] and in Perl 5 [PERLRE] may also 426 produce matches that differ from matches produced by POSIX compatible 427 regular expression matching. Differences in regular expression 428 matching between POSIX BRE, POSIX ERE and PCRE are illustrated in the 429 examples below, where the "sed" command without the "-E" option is 430 used for POSIX BRE matching, the "sed" command with the "-E" option 431 is used for POSIX ERE matching, and the "perl" command is used for 432 PCRE matching. 434 $ echo 'abcdef' | sed 's/ab(cd)?(cdef)?/[xxxx]/' 435 abcdef 436 $ echo 'abcdef' | sed -E 's/ab(cd)?(cdef)?/[xxxx]/' 437 [xxxx] 438 $ echo 'abcdef' | perl -p -e 's/ab(cd)?(cdef)?/[xxxx]/' 439 [xxxx]ef 441 $ echo 'aaa' | sed 's/a\{3,\}/[xxxx]/' 442 [xxxx] 443 $ echo 'aaa' | sed 's/a{3,}/[xxxx]/' 444 aaa 445 $ echo 'aaa' | sed -E 's/a\{3,\}/[xxxx]/' 446 aaa 447 $ echo 'aaa' | sed -E 's/a{3,}/[xxxx]/' 448 [xxxx] 449 $ echo 'aaa' | perl -p -e 's/a\{3,\}/[xxxx]/' 450 aaa 451 $ echo 'aaa' | perl -p -e 's/a{3,}/[xxxx]/' 452 [xxxx] 454 Use of POSIX extended regular expressions is motivated by broad 455 support in the form of API availability [GNU] and database support, 456 with the following major databases supporting POSIX extended regular 457 expressions: 459 Oracle [ORACLE] 460 MySQL [MYSQL] 461 Postgres [POSTGRES] 463 7. IANA Considerations 465 FOR DISCUSSION: The URL query parameter "searchtype" with a value of 466 "regex" is specified here-in as syntax for specifying that the RDAP 467 query search pattern is a POSIX extended regular expression. The 468 same approach could be used for specifying future OPTIONAL RDAP 469 search mechanisms. An IANA-maintained registry of RDAP search 470 mechanisms is recommended for recording a list of allowable values 471 for the "searchtype" query parameter. 473 8. Implementation Status 475 Note to RFC Editor: Please remove this entire section before 476 publication along with the reference to RFC7942 [RFC7942]. 478 This section records the status of known implementations of the 479 protocol defined by this specification at the time of posting of this 480 Internet-Draft, and is based on a proposal described in RFC 7942. 481 The description of implementations in this section is intended to 482 assist the IETF in its decision processes in progressing drafts to 483 RFCs. Please note that the listing of any individual implementation 484 here does not imply endorsement by the IETF. Furthermore, no effort 485 has been spent to verify the information presented here that was 486 supplied by IETF contributors. This is not intended as, and must not 487 be construed to be, a catalog of available implementations or their 488 features. Readers are advised to note that other implementations may 489 exist. 491 According to RFC 7942, "this will allow reviewers and working groups 492 to assign due consideration to documents that have the benefit of 493 running code, which may serve as evidence of valuable experimentation 494 and feedback that have made the implemented protocols more mature. 495 It is up to the individual working groups to use this information as 496 they see fit". 498 8.1. Verisign Labs 500 Responsible Organization: Verisign Labs 501 Location: https://rdap.verisignlabs.com/ 502 Description: This implementation includes support for POSIX 503 extended regular expression domain registry RDAP queries using 504 live data from the .cc and .tv country code top-level domains. 505 This implementation also supports federated authentication using 506 OpenID Connect providers as described in [RDAPOPENID]. Three 507 access levels are provided based on the authenticated identity of 508 the client: 510 1. Unauthenticated: Limited information is returned in response 511 to queries from unauthenticated clients. 512 2. Basic: Clients who authenticate using a publicly available 513 identity provider like Google Gmail or Microsoft Hotmail will 514 receive all of the information available to an unauthenticated 515 client plus additional registration metadata, but no 516 personally identifiable information associated with entities. 517 3. Advanced: Clients who authenticate using a more restrictive 518 identity provider will receive all of the information 519 available to a Basic client plus whatever information the 520 server operator deems appropriate for a fully authorized 521 client. Currently supported identity providers include those 522 developed by Verisign Labs 523 (https://testprovider.rdap.verisignlabs.com/) and CZ.NIC 524 (https://www.mojeid.cz/). 525 Level of Maturity: This is a "proof of concept" research 526 implementation. 527 Coverage: This implementation includes all of the features 528 described in this specification. 529 Contact Information: Swapneel Sheth, ssheth@verisign.com 531 9. Security Considerations 533 Security services for the operations specified in this document are 534 described in RFC 7481 [RFC7481]. 536 Search functionality typically requires more server resources (such 537 as memory, CPU cycles, and network bandwidth) when compared to basic 538 lookup functionality. This increases the risk of server resource 539 exhaustion and subsequent denial of service due to abuse. This risk 540 can be mitigated by developing and implementing controls to restrict 541 search functionality to identified and authorized clients. If those 542 clients behave badly, their search privileges can be suspended or 543 revoked. Rate limiting as described in Section 5.5 of RFC 7480 544 [RFC7480] can also be used to control the rate of received search 545 requests. Server operators can also reduce their risk by restricting 546 the amount of information returned in response to a search request. 548 Search functionality also increases the privacy risk of disclosing 549 object relationships that might not otherwise be obvious. For 550 example, a search that returns IDN variants [RFC6927] that do not 551 explicitly match a client-provided search pattern can disclose 552 information about registered domain names that might not be otherwise 553 available. Implementers need to consider the policy and privacy 554 implications of returning information that was not explicitly 555 requested. 557 Note that there might not be a single, static information return 558 policy that applies to all clients equally. Client identity and 559 associated authorizations can be a relevant factor in determining how 560 broad the response set will be for any particular query. 562 10. Acknowledgements 564 The author would like to acknowledge the following individuals for 565 their contributions to the development of this document: TBD. 567 11. References 569 11.1. Normative References 571 [IEEE.1003.1_2013_EDITION] 572 IEEE, "Standard for Information TechnologyPortable 573 Operating System Interface (POSIX(R)) Base Specifications, 574 Issue 7", IEEE 1003.1, 2013 Edition, 575 DOI 10.1109/ieeestd.2013.6506091, April 2013, 576 . 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, 581 DOI 10.17487/RFC2119, March 1997, 582 . 584 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 585 Resource Identifier (URI): Generic Syntax", STD 66, 586 RFC 3986, DOI 10.17487/RFC3986, January 2005, 587 . 589 [RFC5890] Klensin, J., "Internationalized Domain Names for 590 Applications (IDNA): Definitions and Document Framework", 591 RFC 5890, DOI 10.17487/RFC5890, August 2010, 592 . 594 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 595 Address Text Representation", RFC 5952, 596 DOI 10.17487/RFC5952, August 2010, 597 . 599 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 600 Protocol (HTTP/1.1): Message Syntax and Routing", 601 RFC 7230, DOI 10.17487/RFC7230, June 2014, 602 . 604 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 605 Registration Data Access Protocol (RDAP)", RFC 7480, 606 DOI 10.17487/RFC7480, March 2015, 607 . 609 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 610 Registration Data Access Protocol (RDAP)", RFC 7481, 611 DOI 10.17487/RFC7481, March 2015, 612 . 614 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 615 Protocol (RDAP) Query Format", RFC 7482, 616 DOI 10.17487/RFC7482, March 2015, 617 . 619 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 620 Registration Data Access Protocol (RDAP)", RFC 7483, 621 DOI 10.17487/RFC7483, March 2015, 622 . 624 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 625 Code: The Implementation Status Section", BCP 205, 626 RFC 7942, DOI 10.17487/RFC7942, July 2016, 627 . 629 11.2. Informative References 631 [GNU] gnu.org, "GNU Regular Expression Matching", 632 . 635 [MYSQL] mysql.com, "MySQL Regular Expressions", 636 . 638 [ORACLE] Oracle Corporation, "Oracle SQL and POSIX Regular 639 Expression Standard", 640 . 643 [PCRE] pcre.org, "Perl Compatible Regular Expressions", 644 . 646 [PERLRE] perl.org, "Perl regular expressions", 647 . 649 [POSTGRES] 650 postgresql.org, "PostgreSQL POSIX Regular Expressions", 651 . 654 [RDAPOPENID] 655 ietf.org, "Federated Authentication for the Registration 656 Data Access Protocol (RDAP) using OpenID Connect", 657 . 660 [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet 661 numbers", RFC 1166, DOI 10.17487/RFC1166, July 1990, 662 . 664 [RFC6927] Levine, J. and P. Hoffman, "Variants in Second-Level Names 665 Registered in Top-Level Domains", RFC 6927, 666 DOI 10.17487/RFC6927, May 2013, 667 . 669 Appendix A. Change Log 671 00: Initial version. 672 01: Renewed and moved invalid Normative References to Informative 673 References 674 02: Specified use of percent encoding for reserved URL reserved 675 characters in regulard expressions and removed specifcation for 676 base64url encoding for regular expressions 678 Authors' Addresses 680 Andrew Fregly 681 Verisign Labs 682 12061 Bluemont Way 683 Reston, VA 20190 684 USA 686 Email: afregly@verisign.com 687 URI: http://www.verisignlabs.com/ 689 Swapneel Sheth 690 Verisign Labs 691 12061 Bluemont Way 692 Reston, VA 20190 693 USA 695 Email: ssheth@verisign.com 696 URI: http://www.verisignlabs.com/ 698 Scott Hollenbeck 699 Verisign Labs 700 12061 Bluemont Way 701 Reston, VA 20190 702 USA 704 Email: shollenbeck@verisign.com 705 URI: http://www.verisignlabs.com/