idnits 2.17.1 draft-fregly-regext-rdap-search-regex-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 (October 31, 2016) is 2732 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) ** Downref: Normative reference to an Informational RFC: RFC 1166 ** Downref: Normative reference to an Informational RFC: RFC 6927 ** 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: 5 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: May 4, 2017 Verisign Labs 6 October 31, 2016 8 Registration Data Access Protocol (RDAP) Search Using POSIX Regular 9 Expressions 10 draft-fregly-regext-rdap-search-regex-00 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 May 4, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . 10 66 8.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 11 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 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. Search patterns MUST be base64url encoded. 107 base64url encoding MUST be as described in section 5 of RFC 4648 108 [RFC4648]. base64url encoding will eliminate errors that might occur 109 due to inconsistent encoding and decoding semantics for certain 110 characters. For instance, the space character may be encoded as "+" 111 when submitted through a HTML form and encoded as "%20" when 112 submitted through the address bar of a Web browser. Detailed results 113 can be retrieved using the HTTP GET method and the path segments 114 specified here. 116 This document defines an RDAP query parameter, "searchtype", that is 117 used to identify search requests that require specialized processing 118 beyond the limited functionality described in RFC 7482 [RFC7482]. 119 Search processing using POSIX [IEEE.1003.1_2013_EDITION] extended 120 regular expressions is indicated with a query string parameter value 121 of "regex", e.g. "searchtype=regex". Other forms of search 122 processing are possible and can be described in other specifications 123 using other values for the "searchtype" query parameter. See 124 Section 2.4 for additional information. 126 2.1. Domain Search 128 Syntax: domains?name=&searchtype=regex 130 Syntax: domains?nsLdhName=&searchtype=regex 132 Syntax: domains?nsIp=&searchtype=regex 134 Searches for domain information by name are specified using this 135 form: 137 domains?name=XXXX&searchtype=regex 138 If the URL query string parameter "searchtype" has a value of 139 "regex", then XXXX MUST be a base64url encoded POSIX extended regular 140 expression. base64url encoding MUST be as described in section 5 of 141 RFC 4648 [RFC4648]. The supplied regular expression will be matched 142 against domains in a name space administered by the server operator. 143 Domain names are as defined by RFC 5890 [RFC5890] in "letters, 144 digits, hyphen" format. The following URL would be used to find 145 information for domain names matching the "e[a-z]ample\.com" pattern: 147 https://example.com/rdap/ 148 domains?name=ZVthLXpdYW1wbGVcLmNvbQ&searchtype=regex 150 Internationalized Domain Names (IDNs) in U-label format [RFC5890] can 151 also be matched by POSIX extended regular expression search patterns. 152 Search patterns for these names are of the form 153 /domains?name=XXXX&searchtype=regex, where XXXX is a base64url 154 encoded POSIX extended regular expression. base64url encoding MUST be 155 as described in section 5 of RFC 4648 [RFC4648]. The supplied 156 regular expression will be matched against domain names in U-label 157 format. See section 6.1 of RFC 7482 [RFC7482] for information 158 describing U-label character encoding. See Section 5 for other 159 considerations relative to regular expression matching of IDNs. 161 Searches for domain information by name server name are specified 162 using this form: 164 domains?nsLdhName=YYYY&searchtype=regex 166 If the URL query string parameter "searchtype" has a value of 167 "regex", then YYYY MUST be a base64url encoded POSIX extended regular 168 expression. base64url encoding MUST be as described in section 5 of 169 RFC 4648 [RFC4648]. The supplied regular expression will be matched 170 against host names in a name space administered by the server 171 operator. Host names are as defined by RFC 5890 [RFC5890] in 172 "letters, digits, hyphen" format. The following URL would be used to 173 search for domains delegated to name servers matching the 174 "ns[1-9]\.e[a-z]ample\.com" pattern: 176 https://example.com/rdap/ 177 domains?nsLdhName=bnNbMS05XVwuZVthLXpdYW1wbGVcLmNvbQ&searchtype=regex 179 Searches for domain information by name server IP address are 180 specified using this form: 182 domains?nsIp=ZZZZ&searchtype=regex 184 If the URL query string parameter "searchtype" has a value of 185 "regex", then ZZZZ MUST be a base64url encoded POSIX extended regular 186 expression. base64url encoding MUST be as described in section 5 of 187 RFC 4648 [RFC4648]. The supplied regular expression will be matched 188 against IPv4 addresses [RFC1166] and IPv6 addresses [RFC5952] 189 associated with specific name servers. The following URL would be 190 used to search for domains that have been delegated to name servers 191 that have IP addresses matching the "192\.0\.[1-9]\.0" pattern: 193 https://example.com/rdap/ 194 domains?nsIp=MTkyXC4wXC5bMS05XVwuMA&searchtype=regex 196 2.2. Name Server Search 198 Syntax: nameservers?name=&searchtype=regex 201 Syntax: nameservers?ip=&searchtype=regex 203 Searches for name server information by name server name are 204 specified using this form: 206 nameservers?name=XXXX&searchtype=regex 208 If the URL query string parameter "searchtype" has a value of 209 "regex", then XXXX MUST be a base64url encoded POSIX extended regular 210 expression. base64url encoding MUST be as described in section 5 of 211 RFC 4648 [RFC4648]. The supplied regular expression will be matched 212 against name server names in a name space administered by the server 213 operator. Name server names are as defined in RFC 5890 [RFC5890] in 214 "letters, digits, hyphen" format. Matches will return information 215 for the matching name servers. The following URL would be used to 216 find information for name server names matching the 217 "ns[1-9]\.e[a-z]ample\.com" pattern: 219 https://example.com/rdap/ 220 nameservers?name=bnNbMS05XVwuZVthLXpdYW1wbGVcLmNvbQ&searchtype=regex 222 Internationalized name server names in U-label format [RFC5890] can 223 also be matched by POSIX compliant regular expression search 224 patterns. Search patterns for these names are of the form 225 /nameservers?name=XXXX&searchtype=regex, where XXXX is a base64url 226 encoded POSIX extended regular expression. base64url encoding MUST be 227 as described in section 5 of RFC 4648 [RFC4648]. The supplied 228 regular expression will be matched against name server names in 229 U-label format. See section 6.1 of RFC 7482 [RFC7482] for 230 information describing U-label character encoding. See Section 5 for 231 other considerations relative to regular expression matching of 232 U-labels. 234 Searches for name server information by name server IP address are 235 specified using this form: 237 nameservers?ip=YYYY&searchtype=regex 239 If the URL query string parameter "searchtype" has a value of 240 "regex", then YYYY MUST be a base64url encoded POSIX extended regular 241 expression. base64url encoding MUST be as described in section 5 of 242 RFC 4648 [RFC4648]. The supplied regular expression will be matched 243 against IPv4 addresses [RFC1166] and IPv6 addresses [RFC5952] 244 associated with specific name servers. The following URL would be 245 used to search for name server names that resolve to addresses 246 matching the "192\.0\.[1-9]\.0" pattern: 248 https://example.com/rdap/ 249 nameservers?ip=MTkyXC4wXC5bMS05XVwuMA&searchtype=regex 251 2.3. Entity Search 253 Syntax: entities?fn=&searchtype=regex 255 Syntax: entities?handle=&searchtype=regex 258 Searches for entity information by name are specified using this 259 form: 261 entities?fn=XXXX&searchtype=regex 263 If the URL query string parameter "searchtype" has a value of 264 "regex", then XXXX must be a base64url encoded POSIX extended regular 265 expression. base64url encoding MUST be as described in section 5 of 266 RFC 4648 [RFC4648]. The supplied regular expression will be matched 267 against the "FN" property of an entity (such as a contact, 268 registrant, or registrar) name as specified in Section 5.1 of RFC 269 7483 [RFC7483]. The following URL would be used to find information 270 for entity names matching the "Bobby[[:space:]]Joe[a-z]*" pattern: 272 https://example.com/rdap/ 273 entities?fn=Qm9iYnlbWzpzcGFjZTpdXUpvZVthLXpdKg&searchtype=regex 275 Searches for entity information by handle are specified using this 276 form: 278 entities?handle=XXXX&searchtype=regex 280 If the URL query string parameter "searchtype" has a value of 281 "regex", then XXXX is evaluated as a base64url encoded POSIX extended 282 regular expression. base64url encoding MUST be as described in 283 section 5 of RFC 4648 [RFC4648]. The supplied regular expression 284 will be matched against an entity (such as a contact, registrant, or 285 registrar) identifier whose syntax is specific to the registration 286 provider. The following URL would be used to find information for 287 entity handles matching the "CID-4[0-9]*" pattern: 289 https://example.com/rdap/ 290 entities?handle=Q0lELTRbMC05XSo&searchtype=regex 292 2.4. Future Path Segments 294 OPTIONAL extensions to new RDAP path segments defined in future RDAP 295 specifications MAY be implemented to support POSIX extended regular 296 expressions search capability. The syntax for such OPTIONAL 297 extensions MUST be modeled on the syntax defined in Section 2.1, 298 Section 2.2, and Section 2.3. The following syntax template MUST be 299 followed: 301 Syntax: {path_segment}?{property}=XXXX&searchtype=regex 303 If the URL query string parameter "searchtype" has a value of 304 "regex", then XXXX must be a base64url encoded POSIX extended regular 305 expression. base64url encoding MUST be as described in section 5 of 306 RFC 4648 [RFC4648]. The supplied regular expression will be matched 307 against the property specified by {property} for the path segment 308 specified by {path_segment}. For example, if a new RDAP path segment 309 "foo" is defined and has a property "bar", the following URL would be 310 used to find information for the "foo" resource type with a "bar" 311 property matching the "widget:.*mech.*" pattern: 313 https://example.com/rdap/ 314 foo?bar=d2lkZ2V0Oi4qbWVjaC4q&searchtype=regex 316 3. Search Pattern Syntax 318 POSIX extended regular expression search pattern syntax is defined in 319 Section 9 of IEEE Std 1003.1, 2013 Edition 320 [IEEE.1003.1_2013_EDITION]. An RDAP service implementation MAY 321 implement a subset of the extended regular expression syntax and 322 capabilities defined by the specification. An RDAP service 323 implementation MUST specify the regular expression syntax and 324 capabilities it supports in response to a query to the /help path 325 segment as specified in section 3.1.6 of RFC 7482 [RFC7482]. 327 Characters within a regular expression search pattern may be URI 328 reserved characters. To avoid ambiguity in parsing a URL containing 329 a regular expression search pattern, the regular expression search 330 pattern MUST be base64url encoded as described in RFC 4648 [RFC4648]. 332 4. Query Processing 334 RDAP clients using regular expression search patterns MUST base64url 335 encode the regular expression search pattern using a method described 336 in RFC 4648 [RFC4648]. The regular expression SHOULD be consistent 337 with the regular expression syntax and capabilities supported by the 338 RDAP service implementation that is being queried in order to provide 339 predictable results. The use of a regular expression that is not 340 consistent with the capabilities of the RDAP service implementation 341 MUST result in the return of an HTTP 400 response code as described 342 in section 5.4 of RFC 7480 [RFC7480]. 344 An RDAP service implementation will receive regular expressions 345 search patterns that are base64url encoded. Prior to processing a 346 regular expression, the RDAP service MUST decode the received 347 base64url encoded regular expression search pattern using a method 348 described in RFC 4648 [RFC4648]. After decoding the received regular 349 expression, the regular expression MUST be matched as described in 350 Section 2.1, Section 2.2 and Section 2.3. Matching records related 351 to the search are then returned in the client. 353 The POSIX regular expression specification [IEEE.1003.1_2013_EDITION] 354 allows implementations to provide case insensitive searching. RDAP 355 service implementations SHOULD implement case insensitive searching 356 as described in the specification. This will allow for consistency 357 in search results regardless of the case of the RDAP data being 358 searched. For example, some RDAP service implementations may 359 represent domain names in upper case during searching while other 360 RDAP service implementations may represent domain names in lower case 361 or mixed case during searching. Case insensitive searching will 362 alleviate the need for search clients to know how each RDAP service 363 implementation represents the case of searchable data. RDAP service 364 implementations that do not perform case insensitive searching may 365 produce unexpected search results for entities that are not aware of 366 how the service represents the case of searchable data. 368 An RDAP service implementation MUST specify its support or lack of 369 support for case insensitive searching in response to a query to the 370 /help path segment as specified in section 3.1.6 of RFC 7482 371 [RFC7482]. 373 Servers indicate the success or failure of query processing of a 374 regular expression search pattern by returning an appropriate HTTP 375 response code to the client. Response codes not specifically 376 identified in this document are described in RFC 7480 [RFC7480]. 378 5. Internationalization Considerations 380 An RDAP service implementation that supports regular expression 381 search patterns MUST support pattern construction and pattern 382 matching using UTF-8 encoded character strings. Other character 383 encoding considerations are described in section 6.1 of RFC 7482 384 [RFC7482]. 386 6. Implementation Considerations 388 The set of related records that may be returned in response to a 389 search with a regular expression search pattern are subject to the 390 constraints specified in section 4.2 of RFC 7482 [RFC7482]. 392 An RDAP service implementation MAY choose to limit the scope of 393 searches to RDAP data that is managed by the RDAP service 394 implementation. For example, an RDAP response to a query that could 395 be matched against multiple TLDs or data in related RDAP repositories 396 (such as those distributed between domain registry and domain 397 registrar) need only return matches for the data managed by the RDAP 398 service implementation. 400 Regular expression matching results for some search patterns may vary 401 based on the regular expression search engine used, the version of 402 the engine used, and configuration of the search engine. For 403 example, POSIX [IEEE.1003.1_2013_EDITION] defines different semantics 404 based on whether a search is using Basic Regular Expressions (BRE) or 405 Extended Regular Expressions (ERE). Search mechanisms that perform 406 search processing compliant with Perl Compatible Regular Expressions 407 (PCRE) as defined by pcre.org [PCRE] and in Perl 5 [PERLRE] may also 408 produce matches that differ from matches produced by POSIX compatible 409 regular expression matching. Differences in regular expression 410 matching between POSIX BRE, POSIX ERE and PCRE are illustrated in the 411 examples below, where the "sed" command without the "-E" option is 412 used for POSIX BRE matching, the "sed" command with the "-E" option 413 is used for POSIX ERE matching, and the "perl" command is used for 414 PCRE matching. 416 $ echo 'abcdef' | sed 's/ab(cd)?(cdef)?/[xxxx]/' 417 abcdef 418 $ echo 'abcdef' | sed -E 's/ab(cd)?(cdef)?/[xxxx]/' 419 [xxxx] 420 $ echo 'abcdef' | perl -p -e 's/ab(cd)?(cdef)?/[xxxx]/' 421 [xxxx]ef 423 $ echo 'aaa' | sed 's/a\{3,\}/[xxxx]/' 424 [xxxx] 425 $ echo 'aaa' | sed 's/a{3,}/[xxxx]/' 426 aaa 427 $ echo 'aaa' | sed -E 's/a\{3,\}/[xxxx]/' 428 aaa 429 $ echo 'aaa' | sed -E 's/a{3,}/[xxxx]/' 430 [xxxx] 431 $ echo 'aaa' | perl -p -e 's/a\{3,\}/[xxxx]/' 432 aaa 433 $ echo 'aaa' | perl -p -e 's/a{3,}/[xxxx]/' 434 [xxxx] 436 Use of POSIX extended regular expressions is motivated by broad 437 support in the form of API availability [GNU] and database support, 438 with the following major databases supporting POSIX extended regular 439 expressions: 441 Oracle [ORACLE] 442 MySQL [MYSQL] 443 Postgres [POSTGRES] 445 7. IANA Considerations 447 FOR DISCUSSION: The URL query parameter "searchtype" with a value of 448 "regex" is specified here-in as syntax for specifying that the RDAP 449 query search pattern is a POSIX regular expression. The same 450 approach could be used for specifying future OPTIONAL RDAP search 451 mechanisms. An IANA-maintained registry of RDAP search mechanisms is 452 recommended for recording a list of allowable values for the 453 "searchtype" query parameter. 455 8. Implementation Status 457 Note to RFC Editor: Please remove this entire section before 458 publication along with the reference to RFC7942 [RFC7942]. 460 This section records the status of known implementations of the 461 protocol defined by this specification at the time of posting of this 462 Internet-Draft, and is based on a proposal described in RFC 7942. 464 The description of implementations in this section is intended to 465 assist the IETF in its decision processes in progressing drafts to 466 RFCs. Please note that the listing of any individual implementation 467 here does not imply endorsement by the IETF. Furthermore, no effort 468 has been spent to verify the information presented here that was 469 supplied by IETF contributors. This is not intended as, and must not 470 be construed to be, a catalog of available implementations or their 471 features. Readers are advised to note that other implementations may 472 exist. 474 According to RFC 7942, "this will allow reviewers and working groups 475 to assign due consideration to documents that have the benefit of 476 running code, which may serve as evidence of valuable experimentation 477 and feedback that have made the implemented protocols more mature. 478 It is up to the individual working groups to use this information as 479 they see fit". 481 8.1. Verisign Labs 483 Responsible Organization: Verisign Labs 484 Location: https://rdap.verisignlabs.com/ 485 Description: This implementation includes support for POSIX 486 extended regular expression domain registry RDAP queries using 487 live data from the .cc and .tv country code top-level domains. 488 This implementation also supports federated authentication using 489 OpenID Connect providers as described in [RDAPOPENID]. Three 490 access levels are provided based on the authenticated identity of 491 the client: 493 1. Unauthenticated: Limited information is returned in response 494 to queries from unauthenticated clients. 495 2. Basic: Clients who authenticate using a publicly available 496 identity provider like Google Gmail or Microsoft Hotmail will 497 receive all of the information available to an unauthenticated 498 client plus additional registration metadata, but no 499 personally identifiable information associated with entities. 500 3. Advanced: Clients who authenticate using a more restrictive 501 identity provider will receive all of the information 502 available to a Basic client plus whatever information the 503 server operator deems appropriate for a fully authorized 504 client. Currently supported identity providers include those 505 developed by Verisign Labs 506 (https://testprovider.rdap.verisignlabs.com/) and CZ.NIC 507 (https://www.mojeid.cz/). 508 Level of Maturity: This is a "proof of concept" research 509 implementation. 510 Coverage: This implementation includes all of the features 511 described in this specification. 513 Contact Information: Swapneel Sheth, ssheth@verisign.com 515 9. Security Considerations 517 Security services for the operations specified in this document are 518 described in RFC 7481 [RFC7481]. 520 Search functionality typically requires more server resources (such 521 as memory, CPU cycles, and network bandwidth) when compared to basic 522 lookup functionality. This increases the risk of server resource 523 exhaustion and subsequent denial of service due to abuse. This risk 524 can be mitigated by developing and implementing controls to restrict 525 search functionality to identified and authorized clients. If those 526 clients behave badly, their search privileges can be suspended or 527 revoked. Rate limiting as described in Section 5.5 of RFC 7480 528 [RFC7480] can also be used to control the rate of received search 529 requests. Server operators can also reduce their risk by restricting 530 the amount of information returned in response to a search request. 532 Search functionality also increases the privacy risk of disclosing 533 object relationships that might not otherwise be obvious. For 534 example, a search that returns IDN variants [RFC6927] that do not 535 explicitly match a client-provided search pattern can disclose 536 information about registered domain names that might not be otherwise 537 available. Implementers need to consider the policy and privacy 538 implications of returning information that was not explicitly 539 requested. 541 Note that there might not be a single, static information return 542 policy that applies to all clients equally. Client identity and 543 associated authorizations can be a relevant factor in determining how 544 broad the response set will be for any particular query. 546 10. Acknowledgements 548 The author would like to acknowledge the following individuals for 549 their contributions to the development of this document: TBD. 551 11. References 553 11.1. Normative References 555 [IEEE.1003.1_2013_EDITION] 556 IEEE, "Standard for Information TechnologyPortable 557 Operating System Interface (POSIX(R)) Base Specifications, 558 Issue 7", IEEE 1003.1, 2013 Edition, 559 DOI 10.1109/ieeestd.2013.6506091, April 2013, 560 . 563 [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet 564 numbers", RFC 1166, DOI 10.17487/RFC1166, July 1990, 565 . 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, 569 DOI 10.17487/RFC2119, March 1997, 570 . 572 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 573 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 574 . 576 [RFC5890] Klensin, J., "Internationalized Domain Names for 577 Applications (IDNA): Definitions and Document Framework", 578 RFC 5890, DOI 10.17487/RFC5890, August 2010, 579 . 581 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 582 Address Text Representation", RFC 5952, 583 DOI 10.17487/RFC5952, August 2010, 584 . 586 [RFC6927] Levine, J. and P. Hoffman, "Variants in Second-Level Names 587 Registered in Top-Level Domains", RFC 6927, 588 DOI 10.17487/RFC6927, May 2013, 589 . 591 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 592 Protocol (HTTP/1.1): Message Syntax and Routing", 593 RFC 7230, DOI 10.17487/RFC7230, June 2014, 594 . 596 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 597 Registration Data Access Protocol (RDAP)", RFC 7480, 598 DOI 10.17487/RFC7480, March 2015, 599 . 601 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 602 Registration Data Access Protocol (RDAP)", RFC 7481, 603 DOI 10.17487/RFC7481, March 2015, 604 . 606 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 607 Protocol (RDAP) Query Format", RFC 7482, 608 DOI 10.17487/RFC7482, March 2015, 609 . 611 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 612 Registration Data Access Protocol (RDAP)", RFC 7483, 613 DOI 10.17487/RFC7483, March 2015, 614 . 616 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 617 Code: The Implementation Status Section", BCP 205, 618 RFC 7942, DOI 10.17487/RFC7942, July 2016, 619 . 621 11.2. Informative References 623 [GNU] gnu.org, "GNU Regular Expression Matching", 624 . 627 [MYSQL] mysql.com, "MySQL Regular Expressions", 628 . 630 [ORACLE] Oracle Corporation, "Oracle SQL and POSIX Regular 631 Expression Standard", 632 . 635 [PCRE] pcre.org, "Perl Compatible Regular Expressions", 636 . 638 [PERLRE] perl.org, "Perl regular expressions", 639 . 641 [POSTGRES] 642 postgresql.org, "PostgreSQL POSIX Regular Expressions", 643 . 646 [RDAPOPENID] 647 ietf.org, "Federated Authentication for the Registration 648 Data Access Protocol (RDAP) using OpenID Connect", 649 . 652 Appendix A. Change Log 654 00: Initial version. 656 Authors' Addresses 658 Andrew Fregly 659 Verisign Labs 660 12061 Bluemont Way 661 Reston, VA 20190 662 USA 664 Email: afregly@verisign.com 665 URI: http://www.verisignlabs.com/ 667 Swapneel Sheth 668 Verisign Labs 669 12061 Bluemont Way 670 Reston, VA 20190 671 USA 673 Email: ssheth@verisign.com 674 URI: http://www.verisignlabs.com/ 676 Scott Hollenbeck 677 Verisign Labs 678 12061 Bluemont Way 679 Reston, VA 20190 680 USA 682 Email: shollenbeck@verisign.com 683 URI: http://www.verisignlabs.com/