Self-explanatory RDAP

Fragmented ccTLD Systems: Why ICANN Must Address the Modeling Barrier

A proposal for “RDAP Next” — a unified, semantically consistent registry data model designed for automation, interoperability, and accountability.
  1. ICANN’s limited visibility into the diverse software environments powering ccTLD operations has led to systemic fragmentation — a critical obstacle to achieving unified and resilient global registry modeling.
  2. PostgreSQL’s support for JSON and JSONB field types enables flexible storage of semi-structured, TLD-specific identifier properties. These capabilities are essential for integrating heterogeneous data from multiple sources. However, the current RDAP vCard array format for postal addresses lacks structural consistency. For example, inconsistent use of country names versus ISO codes in RDAP responses undermines both machine readability and data reliability. Flattened JSON fields eliminate arbitrary nesting and reduce schema ambiguity.
  3. Operationally, some ccTLDs — such as the Netherlands — have implemented optimized practices, including indexed fields for postal code search. Next, RDAP output, especially for an entity nested at the table level, can be done at a single level. This facilitates both automatic parsing and user-friendly presentation. And finally, the table structure should enforce relationship-specific visibility in RDAP to reduce ambiguity and improve security.
  4. Data quality is further undermined by overreliance on registrar-supplied input. In many ccTLD ecosystems, registrars remain the primary data source, often without authoritative validation. This weakens data integrity and highlights the need for automated, standardized controls across the registry landscape.
  5. Domain lifecycle modeling also demands greater precision. For instance: a domain marked as pendingDelete should not simultaneously carry the redemptionPeriod status — and vice versa. These are mutually exclusive lifecycle states that should be modeled explicitly to prevent operational ambiguity.
  6. RDAP includes domain status codes such as transfer prohibited. However, unlike EPP, RDAP does not distinguish whether these restrictions are imposed by the registrar (client-side) or the registry (server-side). This lack of granularity and accountability having an unspecified actor may hinder operational clarity and complicate dispute resolution.
  7. Aligning the domain deletion phase (pendingDelete) with search engine deindexing elevates it from a purely technical state to a GDPR-relevant lifecycle boundary. This alignment creates legal, operational, and policy incentives to support data minimization, authoritative lifecycle closure, and responsible information removal.
  8. RDAP Next Modeling
    Legacy RDAP status labels are ambiguous and inconsistently applied. The proposed model introduces structured, descriptive status identifiers to ensure semantic clarity, interoperability, and consistency in automation.
    RDAP Status Remapping
    (in)active → dns_state (existence of a name server): dns_delegated / dns_undelegated
    redemption period → pending_redemption
    Prohibition Flags:
    When registry-controlled:
    * serverTransferProhibited
    * serverUpdateProhibited
    * serverDeleteProhibited
    * serverRenewProhibited
    Otherwise registrar-controlled:
    * clientTransferProhibited
    * clientUpdateProhibited
    * clientDeleteProhibited
    * clientRenewProhibited
    Note 1: Avoid using ambiguous statuses (e.g., locked or transfer prohibited) when more fine-grained flags are available.
    Note 2: If a domain has no DNS, it cannot use DMARC / SPF to defend against unauthorized email.

    Finally, URL paths use kebab-case, EPP elements use camelCase, and JSON fields and query parameters from space-separated lowercase to snake_case use. Furthermore fixed-order arrays for readability, and abuse, only at the table level, under the registrar.subject_tld_global_handle TEXT NOT NULL UNIQUE, subject_registrar_handle TEXT,
[
    {"metadata":[
        {"object_type":"domain",     
        "global_data_uri":[],
        "registry_data_uri":[],
        "registrar_data_uri":[],
        "tld_information_uri": [
            {"href":"https://rdap.hostingtool.nl/modeling_tld/index.php?tld=nl","media_type":"text/html","description":""}],
        "registrar_identifiers":[{"type":"IANA Registrar ID","identifier":"0000"}],
        "resource_upload_at":"2025-11-16T00:43:55Z"}]},
    {"domain":[
        {"ascii_name":"example.nl",
        "unicode_name":"example.nl",
        "dns_state":["dns_delegated"],
        "created_at":"2005-02-11T10:32:57Z",
        "latest_data_mutation_at":"2025-02-07T13:03:43Z"}]},
    {"relationships":[
        {"sponsor":[{
            "tld_global_handle":".",
            "source_handle":".",
            "subject_code":".",
            "organization_name":".",
            "presented_name":".",
            "email":[],
            "contact_uri":[],
            "country_code":".",
            "links":[],
            "data_uri":[],
            "publication_state":[]}]},
        {"registrant":[{"..."}]},
        {"actor":[{"..."}]},
        {"request_handling":[{"..."}]},
        {"issue_reporting":[{"..."}]},
        {"billing":[{"..."}]},
        {"escalation":[{"..."}]},
        {"reseller":[{"..."}]},
        {"registrar":[{"..."}]},
        {"registrar_abuse":[{"..."}]}]},
    {"nameservers":[{"ascii_name":"ns1.transip.nl"}]},
    {"dns_security":[{"rdap_dnssec_signed": true,
        "ds_data": [{"rdap_ds_algorithm_number": "13"}]}]}
]

Up-to-Date PostgreSQL Registry Table Definition (Since May 16, 2025)
Developed to replace legacy registry systems and support deployment on global RDAP servers, this schema upgrade enhances data clarity, consistency, and maintainability, representing a critical step forward in modernizing the RDAP protocol.

Machine-Readable IANA Root Zone Data:
My IANA root zone data is in a renewed format, to be retrieved from a designated IANA server and relying on user activity logging—including from unidentified internet users—for issue resolution, the tool avoids unnecessary traffic, reduces system overhead, and supports traceable, efficient operations.

RFC-allowed in the .nl Domain (Netherlands)

– Dutch SIDN maintains gTLD operational requirements for .amsterdam and .politie.
– The .frl root zone (Province of Friesland) is maintained in England and has been updated.
– If SIDN adopts 30-day pending redemption plus 5-day pending delete, it could work well.
– Final-stage domains for ccTLD: https://www.catchtiger.com/nl/domeinnaam-veilingen/
or for gTLD: https://www.expireddomains.net/expired-domains/.
– The .nl nameserver domain dns.nl has no mail-related DNS, leaving it unprotected against sender spoofing.
– During a ccTLD migration (e.g., with SIDN), each registry domain should include a registrant, contact objects, and DNS settings, and must avoid using ambiguous status values. Instead, clearly defined statuses (e.g., the EPP code serverTransferProhibited) should be applied to ensure transparent registrar responsibility.

RFC-allowed in the .fr Domain (France)

RFC-allowed in the .de Domain (Germany)