rfc-5144

A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS)

A. Newton, M. Sanz
date2008-02 streamIETF areaapp wgcrisp statusPROPOSED STANDARD pages17 canonicalhttps://www.rfc-editor.org/rfc/rfc5144 doi10.17487/RFC5144 errataview
This document describes a lightweight domain availability service using the Internet Registry Information Service (IRIS) framework and the data model of the IRIS Domain Registry (DREG) service. [STANDARDS-TRACK]

Extracted elements (20)

design-rationale §1

DCHK uses a strict subset of the DREG data model so that implementors can directly reuse DREG code paths and operators can deploy the service in the same server process as DREG or in a separate process/machine, with either scenario transparent to the end user.

dns, registry

design-rationale §3.3

The XPC transport is described as preferable to the BEEP transport for DCHK, though both remain optional beyond the mandatory IRIS-LWZ implementation, reflecting a preference for lighter-weight transports for a high-volume availability service.

dns

interoperability-note §1

DCHK's data model is a strict subset of the DREG data model, enabling seamless integration between the domain availability service and the full DREG service so users can find availability status and reference full registration information in DREG.

dns, registry

normative-requirement §4 MUST

All date and time elements use the XML Schema 'dateTime' type; if their contents are UTC timestamps, they MUST be specified using the capitalized 'Z' indicator rather than lowercase 'z'.

dns

normative-requirement §3.3 MUST

All DCHK clients and servers MUST implement the Lightweight UDP Transport Protocol (IRIS-LWZ). Use of other transports such as IRIS-XPC or BEEP is optional and at the discretion of the server operator.

dns, udp

normative-requirement §3.1.1.1 MUST

Each <description> element within a domainStatusType MUST have a 'language' attribute describing the language of the description element.

dns

normative-requirement §3.4.1 MUST

The application service label associated with the DCHK registry type MUST be 'DCHK1', which is the abbreviated form of the URN urn:ietf:params:xml:ns:dchk1.

dns, registry

normative-requirement §3.4.2 MUST

The bottom-up alternative resolution method MUST be identified as 'bottom' in IRIS URIs, and its process is identical to the 'bottom' process described by RFC 3982.

dns

normative-requirement §3.1.1 MUST

The contents of the <domainName> element MUST be a domain name as specified by RFC 1035.

dns

normative-requirement §3.1.1 MUST

The <registrationReference> element's referent MUST be either a <domain> as defined in Section 3.1.1 or a <domain> as defined by RFC 3982 (DREG), intended to point to the downstream registration reference.

dns, registry

normative-requirement §3.4.3 MUST

The top-down alternative resolution method MUST be identified as 'top' in IRIS URIs, and its process is identical to the 'top' process described by RFC 3982.

dns

protocol-element §3.1.1.1

Each domainStatusType element may contain optional child elements <appliedDate>, <ticket>, <description> (with required 'language' attribute), and <subStatus> (with required 'authority' attribute), plus optional attributes 'actor' (registry/registrar/registrationServiceProvider), 'disposition' (pending/prohibited), and 'scope'.

dns, registry

protocol-element §3.1.1

The <domain> result element represents an instance of a domain assignment and includes child elements: <domainName> (required, RFC 1035 domain name), <idn> (optional, nameprep form), <status> (optional, domain status), <registrationReference>, <createdDateTime>, <initialDelegationDateTime>, <expirationDateTime>, <lastDatabaseUpdateDateTime>, and <iris:seeAlso>.

dns, registry

protocol-element §3.1.2

The <lookupEntity> query supports two entity classes: 'domain-name' (a fully qualified RFC 1035 domain name) and 'idn' (a fully qualified nameprep-form domain name per RFC 3491), both yielding a <domain> result.

dns, registry

protocol-element §3.1.1

The <status> element within <domain> supports the following status types: <active>, <inactive>, <dispute>, <addPeriod>, <renewPeriod>, <autoRenewPeriod>, <transferPeriod>, <redemptionPeriod>, <policyCompliant>, <policyNoncompliant>, <reserved>, <create>, <delete>, <renew>, <restore>, <transfer>, <update>, and <other>.

dns, registry

registry §5.4

IANA registered the BEEP Profile URI http://iana.org/beep/iris1/dchk1 in addition to the registration provided in IRIS-BEEP (RFC 3983).

registry, dns

registry §5.3

IANA registered the S-NAPTR application service label 'DCHK1' per the IANA considerations defined in IRIS (RFC 3981).

registry, dns

registry §5.1

IANA registered the XML namespace URN urn:ietf:params:xml:ns:dchk1 and the XML schema URN urn:ietf:params:xml:schema:dchk1 in the IETF XML Registry per RFC 3688.

registry, dns

security-consideration §6

Being a proper subset of RFC 3982 (DREG), the DCHK registry introduces no security considerations beyond those documented in RFC 3981 (IRIS core protocol). Implementors should refer to RFC 3981 for the applicable security analysis.

security, dns

wire-format §3.2

The DCHK formal XML syntax is expressed in XML Schema notation with target namespace urn:ietf:params:xml:ns:dchk1, importing the IRIS namespace urn:ietf:params:xml:ns:iris1. The <domain> element is of type dchk:domainType, which extends iris:resultType.

dns, registry