3.1. Common object attributes

Each managed object has the following attributes:

roid

Repository object identifier as eppcom:roidType. An id that is generated by the server during object creation. See also ROID.

clID

The handle of the current designated registrar as eppcom:clIDType.

crID

The handle of the registrar who created this object as eppcom:clIDType.

upID

The handle of the registrar who was the last to update this object as eppcom:clIDType.

crDate

The timestamp of the creation of this object in the repository as xs:dateTime.

upDate

The timestamp of the last update of this object as xs:dateTime.

trDate

The timestamp of the last transfer of this object as xs:dateTime.

authInfo

Authorization information as fredcom:authInfoType.

Starting from Release 2.47.0, authInfo has limited validity (TTL). The value can be configured, see AuthInfo TTL.

Create command containing authInfo attribute will run, but the authInfo is not written to the system.

It is not possible to get authInfo value using the info command. Validity can be checked by info command with authInfo parameter.

If authInfo is invalid, the server returns error 2202 Invalid authorization information.

Since Release 2.48.0 the authInfo length can be configured.

status

Current object status(es) (possible values are object-specific).

Statuses are set by the server and cannot be directly altered by a client.

An object can have one or more statuses but they can appear only in certain combinations which are not contradictory.

3.1.1. Domain names and hostnames

A domain name being registered or a name-server hostname being assigned to an nsset must be in the FQDN form and must comply with restrictions as follows.

Regular domain names (e.g. in the cz zone)

  • are composed of 2 labels separated with a period .,

  • the first label
    • contains only upper-case and lower-case letters of the English alphabet, digits (characters 0 through 9), and - [1] characters,

    • does not begin nor end with the - [1] character,

    • does not contain two or more consecutive - [1] characters,

    • has the length of 1–63 characters,

  • the second label is a TLD zone (e.g. cz),

  • may end with a period.

The register is case-insensitive and presents the domain names transformed to lower case.

ENUM domain names (e.g. in the 0.2.4.e164.arpa zone)

  • are composed of 6–15 labels separated with a period .,

  • each label preceeding the zone contains exactly one digit (characters 0 through 9),

  • ends with a Tier1 ENUM zone (e.g. 0.2.4.e164.arpa),

  • may end with a period.

The register is case-insensitive and presents the domain names transformed to lower case.

Note

Validation of the format of domain names may be configured by the Registry operator differently. The Registry operator is supposed to publish a document that declares the rules of registrar communication with the Registry, including a definition of valid domain names.

Hostnames

  • are composed of labels separated with periods .,

  • labels
    • contain only upper-case and lower-case letters of the English alphabet, digits (characters 0 through 9), and - [1] characters,

    • do not begin nor end with the - [1] character,

    • have the length of 1–63 characters,

  • may end with a period,

  • must not exceed the total length of 255 characters (including delimiter periods and the final period).

3.1.2. Handles of contacts, nssets and keysets

Handles of contacts, name-server sets and key sets:

  • contain only upper-case and/or lower-case letters of the English alphabet, digits (characters 0 through 9), and - [1] characters,

  • do not begin nor end with the - [1] character,

  • do not exceed the length of 30 [2] characters.

The register is case-insensitive and presents the identifiers transformed to upper case.

Note

Validation of the format of handles may be configured by the Registry operator differently. The Registry operator is supposed to publish a document that declares the rules of registrar communication with the Registry, including a definition of valid handles.

3.1.3. Timestamps

Timestamps are provided in local time of the FRED EPP server with an offset from UTC in compliance with RFC 3339 and xs:dateTime syntax.