The original Shared Registry System Protocol (version 0.9) was
developed by CORE together with Emergent, Inc. in the context of the creation
of a registry system suitable for the registration of the anticipated seven new
top level domains. Due to the political change, CORE was unable to start the
registration of those domains. Instead, CORE got the opportunity to register
COM, NET and ORG (CNO) domains via the registry spin-off of Network Solution
Inc. As the infrastructure had already been set up and was working, CORE
decided to extend the registry system instead of the development of a new
system specific to CNO domains. The server system was extended to synchronize
its database with NSIRegistry’s via the Registry Registrar Protocol (RRP). The
payload of the SRSP was modified to conform to the new needs. The development
was performed by Computer Service Langenbach GmbH, and the SRSP got the version
number 1.0.

This document describes the version 1.1 of the protocol, which is
mostly a cosmetic update of the payload and does not introduce much new
functionality.

2.2. Protocol Structure

The protocol defines the communication between a client (operated
by the registrar) and the server (operated by the registry). It is
message-based, i.e. one side (either the server or the client), compiles a
packet with its data (called payload) and sends it to the opposite side. The
receive and transmit channels are not synchronized: The client does not need to
wait for the server’s answer to send additional requests; the server does not
need to send the responses immediately or in the order in which the client sent
the requests. But it is guaranteed that the server does not send responses not
related to the particular client, i.e. the client does not receive unexpected
responses. Due to the transaction management, situations where the communication
fails can be handled (see below for details).

The protocol consists of two layers. The transport layer defines
the communication between the client and the server. It is also responsible for
the client/server authentication and for the secure transmission of the payload
data.

The payload represents the application layer. It defines the
requests from the clients and the responses from the server. A built-in
transaction management allows the processing of asynchronous, interleaved
requests.

For the purpose of domain transfers, it is required that the
registry can notify the registrar about certain events. This does not fit in
mentioned request-reply schema. Therefore, the notification is handled
separately, but by using the same technologies: The server uses the e-mail
transmission variant for the notification. The destination e-mail address is a
fixed address specified by the registrar. The format of the payload is the
same, although different keys are used.

2.1.2.1. Transmission Layer

The transmission layer is responsible for the transfer of the
payload to the server and back to the client. The SRSP defines two different
variants for this transfer: by e-mail and by a TCP connection. In both cases,
the authentication and the secure transmission is done by digital signatures[1].
The format of the signatures conforms to the standard defined by [PGP5].

2.1.1.2.1.1. Digital Signatures

For the attachment of the signature to the payload, the PGP
specific variant of the S/MIME standards is used, as described in [RFC1847] and
[RFC2015]. The following content-type specific attributes must be used in the
context of this protocol:

micalgpgp-sha1

protocolapplication/pgp-signature

The keys must use the DSS/Diffie-Hellman algorithms. Keys of
other types are not accepted. Depending on whether the message is sent to the
server or to the client, it is signed by different keys.

On the server side, a registry specific key is used to sign the
messages to the clients. On the client side, multiple keys can be used. There
is a super contact with a corresponding key, which is maintained by the
registry. An administrative contact and additional agents
with their keys can be added by registrar at will (see modify
registrar below).

2.1.2.2.1.2. Transmission by E-Mail

The PGP-signed payload is sent to a specific address at the
registry. The registry uses the contents of the reply-to
field or, if it does not exist, the contents of the from
field specifies the e-mail address, to which the server’s response is sent
back. The e-mail address is not used to authenticate the user — the registrar-id
field together with the key used for the signature identifies and authenticates
the user.

Due to the mechanisms behind the e-mail transport,there is a risk of wrongly delivered e-mails
and eavesdropping. Although protocol does not transport very sensitive data, it
is recommended not to use this transmission method.

2.1.3.2.1.3. Transmission by TCP

In this variant, the messages are transported between client and
server via a TCP connection. Port number 362/service name srssend
has been assigned for that service [IANA-PORTS].

For transmission, the payload is signed according to the rules
above. A message is constructed according to the syntactic rules specified in
[RFC822] and [RFC1521], with the difference that the header consists only of
MIME related fields, i.e., in relation to this application, exactly of the content-type field.

The message is sent through the TCP connection without additional
information (length or termination mark). Since the outermost content-type is
always a multipart type (multipart/signed),
the body of the message always contains MIME boundaries. The reader can easily
detect the end of the message by watching the input stream for the closing
boundary (it differs from intermediate boundaries by two additional hyphens).

2.1.4.2.1.4. Payload Encoding

The payload has the content-type text/x-srs-data.
No MIME content transfer encoding or compression may be applied to the payload.

2.2.2.2. Payload

2.2.1.2.2.1. Registry Data Model

Before describing the requests of the client and the responses of
the server, it is important to understand the model on which the registry
operates.

The registry stores objects. An object is, in this context, a
collection of related data. Four different object types exist: domains,
contacts, hosts and registrars (explained later). Each object has a unique
identifier. This identifier is either a certain part of the data (in case of
the domain object, it is the domain name), or it is a unrelated text label, usually
called handle.

object type

unique identifier

domain

the domain name, case insensitive

contact

text label COCO-N (where N is a positive number)

Host

text label COHO-N (where N is a positive number)

registrar

text label CORE-N (where N is a positive number)

Objects can reference each other, e.g. domains reference hosts
for the purpose of specifying the name servers which manage the corresponding
zones. Referenced objects cannot be deleted, as the referencing objects would
become invalid. A change to a referenced object indirectly modifies all
referencing objects[2], e.g.,
changing a host’s IP address results in a change of all domains referencing it:
The next build of the registry’s master zone file would contain the new IP
address for those domains.

The objects are shared among the registrars, i.e., any registrar
can view or use any object. Domain, contact and host objects have a property of
the managing registrar. Each of those objects is managed by the registrar who
created it. The property restricts the right to modify a certain object: only
the managing registrar may change it. The managing registrar of domains is
changed during the transfer domain process. The managing
registrar of contacts and hosts cannot be changed. Even in the case of a domain
transfer between registrars, the contacts and hosts referenced in the domain
stay at the loosing registrar. The gaining registrar can continue to use these
contacts and hosts or it can create new ones and update the domain accordingly.

2.2.1.1.2.2.1.1. The Domain Object

The domain object stores the domain related data, which is

-the domain name itself, fully qualified

-the owner of the domain

-the administrative, technical and zone contact of the
domain (the tasks of these contacts is out of the scope of this document)

-up to twelve hosts

-the registration period in years

-the state of the domain

The contacts (excluding the owner) and hosts are stored as
references to the corresponding objects. The owner is directly stored in the
domain object. It contains the data of a given contact object at the point of
time of the creation or modification of the domain object. Later changes to the
contact object do not modify the contents of the domain object. Although the
domain object stores a reference to the owner contact object, the reference has
only informational character: It just informs the registrar about the origin of
the owner data.

The registration period determines how long the domain will
operate without further interaction and how much is deducted from the
registrar’s account.

The state has one of the four possible values:

reserved

the domain is registered but no entry
is generated in the registry’s master zone file.

production

the domain is registered and fully
functional

expired

the registration period has expired
(the exact consequences are out of the scope of this document, limited
modification rights may apply)

hold

the domain is currently matter of a
dispute (the exact consequences are out of the scope of this document,
limited modification rights may apply)

2.2.1.2.2.2.1.2. The Contact Object

The contact object stores the identity and various types of
addresses of an individual or of an organization. It contains the following
data:

-a flag which identifies whether the contact is an
individual or an organization

-the first name, the last name and the title of the
individual

-the name of the organization

-The "real world" address: two free form
address lines (typically used for specification of the street, but may contain
a more specific or different inner-city address), the city (including the
postal code), the state and the country.

-the phone number
(with international area code)

-the fax number (with international area code)

-the e-mail address

Although it should be avoided by the registrar, it is possible to
create multiple contact objects for exactly the same person or organization.

2.2.1.3.2.2.1.3. The Host Object

The host object describes a name server, which is able to respond
to DNS requests ([RFC1035]) for those domains which reference this object. The
following data is stored in the object:

-the domain name of the name server

-the IP address of the name server (optional)

-a reference to a contact object (identifying a person
or organization, who/which is responsible for the name server; optional)

Although it should be avoided by the registrar, it is possible to
create multiple host objects with the same domain name or IP address. Please
note that the host object does not contain a reference to a domain object, so a
domain object may be deleted even if a host exists that is located inside (in
the sense of the domain name system) that domain.

2.2.1.4.2.2.1.4. The Registrar Object

The registrar object is maintained by the registry. Some parts of
the data are exposed to the registrars, and a registrar is able to modify some
aspects of his own data. The data which is exposed is:

-the name and the handle of the registrar

-the status (active, suspended
or defunct)

-the account balance

-the super, administrative and agent contacts, along
with PGP related information and permissions.

2.2.2.2.2.2. Syntax

The payload consists of readable text, encoded by the 7-Bit ASCII
encoding. It represents a set of key-value pairs. A single key may appear
multiple times. In this case, each appearance of the key represents an
independent record and is not the continuation of a previous key-value pair.
The order of differing keys is irrelevant. In the case of multiple identical
keys, the order is important.

Two representations exist for a key-value pair. They differ only
syntactically: the first variant is more suitable for single line entries. If
it starts with a quote, that quote must be doubled to make the entry different
to the second variant. The value may continue on the next line, but the newline
must be prefixed by a backslash (the backslash/newline combination does not
become part of the value). Whitespace that appears at the start or at the end
of the value is ignored.

The second form is a multi-line form which is used for lengthy
data, e.g. an ASCII encoded PGP public key. It starts and ends with a double
quote. Any non double-quote character between them is allowed, even a newline.
The quotes are not part of the value.

(name
denotes a non-terminal symbol, | separates
alternatives, x
denotes a literal character or character sequence, 0xNN the hexadecimal code of
a character, [ from .. to ] a sub-range of the
ASCII character set, ? zero or one
occurrences, + one or more occurrences, *
zero or more occurrences)

2.2.3.2.2.3. Transaction Mechanism

The protocol uses transaction identifiers to enable the tracking
of requests. The transaction identifier is specified by the client via the transaction-id key. The server uses that
identifier in every response, so the client can associate these responses to
the corresponding requests.

The server reacts to a normal request by sending two responses.
The first is an acknowledge (response-type: ack)
and is sent immediately after the reception at the server. After the processing
of the request, the server sends the results back to the client (response-type:
reply).

In both transmission variants (e-mail and TCP), it may happen
that the communication fails — either the e-mail is lost or the TCP connection
is interrupted, maybe just in the moment of sending a request or receiving a
response. In the case of requests which do not modify the state of the
registry, the client has to repeat the request, since the server does not back
up the results of such requests.

For requests that modify the state of the registry, the server
saves the results of processed requests for a certain time, at least for a day.
Two special request exist to help the client on its recovery: With the status request, the client is able to retrieve
the status of a specific request. The server responses either with the result
of the request, with the current processing state or with the information that
no request with the given transaction identifier exist (either the request has
not yet been received or it is lost).

The other special request is the query
request. By this request, the client can ask the server to send back a list of
transaction identifiers of requests, whose submission or completion time falls
in a specified period and that have the specified processing state.

Each registrar has its own name space for the transaction
identifiers. Therefore it is not possible to request information about
transactions of different registrars.

2.2.4.2.2.4. Common Request Keys

All requests sent to the server must contain at least the
following four key: registrar-id, payload-version,
transaction-id
and request-type.

The registrar-id key identifies the registrar. It
is also used for authentication in combination with the signature of the
transmission layer.

the payload-version key enables the server to
identify the version of the payload and to react differently to different
client software versions.

The transaction-id key represents the transaction
identifier of the request, as discussed above.

The request-type key describes the action the
server should perform on behalf of the client.

2.2.5.2.2.5. Common Response Keys

All responses sent from the server contain at least the following
three keys: registrar-id, transaction-id and response-type.

The registrar-id identifies the registrar, whose
request is replied.

The transaction-id identifies the request the
response corresponds to.

The response-type tells whether the response is an
intermediate (acknowledge) or the final response (reply).

2.2.6.2.2.6. Acknowledge Responses

The acknowledge response is immediately sent by the server to
notify that the request has been received, that it is syntactically correct,
that the client authentication was successful, that it conforms so far to the
protocol and that it can be queued for processing. It does, however, not give
any clues whether the processing of the request will succeed or fail. If one of
the conditions above is not satisfied, a reply is sent back instead, indicating
the corresponding error.

The client does not need to take this response into account, but
it can use this message for the internal management of the requests eventually.

The acknowledge response has the value ack
for the response-type key. No additional keys appear in this message.

2.2.7.2.2.7. Replies

Any reply contains the request-state key,
indicating whether the request was successfully (value succeeded)
processed or whether the processing failed for any reason (value failed).

If the processing is successful, the reply contains the success
key, which contains an informational message.

If the processing fails, the reply contains a list of errors
which were detected. This list is not necessarily complete, i.e., if these
errors are corrected, it is not guaranteed that the new request will succeed.

The errors are reported by the error-code
and error-text
keys. The n-th error-code key corresponds to the n-th error-text
key.

2.2.8.2.2.8. Requests and their Replies

The protocol defines the following requests:

domain related

create
domain

R

creates a new domain object

modify
domain

R

modifies a domain, including owner
changes

delete
domain

R

deletes an existing domain

renew domain

R

extends the registration period of a
domain

transfer
domain

R

either initiates an incoming domain
transfer or confirms (positively or negatively) an outgoing domain transfer

complete
transfer

R

completes an incoming domain transfer

inquire
domain

requests the data of a domain object

contact related

create
contact

R

creates a new contact object

modify
contact

R

modifies an existing contact

delete
contact

R

deletes an existing contact

inquire
contact

requests the data of a contact object

host related

create host

R

creates a new host object

modify host

R

modifies an existing host

delete host

R

deletes an existing host

inquire host

requests the data of a host object

registrar related

modify
registrar

R

modifies the exposed parts of a
registrar object

inquire
registrar

requests the exposed data of a
registrar object

transaction management

status

requests the status of a specified
request

query

requests all the transaction
identifiers of the requests of a specified period

The replies of the requests marked with R are recorded and can be
queried by the status and query
requests.

2.2.8.1.2.2.8.1. Complete Transfer Request

General information:

request type:

complete
transfer

recorded:

yes

The complete transfer request is the final step in
the process for an incoming domain transfer. The request and reply keys are
identical to the create domain request.

Special request keys:

domain-name

M

the domain name

owner-contact

M

the new owner (approved-owner-change must be Y to come
into effect)

admin-contact

M

the new administrative contact

tech-contact

M

the new technical contact

zone-contact

M

the new zone contact

approved-owner-change

M

flag, whether an owner change should be performed (see
also the modify domain request)

ns1-host
ns2-host
...
ns12-host

O

either none or at least two name servers must be
specified. If no name server is specified, the domain state must be set to reserved.

domain-state

M

either production or reserved.
Other states may not be assigned by a registrar.

(M mandatory key, O optional key, D disallowed)

Special reply keys:

expiration-date

the point of time when the domain expires

costs

the costs of the transfer

2.2.8.2.2.2.8.2. Create Contact Request

General information:

request type:

create
contact

recorded:

yes

The create contact request creates a new contact
object in the registry’s database.

Special request keys:

individual

M

determines whether this contact describes an individual
(Y) or an organization (N)

fname

M/D

the first name of the individual

lname

M/D

the last name of the individual

title

O/D

the title of the individual

organization

O/M

the organization (may be specified for an individual also)

address-1

M

the city-local address

address-2

O

additional address

city

M

the city where the individual/organization is located in

postal-code

M

the postal code of the city

state

O

the state where the city is located in

country

M

the country the city is located in

phone

M

the phone number

fax

O

the fax number

email

M

the e-mail address

(M mandatory key, O optional key, D disallowed)

Special reply keys:

handle

the handle for the contact, assigned by the server

2.2.8.3.2.2.8.3. Create Domain Request

General information:

request type:

create
domain

recorded:

yes

The create domain request creates a new domain.
The name may not exist when the request is processed.

Special request keys:

domain-name

M

the domain name

owner-contact

M

the owner

admin-contact

M

the administrative contact

tech-contact

M

the technical contact

zone-contact

M

the zone
contact

ns1-host
ns2-host
...
ns12-host

O

either none or at least two name servers must be
specified. If no name server is specified, the domain state must be set to reserved.

domain-state

M

either production or reserved.
Other states may not be assigned by a registrar.

period

O

the registration period. If omitted, a registry specific
default period is used.

(M mandatory key, O optional key, D disallowed)

Special reply keys:

expiration-date

the point of time when the domain expires

costs

the costs of the creation

2.2.8.4.2.2.8.4. Create Host Request

General information:

request type:

create
host

recorded:

yes

The create host request creates a new host object
in the registry’s database.

Special request keys:

contact

O

a contact that is responsible for the host

domain-name

M

the domain name of the host

ip-address

O

the IP address of the host

(M mandatory key, O optional key, D disallowed)

Special reply keys:

handle

the handle for the host, assigned by the server

2.2.8.5.2.2.8.5. Delete Contact Request

General information:

request type:

delete
contact

recorded:

yes

The delete contact request deletes an existing
contact object in the registry’s database. The object may not be referenced by
other objects, i.e., may not appear in a host contact or domain contact (as the
owner or the admin, technical or zone contact). The object must be managed by
the registrar.

Special request keys:

handle

M

the contact handle of the object

(M mandatory key, O optional key, D disallowed)

2.2.8.6.2.2.8.6. Delete Domain Request

General information:

request type:

delete
domain

recorded:

yes

The delete domain request deletes an existing
domain object in the registry’s database. The object must be managed by the
registrar. Depending on the registry’s policy, costs are refunded if a domain
is deleted a short time after the creation.

Special request keys:

domain-name

M

the name of the domain to be deleted

(M mandatory key, O optional key, D disallowed)

Special reply keys:

costs

the costs (refunds) of the deletion

2.2.8.7.2.2.8.7. Delete Host Request

General information:

request type:

delete
host

recorded:

yes

The delete host request deletes an existing host
object in the registry’s database. The object may not be referenced by other
objects, i.e., may not appear in a domain as a name server. The object must be
managed by the registrar.

Special request keys:

handle

M

the host handle of the object

(M mandatory key, O optional key, D disallowed)

2.2.8.8.2.2.8.8. Inquire Contact Request

General information:

request type:

inquire
contact

recorded:

no

The inquire contact request returns information
about an existing contact object. Depending on the existence and the value of
the list
key, either the contact details or its usage in domains and hosts is returned.

Special request keys:

handle

M

the contact handle of the object

list

O

what kind of information should be returned. If key does
not exist or is empty, then details about the contact are returned (case 1).
If the value is equal to domains, a list of
domains, which use this contact as the owner, the administrative, technical
or zone contact, is returned (case 2). If the value is equal to hosts,
a list of hosts using the object as a contact is returned (case 3).

(M mandatory key, O optional key, D disallowed)

Special reply keys (case 1):

handle

the handle of the object

individual

determines whether this contact describes an individual
(Y) or an organization (N)

fname

the first name of the individual

lname

the last name of the individual

title

the title of the individual

organization

the organization

address-1

the city-local address

address-2

additional address

city

the city where the individual/organization is located in

postal-code

the postal code of the city

state

the state where the city is located in

country

the country the city is located in

phone

the phone number

fax

the fax number

email

the e-mail address

managing-registrar-id

the managing registrar

created

the point of time when the object was created

created-by

the registrar who created the object (typically identical
to managing-registrar-id)

last-modified

the point of time when the object was modified at last. It
appears only after the first modification.

last-modified-by

the registrar who modified the object at last (typically
identical to managing-registrar-id). It appears only
after the first modification.

owner: determines whether this contact describes an
individual (Y) or an organization (N)

fname

owner: the first name of the individual

lname

owner: the last name of the individual

title

owner: the title of the individual

organization

owner: the organization

address-1

owner: the city-local address

address-2

owner: additional address

city

owner: the city where the individual/organization is
located

postal-code

owner: the postal code of the city

state

owner: the state where the city is located in

country

owner: the country the city is located in

phone

owner: the phone number

fax

owner: the fax number

email

owner: the e-mail address

owner-contact-origin

the handle of the contact which was used as the source of
the owner data

admin-contact

the handle of the administrative contact

tech-contact

the handle of the technical contact

zone-contact

the handle of the zone contact

managing-registrar-id

the managing registrar

ns1-host
ns2-host
...
ns12-host

the handles of the name servers

domain-state

the current domain state

created

the point of time when the object was created

created-by

the registrar who created the object (typically identical
to managing-registrar-id)

last-modified

the point of time when the object was modified at last. It
appears only after the first modification.

last-modified-by

the registrar who modified the object at last (typically
identical to managing-registrar-id). It appears only
after the first modification.

2.2.8.10.2.2.8.10. Inquire Host Request

General information:

request type:

inquire
host

recorded:

no

The inquire host request returns information about
an existing host object. Depending on the existence and the value of the list
key, either the host details or its usage in domains is returned.

Special request keys:

handle

M

the host handle of the object

list

O

what kind of information should be returned. If key does
not exist or is empty, then details about the host are returned (case 1). If
the value is equal to domains, a list of
domains, which use this host as a name server, is returned (case 2).

(M mandatory key, O optional key, D disallowed)

Special reply keys (case 1):

handle

the handle of the object

contact

a contact that is responsible for the host

domain-name

the domain name of the host

ip-address

the IP address of the host

created

the point of time when the object was created

created-by

the registrar who created the object (typically identical
to managing-registrar-id)

last-modified

the point of time when the object was modified at last. It
appears only after the first modification.

last-modified-by

the registrar who modified the object at last (typically
identical to managing-registrar-id). It appears only
after the first modification.

Special reply keys (case 2):

domain-name

a domain name. This key is repeated for each domain.

count

the number of domains that use the host

2.2.8.11.2.2.8.11. Inquire Registrar Request

General information:

request type:

inquire
registrar

recorded:

no

The inquire registrar request returns some information about a registrar. If the list
key is not present or has an empty value, information about the users and their
public keys is returned (case 1). If the value of the list key is domains,
the domains managed by the registrar are listed (case 2). If the value is hosts,
the hosts managed by the registrar are listed (case 3). If the value is contacts,
the contacts managed by the registrar are listed (case 4).

Special request keys:

handle

M

the handle of the registrar

list

O

whether the contacts, hosts or domains of the registrar
should be listed

(M mandatory key, O optional key, D disallowed)

Special reply keys (case 1):

handle

the handle of the registrar

organization

the name of the registrar

reg-admin-permissions

the allowed request types

reg-admin-contact

the contact handle

reg-admin-auth-type

the type of the public key

reg-admin-auth-key-info

information about the public key

reg-agent-permissions

the allowed request types

reg-agent1-contact
...
reg-agent12-contact

the contact handles

reg-agent1-auth-type
...
reg-agent12-auth-type

the types of the public keys

reg-agent1-auth-key-info
...
reg-agent12-auth-key-info

information about the public keys

reg-super-permissions

the allowed request types

reg-super-contact

the contact handle

reg-super-auth-type

the type of the public key

reg-super-auth-key-info

information about the public key

reg-state

the state of the registrar

transaction-credit

the current balance of the account

created

the point of time when the object was created

created-by

the registrar who created the object (typically identical
to managing-registrar-id)

last-modified

the point of time when the object was modified at last. It
appears only after the first modification.

last-modified-by

the registrar who modified the object at last (typically
identical to managing-registrar-id). It appears only
after the first modification.

Special reply keys (case 2):

domain-name

a domain name. This key is repeated for each domain.

count

the number of domains

Special reply keys (case 3):

handle

a host handle. This key is repeated for each host.

count

the number of hosts

Special reply keys (case 4):

handle

a contact handle. This key is repeated for each host.

count

the number of contacts

2.2.8.12.2.2.8.12. Modify Contact Request

General information:

request type:

modify
contact

recorded:

yes

The create contact request modifies an existing
contact object. The object must be managed by the registrar.

Special request keys:

handle

M

the handle of the contact

individual

M

determines whether this contact describes an individual
(Y) or an organization (N)

fname

M/D

the first name of the individual

lname

M/D

the last name of the individual

title

O/D

the title of the individual

organization

O/M

the organization (may be specified for an individual also)

address-1

M

the city-local address

address-2

O

additional address

city

M

the city where the individual/organization is located in

postal-code

M

the postal code of the city

state

O

the state where the city is located in

country

M

the country the city is located in

phone

M

the phone number

fax

O

the fax number

email

M

the e-mail address

(M mandatory key, O optional key, D disallowed)

2.2.8.13.2.2.8.13. Modify Domain Request

General information:

request type:

modify
domain

recorded:

yes

The modify domain request changes contacts and name servers of the given domain.
Data from the given owner contact is either copied partially or fully into the
domain object, depending on the value of the approved-owner-change
key. If the value is Y, all fields are copied.
If the value is N, the following fields are copied: title,
email,
phone
and fax.

Special request keys:

domain-name

M

the domain name

owner-contact

O

the new owner (effect depends on the approved-owner-change
key; see above)

admin-contact

O*

the new administrative contact

tech-contact

O*

the new technical contact

zone-contact

O*

the new zone contact

approved-owner-change

O*

flag, whether an owner change should be performed

ns1-host
ns2-host
...
ns12-host

O

either none or at least two name servers must be specified.
If no name server is specified, the domain state must be set to reserved.

domain-state

O*

either production or reserved.
Other states may not be assigned by a registrar.

(M mandatory key, O optional key, D disallowed)

* not changed if key is omitted

2.2.8.14.2.2.8.14. Modify Host Request

General information:

request type:

modify
host

recorded:

yes

The modify host request modifies an existing host
object. The object must be managed by the registrar.

Special request keys:

Contact

O

a contact that is responsible for the host

domain-name

M

the domain name of the host

ip-address

O

the IP address of the host

(M mandatory key, O optional key, D disallowed)

2.2.8.15.2.2.8.15. Modify Registrar Request

General information:

request type:

modify
host

recorded:

yes

The modify registrar request enables the registrar
to modify some aspects of his data stored in the registry system, mainly the
keys and the identities of the staff working with the SRS.

Special request keys:

Handle

M

the handle of the registrar

Organization

O*

the name of the registrar

reg-admin-contact

O*

the contact describing the administrator

reg-admin-auth-type

O*

the type of the authorization the administrator uses

reg-admin-auth-key

O*

the public key of the administrator

reg-agent1-contact
...
reg-agent12-contact

O*

the contacts describing the agents

reg-agent1-auth-type
...
reg-agent12-auth-type

O*

the types of the authorizations of the agents

reg-agent1-auth-key
...
reg-agent12-auth-key

O*

the public keys of the agents

reg-super-contact

O*

the contact describing the super administrator

reg-super-auth-type

O*

the type of the authorization the super administrator uses

reg-super-auth-key

O*

the public key of the super administrator

(M mandatory key, O optional key, D disallowed)

* if omitted, the corresponding entry is not modified

2.2.8.16.2.2.8.16. Query Request

General information:

request type:

query

recorded:

no

The query request returns information about
requests submitted/completed in a given period of time. Only those requests are
returned, whose results were recorded previously. See the general
information/recorded entries in the description of the requests
whether the results are recorded or not. The requests are returned in
chronological order regarding to the submission date.

Special request keys:

completed-before

O

if present, it restricts the output to those requests
which were completed before the given date (including)

completed-after

O

if present, it restricts the output to those requests
which were completed after the given date (including)

submitted-before

O

if present, it restricts the output to those requests
which were submitted before the given date (including)

submitted-after

O

if present, it restricts the output to those requests
which were submitted after the given date (including)

request-state

O

if present, it restricts the output to those requests
which are in the given state.

(M mandatory key, O optional key, D disallowed)

Special reply keys:

request-transaction-id

a transaction identifier that matches the condition(s).
This key is repeated for each request

count

the number of requests matching the condition(s)

2.2.8.17.2.2.8.17. Renew Domain Request

General information:

request type:

renew
domain

recorded:

yes

The renew domain request extends the registration
period of a domain.

Special request keys:

domain-name

M

the domain name

period

M

the extension of registration period.

(M mandatory key, O optional key, D disallowed)

Special reply keys:

expiration-date

the point of time when the domain expires

costs

the costs of the renewal

2.2.8.18.2.2.8.18. Status Request

General information:

request type:

status

recorded:

no

The status request enables the client to retrieve
information about requests sent to the server earlier. If the request has been
finished, the result of it is returned. If the specified transaction identifier
is unknown to the server, the server returns a failed
request state with the error-code key indicating the problem.

Special request keys:

transaction-id

M

In contrast to other requests, not a new transaction
identifier should be specified here, but the transaction identifier of the
request to be inspected instead.

(M mandatory key, O optional key, D disallowed)

Special reply keys:

request-state

If the request related to the given transaction identifier
does not exist, failed is returned and error code -270 is returned. If the request has been
received, but not yet been processed, either pending
or in-process
is returned. If the request has been processed, the key contains the
corresponding value of the request’s reply.

(other)

see the description of the specific request

2.2.8.19.2.2.8.19. Transfer Domain Request

General information:

request type:

transfer
domain

recorded:

yes

The transfer domain request is used in the process
of the transfer of a domain from one registrar to another registrar. The
request is both used for incoming and outgoing transfers. See below for the
exact process.

Special request keys:

domain-name

M

the domain name

action

M

the action to be performed.

(M mandatory key, O optional key, D disallowed)

2.2.9.2.2.9. Notifications

During the domain transfer process, the server sends
notifications to the registrar. The notifications use the e-mail transmission
variant and the payload layer. The registrar may react upon the notifications
by sending normal requests to the server via one of its clients. The
notification contains at least two keys:

payload-version

identifies the version of the payload used for the
notification

notification-type

the type of notification

2.2.9.1.2.2.9.1. Init-Transfer Notification

General information:

notification type:

init-transfer

The init-transfer notification is sent to the
loosing registrar to inform that a domain transfer process has been started for
the given domain.

Additional keys:

domain-name

the name of the domain to be transferred

gaining-registrar

the registrar who initiated the transfer

time-out-date

point of time until the loosing registrar can react

2.2.9.2.2.2.9.2. Transfer-Acknowledge Notification

General information:

notification type:

transfer-acknowledge

The transfer-acknowledge notification is sent to
the gaining registrar to inform about the decision of the loosing registrar (or
the registry in case of a timeout).

Additional keys:

domain-name

the name of the domain to be transferred

transfer-approved

tells whether the loosing registrar has acknowledged the
transfer positively or negatively.

time-out-date

point of time until the gaining registrar can react

2.2.9.3.2.2.9.3. Transfer-Finish Notification

General information:

notification type:

transfer-finish

The transfer-finished notification is sent to the
loosing registrar (and to the gaining registrar in case of a time-out) to
inform about the final result of the domain transfer process.

Additional keys:

domain-name

the name of the domain

transfer-performed

tells whether the transfer has been performed or not

2.2.10.2.2.10. Common Data Types

2.2.10.1.2.2.10.1. Handles

SRSP specific handles share a common format: a prefix followed by
a number. The prefix is CORE-, COCO- and COHO-
for registrar, contact and host handles, respectively. The case of the prefixes
does not matter. Handles are always assigned by the server (or, for the
registrar handle, by the registry staff).

2.2.10.2.2.2.10.2. Domain Names

2.2.10.3.2.2.10.3. IP Addresses

The IP Addresses are IPv4 addresses in the form A.B.C.D,
where A, B, C, D are numbers between 0 and 255.

2.2.10.4.2.2.10.4. Dates/Times

A date and time always appear in combination. The time zone is
Greenwich Mean Time (GMT). The exact format is

YYYYMMDDhh:mm:ss

where YYYY
is four-digit year, MM
is the two-digit month, DD
is the two digit day, hh
is the two digit hour, mm
is the two digit minute and ss
is the two digit second. Date and time are separated by exactly one space
character (0x20).

2.2.10.5.2.2.10.5. Phone and Fax Numbers

It is strongly recommended (although not required) that telephone
and Fax numbers are specified in the international format, i.e., starting with
a plus sign, followed by the international area code, by the area code used in
the specific country and by the local subscriber number.

2.2.10.6.2.2.10.6. E-Mail Addresses

E-mail addresses should conform to the format specified in
[RFC822], without any comments.

2.2.10.7.2.2.10.7. Billing Units

CORE uses a fictional currency for the registrars’ accounts. It
is called RCU (registry currency unit). It is a number with two fractional
digits.

2.2.11.3.2.2.11.3. Admin-Contact Key

2.2.11.4.2.2.11.4. Approved-Owner-Change Key

name:

approved-owner-change

used by:

client

format/values:

Y or N (case insensitive)

description:

If Y (yes), it signals that the
requirements for an owner change have been fulfilled by the registrar and
that the owner data of the domain should be updated by the given owner
contact handle. If N (no), most of the previous owner data is retained. See
the modify domain request for details.

2.2.11.5.2.2.11.5. City Key

name:

city

used by:

client, server

format/values:

text string, no more than 50 characters

description:

Specifies the city where the contact is
located in.

2.2.11.6.2.2.11.6. Completed-Before Key

name:

completed-before

used by:

client

format/values:

date

description:

Specifies the upper bound for the
completion date of a request to be found by the query
request.

2.2.11.7.2.2.11.7. Completed-Since Key

name:

completed-since

used by:

client

format/values:

date

description:

Specifies the lower bound for the
completion date of a request to be found by the query
request.

2.2.11.8.2.2.11.8. Contact Key

name:

contact

used by:

client, server

format/values:

contact handle

description:

(Administrative, technical) contact of
the host.

2.2.11.9.2.2.11.9. Costs Key

name:

costs

used by:

server

format/values:

RCU value

description:

Specifies the amount of RCUs which were
deducted from the registrar’s account. A positive value is a debit, a
negative value a credit.

2.2.11.10.2.2.11.10. Count Key

name:

count

used by:

server

format/values:

positive number

description:

The number of objects that meet the
criteria (inquire requests in combination with the list
key, or the query request). The value is not necessarily
identical with the number of object handles/domain names returned: the actual
number of objects listed may be reduced due to the registry policy.

2.2.11.11.2.2.11.11. Country Key

name:

country

used by:

client, server

format/values:

text string, no more than 50 characters; although not
required, it is strongly recommended to use the ISO two letter code [ISO3166]

description:

Specifies the country where the contact
is located in.

2.2.11.12.2.2.11.12. Created Key

name:

created

used by:

server

format/values:

date

description:

Specifies the date when the object was
created.

2.2.11.13.2.2.11.13. Created-By Key

name:

created-by

used by:

server

format/values:

registrar handle

description:

Specifies the handle of the registrar
who created the object.

2.2.11.14.2.2.11.14. Domain-Name Key

name:

domain-name

used by:

client, server, notification

format/values:

domain name

description:

For domain objects the name of the
domain, for host objects the DNS name of the host.

2.2.11.15.2.2.11.15. Domain-State Key

name:

domain-state

used by:

client, server

format/values:

either reserved,
production, expired
or hold (case insensitive)

description:

The state of the domain. See the
description of the domain object for details.

2.2.11.16.2.2.11.16. EMail Key

name:

email

used by:

client, server

format/values:

text string, containing a single valid e-mail address

description:

Specifies an e-mail address.

2.2.11.17.2.2.11.17. Error-Code Key

name:

error-code

used by:

server

format/values:

integer number (positive or negative)

description:

Indicates a specific error. See below
for the error codes.

2.2.11.18.2.2.11.18. Error-Text Key

name:

error-text

used by:

server

format/values:

text string

description:

Contains a human readable explanation
of the error. The string is meant for debugging purposes. The client should
not attempt to parse the contents of this string. Therefore, no description
of the various texts are given in this document.

2.2.11.19.2.2.11.19. Expiration-Date Key

name:

expiration-date

used by:

server

format/values:

date

description:

Specifies the date when the domain
expires.

2.2.11.20.2.2.11.20. Fax Key

name:

fax

used by:

client, server

format/values:

text string, containing a phone number of a fax machine

description:

Specifies a fax number.

2.2.11.21.2.2.11.21. FName Key

name:

fname

used by:

client, server

format/values:

text string, no more than 50 characters

description:

Specifies the first name of an
individual.

2.2.11.22.2.2.11.22. Gaining-Registrar Key

name:

gaining-registrar

used by:

notification

format/values:

registrar handle

description:

Specifies the registrar who wants to
gain a domain in a domain transfer process.

2.2.11.23.2.2.11.23. Handle Key

name:

handle

used by:

client, server

format/values:

handle

description:

Specifies the handle of the target
object to be modified, deleted or inquired (client) or the handle that has
been assigned by the server

2.2.11.24.2.2.11.24. Individual Key

name:

individual

used by:

client, server

format/values:

either Y or N (case insensitive)

description:

Specifies whether a contact describes
an individual (Y) or an organization (N).

2.2.11.25.2.2.11.25. IP-Address Key

name:

ip-address

used by:

client, server

format/values:

An IP address

description:

Specifies the IP address of a host.

2.2.11.26.2.2.11.26. Last-Modified Key

name:

last-modified

used by:

server

format/values:

date

description:

Specifies the date when the object was
modified at last.

2.2.11.27.2.2.11.27. Last-Modified-By Key

name:

last-modified-by

used by:

server

format/values:

registrar handle

description:

Specifies the handle of the registrar
who modified the object at last.

2.2.11.36.2.2.11.36. Payload-Version Key

client (the server does not use this
key, since it always uses the same payload version as the client used in its
request), notification

format/values:

N.M

where N and M are positive numbers

description:

Specifies the version number of the
payload. The payload specified in this document has the version number 1.1.

2.2.11.37.2.2.11.37. Period Key

name:

period

used by:

client

format/values:

positive number indicating the number of years

description:

Specifies the registration period of a
domain (or its extension).

2.2.11.38.2.2.11.38. Phone Key

name:

phone

used by:

client, server

format/values:

text string, containing a phone number

description:

Specifies a phone number

2.2.11.39.2.2.11.39. Postal-Code Key

name:

postal-code

used by:

client, server

format/values:

text string, containing the postal code

description:

Specifies the postal code of the
related city key.

2.2.11.40.2.2.11.40. Reg-Admin-Auth-Key Key

name:

reg-admin-auth-key

used by:

client

format/values:

PGP key

description:

The public PGP key which the registrar
uses for administration purposes.

2.2.11.41.2.2.11.41. Reg-Admin-Auth-Key-Info Key

name:

reg-admin-auth-key-info

used by:

server

format/values:

key related information in the form <param> = <value>
[ , <param>
= <value> ...]
For PGP5 keys, the following information is returned: auth_keyid (the ID of the PGP key), auth_uid (the user identification)

description:

Additional information about the key

2.2.11.42.2.2.11.42. Reg-Admin-Auth-Type Key

name:

reg-admin-auth-type

used by:

client

format/values:

must be pgp5
(case insensitive)

description:

The type of the cryptographic key
specified with the corresponding reg-admin-auth-key.

2.2.11.43.2.2.11.43. Reg-Admin-Contact Key

name:

reg-admin-contact

used by:

client, server

format/values:

contact handle

description:

Contact handle of the registrar
administration.

2.2.11.44.2.2.11.44. Reg-Admin-Permissions Key

name:

reg-admin-permissions

used by:

server

format/values:

a comma-separated list of request types

description:

Specifies the allowed request types for
the corresponding entity.

2.2.11.45.2.2.11.45. Reg-Agent-Auth-Key Keys

name:

reg-agent1-auth-key
reg-agent2-auth-key
...
reg-agent12-auth-key

used by:

client

format/values:

PGP key

description:

The public PGP key which the
registrar’s staff uses for the daily work.

2.2.11.46.2.2.11.46. Reg-Agent-Auth-Key-Info Key

name:

reg-agent-auth-key-info

used by:

server

format/values:

key related information in the form <param> = <value>
[ , <param>
= <value> ...]
For PGP5 keys, the following information is returned: auth_keyid (the ID of the PGP key), auth_uid (the user identification)

description:

Additional information about the key

2.2.11.47.2.2.11.47. Reg-Agent-Auth-Type Keys

name:

reg-agent1-auth-type
reg-agent2-auth-type
...
reg-agent12-auth-type

used by:

client

format/values:

must be pgp5
(case insensitive)

description:

The type of the cryptographic key
specified with the corresponding reg-agentN-auth-key.

2.2.11.48.2.2.11.48. Reg-Agent-Contact Keys

name:

reg-agent1-contact
reg-agent2-contact
...
reg-agent12-contact

used by:

client, server

format/values:

contact handle

description:

Contact handle of the registrar staff.

2.2.11.49.2.2.11.49. Reg-Agent-Permissions Key

name:

reg-agent-permissions

used by:

server

format/values:

a comma-separated list of request types

description:

Specifies the allowed request types for
the corresponding entity.

2.2.11.50.2.2.11.50. Reg-State Key

name:

reg-state

used by:

client, server

format/values:

one of active,
suspended or defunct
(case insensitive)

description:

The registrar’s state

2.2.11.51.2.2.11.51. Reg-Super-Auth-Key Key

name:

reg-super-auth-key

used by:

client

format/values:

PGP key

description:

The public PGP key of the registrar’s
super contact.

2.2.11.52.2.2.11.52. Reg-Super-Auth-Key-Info Key

name:

reg-super-auth-key-info

used by:

server

format/values:

key related information in the form <param> = <value>
[ , <param>
= <value> ...]
For PGP5 keys, the following information is returned: auth_keyid (the ID of the PGP key), auth_uid (the user identification)

description:

Additional information about the key

2.2.11.53.2.2.11.53. Reg-Super-Auth-Type Key

name:

reg-super-auth-type

used by:

client

format/values:

must be pgp5
(case insensitive)

description:

The type of the cryptographic key
specified with the corresponding reg-super-auth-key.

2.2.11.54.2.2.11.54. Reg-Super-Contact Key

name:

reg-super-contact

used by:

client, server

format/values:

contact handle

description:

Contact handle of the registrar’s super
contact.

2.2.11.55.2.2.11.55. Reg-Super-Permissions Key

name:

reg-super-permissions

used by:

server

format/values:

a comma-separated list of request types

description:

Specifies the allowed request types for
the corresponding entity.

2.2.11.56.2.2.11.56. Registrar-ID Key

name:

registrar-id

used by:

client, server

format/values:

registrar handle

description:

This key identifies the registrar. The
handle is assigned by the registry staff.

2.2.11.57.2.2.11.57. Request-Transaction-ID Key

name:

request-transaction-id

used by:

server

format/values:

transaction identifier (see transaction-id
key)

description:

The transaction identifier of a
previously received request. This key is used in the reply of a query
request.

2.2.11.58.2.2.11.58. Request-Type Key

name:

request-type

used by:

client

format/values:

The value consists of a sequence of
words, separated by whitespace. A word is a sequence of the letters A to Z.
The case of the words is irrelevant

description:

The request type specifies the action
the server should perform on behalf of the client.

2.2.11.59.2.2.11.59. Request-State Key

name:

request-state

used by:

server

format/values:

one of the following terms: pending, in-process,
succeeded, failed

description:

Returns the processing state of a
request. The meanings of the values are:

pendingthe request has been received
and is currently waiting to be processed

in-processthe request is being processed

succeededthe request has been processed
successfully. Changes were made according to the request

failedthe processing of the
request failed. No changes, even not partially, were made

2.2.11.60.2.2.11.60. Response-Type Key

name:

response-type

used by:

server

format/values:

either ack
or reply

description:

This key tells the client whether the
response contains an intermediate confirmation of the reception of the
request (acknowledge, ack) or the final
result of the request (reply)

2.2.11.61.2.2.11.61. State Key

name:

state

used by:

client, server

format/values:

text string

description:

The state or territory where the
contact is located in.

2.2.11.62.2.2.11.62. Submitted-Before Key

name:

submitted-before

used by:

client

format/values:

date

description:

Specifies the upper bound for the
submission date of a request to be found by the query
request.

2.2.11.63.2.2.11.63. Submitted-Since Key

name:

submitted-since

used by:

client

format/values:

date

description:

Specifies the lower bound for the
submission date of a request to be found by the query
request.

2.2.11.64.2.2.11.64. Success Key

name:

success

used by:

server

format/values:

text string

description:

A human readable comment to the
successful processing of a request. The string is meant for debugging
purposes. The client should not attempt to parse the contents of this string.
Therefore, no description of the various texts are given in this document.

2.2.11.65.2.2.11.65. Tech-Contact Key

name:

tech-contact

used by:

client, server

format/values:

contact handle

description:

Technical contact (of a domain).

2.2.11.66.2.2.11.66. Time-Out-Date Key

name:

time-out-date

used by:

notification

format/values:

date

description:

The deadline until the server expects a
reaction from the registrar.

2.2.11.67.2.2.11.67. Title Key

name:

title

used by:

client, server

format/values:

text string, no more than 50 characters

description:

The title of the contact.

2.2.11.68.2.2.11.68. Transaction-Credit Key

name:

title

used by:

server

format/values:

RCU value

description:

The balance of the registrar’s account.

2.2.11.69.2.2.11.69. Transaction-ID Key

name:

transaction-id

used by:

client, server

format/values:

may consist of a sequence of printable,
non-whitespace characters, no less than one character and no more than forty
characters

description:

The transaction identifier is generated
by the client. It is not required, but strongly recommended that the
identifier is registrar-unique, since the status
request cannot return any information for multiply used transaction
identifiers.

2.2.11.71.2.2.11.71. Transfer-Performed Key

Specifies whether the transfer has
finally been performed (Y) or not (N).

2.2.11.72.2.2.11.72. Zone-Contact Key

name:

zone-contact

used by:

client, server

format/values:

contact handle

description:

Contact who is responsible for the
maintenance of the DNS zone.

2.2.12.2.2.12. Error Codes

-100

empty request

-101

transaction-id not found

-102

registrar-id not found or invalid

-103

request-type not found or invalid

-104

no permission to execute this request

-105

field payload version not found or
invalid

-106

not enough credits for this request

-107

duplicate key in request

-108

no registrar-contact record found for
registrar-id and PGP keyid

-109

no registrar-handle record found or
registrar-handle is invalid

-110

value not found or invalid

-111

mandatory key not found

-112

value exceeds maximum field length

-113

mandatory key can not be empty in
modification request.

-114

invalid top level domain name

-117

value is not a valid date

-118

host-handles must be unique for each
domain

-130

host cannot be deleted because of
references to existing domains.

-131

contact cannot be deleted because of
references to existing objects.

-150

not manager of this contact

-151

illegal flag

-160

domain name is already registered.

-180

not manager of this domain

-200

PGP key could not be added, maybe wrong
format or invalid

-201

PGP keyid is already in use for that
registrar

-251

reg-admin, reg-agent or reg-super key
setsincomplete

-270

no request with the given
transaction-id exists

-310

host-handle not found or invalid

-311

not manager of this host

-350

domain does not exist

-351

domain is not scheduled for transfer

-352

not owner of this transfer, permission
denied

-354

transfer for that domain is already in
progress

2.3.2.3. Domain Transfer Process

The domain transfer process involves three parties — the gaining
registrar, the registry and the loosing registrar. Both registrars negotiate
about the transfer, the registry only being the mediator in this process.

Steps in a domain transfer where the loosing registrar agrees to
a transfer:

If the loosing registrar fails to respond upon the init-transfer
notification before reaching the time-out date, the registry decides on behalf
of the registrar, depending on the registry’s policy. The registry behaves as
if it received a transfer domain request with either positive
or negative transfer acknowledge.

If the gaining registrar fails to respond upon the transfer-acknowledge
notification before reaching the time-out date, the registry behaves as if it
received a transfer domain request with the abort-transfer
action. Additionally, it sends a transfer-finish notification to the gaining
registrar.