idnits 2.17.1 draft-fregly-regext-rdap-search-regex-03.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 (December 3, 2017) is 2329 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) == Outdated reference: A later version (-10) exists of draft-hollenbeck-regext-rdap-openid-01 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 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: June 6, 2018 Verisign Labs 6 December 3, 2017 8 Registration Data Access Protocol (RDAP) Search Using POSIX Regular 9 Expressions 10 draft-fregly-regext-rdap-search-regex-03 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 https://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 June 6, 2018. 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 (https://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 . . . . . . . . . . . . . . . . . . . . . 11 65 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 66 8.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 12 67 8.2. APNIC RDAP Service . . . . . . . . . . . . . . . . . . . 13 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 72 11.2. Informative References . . . . . . . . . . . . . . . . . 15 73 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 The search patterns for Registration Data Access Protocol (RDAP) 79 search as described in RFC 7482 [RFC7482] are limited. The protocol 80 described in this specification extends RDAP search capabilities by 81 adding path segments for RDAP search functions using a RESTful web 82 service and POSIX [IEEE.1003.1_2013_EDITION] extended regular 83 expressions. The service is implemented using the Hypertext Transfer 84 Protocol (HTTP) [RFC7230] and the conventions described in RFC 7480 85 [RFC7480]. 87 1.1. Conventions Used in This Document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 2. RDAP Path Segment Specification 95 The path segments defined in this section are OPTIONAL extensions of 96 path segments defined in RFC 7482 [RFC7482]. The resource type path 97 segments for search are: 99 o 'domains': Used to identify a domain name information search using 100 a pattern to match a fully-qualified domain name. 101 o 'nameservers': Used to identify a name server information search 102 using a pattern to match a host name. 103 o 'entities': Used to identify an entity information search using a 104 pattern to match a string identifier. 106 The search patterns in the path segments MUST be POSIX extended 107 regular expressions. Non-URL-safe characters in Search patterns MUST 108 be percent-encoded. Percent-encoding MUST be as described in section 109 2.1 of RFC 3986 [RFC3986]. Percent-encoding will eliminate errors 110 that might occur due to web-servier or app-server interpretation of 111 certain unsafe characters and will eliminate errors due to 112 inconsistent encoding and decoding semantics for certain characters. 113 For instance, the space character may be encoded as "+" when 114 submitted through a HTML form and encoded as "%20" when submitted 115 through the address bar of a Web browser. Detailed results can be 116 retrieved using the HTTP GET method and the path segments specified 117 here. 119 This document defines an RDAP query parameter, "searchtype", that is 120 used to identify search requests that require specialized processing 121 beyond the limited functionality described in RFC 7482 [RFC7482]. 122 Search processing using POSIX [IEEE.1003.1_2013_EDITION] extended 123 regular expressions is indicated with a query string parameter value 124 of "regex", e.g. "searchtype=regex". Other forms of search 125 processing are possible and can be described in other specifications 126 using other values for the "searchtype" query parameter. See 127 Section 2.4 for additional information. 129 2.1. Domain Search 131 Syntax: domains?name=&searchtype=regex 133 Syntax: domains?nsLdhName=&searchtype=regex 135 Syntax: domains?nsIp=&searchtype=regex 137 Searches for domain information by name are specified using this 138 form: 140 domains?name=XXXX&searchtype=regex 141 If the URL query string parameter "searchtype" has a value of 142 "regex", then XXXX MUST be a POSIX extended regular expression. Non- 143 URL-safe characters in XXXX MUST be percent-encoded. Percent- 144 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 145 The supplied regular expression will be matched against domains in a 146 name space administered by the server operator. Domain names are as 147 defined by RFC 5890 [RFC5890] in "letters, digits, hyphen" format. 148 The following URL would be used to find information for domain names 149 matching the "e[a-z]ample\.com" pattern: 151 https://example.com/rdap/domains?name=e%5Ba- 152 z%5Dample%5C.com&searchtype=regex 154 Internationalized Domain Names (IDNs) in U-label format [RFC5890] can 155 also be matched by POSIX extended regular expression search patterns. 156 Search patterns for these names are of the form 157 /domains?name=XXXX&searchtype=regex, where XXXX is a POSIX extended 158 regular expression. Non-URL-safe characters in XXXX MUST be percent- 159 encoded. Percent-encoding MUST be as described in section 2.1 of RFC 160 3986 [RFC3986]. The supplied regular expression will be matched 161 against domain names in U-label format. See section 6.1 of RFC 7482 162 [RFC7482] for information describing U-label character encoding. See 163 Section 5 for other considerations relative to regular expression 164 matching of IDNs. 166 Searches for domain information by name server name are specified 167 using this form: 169 domains?nsLdhName=YYYY&searchtype=regex 171 If the URL query string parameter "searchtype" has a value of 172 "regex", then YYYY MUST be a POSIX extended regular expression. Non- 173 URL-safe characters in YYYY MUST be percent-encoded. Percent- 174 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 175 The supplied regular expression will be matched against host names in 176 a name space administered by the server operator. Host names are as 177 defined by RFC 5890 [RFC5890] in "letters, digits, hyphen" format. 178 The following URL would be used to search for domains delegated to 179 name servers matching the "ns[1-9]\.e[a-z]ample\.com" pattern: 181 https://example.com/rdap/domains?nsLdhName=ns%5B1-9%5D%5C.e%5Ba- 182 z%5Dample%5C.com&searchtype=regex 184 Searches for domain information by name server IP address are 185 specified using this form: 187 domains?nsIp=ZZZZ&searchtype=regex 188 If the URL query string parameter "searchtype" has a value of 189 "regex", then ZZZZ MUST be a POSIX extended regular expression. Non- 190 URL-safe characters in ZZZZ MUST be percent-encoded. Percent- 191 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 192 The supplied regular expression will be matched against IPv4 193 addresses [RFC1166] and IPv6 addresses [RFC5952] associated with 194 specific name servers. The following URL would be used to search for 195 domains that have been delegated to name servers that have IP 196 addresses matching the "192\.0\.[1-9]\.0" pattern: 198 https://example.com/rdap/ 199 domains?nsIp=192%5C.0%5C.%5B1-9%5D%5C.0&searchtype=regex 201 2.2. Name Server Search 203 Syntax: nameservers?name=&searchtype=regex 206 Syntax: nameservers?ip=&searchtype=regex 208 Searches for name server information by name server name are 209 specified using this form: 211 nameservers?name=XXXX&searchtype=regex 213 If the URL query string parameter "searchtype" has a value of 214 "regex", then XXXX MUST be a POSIX extended regular expression. Non- 215 URL-safe characters in XXXX MUST be percent-encoded. Percent- 216 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 217 The supplied regular expression will be matched against name server 218 names in a name space administered by the server operator. Name 219 server names are as defined in RFC 5890 [RFC5890] in "letters, 220 digits, hyphen" format. Matches will return information for the 221 matching name servers. The following URL would be used to find 222 information for name server names matching the 223 "ns[1-9]\.e[a-z]ample\.com" pattern: 225 https://example.com/rdap/nameservers?name=ns%5B1-9%5D%5C.e%5Ba- 226 z%5Dample%5C.com&searchtype=regex 228 Internationalized name server names in U-label format [RFC5890] can 229 also be matched by POSIX extended regular expression search patterns. 230 Search patterns for these names are of the form 231 /nameservers?name=XXXX&searchtype=regex, where XXXX is a POSIX 232 extended regular expression. Non-URL-safe characters in XXXX MUST be 233 percent-encoded. Percent-encoding MUST be as described in section 234 2.1 of RFC 3986 [RFC3986]. The supplied regular expression will be 235 matched against name server names in U-label format. See section 6.1 236 of RFC 7482 [RFC7482] for information describing U-label character 237 encoding. See Section 5 for other considerations relative to regular 238 expression matching of U-labels. 240 Searches for name server information by name server IP address are 241 specified using this form: 243 nameservers?ip=YYYY&searchtype=regex 245 If the URL query string parameter "searchtype" has a value of 246 "regex", then YYYY MUST be a POSIX extended regular expression. Non- 247 URL-safe characters in YYYY MUST be percent-encoded. Percent- 248 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 249 The supplied regular expression will be matched against IPv4 250 addresses [RFC1166] and IPv6 addresses [RFC5952] associated with 251 specific name servers. The following URL would be used to search for 252 name server names that resolve to addresses matching the 253 "192\.0\.[1-9]\.0" pattern: 255 https://example.com/rdap/ 256 nameservers?ip=192%5C.0%5C.%5B1-9%5D%5C.0&searchtype=regex 258 2.3. Entity Search 260 Syntax: entities?fn=&searchtype=regex 262 Syntax: entities?handle=&searchtype=regex 265 Searches for entity information by name are specified using this 266 form: 268 entities?fn=XXXX&searchtype=regex 270 If the URL query string parameter "searchtype" has a value of 271 "regex", then XXXX MUST be a POSIX extended regular expression. Non- 272 URL-safe characters in XXXX MUST be percent-encoded. Percent- 273 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 274 The supplied regular expression will be matched against the "FN" 275 property of an entity (such as a contact, registrant, or registrar) 276 name as specified in Section 5.1 of RFC 7483 [RFC7483]. The 277 following URL would be used to find information for entity names 278 matching the "Bobby[[:space:]]Joe[a-z]*" pattern: 280 https://example.com/rdap/ 281 entities?fn=Bobby%5B%5B%3Aspace%3A%5D%5DJoe%5Ba- 282 z%5D%2A&searchtype=regex 283 Searches for entity information by handle are specified using this 284 form: 286 entities?handle=XXXX&searchtype=regex 288 If the URL query string parameter "searchtype" has a value of 289 "regex", then XXXX MUST be a POSIX extended regular expression. Non- 290 URL-safe characters in XXXX MUST be percent-encoded. Percent- 291 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 292 The supplied regular expression will be matched against an entity 293 (such as a contact, registrant, or registrar) identifier whose syntax 294 is specific to the registration provider. The following URL would be 295 used to find information for entity handles matching the "CID- 296 4[0-9]*" pattern: 298 https://example.com/rdap/entities?handle=CID- 299 4%5B0-9%5D%2A&searchtype=regex 301 2.4. Future Path Segments 303 OPTIONAL extensions to new RDAP path segments defined in future RDAP 304 specifications MAY be implemented to support POSIX extended regular 305 expressions search capability. The syntax for such OPTIONAL 306 extensions MUST be modeled on the syntax defined in Section 2.1, 307 Section 2.2, and Section 2.3. The following syntax template MUST be 308 followed: 310 Syntax: {path_segment}?{property}=XXXX&searchtype=regex 312 If the URL query string parameter "searchtype" has a value of 313 "regex", then XXXX MUST be a POSIX extended regular expression. Non- 314 URL-safe characters in XXXX MUST be percent-encoded. Percent- 315 encoding MUST be as described in section 2.1 of RFC 3986 [RFC3986]. 316 The supplied regular expression will be matched against the property 317 specified by {property} for the path segment specified by 318 {path_segment}. For example, if a new RDAP path segment "foo" is 319 defined and has a property "bar", the following URL would be used to 320 find information for the "foo" resource type with a "bar" property 321 matching the "widget:.*mech.*" pattern: 323 https://example.com/rdap/ 324 foo?bar=widget%3A.%2Amech.%2A&searchtype=regex 326 3. Search Pattern Syntax 328 POSIX extended regular expression search pattern syntax is defined in 329 Section 9 of IEEE Std 1003.1, 2013 Edition 330 [IEEE.1003.1_2013_EDITION]. An RDAP service implementation MAY 331 implement a subset of the extended regular expression syntax and 332 capabilities defined by the specification. An RDAP service 333 implementation MUST specify the regular expression syntax and 334 capabilities it supports in response to a query to the /help path 335 segment as specified in section 3.1.6 of RFC 7482 [RFC7482]. 337 Characters within a regular expression search pattern may be URI 338 reserved characters. To avoid ambiguity in parsing a URL containing 339 a regular expression search pattern, non-URL-safe character in the 340 regular expression search pattern MUST be percent-encoded as 341 described in RFC 3986 [RFC3986]. 343 4. Query Processing 345 RDAP clients using regular expression search patterns MUST percent- 346 encode non-URL-safe characters in the regular expression search 347 pattern as described in RFC 3986 [RFC3986]. The regular expression 348 SHOULD be consistent with the regular expression syntax and 349 capabilities supported by the RDAP service implementation that is 350 being queried in order to provide predictable results. The use of a 351 regular expression that is not consistent with the capabilities of 352 the RDAP service implementation MUST result in the return of an HTTP 353 400 response code as described in section 5.4 of RFC 7480 [RFC7480]. 355 An RDAP service implementation will receive regular expressions 356 search patterns that contain percent-encoded characters. Prior to 357 processing a regular expression, the RDAP service MUST decode the 358 received percent-encoded characters in regular expressions as 359 described in RFC 3986 [RFC3986]. After decoding the received regular 360 expression, the regular expression MUST be matched as described in 361 Section 2.1, Section 2.2 and Section 2.3. Matching records related 362 to the search are then returned in the client. 364 Server operating systems are typically configured to use a collection 365 of regional and language rules that describe default processing 366 conventions, such as sort order, date format, etc., as part of a 367 "locale" setting. The regular expression library used for an RDAP 368 service implementation will typically acquire all the information it 369 requires for the current locale from the underlying operating system. 370 The locale used by a regular expression library may impact the 371 results of regular expression searches based on locale-specific 372 processing.For example, a POSIX locale can have collating sequences 373 to describe how certain characters or groups of characters can be 374 ordered. In the Czech language, for example, "ch" can be treated as 375 if it were one character. You can use the collating sequence element 376 [.ch.] inside a bracketed expression to match "ch" when the Czech 377 locale (cs-CZ) is active, but a similar collating sequence would not 378 match the string if the system locale was, for example, en_US. Users 379 submitting regular expression searches that do not take into account 380 locale-specific processing may receive misleading or inaccurate 381 results. As such, it is RECOMMENDED to identify the underlying 382 locale in the "help" path segment as specified in section 3.1.6 of 383 RFC 7482 [RFC7482]. This will help RDAP clients construct regular 384 expressions that can be processed in a predictable way. 386 The POSIX regular expression specification [IEEE.1003.1_2013_EDITION] 387 allows implementations to provide case insensitive searching. RDAP 388 service implementations SHOULD implement case insensitive searching 389 as described in the specification. This will allow for consistency 390 in search results regardless of the case of the RDAP data being 391 searched. For example, some RDAP service implementations may 392 represent domain names in upper case during searching while other 393 RDAP service implementations may represent domain names in lower case 394 or mixed case during searching. Case insensitive searching will 395 alleviate the need for search clients to know how each RDAP service 396 implementation represents the case of searchable data. RDAP service 397 implementations that do not perform case insensitive searching may 398 produce unexpected search results for entities that are not aware of 399 how the service represents the case of searchable data. 401 An RDAP service implementation MUST specify its support or lack of 402 support for case insensitive searching in response to a query to the 403 /help path segment as specified in section 3.1.6 of RFC 7482 404 [RFC7482]. 406 Servers indicate the success or failure of query processing of a 407 regular expression search pattern by returning an appropriate HTTP 408 response code to the client. Response codes not specifically 409 identified in this document are described in RFC 7480 [RFC7480]. 411 5. Internationalization Considerations 413 An RDAP service implementation that supports regular expression 414 search patterns MUST support pattern construction and pattern 415 matching using UTF-8 encoded character strings. Other character 416 encoding considerations are described in section 6.1 of RFC 7482 417 [RFC7482]. 419 6. Implementation Considerations 421 The set of related records that may be returned in response to a 422 search with a regular expression search pattern are subject to the 423 constraints specified in section 4.2 of RFC 7482 [RFC7482]. 425 An RDAP service implementation MAY choose to limit the scope of 426 searches to RDAP data that is managed by the RDAP service 427 implementation. For example, an RDAP response to a query that could 428 be matched against multiple TLDs or data in related RDAP repositories 429 (such as those distributed between domain registry and domain 430 registrar) need only return matches for the data managed by the RDAP 431 service implementation. 433 Server operating systems are typically configured to use a collection 434 of regional and language rules that describe default processing 435 conventions, such as sort order, date format, etc., as part of a 436 'locale' setting. The regular expression library used for an RDAP 437 service implementation will typically acquire all the information it 438 requires for the current locale from the underlying operating system. 439 The locale used by a regular expression library may impact the 440 results of regular expression searches based on locale-specific 441 processing. For example, a POSIX locale can have collating sequences 442 to describe how certain characters or groups of characters can be 443 ordered. In the Czech language, for example, 'ch' can be treated as 444 if it were one character. You can use the collating sequence element 445 [.ch.] inside a bracketed expression to match 'ch' when the Czech 446 locale (cs-CZ) is active, but a similar collating sequence would not 447 match the string if the system locale was, for example, en_US. Users 448 submitting regular expression searches that do not take into account 449 locale-specific processing may receive misleading or inaccurate 450 results. As such, it is RECOMMENDED to identify the underlying 451 locale in the 'help' path segment as defined in section 3.1.6 of RFC 452 7482 [RFC7482]. This will help RDAP clients construct regular 453 expressions that can be processed in a predictable way. 455 Implementators should take care to ensure that decoding of percent- 456 encoded characters in a received regular expression is only performed 457 once. Standard APIs for processing HTTP requests will likely perform 458 decoding of percent-encoded characters prior to providing a recieved 459 regular expression to the RDAP service implementation code. In such 460 case case, the RDAP service implementation code should not attempt to 461 perform decoding for percent-encoded characters. 463 Regular expression matching results for some search patterns may vary 464 based on the regular expression search engine used, the version of 465 the engine used, and configuration of the search engine. For 466 example, POSIX [IEEE.1003.1_2013_EDITION] defines different semantics 467 based on whether a search is using Basic Regular Expressions (BRE) or 468 Extended Regular Expressions (ERE). Search mechanisms that perform 469 search processing compliant with Perl Compatible Regular Expressions 470 (PCRE) as defined by pcre.org [PCRE] and in Perl 5 [PERLRE] may also 471 produce matches that differ from matches produced by POSIX compatible 472 regular expression matching. Differences in regular expression 473 matching between POSIX BRE, POSIX ERE and PCRE are illustrated in the 474 examples below, where the "sed" command without the "-E" option is 475 used for POSIX BRE matching, the "sed" command with the "-E" option 476 is used for POSIX ERE matching, and the "perl" command is used for 477 PCRE matching. 479 $ echo 'abcdef' | sed 's/ab(cd)?(cdef)?/[xxxx]/' 480 abcdef 481 $ echo 'abcdef' | sed -E 's/ab(cd)?(cdef)?/[xxxx]/' 482 [xxxx] 483 $ echo 'abcdef' | perl -p -e 's/ab(cd)?(cdef)?/[xxxx]/' 484 [xxxx]ef 486 $ echo 'aaa' | sed 's/a\{3,\}/[xxxx]/' 487 [xxxx] 488 $ echo 'aaa' | sed 's/a{3,}/[xxxx]/' 489 aaa 490 $ echo 'aaa' | sed -E 's/a\{3,\}/[xxxx]/' 491 aaa 492 $ echo 'aaa' | sed -E 's/a{3,}/[xxxx]/' 493 [xxxx] 494 $ echo 'aaa' | perl -p -e 's/a\{3,\}/[xxxx]/' 495 aaa 496 $ echo 'aaa' | perl -p -e 's/a{3,}/[xxxx]/' 497 [xxxx] 499 Use of POSIX extended regular expressions is motivated by broad 500 support in the form of API availability [GNU] and database support, 501 with the following major databases supporting POSIX extended regular 502 expressions: 504 Oracle [ORACLE] 505 MySQL [MYSQL] 506 Postgres [POSTGRES] 508 7. IANA Considerations 510 FOR DISCUSSION: The URL query parameter "searchtype" with a value of 511 "regex" is specified here-in as syntax for specifying that the RDAP 512 query search pattern is a POSIX extended regular expression. The 513 same approach could be used for specifying future OPTIONAL RDAP 514 search mechanisms. An IANA-maintained registry of RDAP search 515 mechanisms is recommended for recording a list of allowable values 516 for the "searchtype" query parameter. 518 8. Implementation Status 520 Note to RFC Editor: Please remove this entire section before 521 publication along with the reference to RFC7942 [RFC7942]. 523 This section records the status of known implementations of the 524 protocol defined by this specification at the time of posting of this 525 Internet-Draft, and is based on a proposal described in RFC 7942. 526 The description of implementations in this section is intended to 527 assist the IETF in its decision processes in progressing drafts to 528 RFCs. Please note that the listing of any individual implementation 529 here does not imply endorsement by the IETF. Furthermore, no effort 530 has been spent to verify the information presented here that was 531 supplied by IETF contributors. This is not intended as, and must not 532 be construed to be, a catalog of available implementations or their 533 features. Readers are advised to note that other implementations may 534 exist. 536 According to RFC 7942, "this will allow reviewers and working groups 537 to assign due consideration to documents that have the benefit of 538 running code, which may serve as evidence of valuable experimentation 539 and feedback that have made the implemented protocols more mature. 540 It is up to the individual working groups to use this information as 541 they see fit". 543 8.1. Verisign Labs 545 Responsible Organization: Verisign Labs 546 Location: https://rdap.verisignlabs.com/ 547 Description: This implementation includes support for POSIX 548 extended regular expression domain registry RDAP queries using 549 live data from the .cc and .tv country code top-level domains. 550 This implementation also supports federated authentication using 551 OpenID Connect providers as described in [RDAPOPENID]. Three 552 access levels are provided based on the authenticated identity of 553 the client: 555 1. Unauthenticated: Limited information is returned in response 556 to queries from unauthenticated clients. 557 2. Basic: Clients who authenticate using a publicly available 558 identity provider like Google Gmail or Microsoft Hotmail will 559 receive all of the information available to an unauthenticated 560 client plus additional registration metadata, but no 561 personally identifiable information associated with entities. 562 3. Advanced: Clients who authenticate using a more restrictive 563 identity provider will receive all of the information 564 available to a Basic client plus whatever information the 565 server operator deems appropriate for a fully authorized 566 client. Currently supported identity providers include those 567 developed by Verisign Labs 568 (https://testprovider.rdap.verisignlabs.com/) and CZ.NIC 569 (https://www.mojeid.cz/). 570 Level of Maturity: This is a "proof of concept" research 571 implementation. 572 Coverage: This implementation includes all of the features 573 described in this specification. 574 Contact Information: Swapneel Sheth, ssheth@verisign.com 576 8.2. APNIC RDAP Service 578 Responsible Organization: Asia-Pacific Network Information Centre 579 (APNIC) 580 Location: https://testrdap.apnic.net/ 581 Description: This implementation includes support for POSIX 582 extended regular expression RDAP queries for the domain and entity 583 object classes. The data source is a subset of a snapshot of the 584 production registry data. 585 Level of Maturity: This is a "proof of concept" research 586 implementation. 587 Coverage: Aside from character class expressions, collating 588 symbols, and equivalence class expressions, all of the features 589 described in this specification are implemented. 590 Contact Information: Tom Harrison, tomh@apnic.net 592 9. Security Considerations 594 Security services for the operations specified in this document are 595 described in RFC 7481 [RFC7481]. 597 Search functionality typically requires more server resources (such 598 as memory, CPU cycles, and network bandwidth) when compared to basic 599 lookup functionality. This increases the risk of server resource 600 exhaustion and subsequent denial of service due to abuse. This risk 601 can be mitigated by developing and implementing controls to restrict 602 search functionality to identified and authorized clients. If those 603 clients behave badly, their search privileges can be suspended or 604 revoked. Rate limiting as described in Section 5.5 of RFC 7480 605 [RFC7480] can also be used to control the rate of received search 606 requests. Server operators can also reduce their risk by restricting 607 the amount of information returned in response to a search request. 609 Search functionality also increases the privacy risk of disclosing 610 object relationships that might not otherwise be obvious. For 611 example, a search that returns IDN variants [RFC6927] that do not 612 explicitly match a client-provided search pattern can disclose 613 information about registered domain names that might not be otherwise 614 available. Implementers need to consider the policy and privacy 615 implications of returning information that was not explicitly 616 requested. 618 Note that there might not be a single, static information return 619 policy that applies to all clients equally. Client identity and 620 associated authorizations can be a relevant factor in determining how 621 broad the response set will be for any particular query. 623 10. Acknowledgements 625 The author would like to acknowledge the following individuals for 626 their contributions to the development of this document: TBD. 628 11. References 630 11.1. Normative References 632 [IEEE.1003.1_2013_EDITION] 633 IEEE, "Standard for Information TechnologyPortable 634 Operating System Interface (POSIX(R)) Base Specifications, 635 Issue 7", IEEE 1003.1, 2013 Edition, 636 DOI 10.1109/ieeestd.2013.6506091, April 2013, 637 . 640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC 2119, 642 DOI 10.17487/RFC2119, March 1997, 643 . 645 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 646 Resource Identifier (URI): Generic Syntax", STD 66, 647 RFC 3986, DOI 10.17487/RFC3986, January 2005, 648 . 650 [RFC5890] Klensin, J., "Internationalized Domain Names for 651 Applications (IDNA): Definitions and Document Framework", 652 RFC 5890, DOI 10.17487/RFC5890, August 2010, 653 . 655 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 656 Address Text Representation", RFC 5952, 657 DOI 10.17487/RFC5952, August 2010, 658 . 660 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 661 Protocol (HTTP/1.1): Message Syntax and Routing", 662 RFC 7230, DOI 10.17487/RFC7230, June 2014, 663 . 665 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 666 Registration Data Access Protocol (RDAP)", RFC 7480, 667 DOI 10.17487/RFC7480, March 2015, 668 . 670 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 671 Registration Data Access Protocol (RDAP)", RFC 7481, 672 DOI 10.17487/RFC7481, March 2015, 673 . 675 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 676 Protocol (RDAP) Query Format", RFC 7482, 677 DOI 10.17487/RFC7482, March 2015, 678 . 680 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 681 Registration Data Access Protocol (RDAP)", RFC 7483, 682 DOI 10.17487/RFC7483, March 2015, 683 . 685 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 686 Code: The Implementation Status Section", BCP 205, 687 RFC 7942, DOI 10.17487/RFC7942, July 2016, 688 . 690 11.2. Informative References 692 [GNU] gnu.org, "GNU Regular Expression Matching", 693 . 696 [MYSQL] mysql.com, "MySQL Regular Expressions", 697 . 699 [ORACLE] Oracle Corporation, "Oracle SQL and POSIX Regular 700 Expression Standard", 701 . 704 [PCRE] pcre.org, "Perl Compatible Regular Expressions", 705 . 707 [PERLRE] perl.org, "Perl regular expressions", 708 . 710 [POSTGRES] 711 postgresql.org, "PostgreSQL POSIX Regular Expressions", 712 . 715 [RDAPOPENID] 716 ietf.org, "Federated Authentication for the Registration 717 Data Access Protocol (RDAP) using OpenID Connect", 718 . 721 [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet 722 numbers", RFC 1166, DOI 10.17487/RFC1166, July 1990, 723 . 725 [RFC6927] Levine, J. and P. Hoffman, "Variants in Second-Level Names 726 Registered in Top-Level Domains", RFC 6927, 727 DOI 10.17487/RFC6927, May 2013, 728 . 730 Appendix A. Change Log 732 00: Initial version. 733 01: Renewed and moved invalid Normative References to Informative 734 References 735 02: Specified use of percent encoding for reserved URL reserved 736 characters in regulard expressions and removed specifcation for 737 base64url encoding for regular expressions 738 03: Added information related to implications of system locale on 739 processing regular expression search. Also, updated the 740 implementation status section with APNIC's information. 742 Authors' Addresses 744 Andrew Fregly 745 Verisign Labs 746 12061 Bluemont Way 747 Reston, VA 20190 748 USA 750 Email: afregly@verisign.com 751 URI: http://www.verisignlabs.com/ 752 Swapneel Sheth 753 Verisign Labs 754 12061 Bluemont Way 755 Reston, VA 20190 756 USA 758 Email: ssheth@verisign.com 759 URI: http://www.verisignlabs.com/ 761 Scott Hollenbeck 762 Verisign Labs 763 12061 Bluemont Way 764 Reston, VA 20190 765 USA 767 Email: shollenbeck@verisign.com 768 URI: http://www.verisignlabs.com/