ICANN RDAP

This repository contains open source code written by the Internet Corporation for Assigned Names and Numbers (ICANN). for use with the Registry Data Access Protocol (RDAP). RDAP is standard of the IETF, and extensions to RDAP are a current work activity of the IETF's REGEXT working group. Read about ICANN's role in RDAP. See general information on RDAP.

About, Usage, and Installation

Basic Queries

• Domain: rdap example.com
• TLD: rdap .com
• IP Address: rdap 192.0.2.1
• CIDR: rdap 10/8
• RIR Search: rdap up:192.0.2.1
• ASN: rdap as64496
• GeoFeed: rdap -O geofeed 81.93.181.144
• URL: rdap https://rdap.iana.org/domain/com

See the online user's manual for general information, installation, and usage of this software.

SemVer Policy

This project uses Semantic Versioning (SemVer 2.0.0).

---

Versioning Guidelines

• MAJOR (X.0.0):
  • Breaking public API changes
  • Breaking CLI parameter changes
  • Increases to the Minimum Supported Rust Version (MSRV)
• MINOR (0.Y.0):
  • New backwards-compatible features
  • Non-breaking deprecations
  • Non-breaking improvements
• PATCH (0.0.Z):
  • Backwards-compatible fixes
  • Internal code refactoring
  • Documentation updates
  • Backwards-compatible updates to dependencies in the client and common packages
  • Updates to any dependencies in the cli and srv packages

---

Changes Outside Backwards-Compatibility Scope

Some changes that are not backwards-compatible (i.e., breaking changes) are not considered in the versioning guidelines. Such changes relate to experimental features and certain aspects of the user interface.

Experimental Features

The following are considered experimental features:

• Non-stable RDAP extensions (i.e., those still being standardized). Examples as of this writing are Exts, JSContact, and SimpleRedaction.
• The SQLx server backend.

User Interface

Non-parsable output of the user interface is subject to change. These outputs are the Markdown and gTLD Whois output formats for rdap and the text output for rdap-test.

License

Licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT) at your option.

Contribution

Unless you explicitly state otherwise, any contribution, as defined in the Apache-2.0 license, intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed pursuant to the Apache License, Version 2.0 or the MIT License referenced as above, at ICANN’s option, without any additional terms or conditions.

How To Contribute

Before working on a Pull Request (PR), seek advice from the maintainers regarding the acceptance of the PR. To do this, submit an issue outlining the idea for the PR. If the maintainers agree that the contribution would be welcome, they will assign the issue to you.

Coding And Test Styles

All code should be formatted according to rustfmt. Run cargo fmt --check to determine if changes are needed.

Tests should follow the GIVEN... WHEN... THEN... pattern if possible. Such as:

// GIVEN a domain in the server
...

// WHEN queried
...

// THEN return 200 OK

There can be multiple GIVEN, WHEN, and THEN sections.

You may see some tests with the GIVEN-WHEN-THEN pattern in the test name. This is an older naming convention we no longer use because it became impractical. Just name the test functions like "test_domain_query" or "validate_server_404" or "check_json_parses" or something simple.

Commit Messages

Commit messages need only be one line because the substantive purpose of the contribution should be in the PR request. However, if you want them to have a body, that is fine too.

They take the general form of: "type(scope): description" where scope is optional.

Possible types are:

• feat Commits that add, adjust or remove a new feature.
• fix Commits that fix a feature.
• refactor Commits that rewrite or restructure code without altering behavior.
• style Commits that address code style.
• test Commits that add missing tests or correct existing ones.
• docs Commits that affect documentation.
• build Commits that affect build-related components.
• chore Miscellaneous commits e.g. modifying .gitignore, ... If there is nothing that works for you, make something up.

The scope provides additional contextual information and are optional.

A commit that introduce breaking changes should be indicated by a ! before the : in the subject line e.g. feat(common)!: all output is now toml

The description contains a concise description of the change and should convey the meaning of the commit. The description can reference an issue or commit for simplicity, e.g. fix: #137.

Before Submitting a PR

If you have just installed, run just pr_check. If you don't have just, run each of the commands under "pr_check" in the justfile (the file is easy to read).

Submitting a PR

When submitting the PR, submit it against the 'dev' branch (not the 'main' branch).