Internet DRAFT - draft-brunner-xrp
draft-brunner-xrp
Network Working Group Eric Brunner-Williams
INTERNET-DRAFT Ayesha Damaraju
Ning Zhang
NeuStar
February, 2001 Expires August 2001
Extensible Registry Protocol (XRP)
<draft-brunner-xrp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo describes a connection-oriented, application layer client-
server protocol for the provisioning and management of objects stored
in a shared top level domain (TLD) central registry. The protocol
defines a command framework for object management operations and maps
the commands to the objects defined in an extensible object data
model. The protocol is specified in XML Schema Definition.
Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Brunner, et al Expires August 2001 [Page 1]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Table of Contents
Status of this Memo ............................................ 1
Copyright Notice ............................................... 1
Abstract ....................................................... 2
Table of Contents .............................................. 3
1. Introduction ................................................ 6
2. Protocol Description ........................................ 7
2.1 Session Layer Interface ................................. 7
2.1.1 Protocol Identification and Nameing Conventions .... 7
2.1.2 Connection Establishment ........................... 7
2.1.3 Authentication & Confidentiality ................... 8
2.1.4 Protocol Initialization ............................ 8
2.1.5 Authorization ...................................... 9
2.1.6 Data Exchange (use of XML and MIME) ................ 10
2.1.7 Session Termination ................................ 11
2.2 Service Primitives ...................................... 11
2.2.1 Request Format ..................................... 11
2.2.2 Response Format .................................... 12
2.2.3 Notify Format ...................................... 14
2.2.4 Acknowledgement Format ............................. 14
2.3 Services ................................................ 15
2.3.1 Object Management .................................. 15
2.3.1.1 Create .......................................... 15
2.3.1.2 Delete .......................................... 17
2.3.1.3 Renew ......................................... 18
2.3.1.4 Transfer ...................................... 19
2.3.1.5 Modify ........................................ 23
2.3.2 Object Query ....................................... 24
2.3.2.1 Check ......................................... 24
2.3.2.2 Query ......................................... 25
2.3.2.3 List .......................................... 26
2.3.3 Transaction Management ............................. 27
2.3.3.1 Cancel ........................................ 27
2.3.3.2 Transaction Status ............................ 28
3. Response Codes .............................................. 28
4. Formal Syntax ............................................... 30
5. Internationalization Considerations ......................... 30
6. IANA Considerations ......................................... 31
7. Security Considerations ..................................... 31
7.1 Session Layer .............................................. 31
7.2 Authentication ............................................. 31
7.3 Access Control ............................................. 31
References ..................................................... 32
Authors' Addresses ............................................. 32
A.1 Introduction ............................................... 34
A.2 Object Attributes .......................................... 34
A.2.1 Contact Object ........................................... 34
Brunner, et al Expires August 2001 [Page 2]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
A.2.1.1 Object Elements ..................................... 34
A.2.2 Nameserver Object ..................................... 38
A.2.2.1 Object Elements .................................. 38
A.2.3 Domain-name Object .................................... 40
A.2.3.1 Object Elements .................................. 40
A.2.4 Intellectual Property ................................. 43
A.2.4.1 Object Elements .................................. 43
A.2.5 Registrant Object ..................................... 46
A.2.5.1 Object Elements .................................. 46
A.2.6 Registrar Object ...................................... 49
A.2.6.1 Object Elements ..................................... 49
A.3 XRP Command Mappings ....................................... 53
A.3.1 Create ................................................ 53
A.3.1.1 Contact Object ................................... 54
A.3.1.2 Nameserver Object ................................ 54
A.3.1.3 Domain-name Object ............................... 57
A.3.1.4 Intellectual Property Object ..................... 60
A.3.1.5 Registrant Object ................................ 62
A.3.2 Delete ................................................ 63
A.3.2.1 Contact Object ................................... 63
A.3.2.2 Nameserver Object ................................ 63
A.3.2.3 Domain-name Object ............................... 64
A.3.2.4 Intellectual Property Object ..................... 67
A.3.2.5 Registrant Object ................................ 68
A.3.3 Modify .............................................. 69
A.3.3.1 Contact Object ................................... 69
A.3.3.2 Nameserver Object ................................ 70
A.3.3.3 Domain-name Object ............................... 72
A.3.3.4 Intellectual Property Object ..................... 73
A.3.3.5 Registrant Object ................................ 74
A.3.4 Renew ................................................. 76
A.3.4.1 Domain Object .................................... 76
A.3.4.2 Intellectual Property ............................ 76
A.3.5 Transfer .............................................. 77
A.3.5.1 Contact Object ................................... 79
A.3.5.2 Nameserver Object ................................ 82
A.3.5.3 Domain-name Object ............................... 85
A.3.5.4 Registrant Object ................................ 88
A.3.6 Query ................................................. 91
A.3.6.1 Contact Object ................................... 91
A.3.6.2 Nameserver Object ................................ 93
A.3.6.3 Domain-name Object ............................... 95
A.3.6.4 Intellectual Property Object ..................... 96
A.3.6.5 Registrant Object ................................ 98
A.3.6.6 Registrar Object ................................. 100
A.3.7 Check ................................................. 102
A.3.7.1 Contact Object ................................... 102
A.3.7.2 Nameserver Object ................................ 103
Brunner, et al Expires August 2001 [Page 3]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
A.3.7.3 Domain-name Object ............................... 105
A.3.7.4 Intellectual Property Object ..................... 106
A.3.7.5 Registrant Object ................................ 107
A.3.7.6 Registrar Object ................................. 109
A.3.8 List .................................................. 110
A.3.8.1 Registrar Object ................................. 110
Full Copyright Statement ....................................... 111
Acknowledgement ................................................ 111
1. Introduction
The Extensible Registry Protocol (XRP) Version 1.0, provides
specifications for the exchange of messages between registrar clients
and the registry server for handling registration and management of
Internet domain names in shared Top Level Domain (TLD) registries.
XRP messages are specified using Extensible Markup language (XML).
XRP exceeds the requirements defined in the Generic Registry-
Registrar Protocol Requirements, [GRRP]. XRP is a connection-
oriented application protocol that is layered over multiple transport
protocols.
With the advent of the selection of the seven new Top Level Domain
(TLD) proposals by ICANN at its meeting on 16 November, 2000, the
utility of a common, generic RRP protocol for domain name shared
registration systems is recognized by all successful applicants. In
meetings at the IETF the week of December 11, broad agreement was
reached to develop a common generic RRP protocol that is based on the
GRRP Requirements.
This document is being released to provide a fat registry registrar
protocol implementation of GRRP that relies on the Blocks Extensible
Exchange Protocol (BEEP) framework to provide session management
services, including channel management and security mechanisms for
transport security, authentication, and access control.
2. Protocol Description
XRP is a connection oriented, asynchronous request/response
application protocol based on [GRRP]. It provides request response
command primitives for data exchange between the registrar (client)
and registry (server). Each XRP session uses the Blocks Extensible
Exchange Protocol (BEEP) Framework as the underlying session
management layer. BEEP provides a session management framework that
can be mapped onto multiple transport protocols. A BEEP peer may
support from 1 to 256 concurrent channels. Channel 0 is established
as the control channel.
Brunner, et al Expires August 2001 [Page 4]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
XRP permits simultaneous and independent exchanges of messages
between peers in the context of an XML schema wrapper [XML-SCHEMA].
Message exchange occurs within BEEP channels that define a binding to
a well defined aspect of the XRP application, such as transport
security, user authentication, access control, and data exchange.
Each channel has an associated "profile" that defines the syntax and
semantics of the messages exchanged. Profiles used for
initialization and data exchange are defined in a registration
template. Data exchange messages are defined in XML schema
definition (XSD).
When a successful connection is established by the transport layer,
the BEEP session layer client and server entities advertise the
session management services and profiles it supports by exchanging a
greeting message. The client (the registrar) sends the proposed
profiles for the channel. The server (registry) creates the channel,
selects one of the profiles, and sends it in a reply to the greeting
message; otherwise the server indicates that none of the profiles are
acceptable and declines creation of the channel. Clients then use
the "start" message to negotiate and initialize channels to establish
a secure connection with the XRP server and exchange data. The
client exchanges authentication, identification, and option
information and then engages in a series of client-initiated request-
response message exchanges over the channels established for data
exchange. Channels and sessions are closed by the "close" message.
The XRP session will go through a number of states during its
establishment and existence. Figure 1 illustrates the possible states
of an XRP server from initiation to disconnect. When an XRP session
starts, only the control channel is defined which is used for session
management.
This space intentionally blank
Brunner, et al Expires August 2001 [Page 5]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Figure X. XRP Finite State Transition Diagram.
Each XRP state is defined as follows:
1. WAIT - the server (registry) listens on the transport service
socket for a connection open that triggers an exchange of greeting
messages between the client and server.
2. WFN - after the greeting exchange to advertise the profiles
supported by both peers, the security and authentication profile
negotiation is initiated by the client. If a suitable profile
cannot be negotiated, the server disconnects the client.
3. WFA - the server waits for validation of the client user
authentication for the session. If the client user authorization
fails, the client is disconnected.
4. WFD - The server waits for data exchange over the channels
specified by the client. Each channel is associated with a data
exchange profile.
5. VAL - Each request received by the server is validated by XRP
and passed to the registry application software layer. If the
request has errors, a negative response is returned to the client.
6. EXE - If the request passes XRP validation, it is executed by
the registry application software layer and a positive response is
returned to the client. Each XRP channel provides a one to one
data exchange with a Registry application; for example
authenticating the request, notifying registrars, trademark
monitoring, and update registry object.
7. DIS - If a profile negotiation failure, user authentication
failure, expiration of a server timeout, or receipt of a session
termination occurs from the client, then the session is
disconnected and the server returns to the listing state - WAIT.
2.1 Session Layer Interface
XRP (version 1.0) is specified as a BEEP service and identified by a
profile as a URI prefix:
http://www.neulevel.com/profiles/XRP/1.0
The final designation of the protocol identification will determine
the actual profile URI prefix.
2.1.1 Protocol Identification and Naming Conventions
Brunner, et al Expires August 2001 [Page 6]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Each and every message exchanged over a BEEP channel must be enclosed
in protocol identifier tag which is "xrp". The protocol identifier
consists of attribute "version" and "channel" which identifies the
version of XRP and the channel to be used for data exchange between
the client and server.
Example:
<?xml version "1.0" standalone="no"?>
<xrp version="1.0" channel="001">
...message payload...
</xrp>
XRP peers are named using the "addr-spec" syntax specified in
"Internet Message Format" (draft-drums-msg-fmt-09), i.e.,
local@domain <mailto:local@domain> syntax.
2.1.2 Connection Establishment
XRP session is established, when a BEEP session is created and XRP
profile is identified The SRV algorithm [RFC 2782] is used to
determine the IP/TCP addressing information assigned to the peers:
* Service: "beep"
* Protocol: "tcp"
Profile <http://www.neulevel.com/profiles/XRP/1.0> (as a URI prefix)
Example: Identification of XRP profile after BEEP session establishment
S: <wait for incoming connection>
S: <open connection>
S: RPY 0 0 . 0 162
S: Content-Type: application/beep+xml
S:
S: <greeting>
S: <profile uri="http://www.neulevel.com/profiles/XRP/1.0" />
S: <profile uri="http://xml.resource.org/profiles/TLS" />
S: <profile uri="http://xml.resource.org/profiles/sasl/OPT" />
S: </greeting>
S: END
C: RPY 0 0 . 0 52
C: Content-Type: application/beep+xml
C:
C: </greeting>
C: END
2.1.3 Authentication & Confidentiality
Authentication is a matter of provisioning for each BEEP peer. Peer
Brunner, et al Expires August 2001 [Page 7]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
authentication/User authentication is performed using one of the BEEP
security and authentication service profiles, such as SASL, after a
successful negotiation at the channel initialization. Whenever a
successful authentication occurs, on any channel, the authenticated
identity is updated for all existing and future channels on the BEEP
session; further no additional attempts at authentication are allowed.
Confidentiality is a matter of provisioning for each BEEP peer and is
achieved by transport layer security, such as TLS. Typically, any data
considered sensitive by an originating peer would have its content
encrypted for the intended recipient peer, rather than relying on hop-
by-hop encryption. Similarly, an originating peer will sign the content
if end-to-end authentication is desired.
2.1.4 Protocol Initialization
When a client wants to create a channel for initial tuning or for
data exchange. A BEEP "start" element is sent on channel zero, which
is created on session establishment. The XRP protocol is identified
during the connection establishment as a BEEP profile in the greeting
message and initialized during the initial tuning of the channel used
for data exchange. An optional parameter corresponding to the XRP
authorization sent by the client is carried within a "CDATA" element
during channel creation. During the channel creation, a BEEP/XRP peer
must send the XRP profile to the remote XRP peer, for example:
C: MSG 0 1 . 52 209
C: Content-Type: application/beep+xml
C:
C: <start number="1">
C: <profile uri="http://www.neulevel.com/profiles/XRP/1.0">
C: <![CDATA[<blob>ABYTXORERLTABYL</blob>]]>
C: </profile>
C: </start>
C: END
S:
S: RPY 0 1 . 264 99
S: Content-Type: application/beep+xml
S:
S: <profile uri="http://www.neulevel.com/profiles/XRP/1.0">
S: END
2.1.5 Authorization
During channel creation, the XRP "profile" element in the BEEP
"start" element may contain optional parameters, such as "userid" and
"password" elements that could be used for second-level
authentication, encoded and encapsulated in the "blob" element. Note
Brunner, et al Expires August 2001 [Page 8]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
that by the encapsulated operation failure, the channel creation will
not be performed and the respective error code is returned. For
example:
C: MSG 0 1 . 52 209
C: Content-Type: application/beep+xml
C: <start number="1">
C: <profile uri="http://www.neulevel.com/profiles/XRP/1.0">
C: <![CDATA[<blob>ABYTXORERLTABYL</blob>]]>
C: </profile>
C: </start>
C: END
S:
S: RPY 0 1 . 264 190
S: Content-Type: application/beep+xml
S:
S: <error code='551'>authorization failed</error>
S: END
In this case, a positive reply is sent (as channel creation
succeeded), but the encapsulated response contains an indication as
to why the operation failed. Otherwise, the server signifies success.
For example:
C: MSG 0 1 . 52 209
C: Content-Type: application/beep+xml
C: <start number="1">
C: <profile uri="http://www.neulevel.com/profiles/XRP/1.0">
C: <![CDATA[<blob>ABYTXORERLTABYL</blob>]]>
C: </profile>
C: </start>
C: END
S:
S: RPY 0 1 . 264 99
S: Content-Type: application/beep+xml
S:
S: <profile uri="http://www.neulevel.com/profiles/XRP/1.0"/>
S: END
2.1.6 Data Exchange (use of XML and MIME)
The BEEP framework describes how arbitrary MIME content is exchanged
as a BEEP payload. Each XRP request/response/notification/ack payload
is preceded by the XRP tag <xrp version="1.0"> and ended with the XRP
tag </xrp>. For example, to exchange the following message body that
conforms the XML schema definition of XRP messages:
<xrp version="1.0">
Brunner, et al Expires August 2001 [Page 9]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<response>
<reply>
<code>999</code>
<message>ERROR REASON</message>
</reply>
<transaction-id>
<date>2001-01-20</date>
<client-id>REG-1234</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</response>
</xrp>
The corresponding BEEP message encoding will be as follows:
C: MSG 1 2 . 42 560
C: Content-Type: text/xml
C
C: <?xml version="1.0"?>
C: <xrp version="1.0">
C: <response>
C: <reply>
C: <code>999</code>
C: <message>ERROR REASON</message>
C: </reply>
C: <transaction-id>
C: <date>2001-01-20</date>
C: <client-id>REG-1234</client-id>
C: <code>ABC-12345-XYZ</code>
C: </transaction-id>
C: </response>
C: </xrp>
C: END
2.1.7 Session Termination
XRP session termination is performed by closing the BEEP session,
after all channels are closed.
2.2 Service Primitives
XRP provides four basic service elements: requests, responses,
notifications, and acknowledgements.
When a session is established, the client authenticated, and data
exchange channels established, XRP allows two styles of exchange
between the client and server.
1. request/response - the client sends a "request" message
Brunner, et al Expires August 2001 [Page 10]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
requesting the server to perform the task, the server performs the
task and replies with a "response" message (termed a positive or
negative reply).
2. notify/ack - the server notifies clients about certain events
in the system, and receives an "ack" response as an
acknowledgement.
Both styles are one-to-one synchronous exchanges.
2.2.1 Request Format
Once the XRP client is connected and data exchange channels are
established, the XRP client interacts with the XRP server by sending
a request (command) to the server and waiting for a response to the
request. The request format consists of a command, command options,
and request identifier represented in XML with in the "request"
delimiter. The "request" is the standard delimiter of an atomic
registry server command, the instructions embedded are considered to
be atomic in nature identifying the scope of a logical transaction.
An XRP request must contain the following elements:
1. A command <request> element that identifies the start of the
command
2. A command option corresponding to one of the valid XRP commands
3. A <transaction-id> element that uniquely identifies the command
to both the client and the server consisting of the following
child elements:
a) A <date> element that contains the date of the commands
execution
b) A <client-id> element that matches the identifier used by
the client when establishing a session with the server. Client
identifiers are unique and assigned by the operator of the
registry.
c) A <code> element that is assigned by the client and is
unique on a per-day basis. Code elements must contain a client-
coded combination of letters, numbers, and dashes.
Example:
<request>
... request type and parameters ...
<transaction-id>
... transaction-id element contents ...
Brunner, et al Expires August 2001 [Page 11]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
</transaction-id>
</request>
The transaction identifier is created by the registrar and sent along
with each transaction to provide command- response synchronization
integrity. Transaction identifiers must be logged, retained, and
protected to ensure that both the client and server have consistent
transaction records, traceability, authentication and transaction
rollback and recovery services.
Each request will include one of the XRP supported command options:
Example:
<request>
<obj1:request>
... request parameters ...
</obj1:request>
<transaction-id>
... transaction-id element contents ...
</transaction-id>
</request>
2.2.2 Response Format
The registry will respond to every client request command, with a
success or failure. Individual success and error conditions will be
stated distinctly. The server responses to the client with its
results payload contained in the "response" delimiter. Every response
includes the transaction identification of the original request.
Example:
<response>
... response body ...
<transaction-id>
... transaction identifier element contents ...
</transaction-id>
</response>
Each response contains a "reply" element with the success or failure
code of the processing results, an optional "data" element with
object- specific results, and the transaction-id elements from the
original request. If the command was processed successfully, only one
"reply" element shall be returned. If the command was not processed
successfully, then multiple "reply" elements may be returned to
describe failure conditions. Each "response> element includes the
following attribute and child elements:
Brunner, et al Expires August 2001 [Page 12]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
The "reply" element identifies the success or failure of the request
processing. If the request is processed successfully, there will be
one "reply" element. If the request results in unsuccessful process,
the response will contain multiple "reply" elements with all the
failure conditions. Each "reply" element contains the following child
elements:
1.The "code" element identifying the result code of the request
processing. A three digit, decimal number that describes the
success or failure of the request.
2. The "message" element containing a text description of the
response code. The language of the text is the language specified
by the client while session establishment.
a) The "data" element, is optional and contains the data provided
by the server in response to the request. A "data" element is
included, only when the result is a success. The "data" includes
object specific response to the request.
b) The "data" element will not be included in responses to
notifications
c) The "transaction-id" element identifies the associated
request's transaction identifier with the response.
Example:
<response>
<reply>
<code>nnn</code>
<message>message text</message>
</reply>
<data>
<obj:response>
... response data ...
</obj:response>
</data>
<transaction-id>
... transaction identifier elements of the
original request ...
</transaction-id>
</response>
2.2.3 Notify Format
The registry will notify clients on occurrence of certain events in
the system. The server notifies the client with a "notification"
Brunner, et al Expires August 2001 [Page 13]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
element containing object specific data elements in the "data"
element and a "notification-id" element. Each notification shall
include:
1. A unique identifier for notification-acknowledgement
synchronization integrity, traceability and authentication.
2. Object specific request element, of those objects supported by
the registry.
The identifier is created by the registry and sent along with each
notification. The notification identifier is created using the
current date and a combination of identification information assigned
by and unique to the registry (such as a registrar/contact
identifier) and a unique identifier generated by the registry.
Example:
<notification>
<data>
... object specific data ...
</data>
<notification-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</notification-id>
</notification>
2.2.4 Acknowledgement Format
In response to a notification the client must send an
acknowledgement, in an "ack" element. Each "ack" shall contain the
"notification-id" element to identify the associated original
notification's identifier.
Example:
<ack>
<notification-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</notification-id>
</ack>
2.3 Services
Brunner, et al Expires August 2001 [Page 14]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
XRP supports four major types of services implemented as requests
(commands) and responses. The service types are:
1. Object management
2. Object query
3. Transaction management
4. Notifications
Each of these services is atomic in nature and identifies a logical
transaction. Each of the requests is idempotent, either succeeding
completely or failing completely and producing predictable results in
case of repeated execution.
2.3.1 Object Management
Object management services permit the client to ask the server to
execute an operation and return the result. The available operations
fit into a request-response or transaction pattern. The client is
always provided a response about the completion of the transaction,
whether it succeeded or failed. Failure can be caused by an error
either by the client or server. XRP provides the following
operations to administer objects, supported in the registry database.
These operations allow the client's users to create, delete, modify
and renew the instance of an object, transfer the instance of object,
to modify the sponsoring client and to cancel a earlier performed
transaction within a grace period.
2.3.1.1 Create
The client sends a "create" element to create an instance of an
object. Depending on the object, the object may be created for an
indefinite period of time or an object may be created for a specific
validity period. The create request includes a object specific
"create" request with object specific fields which should include the
unique identity, a "name" of the object to create.
Example:
<request>
<create>
<obj1:create xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific fields ...
</obj1:create>
</create>
Brunner, et al Expires August 2001 [Page 15]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</request>
The server on successful request processing sends a "response"
element, along with the "reply" element and optional "data". The
"data" element will include a object specific "create-response"
element. The "response" element must also include the "transaction-
id" of the respective "request".
The "transaction-id" sent along with the successfully processed
create request/response is also used by the server to authorize
transfer requests from the clients. The authorization or the
transaction identifier must be provided to the authoritative agent by
the client on successful completion.
Example:
<response>
<reply>
<code>nnn</code>
<message>message text</message>
</reply>
<data>
<obj1:create-response xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific elements ...
</obj1:create-response>
</data>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</response>
Authorization: All client registrars must be authorized to use the
create request.
2.3.1.2 Delete
The client sends a "delete" element to delete an existing instance of
an object. The delete request includes an object specific "delete"
request with object specific fields which will identify the instance
of the object to be deleted.
Brunner, et al Expires August 2001 [Page 16]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example:
<request>
<delete>
<obj1:delete xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific identification fields ...
</obj1:delete>
</delete>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</request>
The server on successfully processing the delete request, must
respond with a "response" element. The response for the delete
request includes only the "reply" element on success or failure with
respective result code. The "response" element also includes the
"transaction-id" of the respective "request". The objects must not be
deleted if they are associated with other known objects. The
following business rules apply to handling objects with known
associations.
1. Notify the associated objects sponsoring clients about the
deletion of the object.
2. Modify the status of the object to pending deletion.
Example:
<response>
<reply>
<code>nnn</code>
<message>message text</message>
</reply>
<data>
<obj1:delete-response xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific elements ...
</obj1:delete-response>
</data>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
Brunner, et al Expires August 2001 [Page 17]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
</response>
Authorization: All sponsoring registrars are authorized to use the
delete request on the objects they currently sponsor.
2.3.1.3 Renew
The client sends a "renew" request to extend the validity period of
an object. The renewal of objects is performed on those objects that
are created for a period of time. The "renew" element will include an
object specific "renew" element that identifies the objects with the
unique fields and a period to extend the validity.
Example:
<request>
<renew>
<obj1:renew xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific fields ...
</obj1:renew>
</renew>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-ZYZ</code>
</transaction-id>
</request>
In response the server sends a "response" element, along with the
"reply" element and optional "data" element on successful request
processing. The "data" element includes a object specific "delete-
response" element. The "response" element also includes the
"transaction-id" of the respective "request".
Example:
<response>
<reply>
<code>nnn</code>
<message>message text</message>
</reply>
<data>
<obj1:renew-response xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific elements ...
</obj1:renew-response>
</data>
Brunner, et al Expires August 2001 [Page 18]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</response>
Authorization: All sponsoring clients are authorized to use the renew
request on the objects they currently sponsor.
2.3.1.4 Transfer
A "transfer" request element is used to transfer the sponsored
registrar of an existing object. The transfer command allows
registrars the capability to request, approve, reject, notify the
losing registrar of a transfer, or obtain status. The operation to
perform the transfer is identified in the "type" attribute of the
"transfer" element, where type can be a "request" or "approve" or
"reject" or "status". Along with the object identifier "transfer"
element must include the "authorization" element associated with the
object to confirm the authority of the requesting registrar. The
elements in the "transfer" element to identify the object are object
specific.
Example:
<request>
<transfer type="request">
<obj1:transfer xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific identifier fields ...
</obj1:transfer>
</transfer>
<authorization>
<date>yyyy-mm-dd</date>
<client-id>clientYY</client-id>
<code>ABC-12345-XYZ</code>
</authorization>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</request>
A transfer request must include a notification of the domain-name
object transfer request that is sent to the current sponsoring
registrar for approval.
Brunner, et al Expires August 2001 [Page 19]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example:
</notification>
<data>
<obj1:transfer-response xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific identifier fields ...
</obj1:transfer-response>
</data>
<notification-id>
<date>yyyy-mm-dd</date>
<client-id>clientYY</client-id>
<code>ABC-12345-XYZ</code>
</notification-id>
</notification>
A transfer response is sent to the gaining registrar along with the
data element that includes the object specific "transfer-response"
element. The "transfer-response" element must identify the status of
transfer, object instance, current sponsoring registrar of the object
and dates related to the transfer.
Example:
<response>
<reply>
<code>nnn</code>
<message>message text</message>
</reply>
<data>
<obj1:transfer-response xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd>
... object specific fields identifying pending status ...
</obj1:transfer-response>
</data>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientYY</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</response>
The transfer request will allow the losing registrar to respond to
the notification by approving or rejecting the transfer along with
the "authorization".
Example:
Brunner, et al Expires August 2001 [Page 20]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<request>
<transfer type="approve">
<obj1:transfer xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific identifier fields ...
</obj1:transfer>
</transfer>
<authorization>
<date>yyyy-mm-dd</date>
<client-id>clientYY</client-id>
<code>ABC-12345-XYZ</code>
</authorization>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientYY</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</request>
When the losing registrar responds to the notification or the
response times out -- the XRP server responds with a notification to
the gaining registrar by sending a "notification" element.
Example:
<notification>
<data>
<obj1:transfer-response xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific identifier fields ...
</obj1:transfer-response>
</data>
<notification-id>
<date>yyyy-mm-dd</date>
<client-id>clientYY</client-id>
<code>ABC-12345-XYZ</code>
</notification-id>
</notification>
A query on the status of an earlier transfer request is performed by
using "transfer" request element by identifying the type of request
as "status". The "transfer" must include object specific transfer
element with will identify the object to query. Along with the object
identifier, a "transfer" element must include the "authorization"
element associated with the object to confirm the authority of the
requesting client. The elements in the "transfer" element to identify
the object are object specific.
Brunner, et al Expires August 2001 [Page 21]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example:
<request>
<transfer type="status">
<obj1:transfer xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific identifier fields ...
</obj1:transfer>
</transfer>
<authorization>
<date>yyyy-mm-dd</date>
<client-id>clientYY</client-id>
<code>ABC-12345-XYZ</code>
</authorization>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</request>
A response must be sent to the gaining registrar along with the data
element that includes the object specific "transfer-response"
element. The "transfer-response" element must identify the status of
transfer, object instance, current sponsoring registrar of the object
and dates related to the transfer.
Example:
<response>
<reply>
<code>nnn</code>
<message>message text</message>
</reply>
<data>
<obj1:transfer-response xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd>
... object specific fields ...
... identifying pending status ...
</obj1:transfer-response>
</data>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientYY</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</response>
Brunner, et al Expires August 2001 [Page 22]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Authorization: All registrars must be authorized to use the
"transfer" request. A registrar must be authorized to query an object
for which they are either the gaining or the losing registrar.
Approval or rejection of the notification of domain transfer must be
accepted only from the current sponsoring registrar.
2.3.1.5 Modify
A "modify" element is used to modify information associated with an
existing object. The "modify" element includes an object specific
"modify" element that identifies the objects with the unique fields
and a type of change and values.
Example:
<request>
<modify>
<obj1:modify xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific fields ...
</obj1:modify>
</modify>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</request>
The server processes the request and sends a "response" element,
along with the "reply".
Example:
<response>
<reply>
<code>nnn</code>
<message>message text</message>
</reply>
<data>
<obj1:modify-response xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific elements ...
</obj1:modify-response>
</data>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
Brunner, et al Expires August 2001 [Page 23]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<code>ABC-12345-XYZ</code>
</transaction-id>
</response>
Authorization: All sponsoring clients are authorized to use the
modify request on the objects they currently sponsor.
2.3.2 Object Query
Object query services permit the registrar client to ask the server
to execute an operation and return the result. Both the client and
server entities are always notified about the completion of the
transaction, whether it succeeded or failed. Failure can be caused by
an error either by the client or server. XRP provides the following
operations to query objects, supported in the registry. These
operations allow users to query the existence, information of an
object.
2.3.2.1 Check
The "check" request is used to determine the existence of an object
in the registry. The "check" element must include the elements to
identify the object, which are object specific.
Example:
<request>
<check>
<obj1:check xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific fields ...
</obj1:check>
</check>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</request>
In response the server will process the request and send a "response"
element, along with an object specific data element "check-response"
in the response.
Example:
<response>
<reply>
Brunner, et al Expires August 2001 [Page 24]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<code>nnn</code>
<message>message text</message>
</reply>
<data>
<obj1:check-response xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific fields ...
</obj1:check-response>
</data>
<trainsaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientYY</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</response>
Authorization: All registrars must be authorized to use the "check"
request.
2.3.2.2 Query
The "query" request is used to obtain the information of an existing
object in the registry. The "query" element must include the elements
to identify the object that are object specific.
Example:
<request>
<query>
<obj1:query xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific fields ...
</obj1:query>
</query>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</request>
The server on successfully processing the request responds with a
"response" element, along with the object specific data element
"query-response".
Example:
<response>
Brunner, et al Expires August 2001 [Page 25]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<reply>
<code>nnn</code>
<message>message text</message>
</reply>
<data>
<obj1:query-response xmlns:obj1="urn.NeuLevel.obj1"
xsi:schemaLocation="urn.NeuLevel.obj1 obj1.xsd">
... object specific fields ...
</obj1:query-response>
</data>
<trainsaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientYY</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</response>
Authorization: All registrars must be authorized to use the "query"
request. Only the sponsoring registrar must be able to access the
object authorization information. Access to object information may be
restricted to only sponsoring clients.
2.3.2.3 List
The "list" request provides a list of registrar identifiers for all
registrars in the registry.
Example:
<request>
<list>
<obj1:list xmlns:obj1="urn.registrar.obj1"
xsi:schemaLocation="urn.registrar.obj1 obj1.xsd">
... object specific identifier fields ...
</obj1:list>
</list>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientYY</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</request>
A response must be sent to the client along with the data elements
that include a list of registrar object specific unique identifiers.
Example:
Brunner, et al Expires August 2001 [Page 26]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
</response>
<reply>
<code>nnn</code>
<message>message text</message>
</reply>
<data>
... object specific fields identifying
registrar identifiers ...
</data>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientYY</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</response>
Authorization: All clients must be authorized to use the "list"
request.
2.3.3 Transaction Management
Transaction management services permit the registrar client to cancel
or obtain status on a transaction. The server executes the requested
operation and returns the result. The service users, both in the
client and the server, are always notified about the completion of
the transaction, whether it succeeded or failed. Failure can be
caused by an error either by the client or server. XRP provides the
following transaction management operations for objects supported in
the registry.
2.3.3.1 Cancel
A "cancel" element is used to cancel any transaction, processed
successfully. The server will allow canceling transactions, only with
in a certain grace period after the completion of the transactions.
The "cancel" element has the transaction id of the request - in the
"request-id" element.
Example:
<request>
<cancel>
<request-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</request-id>
</cancel>
Brunner, et al Expires August 2001 [Page 27]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</transaction-id>
</request>
The server must respond with a success or failure reply.
Authorization: Accepted only from the original requesting registrar.
2.3.3.2 Transaction Status
A "trans-status" element is used to query the status of an earlier
request. The "trans-status" element has the transaction id of the
request - in the "request-id" element.
Example:
<request>
<trans-status>
<request-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</request-id>
</trans-status>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>-id>
</transaction-id>
</request>
The server must respond with a success or failure reply.
Example:
<response>
<reply>
<code>nnn</code>
<message> ... message text ... </message>
</reply>
<transaction-id>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>-id>
</transaction-id>
</response>
Brunner, et al Expires August 2001 [Page 28]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Authorization: Accepted only from the original requesting
registrar.
3. Response Codes
XRP requests will return a variety of response codes to signify
success completion or failure conditions. Every XRP response must
include a response code and a human-readable description of the
response code. If not specified in the data exchange profile, the
default language is US English. The following table lists all the
defined XRP response codes.
Category Code Response text in US English
-----------------+-------------+---------------------------------------
Success 111 Request completed successfully
Failure 999 Request failed
-----------------+-------------+---------------------------------------
Protocol Syntax 200 Syntax error in parameters
201 Unknown request
202 Invalid request syntax
203 General syntax error
204 Invalid parameter
205 Parameter value range error
206 Missing required parameter
207 Parameter value syntax error
208 Transaction Identifier is not unique
for the request
209 Invalid Channel number
Channel does not exist
-----------------+-------------+---------------------------------------
Object Management300 Unknown object services requested
301 Duplicate object
302 Object not eligible for deletion
303 Object is not eligible for renewal
304 Object is not eligible for transfer
305 Object is not eligible for checking
306 Object is not eligible for querying
307 Access denied to query this object
308 Object status prohibits requested operation
-----------------+-------------+---------------------------------------
Session/Channel 400 Server ending session
Management
401 Timeout; server ending session
402 Authentication required
403 Authentication mechanism insufficient
Brunner, et al Expires August 2001 [Page 29]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
404 Authentication mechanism requires encryption
405 Authentication failure
406 Authorization failure
407 Too many sessions open
408 Invalid channel number
409 Duplicate channel
410 Transaction Pending
411 Transaction Canceled
412 Transaction Succeeded
413 Transaction Failure
-----------------+-------------+---------------------------------------
Billing 500 Insufficient amount in account to perform
operation
-----------------+-------------+---------------------------------------
Registry Management
600 Registry services unavailable due to
Planned Maintenance
4. Formal Syntax
XRP is specified in XML Schema definition notation. The formal syntax
of XML enables automated validation of the XRP XML instances.
5. Internationalization Considerations
XRP is a protocol based on XML, which provides native support for
encoding information using the double-byte Unicode character set and
other representations such as UTF-8. Standard compliant XML
processors should be able to understand both Unicode and UTF-8
character sets. XRP assumes UTF-8 as the default encoding character
set. XML also includes a provision for identifying other character
sets through use of an "encoding" attribute in an <?xml?> processing
instruction. The complete list of character set encoding identifiers
is maintained by IANA and is described in [CHARSET] and [RFC1700].
XRP returns a human-readable message with every response code. The
XRP Specification describes result codes in US English, but the
actual text returned with a result may be provided in a language
negotiated when a session is established. Languages other than US
English must be noted through specification of a "lang" attribute for
text-based elements. Valid values for the "lang" attribute and
"lang" negotiation elements are described in [RFC1766].
All date-time values presented via XRP must be expressed in Universal
Brunner, et al Expires August 2001 [Page 30]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Coordinated Time. The XML Schema "date" format allows use of time
zone identifiers to indicate offsets from the zero meridian, but this
option MUST NOT be used within XRP. Both extended and truncated date
and time forms defined in [ISO8601] MAY be used.
6. IANA Considerations
Schemas must be registered to ensure URI uniqueness, however, the
IETF does not currently have a recommended repository for the
registration of XML schemas. IANA should maintain a registry of XML
namespace and schema URI assignments. Per policies described in
[IANA], URI assignment requests should be reviewed by a designated
functional expert, and values should be assigned only as a result of
standards action taken by the IESG.
7. Security Considerations
XRP provides transport security, authentication, and access control
security mechanisms based on security profiles provided by the
session layer. Protection against denial of service attacks is
provided by network intrusion detection and load distribution
systems.
7.1 Session Layer
Each session is protected at the transport layer by the TLS
encryption scheme that is based on secure socket layer (SSL)
encryption.
7.2 Authentication
XRP uses a variant of the Simple Authentication Security Layer (SASL)
mechanism described in [RFC2595] to provide a simple application-
layer authentication service. The SASL security mechanism specifies
provision of an authorization identifier, authentication identifier,
and password as a single string separated by ASCII NUL characters,
XRP specifies use of a combined authorization and authentication
identifier and digital certificate as distinct XML elements.
7.3 Access Control
XRP uses an authorization identifier and transaction identifier
information to authorize transfer commands. The authorization
identifier, consisting of the registrar client's userid and password,
controls access to transaction services. When an object is created or
transferred on behalf of a third party, the transaction identifier
Brunner, et al Expires August 2001 [Page 31]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
associated with the XRP <create> or <transfer> must be provided to
the third party by using a facility such as TLS that provides privacy
services. Repeated password guessing attempts are discouraged by
limiting the number of <login> attempts that can be attempted on an
open connection. The XRP server MUST close an open connection if
three <login> attempts are made with either an invalid client
identifier, an invalid password, or both an invalid client
identifier, digital certificate, and an invalid userid and password.
References
[GRRP] Hollenbeck, S., "Generic RRP Requirements", Internet-Draft
<draft-hollenbeck-grrp-reqs-06.txt>, work in progress. (To be
replaced by the RFC name when this memo is published.)
[EPP] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
<draft-hollenbeck-epp-00.txt> work in progress. (To be replaced by
the RFC name when this memo is published.)
[BEEP] Rose, M.T., "The Blocks Extensible Exchange Protocol (BEEP)
Framework", <draft-ietf-beep-framework-11.txt> work in progress. (To
be replaced by the RFC name when this memo is published.)
[BXXP] Rose, M.T., "On the Design of Application Protocols", <draft-
mrose-bxxp-design-00.txt> work in progress. (To be replaced by the
RFC name when this memo is published.)
[RFC1700] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[CHARSET] ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets
[RFC1766] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995.
[XML] Bray, T., et al, "Extensible Markup Language (XML) 1.0 (Second
Edition)", 6 October 2000. http://www.w3.org/TR/2000/REC-
xml-20001006
[XML-SCHEMA] XML Schema Part 1: Structures Working Draft. D. Beech,
M. Maloney, N. Mendelshohn. April 2000.
http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/
XML Schema Part 2: Datatypes Working Draft. P. Biron, A. Malhotra.
Brunner, et al Expires August 2001 [Page 32]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
April 2000. http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/
Author's Addresses
Eric Brunner-Williams
NeuStar, Inc.
1415 Forest Ave.,
Portland, ME 04103
Phone: +1 202 533 2600
Email: ebw@neustar.com
Ayesha Damaraju
NeuStar, Inc.
1120 Vermont Ave, N.W.
Suite 550
Washington, DC 20005
Phone: +1 202 533 2600
Email: ayesha.damaraju@neustar.com
Ning Zhang
NeuStar, Inc.
1120 Vermont Ave, N.W.
Suite 550
Washington, DC 20005
Phone: +1 202 533 2600
Email: Ning.Zhang@neustar.com
Brunner, et al Expires August 2001 [Page 33]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Appendix A: Object Mapping
A.1 Introduction
This appendix documents the XRP command mapping to six registry
objects that are supported in the XRP transactions: contact,
nameserver, domain-name, intellectual property, registrant, and
registrar. XRP object mappings are described in a format similar to
that used in the base document.
A.2 Object Attributes
The attributes associated with each object are described in this
subsection.
A.2.1 Contact Object
The contact is the registrar's owner of the host and domain objects
in the registry. Contacts are used for billing purposes, finding
responsible parties for the objects, and for ownership and
authenticating modification requests. The sponsoring registrar has
all the administrative privileges to manage the object.
A.2.1.1 Object Elements
The contact object consists of all ICANN required data elements and
elements to the support the extended services of registry describing
a technical, admin, registrant, or billing contact. The contact is
required to have the following elements:
Id - A unique identifier is created for every contact in the registry
and this unique identifier is used to reference a contact. The format
is alphanumeric with the minimum and maximum length and character set
specified in the XML Schema Definition (xsd).
Example:
<id>AD-1234</id>
Name & Contact Type - The name element contains the contact's full
name. The element must also contain a "type" attribute with a value
of either "individual" or "organization". The format is alphanumeric
latin characters with the minimum and maximum length and character
set specified in the XML Schema Definition (xsd).
Example:
Brunner, et al Expires August 2001 [Page 34]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<name type="organization">Ayesha L. Damaraju</name>
Title - The title element contains the contact's title. This element
is optional. The format is alphanumeric latin characters with the
minimum and maximum length and character set specified in the XML
Schema Definition (xsd).
Example:
<title>Systems Engineer</title>
Organization - The organization element contains the name of the
organization that the contact belongs to. This element is optional.
The format is alphanumeric latin characters with the minimum and
maximum length and character set specified in the XML Schema
Definition (xsd).
Example:
<organization>NeuLevel</organization>
Address - The postal address element in supported in normalized
address or in RIPE style address format. The normalized address will
include street, city, state, country and postal code elements,
whereas the RIPE style address will include line element. The format
is alphanumeric latin characters with the minimum and maximum length
for each field specified in the XML Schema Definition (xsd).
Example:
<address>
<street>1120 Vermont Avenue</street>
<city>Washington</city>
<state>DC</state>
<postalcode>20005</postalcode>
<country>US</country>
</address>
Line - The line element contains the address in RIPE style.
Example:
<address>
<line>123 king street, washington, dc, 20005, us</line>
</address>
Street - The street element contains the street line of a postal
address.
Brunner, et al Expires August 2001 [Page 35]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example:
<street>1120 Vermont Avenue</street>
City - The city element contains the city or area of the contact.
This is a ICANN required element.
Example:
<city>Washington</city>
State - The state element contains the state or province of the
contact. This is an ICANN required element.
Example:
<state>DC</state>
Postal Code - The postalcode element contains a delivery indicator
unique to the address of the contact. This is often referred to as
the Zip Code in the USA.
Example:
<postalcode>20005</postalcode>
Country Code - The country element is an ISO 3166-1 alpha-2 two (2)
letter country code for the country of origin of the contacts postal
address.
Example:
<country>US</country>
Voice,Fax - The voice element contains an international telephone
number of the contact. The fax element contains an international
telephone number for facsimile of the contact. The following may be
included ., -, and " " in the phone number for readability. The
number must be a full E.164 number starting with "+" and then country
code.
Example:
<voice>+1.8005551212</voice>
<fax>+1.8005551200</fax>
Email - The email element contains a valid Internet E-Mail address of
the contact.
Brunner, et al Expires August 2001 [Page 36]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example:
<email>ayesha.damaraju@NeuLevel.biz</email>
Sponsoring Registrar - Element contains the identifier of the
sponsoring registrar. The sponsoring registrar client has all the
administrative privileges to manage the object. In addition, it
includes the date and time of the most recent successful transfer to
the sponsoring registrar client. The transferred date must not have
contents in it if the contact has never been transferred. The format
of the time field is UCT extended format of ISO 8601.
Example:
<client>
<transferred-date>yyyy-mm-ddT12:00:00.0Z</transferred-date>
<client-id>clientXX</client-id>
</client>
Created - Element contains the reference to the registrar client that
created the object and date and time of object creation. The format
of the time field is UCT extended format of ISO 8601.
Example:
<created>
<created-date>yyyy-mm-ddT12:00:00.0Z</created-date>
<created-client-id>clientXX</created-client-id>
</created>
Modified - Element contains the reference to the registrar client
that modified the object and date and time of object creation. The
format of the time field is UCT extended format of ISO 8601.
Example:
<modified>
<modified-date>yyyy-mm-ddT12:00:00.0Z</modified-date>
<modified-client-id>clientXX</modified-client-id>
</modified>
Authorization Identifier - This is a transaction identifier of the
original creation transaction or the most recent successful transfer
transaction. The format of each field is as specified in the XML
Schema Definition.
Example:
Brunner, et al Expires August 2001 [Page 37]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<authorization>
<date>yyyy-mm-dd</date>
<client-id>clientXX</client-id>
<code>ABC-12345-XYZ</code>
</authorization>
Access Control - This is the element that defines the access control
for the contact information. The element must be one of the following
strings, which restricts access to the object as specified in the XML
Schema Definition.
1. Default "None"
2. Level of Access = [system, none] where system is registrar only
access and none is no restriction.
Example:
<access>none</access>
Optional elements - An optional element is included in the contact to
support extended whois service and different formats and fields
supported by different registrars. Optional elements consist of two
elements "key" and "value". Each optional element will carry
additional key and the respective value of the key.
Example:
<optional>
<key>field1</key>
<value>value1</value>
</optional>
A.2.2 Nameserver Object
The nameserver object elements must contain the names and IP
addresses of authoritative nameservers for the domain. Nameserver is
associated with maximum of 13 IP addresses. Nameservers are required
by ICANN and must be reference in all "domain" elements. The
sponsoring registrar has all the administrative privileges to manage
the object.
A.2.2.1 Object Elements
The nameserver includes the following elements:
Fully Qualified Name - The fqdn attribute specifies the fully
qualified name of the nameserver, a unique name by which the server
is referenced by the other objects. The format is alphanumeric and
Brunner, et al Expires August 2001 [Page 38]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
must be a valid Internet hostname.
Example:
<name>ns1.neulevel.biz</name>
IP Address element - IP address element contains the IP address(es)
associated with the nameserver. Nameserver can be associated with up
to 13 IP addresses.
Example:
<ip>101.1.1.1</ip>
<ip type="ipv6">::FFF:102.1.1.2</ip>
The ip element contains IP version 4 or version 6 address information.
The attribute type can either be "ipv4" or "ipv6" this attribute
defaults to ipv4 if it is not listed.
Sponsoring Registrar - Element contains the identifier of the
sponsoring registrar client. The sponsoring registrar has all the
administrative privileges to manage the object.
Transferred Date - This element includes the date and time of the most
recent successful transfer to the sponsoring registrar element. The
transferred date must not have contents in it if the contact has never
been transferred.
Example:
<client>
<client-id>registrar001</client-id>
<transferred-date>yyyy-mm-ddT12:00:00.0Z</transferred-date>
</client>
Created - Element contains the reference to the registrar that
created the object and date and time of object creation.
Example:
<created>
<created-date>yyyy-mm-ddT12:00:00.0Z</created-date>
<created-client-id>registrar001</created-client-id>
</created>
Modified - Element contains the reference to the registrar that
modified the object and date and time of object creation.
Brunner, et al Expires August 2001 [Page 39]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example:
<modified>
<modified-date>yyyy-mm-ddT12:00:00.0Z</modified-date>
<modified-client-id>registrar001</modified-client-id>
</modified>
Authorization Identifier - This is a transaction identifier of the
registrar who successfully completed the most recent transfer
transaction.
Example:
<authorization>
<date>yyyy-mm-dd</date>
<client-id>registrar001</client-id>
<code>ABC-12345-XYZ</code>
</authorization>
A.2.3 Domain-name Object
The domain-name object contains references to nameserver host objects
for building the root's zone files, references to contacts for
billing, authentication and delegation of responsible parties.
Domain-name objects are identified by their fully qualified domain-
name. The sponsoring registrar has all the administrative privileges
to manage the object.
A.2.3.1 Object Elements
The domain-name object includes the following elements:
Fully Qualified domain-name - This attribute specifies the fully
qualified domain-name, a unique name by which the server is
referenced by the other objects.
Example:
<name>neulevel.biz</name>
Nameserver(s) Elements - The nameserver(s) elements contain the fully
qualified names of the nameserver(s) associated to the domain object.
There are multiple instances of the nameserver element. Up to 13
nameservers can be listed The format is alphanumeric and must be a
valid Internet hostname.
Example:
Brunner, et al Expires August 2001 [Page 40]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<nameserver>ns1.neulevel.biz</nameserver>
Child Server Elements - The child server elements contain the fully
qualified names of the child nameservers created under the parent
domain. An unlimited number of child nameserver elements may be
specified.
Example:
<childserver>NY01.neulevel.net</childserver>
Sponsoring Registrar - Element contains the identifier of the
sponsoring registrar client.
Registrant Transfer Date - This Element includes the date and time of
the most recent successful transfer to the sponsoring registrar. The
transferred date must not have contents in it if the contact has
never been transferred.
Example:
<client>
<client-id>registrar001</client-id>
<transferred-date>yyyy-mm-ddT12:00:00.0Z</transferred_date>
</client>
Registrant Identifier - Element contains the registrant identifier of
the registrant.
Example:
<registrant-id>coca-cola-000001</registrant-id>
Contact Elements - The contact elements contain contact identifiers
for the registrar "administrative", "technical", and "billing"
contacts. The type of the contact is specified by the type attribute
associated with each contact element. There are multiple instances of
the contact element.
Example:
<contact type="billing">John-R-Doe-00001</contact>
Expiration date - The expiration date element contains the date and
time identifying the end of the domain-names registration period.
Example:
Brunner, et al Expires August 2001 [Page 41]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<expiration-date>yyyy-mm-ddT12:00:00.0Z</expiration-date>
Registration Period - The registration period element contains the
date and time identifying the length of domain-names registration
period.
Example:
<period>2</period>
Restricted TLD Authorization - Element contains the authorization of
the registrant, to register a domain in the restricted .tld.
Example:
<reg-auth>authorized</reg-auth>
Created - Element contains the reference to the registrar that
created the object and date and time of object creation.
Example:
<created>
<created-date>yyyy-mm-ddT12:00:00.0Z</created-date>
<created-client-id>clientXX</created-client-id>
</created>
Modified - Element contains the reference to the registrar that
modified the object and date and time of object creation.
Example:
<modified>
<modified-date>yyyy-mm-ddT12:00:00.0Z</modified-date>
<modified-client-id>clientXX</modified-client-id>
</modified>
Authorization Identifier - This is a transaction identifier of the
original creation transaction or the most recent successful transfer
transaction.
Example:
<authorization>
<date>yyyy-mm-dd</date>
<client-id>registrat001</client-id>
<code>ABC-12345-XYZ</code>
</authorization>
Brunner, et al Expires August 2001 [Page 42]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Status Elements - The status element contains the current status
associated with the domain. A domain may have multiple status entries
at any given time. Some status entries may be mutually exclusive.
Indicators must be provided to identify a newly created state,
inactive with no active nameservers associated with it, an active
state, a hold state, a lock state, a pending transfer state, and a
pending removal state.
Example:
<status>active</status>
A.2.4 Intellectual Property
The intellectual property object will contain the information, for
providing intellectual property notification service. This includes
registered trademarks and brandnames. The sponsoring registrar has
all the administrative privileges to manage the object.
A.2.4.1 Object Elements
The intellectual property object includes the following elements:
Id - a unique id is stored for every intellectual property object in
the registry and this unique identifier is used to reference an
object instance. The format is 3 to 16 character alphanumerical field
specified in the XML Schema Definition.
Example:
<id>coca-cola0000001</id>
Monitored String - Each object must contains multiple instances of a
monitored string, over which the party claims intellectual property.
The type of matching must be specified for each monitor string; for
example, [exact, partial, regexp]. An unlimited number of monitored
string entities may be specified.
Example:
<monitor-string type="exact">coca-cola</monitor-string>
<monitor-string type="regexp">[A-Za-z]*cola|cola[0-9]*
</monitor-string>
<monitor-string type="partial">coca</monitor-string>
Trademark - the trademark element identifies the information related
to the trademark. There are three types of trademark entities:
"trademark", "service mark", and "claim". The trademark element must
Brunner, et al Expires August 2001 [Page 43]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
contain the following information.
1. Exact trademark - "name"
2. Country of registration - "country"
3. Trademark Serial Number - "reference"
4. Trademark Registration Number - "registration-no"
5. Date of first use - "date"
6. Indicator - "indicator", Values are "live" or "dead"
Example:
<trademark type="trademark">
<name>coco-cola</name>
<country>US</country>
<reference>nnnnnnnn</reference>
<registration-no>nnnnnnn</registration-no>
<date>yyyy-mm-dd</date>
<indicator>live</indicator>
</trademark>
Contact Elements - The contact elements contain contact identifiers
for trademark "holder" organization representative, the notification
receiver "receiver" representative and the "legal" representative.
The type of the contact is specified by the type attribute associated
with each contact element. There are multiple instances of the
contact element.
Example:
<contact type="legal">lee-f-bailey0001</contact>
Sponsoring Registrar - Element contains the registrar identifier of
the sponsoring registrar client.
Transferred Date - This element includes the date and time of the
most recent successful transfer to the sponsoring registrar element.
The transferred date must not have contents in it if the contact has
never been transferred.
Example:
<client>
<client-id>registrar001</client-id>
<transferred-date>yyyy-mm-ddT12:00:00.0Z</transferred-date>
<client>
Registration Period - The registration period element contains the
date and time identifying the length of intellectual property
registration period.
Brunner, et al Expires August 2001 [Page 44]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example:
<period>2</period>
Expiration date - The expiration date element contains the date and
time identifying the end of the object's registration period.
Example:
<expiration-date>yyyy-mm-ddT12:00:00.0Z<expiration-date>
Created - Element contains the reference to the registrar id that
created the object and date and time of object creation.
Example:
<created>
<created-date>yyyy-mm-dd</created-date>
<created-client-id>registrar0001</created-client-id>
</created>
Modified - Element contains the reference to the registrar id that
modified the object and date and time of object creation.
Example:
<modified>
<modified-date>yyyy-mm-ddT12:00:00.0Z</modified-date>
<modified-client-id>registrar001</modified-client-id>
</modified>
Authorization Identifier - This is a transaction identifier of the
original creation transaction or the most recent successful transfer
transaction.
Example:
<authorization>
<date>yyyy-mm-dd</date>
<client-id>registrar001</client-id>
<code>ABC-12345-XYZ</code>
</authorization>
Optional elements - An optional element is included in the contact to
support extended services supported by different registrars. Optional
elements consist of two elements "key" and "value". Each optional
element will carry additional key and the respective value of the
key.
Brunner, et al Expires August 2001 [Page 45]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example:
<optional>
<key>field1</key>
<value>value1</value>
</optional>
A.2.5 Registrant Object
The registrant object will contain information on the holder of a
registered domain name. The sponsoring registrar has all the
administrative privileges to manage the object.
A.2.5.1 Object Elements
The registrant object includes the following elements:
Id - A unique identifier is created for every registrant object in
the registry and this unique registrant identifier is used to
reference an object instance. The registrant identifier is an
alphanumeric field 3 to 16 characters in length defined by the XML
Schema Definition.
Example:
<id>coca-cola-000001</id>
Registrant Name - Each object must contain only one registrant name -
the businesses or entity name.
Example:
<name>Coca-Cola Company</name>
Address - The postal address element in supported in normalized
address or in RIPE style address format. The normalized address will
include street, city, state, country and postal code elements,
whereas the RIPE style address will include line element.
Example:
<address>
<street>1120 Vermont Avenue</street>
<city>Washington</city>
<state>DC</state>
<country>US</country>
<postalcode>20005</postalcode>
</address>
Brunner, et al Expires August 2001 [Page 46]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Line - The line element contains the address in RIPE style.
Example:
<address>
<line> ... </line>
</address>
Street - The street element contains the street line of a postal
address.
Example:
<street>1120 Vermont Avenue</street>
City - The city element contains the city or area of the contact.
This is an ICANN required element.
Example:
<city>Washington</city>
State - The state element contains the state or province of the
contact. This is a ICANN required element.
Example:
<state>DC</state>
Postal Code - The postal code element contains a delivery indicator
unique to the address of the contact. This is often referred to as
the Zip Code in the USA.
Example:
<postalcode>20005</postalcode>
Country Code - The country element is an ISO 3166-1 alpha-2 two-
letter country code for the country of origin of the contacts postal
address.
Example:
<country>US</country>
Contact Elements - The contact elements contain contact identifiers
for the domain-name "holder" organizational and "administrative"
contact personnel. The type of the contact is specified by the type
Brunner, et al Expires August 2001 [Page 47]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
attribute associated with each contact. There are multiple instances
of the contact element.
Example:
<contact type="holder">JB-Griffen000001</contact>
Dun and Bradstreet (D&B) D-U-N-S(R) Number - the D-U-N-S Number is an
exclusive nine-digit number, assigned to each business location in
D&B's global database. It is widely used as a tool for identifying,
organizing and consolidating information about businesses.
Example:
<duns-number>123456789</duns-number>
Industry Code - the "industry-code" element is of type = [sic,
naics]. The sic Code is an exclusive 4-digit code that classifies
the industries and the naics Code is a new code that identifies
industries by a 6-digit code. The new naics Code will eventually
replace the sic Code.
Example:
<industry-code type="sic">4231</industry-code>
Sponsoring Registrar - Element contains the registrar identifier of
the sponsoring registrar client.
Example:
<client>
<client-id>registrar001</client-id>
<client>
Created - Element contains the reference to the registrar id that
created the object and date and time of object creation.
Example:
<created>
<created-date>yyyy-mm-ddT12:00:00.0Z</created-date>
<created-client-id>registrar001</created-client-id>
</created>
Modified - Element contains the reference to the registrar id that
modified the object and date and time of object creation.
Brunner, et al Expires August 2001 [Page 48]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example:
<modified>
<modified-date>yyyy-mm-ddT12:00:00.0Z</modified-date>
<modified-client-id>registrar001</modified-client-id>
</modified>
Authorization Identifier - This is a transaction identifier of the
original creation transaction or the most recent successful transfer
transaction.
Example:
<authorization>
<date>yyyy-mm-dd</date>
<client-id>registrar001</client-id>
<code>ABC-12345-XYZ</code>
</authorization>
Status - The status element contains the current status associated
with the registrar (active, suspended, defunct). A registrar may have
only one status entry at any given time.
Example:
<status>active</status>
Optional elements - An optional element is included in the contact to
support extended services supported by different registrars. Optional
elements consist of two elements "key" and "value". Each optional
element will carry additional key and the respective value of the
key.
Example:
<optional>
<key>field1</key>
<value>value1</value>
</optional>
A.2.6 Registrar Object
The registrar object will contain the information for each ICANN
certified registrar. The sponsoring registrar has all the
administrative privileges to manage the object.
A.2.6.1 Object Elements
Brunner, et al Expires August 2001 [Page 49]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
The registrar object includes the following elements:
Id - A unique identifier is created for every registrar object in the
registry and this unique identifier is used to reference an object
instance. The identifier is an alphanumeric field 3 to 16 characters
in length defined by the XML Schema Definition.
Example:
<id>registrar0000001</id>
Registrar Name - Each object must contain only one registrar name,
the businesses name. Example:
<name>INWW</name>
Address - The postal address element in supported in normalized
address or in RIPE style address format. The normalized address will
include street, city, state, country and postal code elements,
whereas the RIPE style address will include line element.
Example:
<address>
<street>1120 Vermont Avenue</street>
<city>Washington</city>
<state>DC</state>
<country>US</country>
<postalcode>20005</postalcode>
</address>
Line - The line element contains the address in RIPE style.
Example:
<address>
<line> ... </line>
</address>
Street - The street element contains the street line of a postal
address.
Example:
<street>1120 Vermont Avenue</street>
City - The city element contains the city or area of the contact.
This is an ICANN required element.
Brunner, et al Expires August 2001 [Page 50]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example:
<city>Washington</city>
State - The state element contains the state or province of the
contact. This is a ICANN required element.
Example:
<state>DC</state>
Postal Code - The postalcode element contains a delivery indicator
unique to the address of the contact. This is often referred to as
the Zip Code in the USA.
Example:
<postalcode>20005</postalcode>
Country Code - The country element is an ISO 3166-1 alpha-2 two (2)
letter country code for the country of origin of the contacts postal
address.
Example:
<country>US</country>
Web Address - The URL of the Registrar's homepage.
Example:
<web-url>http://www.nuelevel.biz</Web-url>
Dun and Bradstreet (D&B) D-U-N-S-Number - the D-U-N-S Number is an
exclusive nine-digit number, assigned to each business location in
D&B's global database. It is widely used as a tool for identifying,
organizing and consolidating information about businesses.
Example:
<duns-number>nnnnnnnnn</duns-number>
Industry Code (icode) - the industry code is of type = [SIC, NAICS].
The SIC Code is an exclusive 4-digit code that classifies the
industries and the NAICS Code is a new code that identifies
industries by a 6-digit code. The new NAICS code will eventually
replace the SIC Code.
Brunner, et al Expires August 2001 [Page 51]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example:
<industry-code type="sic">4231</industry-code>
<industry-code type="naics">123456</industry-code>
ICANN Certification ID - the Registrar certification number assigned
by ICANN to each fully qualified registrar.
Example:
<icann-id>dddddddddd</icann-id>
Contact Elements - The contact elements contain contact identifiers
for registrar "service manager", "public relations", "technical",
"administrative", and "billing" person. The type of the contact is
specified by the type attribute associated with each contact element.
There are multiple instances of the contact element.
Example:
<contact type="administrative">Clive-L-Forley01</contact>
Created - Element contains the reference to the registrar that
created the object and date and time of object creation.
Example:
<created>
<created-date>yyyy-mm-ddT12:00:00.0Z</created-date>
<created-client-id>registrar001</created-client-id>
</created>
Modified - Element contains the reference to the registrar that
modified the object and date and time of object creation.
Example:
<modified>
<modified-date>yyyy-mm-ddT12:00:00.0Z</modified-date>
<modified-client-id>registrar001</modified-client-id>
</modified>
Authorization Identifier - This is a transaction id of the original
creation transaction or the most recent transfer transaction.
Example:
<authorization>
Brunner, et al Expires August 2001 [Page 52]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<date>yyyy-mm-dd</date>
<client-id>registrar001</client-id>
<code>ABC-12345-XYZ</code>
</authorization>
Status - The status element contains the current status associated
with the registrar (active, suspended, defunct). A registrar may have
only one status entry at any given time.
Example:
<status>active</status>
a_3_xrp_command_mappings.ms
A.3 XRP Command Mappings
This section describes the object-specific mappings required to
implement each XRP command. Figure A-1 summarizes the command to
object mappings.
Legend:
OMF = Object Management Functions
CON = Contact
NS = Nameserver
Dname = Domain Name
IP = Intellectual Property
RRAR = Registrar
RANT = Registrant
OMF CON NS Dname IP RRAR RANT
--------+-------+-------+-------+-------+-------+-------
Create Y Y Y Y Y
Delete Y Y Y Y Y
Modify Y Y Y Y Y
Renew Y Y
Xfr Y Y Y Y
Query Y Y Y Y Y Y
Check Y Y Y Y Y Y
List Y
Figure A-1. XRP Command to Object Mappings
A.3.1 Create
The object specific command mappings for implementation of the create
command are described in this subsection.
Brunner, et al Expires August 2001 [Page 53]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
A.3.1.1 Contact Object
The "contact:create" element in the "create" object creates an
instance of contact object in the registry. It must be used to
register contact information describing human and organizational
entities. Contact registration must not be limited to a specific
period of time. The "contact:create" request shall contain the
following child elements:
Create Contact
--------------------------------
Child Element Required
Name Y
Title N
Organization N
Address Y
(line or normalized)
Voice Y
Fax N
Email Y
Authorization ID N
Access control N
Digital Certificate N
Optional Elements N
The response "contact:create-response" to the request
Create Contact Response
--------------------------------
Child Element
Contact Unique Identifier
Example: A registrar registers a contact.
<request>
<create>
<contact:create xmlns:contact="urn.NeuLevel.contact"
xsi:schemaLocation="urn.NeuLevel.contact contact.xsd">
<contact:name type="organization">John R. Doe</contact:name>
<contact:organization>NeuStar</contact:organization>
<contact:address>
<contact:street>1120 Vermont Ave.</contact: street>
<contact:city>Washington</contact:city>
<contact:state>DC</contact:state>
<contact:postalcode>20005</contact:postalcode>
<contact:country>US</contact:country>
</contact:address>
<contact:voice>+1.8005551212</contact:voice>
<contact:fax>+1.8005551212</contact:fax>
Brunner, et al Expires August 2001 [Page 54]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<contact:email>ayesha.damaraju@NeuLevel.com</contact:email>
</contact:create>
</create>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successfully processing the request must respond to the
client with the "create-response" element in "data" element of
"response". The response must include the server's unique identifier
for the contact, by which the server will identify the contact.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<contact:create-response xmlns:contact="urn.NeuLevel.contact"
xsi:schemaLocation="urn.NeuLevel.contact contact.xsd">
<contact:id>J-R-Doe-0001</contact:id>
</contact:create-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to create a contact.
Default access is None.
A.3.1.2 Nameserver Object
The "ns:create" element in the "create" object creates an instance of
nameserver object in the registry. The request to register a
nameserver in the same TLDs, must be the child of a registered domain
name and must include one or more and a maximum of 13, nameserver IP
addresses. Nameservers associated with domains registered in other
TLDs should not be specified with IP addresses to reduce the
possibility of duplicating DNS NS records for the nameservers in
multiple zone files.
Nameserver registration must not be limited to a specific period of
time. The "ns:create" request shall contain the following child
elements:
Brunner, et al Expires August 2001 [Page 55]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Create Nameserver
--------------------------------
Child Element Required
Name Y
IP address N
The response to the request will not contain any object specific
data.
Example: A registrar registers a nameserver.
<request>
<create>
<ns:create xmlns:ns="urn.NeuLevel.ns
xsi:schemaLocation=urn.NeuLevel.ns ns.xsd>
<ns:name>ns1.example.tld</ns:name>
<ns:ip>100.1.0.1</ns:ip>
</ns:create>
</create>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client with "response".
Example:
<response>
<reply>
... success reply ...
</reply>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to create nameservers in
the domain they administer.
1. A request to register an object must include a transaction
identifier. The transaction identifier must be returned to the
registrant by the registrar to facilitate authorization of future
transfer requests.
2. The system will register the nameserver along with the data sent.
3. The system will assign the created, modified date elements in the
Brunner, et al Expires August 2001 [Page 56]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
nameserver object.
4. The system will associate the nameserver with the given contact
references.
5. If the nameserver is successfully registered, the system must
return the unique nameserver handle to the registrar.
6. Unauthorized attempts to register nameserver in a parent domain
administered by another registrar will be rejected.
7. Response codes - Unauthorized domain
A.3.1.3 Domain-name Object
A "domain:create" element is used within the "create" request to
create a domain-name instance. The request to register a domain-name
must contain a domain-name element with fully qualified name, maximum
of 13, already registered nameserver references, contact references
(minimum references to admin and technical contact) and optional
registration period in years.
Domain registration must be limited to a specific period of time.
The "domain:create" request shall contain the following child
elements:
Create Domain-name
--------------------------------
Child Element Required
FQDN Y
Nameservers Y
Child nameservers N
Registrar ID Y
Registrant ID Y
Contacts [type=] Y
Registration Period Y
Restricted Registration N
Authorization
(based on tld)
The response "domain:create-response" to the request
Create Domain Response
--------------------------------
Child Element
Domain-name
Expiration date
Brunner, et al Expires August 2001 [Page 57]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Examples: A registrar registers a domain name.
<request>
<create>
<domain:create xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
<domain:name>coca-cola.biz</domain:name>
<domain:nameserver>ns1.neulevel.biz</domain:nameserver>
<client:id>INWW-ab123456789</client:id>
<client:id>registrant000001</clinet:id>
<domain:contact type="administrative">
John-R-Doe001
</domain:contact>
<domain:contact type="technical">
Jim-V-Brown002
</domain:contact>
<domain:period>2</domain:period>
</domaint:create>
</create>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing must respond with
"create-response" element in "data" element of "response". The
response must include the fully qualified name of the domain and the
expiration date of the domain.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<domain:create-response xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
<domain:name>coca-cola.biz</domain:name>
<domain:expiration-date>yyyy-mm-dd
</domain:expiration-date>
</domain:create-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Brunner, et al Expires August 2001 [Page 58]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
The server on successful processing the request notifies any clients
registered for an intellectual property notification service for the
created domain.
Example:
<notification>
<data>
<domain:create-response xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
<domain:name>coca-cola.biz</domain:name>
<domain:expiration-date>yyyy-mm-dd
</domain:expiration-date>
</domain:create-response>
</data>
<notification-id>
... notification identifier elements ...
</notification-id>
</notification>
Authorized users: All clients are authorized to create a domain.
1. A request to register an domain object must include a transaction
identifier. The transaction identifier must be returned to the
registrant by the registrar to facilitate authorization of future
transfer requests.
2. The registration period for domain names must be measured in years
with the minimum period of one year and a maximum period defined by
registry policy.
3. The system will register the domain name to the registrar for the
period specified by the registrar. If the registrar does not specify
a registration period, a system-specific default value must be used
for the initial registration period.
4. The system will associate the domain with given nameserver
references and the status to "new".
5. The system will register the domain name and associate the domain
with given contacts along with the types of contacts, and requested
registrar as the created registrar.
6. The system will assign the created, expired, modified date
elements in the domain object.
7. If the domain is successfully registered, the system must return
the registration expiration date in the response.
Brunner, et al Expires August 2001 [Page 59]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
All registrars may use this service to register domain names.
Response codes:
1. Success
2. Domain name not available (already used)
3. Invalid reference (no reference Nameserver, Contact)
4. Missing required attribute
5. Invalid attribute value syntax
6. Invalid option value
7. Invalid command format
8. Missing command option
A.3.1.4 Intellectual Property Object
The "iprop:create" element is used within the "create" request to
create a intellectual property instance. The request to register a
"iprop" object must contain a monitor-string, trademark or brand
details, expiration-date, and contact references (admin, receiver and
holder organization.
The "iprop:create" request shall contain the following child
elements:
Create iprop
--------------------------------
Child Element Required
monitor-string Y
Trademark [type=] Y
Contacts [type=] Y
Registration Period Y
Authorization ID N
Optional elements N
The response to the request shall be "iprop:create-response".
Create iprop Response
--------------------------------
Child Element
Intellectual Property ID
Expiration Date
Example: A registrar registers a trademark string of a client.
<request>
<create>
<iprop:create xmlns:iprop="urn.NeuLevel.iprop
xsi:schemaLocation="urn.NeuLevel.iprop iprop.xsd">
Brunner, et al Expires August 2001 [Page 60]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<iprop:monitor-string type="exact">
coca-cola
</monitor-string>
<iprop:trademark type="trademark">
<iprop:name>coca-cola</iprop:name>
<iprop:country>US</iprop:country>
<iprop:serial-no>nnnnnnnn</iprop:serial-no>
<iprop:registration-no>nnnnnnn</registration-no>
<iprop:date>yyyy-mm-dd</iprop:date>
</iprop:trademark>
<period>2</period>
<iprop:contact type="administrative">
Jim-N-Smith00001
</iprop:contact>
<iprop:contact type="holder">
L-L-Bean00002
</iprop:contact>
<iprop:contact type="receiver">
Jane-W-Lawyer0003
</iprop:contact>
<client:id>registrar001</client:id>
</create>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client request with "create-response" element in
"data" element of "response". The response must include the server's
unique identifier for the intellectual property, by which the server
will identify the intellectual property.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<iprop:create-response xmlns:iprop="urn.NeuLevel.iprop"
xsi:schemaLocation="urn.NeuLevel.iprop iprop.xsd">
<iprop-id>nnnnnnnnn</iprop-id>
<iprop:expiration-date>yyyy-mm-dd</iprop:expiration-date>
</iprop:create-response>
</data>
<transaction-id>
... transaction id data ...
Brunner, et al Expires August 2001 [Page 61]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
</transaction-id>
</response>
Authorized users: All clients are authorized to create an iprop
object.
A.3.1.5 Registrant Object
The "registrant:create" element is used within the "create" request
to create a registrant object instance. The request to create a
"registrant" object must contain a registrant id, name, address,
contact references [owner, admininstration] and status.
The "registrant:create" request shall contain the following child
elements:
Create registrant
--------------------------------
Child Element Required
Name Y
Address Y
Contacts [type=] Y
DUNS Number N
Industry Code [type=] N
Status N
Authorization ID Y
Optional Elements N
The response to the request shall be "registrant:create-response".
Create registrant Response
--------------------------------
Registrant ID
Example: A registrar registers a registrant.
<request>
<create>
<registrant:create xmlns:registrant="urn.NeuLevel.iprop"
xsi:schemaLocation="urn.NeuLevel.registrant registrant.xsd">
<name>registrant00001</name>
<registrant:name type="owner">
John-R-Doe00001
</registrant:name>
<registrant:address>
<registrant:street>
1120 Vermont Ave.
</registrant:street>
Brunner, et al Expires August 2001 [Page 62]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<registrant:city>Washington</registrant:city>
<registrant:state>DC</registrant:state>
<registrant:postalcode>20005</registrant:postalcode>
<registrant:country>US</registrant:country>
</registrant:address>
</registrant:create>
</create>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client request with "create-response" element in
"data" element of "response". The response must include the server's
unique identifier for the registrant, by which the server will
identify the registrant.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<registrant:create-response xmlns:iprop="urn.NeuLevel.iprop"
xsi:schemaLocation="urn.NeuLevel.iprop iprop.xsd">
<registrant-id>registrant00001</registrant-id>
</registrant:create-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to create an iprop
object.
A.3.2 Delete
The object specific command mappings for implementation of the delete
command are described in this subsection.
A.3.2.1 Contact Object
The delete contact transaction allows a registrar to remove a contact
from the registry. Contacts must be referenced by the unique registry
identifier. A contact must not be deleted if it is associated with a
Brunner, et al Expires August 2001 [Page 63]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
domain-name.
Delete Contact
--------------------------------
Child Element Required
Contact Unique Id Y
The response to the request will not contain any object specific
data.
Example:
<request>
<delete>
<contact:delete xmlns:contact="urn.NeuLevel.contact"
xsi:schemaLocation="urn.NeuLevel.contact contact.xsd">
<contact:id>John-R-Doe0001</contact:id>
</contact:delete>
</delete>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on completion of processing the request must respond with
a success/ failure result with no data element in "response" element.
Example:
<response>
<reply>
... success/failure reply ...
</reply>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All registrar clients are authorized to delete
contacts that they administer. For contacts with associations, the
response codes are:
1. Associated to a domain-name
2. Associated to a nameserver
A.3.2.2 Nameserver Object
Brunner, et al Expires August 2001 [Page 64]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
The "delete" nameserver request is used to remove a nameserver from
the registry along with "ns:delete" element. The "ns:delete" request
shall contain the following child elements:
Delete Nameserver
--------------------------------
Child Element Required
Name Y
The response to the request will not contain any object specific
data. A request to remove a nameserver object must include a
transaction identifier. The nameserver must be referenced using fully
qualified nameserver name in the registry. Lame delegation process -
notify registrar of the domain names using nameserver.
Examples: A registrar deletes a nameserver from the registry.
<request>
<ns:delete xmlns:ns="urn.NeuLevel.ns"
xsi:schemaLocation="urn.NeuLevel.ns ns.xsd">
<name>cns1.coca-cola.net</name>
</ns:delete>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on completion of processing the request must respond with
a success/failure result with no data element in "response" element.
Example:
<response>
<reply>
... success reply ...
</reply>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized user: The current registrar of a nameserver may use the
transaction to delete a nameserver from the registry.
Response codes - active domain-names associated to the nameserver.
A.3.2.3 Domain-name Object
Brunner, et al Expires August 2001 [Page 65]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
A "domain:delete" element is used within the "delete" request to
delete a domain-name already created in the registry. Deleting a
domain-name will also delete all child nameservers. A domain name
must not be deleted if child nameservers are being used to host other
domain-names.
Delete Domain
--------------------------------
Child Element Required
FQDN Y
A request to remove a domain-name object must include a transaction
identifier. The domain-name must be referenced using fully qualified
domain name the unique identifier for the domain-name in the
registry. Lame delegation process - notify registrar of the domain-
names using child nameservers.
Example:
<request>
<delete>
<domain:delete xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
<domain:name>coca-cola.biz</domain:name>
</domain:delete>
</delete>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client with a success/failure result with no data
element in "response".
Example:
<response>
<reply>
... success/failure reply ...
</reply>
<transaction-id>
... transaction id data ...
</transaction-id>
Brunner, et al Expires August 2001 [Page 66]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
</response>
Authorized users: All clients are authorized to delete domains that
they administer.
Response codes - active domain names associated to the child
nameservers.
A.3.2.4 Intellectual Property Object
The "iprop:delete" element is used within the "delete" request to
delete a intellectual property object already created in the
registry.
Delete I-Property
--------------------------------
Child Element Required
IP Identifier Y
Example:
<request>
<delete>
<iprop:delete xmlns:iprop="urn.NeuLevel.iprop"
xsi:schemaLocation="urn.NeuLevel.iprop iprop.xsd">
<iprop:id>coca-cola0000111</iprop:id>
</iprop:delete>
</delete>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on completion of processing the request must respond to
the client with a success/ failure result with no data element in the
response. The response to the request shall not contain any object
specific data.
Example:
<response>
<reply>
... success/failure reply ...
</reply>
<transaction-id>
Brunner, et al Expires August 2001 [Page 67]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to delete intellectual
property objects that they administer.
A.3.2.5 Registrant Object
The "registrant:delete" element is used within the "delete" request
to delete a registrant object already created in the registry. The
registrant object must not be deleted if it is associated with any
domain-names in the registry.
Delete Registrant
--------------------------------
Child Element Required
Registrant Identifier Y
Example:
<request>
<delete>
<registrant:delete xmlns:registrant="urn.NeuLevel.registrant"
xsi:schemaLocation="urn.NeuLevel.registrant registrant.xsd">
<registrant-id>registrant00001</registrant-id>
</registrant:delete>
</delete>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on completion of processing the request must respond to
the client with a success/failure result with no data element in the
response. The response to the request shall not contain any object
specific data.
Example:
<response>
<reply>
... success/failure reply ...
</reply>
<transaction-id>
Brunner, et al Expires August 2001 [Page 68]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to delete registrant
objects that they administer.
Response codes - active domain-names associated with the registrant.
A.3.3 Modify
The object specific command mappings for implementation of the modify
command are described in this subsection.
A.3.3.1 Contact Object
The modify request for a contact allows a user to change the data in
contact object, remove any optional elements from the contact object.
The two operations supported are identified by three elements
"contact:change" and "contact:remove" within the "contact:modify"
element with optional elements of the object.
Modify Contact
--------------------------------
Child Element Required
Contact Identifier Y
Change N
Name N
Title N
Organization N
Address N
Voice N
Fax N
Email N
Access N
Optional elements N
Remove N
Title N
Organization N
Fax N
Optional elements N
Example - Registrar modifies contact information:
<request>
Brunner, et al Expires August 2001 [Page 69]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<modify>
<contact:modify xmlns:contact="urn.NeuLevel.contact"
xsi:schemaLocation="urn.NeuLevel.contact contact.xsd">
<contact:id>AD-0001</contact:id>
<contact:change>
<contact:name type="owner">
John R. Doe
</contact:name>
<contact:organization>
Coca Cola Company
</contact:organization>
<contact:address>
<line>
144 new lane, washington, DC 20005, us
</line>
</contact:address>
<contact:voice>+1.8005551212</contact:voice>
<contact:fax>+1.8005551212</contact:fax>
</contact:change>
</contact:modify>
</modify>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client with a success/ failure result with no data
element in "response". The response to the request will not contain
any object specific data.
Example:
<response>
<reply>
... success/failure reply ...
</reply>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
.fi
.sp
Authorized users - All clients are authorized to modify contacts that
they administer.
Response code - active domain-names associated with the contact.
Brunner, et al Expires August 2001 [Page 70]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
A.3.3.2 Nameserver Object
Modify request for a nameserver will allow a user to add/remove data
from the "ns" object. The operations supported are identified by two
elements "ns:add" and "ns:remove" within the "ns:modify" element.
Modify Nameserver
--------------------------------
Child Element Required
Nameserver name Y
Add N
IP address Y
Remove N
IP address Y
The response to the request will not contain any object specific
data.
Example:
<request>
<modify>
<ns:modify xmlns:ns="urn.NeuLevel.ns"
xsi:schemaLocation="urn.NeuLevel.ns ns.xsd">
<ns:name>ns1.example.tld</ns:name>
<ns:add>
<ns:ip>10.10.1.20</ns:ip>
<ns:ip>10.10.1.30</ns:ip>
</ns:add>
<ns:remove>
<ns:ip>10.10.1.1</ns:ip>
</ns:remove>
</ns:modify>
</modify>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on completion of processing the request must respond to
the client with a success/ failure result with no data element in
"response".
Example:
<response>
Brunner, et al Expires August 2001 [Page 71]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<reply>
... success/failure reply ...
</reply>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users - All registrars are authorized to modify
nameservers that they administer.
Response codes - active domain-names associated with the nameserver.
A.3.3.3 Domain-name Object
A modify domain-name request allows a user to add/remove the data in
domain object. The two operations supported are identified by two
elements "domain:add" and "domain:remove" within the "domain:modify"
element with optional elements of the object.
Modify Domain-name
--------------------------------
Child Element Required
Domain Name Y
Remove N
Contact N
Nameserver N
Child nameserver N
Status N
Add N
Contact N
Nameserver N
Child nameserver N
Status N
The response to the request will not contain any object specific
data.
Example:
<request>
<modify>
<domain:modify xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
Brunner, et al Expires August 2001 [Page 72]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<domain:name>example3.biz</domain:name>
<domain:add>
<domain:contact type="owner">
Jane-W-Smith0001
</domain:contact>
<domain:nameserver>ns3.coca-cola.net</domain:nameserver>
</domain:add>
</domain:modify>
</modify>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client with a success/ failure result with no data
element in [?] response
Example:
<response>
<reply>
... success/failure reply ...
</reply>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to modify domains that
they administer.
A.3.3.4 Intellectual Property Object
The modify request for intellectual property allows a user to
add/remove the data in intellectual property object. The two
operations supported are identified by two elements "iprop:add" and
"iprop:remove" within the "iprop:modify" element with optional
elements of the object.
Modify I-Property
--------------------------------
Child Element Required
IP identifier Y
Remove N
Monitor-string N
Status [live, dead] N
Contacts N
Optional Elements
Brunner, et al Expires August 2001 [Page 73]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Add N
Monitor-string N
Status [live, dead] N
Contacts N
Optional elements N
Example:
<request>
<modify>
<iprop:modify xmlns:iprop="urn.NeuLevel.iprop"
xsi:schemaLocation="urn.NeuLevel.iprop iprop.xsd">
<iprop:id>bill-s-watson00003</iprop:id>
<iprop:add>
<iprop:contact type="receiver">
Bill S. Watson
</iprop:contact>
</iprop:add>
</iprop:modify>
</modify>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on completion of processing the request must respond to
the client with a success/failure result with no data element in
response. The response to the request shall not contain any object
specific data.
Example:
<response>
<reply>
... success/failure reply ...
</reply>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
.fi
.sp
Authorized users: All clients are authorized to modify intellectual
property objects that they administer.
A.3.3.5 Registrant Object
The modify request for a registrant allows a user to change the data in
the registrant object and remove any optional elements from the
Brunner, et al Expires August 2001 [Page 74]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
registrant object. The two operations supported are identified by two
elements "registrant:change" and "registrant:add" within the
"registrant:modify" element with optional elements of the object.
Modify Registrant
--------------------------------
Child Element Required
Registrant Id Y
Change N
Name N
Address N
Contacts N
DUNS Number N
Industry Code N
Status N
Optional Elements
Add N
Contacts N
DUNS Number N
Industry Code N
Optional Elements N
The response to the request will not contain any object specific
data.
Example:
<request>
<modify>
<registrant:modify xmlns:registrant="urn.NeuLevel.registrant
xsi:schemaLocation="urn.NeuLevel.registrant registrant.xsd">
<registrant:id>registrant0001</registrant:id>
<registrant:change>
<registrant:name type="owner">John R. Doe</registrant:name>
<registrant:status>active</registrant:status>
</registrant:change>
</registrant:modify>
</modify>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client with a success/failure result with no data
element in response.
Example:
Brunner, et al Expires August 2001 [Page 75]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<response>
<reply>
... success/failure reply ...
</reply>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All registrars are authorized to modify registrant
objects that they administer.
A.3.4 Renew
The object specific command mappings for implementation of the renew
command are described in this subsection.
A.3.4.1 Domain Object
A "domain:renew" element in the "renew" request will allow a user to
renew a domain-name for a given valid period. The "domain:renew"
request shall contain the following child elements:
Renew Domain-name
--------------------------------
Child Element Required
Domain-name Y
Registration Period N
(default=1)
The response "domain:renew-response" to the request
Renew Domain Response
--------------------------------
Child Element
Domain-name
Expiration date
Example: A registrar renews a domain-name.
<request>
<renew>
<domain:renew xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
<domain:name>coca-cola.biz</domain:name>
<domain:period>2</domain:period>
</domaint:renew> </renew>
<transaction-id>
Brunner, et al Expires August 2001 [Page 76]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
... transaction id data ...
</transaction-id>
</request>
The Server on successful completion of processing the request must
respond to the client with "renew-response" element in "data" element
of "response". The response must include the fully qualified name of
the domain and the expiration date of the domain.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<domain:renew-response xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
<domain:name>coca-cola.biz</domain:name>
<domain:expiration-date>yyyy-mm-dd</domain:expiration-date>
</domain:renew-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to renew a domain that
they administer.
A.3.4.2 Intellectual Property
A "iprop:renew" element in the "renew" request allows a user to renew
a intellectual property object for a given valid period.
The "iprop:renew" request shall contain the following child elements:
Renew I-Property
--------------------------------
Child Element Required
IP Identifier Y
Registration Period N
(default 1 year)
The response "iprop:renew-response" to the request
Renew I-Property Response
--------------------------------
Brunner, et al Expires August 2001 [Page 77]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Child Element
Intellectual Property ID
Expiration date
Example:
A registrar registers a object.
<request>
<renew>
<iprop:renew xmlns:iprop="urn.NeuLevel.iprop"
xsi:schemaLocation="urn.NeuLevel.iprop iprop.xsd">
<iprop:id>coca-cola000001</iprop:id>
<iprop:period>2</iprop:period>
</iprop:renew>
</renew>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client with "renew-response" element in "data" element
of "response". The response must include the unique identifier of
the intellectual property object and the expiration date of the
object.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<iprop:renew-response xmlns:iprop="urn.NeuLevel.iprop"
xsi:schemaLocation="urn.NeuLevel.iprop iprop.xsd">
<iprop:id>coca-cola00001</iprop:id>
<iprop:expiration-date>yyyy-mm-dd</iprop:expiration-date>
</iprop:renew-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to renew an iprop item
that they administer.
A.3.5 Transfer
Brunner, et al Expires August 2001 [Page 78]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
The object specific command mappings for implementation of the
transfer command are described in this subsection.
A.3.5.1 Contact Object
The "contact:transfer" element in the "transfer" request will allow
the user to:
1. Initiate a transfer of given contact type of "transfer" element
set to "request")
2. Approve a transfer of given contact (type of "transfer" element
set to "approve"
3. Reject a transfer of given contact (type of "transfer" element set
to "reject")
4. Query a transfer status (type of "transfer" element set to
"query")
The table that follows describes the contact transfer status flow.
This space left intentionally blank
Brunner, et al Expires August 2001 [Page 79]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Along with the unique identifier of the contact object and the
authorization associated with the contact object.
Transfer Contact
--------------------------------
Child Element Required
Contact Unique Id Y
The response "contact:transfer-response" to the request
Transfer Contact Response
--------------------------------
Child Element
Contact id
Registrar requesting transfer
Original sponsoring registrar
Transfer status
Transfer requested date
Response requested by date
Date the original sponsoring registrar responds to transfer request
(approve or reject)
Transfer Contact Notification
--------------------------------
Child Element
Contact id
Registrar requesting transfer
Original sponsoring registrar
Transfer status
Transfer requested date
Response requested by date
Date the original sponsoring registrar responds to transfer request
(approve or reject)
Example: A registrar transfers a contact.
<request>
<transfer type="request">
<contact:transfer xmlns:contact="urn.NeuLevel.contact"
xsi:schemaLocation="urn.NeuLevel.contact contact.xsd">
<contact:id>JA-0002</contact:id>
</contact:transfer>
<authorization>
... authorization elements ...
</authorization>
</transfer>
<transaction-id>
... transaction id data ...
Brunner, et al Expires August 2001 [Page 80]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client with "transfer-response" element in "data"
element of "response". The response must include the server's unique
identifier for the contact, by which the server will identify the
contact.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<contact:transfer-response xmlns:contact="urn.NeuLevel.contact"
xsi:schemaLocation="urn.NeuLevel.contact contact.xsd">
<contact:id>JA-0002</contact:id>
<contact:requested-client>
registrar001
</contact:requested-client>
<contact:actor-client>registrar002</contact:actor-client>
<contact:transfer-status>pending</contact:transfer-status>
<contact:requested-date>yyyy-mm-dd</contact:requested-date>
<contact:action-date>yyyy-mm-dd</contact:action-date>
</contact:transfer-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
In addition the server notifies the other registrar client involved
in the transfer of the contact about the transfer (the same data in
the "contact:transfer-response".)
Example:
<notification>
<data>
<contact:transfer-response xmlns:contact="urn.NeuLevel.contact"
xsi:schemaLocation="urn.NeuLevel.contact contact.xsd">
<contact:id>JA-0002</contact:id>
<contact:requested-client>CLT100</contact:requested-client>
<contact:actor-client>CLT200</contact:actor-client>
<contact:transfer-status>pending</contact:transfer-status>
<contact:requested-date>yyyy-mm-dd</contact:requested-date>
Brunner, et al Expires August 2001 [Page 81]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<contact:action-date>yyyy-mm-dd</contact:action-date>
</contact:transfer-response>
</data>
<notification-id>
... notification id data ...
</notification-id>
</notification>
Authorized users: All clients are authorized to request to transfer a
contact.
A.3.5.2 Nameserver Object
The transfer nameserver request must be used to transfer a non-.tld
nameserver; for example, ns1.coca-cola.net that is associated with a
registrant's domain-name in the .tld registry. A "ns:transfer"
element in the "transfer" request will allow the registrar to:
1. Initiate a transfer of given nameserver. (type of "transfer"
element set to request)
2. Approve a transfer of given nameserver (type of transfer element
set to approve)
3. Reject a transfer of given nameserver (type of "transfer" element
set to "reject")
4. Query a transfer status (type of "transfer" element set to
"query")
Domain transfer status flow - The following table provides the domain
transfer status flow.
This space intentionally left blank
Brunner, et al Expires August 2001 [Page 82]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Along with the fully qualified name of the domain object and the
authorization associated with the nameserver object
Transfer Nameserver
--------------------------------
Child Element Required
Nameserver name Y
The response "ns:transfer-response" to the request contains the
following child elements.
Transfer Nameserver Response
--------------------------------
Child Element
Nameserver name
Registrar requesting transfer
Original sponsoring registrar
Transfer status
Transfer requested date
Response requested by date (for requests)
Date the original sponsoring registrar responds to transfer request
(approve or reject)
The notification contains the following child elements:
Transfer Nameserver Notification
--------------------------------
Child Element
Nameserver name
Registrar requesting transfer
Original sponsoring registrar
Transfer status
Transfer requested date
Response requested by date (for requests)
Date the original sponsoring registrar responds to transfer request
(approve or reject)
Example: A registrar initiates a nameserver transfer.
<request>
<transfer type="request">
<ns:transfer xmlns:ns="urn.NeuLevel.ns"
xsi:schemaLocation="urn.NeuLevel.ns ns.xsd">
<ns:name>ns1.coca-cola.net</ns:name>
</ns:transfer>
<authorization>
... authorization elements ...
</authorization>
</transfer>
Brunner, et al Expires August 2001 [Page 83]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client with "transfer-response" element in "data"
element of "response". The response must include the nameserver
Internet name, by which the server will identify the nameserver. In
addition server notifies the other losing registrar involved in the
transfer of the domain about the transfer (the same data in the
"ns:transfer-response".)
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<ns:transfer-response xmlns:ns="urn.NeuLevel.ns"
xsi:schemaLocation="urn.NeuLevel.ns ns.xsd">
<ns:name>ns1.coca-cola.net</ns:name>
<ns:requested-client>registrar001</ns:requested-client>
<ns:actor-client>registrar002</ns:actor-client>
<ns:transfer-status>pending</ns:transfer-status>
<ns:requested-date>yyyy-mm-dd</ns:requested-date>
<ns:action-date>yyyy-mm-dd</ns:action-date>
</ns:transfer-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Example: Notification to losing registrar
<notification>
<data>
<ns:transfer-response xmlns:ns="urn.NeuLevel.ns"
xsi:schemaLocation="urn.NeuLevel.ns ns.xsd">
<ns:name>ns1.coca-cola.com</ns:name>
<ns:requested-client>registrar001</ns:requested-client>
<ns:actor-client>registrar002</ns:actor-client>
<ns:transfer-status>pending</ns:transfer-status>
Brunner, et al Expires August 2001 [Page 84]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<ns:requested-date>yyyy-mm-dd</ns:requested-date>
<ns:action-date>yyyy-mm-dd</ns:action-date>
</ns:transfer-response>
</data>
<notification-id>
... notification id data ...
</notification-id>
</notification>
Authorized users - All clients are authorized to request to transfer
a nameserver.
A.3.5.3 Domain-name Object
A "domain:transfer" element in the "transfer" request will allow
the user to:
1. Initiate a transfer of given domain-name. (type of "transfer"
element set to "request")
2. Approve a transfer of given domain-name (type of "transfer"
element set to "approve")
3. Reject a transfer of given domain-name (type of "transfer" element
set to "reject")
4. Query a transfer status (type of "transfer" element set to
"query")
Domain transfer status flow: The following table provides the domain-
name transfer status flow.
This space left intentionally blank
Brunner, et al Expires August 2001 [Page 85]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
The request includes with the fully qualified name of the domain-name
object and the authorization associated with the domain-name object.
Transfer Domain-name
--------------------------------
Child Element Required
Domain-name Y
Authorization Y
The response "domain:transfer-response" to the request includes the
following child elements:
Transfer Domain-name Response
--------------------------------
Child Element
Domain name
Registrar requesting transfer
Original sponsoring registrar
Transfer status
Transfer requested date
Response requested by date
Date the original sponsoring registrar responds to transfer request
(approve or reject)
Transfer Domain-name Notification
--------------------------------
Child Element
Domain name
Registrar requesting transfer
Original sponsoring registrar
Transfer status
Transfer requested date
Response requested by date
Date the original sponsoring registrar responds to transfer request
(approve or reject)
Example: A registrar transfers a domain.
<request>
<transfer type="request">
<domain:transfer xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
<domain:name>coca-cola.biz</domain:name>
</domain:transfer>
<authorization>
... authorization elements ...
</authorization>
</transfer>
<transaction-id>
Brunner, et al Expires August 2001 [Page 86]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the registrar client with "transfer-response" element in
the "data" element of "response". The response must include the
server's unique identifier for the domain-name, by which the server
will identify the domain-name. In addition server notifies the other
registrar client involved in the transfer of the domain-name about
the transfer (the same data in the "domain:transfer-response".)
Example: Response to the requesting registrar.
<response>
<reply>
... success reply ...
</reply>
<data>
<domain:transfer-response xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
<domain:name>coca-cola'biz</domain:name>
<domain:requested-client>registrar001</domain:requested-client>
<domain:actor-client>CLT200</domain:actor-client>
<domain:transfer-status>pending</domain:transfer-status>
<domain:requested-date>yyyy-mm-dd</domain:requested-date>
<domain:action-date>yyyy-mm-dd</domain:action-date>
</domain:transfer-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Example: Notification to losing registrar.
<notification>
<data>
<domain:transfer-response xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
<domain:name>example.tld</domain:name>
<domain:requested-client>registrar001</domain:requested-client>
<domain:actor-client>registrar002</domain:actor-client>
<domain:transfer-status>pending</domain:transfer-status>
<domain:requested-date>yyyy-mm-dd </domain:requested-date>
Brunner, et al Expires August 2001 [Page 87]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<domain:action-date>yyyy-mm-dd</domain:action-date>
</domain:transfer-response>
</data>
<notification-id>
... notification id data ...
</notification-id>
</notification>
Authorized users: All clients are authorized to request to transfer a
domain.
A.3.5.4 Registrant Object
The "registrant:transfer" element in the "transfer" request will
allow the user to:
5. Initiate a transfer of a registrant (type of "transfer" element
set to "request")
6. Approve a transfer of a registrant (type of "transfer" element set
to "approve"
7. Reject a transfer of a registrant (type of "transfer" element set
to "reject")
8. Query a transfer status (type of "transfer" element set to
"query")
The table that follows describes the registrant transfer status flow.
This space left intentionally blank
Brunner, et al Expires August 2001 [Page 88]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
The request child elements includes the unique identifier of the
registrant object and the authorization associated with the
registrant object.
Transfer Registrant
--------------------------------
Child Element Required
Registrar Unique Id Y
Authorization Y
The response child elements in "registrant:transfer-response" to the
request include the following:
Transfer Registrant Response
--------------------------------
Child Element
Registrant id
Registrar Requesting transfer
Original Sponsoring Registrar
Transfer status
Transfer requested date
Response requested by date (for requests)
Date the original sponsoring registrar responds to transfer request
(approve or reject)
Transfer Registrant Notification
--------------------------------
Child Element
Registrant id
Registrar Requesting transfer
Original Sponsoring Registrar
Transfer status
Transfer requested date
Response requested by date (for requests)
Date the original sponsoring registrar responds to transfer request
(approve or reject)
Example: A registrar initiates transfer of a registrant.
<request>
<transfer type="request">
<registrant:transfer xmlns:registrant="urn.NeuLevel.registrant"
xsi:schemaLocation="urn.NeuLevel.registrant registrant.xsd">
<registrant:id>JA-0002</registrant:id>
</registrant:transfer>
<authorization>
... authorization elements ...
Brunner, et al Expires August 2001 [Page 89]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
</authorization>
</transfer>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client with "transfer-response" element in "data"
element of "response". The response must include the server's unique
identifier for the registrant, by which the server will identify the
registrant.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<registrant:transfer-response xmlns:registrant="urn.NeuLevel.registrant"
xsi:schemaLocation="urn.NeuLevel.registrant registrant.xsd">
<registrant:id>JA-0002</registrant:id>
<registrant:requested-client>registrar001</registrant:requested-client>
<registrant:actor-client>registrar002</registrant:actor-client>
<registrant:transfer-status>pending</registrant:transfer-status>
<registrant:requested-date>yyyy-mm-dd</registrant:requested-date>
<registrant:action-date>yyyy-mm-dd</registrant:action-date>
</registrant:transfer-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
In addition, the server notifies the losing original registrar
sponsor involved in the transfer of the registrant about the transfer
(the same data in the "registrant:transfer-response".)
Example:
<notification>
<data>
<registrant:transfer-response xmlns:registrant="urn.NeuLevel.registrant"
xsi:schemaLocation="urn.NeuLevel.registrant registrant.xsd">
<registrant:id>registrant00001</registrant:id>
<registrant:requested-client>registrar001</registrant:requested-client>
Brunner, et al Expires August 2001 [Page 90]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<registrant:actor-client>registrar002</registrant:actor-client>
<registrant:transfer-status>pending</registrant:transfer-status>
<registrant:requested-date>yyyy-mm-dd</registrant:requested-date>
<registrant:action-date>yyyy-mm-dd</registrant:action-date>
</registrant:transfer-response>
</data>
<notification-id>
... notification id data ...
</notification-id>
</notification>
Authorized users: All clients are authorized to request to transfer a
contact.
A.3.6 Query
The object specific command mappings for implementation of the query
command are described in this subsection.
A.3.6.1 Contact Object
The "contact:query" element in the "query" request will allow the
user to obtain the contact information for a given contact id based
on userid and password access control.
Query Contact
--------------------------------
Child Element Required
Contact ID Y
Authorization Y
The response "contact:query-response" to the request includes the
following child elements:
Query Contact Response
--------------------------------
Child Element
Name
Title
Organization
Address (line or normalized)
Voice
Fax
Email
Created (on, when)
Modified (on, when)
Authorization (only to sponsoring registrar)
Brunner, et al Expires August 2001 [Page 91]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example: A registrar queries a contact.
<request>
<query>
<contact:query xmlns:contact="urn.NeuLevel.contact"
xsi:schemaLocation="urn.NeuLevel.contact contact.xsd">
<contact:id>AB-12345678</contact:id>
</contact:query>
<authorization>
... authorization elements ...
</authorization>
</query>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server upon successful completion of the processing the request
must respond with "query-response" element in "data" element of
"response". The response must include the server's unique identifier
for the contact, by which the server will identify the contact.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<contact:query-response xmlns:contact="urn.NeuLevel.contact"
xsi:schemaLocation="urn.NeuLevel.contact contact.xsd">
<contact:id>AD-123456</contact:id>
<contact:name type="owner">L.L. Bean</contact:name>
<contact:organization>CEO</contact:organization>
<contact:address>
<contact:street>1120 Vermont Ave.</contact: street>
<contact:city>Washington</contact:city>
<contact:state>DC</contact:state>
<contact:postalcode>20005</contact:postalcode>
<contact:country>US</contact:country>
</contact:address>
<contact:voice>+1.8005551212</contact:voice>
<contact:fax>+1.8005551212</contact:fax>
<contact:email>aye.damaraju@NeuLevel.com</contact:email>
<contact:client>
<contact:transferred-date>yyyy-mm-dd</contact:transferred-date>
<contact:client-id>CLN100</contact:client-id>
</contact:client>
Brunner, et al Expires August 2001 [Page 92]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<contact:created>
<contact:created-date>yyyy-mm-dd</contact:created-date>
<contact:client-id>CLN200</contact:client-id>
</contact:created>
<contact:modified>
<contact:modified-date>yyyy-mm-ddy</contact:modified-date>
<contact:client-id>CLN200</contact:client-id>
</contact:modified>
<contact:authorization>
<contact:date>yyyy-mm-dd</contact:date>
<contact:client-id>CLN200</contact:client-id>
<contact:code> ... </contact:code>
</contact:authorization>
</contact:query-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to query a contact for
information.
A.3.6.2 Nameserver Object
The "ns:query" element in the "query" request will allow the user to
obtain the nameserver information for a given nameserver name.
Query Nameserver
--------------------------------
Child Element Required
Nameserver name Y
The response "ns:query-response" to the request
Query Nameserver Response
--------------------------------
Child Element
Name
Registrar ID
IP addresses
Created (on, when)
Modified (on, when)
Authorization (only to sponsoring registrar
Brunner, et al Expires August 2001 [Page 93]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example: A registrar queries a nameserver object.
<request>
<query>
<ns:query xmlns:ns="urn.NeuLevel.ns"
xsi:schemaLocation="urn.NeuLevel.ns ns.xsd">
<ns:name>ns1.coca-cola.biz</ns:name>
</ns:query>
</query>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the registrar client with "query-response" element in
"data" element of "response". The response must include the fully
qualified name of the nameserver.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<ns:query-response xmlns:ns="urn.NeuLevel.ns"
xsi:schemaLocation="urn.NeuLevel.ns ns.xsd">
<ns:name>ns1.example.tld</ns:name>
<ns:client>
<ns:transferred-date>yyyy-mm-dd</ns:transferred-date>
<ns:client-id>CLN100</ns:client-id>
</ns:client>
<ns:ip>10.10.1.20</ns:ip>
<ns:created>
<ns:created-date>yyyy-mm-dd</ns:created-date>
<ns:client-id>CLN200</ns:client-id>
</ns:created>
<ns:modified>
<ns:modified-date>yyyy-mm-dd</ns:modified-date>
<ns:client-id>CLN200</ns:client-id>
</ns:modified>
<ns:authorization>
<ns:date>yyyy-mm-dd</ns:date>
<ns:client-id> ... </ns:client-id>
<ns:code> ... </ns:code>
</ns:authorization>
</ns:query-response>
Brunner, et al Expires August 2001 [Page 94]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to query a nameserver
for information.
A.3.6.3 Domain-name Object
The "domain:query" element in the "query" request allows the user to
obtain the domain-name information for a given domain-name.
Query Domain-name
--------------------------------
Child Element Required
Domain-name Y
The response "domain:query-response" to the request includes the
following child elements:
Query Domain-name Response
--------------------------------
Child Element
Registrant ID
Domain-name
Created (on, when)
Modified (on, when)
Sponsoring Registrar
Contacts
Nameservers
Child Name servers
Expiration date
Domain-name status
Authorization (only to original sponsoring registrar)
Restricted Registration Access (only to sponsoring registrar)
Example: A registrar queries a domain-name.
<request>
<query>
<domain:query xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
<domain:name>coca-cola.biz</domain:name>
</domain:query>
</query>
<transaction-id>
Brunner, et al Expires August 2001 [Page 95]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the registrar client with the "query-response" element in
"data" element of "response". The response must include the server's
unique identifier for the domain-name, by which the server will
identify the domain-name.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<domain:query-response xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
<domain:name>coca-cola.biz</domain:name>
<domain:created>
<domain:created-date>yyyy-mm-dd</domain:created-date>
<domain:created-client-id>CLN10</domain:created-client-id>
</domain:created>
<domain:modified>
<domain:modified-date>yyyy-mm-dd</domain:modified-date>
<domain:modified-client-id>
registrar002
</domain:modified-client-id>
</domain:modified>
<domain:client>
<domain:transferred-date>yyyy-mm-dd </domain:transferred-date>
<domain:client-id>registrar001</domain:client-id>
</domain:client>
<domain:contact type="administrative">CNT100</domain:contact>
<domain:contact type="technical">CNT200</domain:contact>
<registrant-id>registrar000001</registrant-id>
<domain:nameserver>ns3.example3.tld</domain:nameserver>
<domain:childserver>ns1.example.tld</domain:childserver>
<domain:status>active</domain:status>
<domain:expiration-date>yyyy-mm-dd</domain:expiration-date>
<domain:authorization>
<domain:date>yyyy-mm-dd</domain:date>
<domain:client-id>CLN400</domain:client-id>
<domain:code> ... </domain:code>
</domain:authorization>
</domain:query-response>
</data>
Brunner, et al Expires August 2001 [Page 96]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to query a domain for
information.
A.3.6.4 Intellectual Property Object
The "iprop:query" element in the "query" request allows the user to
obtain the intellectual property information for a given intellectual
property id.
Query Intellectual Property
--------------------------------
Child Element Required
Property Unique Id Y
The response to the request shall be "iprop:query-response".
Query Intellectual Property Response
--------------------------------
Child Element
Monitor-String
Contacts
Trademark
Created (on, when)
Modified (on, when)
Sponsoring registrar id
Authorization (only to sponsoring registrar)
Optional Elements
Example: A registrar queries an iprop object.
<request>
<query>
<iprop:query xmlns:iprop="urn.NeuLevel.iprop"
xsi:schemaLocation="urn.NeuLevel.iprop iprop.xsd">
<iprop:id>nnnnnnnnn</iprop:id>
</iprop:query>
</query>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
Brunner, et al Expires August 2001 [Page 97]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
respond to the client with "query-response" element in "data" element
of "response". The response must include the server's unique
identifier for the iprop, by which the server will identify the
iprop.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<iprop:query-response xmlns:iprop="urn.NeuLevel.iprop"
xsi:schemaLocation="urn.NeuLevel.iprop iprop.xsd">
<iprop:id>123456789</iprop:id>
<iprop:monitor-string>coca-cola.biz</monitor-string>
<iprop:contact type="administrative">JBLegal0000005</iprop:contact>
<iprop:contact type="holder">LLOwner000006 </iprop:contact>
<iprop:contact type="receiver">LawOffice0002 </iprop:contact>
<iprop:trademark>
<iprop:name>coca-cola</ iprop:name>
< iprop:country>us</ iprop:country>
< iprop:reference>12345678</ iprop:reference>
< iprop:date>yyyy-mm-dd</iprop:date>
</iprop:trademark>
<iprop:client>
<iprop:client-id>CLN100</iprop:client-id>
</iprop:client>
<iprop:created>
<iprop:created-date>yyyy-mm-dd</iprop:created-date>
<iprop:client-id>CLN200</iprop:client-id>
<transferred-date>yyyy-mm-dd</transferred-date>
</iprop:created>
<iprop:modified>
<iprop:modified-date>yyyy-mm-dd</iprop:modified-date>
<iprop:client-id>CLN200</iprop:client-id>
</iprop:modified>
<iprop:authorization>
<iprop:date>yyyy-mm-dd</iprop:date>
<iprop:client-id>CLN500</iprop:client-id>
<iprop:code> ... </iprop:code>
</iprop:authorization>
</iprop:query-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Brunner, et al Expires August 2001 [Page 98]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Authorized users: Only sponsoring clients are authorized to query a
iprop object they sponsor.
A.3.6.5 Registrant Object
The "registrant:query" element in the "query" request allows the user
to obtain registrant information associated with a given domain-name.
Query Registrant
--------------------------------
Child Element Required
Registrant ID Y
The response "registrant:query-response" to the request includes the
following child elements:
Query Registrant Response
--------------------------------
Name
Address
Contacts
DUNS Number
SIC Code
Status
Created (on, when)
Modified (on, when)
Authorization (only to original sponsoring registrar)
Optional Elements
Example: A registrar queries a registrant object.
<request>
<query>
<registrant:query xmlns:domain="urn.NeuLevel.registrant"
xsi:schemaLocation="urn.NeuLevel.registrant registrant.xsd">
<registrant:id>coca-cola-123456</registrant:id>
</registrant:query>
</query>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the registrar client with the "query-response" element in
"data" element of "response". The response must include the server's
unique identifier for the registrant, by which the server will
identify the registrant.
Brunner, et al Expires August 2001 [Page 99]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<registrant:query-response xmlns:registrant="urn.NeuLevel.registrant"
xsi:schemaLocation="urn.NeuLevel.registrant registrant.xsd">
<registrant:name>coca-cola</registrant:name>
<registrant:address>line</registrant:address>
<registrant:contact type="owner">L.L. Bean</registrant:contact>
<registrant:status>active</registrant:status>
<registrant:created>
<registrant:created-date>yyyy-mm-dd</registrant:created-date>
<registrant:created-client-id>
CLN10
</registrant:created-client-id>
</registrant:created>
<registrant:modified>
<registrant:modified-date>yyyy-mm-dd </registrant:modified-date>
<registrant:modified-client-id>
CLN20
</registrant:modified-client-id>
</registrant:modified>
<registrant:authorization>
<registrant:date>yyyy-mm-dd</registrant:date>
<registrant:client-id>INWW-asdfd-12345</registrant:client-id>
<registrant:code>nnnnnnnnnnnnnn</registrant:code>
</registrant:authorization>
</registrant:query-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to query a domain for
information.
A.3.6.6 Registrar Object
The "registrar:query" element in the "query" request allows the
registrar client to obtain registrar object information associated
with a domain-name.
Brunner, et al Expires August 2001 [Page 100]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Query Registrar Object
--------------------------------
Child Element Required
Registrar ID Y
The response "registrar:query-response" to the request includes the
following child elements:
Query Registrar Response
--------------------------------
Name
Address
Web URL
ICANN Certification ID
DUNS Number
SIC Code
Contacts
Status
Created (on, when)
Modified (on, when) Authorization (only to original
sponsoring registrar)
Optional Elements
Example: A registrar queries a registrar object.
<request>
<query>
<registrar:query xmlns:domain="urn.NeuLevel.registrar"
xsi:schemaLocation="urn.NeuLevel.registrar registrar.xsd">
<registrar:id>INWW-asdfd-12345</registrar:id>
</registrar:query>
</query>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the registrar client with the "query-response" element in
"data" element of "response". The response must include the server's
unique identifier for the registrar, by which the server will
identify the registrar.
Example:
<response>
<reply>
... success reply ...
Brunner, et al Expires August 2001 [Page 101]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
</reply>
<data>
<registrar:query-response xmlns:registrar="urn.NeuLevel.registrar"
xsi:schemaLocation="urn.NeuLevel.registrar registrar.xsd">
<registrar:name>INWW</registrar:name>
<registrar:address>line</registrar:address>
<registrar:contact type="technical">David Taylor</registrar:contact>
<registrar:status>active</registrar:status>
<registrar:created>
<registrar:created-date>yyyy-mm-dd </registrar:created-date>
<registrar:created-client-id>
INWW-asdfd-12345
</registrar:created-client-id>
</registrar:created>
<registrar:modified>
<registrar:modified-date>yyyy-mm-dd</registrar:modified-date>
<registrar:modified-client-id>
INWW-asdfd-12345
</registrar:modified-client-id>
</registrar:modified>
<registrar:authorization>
<registrar:date>yyyy-mm-dd</registrar:date>
<registrar:client-id>INWW-asdfd-12345 </registrar:client-id>
<registrar:code>nnnnnnnnnnnnn</registrar:code>
</registrar:authorization>
</registrar:query-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All registrar clients are authorized to query a
registrar object for information.
A.3.7 Check
The object specific command mappings for implementation of the check
command are described in this subsection.
A.3.7.1 Contact Object
The "contact:check" element in the "check" request will allow the
user to check the existence of given contacts (up to 16 contact
entities). The request must include the following child elements:
Check Contact
--------------------------------
Brunner, et al Expires August 2001 [Page 102]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Child Element Required
Contact Unique Id Y
(multiple occurrences)
The response "contact:check-response" to the request consist of the
following child elements:
Check Contact Response
--------------------------------
Child Element
Contact Unique Identifier (multiple occurrences)
Result (attribute of id - known or unknown as values)
Example:
<request>
<check>
<contact:check xmlns:contact="urn.NeuLevel.contact"
xsi:schemaLocation="urn.NeuLevel.contact contact.xsd">
<contact:id>CNT100</contact:id>
<contact:id>CNT300</contact:id>
</contact:check>
</check>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successfully processing the request must respond to the
client with "check-response" element in "data" element of "response".
The response must include the server's unique identifier for the
contact, by which the server will identify the contact along with the
attribute "result" to identify the existence of the contact.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<contact:check-response>
<contact:check_id result="known">CNT100</contact:id>
<contact check_id result="unknown">CNT300</contact:id>
</contact:check-response>
</data>
<transaction-id>
Brunner, et al Expires August 2001 [Page 103]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to check a contact for
its existence.
A.3.7.2 Nameserver Object
The "ns:check" element in the "check" request will allow the user to
check the existence of given nameservers (up to 13 nameservers). The
request must contain the following child elements:
Check Nameservers
--------------------------------
Child Element Required
Unique FQDN Y
(multiple occurrences)
The response "ns:check-response" to the request
Check Nameservers Response
--------------------------------
Child Element
Unique fully qualified names (multiple occurrences)
Result (attribute of name - known or unknown as values)
Examples:
<request>
<check>
<ns:check xmlns:ns="urn.NeuLevel.ns"
xsi:schemaLocation="urn.NeuLevel.ns ns.xsd">
<ns:check_name>ns1.example.tld</ns:check_name>
<ns:check_name>ns2.example.tld</ns:check_name>
</ns:check>
</check>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the with a "check-response" element in "data" element of
"response". The response must include the server's unique identifier
Brunner, et al Expires August 2001 [Page 104]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
for the ns, by which the server will identify the ns along with the
attribute "result" to identify the existence of the ns.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<ns:check-response>
<ns:name result="known">ns1.example.tld</ns:name>
<ns:name result="unknown">ns2.example.tld</ns:name>
</ns:check-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to check a nameserver
for its existence.
A.3.7.3 Domain-name Object
The "domain:check" element in the "check" request will allow the
user to check for the existence of given domain-names (up to 16
domain-name entities).
Check Domain
--------------------------------
Child Element Required
Unique domain-names Y
(multiple occurrences)
The response "domain:check-response" to the request.
Check Domain Response
--------------------------------
Child Element
Unique domain-names (multiple occurrences)
Result (attribute of id - known, monitored, unknown as values)
Example:
<request>
<check>
<domain:check xmlns:domain="urn.NeuLevel.domain"
xsi:schemaLocation="urn.NeuLevel.domain domain.xsd">
Brunner, et al Expires August 2001 [Page 105]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<domain:name>example1.biz</domain:name>
<domain:name>example2.biz</domain:name>
</domain:check>
</check>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client with "check-response" element in "data" element
of "response". The response must include the server's unique
identifier for the domain, by which the server will identify the
domain along with the attribute "result" to identify the existence of
the domain.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<domain:check-response>
<domain:name result="known">HP.biz</domain:name>
<domain:name result="unknown">example2.biz</domain:name>
</domain:check-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to check a domain for
existence.
A.3.7.4 Intellectual Property Object
The "iprop:check" element in the "check" request will allow the
registrar user to check the existence of given intellectual property
objects (up to 16 intellectual property entities).
Check I-Property
--------------------------------
Child Element Required
Property Unique Id Y
(multiple occurrences)
Brunner, et al Expires August 2001 [Page 106]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
The response to the request shall be "iprop:check-response".
Check I-Property Response
--------------------------------
Child Element
Property Unique Identifier (multiple occurrences)
Result (attribute of id - known or unknown as values)
Example:
<request>
<check>
<iprop:check xmlns:iprop="urn.NeuLevel.iprop"
xsi:schemaLocation="urn.NeuLevel.iprop iprop.xsd">
<iprop:id>nnnnnnnnn</iprop:id>
<iprop:id>nnnnnnnnn</iprop:id>
</iprop:check>
</check>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client request with "check-response" element in "data"
element of "response". The response must include the server's unique
identifier for the iprop, by which the server will identify the iprop
along with the attribute "result" to identify the existence of the
iprop.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<iprop:check-response>
<iprop:id result="known">nnnnnnnnn</iprop:id>
<iprop:id result="unknown">nnnnnnnnn</iprop:id>
</iprop:check-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to check a iprop for its
existence.
Brunner, et al Expires August 2001 [Page 107]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
A.3.7.5 Registrant Object
The "registrant:check" element in the "check" request will allow the
registrar user to check the existence of given registrant objects (up
to 16 registrant entities).
Check Registrant
--------------------------------
Child Element Required
Registrant Unique Id Y
(multiple occurrences)
The response to the request shall be "registrant:check-response". The
response must consist of the following child elements:
Check Registrant Response
--------------------------------
Child Element
Registrant Identifier (multiple occurrences)
Result (attribute of id - "known" or "unknown" as values)
Example:
<request>
<check>
<registrant:check xmlns:registrant="urn.NeuLevel.registrant"
xsi:schemaLocation="urn.NeuLevel.registrant registrant.xsd">
<registrant:id>coca-cola-12345</registrant:id>
<registrant:id>MBI-12345</registrant:id>
</registrant:check>
</check>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client request with "check-response" element in "data"
element of "response". The response must include the server's unique
identifier for the registrant, by which the server will identify the
registrant along with the attribute "result" to identify the
existence of the registrant.
Example:
<response>
<reply>
... success reply ...
</reply>
Brunner, et al Expires August 2001 [Page 108]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
<data>
<registrant:check-response>
<registrant:id result="known">coca-cola12345 </registrant:id>
<registrant:id result="unknown">MBI-12345 </registrant:id>
</registrant:check-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to check a registrant
object for its existence.
A.3.7.6 Registrar Object
The "registrar:check" element in the "check" request will allow the
registrar user to check the existence of given registrar objects (up
to 16 registrar entities).
Check Registrar
--------------------------------
Child Element Required
Registrar Unique Id Y
(multiple occurrences)
The response to the request shall be "registrar:check-response". The
response must consist of the following child elements:
Check Registrar Response
--------------------------------
Child Element
Registrar Identifier (multiple occurrences)
Result (attribute of id - "known" or "unknown" as values)
Example:
<request>
<check>
<registrar:check xmlns:registrar="urn.NeuLevel.registrar"
xsi:schemaLocation="urn.NeuLevel.registrar registrar.xsd">
<registrar:id>INWW12345</registrar:id>
.
.
.
<registrar:id>Register.com1234</registrar:id>
</registrar:check>
</check>
<transaction-id>
Brunner, et al Expires August 2001 [Page 109]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
... transaction id data ...
</transaction-id>
</request>
The server on successful completion of processing the request must
respond to the client request with "check-response" element in "data"
element of "response". The response must include the server's unique
identifier for the registrar, by which the server will identify the
registrar entity along with the attribute "result" to identify the
existence of the registrar.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<registrar:check-response>
<registrar:id result="known">INWW-12345 </registrar:id>
.
.
.
<registrant:id result="known">Register.com12345 </registrant:id>
</registrant:check-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All clients are authorized to check a registrar
object for its existence.
A.3.8 List
The object specific command mappings for implementation of the list
command are described in this subsection. The list command is
initially restricted to the registrar object
A.3.8.1 Registrar Object
The registrar client must use the "list" request which includes
"registrar:list" element to obtain a list of registrar identifiers
for all registrars. These registrar identifiers are used in contact
transfer and domain transfer requests. The "registrar:list" element
returns a list of certified registrars maintained in the registry.
Brunner, et al Expires August 2001 [Page 110]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
List Registrar Response
--------------------------------
Child Element
Registrar Unique Identifier (multiple occurrences)
Example:
<request>
<list>
<registrar:list xmlns:registrar="urn.NeuLevel.registrar"
xsi:schemaLocation="urn.NeuLevel.registrar registrar.xsd">
</registrar:list>
</list>
<transaction-id>
... transaction id data ...
</transaction-id>
</request>
The server on successful processing the request must respond to the
client with object specific registrar identifiers for all registrars
in the registry.
Example:
<response>
<reply>
... success reply ...
</reply>
<data>
<registrar:list-response xmlns:registrar="urn.NeuLevel.registrar"
xsi:schemaLocation="urn.NeuLevel.registrar registrar.xsd">
<id>registrar-001</id>
<id>registrar-002</id>
.
.
.
<id>registrar-100</id>
</registrar:list-response>
</data>
<transaction-id>
... transaction id data ...
</transaction-id>
</response>
Authorized users: All registrar clients are authorized to obtain a
list of registrar id's maintained on the registry.
Brunner, et al Expires August 2001 [Page 111]
Internet-Draft Extensible Registry Protocol (XRP) February 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Brunner, et al Expires August 2001 [Page 112]
