Skip to main content

Registration Data Access Protocol (RDAP) Search Using POSIX Regular Expressions
draft-fregly-regext-rdap-search-regex-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Andrew Fregly , Swapneel Sheth , Scott Hollenbeck
Last updated 2016-10-31
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-fregly-regext-rdap-search-regex-00
Internet Engineering Task Force                                A. Fregly
Internet-Draft                                                  S. Sheth
Intended status: Standards Track                           S. Hollenbeck
Expires: May 4, 2017                                       Verisign Labs
                                                        October 31, 2016

  Registration Data Access Protocol (RDAP) Search Using POSIX Regular
                              Expressions
                draft-fregly-regext-rdap-search-regex-00

Abstract

   The Registration Data Access Protocol (RDAP) provides limited search
   functionality based on pattern matching.  This document describes an
   RDAP query extension that provides additional search functionality
   using POSIX extended regular expressions.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 4, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Fregly, et al.             Expires May 4, 2017                  [Page 1]
Internet-Draft           RDAP Search using Regex            October 2016

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   2
   2.  RDAP Path Segment Specification . . . . . . . . . . . . . . .   3
     2.1.  Domain Search . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Name Server Search  . . . . . . . . . . . . . . . . . . .   5
     2.3.  Entity Search . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Future Path Segments  . . . . . . . . . . . . . . . . . .   7
   3.  Search Pattern Syntax . . . . . . . . . . . . . . . . . . . .   7
   4.  Query Processing  . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Internationalization Considerations . . . . . . . . . . . . .   9
   6.  Implementation Considerations . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Verisign Labs . . . . . . . . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     11.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   The search patterns for Registration Data Access Protocol (RDAP)
   search as described in RFC 7482 [RFC7482] are limited.  The protocol
   described in this specification extends RDAP search capabilities by
   adding path segments for RDAP search functions using a RESTful web
   service and POSIX [IEEE.1003.1_2013_EDITION] extended regular
   expressions.  The service is implemented using the Hypertext Transfer
   Protocol (HTTP) [RFC7230] and the conventions described in RFC 7480
   [RFC7480].

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Fregly, et al.             Expires May 4, 2017                  [Page 2]
Internet-Draft           RDAP Search using Regex            October 2016

2.  RDAP Path Segment Specification

   The path segments defined in this section are OPTIONAL extensions of
   path segments defined in RFC 7482 [RFC7482].  The resource type path
   segments for search are:

   o  'domains': Used to identify a domain name information search using
      a pattern to match a fully-qualified domain name.
   o  'nameservers': Used to identify a name server information search
      using a pattern to match a host name.
   o  'entities': Used to identify an entity information search using a
      pattern to match a string identifier.

   The search patterns in the path segments MUST be POSIX extended
   regular expressions.  Search patterns MUST be base64url encoded.
   base64url encoding MUST be as described in section 5 of RFC 4648
   [RFC4648]. base64url encoding will eliminate errors that might occur
   due to inconsistent encoding and decoding semantics for certain
   characters.  For instance, the space character may be encoded as "+"
   when submitted through a HTML form and encoded as "%20" when
   submitted through the address bar of a Web browser.  Detailed results
   can be retrieved using the HTTP GET method and the path segments
   specified here.

   This document defines an RDAP query parameter, "searchtype", that is
   used to identify search requests that require specialized processing
   beyond the limited functionality described in RFC 7482 [RFC7482].
   Search processing using POSIX [IEEE.1003.1_2013_EDITION] extended
   regular expressions is indicated with a query string parameter value
   of "regex", e.g. "searchtype=regex".  Other forms of search
   processing are possible and can be described in other specifications
   using other values for the "searchtype" query parameter.  See
   Section 2.4 for additional information.

2.1.  Domain Search

   Syntax: domains?name=<domain search pattern>&searchtype=regex

   Syntax: domains?nsLdhName=<domain search pattern>&searchtype=regex

   Syntax: domains?nsIp=<domain search pattern>&searchtype=regex

   Searches for domain information by name are specified using this
   form:

   domains?name=XXXX&searchtype=regex

Fregly, et al.             Expires May 4, 2017                  [Page 3]
Internet-Draft           RDAP Search using Regex            October 2016

   If the URL query string parameter "searchtype" has a value of
   "regex", then XXXX MUST be a base64url encoded POSIX extended regular
   expression. base64url encoding MUST be as described in section 5 of
   RFC 4648 [RFC4648].  The supplied regular expression will be matched
   against domains in a name space administered by the server operator.
   Domain names are as defined by RFC 5890 [RFC5890] in "letters,
   digits, hyphen" format.  The following URL would be used to find
   information for domain names matching the "e[a-z]ample\.com" pattern:

   https://example.com/rdap/
   domains?name=ZVthLXpdYW1wbGVcLmNvbQ&searchtype=regex

   Internationalized Domain Names (IDNs) in U-label format [RFC5890] can
   also be matched by POSIX extended regular expression search patterns.
   Search patterns for these names are of the form
   /domains?name=XXXX&searchtype=regex, where XXXX is a base64url
   encoded POSIX extended regular expression. base64url encoding MUST be
   as described in section 5 of RFC 4648 [RFC4648].  The supplied
   regular expression will be matched against domain names in U-label
   format.  See section 6.1 of RFC 7482 [RFC7482] for information
   describing U-label character encoding.  See Section 5 for other
   considerations relative to regular expression matching of IDNs.

   Searches for domain information by name server name are specified
   using this form:

   domains?nsLdhName=YYYY&searchtype=regex

   If the URL query string parameter "searchtype" has a value of
   "regex", then YYYY MUST be a base64url encoded POSIX extended regular
   expression. base64url encoding MUST be as described in section 5 of
   RFC 4648 [RFC4648].  The supplied regular expression will be matched
   against host names in a name space administered by the server
   operator.  Host names are as defined by RFC 5890 [RFC5890] in
   "letters, digits, hyphen" format.  The following URL would be used to
   search for domains delegated to name servers matching the
   "ns[1-9]\.e[a-z]ample\.com" pattern:

   https://example.com/rdap/
   domains?nsLdhName=bnNbMS05XVwuZVthLXpdYW1wbGVcLmNvbQ&searchtype=regex

   Searches for domain information by name server IP address are
   specified using this form:

   domains?nsIp=ZZZZ&searchtype=regex

   If the URL query string parameter "searchtype" has a value of
   "regex", then ZZZZ MUST be a base64url encoded POSIX extended regular

Fregly, et al.             Expires May 4, 2017                  [Page 4]
Internet-Draft           RDAP Search using Regex            October 2016

   expression. base64url encoding MUST be as described in section 5 of
   RFC 4648 [RFC4648].  The supplied regular expression will be matched
   against IPv4 addresses [RFC1166] and IPv6 addresses [RFC5952]
   associated with specific name servers.  The following URL would be
   used to search for domains that have been delegated to name servers
   that have IP addresses matching the "192\.0\.[1-9]\.0" pattern:

   https://example.com/rdap/
   domains?nsIp=MTkyXC4wXC5bMS05XVwuMA&searchtype=regex

2.2.  Name Server Search

   Syntax: nameservers?name=<name server search
   pattern>&searchtype=regex

   Syntax: nameservers?ip=<name server search pattern>&searchtype=regex

   Searches for name server information by name server name are
   specified using this form:

   nameservers?name=XXXX&searchtype=regex

   If the URL query string parameter "searchtype" has a value of
   "regex", then XXXX MUST be a base64url encoded POSIX extended regular
   expression. base64url encoding MUST be as described in section 5 of
   RFC 4648 [RFC4648].  The supplied regular expression will be matched
   against name server names in a name space administered by the server
   operator.  Name server names are as defined in RFC 5890 [RFC5890] in
   "letters, digits, hyphen" format.  Matches will return information
   for the matching name servers.  The following URL would be used to
   find information for name server names matching the
   "ns[1-9]\.e[a-z]ample\.com" pattern:

   https://example.com/rdap/
   nameservers?name=bnNbMS05XVwuZVthLXpdYW1wbGVcLmNvbQ&searchtype=regex

   Internationalized name server names in U-label format [RFC5890] can
   also be matched by POSIX compliant regular expression search
   patterns.  Search patterns for these names are of the form
   /nameservers?name=XXXX&searchtype=regex, where XXXX is a base64url
   encoded POSIX extended regular expression. base64url encoding MUST be
   as described in section 5 of RFC 4648 [RFC4648].  The supplied
   regular expression will be matched against name server names in
   U-label format.  See section 6.1 of RFC 7482 [RFC7482] for
   information describing U-label character encoding.  See Section 5 for
   other considerations relative to regular expression matching of
   U-labels.

Fregly, et al.             Expires May 4, 2017                  [Page 5]
Internet-Draft           RDAP Search using Regex            October 2016

   Searches for name server information by name server IP address are
   specified using this form:

   nameservers?ip=YYYY&searchtype=regex

   If the URL query string parameter "searchtype" has a value of
   "regex", then YYYY MUST be a base64url encoded POSIX extended regular
   expression. base64url encoding MUST be as described in section 5 of
   RFC 4648 [RFC4648].  The supplied regular expression will be matched
   against IPv4 addresses [RFC1166] and IPv6 addresses [RFC5952]
   associated with specific name servers.  The following URL would be
   used to search for name server names that resolve to addresses
   matching the "192\.0\.[1-9]\.0" pattern:

   https://example.com/rdap/
   nameservers?ip=MTkyXC4wXC5bMS05XVwuMA&searchtype=regex

2.3.  Entity Search

   Syntax: entities?fn=<entity name search pattern>&searchtype=regex

   Syntax: entities?handle=<entity handle search
   pattern>&searchtype=regex

   Searches for entity information by name are specified using this
   form:

   entities?fn=XXXX&searchtype=regex

   If the URL query string parameter "searchtype" has a value of
   "regex", then XXXX must be a base64url encoded POSIX extended regular
   expression. base64url encoding MUST be as described in section 5 of
   RFC 4648 [RFC4648].  The supplied regular expression will be matched
   against the "FN" property of an entity (such as a contact,
   registrant, or registrar) name as specified in Section 5.1 of RFC
   7483 [RFC7483].  The following URL would be used to find information
   for entity names matching the "Bobby[[:space:]]Joe[a-z]*" pattern:

   https://example.com/rdap/
   entities?fn=Qm9iYnlbWzpzcGFjZTpdXUpvZVthLXpdKg&searchtype=regex

   Searches for entity information by handle are specified using this
   form:

   entities?handle=XXXX&searchtype=regex

   If the URL query string parameter "searchtype" has a value of
   "regex", then XXXX is evaluated as a base64url encoded POSIX extended

Fregly, et al.             Expires May 4, 2017                  [Page 6]
Internet-Draft           RDAP Search using Regex            October 2016

   regular expression. base64url encoding MUST be as described in
   section 5 of RFC 4648 [RFC4648].  The supplied regular expression
   will be matched against an entity (such as a contact, registrant, or
   registrar) identifier whose syntax is specific to the registration
   provider.  The following URL would be used to find information for
   entity handles matching the "CID-4[0-9]*" pattern:

   https://example.com/rdap/
   entities?handle=Q0lELTRbMC05XSo&searchtype=regex

2.4.  Future Path Segments

   OPTIONAL extensions to new RDAP path segments defined in future RDAP
   specifications MAY be implemented to support POSIX extended regular
   expressions search capability.  The syntax for such OPTIONAL
   extensions MUST be modeled on the syntax defined in Section 2.1,
   Section 2.2, and Section 2.3.  The following syntax template MUST be
   followed:

   Syntax: {path_segment}?{property}=XXXX&searchtype=regex

   If the URL query string parameter "searchtype" has a value of
   "regex", then XXXX must be a base64url encoded POSIX extended regular
   expression. base64url encoding MUST be as described in section 5 of
   RFC 4648 [RFC4648].  The supplied regular expression will be matched
   against the property specified by {property} for the path segment
   specified by {path_segment}. For example, if a new RDAP path segment
   "foo" is defined and has a property "bar", the following URL would be
   used to find information for the "foo" resource type with a "bar"
   property matching the "widget:.*mech.*" pattern:

   https://example.com/rdap/
   foo?bar=d2lkZ2V0Oi4qbWVjaC4q&searchtype=regex

3.  Search Pattern Syntax

   POSIX extended regular expression search pattern syntax is defined in
   Section 9 of IEEE Std 1003.1, 2013 Edition
   [IEEE.1003.1_2013_EDITION].  An RDAP service implementation MAY
   implement a subset of the extended regular expression syntax and
   capabilities defined by the specification.  An RDAP service
   implementation MUST specify the regular expression syntax and
   capabilities it supports in response to a query to the /help path
   segment as specified in section 3.1.6 of RFC 7482 [RFC7482].

   Characters within a regular expression search pattern may be URI
   reserved characters.  To avoid ambiguity in parsing a URL containing

Fregly, et al.             Expires May 4, 2017                  [Page 7]
Internet-Draft           RDAP Search using Regex            October 2016

   a regular expression search pattern, the regular expression search
   pattern MUST be base64url encoded as described in RFC 4648 [RFC4648].

4.  Query Processing

   RDAP clients using regular expression search patterns MUST base64url
   encode the regular expression search pattern using a method described
   in RFC 4648 [RFC4648].  The regular expression SHOULD be consistent
   with the regular expression syntax and capabilities supported by the
   RDAP service implementation that is being queried in order to provide
   predictable results.  The use of a regular expression that is not
   consistent with the capabilities of the RDAP service implementation
   MUST result in the return of an HTTP 400 response code as described
   in section 5.4 of RFC 7480 [RFC7480].

   An RDAP service implementation will receive regular expressions
   search patterns that are base64url encoded.  Prior to processing a
   regular expression, the RDAP service MUST decode the received
   base64url encoded regular expression search pattern using a method
   described in RFC 4648 [RFC4648].  After decoding the received regular
   expression, the regular expression MUST be matched as described in
   Section 2.1, Section 2.2 and Section 2.3.  Matching records related
   to the search are then returned in the client.

   The POSIX regular expression specification [IEEE.1003.1_2013_EDITION]
   allows implementations to provide case insensitive searching.  RDAP
   service implementations SHOULD implement case insensitive searching
   as described in the specification.  This will allow for consistency
   in search results regardless of the case of the RDAP data being
   searched.  For example, some RDAP service implementations may
   represent domain names in upper case during searching while other
   RDAP service implementations may represent domain names in lower case
   or mixed case during searching.  Case insensitive searching will
   alleviate the need for search clients to know how each RDAP service
   implementation represents the case of searchable data.  RDAP service
   implementations that do not perform case insensitive searching may
   produce unexpected search results for entities that are not aware of
   how the service represents the case of searchable data.

   An RDAP service implementation MUST specify its support or lack of
   support for case insensitive searching in response to a query to the
   /help path segment as specified in section 3.1.6 of RFC 7482
   [RFC7482].

   Servers indicate the success or failure of query processing of a
   regular expression search pattern by returning an appropriate HTTP
   response code to the client.  Response codes not specifically
   identified in this document are described in RFC 7480 [RFC7480].

Fregly, et al.             Expires May 4, 2017                  [Page 8]
Internet-Draft           RDAP Search using Regex            October 2016

5.  Internationalization Considerations

   An RDAP service implementation that supports regular expression
   search patterns MUST support pattern construction and pattern
   matching using UTF-8 encoded character strings.  Other character
   encoding considerations are described in section 6.1 of RFC 7482
   [RFC7482].

6.  Implementation Considerations

   The set of related records that may be returned in response to a
   search with a regular expression search pattern are subject to the
   constraints specified in section 4.2 of RFC 7482 [RFC7482].

   An RDAP service implementation MAY choose to limit the scope of
   searches to RDAP data that is managed by the RDAP service
   implementation.  For example, an RDAP response to a query that could
   be matched against multiple TLDs or data in related RDAP repositories
   (such as those distributed between domain registry and domain
   registrar) need only return matches for the data managed by the RDAP
   service implementation.

   Regular expression matching results for some search patterns may vary
   based on the regular expression search engine used, the version of
   the engine used, and configuration of the search engine.  For
   example, POSIX [IEEE.1003.1_2013_EDITION] defines different semantics
   based on whether a search is using Basic Regular Expressions (BRE) or
   Extended Regular Expressions (ERE).  Search mechanisms that perform
   search processing compliant with Perl Compatible Regular Expressions
   (PCRE) as defined by pcre.org [PCRE] and in Perl 5 [PERLRE] may also
   produce matches that differ from matches produced by POSIX compatible
   regular expression matching.  Differences in regular expression
   matching between POSIX BRE, POSIX ERE and PCRE are illustrated in the
   examples below, where the "sed" command without the "-E" option is
   used for POSIX BRE matching, the "sed" command with the "-E" option
   is used for POSIX ERE matching, and the "perl" command is used for
   PCRE matching.

Fregly, et al.             Expires May 4, 2017                  [Page 9]
Internet-Draft           RDAP Search using Regex            October 2016

            $ echo 'abcdef' | sed 's/ab(cd)?(cdef)?/[xxxx]/'
            abcdef
            $ echo 'abcdef' | sed -E 's/ab(cd)?(cdef)?/[xxxx]/'
            [xxxx]
            $ echo 'abcdef' | perl -p -e 's/ab(cd)?(cdef)?/[xxxx]/'
            [xxxx]ef

            $ echo 'aaa' | sed 's/a\{3,\}/[xxxx]/'
            [xxxx]
            $ echo 'aaa' | sed 's/a{3,}/[xxxx]/'
            aaa
            $ echo 'aaa' | sed -E 's/a\{3,\}/[xxxx]/'
            aaa
            $ echo 'aaa' | sed -E 's/a{3,}/[xxxx]/'
            [xxxx]
            $ echo 'aaa' | perl -p -e 's/a\{3,\}/[xxxx]/'
            aaa
            $ echo 'aaa' | perl -p -e 's/a{3,}/[xxxx]/'
            [xxxx]

   Use of POSIX extended regular expressions is motivated by broad
   support in the form of API availability [GNU] and database support,
   with the following major databases supporting POSIX extended regular
   expressions:

           Oracle [ORACLE]
           MySQL [MYSQL]
           Postgres [POSTGRES]

7.  IANA Considerations

   FOR DISCUSSION: The URL query parameter "searchtype" with a value of
   "regex" is specified here-in as syntax for specifying that the RDAP
   query search pattern is a POSIX regular expression.  The same
   approach could be used for specifying future OPTIONAL RDAP search
   mechanisms.  An IANA-maintained registry of RDAP search mechanisms is
   recommended for recording a list of allowable values for the
   "searchtype" query parameter.

8.  Implementation Status

   Note to RFC Editor: Please remove this entire section before
   publication along with the reference to RFC7942 [RFC7942].

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in RFC 7942.

Fregly, et al.             Expires May 4, 2017                 [Page 10]
Internet-Draft           RDAP Search using Regex            October 2016

   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to RFC 7942, "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

8.1.  Verisign Labs

      Responsible Organization: Verisign Labs
      Location: https://rdap.verisignlabs.com/
      Description: This implementation includes support for POSIX
      extended regular expression domain registry RDAP queries using
      live data from the .cc and .tv country code top-level domains.
      This implementation also supports federated authentication using
      OpenID Connect providers as described in [RDAPOPENID].  Three
      access levels are provided based on the authenticated identity of
      the client:

      1.  Unauthenticated: Limited information is returned in response
          to queries from unauthenticated clients.
      2.  Basic: Clients who authenticate using a publicly available
          identity provider like Google Gmail or Microsoft Hotmail will
          receive all of the information available to an unauthenticated
          client plus additional registration metadata, but no
          personally identifiable information associated with entities.
      3.  Advanced: Clients who authenticate using a more restrictive
          identity provider will receive all of the information
          available to a Basic client plus whatever information the
          server operator deems appropriate for a fully authorized
          client.  Currently supported identity providers include those
          developed by Verisign Labs
          (https://testprovider.rdap.verisignlabs.com/) and CZ.NIC
          (https://www.mojeid.cz/).
      Level of Maturity: This is a "proof of concept" research
      implementation.
      Coverage: This implementation includes all of the features
      described in this specification.

Fregly, et al.             Expires May 4, 2017                 [Page 11]
Internet-Draft           RDAP Search using Regex            October 2016

      Contact Information: Swapneel Sheth, ssheth@verisign.com

9.  Security Considerations

   Security services for the operations specified in this document are
   described in RFC 7481 [RFC7481].

   Search functionality typically requires more server resources (such
   as memory, CPU cycles, and network bandwidth) when compared to basic
   lookup functionality.  This increases the risk of server resource
   exhaustion and subsequent denial of service due to abuse.  This risk
   can be mitigated by developing and implementing controls to restrict
   search functionality to identified and authorized clients.  If those
   clients behave badly, their search privileges can be suspended or
   revoked.  Rate limiting as described in Section 5.5 of RFC 7480
   [RFC7480] can also be used to control the rate of received search
   requests.  Server operators can also reduce their risk by restricting
   the amount of information returned in response to a search request.

   Search functionality also increases the privacy risk of disclosing
   object relationships that might not otherwise be obvious.  For
   example, a search that returns IDN variants [RFC6927] that do not
   explicitly match a client-provided search pattern can disclose
   information about registered domain names that might not be otherwise
   available.  Implementers need to consider the policy and privacy
   implications of returning information that was not explicitly
   requested.

   Note that there might not be a single, static information return
   policy that applies to all clients equally.  Client identity and
   associated authorizations can be a relevant factor in determining how
   broad the response set will be for any particular query.

10.  Acknowledgements

   The author would like to acknowledge the following individuals for
   their contributions to the development of this document: TBD.

11.  References

11.1.  Normative References

Fregly, et al.             Expires May 4, 2017                 [Page 12]
Internet-Draft           RDAP Search using Regex            October 2016

   [IEEE.1003.1_2013_EDITION]
              IEEE, "Standard for Information TechnologyPortable
              Operating System Interface (POSIX(R)) Base Specifications,
              Issue 7", IEEE 1003.1, 2013 Edition,
              DOI 10.1109/ieeestd.2013.6506091, April 2013,
              <http://ieeexplore.ieee.org/servlet/
              opac?punumber=6506089>.

   [RFC1166]  Kirkpatrick, S., Stahl, M., and M. Recker, "Internet
              numbers", RFC 1166, DOI 10.17487/RFC1166, July 1990,
              <http://www.rfc-editor.org/info/rfc1166>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <http://www.rfc-editor.org/info/rfc4648>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <http://www.rfc-editor.org/info/rfc5890>.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952,
              DOI 10.17487/RFC5952, August 2010,
              <http://www.rfc-editor.org/info/rfc5952>.

   [RFC6927]  Levine, J. and P. Hoffman, "Variants in Second-Level Names
              Registered in Top-Level Domains", RFC 6927,
              DOI 10.17487/RFC6927, May 2013,
              <http://www.rfc-editor.org/info/rfc6927>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
              Registration Data Access Protocol (RDAP)", RFC 7480,
              DOI 10.17487/RFC7480, March 2015,
              <http://www.rfc-editor.org/info/rfc7480>.

Fregly, et al.             Expires May 4, 2017                 [Page 13]
Internet-Draft           RDAP Search using Regex            October 2016

   [RFC7481]  Hollenbeck, S. and N. Kong, "Security Services for the
              Registration Data Access Protocol (RDAP)", RFC 7481,
              DOI 10.17487/RFC7481, March 2015,
              <http://www.rfc-editor.org/info/rfc7481>.

   [RFC7482]  Newton, A. and S. Hollenbeck, "Registration Data Access
              Protocol (RDAP) Query Format", RFC 7482,
              DOI 10.17487/RFC7482, March 2015,
              <http://www.rfc-editor.org/info/rfc7482>.

   [RFC7483]  Newton, A. and S. Hollenbeck, "JSON Responses for the
              Registration Data Access Protocol (RDAP)", RFC 7483,
              DOI 10.17487/RFC7483, March 2015,
              <http://www.rfc-editor.org/info/rfc7483>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <http://www.rfc-editor.org/info/rfc7942>.

11.2.  Informative References

   [GNU]      gnu.org, "GNU Regular Expression Matching",
              <https://www.gnu.org/software/libc/manual/html_node/
              Regular-Expressions.html>.

   [MYSQL]    mysql.com, "MySQL Regular Expressions",
              <http://dev.mysql.com/doc/refman/5.7/en/regexp.html>.

   [ORACLE]   Oracle Corporation, "Oracle SQL and POSIX Regular
              Expression Standard",
              <https://docs.oracle.com/database/121/ADFNS/
              adfns_regexp.htm#ADFNS231>.

   [PCRE]     pcre.org, "Perl Compatible Regular Expressions",
              <http://www.pcre.org/>.

   [PERLRE]   perl.org, "Perl regular expressions",
              <http://perldoc.perl.org/perlre.html>.

   [POSTGRES]
              postgresql.org, "PostgreSQL POSIX Regular Expressions",
              <https://www.postgresql.org/docs/9.3/static/functions-
              matching.html>.

Fregly, et al.             Expires May 4, 2017                 [Page 14]
Internet-Draft           RDAP Search using Regex            October 2016

   [RDAPOPENID]
              ietf.org, "Federated Authentication for the Registration
              Data Access Protocol (RDAP) using OpenID Connect",
              <https://tools.ietf.org/html/draft-hollenbeck-regext-rdap-
              openid-01.txt>.

Appendix A.  Change Log

   00:  Initial version.

Authors' Addresses

   Andrew Fregly
   Verisign Labs
   12061 Bluemont Way
   Reston, VA  20190
   USA

   Email: afregly@verisign.com
   URI:   http://www.verisignlabs.com/

   Swapneel Sheth
   Verisign Labs
   12061 Bluemont Way
   Reston, VA  20190
   USA

   Email: ssheth@verisign.com
   URI:   http://www.verisignlabs.com/

   Scott Hollenbeck
   Verisign Labs
   12061 Bluemont Way
   Reston, VA  20190
   USA

   Email: shollenbeck@verisign.com
   URI:   http://www.verisignlabs.com/

Fregly, et al.             Expires May 4, 2017                 [Page 15]