Skip to content

RDAP Conformance Tool Users Manual

About

The ICANN RDAP Conformance Tool, often referred to as "RDAPCT", is program to help RDAP server operators find issues of conformance to the Registration Data Access Protocol (RDAP) specifications, as defined by the Internet Engineering Task Force (IETF), and (optionally) the gTLD RDAP profiles, as defined by ICANN. RDAPCT may be used by other RDAP server operators, such as ccTLDs and RIRs, but is primarily designed for gTLD RDAP service operators. Apart from generic RDAP tests, there are no specific tests for IP addresses and AS Numbers RDAP servers.

RDAPCT operates by taking an RDAP URL, along with parameters defining the context of that URL, to send queries to the RDAP server and then produces a results file.

ICANN also hosts an online version of RDAPCT at https://webrdapct.icann.org.

Contributing

RDAPCT is open source software. ICANN accepts contributions for both the source code and this documentation. Pull requests for the source code are accepted against the master branch, and pull requests for this documentation are accepted against the gh-pages branch.

Installing and Using

There are two methods for installing and using the RDAP Conformance Tool. The first method uses Docker and the second method uses Java. Please be aware that running these this tool from within the network of a registry, registrar, or RDAP service provider may not find problems that are caused by CDNs, proxies, and other network elements. It is always advised to use this tool from "outside" your network. For this reason, the online version may be more appropriate.

With each method, the RDAP Conformance Tool must be given a full RDAP URL as defined by RFC 9082. For example, if the "base" RDAP URL for a domain registry or registrar is https://rdap.example then the complete URL for a domain at that registry or registrar would be https://rdap.example/domain/example.net.

The supplied configuration file, rdapct_config.json (which can be downloaded from a release) is configured to instruct the tool to ignore known false positives.

Using with Docker

To use Docker, you must either download a source release or clone the repository. This repository contains a Dockerfile which builds an image containing the tool.

To build it, run this command:

docker buildx build -t [image_name] .

Replace [image_name] with a unique memorable name such as rdapct. Once the image has been built, you can run the tool using

docker run rdapct ARGS

When run via Docker, a minimal configuration file is used, and the results are printed to STDOUT.

Datasets are added to the image at build time and are not refreshed, so the image should be rebuilt in order to ensure they are up-to-date.

Using with Java

To use with Java, you must obtain the RDAPCT JAR file and a configuration file. Both are available to download from a GitHub Release. You may also use Maven to build and compile it yourself.

To run the tool, invoke the Java command with the jar option referencing the rdapct JAR file and the configuration file:

java -jar rdapct-3.0.0.jar -c ./rdapct-config.json https://rdap.registry.com/domain/example.com

where rdapct-config.json is the configuration file.

Getting the Results

The tool issues the query specified on the command line, parses the response and tests the response.

The tool will return with exit code 0 if it was able to successfully query the RDAP server, otherwise it will return with a non-zero exit code. The details of the tests are found in the /results directory, and the datasets retrieved from the relevant IANA registries are found in the /datasets directory.

Queries such as domain, nameserver, entity are supported. Basic search (RFC 7482) is also supported.

Testing for RFC Compliance

By default, the RDAP Conformance Tool tests only for compliance with the IETF RDAP RFCs. To invoke the tool for this purpose, no special parameters are required:

Docker method: 

docker run rdapct https://test.example

Java method: 

java -jar rdapct-3.0.0.jar -c ./rdapct-config.json https://test.example

Testing As a gTLD Registry

For gTLD registries, there are additional parameters to be used: * --gtld-registry signifies to test the output for gTLD registry compliance * --thin if the gTLD registry is a "thin" registry * --use-rdap-profile-february-2019 to test for compliance with the 2019 gTLD RDAP Profile. * --use-rdap-profile-february-2024 to test for compliance with the 2024 gTLD RDAP Profile.

Docker method: 

docker run rdapct --gtld-registry --use-rdap-profile-february-2024 https://test.example

or for thin registries 

docker run rdapct --gtld-registry --thin --use-rdap-profile-february-2024 https://test.example

Java method: 

java -jar rdapct-3.0.0.jar -c ./rdapct-config.json --gtld-registry --use-rdap-profile-february-2024 https://test.example

or for thin registries 

java -jar rdapct-3.0.0.jar -c ./rdapct-config.json --gtld-registry --thin --use-rdap-profile-february-2024 https://test.example

Testing As a gTLD Registrar

For gTLD registrars, the following parameters are requried: * --gtld-registrar signifies to test the output for gTLD registrar compliance * --use-rdap-profile-february-2019 to test for compliance with the 2019 gTLD RDAP Profile. * --use-rdap-profile-february-2024 to test for compliance with the 2024 gTLD RDAP Profile.

Docker method: 

docker run rdapct --gtld-registrar --use-rdap-profile-february-2024 https://test.example

Java method: 

java -jar rdapct-3.0.0.jar -c ./rdapct-config.json --gtld-registrar --use-rdap-profile-february-2024 https://test.example

Additional Queries

The --additional-conformance-queries comamnd line parameter will cause RDAPCT to issue the following RDAP queries in addition to the one provided in the give RDAP URL:

  1. /help - queries the servers help path to asses conformance.
  2. /domain/not-a-domain.invalid - queries for a domain that cannot be registered to asses conformance with a negative answer.

Supressing IPv4 or IPv6 Queries

By default, RDAPCT issues all queries over both IPv4 and IPv6. The --no-ipv4-queries may be used to suppress queries over IPv4, and the --no-ipv6-queries may be used to suppress queries over IPv6.

Specifying the Results File

By default, RDAPCT writes the results to a file in a subordinate results directory with the file name results-XXXX.json where XXXX is the timestamp when the file was generated. The --results-file may be used to write the results to a file with a specific file name.

Testing A Local File

It is possible to test RDAP responses in local files. This requires using the "file" URL and the --query-type parameter. Here is an example using Java:

java -jar rdapct-3.0.0.jar -c ./rdapct-config.json --query-type DOMAIN file:///dir/subdir/test_example.json

The values for --query-type can be:

  • DOMAIN
  • NAMESERVER
  • ENTITY
  • AUTNUM
  • IP_NETWORK
  • NAMESERVERS
  • HELP
  • ERROR

Experimental Parallel Network Mode

You can now enable parallel network execution in RDAPCT. This makes the tool run network-related checks at the same time instead of one after the other. It can significantly reduce how long the tool takes to finish.

To enable this feature, use this system property when running the tool:

-Drdap.parallel.network=true

Example:

java -Drdap.parallel.network=true -jar rdap-conformance-tool.jar --config config.json https://example.com/rdap/domain/example.com

If you leave out the flag, the tool will run in the default (slower) mode with validations executing one at a time.

When enabled, this feature does the following:

  • Network checks run in parallel, which means several can happen at once.
  • It’s a more aggressive mode and may cause some network errors, especially with slow or unstable servers.
  • If you see a few network failures, rerunning the tool might resolve them. These errors are often just timing-related.

Exit Codes

RDAPCT emits the following exit codes when the process terminates:

Value Meaning
0 Normal Exit.
1 The configuration definition file is syntactically invalid.
2 The tool was not able to download a dataset.
3 The RDAP query is not supported by the tool.
4 The RDAP query is domain/ or nameserver/, but A-labels and U-labels are mixed.
5 No longer used. See result code -13000.
6 No longer used. See result code -13001.
7 No longer used. See result code -13002.
8 No longer used. See result code -13003.
9 The RDAP query is invalid because the TLD uses the thin model.
10 Failed to connect to host.
11 The TLS handshake failed.
12 TLS server certificate - common name invalid.
13 TLS server certificate - revoked.
14 TLS server certificate - expired.
15 Other errors with the TLS server certificate.
16 Too many redirects.
17 HTTP errors.
18 HTTP/2 errors.
19 Failure sending network data.
20 Failure in receiving network data.
21 Failure in writing result file.
22 Failure in reading result file.
23 Reserved.
24 Reserved.
25 Bad user input.

Queries & Rate Limits

RDAPCT will issue the same query multiple times over different transports and with various HTTP options. Depending on the implementation of the RDAP service, this may result in the same test result appearing multiple times in the output, appearing to be erroneous duplicates though they are not. The information on this page describes how RDAPCT sends queries and handles rate limits.

HTTP Methods and Transports

RDAPCT issues queries based on the URL it is given. Each URL may result in numerous queries:

  • Once over IPv4 (if available) using an accept header containing the media type “application/json” using the GET method.
  • Once over IPv4 (if available) using an accept header containing the media type “application/rdap+json” using the GET method.
  • Once over IPv6 (if available) using an accept header containing the media type “application/json” using the GET method.
  • Once over IPv6 (if available) using an accept header containing the media type “application/rdap+json” using the GET method.
  • Once over IPv4 (if available) using an accept header containing the media type “application/json” using the HEAD method if either of the ICANN gTLD RDAP Profiles is specified.
  • Once over IPv4 (if available) using an accept header containing the media type “application/rdap+json” using the HEAD method if either of the ICANN gTLD RDAP Profiles is specified.
  • Once over IPv6 (if available) using an accept header containing the media type “application/json” using the HEAD method if either of the ICANN gTLD RDAP Profiles is specified.
  • Once over IPv6 (if available) using an accept header containing the media type “application/rdap+json” using the HEAD method if either of the ICANN gTLD RDAP Profiles is specified.

Queries using the HEAD method will return no content and therefore tests comparing content will not be applicable.

Use of the HEAD method is determined when an ICANN gTLD profile is specified using either the --use-rdap-profile-february-2019 option or the --use-rdap-profile-february-2024 option (see Registry Testing and Registrar Testing).

Usage of IPv4 and IPv6 can be suppressed with the --no-ipv4-queries and --no-ipv6-queries (see Suppressing Queries).

Case Folding Queries

URLs for ASCII domains will automatically result in a "case-folded" equivalent query, and the results of each query will be compared for equivalence. For example, if the given URL is https://reg.example/domain/example.com then a case-folded query of https://reg.example/domain/eXaMpLe.CoM will sent as well.

Additional Queries

The --additional-conformance-queries option will also send queries for /help and /domain/not-a-domain.invalid. See Additional Queries.

Rate Limiting

RDAPCT honors the HTTP status code 429, as specified by RFC 7480.

If a 429 response contains a retry-after header (see RFC 9110), RDAPCT will requery once after the number of seconds specified by the value given in the retry-after header up to 120 seconds.

If a 429 response does not contain a retry-after header, RDAPCT will requery once after 30 seconds.

Configuration

The definition file specifies which single tests are errors, warnings, or ignored (i.e. not tested for).

Note: a definition file is required for starting a test.

The Configuration File

  • definitionIdentifier : a required JSON string that identifies the configuration definition file. The string is copied verbatim to the definitionIdentifier element of the results file.

  • definitionError : an optional JSON array of objects. Each object contains the following elements:

    • code : a required JSON number that identifies a single test.
    • notes : a required JSON string that is copied verbatim if the test fails, generating an entry in the results section in the results file.

  • definitionWarning : an optional JSON array of objects. Each object contains the following elements:

    • code : a required JSON number that identifies a single test.
    • notes : an optional JSON string that is copied verbatim if the test fails, generating an entry in the results section in the results file.
  • definitionIgnore : an optional JSON array of single test identifiers that are ignored (i.e. not tested for). The contents of this element are copied verbatim to the ignore section in the results file.
  • definitionNotes : an optional JSON array of strings that are copied verbatim to the notes section in the results file.

Example Configuration

{
    "definitionIdentifier": "gTLD Profile Version 1.0",
    "definitionError": [{
        "code": -1102,
        "notes": "If the gTLD is a legacy gTLD, this may not indicate an error, review by a person is required."
    }],
    "definitionWarning": [{
        "code": -2186,
        "notes": "This only applies for a few gTLDs."
    }],
    "definitionIgnore": [-2323, -2345, -2346],
    "definitionNotes": ["This is a configuration definition for a legacy gTLD.", "Developed by ICANN."]
}

Test Categories and Groups

Categories and Groups

Tests fall into one of three categoreis:

Inside each category, tests are organized into test groups. Individual tests will often refer to or depend on other test groups. Many of the tests applicable to the 2024 gTLD profile are found in the 2019 gTLD profile.

Extensions IDs and Profile Versions

The table below maps the gTLD profile versions and RDAP extension identifiers:

Year Version Technical Implementation Guide ID Response Profile ID
2019 v2.1 icann_rdap_technical_implementation_guide_0 icann_rdap_response_profile_0
2024 v2.2 icann_rdap_technical_implementation_guide_1 icann_rdap_response_profile_1

Test Results

Be default, RDAPCT places the results in a file in the results directory in the current working directory, with a file name of results-YYYYMMDDHHmmsss.json where YYYYMMDDHHmmss is the UTC time when the file was written.

This file can be specified using the --results-file option (see Specifying the Results File).

The results file will look something like this, except with no comments (which are not valid JSON):

{
    // Information on the version of the software.
    "testedDate": "2025-07-15T14:56:51.894633Z",
    "buildDate": "2025-07-15T14:55:27Z",
    "conformanceToolVersion": "2.0.3",

    // Information on the inputs and options.
    "testedURI": "https://example.org/domain/example.net",
    "gtldRegistry": true,
    "gtldRegistrar": false,
    "rdapProfileFebruary2019": false,
    "rdapProfileFebruary2024": true,
    "noIpv4": false,
    "noIpv6": false,
    "thinRegistry": false,
    "additionalConformanceQueries": false,
    "definitionIdentifier": "Standard gTLD RDAP Server Conformance",

    // Group results.
    "groupOK": [],
    "groupErrorWarning": [],

    // Specific results.
    "results": {

        // Tests that are ignored based on the configuration file.
        "ignore": [],

        // Notes about the tests from the configuration file.
        "notes": ["This conformance configuration is typical of gTLD RDAP server needs."],

        // Tests that resulted in warnings.
        "warning": [],

        // Tests that resulted in an error.
        "error": [{

            // The media type used in the accept header
            "acceptMediaType": null,

            // The result code of the test.
            "code": -13019,

            // Specific notes about the test.
            "notes": "",

            // The IP address of the server tested.
            "serverIpAddress": null,

            // Information about the test result.
            "message": "Unable to resolve an IP address endpoint using DNS.",

            // The query URI of the test.
            "queriedURI": null,

            // The HTTP method of the teset.
            "httpMethod": null,

            // Relevant value being tested.
            "value": "no response available",

            // Received HTTP status code.
            "receivedHttpStatusCode": null
        }]
    }
}

STD 95 Tests

General Tests

IPv4 address validation

Test group: [ipv4Validation]

The following steps should be used to test that an IPv4 address is valid:

  1. Test case -10100: The IPv4 address is syntactically valid in dot-decimal notation. 
    {
  "code": -10100,
  "value": "<IPv4 address string>",
  "message": "The IPv4 address is not syntactically valid in dot-decimal notation."
}
  2. Test case -10101: The IPv4 address MUST be part of a prefix categorized as "ALLOCATED" or "LEGACY" in the "Status" field in the ipv4AddressSpace. 
    {
  "code": -10101,
  "value": "<IPv4 address string>",
  "message": "The IPv4 address is not included in a prefix categorized as ALLOCATED or LEGACY in the IANA IPv4 Address Space Registry. Dataset: ipv4AddressSpace"
}
  3. Test case -10102: The IPv4 address MUST NOT be part of the specialIPv4Addresses. 
    {
  "code": -10102,
  "value": "<IPv4 address string>",
  "message": "The IPv4 address is included in the IANA IPv4 Special-Purpose Address Registry. Dataset: specialIPv4Addresses"
}

IPv6 address validation

Test group: [ipv6Validation]

The following steps should be used to test that an IPv6 address is valid:

  1. Test case -10200: The IPv6 address is in canonical textual representation format. 
    {
  "code": -10200,
  "value": "<IPv6 address string>",
  "message": "The IPv6 address is not syntactically valid."
}
  2. Test case -10201: The IPv6 address MUST be part of an allocation of type "Global Unicast" in the ipv6AddressSpace. 
    {
  "code": -10201,
  "value": "<IPv6 address string>",
  "message": "The IPv6 address is not included in a prefix categorized as Global Unicast in the Internet Protocol Version 6 Address Space. Dataset: ipv6AddressSpace"
}
  3. Test case -10202: The IPv6 address MUST NOT be part of the specialIPv6Addresses. 
    {
  "code": -10202,
  "value": "<IPv6 address string>",
  "message": "The IPv6 address is included in the IANA IPv6 Special-Purpose Address Registry. Dataset: specialIPv6Addresses"
}

Domain Name validation

Test group: [domainNameValidation]

The following steps should be used to test that a domain name is valid:

  1. Test case -10300: The length of each label is between 1 and 63. 
    {
  "code": -10300,
  "value": "<domain name>",
  "message": "A DNS label with length not between 1 and 63 was found."
}
  2. Test case -10301: A maximum total length of 253 characters not including the last ".". 
    {
  "code": -10301,
  "value": "<domain name>",
  "message": "A domain name of more than 253 characters was found. "
}
  3. Test case -10302: At least two labels shall exist in the domain name. See, RDAP_Technical_Implementation_Guide_2_1 section 1.10. 
    {
  "code": -10302,
  "value": "<domain name>",
  "message": "A domain name with less than two labels was found."
}
  4. Test case -10303: Each label of the domain name is a valid "A-label", "U-label", or "NR-LDH label". 
    {
  "code": -10303,
  "value": "<domain name>",
  "message": "A DNS label not being a valid 'A-label', 'U-label', or 'NR-LDH label' was found."
}

Note: the latest version of the IANA IDNA Rules and Derived Property Values shall be used. See https://www.iana.org/assignments/idna-tables-11.0.0/idna-tables-11.0.0.xml.

Web URI validation

Test group: [webUriValidation]

The following steps should be used to test that a Web URI is valid:

  1. Test case -10400: The URI shall be syntactically valid according to RFC3986. 
    {
  "code": -10400,
  "value": "<URI>",
  "message": "The URI is not syntactically valid according to RFC3986."
}
  2. Test case -10401: The scheme of the URI shall be "http" or "https". 
    {
  "code": -10401,
  "value": "<URI>",
  "message": "The scheme of the URI is not 'http' nor 'https'"
}
  3. Test case -10402: The host of the URI shall pass the test Domain Name validation [domainNameValidation], IPv4 address validation [ipv4Validation] or IPv6 address validation [ipv6Validation]. 
    {
  "code": -10402,
  "value": "<URI>",
  "message": "The host does not pass Domain Name validation [domainNameValidation], IPv4 address validation [ipv4Validation] nor IPv6 address validation [ipv6Validation]"
}

Domain label case folding validation

Test group: [domainCaseFoldingValidation]

The following steps should be used to test that an RDAP server is processing label case conversion correctly for domain name lookups:

  1. Test case -10403: A subsequent RDAP lookup may be performed in the case of a domain name lookup to validate correct support for case insensitive label matching:
    1. For any "NR-LDH label" or "A-label" present, the RDAP response must match the response of a subsequent request converting any "NR-LDH label" or "A-label" alternating uppercase and lowercase characters (e.g., if the domain is "test.example" the RDAP response must match also for converted domain name "tEsT.ExAmPlE").
    2. For any "U-Label" present, in case that any of the code points support case folding, the u-label should be case-folded for the subsequent request. (e.g., if the domain is "CAFÉ.EXAMPLE" the RDAP response must match also for converted domain name "café.ExAmPlE").
      • In case that the domain name in the query contains all u-labels and none of the labels can be case-folded (i.e., the script or code points do not support case folding) a subsequent query is not required.
      • In case that the domain name in the query contains all u-labels and the resulting domain name to query after case-folding is the same as the original, a subsequent query is not required.
{
  "code": -10403,
  "value": "<converted domain name>",
  "message": "RDAP responses do not match when handling domain label case folding."
}

Common Data Structures Tests

RDAP Conformance validation

Test group: [stdRdapConformanceValidation]

The following steps should be used to test that an RDAP Conformance data structure is valid:

  1. Test case -10500: The RDAP Conformance data structure must be a syntactically valid JSON array. 
    {
  "code": -10500,
  "value": "<rdapConformance structure>",
  "message": "The RDAP Conformance structure is not syntactically valid."
}
  2. Test case -10501: Every value of the JSON array shall be a JSON string data type. 
    {
  "code": -10501,
  "value": "<JSON value>",
  "message": "The JSON value is not a string."
}
  3. Test case -10502: Each of the JSON string values in the JSON array, with the exception of "rdap_level_0", shall be included as an Extension Identifier in RDAPExtensions. 
    {
  "code": -10502,
  "value": "<JSON string>",
  "message": "The JSON string is not included as an Extension Identifier in RDAPExtensions."
}
  4. Test case -10503: The JSON string value "rdap_level_0" is not included in the RDAP Conformance data structure. 
    {
  "code": -10503,
  "value": "<rdapConformance>",
  "message": "The RDAP Conformance data structure does not include rdap_level_0."
}
  5. Test case -10504: The rdapConformance array must exist in all RDAP responses. 
    {
  "code": -10504,
  "value": "<response>",
  "message": "RFC 9083 requires all RDAP responses to have an rdapConformance array."
}
  6. Test case -10505: If the rdapConformance array exists in an object that is embedded in another object, then this is an error because rdapConformance must only appear in the top-most part of an RDAP response. 
    {
  "code": -10505,
  "value": "<RDAP object>",
  "message": "The rdapConformance array must appear only in the top-most of the RDAP response."
}

Test group: [stdRdapLinksValidation]

The following steps should be used to test that a links data structure is valid:

  1. Test case -10600: The links data structure must be a syntactically valid JSON array. 
    {
  "code": -10600,
  "value": "<links structure>",
  "message": "The links structure is not syntactically valid."
}
  2. For every object (i.e. link) of the JSON array, verify that the link structure complies with:
    1. Test case -10601: The name of every name/value pair shall be value, rel, href, hreflang, title, media or type. 
      {
  "code": -10601,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: value, rel, href, hreflang, title, media or type."
}
    2. Test case -10602: The JSON name/value pairs of rel, href, hreflang, title, media and type shall appear only once. 
      {
  "code": -10602,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a link structure was found more than once."
}
    3. Test case -10603: If the JSON name media exists, the allowed values are: screen, tty, tv, projection, handheld, print, braille, embossed, speech, and all. 
      {
  "code": -10603,
  "value": "<name/value pair>",
  "message": "The value for the JSON name media is not of: screen, tty, tv, projection, handheld, print, braille, embossed, speech, or all."
}
    4. Test case -10604: If the JSON name rel exists, the value shall be included as a "Relation Name" in linkRelations. 
      {
  "code": -10604,
  "value": "<name/value pair>",
  "message": "The JSON value is not included as a Relation Name in linkRelations."
}
    5. Test case -10605: If the JSON name type exists, the value shall be included as a "Type Name/Subtype Name" as registered in mediaTypes. 
      {
  "code": -10605,
  "value": "<name/value pair>",
  "message": "The JSON value is not included as a Name in mediaTypes."
}
    6. Test case -10606: If the JSON name title exists, the value shall be a JSON string data type. 
      {
  "code": -10606,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
    7. Test case -10607: If the JSON name hreflang exists, the value shall be a JSON string data type or a valid JSON array where every value is a JSON string data type. 
      {
  "code": -10607,
  "value": "<name/value pair>",
  "message": "The value for the JSON name hreflang is not a JSON string data type or a valid JSON array where every value is a JSON string data type."
}
    8. Test case -10608: If the JSON name hreflang exists, every one of the JSON string data values shall conform to the Language-Tag syntax. 
      {
  "code": -10608,
  "value": "<name/value pair>",
  "message": "The value of the JSON string data in the hreflang does not conform to Language-Tag syntax."
}
    9. Test case -10609: If the JSON name value exists, the value shall pass the test Web URI validation [webUriValidation] defined in this document. 
      {
  "code": -10609,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Web URI validation [webUriValidation]."
}
    10. Test case -10610: The JSON name href shall exist. 
      {
  "code": -10610,
  "value": "<links structure>",
  "message": "The href element does not exist."
}
    11. Test case -10611: For the JSON name href, the value shall pass the test Web URI validation [webUriValidation] defined in this document. 
      {
  "code": -10611,
  "value": "<name/value pair>",
  "message": "The value for the JSON name href does not pass Web URI validation [webUriValidation]."
}
    12. Test case -10612: The JSON name value shall exist: 
      {
  "code": -10612,
  "value": "<link structure>",
  "message": "A 'value' propert does not exist in the link object."
}
    13. Test case -10613: The JSON name “rel” shall exist: 
      {
  "code": -10613,
  "value": "<link structure>",
  "message": "A 'rel' property does not exist in the link object."
}

Notices and Remarks Validation

Test group: [stdRdapNoticesRemarksValidation]

The following steps should be used to test that a notices or remarks data structure is valid:

  1. Test case -10700: The notices or remarks data structure must be a syntactically valid JSON array. 
    {
  "code": -10700,
  "value": "<notices or remarks structure>",
  "message": "The notices or remarks structure is not syntactically valid."
}
  2. For every object of the JSON array, verify that the structure complies with:
    1. Test case -10701: The name of every name/value pair shall be title, type, description or links. 
      {
  "code": -10701,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: title, type, description or links."
}
    2. Test case -10702: The JSON name/values of title, type, description and links shall exist only once. 
      {
  "code": -10702,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a link structure was found more than once."
}
    3. Test case -10703: If the JSON name title exists, the value shall be a JSON string data type. 
      {
  "code": -10703,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
    4. Test case -10704: If the JSON name links exists, the value shall pass the test Links validation [stdRdapLinksValidation] defined in this document. 
      {
  "code": -10704,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Links validation [stdRdapLinksValidation]."
}
    5. Test case -10705: If the JSON name type exists, the value shall be a JSON string data type. 
      {
  "code": -10705,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
    6. Test case -10706: If the JSON name type exists, the value shall be included in the RDAPJSONValues with Type="notice and remark type". 
      {
  "code": -10706,
  "value": "<JSON string>",
  "message": "The JSON string is not included as a Value with Type='notice and remark type' in the RDAPJSONValues dataset."
}
    7. Test case -10707: The JSON name description shall exist. 
      {
  "code": -10707,
  "value": "<notices or remarks structure>",
  "message": "The description element does not exist."
}
    8. Test case -10708: The description data structure must be a syntactically valid JSON array. 
      {
  "code": -10708,
  "value": "<description structure>",
  "message": "The description structure is not syntactically valid."
}
    9. Test case -10709: Every value of the JSON array of the description data structure shall be a JSON string data type. 
      {
  "code": -10709,
  "value": "<JSON value>",
  "message": "The JSON value is not a string."
}

Language Identifier Validation

Test group: [stdRdapLanguageIdentifierValidation]

The following steps should be used to test that a lang data structure is valid:

  1. Test case -10800: For the JSON name lang, the value shall conform to the Language-Tag syntax. 
    {
  "code": -10800,
  "value": "<name/value pair>",
  "message": "The value of the JSON string data in lang does not conform to Language-Tag syntax."
}

Events Validation

Test group: [stdRdapEventsValidation]

The following steps should be used to test that a events data structure is valid:

  1. Test case -10900: The events data structure must be a syntactically valid JSON array. 
    {
  "code": -10900,
  "value": "<events structure>",
  "message": "The events structure is not syntactically valid."
}
  2. For every object of the JSON array, verify that the structure complies with:
    1. Test case -10901: The name of every name/value pair shall be any of: eventAction, eventActor, eventDate or links. 
      {
  "code": -10901,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: eventAction, eventActor, eventDate or links."
}
    2. Test case -10902: The JSON name/value pairs of eventAction, eventActor, eventDate and links shall exist only once. 
      {
  "code": -10902,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a link structure was found more than once. "
}
    3. Test case -10903: The JSON name eventAction shall exist. 
      {
  "code": -10903,
  "value": "<links structure>",
  "message": "The eventAction element does not exist."
}
    4. Test case -10904: For the JSON name eventAction, the value shall be a JSON string data type. 
      {
  "code": -10904,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
    5. For the JSON name eventAction, the value shall be included in the RDAPJSONValues with Type="event action". 
      {
  "code": -10905,
  "value": "<JSON string>",
  "message": "The JSON string is not included as a Value with Type='event action' in the RDAPJSONValues data set.
}
    6. Test case -10906: The JSON name eventDate shall exist. 
      {
  "code": -10906,
  "value": "<links structure>",
  "message": "The eventDate element does not exist."
}
    7. Test case -10907: For the JSON name eventDate, the value shall be a JSON string data type. 
      {
  "code": -10907,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
    8. Test case -10908: For the JSON name eventDate, the value shall be syntactically valid time and date according to RFC3339. 
      {
"code": -10908,
"value": "<name/value pair>",
"message": "The JSON value shall be a syntactically valid time and date according to RFC3339."
}
    9. Test case -10909: If the JSON name eventActor exists, the value shall be a JSON string data type. 
      {
  "code": -10909,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
    10. Test case -10910: If the JSON name links exists, the JSON name eventActor shall also exist. 
      {
  "code": -10910,
  "value": "<events structure>",
  "message": "A links structure was found but an eventActor was not."
}
    11. Test case -10911: If the JSON name links exists, the value shall pass the test Links validation [stdRdapLinksValidation] defined in this document. 
      {
  "code": -10911,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Links validation [stdRdapLinksValidation]."
}
  3. Test case -10912: An eventAction value shall only appears once within the events array. 
    {
  "code": -10912,
  "value": "<events structure>",
  "message": "An eventAction value exists more than once within the events array."
}

Status validation

Test group: [stdRdapStatusValidation]

The following steps should be used to test that a status data structure is valid:

  1. Test case -11000: The status data structure must be a syntactically valid JSON array. 
    {
  "code": -11000,
  "value": "<status structure>",
  "message": "The status structure is not syntactically valid."
}
  2. Test case -11001: Every value of the JSON array shall be a JSON string data type. 
    {
  "code": -11001,
  "value": "<JSON value>",
  "message": "The JSON value is not a string."
}
  3. Test case -11002: Each of the JSON string values in the JSON array shall be included in the RDAPJSONValues with Type="status". 
    {
  "code": -11002,
  "value": "<JSON string>",
  "message": "The JSON string is not included as a Value with Type='status'."
}
  4. Test case -11003: A string in the status array shall only appear once: 
    {
  "code": -11003,
  "value": "<JSON string>",
  "message": "A status value exists more than once in the status array."
}

Port 43 WHOIS Server

Test group: [stdRdapPort43WhoisServerValidation]

The following steps should be used to test that a port43 data structure is valid:

  1. Test case -11100: For the JSON name port43, the value shall pass the test [IPv4Validation], [IPv6Validation] or [DomainNameValidation] defined in this document. 
    {
"code": -11100,
"value": "<name/value pair>",
"message": "The value for the JSON name port43 does not pass [IPv4Validation], [IPv6Validation] or [DomainNameValidation]."
}

Public IDs validation

Test group: [stdRdapPublicIdsValidation]

The following steps should be used to test that a publicIds data structure is valid:

  1. Test case -11200: The publicIds data structure must be a syntactically valid JSON array. 
    {
  "code": -11200,
  "value": "<publicIds structure>",
  "message": "The publicIds structure is not syntactically valid."
}
  2. For every object of the JSON array, verify that the structure complies with:
    1. Test case -11201: The name of every name/value pairs shall be type or identifier. 
      {
  "code": -11201,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: type or identifier."
}
    2. Test case -11202: The JSON name/values of type or identifier shall appear only once. 
      {
  "code": -11202,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a domain structure was found more than once."
}
    3. Test case -11203: The JSON name/values of type and identifier shall appear. 
      {
  "code": -11203,
  "value": "<publicIds structure>",
  "message": "The following name/values shall exist: type or identifier."
}
    4. Test case -11204: For the JSON name type, the value shall be a JSON string data type. 
      {
  "code": -11204,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
    5. Test case -11205: For the JSON name identifier, the value shall be a JSON string data type. 
      {
  "code": -11205,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}

asEventActor Validation

Test group: [stdRdapAsEventActorValidation]

The following steps should be used to test that an asEventActor data structure is valid:

  1. Test case -11300: The asEventActor data structure must be a syntactically valid JSON array. 
    {
  "code": -11300,
  "value": "<asEventActor structure>",
  "message": "The asEventActor structure is not syntactically valid."
}
  2. Test case -11301: The asEventActor data structure must be embedded within an entity object, and the entity object must be embedded within another object. 
    {
  "code": -11301,
  "value": "<asEventActor structure>",
  "message": "The asEventActor structure is not embedded within an entity object and the entity object is not embedded within another object."
}
  3. For every object of the JSON array, verify that the structure complies with:
    1. Test case -11302: The name of every name/value pair shall be any of: eventAction or eventDate. 
      {
  "code": -11302,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: eventAction and eventDate."
}
    2. Test case -11303: The JSON name/values of eventAction or eventDate shall appear only once. 
      {
  "code": -11303,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a link structure was found more than once."
}
    3. Test case -11304: The JSON name eventAction shall exist. 
      {
  "code": -11304,
  "value": "<links structure>",
  "message": "The eventAction element does not exist."
}
    4. Test case -11305: For the JSON name eventAction, the value shall be a JSON string data type. 
      {
  "code": -11305,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
    5. Test case -11306: For the JSON name eventAction, the value shall be included in the RDAPJSONValues with Type="event action". 
      {
  "code": -11306,
  "value": "<JSON string>",
  "message": "The JSON string is not included as a Value with Type='event action' in the RDAPJSONValues dataset."
}
    6. Test case -11307: The JSON name eventDate shall exist. 
      {
  "code": -11307,
  "value": "<links structure>",
  "message": "The eventDate element does not exist."
}
    7. Test case -11308: For the JSON name eventDate, the value shall be a JSON string data type. 
      {
  "code": -11308,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
    8. Test case -11309: For the JSON name eventDate, the value shall be syntactically valid time and date according to RFC3339. 
      {
  "code": -11309,
  "value": "<name/value pair>",
  "message": "The JSON value shall be a syntactically valid time and date according to RFC3339."
}
  4. Test case -11310: An eventAction shall only appear once within the events array. 
    {
  "code": -11310,
  "value": "<events structure>",
  "message": "An _eventAction_ exists more than once within the events array."
}

IP Addresses Validation

Test group: [stdRdapIpAddressesValidation]

The following steps should be used to test that an ipAddresses data structure is valid:

  1. Test case -11400: The ipAddresses data structure must be a syntactically valid JSON object. 
    {
  "code": -11400,
  "value": "<ipAddresses structure>",
  "message": "The ipAddresses structure is not syntactically valid."
}
  2. Test case -11401: The name of every name/value pair shall be any of: v4 or v6. 
    {
  "code": -11401,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: v4 or v6."
}
  3. Test case -11402: The JSON name/values of v4 and v6 shall appear only once. 
    {
  "code": -11402,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of an ipAddresses structure was found more than once."
}
  4. Test case -11403: One v4 name/values or one v6 name/value shall appear. 
    {
  "code": -11403,
  "value": "<name/value pair>",
  "message": "v4 nor v6 name/value pair exists."
}
  5. If the JSON name v4 exists, the value shall pass the following:
    1. Test case -11404: The v4 data structure must be a syntactically valid JSON array. 
      {
  "code": -11404,
  "value": "<v4 structure>",
  "message": "The v4 structure is not syntactically valid."
}
    2. For every object of the JSON array, verify that the structure complies with:
      1. Test case -11405: Every value of the JSON array shall be a JSON string data type. 
        {
  "code": -11405,
  "value": "<JSON value>",
  "message": "The JSON value is not a string."
}
      2. Test case -11406: The IPv4 address is syntactically valid in dot-decimal notation. 
        {
  "code": -11406,
  "value": "<IPv4 address string>",
  "message": "The IPv4 address is not syntactically valid in dot-decimal notation."
}
  6. If the JSON name v6 exists, the value shall pass the following:
    1. Test case -11407: The v6 data structure must be a syntactically valid JSON array. 
      {
  "code": -11407,
  "value": "<v6 structure>",
  "message": "The v6 structure is not syntactically valid."
}
    2. For every object of the JSON array, verify that the structure complies with:
      1. Test case -11408: Every value of the JSON array shall be a JSON string data type. 
        {
  "code": -11408,
  "value": "<JSON value>",
  "message": "The JSON value is not a string."
}
      2. Test case -11409: The IPv6 address is syntactically valid. 
        {
  "code": -11409,
  "value": "<IPv6 address string>",
  "message": "The IPv6 address is not syntactically valid."
}

Variants validation

Test group: [stdRdapVariantsValidation]

The following steps should be used to test that a variants data structure is valid:

  1. Test case -11500: The variants data structure must be a syntactically valid JSON array. 
    {
  "code": -11500,
  "value": "<variants structure>",
  "message": "The variants structure is not syntactically valid."
}

  2. For every object of the JSON array, verify that the structure complies with:

    1. Test case -11501: The name of every name/value pair shall be relation, idnTable or variantNames. 
      {
  "code": -11501,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: relation, idnTable or variantNames."
}
    2. Test case -11502: The JSON name/value pairs of relation, idnTable and variantNames shall appear only once. 
      {
  "code": -11502,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a link structure was found more than once."
}
    3. Test case -11503: The RDAP relation data structure must be a syntactically valid JSON array. 
      {
  "code": -11503,
  "value": "<relation structure>",
  "message": "The RDAP Conformance structure is not syntactically valid."
}

    4. For every object of the JSON array, verify that the structure complies with:

    5. Test case -11504: Every value of the JSON array shall be a JSON string data type. 

      {
  "code": -11504,
  "value": "<JSON value>",
  "message": "The JSON value is not a string."
}

    6. Test case -11505: Each of the JSON string values in the JSON array shall be included in the RDAPJSONValues with Type="domain variant relation". 
      {
  "code": -11505,
  "value": "<JSON string>",
  "message": "The JSON string is not included as a Value with Type='domain variant relation '."
}
    7. Test case -11506: If the JSON name idnTable exists, the value shall be a JSON string data type. 
      {
  "code": -11506,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
    8. Test case -11507: The variantNames data structure must be a syntactically valid JSON array. 
      {
  "code": -11507,
  "value": "<variantNames structure>",
  "message": "The variantNames structure is not syntactically valid."
}
    9. For every object of the JSON array, verify that the structure complies with:
      1. Test case -11508: The name of every name/value pair shall be any of: ldhName or unicodeName 
        {
  "code": -11508,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: ldhName or unicodeName."
}
      2. Test case -11509: The JSON name/value pairs of ldhName or unicodeName shall exist only once. 
        {
  "code": -11509,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a link structure was found more than once."
}
      3. Test case -11510: If the JSON name title ldhName exists, the value shall pass the test LDH name [stdRdapLdhNameValidation] defined in this document. 
        {
  "code": -11510,
  "value": "<name/value pair>",
  "message": " The value for the JSON name value does not pass LDH name [stdRdapLdhNameValidation]."
}
      4. Test case -11511: If the JSON name unicodeName exists, the value shall pass the test Unicode name [stdRdapUnicodeNameValidation] defined in this document. 
        {
  "code": -11511,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Unicode name [stdRdapUnicodeNameValidation]."
}

Unicode name

Test group: [stdRdapUnicodeNameValidation]

The following steps should be used to test that a unicodeName is valid:

  1. Test case -11600: The length of each label is between 1 and 63. 
    {
  "code": -11600,
  "value": "<domain name>",
  "message": "A DNS label with length not between 1 and 63 was found."
}
  2. Test case -11601: A maximum total length of 253 characters not including the last ".". 
    {
  "code": -11601,
  "value": "<domain name>",
  "message": "A domain name of more than 253 characters was found."
}
  3. Test case -11602: At least two labels shall exist in the domain name. See, RDAP_Technical_Implementation_Guide_2_1 section 1.10. 
    {
  "code": -11602,
  "value": "<domain name>",
  "message": "A domain name with less than two labels was found. See RDAP_Technical_Implementation_Guide_2_1 section 1.10"
}
  4. Test case -11603: Each label of the domain name is a valid "U-label or "NR-LDH label". 
    {
  "code": -11603,
  "value": "<domain name>",
  "message": "A label not being a valid 'U-label' or 'NR-LDH label' was found."
}

Note: the latest version of the IANA IDNA Rules and Derived Property Values shall be used. See, https://www.iana.org/assignments/idna-tables-11.0.0/idna-tables-11.0.0.xml

Note: some legacy gTLDs may fail this test, because they have a few domain name registrations that comply with IDNA2003 but not IDNA2018. Such names are not recommended to be used when testing an RDAP response with this tool.

LDH name

Test group: [stdRdapLdhNameValidation]

The following steps should be used to test that a ldhName is valid:

  1. Test case -11700: The length of each label is between 1 and 63. 
    {
  "code": -11700,
  "value": "<domain name>",
  "message": "A DNS label with length not between 1 and 63 was found."
}
  2. Test case -11701: A maximum total length of 253 characters not including the last ".". 
    {
  "code": -11701,
  "value": "<domain name>",
  "message": "A domain name of more than 253 characters was found."
}
  3. Test case -11702: At least two labels shall exist in the domain name. See, RDAP_Technical_Implementation_Guide_2_1 section 1.10. 
    {
  "code": -11702,
  "value": "<domain name>",
  "message": "A domain name with less than two labels was found. See RDAP_Technical_Implementation_Guide_2_1 section 1.10"
}
  4. Test case -11703: Each label of the domain name is a valid "A-label or "NR-LDH label". 
    {
  "code": -11703,
  "value": "<domain name>",
  "message": "A label not being a valid 'A-label' or 'NR-LDH label' was found."
}

Note: the latest version of the IANA IDNA Rules and Derived Property Values shall be used. See, https://www.iana.org/assignments/idna-tables-11.0.0/idna-tables-11.0.0.xml

Note: some legacy gTLDs may fail this test, because they have a few domain name registrations that comply with IDNA2003 but not IDNA2018. Such names are not recommended to be used when testing an RDAP response with this tool.

Roles validation

Test group: [stdRdapRolesValidation]

The following steps should be used to test that a roles data structure is valid:

  1. Test case -11800: The roles data structure must be a syntactically valid JSON array. 
    {
  "code": -11800,
  "value": "<roles structure>",
  "message": "The roles structure is not syntactically valid."
}
  2. Test case -11801: Every value of the JSON array shall be a JSON string data type. 
    {
  "code": -11801,
  "value": "<JSON value>",
  "message": "The JSON value is not a string."
}
  3. Test case -11802: Each of the JSON string values in the JSON array shall be included in the RDAPJSONValues with Type="role". 
    {
  "code": -11802,
  "value": "<JSON string>",
  "message": "The JSON string is not included as a Value with Type='role'."
}
  4. Test case -11803: The role value shall only appear once in the JSON array. 
    {
  "code": -11803,
  "value": "<roles structure>",
  "message": "A role value appeared more than once."
}

Entities validation

Test group: [stdRdapEntitiesValidation]

The following steps should be used to test that an entities data structure is valid:

  1. Test case -11900: The entities data structure must be a syntactically valid JSON array. 
    {
    "code": -11900,
    "value": "<entities structure>",
    "message": "The entities structure is not syntactically valid."
}
  2. Test case -11901: Every value of the JSON array shall pass the test Entity lookup validation [stdRdapEntityLookupValidation] defined in this document. 
    {
    "code": -11901,
    "value": "<JSON value>",
    "message": "The JSON value does not pass Entity lookup validation [stdRdapEntityLookupValidation]."
}

Secure DNS validation

Test group: [stdRdapSecureDnsValidation]

The following steps should be used to test that a secureDNS data structure is valid:

  1. Test case -12000: The secureDNS data structure must be a syntactically valid JSON object. 
    {
  "code": -12000,
  "value": "<secureDNS structure>",
  "message": "The domain structure is not syntactically valid."
}
  2. Test case -12001: The name of every name/value pairs shall be zoneSigned, delegationSigned, maxSigLife, dsData or keyData. 
    {
  "code": -12001,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: zoneSigned, delegationSigned, maxSigLife, dsData or keyData."
}
  3. Test case -12002: The JSON name/values of zoneSigned, delegationSigned, maxSigLife, dsData and keyData shall appear only once. 
    {
  "code": -12002,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a domain structure was found more than once."
}
  4. Test case -12003: If the JSON name zoneSigned appears, the value shall be a JSON boolean data type. 
    {
  "code": -12003,
  "value": "<name/value pair>",
  "message": "The JSON value is not a boolean."
}
  5. Test case -12005: If the JSON name delegationSigned appears, the value shall be a JSON boolean data type. 
    {
  "code": -12005,
  "value": "<name/value pair>",
  "message": "The JSON value is not a boolean."
}
  6. Test case -12006: If the JSON name maxSigLife exists, the value shall be a JSON number data type between 1 and 2147483647. 
    {
  "code": -12006,
  "value": "<name/value pair>",
  "message": "The JSON value is not a number between 1 and 2147483647."
}
  7. If the JSON name dsData appears, the value shall pass the following:
    1. Test case -12008: The dsData data structure must be a syntactically valid array of JSON objects. 
      {
  "code": -12008,
  "value": "<dsData structure>",
  "message": "The dsData structure is not syntactically valid."
}
    2. Test case -12009: The name of every name/value pair shall be any of: keyTag, algorithm, digest, digestType, events or links. 
      {
  "code": -12009,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: keyTag, algorithm, digest, digestType, events or links."
}
    3. Test case -12010: The JSON name/values of keyTag, algorithm, digest, digestType, events or links shall appear only once. 
      {
  "code": -12010,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a dsData structure was found more than once."
}
    4. Test case -12011: The JSON name/values of keyTag, algorithm, digest and digestType shall appear. 
      {
  "code": -12011,
  "value": "<dsData structure>",
  "message": "The following name/values shall exist: keyTag, algorithm, digest and digestType."
}
    5. Test case -12012: For the JSON name keyTag, the value shall be a JSON number data type between 1 and 65535. 
      {
  "code": -12012,
  "value": "<name/value pair>",
  "message": "The JSON value is not a number between 1 and 65535."
}
    6. Test case -12013: For the JSON name algorithm, the value shall be a JSON number listed with Zone Signing=Y in dnsSecAlgNumbers. The values 253 and 254 are not valid for this test. 
      {
  "code": -12013,
  "value": "<name/value pair>",
  "message": "The JSON value is not listed with Zone Signing=Y in dnsSecAlgNumbers, or it's 253 or 254."
}
    7. Test case -12014: For the JSON name digest, the value shall be a JSON string of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal text. 
      {
  "code": -12014,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal test."
}
    8. Test case -12015: For the JSON name digestType, the value shall be a JSON number assigned in dsRrTypes. 
      {
  "code": -12015,
  "value": "<name/value pair>",
  "message": "The JSON value is not assigned in dsRrTypes."
}
    9. Test case -12016: If the JSON name events exists, the value shall pass the test Events Validation [stdRdapEventsValidation] defined in this document. 
      {
  "code": -12016,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Events Validation [stdRdapEventsValidation]."
}
    10. Test case -12017: If the JSON name links exists, the value shall pass the test Links validation [stdRdapLinksValidation] defined in this document. 
      {
  "code": -12017,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Links validation [stdRdapLinksValidation]."
}
  8. If the JSON name keyData exists, the value shall pass the following:
    1. Test case -12018: The keyData data structure must be a syntactically valid array of JSON objects. 
      {
  "code": -12018,
  "value": "<keyData structure>",
  "message": "The keyData structure is not syntactically valid."
}
    2. Test case -12019: The name of every name/value pair shall be flags, protocol, publicKey, algorithm, events or links. 
      {
  "code": -12019,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: flags, protocol, publicKey, algorithm, events or links."
}
    3. Test case -12020: The JSON name/values of flags, protocol, publicKey, algorithm, events or links shall appear only once. 
      {
  "code": -12020,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a keyData structure was found more than once."
}
    4. Test case -12021: The JSON name/values of flags, protocol, publicKey and algorithm shall appear. 
      {
  "code": -12021,
  "value": "<dsData structure>",
  "message": "The following name/values shall exist: flags, protocol, publicKey and algorithm."
}
    5. Test case -12022: For the JSON name flags, the value shall be a JSON number data type with values: 256 or 257. 
      {
  "code": -12022,
  "value": "<name/value pair>",
  "message": "The JSON value is not 256 or 257."
}
    6. Test case -12023: For the JSON name protocol, the value shall be a JSON number data type with value: 3. 
      {
  "code": -12023,
  "value": "<name/value pair>",
  "message": "The JSON value is not 3."
}
    7. Test case -12024: For the JSON name publicKey, the value shall be a JSON string, and the key is represented as a Base64. Whitespace is allowed within the text. 
      {
  "code": -12024,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal text."
}
    8. Test case -12025: For the JSON name algorithm, the value shall be a JSON number listed with Zone Signing=Y in dnsSecAlgNumbers. The values 253 and 254 are not valid for this test. 
      {
  "code": -12025,
  "value": "<name/value pair>",
  "message": "The JSON value is not listed with Zone Signing=Y in dnsSecAlgNumbers, or it's 253 or 254."
}
    9. Test case -12026: If the JSON name events exists, the value shall pass the test Events Validation [stdRdapEventsValidation] defined in this document. 
      {
  "code": -12026,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Events Validation [stdRdapEventsValidation]."
}
    10. Test case -12027: If the JSON name links exists, the value shall pass the test Links validation [stdRdapLinksValidation] defined in this document. 
      {
  "code": -12027,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Links validation [stdRdapLinksValidation]."
}

Codes -12004 and -12007 are intentionally omitted.

Error Response Body

Test group: [stdRdapErrorResponseBodyValidation]

The following steps should be used to test that an error data structure is valid:

  1. Test case -12100: The error data structure must be a syntactically valid JSON object. 
    {
  "code": -12100,
  "value": "<error structure>",
  "message": "The error structure is not syntactically valid."
}
  2. Test case -12101: At least the following name/value pairs shall appear: errorCode, title and description. 
    {
  "code": -12101,
  "value": "<name/value pair>",
  "message": "At least the following name/value pairs shall exist: errorCode, title and description."
}
  3. Test case -12102: The JSON name/values of errorCode, title, and description shall appear only once. 
    {
  "code": -12102,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of an error structure was found more than once."
}
  4. Test case -12103: For the JSON name errorCode, the value shall be a JSON number data type. 
    {
  "code": -12103,
  "value": "<name/value pair>",
  "message": "The JSON value is not a number."
}
  5. Test case -12104: For the JSON name title, the value shall be a JSON string data type. 
    {
  "code": -12104,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
  6. Test case -12105: The description data structure must be a syntactically valid JSON array. 
    {
  "code": -12105,
  "value": "<description structure>",
  "message": "The description structure is not syntactically valid."
}
  7. Test case -12106: Every value of the JSON array of the description data structure shall be a JSON string data type. 
    {
  "code": -12106,
  "value": "<JSON value>",
  "message": "The JSON value is not a string."
}
  8. Test case -12107: "errorCode" is required in an error response. 
    {
  "code": -12107,
  "value": "<error structure>",
  "message": "The errorCode value is required in an error response."
}

Object Class Tests

Domain Lookup Validation

Test group: [stdRdapDomainLookupValidation]

The following steps should be used to test that a domain data structure is valid:

  1. Test case -12200: The domain data structure must be a syntactically valid JSON object. 
    {
  "code": -12200,
  "value": "<domain structure>",
  "message": "The domain structure is not syntactically valid."
}
  2. Test case -12201: The name of every name/value pairs shall be any of: objectClassName, handle, ldhName, unicodeName, variants, nameservers, secureDNS, entities, status, publicIds, remarks, links, port43, events, notices or rdapConformance. 
    {
  "code": -12201,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: objectClassName, handle, ldhName, unicodeName, variants, nameservers, secureDNS, entities, status, publicIds, remarks, links, port43, events, notices or rdapConformance."
}
  3. Test case -12202: The JSON name/values of objectClassName, handle, ldhName, unicodeName, variants, nameservers, secureDNS, entities, status, publicIds, remarks, links, port43, events, notices or rdapConformance shall appear only once. 
    {
  "code": -12202,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a domain structure was found more than once."
}
  4. Test case -12203: For the JSON name objectClassName, the value shall be "domain". 
    {
  "code": -12203,
  "value": "<name/value pair>",
  "message": "The JSON value is not 'domain'."
}
  5. Test case -12204: If the JSON name handle exists, the value shall be a JSON string data type. 
    {
  "code": -12204,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
  6. Test case -12205: If the JSON name ldhName, the value shall pass the test LDH name [stdRdapLdhNameValidation] defined in this document. 
    {
  "code": -12205,
  "value": "<name/value pair>",
  "message": " The value for the JSON name value does not pass LDH name [stdRdapLdhNameValidation]."
}
  7. Test case -12206: If the JSON name unicodeName exists, the value shall pass the test Unicode name [stdRdapUnicodeNameValidation] defined in this document. 
    {
  "code": -12206,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Unicode name [stdRdapUnicodeNameValidation]."
}
  8. Test case -12207: If the JSON name variants exists, the value shall pass the test Variants validation [stdRdapVariantsValidation] defined in this document. 
    {
  "code": -12207,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Variants validation [stdRdapVariantsValidation]."
}
  9. Test case -12208: If the JSON name nameservers exists, the value shall pass the test Nameserver lookup validation [stdRdapNameserverLookupValidation] defined in this document. 
    {
  "code": -12208,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Nameserver lookup validation [stdRdapNameserverLookupValidation]."
}
  10. Test case -12209: If the JSON name secureDNS exists, the value shall pass the test Secure DNS validation [stdRdapSecureDnsValidation] defined in this document. 
    {
  "code": -12209,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Secure DNS validation [stdRdapSecureDnsValidation]."
}
  11. Test case -12210: If the JSON name entities exists, the value shall pass the test Entities validation [stdRdapEntitiesValidation] defined in this document. 
    {
  "code": -12210,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Entities validation [stdRdapEntitiesValidation]."
}
  12. Test case -12211: If the JSON name status exists, the value shall pass the test Status validation [stdRdapStatusValidation] defined in this document. 
    {
  "code": -12211,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Status validation [stdRdapStatusValidation]."
}
  13. Test case -12212: If the JSON name publicIds exists, the value shall pass the test Public IDs validation [stdRdapPublicIdsValidation] defined in this document. 
    {
  "code": -12212,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Public IDs validation [stdRdapPublicIdsValidation]."
}
  14. Test case -12213: If the JSON name remarks exists, the value shall pass the test Notices and Remarks Validation [stdRdapNoticesRemarksValidation] defined in this document. 
    {
  "code": -12213,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Notices and Remarks Validation [stdRdapNoticesRemarksValidation]."
}
  15. Test case -12214: If the JSON name links exists, the value shall pass the test Links validation [stdRdapLinksValidation] defined in this document. 
    {
  "code": -12214,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Links validation [stdRdapLinksValidation]."
}
  16. Test case -12215: If the JSON name port43 exists, the value shall pass the test Port 43 WHOIS Server [stdRdapPort43WhoisServerValidation] defined in this document. 
    {
  "code": -12215,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Port 43 WHOIS Server [stdRdapPort43WhoisServerValidation]."
}
  17. Test case -12216: If the JSON name events exists, the value shall pass the test Events Validation [stdRdapEventsValidation] defined in this document. 
    {
  "code": -12216,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Events Validation [stdRdapEventsValidation]."
}
  18. Test case -12217: If the JSON name notices exists, the value shall pass the test Notices and Remarks Validation [stdRdapNoticesRemarksValidation] defined in this document. 
    {
  "code": -12217,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Notices and Remarks Validation [stdRdapNoticesRemarksValidation]."
}
  19. Test case -12218: If the JSON name notices exists and the domain object is not the topmost JSON object. 
    {
  "code": -12218,
  "value": "<name/value pair>",
  "message": "The value for the JSON name notices exists but domain object is not the topmost JSON object."
}
  20. Test case -12219: If the JSON name rdapConformance exists, the value shall pass the test RDAP Conformance validation [stdRdapConformanceValidation] defined in this document. 
    {
  "code": -12219,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass RDAP Conformance validation [stdRdapConformanceValidation]."
}

Entity lookup validation

Test group: [stdRdapEntityLookupValidation]

The following steps should be used to test that an entity data structure is valid:

  1. Test case -12300: The entity data structure must be a syntactically valid JSON object. 
    {
  "code": -12300,
  "value": "<entity structure>",
  "message": "The entity structure is not syntactically valid."
}
  2. Test case -12301: The name of every name/value pairs shall be any of: objectClassName, handle, vcardArray, roles, publicIds, entities, remarks, links, events, asEventActor, status, port43, notices or rdapConformance. 
    {
  "code": -12301,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: objectClassName, handle, vcardArray, roles, publicIds, entities, remarks, links, events, asEventActor, status, port43, notices or rdapConformance."
}
  3. Test case -12302: The JSON name/values of objectClassName, handle, vcardArray, roles, publicIds, entities, remarks, links, events, asEventActor, status, port43, notices or rdapConformance shall exist only once. 
    {
"code": -12302,
"value": "<name/value pair>",
"message": "The name in the name/value pair of a domain structure was found more than once."
}
  4. Test case -12303: For the JSON name objectClassName, the value shall be "entity". 
    {
  "code": -12303,
  "value": "<name/value pair>",
  "message": "The JSON value is not 'entity'."
}
  5. Test case -12304: If the JSON name handle exists, the value shall be a JSON string data type. 
    {
  "code": -12304,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
  6. Test case -12305: If the JSON name title vcardArray exists, the value shall be syntactically valid. 
    {
  "code": -12305,
  "value": "<name/value pair>",
  "message": " The value for the JSON name value is not a syntactically valid vcardArray."
}
  7. Test case -12306: If the JSON name roles exists, the value shall pass the test Roles validation [stdRdapRolesValidation] defined in this document. 
    {
  "code": -12306,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Roles validation [stdRdapRolesValidation]."
}
  8. Test case -12307: If the JSON name publicIds exists, the value shall pass the test Public IDs validation [stdRdapPublicIdsValidation] defined in this document. 
    {
  "code": -12307,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Public IDs validation [stdRdapPublicIdsValidation]."
}
  9. Test case -12308: If the JSON name entities exists, the value shall pass the test Entities validation [stdRdapEntitiesValidation] defined in this document. 
    {
  "code": -12308,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Entities validation [stdRdapEntitiesValidation]."
}
  10. Test case -12309: If the JSON name remarks exists, the value shall pass the test Notices and Remarks Validation [stdRdapNoticesRemarksValidation] defined in this document. 
    {
  "code": -12309,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Notices and Remarks Validation [stdRdapNoticesRemarksValidation]."
}
  11. Test case -12310: If the JSON name links exists, the value shall pass the test Links validation [stdRdapLinksValidation] defined in this document. 
    {
  "code": -12310,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Links validation [stdRdapLinksValidation]."
}
  12. Test case -12311: If the JSON name events exists, the value shall pass the test Events Validation [stdRdapEventsValidation] defined in this document. 
    {
  "code": -12311,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Events Validation [stdRdapEventsValidation]."
}
  13. Test case -12312: If the JSON name asEventActor exists, the value shall pass the test asEventActor Validation [stdRdapAsEventActorValidation] defined in this document. 
    {
  "code": -12312,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass asEventActor Validation [stdRdapAsEventActorValidation]."
}
  14. Test case -12313: If the JSON name status exists, the value shall pass the test Status validation [stdRdapStatusValidation] defined in this document. 
    {
  "code": -12313,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Status validation [stdRdapStatusValidation]."
}
  15. Test case -12314: If the JSON name port43 exists, the value shall pass the test Port 43 WHOIS Server [stdRdapPort43WhoisServerValidation] defined in this document. 
    {
  "code": -12314,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Port 43 WHOIS Server [stdRdapPort43WhoisServerValidation]."
}
  16. Test case -12315: If the JSON name notices exists, the value shall pass the test Notices and Remarks Validation [stdRdapNoticesRemarksValidation] defined in this document. 
    {
  "code": -12315,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Notices and Remarks Validation [stdRdapNoticesRemarksValidation]."
}
  17. Test case -12316: If the JSON name notices exists and the entity object is not the topmost JSON object. 
    {
  "code": -12316,
  "value": "<name/value pair>",
  "message": "The value for the JSON name notices exists but entity object is not the topmost JSON object."
}
  18. Test case -12317: If the JSON name rdapConformance exists, the value shall pass the test RDAP Conformance validation [stdRdapConformanceValidation] defined in this document. 
    {
  "code": -12317,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass RDAP Conformance validation [stdRdapConformanceValidation]."
}

Nameserver lookup validation

Test group: [stdRdapNameserverLookupValidation]

The following steps should be used to test that a nameserver data structure is valid:

  1. Test case -12400: The nameserver data structure must be a syntactically valid JSON object. 
    {
    "code": -12400,
    "value": "<nameserver structure>",
    "message": "The nameserver structure is not syntactically valid."
}
  2. Test case -12401: The name of every name/value pairs shall be any of: objectClassName, handle, ldhName, unicodeName, ipAddresses, entities, status, remarks, links, port43, events, notices or rdapConformance. 
    {
    "code": -12401,
    "value": "<name/value pair>",
    "message": "The name in the name/value pair is not of: objectClassName, handle, ldhName, unicodeName, ipAddresses, entities, status, remarks, links, port43, events, notices or rdapConformance."
}
  3. Test case -12402: The JSON name/values of objectClassName, handle, ldhName, unicodeName, ipAddresses, entities, status, remarks, links, port43, events, notices or rdapConformance shall exist only once. 
    {
  "code": -12402,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a link structure was found more than once."
}
  4. Test case -12403: For the JSON name objectClassName, the value shall be "nameserver". 
    {
  "code": -12403,
  "value": "<name/value pair>",
  "message": "The JSON value is not 'nameserver'."
}
  5. Test case -12404: If the JSON name handle exists, the value shall be a JSON string data type. 
    {
  "code": -12404,
  "value": "<name/value pair>",
  "message": "The JSON value is not a string."
}
  6. Test case -12405: If the JSON name ldhName exists, the value shall pass the test LDH name [stdRdapLdhNameValidation] defined in this document. 
    {
  "code": -12405,
  "value": "<name/value pair>",
  "message": " The value for the JSON name value does not pass LDH name [stdRdapLdhNameValidation]."
}
  7. Test case -12406: If the JSON name unicodeName exists, the value shall pass the test Unicode name [stdRdapUnicodeNameValidation] defined in this document. 
    {
  "code": -12406,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Unicode name [stdRdapUnicodeNameValidation]."
}
  8. Test case -12407: If the JSON name ipAddresses exists, the value shall pass the test IP Addresses Validation [stdRdapIpAddressesValidation] defined in this document. 
    {
  "code": -12407,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass IP Addresses Validation [stdRdapIpAddressesValidation]."
}
  9. Test case -12408: If the JSON name entities exists, the value shall pass the test Entities validation [stdRdapEntitiesValidation] defined in this document. 
    {
  "code": -12408,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Entities validation [stdRdapEntitiesValidation]."
}
  10. Test case -12409: If the JSON name status exists, the value shall pass the test Status validation [stdRdapStatusValidation] defined in this document. 
    {
  "code": -12409,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Status validation [stdRdapStatusValidation]."
}
  11. Test case -12410: If the JSON name remarks exists, the value shall pass the test Notices and Remarks Validation [stdRdapNoticesRemarksValidation] defined in this document. 
    {
  "code": -12410,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Notices and Remarks Validation [stdRdapNoticesRemarksValidation]."
}
  12. Test case -12411: If the JSON name links exists, the value shall pass the test Links validation [stdRdapLinksValidation] defined in this document. 
    {
"code": -12411,
"value": "<name/value pair>",
"message": "The value for the JSON name value does not pass Links validation [stdRdapLinksValidation]."
}
  13. Test case -12412: If the JSON name port43 exists, the value shall pass the test Port 43 WHOIS Server [stdRdapPort43WhoisServerValidation] defined in this document. 
    {
  "code": -12412,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Port 43 WHOIS Server [stdRdapPort43WhoisServerValidation]."
}
  14. Test case -12413: If the JSON name events exists, the value shall pass the test Events Validation [stdRdapEventsValidation] defined in this document. 
    {
  "code": -12413,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Events Validation [stdRdapEventsValidation]."
}
  15. Test case -12414: If the JSON name notices exists, the value shall pass the test Notices and Remarks Validation [stdRdapNoticesRemarksValidation] defined in this document. 
    {
"code": -12414,
"value": "<name/value pair>",
"message": "The value for the JSON name value does not pass Notices and Remarks Validation [stdRdapNoticesRemarksValidation]."
}
  16. Test case -12415: If the JSON name notices exists and the nameserver object is not the topmost JSON object. 
    {
"code": -12415,
"value": "<name/value pair>",
"message": "The value for the JSON name notices exists but nameserver object is not the topmost JSON object."
}
  17. Test case -12416: If the JSON name rdapConformance exists, the value shall pass the test RDAP Conformance validation [stdRdapConformanceValidation] defined in this document. 
    {
  "code": -12416,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass RDAP Conformance validation [stdRdapConformanceValidation]."
}

Help validation

Test group:[stdRdapHelpValidation]

The following steps should be used to test that a help data structure is valid:

  1. Test case -12500: The help data structure must be a syntactically valid JSON object. 
    {
  "code": -12500,
  "value": "<help structure>",
  "message": "The help structure is not syntactically valid."
}
  2. Test case -12501: The name of every name/value pairs shall be notices or rdapConformance. 
    {
  "code": -12501,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: notices or rdapConformance."
}
  3. Test case -12502: The JSON name/values of notices or rdapConformance shall exist only once. 
    {
  "code": -12502,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a link structure was found more than once."
}
  4. Test case -12503: If the JSON name notices exists, the value shall pass the test Notices and Remarks Validation [stdRdapNoticesRemarksValidation] defined in this document. 
    {
  "code": -12503,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Notices and Remarks Validation [stdRdapNoticesRemarksValidation]."
}
  5. Test case -12504: If the JSON name rdapConformance exists, the value shall pass the test RDAP Conformance validation [stdRdapConformanceValidation] defined in this document. 
    {
  "code": -12504,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass RDAP Conformance validation [stdRdapConformanceValidation]."
}

Nameservers search validation

Test group: [stdRdapNameserversSearchValidation]

The following steps should be used to test that a nameserverSearchResults data structure is valid:

  1. Test case -12600: The nameserverSearchResults data structure must be a syntactically valid JSON object. 
    {
  "code": -12600,
  "value": "<nameserver structure>",
  "message": "The nameserver structure is not syntactically valid."
}
  2. Test case -12601: The name of every name/value pairs shall be any of: nameserverSearchResults, remarks, events, notices or rdapConformance. 
    {
  "code": -12601,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair is not of: nameserverSearchResults, remarks, events, notices or rdapConformance."
}
  3. Test case -12602: The JSON name/values of nameserverSearchResults, remarks, events, notices or rdapConformance shall exist only once. 
    {
  "code": -12602,
  "value": "<name/value pair>",
  "message": "The name in the name/value pair of a link structure was found more than once."
}
  4. Test case -12603: The nameserverSearchResults data structure must be a syntactically valid JSON array. 
    {
  "code": -12603,
  "value": "<nameserverSearchResults structure>",
  "message": "The nameserverSearchResults structure is not syntactically valid."
}
  5. For every object (i.e. nameserver) of the JSON array, verify that the nameserverSearchResults structure complies with:
    1. Test case -12604: The object (i.e. nameserver) shall pass the Nameserver lookup validation [stdRdapNameserverLookupValidation] test. 
      {
  "code": -12604,
  "value": "<nameserver object>",
  "message": "The nameserver object does not pass Nameserver lookup validation [stdRdapNameserverLookupValidation]."
}
  6. Test case -12605: If the JSON name remarks exists, the value shall pass the test Notices and Remarks Validation [stdRdapNoticesRemarksValidation] defined in this document. 
    {
  "code": -12605,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Notices and Remarks Validation [stdRdapNoticesRemarksValidation]."
}
  7. Test case -12606: If the JSON name events exists, the value shall pass the test Events Validation [stdRdapEventsValidation] defined in this document. 
    {
  "code": -12606,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Events Validation [stdRdapEventsValidation]."
}
  8. Test case -12607: If the JSON name notices exists, the value shall pass the test Notices and Remarks Validation [stdRdapNoticesRemarksValidation] defined in this document. 
    {
  "code": -12607,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass Notices and Remarks Validation [stdRdapNoticesRemarksValidation]."
}
  9. Test case -12608: If the JSON name notices exists and the object is not the topmost JSON object. 
    {
  "code": -12608,
  "value": "<name/value pair>",
  "message": "The value for the JSON name notices exists but object is not the topmost JSON object."
}
  10. Test case -12609: If the JSON name rdapConformance exists, the value shall pass the test RDAP Conformance validation [stdRdapConformanceValidation] defined in this document. 
    {
  "code": -12609,
  "value": "<name/value pair>",
  "message": "The value for the JSON name value does not pass RDAP Conformance validation [stdRdapConformanceValidation]."
}
  11. Test case -12610: The nameserverSearchResults value must exist. 
    {
  "code": -12610,
  "value": "<response>",
  "message": "The nameserverSearchResults structure is required."
}

Response Tests

Test group: [stdResponseValidation]

  1. Test case -13000: Validate that the content-type HTTP header has the media type “application/rdap+json”. This validation should allow for media type parameters such as “charset”, etc… 
    {
  "code": -13000,
  "value": "<content-type header>",
  "message": "The content-type header does not contain the application/rdap+json media type."
}
    See Media Types in the conformance considerations for more information.
  2. Test case -13001: Validate that the response is parsable JSON. 
    {
  "code": -13001,
  "value": "response body not given",
  "message": "The response was not valid JSON."
}
  3. Test case -13002: Validate that the HTTP status code is either 200 or 404. 
    {
  "code": -13002,
  "value": "<HTTP status code>",
  "message": "The HTTP status code was not 200 nor 404."
}
  4. Test case -13003: If the query is a lookup (/domain, /ip, /nameserver, /autnum, /entity), validate that it has an objectClassName string member. 
    {
  "code": -13003,
  "value": "<response>",
  "message": "The response does not have an objectClassName string."
}
  5. Test case -13004: Validate that a query for “example.invalid” with random query parameters does not result in an HTTP 3xx response in which the URI in the “location” header contains the same query parameters used in the query. 
    {
  "code": -13004,
  "value": "<location header value>",
  "message": "Response redirect contained query parameters copied from the request."
}
  6. Test case -13005: Validate that a query for “test.invalid” does not result in an HTTP redirect (that is, if the server answers with a 3xx validate that the redirect does not point back to the same server). 
    {
  "code": -13005,
  "value": "<location header value>",
  "message": "Server responded with a redirect to itself for domain 'test.invalid'."
}
  7. Test case -13006: Validate that a query for “test.invalid” does not result in an HTTP 200 Ok. 
    {
  "code": -13006,
  "value": "<response body>",
  "message": "Server responded with a 200 Ok for 'test.invalid'."
}
  8. Test case -13007: If a query fails to connect (CONNECTION FAILED), issue the following error: 
    {
  "code": -13007,
  "value": "no response available",
  "message": "Failed to connect to server."
}
  9. Test case -13008: If a query fails because of a TLS handshake (HANDSHAKE_FAILED), issue the following error: 
    {
  "code": -13008,
  "value": "no response available",
  "message": "TLS handshake failed."
}
  10. Test case -13009: If a query fails to connect because of an invalid TLS certificate (INVALID_CERTIFICATE), issue the following error: 
    {
  "code": -13009,
  "value": "no response available",
  "message": "Invalid TLS certificate."
}
  11. Test case -13010: If a query fails to connect because of revoked TLS certificate (REVOKED_CERTIFICATE), issue the following error: 
    {
  "code": -13010,
  "value": "no response available",
  "message": "Revoked TLS certificate."
}
  12. Test case -13011: If a query fails to connect because of an expired TLS certificate (EXPIRED_CERTIFICATE), issue the following error: 
    {
  "code": -13011,
  "value": "no response available",
  "message": "Expired certificate."
}
  13. Test case -13012: If a query fails to connect because of TLS certificate errors, issue the following error: 
    {
  "code": -13012,
  "value": "no response available",
  "message": "TLS certificate error."
}
  14. Test case -13013: If a query fails to connect because of too many HTTP redirects (TOO_MANY_REDIRECTS), issue the following error: 
    {
  "code": -13013,
  "value": "no response available",
  "message": "Too many HTTP redirects."
}
  15. Test case -13014: If a query fails because of an HTTP error (HTTP_ERROR), issue the following error: 
    {
  "code": -13014,
  "value": "no response available",
  "message": "HTTP error."
}
  16. Test case -13015: If a query fails because of an HTTP2 error (HTTP2_ERROR), issue the following error: 
    {
  "code": -13015,
  "value": "no response available",
  "message": "HTTP2 error."
}
  17. Test case -13016: If a query fails because data failed to be sent on the network (NETWORK_SEND_FAIL), issue the following error: 
    {
  "code": -13016,
  "value": "no response available",
  "message": "Network send fail."
}
  18. Test case -13017: If a query fails because data failed to be received on the network (NETWORK_RECEIVE_ERROR), issue the following error: 
    {
  "code": -13017,
  "value": "no response available",
  "message": "Network receive fail."
}
  19. Test case -13018: Validate that all queries issued over all IP protocols for all HTTP methods except queries for domains under .invalid (see codes -130004, -13005, -130006, and -65300) have the same HTTP status code. 
    {
  "code": -13018,
  "value": "<array of tuples composed of validation codes and status code>",
  "message": "Queries do not produce the same HTTP status code."
}
  20. Test case -13019: If a query fails because the DNS resolution process does not yield an IP address, issue the following error. 
    {
  "code": -13019,
  "value": "<host name>",
  "message": "Unable to resolve an IP address endpoint using DNS."
}

  21. Test case -13020: If the input URL (that is, the URL given by the user for executing this tool) returns an HTTP 404 status code for both a GET request and a HEAD request, if applicable because a gTLD profile has been selected, and no other validations are given in the error array, then this validation should appear only in the WARNING array. 

    {
  "code": -13020,
  "value": "<URL>",
  "message": "This URL returned an HTTP 404 status code that was validly formed. If the provided URL does not reference a registered resource, then this warning may be ignored. If the provided URL does reference a registered resource, then this should be considered an error."
}
    If the provided URL does not reference a registered resource, then this warning may be ignored. If the provided URL does reference a registered resource, then this should be considered an error.

  22. Test case -13021: If the input URL results in a refused connection, then issue the following error: 

    {
  "code": -13021,
  "value": "<URL>",
  "message": "Connection refused by host."
}

2019 gTLD profile Tests

Technical Implemenation Guide

General Tests

TIG Section 1.2

Test group: [tigSection_1_2_Validation]

The following steps should be used to test the RDAP protocol section 1.2 of the RDAP_Technical_Implementation_Guide_2_1:

  1. Test case -20100: If the scheme of the URI to be tested is "http": 
    {
  "code": -20100,
  "value": "<URI>",
  "message": "The URL is HTTP, per section 1.2 of the RDAP_Technical_Implementation_Guide_2_1 shall be HTTPS only."
}
    See the HTTP URLs conformance consideration for further information.
  2. Test case -20101: If the scheme of the URI to be tested is "https", perform the same RDAP query using "http". If the HTTP URI provides a response (other than redirect):: 
    {
  "code": -20101,
  "value": "<RDAP response provided over HTTP> + '\n/\n' + <RDAP response provided over HTTPS>",
  "message": "The RDAP response was provided over HTTP, per section 1.2 of the RDAP_Technical_Implementation_Guide_2_1 shall be HTTPS only."
}
    See the HTTP to HTTPS Redirects conformance consideration for further information.

Note: If redirects are present, the test [tigSection_1_2_Validation] shall be performed on the URL on the last HTTP redirect.

TIG Section 1.3

Test group: [tigSection_1_3_Validation]

The following steps should be used to test the RDAP protocol section 1.3 of the RDAP_Technical_Implementation_Guide_2_1:

  1. Test case -20200: If the scheme of the URI to be tested is "https", verify that SSLv2 and SSLv3 are not offered by the RDAP server. 
    {
  "code": -20200,
  "value": "<URI>",
  "message": "The RDAP server is offering SSLv2 and/or SSLv3."
}

Note: the test [tigSection_1_3_Validation] shall be performed on the URL on every HTTP redirect.

TIG Section 1.6

Test group: [tigSection_1_6_Validation]

The following steps should be used to test the RDAP protocol section 1.6 of the RDAP_Technical_Implementation_Guide_2_1:

  1. Test case -20300: The tool shall use the HTTP HEAD method on the URI to be tested. If the HTTP Status code is different from the status code obtained when doing the GET method: 
    {
  "code": -20300,
  "value": "<HTTP Status code when using the GET method> + '\n/\n' + <HTTP Status code when using the HEAD method>",
  "message": "The HTTP Status code obtained when using the HEAD method is different from the GET method. See section 1.6 of the RDAP_Technical_Implementation_Guide_2_1."
}

TIG Section 1.8

Test group: [tigSection_1_8_Validation]

The following steps should be used to test the RDAP protocol section 1.8 of the RDAP_Technical_Implementation_Guide_2_1:

  1. Test case -20400: Obtain the Resource Record for the A QTYPE for the host in the URI. Validate that the status of the DNS response is not NOERROR. Validate that all IPv4 addresses in the RDATA pass IPv4 address validation [ipv4Validation]: 
    {
  "code": -20400,
  "value": "<IPv4 addresses>",
  "message": "No IPv4 address records (A) could be resolved in DNS for this service. See section 1.8 of the RDAP_Technical_Implementation_Guide_2_1."
}
  2. Test case -20401: Obtain the Resource Record for the AAAA QTYPE for the host in the URI. Validate that the status of the DNS response is not NOERROR. Validate that all IPv6 addresses in the RDATA pass IPv6 address validation [ipv6Validation]: 
    {
  "code": -20401,
  "value": "<IPv6 addresses>",
  "message": "No IPv6 address records (AAAA) could be resolved in DNS for this service. See section 1.8 of the RDAP_Technical_Implementation_Guide_2_1."
}

Note: the test [tigSection_1_8_Validation] shall be performed on the URL on every HTTP redirect.

TIG Section 1.13

Test group: [tigSection_1_13_Validation]

The following steps should be used to test the RDAP protocol section 1.13 of the RDAP_Technical_Implementation_Guide_2_1:

  1. Test case -20500: Validate that the HTTP header "Access-Control-Allow-Origin: *" is included in the RDAP response. 
    {
  "code": -20500,
  "value": "<HTTP headers>",
  "message": "The HTTP header 'Access-Control-Allow-Origin: *' is not included in the HTTP headers. See section 1.13 of the RDAP_Technical_Implementation_Guide_2_1."
}
    See the CORS (Access-Control-Allow-Origin) conformance consideration for more information.

Note: the test [tigSection_1_13_Validation] shall be performed on the URL on every HTTP redirect.

TIG Section 1.14

Test group: [tigSection_1_14_Validation]

The following steps should be used to test the RDAP protocol section 1.14 of the RDAP_Technical_Implementation_Guide_2_1:

  1. Test case -20600: Validate that the JSON string value "icann_rdap_technical_implementation_guide_0" is included in the RDAP Conformance data structure. 
    {
  "code": -20600,
  "value": "<rdapConformance data structure>",
  "message": "The RDAP Conformance data structure does not include icann_rdap_technical_implementation_guide_0. See section 1.14 of the RDAP_Technical_Implementation_Guide_2_1."
}

TIG Section 3.3 and 3.4

Test group: [tigSection_3_3_and_3_4_Validation]

The following steps should be used to test the RDAP protocol section 3.3 and 3.4 of the RDAP_Technical_Implementation_Guide_2_1:

  1. Test case -20700: Validate that at least one links data structure exists within the notices object in the topmost object. 
    {
  "code": -20700,
  "value": "<notices data structure>",
  "message": "A links object was not found in the notices object in the topmost object. See section 3.3 and 3.4 of the RDAP_Technical_Implementation_Guide_2_1."
}

TIG Section 4.1

Test group: [tigSection_4_1_Validation]

The following steps should be used to test the RDAP protocol section 4.1 of the TIG:

  1. Test case -20800: Validate that all the entities in the RDAP Response contain structured address. If a street address has more than one line, it MUST be structured as an array of strings. 
    {
  "code": -20800,
  "value": "<entity data structure>",
  "message": "An entity with a non-structured address was found. See section 4.1 of the TIG."
}

TIG Section 7.1 and 7.2

Test group: [tigSection_7_1_and_7_2_Validation]

The following steps should be used to test the RDAP protocol section 7. 1 and 7. 2 of the TIG:

  1. Test case -20900: Validate that at all the tel properties in the entities in the RDAP Response contain voice or fax as type parameter. 
    {
  "code": -20900,
  "value": "<entity data structure>",
  "message": "An entity with a tel property without a voice or fax type was found. See section 7.1 and 7.2 of the TIG."
}

Registry Tests

TIG Section 1.11.1

Test group: [tigSection_1_11_1_Validation]

The following steps should be used to test the RDAP protocol section 1.11.1 and 1.2 of the RDAP_Technical_Implementation_Guide_2_1:

  1. Test case -23100: Verify that the TLD of the domain name is listed in the bootstrapDomainNameSpace. 
    {
  "code": -23100,
  "value": "<TLD> + '\n/\n' <bootstrapDomainNameSpace>",
  "message": "The TLD is not included in the bootstrapDomainNameSpace. See section 1.11.1 of the RDAP_Technical_Implementation_Guide_2_1."
}
  2. Test case -23101: Validate that at least one base URL exists in the bootstrapDomainNameSpace for the TLD. 
    {
  "code": -23101,
  "value": "<TLD element in bootstrapDomainNameSpace>",
  "message": "The TLD entry in bootstrapDomainNameSpace does not contain a base URL. See section 1.11.1 of the RDAP_Technical_Implementation_Guide_2_1."
}
  3. Test case -23102: For the entry of the TLD in bootstrapDomainNameSpace verify that every one of the base URLs contain a schema of "https". 
    {
  "code": -23102,
  "value": "<TLD entry in bootstrapDomainNameSpace>",
  "message": "One or more of the base URLs for the TLD contain a schema different from https. See section 1.2 of the RDAP_Technical_Implementation_Guide_2_1."
}

TIG Section 3.2

Test group: [tigSection_3_2_Validation]

The following steps should be used to test the RDAP protocol section 3.2 of the RDAP_Technical_Implementation_Guide_2_1:

  1. Test case -23200: If the query is a gTLD Registry (i.e. --gtld-registry) and Public ID identifier of the registrar is not “9999”, validate that a links data structure in the topmost object exists, and the links object shall contain the elements rel :related and href. 
    {
  "code": -23200,
  "value": "<links data structure>",
  "message": "A links data structure in the topmost object exists, and the links object shall contain the elements rel:related and href, but they were not found. See section 3.2 of the RDAP_Technical_Implementation_Guide_2_1."
}

TIG Section 6.1

Test group: [tigSection_6_1_Validation]

The following steps should be used to test the RDAP protocol section 6.1 of the RDAP_Technical_Implementation_Guide_2_1:

  1. Test case -23300: For the entity with the registrar role within the domain object, validate that a publicIds member is included. 
    {
  "code": -23300,
  "value": "<entity data structure>",
  "message": "A publicIds member is not included in the entity with the registrar role."
}
  2. Test case -23301: For the entity with the registrar role within the domain object, if a publicIds member is included, validate that the identifier member is a positive integer. 
    {
  "code": -23301,
  "value": "<publicIds data structure>",
  "message": "The identifier of the publicIds member of the entity with the registrar role is not a positive integer."
}

Registrar Tests

TIG Section 1.12.1

Test group: [tigSection_1_12_1_Validation]

The following steps should be used to test the RDAP protocol section 1.12.1 of the RDAP_Technical_Implementation_Guide_2_1:

  1. Test case -26100: Get the identifier in the publicIds element in the entity with the registrar role. 
    {
  "code": -26100,
  "value": "<publicIds data structure>",
  "message": "An identifier in the publicIds within the entity data structure with the registrar role was not found. See section 1.12.1 of the RDAP_Technical_Implementation_Guide_2_1."
}
  2. Test case -26101: For the identifier found in the previous step, validate that an entry exists in the registrarId. 
    {
  "code": -26101,
  "value": "<identifier> '\n/\n' <registrarId>",
  "message": "The registrar identifier is not included in the registrarId. See section 1.12.1 of the RDAP_Technical_Implementation_Guide_2_1."
}
  3. Test case -26102: For the identifier found in the previous step, verify that every of the base URLs contain a schema of "https". 
    {
  "code": -26102,
  "value": "<Registrar entry in registrarId>",
  "message": "One or more of the base URLs for the registrar contain a schema different from https. See section 1.2 of the RDAP_Technical_Implementation_Guide_2_1."
}

Response Profile

General Tests

RP Section 1.2.2

Test group: [rdapResponseProfile_1_2_2_Validation]

The following steps should be used to test the RDAP protocol section 1.2.2 of the RDAP Response Profile 2.1:

  1. Test case -40100: Validate that the RDAP response does not contain browser executable code (e.g., JavaScript). 
    {
  "code": -40100,
  "value": "<rdap response>",
  "message": "The RDAP response contains browser executable code (e.g., JavaScript). See section 1.2.2 of the RDAP_Response_Profile_2_1."
}

RP Section 1.3

Test group: [rdapResponseProfile_1_3_Validation]

The following steps should be used to test the RDAP protocol section 1.3 of the RDAP Response Profile 2.1:

  1. Test case -40200: Validate that the JSON string value "icann_rdap_response_profile_0" is included in the RDAP Conformance data structure. 
    {
  "code": -40200,
  "value": "<rdapConformance data structure>",
  "message": "The RDAP Conformance data structure does not include icann_rdap_response_profile_0. See section 1.3 of the RDAP_Response_Profile_2_1."
}

RP Section 1.4

Test group: [rdapResponseProfile_1_4_Validation]

The following steps should be used to test the RDAP protocol section 1. 4 of the RDAP Response Profile 2.1:

  1. Test case -40400: Validate that the country name parameter is empty in the adr of all the jCard objects in the RDAP response. 
    {
  "code": -40400,
  "value": "<vcard object>",
  "message": "A vcard object with a country name parameter with data was found. "
}
    See Registrant Without CC Parameter in the conformance considerations for more information.

Miscellaneous Tests

Test Group: [rdapResponseProfile_2_3_1_3_and_2_7_6_and_3_3_and_4_4_Validation]

The following steps should be used to test the RDAP protocol section 2.3.1.3, 2.7.6, 3.3 and 4.4 of the RDAP Response Profile 2.1:

  1. Test case -43100: Validate that an eventAction type "last update of RDAP database" exists in events structure included in the topmost object. 
    {
  "code": -43100,
  "value": "<events data structure>",
  "message": "An eventAction type last update of RDAP database does not exists in the topmost events data structure. See section 2.3.1.3, 2.7.6, 3.3 and 4.4 of the RDAP_Response_Profile_2_1."
}

Domain Tests

RP Section 2.1

Test group: [rdapResponseProfile_2_1_Validation]

The following steps should be used to test the RDAP protocol section 2.1 of the RDAP Response Profile 2.1.

  1. Test case -46100: If domain/ in the RDAP Query URI contains only A-label or NR-LDH labels, the topmost domain object shall contain a ldhName. 
    {
  "code": -46100,
  "value": "<domain object>",
  "message": "The RDAP Query URI contains only A-label or NR-LDH labels, the topmost domain object does not contain a ldhName member. See section 2.1 of the RDAP_Response_Profile_2_1."
}
  2. Test case -46101: If domain/ in the RDAP Query URI contains one or more U-label, the topmost domain object shall contain an unicodeName. 
    {
  "code": -46101,
  "value": "<domain object>",
  "message": " The RDAP Query URI contains one or more U-label, the topmost domain object does not contain a unicodeName member. See section 2.1 of the RDAP_Response_Profile_2_1."
}

RP Section 2.2

Test group: [rdapResponseProfile_2_2_Validation]

The following steps should be used to test the RDAP protocol section 2.2 of the RDAP Response Profile 2.1:

  1. Test case -46200: The handle in the topmost domain object shall comply with the following format specified in RFC5730: "(\w|_){1,80}-\w{1,8}". 
    {
  "code": -46200,
  "value": "<domain object>",
  "message": "The handle in the domain object does not comply with the format (\\w|_){1,80}-\\w{1,8} specified in RFC5730."
}
  2. Test case -46201: If the handle in the topmost domain object comply with the format: "(\w|_){1,80}-\w{1,8}", validate that the string followed by a hyphen ("-", ASCII value 0x002D) is registered in EPPROID. 
    {
  "code": -46201,
  "value": "<domain object>",
  "message": "The globally unique identifier in the domain object handle is not registered in EPPROID."
}
  3. Test case -46205", validate that the string followed by a hyphen ("-", ASCII value 0x002D) is not “ICANNRST”. 
    {
  "code": -46205,
  "value": "<domain object>",
  "message": "The globally unique identifier in the domain object handle is using an EPPROID reserved for testing by ICANN."
}
    }: If the handle in the topmost domain object comply with the format: "(\w|_){1,80}-\w{1,8

RP Section 2.3.1.1

Test group: [rdapResponseProfile_2_3_1_1_Validation]

The following steps should be used to test the RDAP protocol section 2.3.1.1 of the RDAP Response Profile 2.1:

  1. Test case -46300: Validate that an eventAction of type "registration" exists in the topmost events structure. 
    {
  "code": -46300,
  "value": "<events data structure>",
  "message": "An eventAction of type registration does not exists in the topmost events data structure. See section 2.3.1.1 of the RDAP_Response_Profile_2_1."
}

RP Section 2.3.1.2

Test group: [rdapResponseProfile_2_3_1_2_Validation]

The following steps should be used to test the RDAP protocol section 2.3.1.2 of the RDAP Response Profile 2.1:

  1. Test case -46400: Validate that an eventAction type "expiration" exists in the topmost events structure. 
    {
  "code": -46400,
  "value": "<events data structure>",
  "message": "An eventAction of type expiration does not exist in the topmost events data structure. See section 2.3.1.2 of the RDAP_Response_Profile_2_1."
}

Required Notices

Test group: [rdapResponseProfile_notices_included_Validation]

The following steps should be used to test that a notices member appear in the RDAP response:

  1. Test case -46500: Validate that a notices member appears in the RDAP response. 
    {
  "code": -46500,
  "value": "<RDAP response>",
  "message": "A notices members does not appear in the RDAP response."
}

RP Section 2.6.3

Test group: [rdapResponseProfile_2_6_3_Validation]

The following steps should be used to test the RDAP protocol section 2.6.3 of the RDAP Response Profile 2.1:

  1. Test case -46600: Validate that the notices member contains an element in the JSON array with a title “Status Codes”, a description containing the string “For more information on domain status codes, please visit https://icann.org/epp” and a links member with an href containing "https://icann.org/epp". 
    {
  "code": -46600,
  "value": "<notices structure>",
  "message": "The notice for https://icann.org/epp was not found."
}
    See Notice of EPP Status Codes in the conformance considerations for more information.

RP Section 2.11

Test group: [rdapResponseProfile_2_11_Validation]

The following steps should be used to test the RDAP protocol section 2.11 of the RDAP Response Profile 2.1:

  1. Test case -46700: Validate that the notices member contains an element in the JSON array with a title “RDDS Inaccuracy Complaint Form”, a description containing the string “URL of the ICANN RDDS Inaccuracy Complaint Form: https://icann.org/wicf” and a links member with an href containing "https://icann.org/wicf". 
    {
  "code": -46700,
  "value": "<notices structure>",
  "message": "The notice for https://icann.org/wicf was not found."
}
    See Notice of RDDS Inaccuracy Report in the conformance considerations for more information.
  2. Test case -65300: Validate that the query “/domain/not-a-domain.invalid” yields an HTTP status code of 404. 
    {
  "code": -65300,
  "value": "<http status code>",
  "message": "A query for an invalid domain name did not yield a 404 response."
}

RP Section 2.10

Test group: [rdapResponseProfile_2_10_Validation]

The following steps should be used to test the RDAP protocol section 2.10 of the RDAP Response Profile 2.1:

  1. Test case -46800: Validate that a secureDNS member is included in the domain object. 
    {
  "code": -46800,
  "value": "<domain object>",
  "message": "A secureDNS member does not appear in the domain object."
}
  2. Test case -46801: The JSON name delegationSigned shall appear. 
    {
    "code": -46801,
    "value": "<secureDNS structure>",
    "message": "The delegationSigned element does not exist."
}
  3. Test case -46802: If delegationSigned has a value of true, one dsData name/values or one keyData name/value shall appear. 
    {
  "code": -46802,
  "value": "<secureDNS structure>",
  "message": "delegationSigned value is true, but no dsData nor keyData name/value pair exists."
}

RFC 5731 Validation

Test group: [rdapResponseProfile_rfc5731_Validation]

The following steps should be used to test that the status values comply with RFC5731:

  1. Test case -46900: Validate that the values of the status member in the topmost object comply with the following:
    1. "active" status MUST NOT be combined with any other status.
    2. "pending delete" status MUST NOT be combined with either "client delete prohibited" or "server delete prohibited" status.
    3. "pending renew" status MUST NOT be combined with either "client renew prohibited" or "server renew prohibited" status.
    4. "pending transfer" status MUST NOT be combined with either "client transfer prohibited" or "server transfer prohibited" status.
    5. "pending update" status MUST NOT be combined with either "client update prohibited" or "server update prohibited" status.
    6. The "pending create", "pending delete", "pending renew", "pending transfer", and "pending update" status values MUST NOT be combined with each other. 
      {
  "code": -46900,
  "value": "<status data structure>",
  "message": "The values of the status data structure does not comply with RFC5731."
}

RFC 3915 Validation

Test group: [rdapResponseProfile_rfc3915_Validation]

The following steps should be used to test that the status values comply with RFC3915:

  1. Test case -47000 -- DEPRECATED, SEE 47001 and 47002: Validate that the values of the status member in the topmost object comply with the following:
    1. "redemption period" status MUST only be combined with "pending delete".
    2. "pending restore" status MUST only be combined with "pending delete". 
      {
  "code": -47000,
  "value": "<status data structure>",
  "message": "The values of the status data structure does not comply with RFC3915."
}
  2. Test case -47001: If the topmost object is a domain, validate that if the “status” member has the value “redemption period” only if it also has the value “pending delete”. 
    {
  "code": -47001,
  "value": "<status data structure>",
  "message": "'redemption period' is only valid with a status of 'pending delete'"
}
  3. Test case -47002: If the topmost object is a domain, validate that if the “status” member has the value “pending restore” only if it also has the value “pending delete”. 
    {
  "code": -47002,
  "value": "<status data structure>",
  "message": "'pending restore' is only valid with a status of 'pending delete'"
}

RP Section 2.6.1

Test group: [rdapResponseProfile_2_6_1_Validation]

The following steps should be used to test the RDAP protocol section 2.6.1 of the RDAP Response Profile 2.1:

  1. Test case -47100: Validate that a status member in the topmost object contain at least one value. 
    {
  "code": -47100,
  "value": "<status data structure>",
  "message": "The status member does not contain at least one value."
}

RP Section 2.9.1 and 2.9.2

Test group: [rdapResponseProfile_2_9_1_and_2_9_2_Validation]

The following steps should be used to test the RDAP protocol section 2.9.1 and 2.9.2 of the RDAP Response Profile 2.1:

  1. Test case -47200: If the nameservers member is included within the domain object, validate that all nameserver objects contain the ldhName element. 
    {
  "code": -47200,
  "value": "<nameservers data structure>",
  "message": "A nameserver object without ldhName was found."
}
  2. Test case -47201: If the nameservers member is included within the domain object, validate that all handles in the nameserver objects comply with the following format specified in RFC5730: "(\w|_){1,80}-\w{1,8}". 
    {
  "code": -47201,
  "value": "<nameserver object>",
  "message": "The handle in the nameserver object does not comply with the format (\\w|_){1,80}-\\w{1,8} specified in RFC5730."
}
  3. Test case -47202: If the nameservers member is included within the domain object, validate that the string followed by a hyphen ("-", ASCII value 0x002D) is registered in EPPROID for all the handles that comply with the format "(\w|_){1,80}-\w{1,8}". 
    {
  "code": -47202,
  "value": "<nameserver object>",
  "message": "The globally unique identifier in the nameserver object handle is not registered in EPPROID."
}
  4. Test case -47203: If the nameservers member is included within the domain object AND THE QUERY IS TO A GLTD REGISTRAR (i.e. --gtld-registrar option) and at least one nameserver object contains a handle or a status element, validate that all nameserver objects include a handle and a status element. 
    {
  "code": -47203,
  "value": "<nameserver object>",
  "message": "The handle or status in the nameserver object is not included."
}
  5. Test case -47204: If the nameservers member is included within the domain object, validate that all status elements included in the nameserver objects comply with the following:
    1. "active" status MAY only be combined with "associated" status.
    2. "associated" status MAY be combined with any status.
    3. "pending delete" status MUST NOT be combined with either "client delete prohibited" or "server delete prohibited" status.
    4. "pending update" status MUST NOT be combined with either "client update prohibited" or "server update prohibited" status.
    5. The pending create, pending delete, pending renew, pending transfer, and pending update status values MUST NOT be combined with each other. 
      {
  "code": -47204,
  "value": "<status data structure>",
  "message": "The values of the status data structure does not comply with RFC5732."
}
  6. Test case -47205: If the nameservers member is included within the domain object, validate that the handle is a string followed by a hyphen ("-", ASCII value 0x002D) is not “ICANNRST”. 
    {
  "code": -47205,
  "value": "<nameserver object>",
  "message": "The globally unique identifier in the nameserver object handle is using an EPPROID reserved for testing by ICANN."
}

RP Section 2.4.1

Test group: [rdapResponseProfile_2_4_1_Validation]

The following steps should be used to test the RDAP protocol section 2. 4 .1 of the RDAP Response Profile 2.1:

  1. Test case -47300: An entity with the registrar role within the topmost domain object shall exist. 
    {
  "code": -47300,
  "value": "<domain object data structure>",
  "message": "An entity with the registrar role was not found in the domain topmost object."
}
  2. Test case -47301: Only one entity with the registrar role within the topmost domain object shall exist. 
    {
  "code": -47301,
  "value": "<domain object data structure>",
  "message": "More than one entities with the registrar role were found in the domain topmost object."
}
  3. Test case -47302: For the entity with the registrar role within the topmost domain object, validate that a fn member is included in all of the vcard objects. 
    {
"code": -47302,
"value": "<entity data structure>",
"message": "An fn member was not found in one or more vcard objects of the entity with the registrar role."
}

RP Section 2.4.2 and 2.4.3

Test group: [rdapResponseProfile_2_4_2_and_2_4_3_Validation]

The following steps should be used to test the RDAP protocol section 2. 4. 2 and 2.4.3 of the RDAP Response Profile 2.1:

  1. Test case -47400: For the entity with the registrar role within the topmost object, validate that a publicIds member is included. 
    {
  "code": -47400,
  "value": "<entity data structure>",
  "message": "A publicIds member is not included in the entity with the registrar role."
}
  2. Test case -47401: For the entity with the registrar role within the domain object, if a publicIds member is included, validate that the identifier member is a positive integer. 
    {
  "code": -47401,
  "value": "<publicIds data structure>",
  "message": "The identifier of the publicIds member of the entity with the registrar role is not a positive integer."
}
  3. Test case -47402: For the entity with the registrar role within the domain object, validate that the handle member is a positive integer. 
    {
  "code": -47402,
  "value": "<publicIds data structure>",
  "message": "The handle of the entity with the registrar role is not a positive integer."
}
  4. Test case -47403: For the entity with the registrar role within the domain object, if a publicIds member is included, validate that the identifier member equals the handle member. 
    {
  "code": -47403,
  "value": "<entity data structure>",
  "message": "The identifier of the publicIds member of the entity with the registrar role is not equal to the handle member."
}
  5. Test case -47404: For the entity with the registrar role within the domain object, validate that the value of the handle member exists in the registrarId. 
    {
  "code": -47404,
  "value": "<handle> + \n\n + <registrarId>",
  "message": "The handle references an IANA Registrar ID that does not exist in the **registrarId** ."
}

RP Section 2.4.5

Test group: [rdapResponseProfile_2_4_5_Validation]

  1. Test case -47500: For the entity with the registrar role within the domain object, validate that an entity with the abuse role is included, and the entity with the abuse role includes a tel and email members in all the vcard objects. 
    {
  "code": -47500,
  "value": "<entity data structure>",
  "message": "Tel and email members were not found for the entity within the entity with the abuse role in the topmost domain object."
}

Nameserver Tests

RP Section 4.1

Test group: [rdapResponseProfile_4_1_Validation]

The following steps should be used to test the RDAP protocol section 4 .1 of the RDAP Response Profile 2.1:

  1. Test case -49100: If nameserver/ in the RDAP Query URI contains only A-label or NR- LDH labels, the topmost domain object shall contain a ldhName. 
    {
  "code": -49100,
  "value": "<nameserver object>",
  "message": "The RDAP Query URI contains only A-label or NR-LDH labels, the topmost nameserver object does not contain a ldhName member. See section 2.1 of the RDAP_Response_Profile_2_1."
}
  2. Test case -49101: If nameserver/ in the RDAP Query URI contains one or more U- label, the topmost domain object shall contain an unicodeName. 
    {
  "code": -49101,
  "value": "<nameserver object>",
  "message": " The RDAP Query URI contains one or more U-label, the topmost nameserver object does not contain a unicodeName member. See section 2.1 of the RDAP_Response_Profile_2_1."
}
  3. Test case -49102: The handle in the topmost nameserver object shall comply with the following format specified in RFC5730: "(\w|_){1,80}-\w{1,8}". 
    {
  "code": -49102,
  "value": "<nameserver object>",
  "message": "The handle in the nameserver object does not comply with the format (\\w|_){1,80}-\\w{1,8} specified in RFC5730."
}
  4. Test case -49103: If the handle in the topmost nameserver object comply with the format: "(\w|_){1,80}- \w{1,8}", validate that the string followed by a hyphen ("-", ASCII value 0x002D) is registered in EPPROID. 
    {
  "code": -49103,
  "value": "<nameserver object>",
  "message": "The globally unique identifier in the nameserver object handle is not registered in EPPROID."
}
  5. Test case -49104: If the handle in the topmost nameserver object comply with the format: "(\w|_){1,80}-\w{1,8}", validate that the string followed by a hyphen ("-", ASCII value 0x002D) is not “ICANNRST”. 
    {
  "code": -49104,
  "value": "<nameserver object>",
  "message": "The globally unique identifier in the nameserver object handle is using an EPPROID reserved for testing by ICANN."
}

RP Section 4.3

Test group: [rdapResponseProfile_4_3_Validation]

The following steps should be used to test the RDAP protocol section 4. 3 of the RDAP Response Profile 2.1.

The following steps shall only be executed if an entity with the registrar role exists within the topmost object, and the handle is different from "not applicable":

  1. Test case -49200: For the entity with the registrar role within the topmost object, validate that a publicIds member is included. 
    {
  "code": -49200,
  "value": "<entity data structure>",
  "message": "A publicIds member is not included in the entity with the registrar role."
}
  2. Test case -49201: For the entity with the registrar role within the domain object, if a publicIds member is included, validate that the identifier member is a positive integer. 
    {
  "code": -49201,
  "value": "<publicIds data structure>",
  "message": "The identifier of the publicIds member of the entity with the registrar role is not a positive integer."
}
  3. Test case -49202: For the entity with the registrar role within the domain object, validate that the handle member is a positive integer. 
    {
  "code": -49202,
  "value": "<publicIds data structure>",
  "message": "The handle of the entity with the registrar role is not a positive integer."
}
  4. Test case -49203: For the entity with the registrar role within the domain object, if a publicIds member is included, validate that the identifier member equals the handle member. 
    {
  "code": -49203,
  "value": "<entity data structure>",
  "message": "The identifier of the publicIds member of the entity with the registrar role is not equal to the handle member."
}
  5. Test case -49204: For the entity with the registrar role within the domain object, validate that the value of the handle member exists in the registrarId. 
    {
  "code": -49204,
  "value": "<handle> + \n\n + <registrarId>",
  "message": "The handle references an IANA Registrar ID that does not exist in the registrarId ."
}

The following steps shall only be executed if an entity with the registrar role exists within the topmost object, and the handle is "not applicable":

  1. Test case -49205: For the entity with the registrar role within the topmost object, validate that a publicIds member is not included. 
    {
"code": -49205,
"value": "<entity data structure>",
"message": "A publicIds member is included in the entity with the registrar role."
}

Nameserver Status

Test group: [nameserver_status]

  1. Test case -49300: If a status element is included in the nameserver object, validate that it complies with the following:
    1. "active" status MAY only be combined with "associated" status.
    2. "associated" status MAY be combined with any status.
    3. "pending delete" status MUST NOT be combined with either "client delete prohibited" or "server delete prohibited" status.
    4. "pending update" status MUST NOT be combined with either "client update prohibited" or "server update prohibited" status.
    5. Test case -49300: The pending create, pending delete, pending renew, pending transfer, and pending update status values MUST NOT be combined with each other. 
      {
  "code": -49300,
  "value": "<status data structure>",
  "message": "The values of the status data structure does not comply with RFC5732."
}

General Entity Within Domain Tests

RP Sections 2.7.1.x, 2.7.2.x, 2.7.3.x, and 2.7.4.x

Test group: [rdapResponseProfile_2_7_1_X_and_2_7_2_X_and_2_7_3_X_and_2_7_4_X_Validation]

The following steps should be used to test the RDAP protocol section 2.7.1.X and 2.7.2.X and 2.7.3.X and 2.7.4.X of the RDAP Response Profile 2.1:

  1. Test case -52100: For entities with the registrant, administrative, technical and billing role within the domain object, if a remarks member with the title "REDACTED FOR PRIVACY" is included, validate that the type member is "object redacted due to authorization". 
    {
  "code": -52100,
  "value": "<entity data structure>",
  "message": "An entity with the registrant, administrative, technical or billing role with a remarks members with the title 'REDACTED FOR PRIVACY' was found, but the description and type does not contain the value in 2.7.4.3 of the RDAP_Response_Profile_2_1."
}
  2. Test case -52101: For entities with the registrant, administrative, technical and billing role within the domain object, if a remarks member with the title "REDACTED FOR PRIVACY" is not included, validate that valid handle , fn , adr , tel members are included. For the adr member, validate that the following RDDS fields are included: Street and City. 
    {
  "code": -52101,
  "value": "<entity data structure>",
  "message": "An entity without a remark titled “REDACTED FOR PRIVACY” does not have all the necessary information of handle, fn, adr, tel, street and city."
}
  3. Test case -52102: For entities with the registrant, administrative, technical and billing role within the domain object, if a remarks member with the title "REDACTED FOR PRIVACY" is not included, validate that the handle comply with the following format specified in RFC5730: "(\w|_){1,80}-\w{1,8}". 
    {
  "code": -52102,
  "value": "<nameserver object>",
  "message": "The handle in the entity object does not comply with the format (\\w|_){1,80}-\\w{1,8} specified in RFC5730."
}
  4. Test case -52103: For entities with the registrant, administrative, technical and billing role within the domain object, if a remarks member with the title "REDACTED FOR PRIVACY" is not included and the handle conforms to the format: "(\w|_){1,80}-\w{1,8}", validate that the string followed by a hyphen ("-", ASCII value 0x002D) is registered in EPPROID. 
    {
  "code": -52103,
  "value": "<nameserver object>",
  "message": "The globally unique identifier in the entity object handle is not registered in EPPROID."
}
  5. Test case -52104: Only one entity shall be assigned the following roles: registrant, administrative, technical and billing. 
    {
  "code": -52104,
  "value": "<entities data structure>",
  "message": "More than one entity with the following roles were found: registrant, administrative, technical and billing."
}
    See Registrant Without CC Parameter in the conformance considerations for more information.
  6. Test case -52105: For entities with the registrant role within the domain object, validate that the CC parameter is included in the entity as defined in RFC8605. 
    {
  "code": -52105,
  "value": "<entity data structure>",
  "message": "An entity with the registrant role without the CC parameter was found. See section 2.7.3.1 of the RDAP_Response_Profile_2_1."
}
  7. Test case -52106: For entities with the registrant, administrative, technical and billing role within the domain object, if a remarks member with the title "REDACTED FOR PRIVACY" is not included and the handle conforms to the format: "(\w|_){1,80}-\w{1,8}", validate that the string followed by a hyphen ("-", ASCII value 0x002D) is not “ICANNRST”. 
    {
  "code": -52106,
  "value": "<entity data structure>",
  "message": "The globally unique identifier in the entity object handle is using an EPPROID reserved for testing by ICANN."
}

Registry Entities Within Domain Tests

RP Section 2.7.5.3

Test group: [rdapResponseProfile_2_7_5_3_Validation]

The following steps should be used to test the RDAP protocol section 2.7.5.3 of the RDAP Response Profile 2.1:

  1. Test case -55000: For the entities with the registrant, administrative, technical and billing role within the domain object, if the email property is omitted, validate that a remarks element containing a title member with a value "EMAIL REDACTED FOR PRIVACY" and a type member with a value "object redacted due to authorization" is included in the entity object. 
    {
  "code": -55000,
  "value": "<entity data structure>",
  "message": "An entity with the administrative, technical, or billing role without a valid 'EMAIL REDACTED FOR PRIVACY' remark was found. See section 2.7.5. 3 of the RDAP_Response_Profile_2_1."
}
    Note: this test also includes 2.7.5.1.

Registrar Entities Within Domain Tests

RP Section 2.7.5.2

Test group: [rdapResponseProfile_2_7_5_2_Validation]

The following steps should be used to test the RDAP protocol section 2.7.5.2 of the RDAP Response Profile 2.1:

  1. Test case -58000: For the entities with the registrant, administrative, technical and billing role within the domain object, if the email property is omitted, validate that a CONTACT-URI member is included. 
    {
  "code": -58000,
  "value": "<entity data structure>",
  "message": "An entity with the administrative, technical, or billing role without a CONTACT-URI member was found. See section 2.7.5.2 of the RDAP_Response_Profile_2_1."
}
  2. Test case -58001: For the entities with the registrant, administrative, technical and billing role within the domain object, if a CONTACT-URI member is included, validate that the content is an email address or an http/https link. 
    {
"code": -58001,
"value": "<entity data structure>",
"message": "The content of the CONTACT-URI member of an entity with the administrative, technical, or billing role does not contain an email or http/https link. See section 2.7.5.2 of the RDAP_Response_Profile_2_1."
}
    Note: this test also includes 2.7.5.1.

Registrar Entity Tests

RP Section 3.1

Test group: [rdapResponseProfile_3_1_Validation]

The following steps should be used to test the RDAP protocol section 3.1 of the RDAP Response Profile 2.1:

  1. Test case -60100: An entity with the registrar role as the topmost object shall exist. 
    {
  "code": -60100,
  "value": "<topmost object>",
  "message": "An entity with the registrar role was not found as the topmost object. See section 3.1 of the RDAP_Response_Profile_2_1"
}
  2. Test case -60101: Validate that valid handle , fn , adr , tel , email members are included in the topmost object. For the adr member, validate that the following RDDS fields are included: Street, City and Country. 
    {
  "code": -60101,
  "value": "<topmost object>",
  "message": "The required members for a registrar entity were not found. See section 3.1 of the RDAP Response Profile 2.1."
}

RP Section 3.2

Test group: [rdapResponseProfile_3_2_Validation]

The following steps should be used to test the RDAP protocol section 3.2 of the RDAP Response Profile 2.1:

  1. Test case -60200: If entities with the administrative and technical roles within the topmost object exist, validate that valid fn , tel , email members are included. 
    {
  "code": -60200,
  "value": "<entity data structure>",
  "message": "The required members for entities with the administrative and technical roles were not found. See section 3.2 of the RDAP_Response_Profile_2_1."
}

2024 gTLD profile Tests

Tests From The 2019 Profile

The following test groups from the RDAP Profile February-2019 collection are to be included in this collection without qualification:

Technical Implemenation Guide

General Tests

TIG Section 1.3

Test group: [tigSection_1_3_Validation]

  1. Test case -61000: Validate that the JSON string value "icann_rdap_technical_implementation_guide_1" is included in the RDAP Conformance data structure. 
    {
  "code": -61000,
  "value": "<rdapConformance data structure>",
  "message": "The RDAP Conformance data structure does not include icann_rdap_technical_implementation_guide_1."
}

TIG 2024 Section 1.5

Test group: [tigSection2024_1_5_Validation]

  1. Test case -61100: If the scheme of the URI to be tested is "https", verify that only TLS 1.2 or TLS 1.3 are offered by the RDAP server. 
    {
  "code": -61100,
  "value": "<URI>",
  "message": "The RDAP server must only use TLS 1.2 or TLS 1.3."
}
  2. Test case -61101: If the server is using TLS 1.2, verify that the cipher suite being used is one of: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
    {
  "code": -61101,
  "value": "<URI>",
  "message": "The RDAP server must one of the following cipher suites when using TLS 1.2: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384."
}

TIG 2024 Section 3.2

Test group: [tigSection2024_3_2_Validation]

  1. Test case -23201: Validate that the links object found with the test of code -23200 has a value property and that the property contents match the URI used to query the server. 
    {
  "code": -23201,
  "value": "<links data structure>",
  "message": "a value property must be specified and it must match the URI of the query."
}

TIG 2024 Section 3.3

Test group: [tigSection2024_3_3_Validation]

  1. Test case -61200: Validate that at least one notices object is in the topmost object containing a links object with a rel property of “terms-of-service: 
    {
  "code": -61200,
  "value": "<RDAP response>",
  "message": "The response must have one notice to the terms of service."
}
  2. Test case -61201: Validate that the links object above has an href property with an https or http URL. 
    {
  "code": -61201,
  "value": "<link>",
  "message": "This link must have an href."
}
  3. Test case -61202: Validate that the links object above has a value property that is the URI used to query the RDAP server for this specific response. 
    {
  "code": -61202,
  "value": "<link>",
  "message": "This link must have a value that is the same as the queried URI."
}

TIG 2024 Section 3.4

Test group: [tigSection2024_3_4_Validation]

  1. Test case -20701: Validate that the server responds to a /help query with an HTTP 200 OK and a valid RDAP JSON Response to /help. 
    {
  "code": -20701,
  "value": "<response>",
  "message": "Response to a /help query did not yield a proper status code or RDAP response."
}

Response Profile

General Tests

RP 2024 Section 1.2

Test group: [rdapResponseProfile2024_1_2_Validation]

  1. Test case -62000: Validate that the JSON string value “icann_rdap_response_profile_1” is included in the RDAP Conformance data structure. 
    {
  "code": -62000,
  "value": "<rdapConformance data structure>",
  "message": "The RDAP Conformance data structure does not include icann_rdap_response_profile_1."
}
  2. Test case -62001: Validate that the JSON string value “redacted” is in the RDAP Conformance data structure if the redacted data structure is in the topmost of the response as specified by RFC 9537. 
    {
  "code": -62001,
  "value": "<rdapConformance data structure>",
  "message": "The RDAP Conformance data structure does not include redacted but RFC 9537 is being used."
}

Domain Tests

RP Section 2.2

Test group: [rdapResponseProfile_2_2_Validation]

If the handle is in the topmost domain object, the following tests apply:

  1. Test case -46200: The handle in the topmost domain object shall comply with the following format specified in RFC5730: "(\w|_){1,80}-\w{1,8}". 
    {
  "code": -46200,
  "value": "<domain object>",
  "message": "The handle in the domain object does not comply with the format (\\w|_){1,80}-\\w{1,8} specified in RFC5730."
}
  2. Test case -46201: If the handle in the topmost domain object comply with the format: "(\w|_){1,80}-\w{1,8}", validate that the string followed by a hyphen ("-", ASCII value 0x002D) is registered in EPPROID. 
    {
  "code": -46201,
  "value": "<domain object>",
  "message": "The globally unique identifier in the domain object handle is not registered in EPPROID."
}

If the handle is NOT in the topmost domain object, the following tests apply:

  1. Test case -46202: Verify that a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Registry Domain ID”. 
    {
  "code": -46202,
  "value": "<redacted data structure>",
  "message": "a redaction of type Registry Domain ID is required."
}
  2. Test case -46203: In the redaction object from the above test, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the prePath property is either absent or is present as a JSON string of “$.handle”. 
    {
  "code": -46203,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registry Domain ID"
}
  3. Test case -46204: In the redaction object from the above test, verify that the method property is either absent or is present as is a JSON string of “removal”. 
    {
  "code": -46204,
  "value": "<redaction object>",
  "message": "Registry Domain ID redaction method must be removal if present"
}

RP Section 2.6.3

Test group: [rdapResponseProfile_2_6_3_Validation]

  1. Test case -46601: Validate that the notices member contains an element in the JSON array with a title “Status Codes”. 
    {
  "code": -46601,
  "value": "<notices array structure>",
  "message": "The notice for Status Codes was not found."
}
  2. Test case -46602: With the notice object above, validate that it contains a description array containing one string of “For more information on domain status codes, please visit https://icann.org/epp”. This test should ignore extra whitespace and trailing punctuation. 
    {
  "code": -46602,
  "value": "<notice structure>",
  "message": "The notice for Status Codes does not have the proper description."
}
  3. Test case -46603: With the notice object above, validate that it contains a links array. 
    {
  "code": -46603,
  "value": "<notice structure>",
  "message": "The notice for Status Codes does not have links."
}
  4. Test case -46604: With the links array above, validate that it contains one link object with an href property of “https://icann.org/epp”. 
    {
  "code": -46604,
  "value": "<notice structure>",
  "message": "The notice for Status Codes does not have a link to the status codes."
}
  5. Test case -46605: With the link object above, validate that it contains a rel property that is a string of “glossary”. 
    {
  "code": -46605,
  "value": "<notice structure>",
  "message": "The notice for Status Codes does not have a link relation type of glossary"
}
  6. Test case -46606: With the link object above, validate that it contains a value property that is a string of the URL used to query for this response. 
    {
  "code": -46606,
  "value": "<notice structure>",
  "message": "The notice for Status Codes does not have a link value of the request URL."
}

RP Section 2.10

Test group: [rdapResponseProfile_2_10_Validation]

  1. Test case -46701: Validate that the notices member contains an element in the JSON array with a title ““RDDS Inaccuracy Complaint Form”. 
    {
  "code": -46701,
  "value": "<notices array structure>",
  "message": "The notice for RDDS Inaccuracy Complaint Form was not found."
}
  2. Test case -46702: With the notice object above, validate that it contains a description array containing one string of “URL of the ICANN RDDS Inaccuracy Complaint Form: https://icann.org/wicf”. This test should ignore extra whitespace and trailing punctuation. 
    {
  "code": -46702,
  "value": "<notice structure>",
  "message": "The notice for RDDS Inaccuracy Complaint Form does not have the proper description."
}
  3. Test case -46703: With the notice object above, validate that it contains a links array. 
    {
  "code": -46703,
  "value": "<notice structure>",
  "message": "The notice for RDDS Inaccuracy Complaint Form does not have links."
}
  4. Test case -46704: With the links array above, validate that it contains one link object with an href property of “https://icann.org/wicf”. 
    {
  "code": -46704,
  "value": "<notice structure>",
  "message": "The notice for RDDS Inaccuracy Complaint Form does not have a link to the complaint form."
}
  5. Test case -46705: With the link object above, validate that it contains a rel property that is a string of “help”. 
    {
  "code": -46705,
  "value": "<notice structure>",
  "message": "The notice for RDDS Inaccuracy Complaint Form does not have a link relation type of help"
}
  6. Test case -46706: With the link object above, validate that it contains a value property that is a string of the URL used to query for this response. 
    {
  "code": -46706,
  "value": "<notice structure>",
  "message": "The notice for RDDS Inaccuracy Complaint Form does not have a link value of the request URL."
}

RP 2024 Section 2.7.3

Test group: [rdapResponseProfile2024_2_7_3_Validation]

  1. Test case -47600: For every entity of the domain (i.e. the top-level entities of the domain, not entities subordinate to other entities) excluding entities with the roles “registrar”, “registrant”, or “technical”, verify the handle is of the format: "(\w|_){1,80}-\w{1,8}". 
    {
  "code": -47600,
  "value": "<entity handle>",
  "message": "The handle in the entity object does not comply with the format (\\w|_){1,80}-\\w{1,8} specified in RFC5730."
}
  2. Test case -47601: With the handle above, verify the string followed by a hyphen (“-”, ASCII value 0x002D) is registered in the EPPROID dataset. 
    {
  "code": -47601,
  "value": "<entity handle>",
  "message": "The globally unique identifier in the entity object handle is not registered in EPPROID."
}

RP 2024 Section 2.4.6

Test group: [rdapResponseProfile2024_2_4_6_Validation]

  1. Test case -47700: Verify that the domain object has one entity with the role “registrar” with one link object in the links array with a rel property of the string “about”. 
    {
  "code": -47700,
  "value": "<domain structure>",
  "message": "A domain must have link to the RDAP base URL of the registrar."
}
  2. Test case -47701: With the handle of the “registrar” entity, verify that the “value” property of the link object above matches one of the base URLs in the registrarId data set. 
    {
  "code": -47701,
  "value": "<link structure>",
  "message": "The registrar base URL is not registered with IANA."
}
  3. Test case -47702: With the link object above, validate the href property contains an URL with the “https” scheme. 
    {
  "code": -47702,
  "value": "<link structure>",
  "message": "The registrar RDAP base URL must have an https scheme."
}
  4. Test case -47703: With the link object above, verify that the href property is a valid URI according to the rules in webUriValidation. 
    {
  "code": -47703,
  "value": "<link structure>",
  "message": "The ‘value’ property is not a valid Web URI according to [webUriValidation]."
}

Domain Registrant Tests

RP 2024 Section 2.7.2

Test group: [rdapResponseProfile2024_2_7_2_Validation]

  1. Test case -63000: If the queried RDAP server is a registrar (such as with the --gtld-registrar command line parameter or through the configuration object), verify that the domain object has one entity with the “registrant” role. 
    {
  "code": -63000,
  "value": "<domain structure>",
  "message": "A domain served by a registrar must have one registrant."
}

Registrant Handle

Test group: [rdapResponseProfile_registrant_handle]

These tests only apply to an entity with the “registrant” role, if present.

If the handle of the entity with the “registrant” role is present, the following tests apply:

  1. Test case -63100: The handle of the entity object above shall comply with the following format specified in RFC5730: "(\w|_){1,80}-\w{1,8}". 
    {
  "code": -63100,
  "value": "<handle>",
  "message": "The handle of the registrant does not comply with the format (\\w|_){1,80}-\\w{1,8} specified in RFC5730."
}
  2. Test case -63101: If the handle of the entity object above complies with the format: "(\w|_){1,80}-\w{1,8}", validate that the string followed by a hyphen ("-", ASCII value 0x002D) is registered in EPPROID. 
    {
  "code": -63101,
  "value": "<handle>",
  "message": "The globally unique identifier in the registrant handle is not registered in EPPROID."
}

If the handle is NOT in the entity object with the registrant, the following tests apply:

  1. Test case -63102: Verify that a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Registry Registrant ID”. 
    {
  "code": -63102,
  "value": "<redacted data structure>",
  "message": "a redaction of type Registry Registrant ID is required."
}
  2. Test case -63103: In the redaction object from the above test, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the prePath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -63103,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registry Registrant ID"
}
  3. Test case -63104: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to an empty set. 
    {
  "code": -63104,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to a zero set for redaction by removal of Registry Registrant ID."
}
  4. Test case -63105: In the redaction object from the above test, verify that the method property is either absent or is present as is a JSON string of “removal”. 
    {
  "code": -63105,
  "value": "<redaction object>",
  "message": "Registry Registrant ID redaction method must be removal if present"
}

RP 2024 Section 2.7.4.1

Test group: [rdapResponseProfile2024_2_7_4_1_Validation]

These tests only apply to an entity with the “registrant” role, if present.

  1. Test case -63200: Verify the fn property of all the vCard objects of the entity with the “registrant” role is present. 
    {
  "code": -63200,
  "value": "<vcard array>",
  "message": "The fn property is required on the vcard for the registrant."
}

If the fn property above is present but empty, the following tests apply:

  1. Test case -63201: Verify that a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Registrant Name”. 
    {
  "code": -63201,
  "value": "<redacted data structure>",
  "message": "a redaction of type Registrant Name is required."
}
  2. Test case -63202: In the redaction object from the above test, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the postPath property is present with a valid JSONPath expression. 
    {
  "code": -63202,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registrant Name"
}
  3. Test case -63203: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to a non-empty set. 
    {
  "code": -63203,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to non-empty set for redaction by empty value of Registrant Name."
}
  4. Test case -63204: In the redaction object from the above test, verify that the method property is present as is a JSON string of “emptyValue”. 
    {
  "code": -63204,
  "value": "<redaction object>",
  "message": "Registrant Name redaction method must be empytValue"
}

RP 2024 Section 2.7.4.2

Test group: [rdapResponseProfile2024_2_7_4_2_Validation]

These tests only apply to an entity with the “registrant” role, if present.

If the org property on the vCards for the entity with the role of registrant is not present, the following tests apply:

  1. Test case -63300: Verify that a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Registrant Organization”. 
    {
  "code": -63300,
  "value": "<redacted data structure>",
  "message": "a redaction of type Registrant Organization is required."
}
  2. Test case -63301: In the redaction object from the above test, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the prePath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -63301,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registrant Organization"
}
  3. Test case -63302: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to an empty set. 
    {
  "code": -63302,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to a zero set for redaction by removal of Registrant Organization."
}
  4. Test case -63303: In the redaction object from the above test, verify that the method property is either absent or is present as is a JSON string of “removal”. 
    {
  "code": -63303,
  "value": "<redaction object>",
  "message": "Registrant Organization redaction method must be removal if present"
}

RP 2024 Section 2.7.4.3

Test group: [rdapResponseProfile2024_2_7_4_3_Validation]

These tests only apply to an entity with the “registrant” role, if present.

  1. Test case -63400: Verify the street value (zero-indexed 2) of the adr property of all the vCard objects of the entity with the “registrant” role is present. 
    {
  "code": -63400,
  "value": "<vcard array>",
  "message": "The street value of the adr property is required on the vcard for the registrant."
}

If the street value of the adr property above is present but empty, the following tests apply:

  1. Test case -63401: Verify that a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Registrant Street”. 
    {
  "code": -63401,
  "value": "<redacted data structure>",
  "message": "a redaction of type Registrant Street is required."
}
  2. Test case -63402: In the redaction object from the above test, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the postPath property is present with a valid JSONPath expression. 
    {
  "code": -63402,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registrant Street"
}
  3. Test case -63403: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to a non-empty set. 
    {
  "code": -63403,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to non-empty set for redaction by empty value of Registrant Street."
}
  4. Test case -63404: In the redaction object from the above test, verify that the method property is present as is a JSON string of “emptyValue”. 
    {
  "code": -63404,
  "value": "<redaction object>",
  "message": "Registrant Street redaction method must be empytValue"
}

RP 2024 Section 2.7.4.4

Test group: [rdapResponseProfile2024_2_7_4_4_Validation]

These tests only apply to an entity with the “registrant” role, if present.

  1. Test case -63500: Verify the city value (zero-indexed 3) of the adr property of all the vCard objects of the entity with the “registrant” role is present. 
    {
  "code": -63500,
  "value": "<vcard array>",
  "message": "The city value of the adr property is required on the vcard for the registrant."
}

If the city value of the adr property above is present but empty, the following tests apply:

  1. Test case -63501: Verify that a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Registrant City”. 
    {
  "code": -63501,
  "value": "<redacted data structure>",
  "message": "a redaction of type Registrant City is required."
}
  2. Test case -63502: In the redaction object from the above test, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the postPath property is present with a valid JSONPath expression. 
    {
  "code": -63502,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registrant City"
}
  3. Test case -63503: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to a non-empty set. 
    {
  "code": -63503,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to non-empty set for redaction by empty value of Registrant City."
}
  4. Test case -63504: In the redaction object from the above test, verify that the method property is present as is a JSON string of “emptyValue”. 
    {
  "code": -63504,
  "value": "<redaction object>",
  "message": "Registrant City redaction method must be empytValue"
}

RP 2024 Section 2.7.4.6

Test group: [rdapResponseProfile_2_7_4_6_Validation]

These tests only apply to an entity with the “registrant” role, if present.

  1. Test case -63600: Verify the postal code value (zero-indexed 5) of the adr property of all the vCard objects of the entity with the “registrant” role is present. 
    {
  "code": -63600,
  "value": "<vcard array>",
  "message": "The postal code value of the adr property is required on the vcard for the registrant."
}

If the postal code value of the adr property above is present but empty, the following tests apply:

  1. Test case -63601: Verify that a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Registrant Postal Code”. 
    {
  "code": -63601,
  "value": "<redacted data structure>",
  "message": "a redaction of type Registrant Postal Code is required."
}
  2. Test case -63602: In the redaction object from the above test, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the postPath property is present with a valid JSONPath expression. 
    {
  "code": -63602,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registrant Postal Code"
}
  3. Test case -63603: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to a non-empty set. 
    {
  "code": -63603,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to non-empty set for redaction by empty value of Registrant Postal Code."
}
  4. Test case -63604: In the redaction object from the above test, verify that the method property is present as is a JSON string of “emptyValue”. 
    {
  "code": -63604,
  "value": "<redaction object>",
  "message": "Registrant Postal Code redaction method must be empytValue"
}

RP 2024 Section 2.7.4.8

Test group: [rdapResponseProfile2024_2_7_4_8_Validation]

These tests only apply to an entity with the “registrant” role, if present.

If a tel property with a “voice” parameter on the vCards for the entity with the role of registrant is not present, the following tests apply:

  1. Test case -63700: Verify that a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Registrant Phone”. 
    {
  "code": -63700,
  "value": "<redacted data structure>",
  "message": "a redaction of type Registrant Phone is required."
}
  2. Test case -63701: In the redaction object from the above test, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the prePath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -63701,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registrant Phone"
}
  3. Test case -63702: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to an empty set. 
    {
  "code": -63702,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to a zero set for redaction by removal of Registrant Phone."
}
  4. Test case -63703: In the redaction object from the above test, verify that the method property is either absent or is present as is a JSON string of “removal”. 
    {
  "code": -63703,
  "value": "<redaction object>",
  "message": "Registrant Phone redaction method must be removal if present"
}

RP 2024 Section 2.7.5.1

Test group: [rdapResponseProfile2024_2_7_5_1_Validation]

These tests only apply to an entity with the “registrant” role, if present.

If a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Registrant Phone Ext”, these tests apply:

  1. Test case -63800: In the redaction object from the above, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the prePath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -63800,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registrant Phone Ext"
}
  2. Test case -63801: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to an empty set. 
    {
  "code": -63801,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to a zero set for redaction by removal of Registrant Phone Ext."
}
  3. Test case -63802: In the redaction object from the above test, verify that the method property is either absent or is present as is a JSON string of “removal”. 
    {
  "code": -63802,
  "value": "<redaction object>",
  "message": "Registrant Phone Ext redaction method must be removal if present"
}

RP 2024 Section 2.7.5.2

Test group: [rdapResponseProfile_2_7_5_2_Validation]

These tests only apply to an entity with the “registrant” role, if present.

If a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Registrant Fax”, these tests apply:

  1. Test case -63900: In the redaction object from the above, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the prePath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -63900,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registrant Fax"
}
  2. Test case -63901: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to an empty set. 
    {
  "code": -63901,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to a zero set for redaction by removal of Registrant Fax."
}
  3. Test case -63902: In the redaction object from the above test, verify that the method property is either absent or is present as is a JSON string of “removal”. 
    {
  "code": -63902,
  "value": "<redaction object>",
  "message": "Registrant Fax redaction method must be removal if present"
}

RP Section 2.7.5.3

Test group: [rdapResponseProfile_2_7_5_3_Validation]

These tests only apply to an entity with the “registrant” role, if present.

If a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Registrant Fax Ext”, these tests apply:

  1. Test case -64000: In the redaction object from the above, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the prePath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -64000,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registrant Fax Ext"
}
  2. Test case -64001: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to an empty set. 
    {
  "code": -64001,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to a zero set for redaction by removal of Registrant Fax Ext."
}
  3. Test case -64002: In the redaction object from the above test, verify that the method property is either absent or is present as is a JSON string of “removal”. 
    {
  "code": -64002,
  "value": "<redaction object>",
  "message": "Registrant Fax Ext redaction method must be removal if present"
}

RP 2024 Section 2.7.4.9

Test group: [rdapResponseProfile2024_2_7_4_9_Validation]

These tests only apply to an entity with the “registrant” role, if present, on queries of a gTLD registrar (i.e. --gtld-registrar).

If a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Registrant Email”, these tests apply:

  1. Test case -64100: Verify that the contact-uri property and the email property do not exist together on any vCards for the entity with the role of “registrant”. 
    {
  "code": -64100,
  "value": "<vCard/jCard structrue>",
  "message": "a redaction of Registrant Email may not have both the email and contact-uri"
}
  2. Test case -64101: Verify that either the contact-uri property or the email property exists on all vCards for the entity with the role of “registrant”. 
    {
  "code": -64101,
  "value": "<vCard/jCard structrue>",
  "message": "a redaction of Registrant Email must have either the email and contact-uri"
}
  3. Test case -64102: In the redaction object from the above test, verify that the method property is present as is a JSON string of “replacementValue”. 
    {
  "code": -64102,
  "value": "<redaction object>",
  "message": "Registrant Email redaction method must be replacementValue"
}

Given the above, if the email property exists on any of the vCards, the following tests apply:

  1. Test case -64103: In the redaction object from the above, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the postPath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -64103,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registrant Email postPath"
}
  2. Test case -64104: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to a non-empty set. 
    {
  "code": -64104,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to a non-empty set for redaction by replacementvalue of Registrant Email."
}

Given the above, if the contact-uri property exists on any of the vCards, the following tests apply:

  1. Test case -64105: In the redaction object from the above, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the replacementPath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -64105,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registrant Email replacementPath"
}
  2. Test case -64106: In the redaction object from the above, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the prePath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -64106,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Registrant Email prePath"
}
  3. Test case -64107: With the JSONPath expression from above in replacementPath, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to a non-empty set. 
    {
  "code": -64107,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to a non-empty set for redaction by replacementvalue of Registrant Email in replacementPath"
}

If a redaction object (see RFC 9537) is NOT in the redacted array with a name object containing the type property which is a JSON string of “Registrant Email”, these tests apply:

  1. Validate that a properly formed email address is in an email property on at least one of the vCards. 
    {
  "code": -64108,
  "value": "<registrant entity>",
  "message": "An email must either be present and valid or redacted for the registrant"
}

Domain Technical Contact Tests

RP 2024 Section 2.7.6.1

Test group: [rdapResponseProfile2024_2_7_6_1_Validation]

These tests only apply to an entity with the “technical” role, if present.

  1. Test case -65000: Verify the fn property of all the vCard objects of the entity with the “technical” role is present. 
    {
  "code": -65000,
  "value": "<vcard array>",
  "message": "The fn property is required on the vcard for the technical contact."
}

If the fn property above is present but empty, the following tests apply:

  1. Test case -65001: Verify that a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Tech Name”. 
    {
  "code": -65001,
  "value": "<redacted data structure>",
  "message": "a redaction of type Tech Name is required."
}
  2. Test case -65002: In the redaction object from the above test, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the postPath property is present with a valid JSONPath expression. 
    {
  "code": -65002,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Tech Name"
}
  3. Test case -65003: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to a non-empty set. 
    {
  "code": -65003,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to a non-empty set for redaction by empty value of Tech Name."
}
  4. Test case -65004: In the redaction object from the above test, verify that the method property is present as is a JSON string of “emptyValue”. 
    {
  "code": -65004,
  "value": "<redaction object>",
  "message": "Tech Name redaction method must be emptyValue"
}

RP 2024 Section 2.7.6.2

Test group: [rdapResponseProfile2024_2_7_6_2_Validation]

These tests only apply to an entity with the “technical” role, if present.

If a tel property with a “voice” parameter on the vCards for the entity with the role of “technical” is not present, the following tests apply:

  1. Test case -65100: Verify that a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Tech Phone”. 
    {
  "code": -65100,
  "value": "<redacted data structure>",
  "message": "a redaction of type Tech Phone is required."
}
  2. Test case -65101: In the redaction object from the above test, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the prePath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -65101,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Tech Phone"
}
  3. Test case -65102: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to an empty set. 
    {
  "code": -65102,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to a zero set for redaction by removal of Tech Phone."
}
  4. Test case -65103: In the redaction object from the above test, verify that the method property is either absent or is present as is a JSON string of “removal”. 
    {
  "code": -65103,
  "value": "<redaction object>",
  "message": "Tech Phone redaction method must be removal if present"
}

RP 2024 Section 2.7.6.3

Test group: [rdapResponseProfile2024_2_7_6_3_Validation]

These tests only apply to an entity with the “technical” role, if present.

If a redaction object (see RFC 9537) is in the redacted array with a name object containing the type property which is a JSON string of “Tech Email”, these tests apply:

  1. Test case -65200: Verify that the contact-uri property and the email property do not exist together on any vCards for the entity with the role of “technical”. 
    {
  "code": -65200,
  "value": "<vCard/jCard structrue>",
  "message": "a redaction of Tech Email may not have both the email and contact-uri"
}
  2. Test case -65201: Verify that either the contact-uri property or the email property exists on all vCards for the entity with the role of “technical”. 
    {
  "code": -65201,
  "value": "<vCard/jCard structrue>",
  "message": "a redaction of Tech Email must have either the email or contact-uri"
}
  3. Test case -65202: In the redaction object from the above test, verify that the method property is present and is a JSON string of “replacementValue”. 
    {
  "code": -65202,
  "value": "<redaction object>",
  "message": "Tech Email redaction method must be replacementValue"
}

Given the above, if the email property exists on any of the vCards, the following tests apply:

  1. Test case -65203: In the redaction object from the above, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the postPath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -65203,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Tech Email postPath"
}
  2. Test case -65204: With the JSONPath expression from above, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to a non-empty set. 
    {
  "code": -65204,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to a non-empty set for redaction by replacementValue of Tech Email."
}

Given the above, if the contact-uri property exists on any of the vCards, the following tests apply:

  1. Test case -65205: In the redaction object from the above, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the replacementPath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -65205,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Tech Email replacementPath"
}
  2. Test case -65206: In the redaction object from the above, if the pathLang property is either absent or is present as a JSON string of “jsonpath”, then verify that the prePath property is either absent or is present with a valid JSONPath expression. 
    {
  "code": -65206,
  "value": "<redaction object>",
  "message": "jsonpath is invalid for Tech Email prePath"
}
  3. Test case -65207: With the JSONPath expression from above in replacementPath, if the pathLang property is either absent or is present as a string of “jsonpath” then verify that the expression evaluates to a non-empty set. 
    {
  "code": -65207,
  "value": "<redaction object>",
  "message": "jsonpath must evaluate to a non-empty set for redaction by replacementValue of Tech Email in replacementPath"
}

Conformance Considerations

CORS (Access-Control-Allow-Origin)

The access-control-allow-origin HTTP header is part of the Cross-Origin Resource Sharing (CORS) mechanism to help applications that run inside of web browsers to access web APIs, such as RDAP.

Section 1.14 of the 2024 ICANN RDAP Technical Implementation Guide (TIG) states:

1.14. When responding to RDAP valid requests, an RDAP server MUST include the Access-Control-Allow-Origin response header, as specified by [W3C.REC-cors-20140116]. Unless otherwise specified, a value of "*" MUST be used.

NOTE: This is in section 1.13 of the 2019 TIG

This means that an RDAP server must set the "access-control-allow-origin" HTTP header to the value "*":

access-control-allow-origin: *

Some web application firewalls and gateways will automatically respond with an access-control-allow-origin header in the response when the request contains an origin header, as is the case with some web browsers. Hence, checking for access-control-allow-origin with a web browser may be misleading in some cases, and confusion may arise between what is returned to the web browser in these specific conditions compared to the results seen by RDAPCT.

NOTE: HTTP headers are not required to be capitalized.

HTTP URLs

Section 1.4 of the 2024 ICANN RDAP Technical Implementation Guide states:

1.4. The RDAP service MUST be provided over HTTPS only as described in RFC9110 or its successors.

NOTE: This in section 1.2 of the 2019 TIG

This means that RDAP services for gTLD registries and registrars is only to be offered over HTTPS, and the URL for the RDAP service should use the "https" URI scheme.

HTTP to HTTPS Redirects

Section 1.4 of the 2024 ICANN RDAP Technical Implementation Guide states:

1.4. The RDAP service MUST be provided over HTTPS only as described in RFC9110 or its successors.

NOTE: This in section 1.2 of the 2019 TIG

This means that RDAP services for gTLD registries and registrars is only to be offered over HTTPS, and the URL for the RDAP service should use the "https" URI scheme. For gTLD registries, this means they are to provide HTTPS and only HTTPS to IANA to be placed in the RDAP bootstrap files.

If an HTTP URL is operational, it must redirect to the HTTPS URL even if the HTTP URL is not publicly known.

Media Types

Testing an RDAP service with just a web browser (i.e. not an RDAP web-app) can mask issues with the acceptance of media types (formerly called MIME types). A bare web browser will not properly account for the correct media types required of RDAP.

RFC 7480 Section 4.2 states the following:

To indicate to servers that an RDAP response is desired, clients include an Accept header field with an RDAP-specific JSON media type, the generic JSON media type, or both. Servers receiving an RDAP request return an entity with a Content-Type header containing the RDAP-specific JSON media type.

This means that a client may use either the "application/json" or "application/rdap+json" media type in the "accept" HTTP header of an RDAP request, but the RDAP response must only have the "application/rdap+json" media type in the "content-type" HTTP header.

This can be demonstrated using these curl command:

  • curl -v -H "accept: application/rdap+json" https://rdap.example.
    • The output should contain:
      • > accept: application/rdap+json
      • < content-type: application/rdap+json
  • curl -v -H "accept: application/json" https://rdap.example.
    • The output should contain:
      • > accept: application/json
      • < content-type: application/rdap+json

NOTE: HTTP headers are not required to be capitalized.

Referrals to Registars

Both the 2019 and the 2024 gTLD RDAP profiles require gTLD registries to provide link referrals to the corresponding objects in the registrar's RDAP service. The 2019 profile is silent on how a registry obtains a registrar's RDAP URL. However, the 2024 profile clarifies that the IANA Registrar IDs registry is to be used to obtain a registrar's RDAP base URL.

Registrant Without CC Parameter

Section 1.4 of the 2024 ICANN RDAP Response Profile states:

1.4. In an entity object with an adr structure, the country name property MUST be empty and the cc property MUST be populated by a value from ISO 3166-1 alpha-2.

This means that the country name must be empty and the ISO 3166-2 Alpha-2 country code for that country should be used instead. RDAP uses jCard, which is the JSON form of vCard, and vCard defines postal addresses to use country name. However, RFC 8605 defines a "cc" parameter for vCard to specify the ISO 3166-1 Alpha-2 country code.

Usage With Structured Postal Addresses

When using structured postal addresses in jCard with the "cc" parameter, the "adr" property looks like this:

[
  "adr",
  {
    "cc": "CA"
  },
  "text",
  [
    "",   
    "",    
    "123 Maple Ave", 
    "Quebec",        
    "QC",            
    "G1V 2M2",       
    ""
  ]
]

The last string in string array that is the last element in the "adr" property is designated to be the country name. It is to be left blank, and the "cc" parameter is to be used.

NOTE: The array is always seven elements in length. The first 2 empty strings represent a mail box number and suite/apartment number, but neither is recommended for use.

Using with Unstructured Postal Addresses

NOTE: Unstructured postal addresses are disallowed by Section 3.8.1 of the Technical Implementation Guide. This information is provided for educational purposes.

jCard allows the use of unstructured postal addresses, where each line of an address on a postal envelope is separated by a newline (\n). Here is an example with the "cc" parameter.

[
  "adr",
  {
    "cc": "CA",
    "label":"123 Maple Ave\nQuebec\nQC\nG1V 2M2\n\n"
  },
  "text",
  [
    "", "", "", "", "", "", ""
  ]
]

NOTE: The seven-element text array is still given but all strings are empty, and the "label" parameter is used to represent the address.

Notice of EPP Status Codes

Section 2.6.3 of the 2024 ICANN RDAP Response Profile requires servers provide an RDAP notice with a link to the EPP Status Codes:

2.6.3. A domain name RDAP response MUST contain a notices member with a title “Status Codes”, a description containing the string “For more information on domain status codes, please visit https://icann.org/epp” and a links member with the https://icann.org/epp URL in the href, rel:glossary, and a value with the RDAP lookup path that generated the RDAP response.

NOTE: This is section 2.6.3 of the 2019 Profile.

Here is an example of the notice, which is one of the JSON objects inside the "notices" array that MUST only appear at the top-most JSON of the RDAP response:

{
  "title": "Status Codes",
  "description": [
    "“For more information on domain status codes, please visit https://icann.org/epp"
  ],
  "links": [
    {
      "value": "https://some-value.example",
      "rel": "glossary",
      "href": "https://icann.org/epp",
      "type": "text/html"
    }
  ]
}

The "type" attribute is not required to be set, but if set it should match the media type of the value used in "href", which is "text/html" for "https://icann.org/epp". Setting this attribute is good practice.

The "value" attribute

The "value" attribute must be the request URL of the RDAP query. For example, if the RDAP query used "https://rdap.example/domain/foo.example" to query for a domain where this notice is found, then the "value" attribute must be "https://rdap.example/domain/foo.example".

The "rel" attribute

The value of the "rel" attribute must be "glossary". Values of "alternate" or "about" will trigger a compliance issue.

Using www.icann.org

While using the URL of "https://www.icann.org/epp" in either the "href" attribute or the link description will lead user to the right page, the conformance tool strictly checks for the usage of "https://icann.org/epp" (notice the lack of "www.").

Notice of RDDS Inaccuracy Report

Section 2.10 of the 2024 ICANN RDAP Response Profile requires servers provide an RDAP notice with a link the ICANN RDDS Inaccuracy Form:

2.10. RDDS Inaccuracy - A domain name RDAP response MUST contain a notices member with a title “RDDS Inaccuracy Complaint Form”, a description containing the string “URL of the ICANN RDDS Inaccuracy Complaint Form: https://icann.org/wicf” and a links member with the https://icann.org/wicf URL in the href, rel:help, and a value with the RDAP lookup path that generated the RDAP response.

NOTE: This is section 2.11 of the 2019 Profile.

Here is an example of the notice, which is one of the JSON objects inside the "notices" array that MUST only appear at the top-most JSON of the RDAP response:

{
  "title": "RDDS Inaccuracy Complaint Form",
  "description": [
    "URL of the ICANN RDDS Inaccuracy Complaint Form: https://icann.org/wicf"
  ],
  "links": [
    {
      "value": "https://some-value.example",
      "rel": "help",
      "href": "https://icann.org/wicf",
      "type": "text/html"
    }
  ]
}

The "type" attribute is not required to be set, but if set it should match the media type of the value used in "href", which is "text/html" for "https://icann.org/wicf". Setting this attribute is good practice.

The "value" attribute

The "value" attribute must be the request URL of the RDAP query. For example, if the RDAP query used "https://rdap.example/domain/foo.example" to query for a domain where this notice is found, then the "value" attribute must be "https://rdap.example/domain/foo.example".

The "rel" attribute

The value of the "rel" attribute must be "help". Values of "alternate" or "about" will trigger a compliance issue.

Using www.icann.org

While using the URL of "https://www.icann.org/wicf" in either the "href" attribute or the link description will lead user to the right page, the conformance tool strictly checks for the usage of "https://icann.org/wicf" (notice the lack of "www.").

TLS Handshake Issues

TLS handshake issues can be caused by TLS certificates signed with out-of-date signing algorithms. This can be an issue with the TLS certificate issued for the RDAP server or any certificate in the chain, including the root certificate used by the issuing Certificate Authority.

The openssl command can be used to determine if this is the issue.

openssl s_client -connect example.com:443 -showcerts < /dev/null 2>/dev/null | grep sigalg

Might produce the following:

   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   a:PKEY: RSA, 2048 (bit); sigalg: sha384WithRSAEncryption
   a:PKEY: RSA, 4096 (bit); sigalg: sha384WithRSAEncryption
   a:PKEY: RSA, 2048 (bit); sigalg: sha1WithRSAEncryption

Here, the very last certificate has the signing algorithm has "sha1WithRSAEncryption". As SHA1 is deprected by RFC 9155, the TLS handshake will because SHA1 is considered insecure.

Another tool to view TLS certificates used in HTTPS is https://www.ssllabs.com/ssltest/index.html.

2024 Profile Redaction Requirements

The 2024 Response Profile requires updates to the redaction mechanisms used in the RDAP response. This is described in Sections 2.7.7 and 2.7.8 and Appendix E of the RDAP Response Profile. This will require registrars and registry operators to implement RFC 9537 redaction mechanisms, including redaction by replacement (for email values) and redaction by removal or empty value (for other redacted registration data values).

The redaction remarks element previously required by Section 2.7.4.3 of the 2019 RDAP Response Profile is now obsolete.

Registrant Name / Tech Name

The "Registrant Name", and if applicable, "Tech Name" values are included in the fn property in accordance with Section 2.7.4 of the RDAP Response Profile. Both values may be redacted pursuant to Sections 9.2.2.1.3 and 9.2.2.1.11 of the Registration Data Policy.

fn Property

The fn property is required by RFC 6350. Because the fn property is required, when redacting the fn property, registrars must use Redaction by Empty Value and the value of the fn property must be blank in the RDAP response.

This is shown with an empty string, for example:

[
  "fn",
  {},
  "text",
  ""
]

In addition, the response must include the empty value redacted member, for example:

"redacted": [
  {
    "name": {
      "type": "Registrant Name"
    },
    "postPath": "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='fn')][3]",
    "pathLang": "jsonpath",
    "method": "emptyValue",
    "reason": {
      "description": "Server policy"
    }
  }
]

Registrant Postal Address

Registrant State/Province and Country

Registrars must collect the Registrant State/Province (if applicable to the respective country or territory) and Registrant Country pursuant to Sections 6.1.12 and 6.1.14 of the Registration Data Policy. Publication is required pursuant to Sections 9.1.4 and 9.1.5; redaction is not permitted under Section 9.2.

Registrant Street, City, and Postal Code

These elements are included in the adr property in accordance with Section 2.7.4 of the RDAP Response Profile. The values may be redacted pursuant to Sections 9.2.2.1.4. 9.2.2.1.5 and 9.2.2.4 of the Registration Data Policy.

adr Property

To accommodate the required data elements in the Registrant postal address, the RDAP response must include an adr property for the Registrant. Pursuant to Section 3.8.1, the RDAP response must use a structured adr property. Because the adr property is required, when redacting the Registrant Street, City and/or Postal Code, registrars must use Redaction by Empty Value and the value of these data elements in the adr property must be blank in the RDAP response.

This shows a partially redacted postal address of a structured adr property within the vCard: 

[
  "adr",
  {
    "cc": "CA"
  },
  "text",
  [
    "",   
    "",    
    "", 
    "",        
    "QC",            
    "",       
    ""
  ]
]

In addition, the response must include the empty value redacted members, for example (Registrant City):

"redacted": [
  {
    "name": {
      "type": "Registrant City"
    },
    "postPath": "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='adr')][3][3]",
    "pathLang": "jsonpath",
    "method": "emptyValue",
    "reason": {
    "description": "Server policy"
  }
]

Registrant Email / Tech Email

When redacting registration data in RDAP, Section Section 9.2.3 of the Registration Data Policy requires registrars to include an email address (email property) or a link to a web form (contact-uri) to facilitate email communication with the relevant contact for the Email value. Registrars must use the Redaction by Replacement Value Method in the RDAP response.

email Property

If the redacted Email value is an anonymized syntactically valid email, the RDAP response must include an email property and not a contact-uri property.

This is shown with the valid anonymized email, for example: 

[
  "email",
  {},
  "text",
  "anonymized123@example.com"
]

In addition, the response must include the replacement redacted member, for example:

"redacted": [
  {
    "name": {
      "type": "Registrant Email"
    },
    "postPath": "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')][3]",
    "pathLang": "jsonpath",
    "method": "replacementValue",
  }
]

contact-uri Property

If the redacted Email value is a web form, the RDAP response must include a contact-uri property and not an email property.

This is shown with the valid HTTP URL, for example: 

[
  "contact-uri",
  {},
  "uri",
  "https://email.example.com/123"
]

In addition, the response must include the replacement redacted member, for example:

"redacted": [
  {
    "name": {
      "type": "Registrant Email"
    },
    "prePath": "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')]",
    "replacementPath": "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')]",
    "pathLang": "jsonpath",
    "method": "replacementValue",
  }
]

Additional Registration Data values

In some cases, it is permitted to redact an entire property in the RDAP response (e.g., Repository Object Identifiers, Registrant Organization, and Registrant and Tech Phone, Fax, Phone Ext and Fax Ext). These values will be removed entirely and no corresponding property will appear in the RDAP response. Registrars must use the Redaction by Removal Method in the RDAP response.

The response must include the removal redacted member, for example:

"redacted": [
  {
    "name": {
      "type": "Registrant Organization"
    },
    "prePath": "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='org')]",
    "method": "removal"
  }
]

Appendix E of the Response Profile provides the full list of required redaction members.

References

RDAP RFCs:

DNS RFCs:

DNSSEC RFCs:

IDNA RFCs:

gTLD RDAP Profile

February 2019

February 2024

Other RFCs

Other Specifications