[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 RFC 2832

Internet Engineering Task Force                         Scott Hollenbeck
Internet-Draft                                          Manoj Srivastava
Category-to-be: Informational           Network Solutions, Inc. Registry
Expires: June 2000                                         December 1999


            Registry Registrar Protocol (RRP) Version 1.1.0
                     <draft-hollenbeck-rrp-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.

  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 document describes a protocol for the registration and management
  of second level domain names and associated name servers in both Top
  Level Domains (TLDs) and country code Top Level Domains (ccTLDs). This
  protocol was developed by the Network Solutions Registry for use
  within the Shared Registration System and is being published "as-is"
  with the goal of eventual publication as an Informational RFC.

  Internet domain name registration typically involves three entities: a
  registrant who wishes to register a domain name, a registrar who
  provides services to the registrant, and a registry that provides
  services to the registrar while serving as the authoritative
  repository of all functional information required to resolve names
  registered in the registry's TLDs.  This document describes a protocol
  for registry-registrar communication only.  The protocol does not
  provide any registrant services.

  This document is being discussed on the "rrp" mailing list.  To join



Hollenbeck, Srivastava     Expires June 2000                    [Page 1]


Internet-Draft        Registry Registrar Protocol          December 1999


  the list, send a message to <majordomo@NSIRegistry.com> with the words
  "subscribe rrp" in the body of the message. There is also a web site
  for the mailing list archives at
  <http://www.NSIRegistry.com/maillist/rrp>.

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 [MUSTSHOULD]. Further,
  the term "implicit attribute" refers to an entity attribute whose
  value is derived either from another attribute or is dependent on an
  established RRP session.

  In examples, "C:" represents lines sent by the registrar client and
  "S" represents lines sent by the registry server.

  The term "System" is used in this document to collectively refer to
  this protocol and the software and hardware that implements the
  protocol.

Table of Contents

    1. Introduction .................................................    3
    2. Security Services ............................................    4
    2.1 Connection Security .........................................    4
    2.2 System Data Security ........................................    4
    3. Connection Model .............................................    5
    4. Protocol Description .........................................    5
    4.1 Request Format ..............................................    6
    4.2 Response Format .............................................    7
    4.3 Protocol Commands ...........................................    7
    4.3.1 ADD .......................................................    7
    4.3.2 CHECK .....................................................    9
    4.3.3 DEL .......................................................   11
    4.3.4 DESCRIBE ..................................................   12
    4.3.5 MOD .......................................................   13
    4.3.6 QUIT ......................................................   14
    4.3.7 RENEW .....................................................   15
    4.3.8 SESSION ...................................................   16
    4.3.9 STATUS ....................................................   16
    4.3.10 TRANSFER .................................................   19
    5. Response Codes ...............................................   20
    5.1 Response Code Summary .......................................   20
    5.2 Command-Response Correspondence .............................   25
    6. Domain Status Codes ..........................................   26
    6.1 Domain Status Code Description ..............................   27
    7. Formal Syntax ................................................   27



Hollenbeck, Srivastava     Expires June 2000                    [Page 2]


Internet-Draft        Registry Registrar Protocol          December 1999


    8. Internationalization .........................................   32
    9. Known Issues .................................................   32
    10. Security Considerations .....................................   34
    11. IANA Considerations .........................................   34
    12. References ..................................................   34
    13. Acknowledgments .............................................   34
    14. Authors' Address ............................................   34
    15. Full Copyright Statement ....................................   35

1. Introduction

  This document describes the specifications for the Registry Registrar
  Protocol (RRP) version 1.1.0, a TCP-based, 7-bit US-ASCII text
  protocol that permits multiple registrars to provide second level
  Internet domain name registration services in the top level domains
  (TLDs) administered by a TLD registry.

  RRP was developed by the Network Solutions, Inc. Registry under the
  auspices of the Shared Registration System program. The protocol was
  initially deployed in April 1999 as part of a test bed implementation
  of the Shared Registration System with five registrars. Additional
  registrars began using the protocol in July 1999. The operational
  experiences of both the registry and the registrars identified several
  "lessons learned" which have been documented here as "Known Issues".

  This document provides both a description of a protocol and notice of
  learned operational issues that may be useful as first steps in
  developing a standards track domain registration services protocol.
  This document and the protocol it describes may be modified in the
  future based on continued operational experience and community
  reaction.

  The registry stores information about registered domain names and
  associated name servers. A domain name's data includes its name, name
  servers, registrar, registration expiration date, and status. A name
  server's data includes its server name, IP addresses, and registrar. A
  registrar MAY perform the following registration service procedures
  using RRP:

  - Determine if a domain name has been registered.
  - Register a domain name.
  - Renew the registration of a domain name.
  - Cancel the registration of a domain name.
  - Update the name servers of a domain name.
  - Transfer a domain name from another registrar.
  - Examine the status of domain names that the registrar has registered.
  - Modify the status of domain names that the registrar has registered.
  - Determine if a name server has been registered.



Hollenbeck, Srivastava     Expires June 2000                    [Page 3]


Internet-Draft        Registry Registrar Protocol          December 1999


  - Register a name server.
  - Update the IP addresses of a name server.
  - Delete a name server.
  - Examine the status of name servers that the registrar has registered.

  All RRP commands include features to provide idempotency.  That is,
  the effect of each command is the same if the command is executed once
  or if the command is executed multiple times. This property is
  extremely useful in situations when a command is retried due to an
  error condition that results in a missed command response and a
  command retry is attempted. Command retries will be caught by the
  System and rejected with an appropriate error response code. Command
  parameters that do not provide idempotency will be explained fully as
  part of the appropriate command description.

2. Security Services

  RRP provides only basic password-based registrar authentication
  services.  Additional security services, including privacy and
  registrar authentication using public key cryptography, are provided
  through other means.

2.1 Connection Security

  Each RRP session MUST be encrypted using the Secure Socket Layer (SSL)
  v3.0 protocol as specified in [SSL]. SSL provides privacy services
  that reduce the risk of inadvertent disclosure of registrar-sensitive
  information, such as the registrar's user identifier and password.

  SSL supports mutual authentication of the client and server. The
  client and server SHOULD both be authenticated using SSL when
  establishing an RRP session.  Further, a registrar MUST be
  authenticated when establishing an RRP connection via the RRP SESSION
  command by providing a registrar user identifier and password known
  only to the registrar and the System.

  The SSL protocol is not an IETF Standards Track protocol. The
  Transport Layer Security protocol, specified in [TLS], is a Standards
  Track protocol that provides SSL v3.0 compatibility features.

2.2 System Data Security

  The System stores information about the registered domain names and
  their name servers.  Only the current registrar of a registered domain
  name is authorized to query it, update its name servers, and cancel or
  renew it. Any registrar can initiate a transfer of a domain name and
  its associated name servers from another registrar.




Hollenbeck, Srivastava     Expires June 2000                    [Page 4]


Internet-Draft        Registry Registrar Protocol          December 1999


  Only a name server's registrar can query, update, and delete it.  In
  general, name servers must be registered through the current registrar
  of the name server's parent domain name, though an implementation MAY
  allow use of name servers registered in other TLDs without specifying
  IP addresses or requiring parent domain registration. Use of ccTLD
  name servers for a gTLD domain name is one such example.

  Name servers are implicitly transferred by the System when their
  parent domain name is transferred. In addition, a name server cannot
  be deleted if it is hosting domain names.

3. Connection Model

  IANA has assigned TCP port 648 for RRP use. All RRP implementations
  MUST provide RRP services over SSL on TCP port 648.

4. Protocol Description

  A typical RRP session will go through a number of states during its
  lifetime.  Figure 1 illustrates the possible states of an RRP server.
                                      |
                                      |
                                      v
                             +-----------------+   Timeout
                             |   Waiting for   |-------------------+
   Authentication Succeeded  |      Client     |                   |
                   +---------|  Authentication | Authentication    |
                   |         |      (PRE)      |-----+  Failed     |
                   |         +-----------------+     |             |
                   |                                 |             |
                   V                                 V             |
             +-----------+     Succeeded    +--------------------+ |
             |Waiting for|<-----------------|    Waiting for     | |
             |  Command  |----------+       |Authentication Retry| |
             |   (WFC)   |  Timeout |       |       (WFR)        | |
             +-----------+          |       +--------------------+ |
                 |   ^              |           |         |        |
                 |   |              |   Timeout |         | Failed |
         Request V   |Response      |           |         |        |
             +-----------+          |           V         V        V
             | Executing |          |          +--------------------+
             |  Command  |          +--------->|    Disconnected    |
             |   (EXE)   |-------------------->|       (DIS)        |
             +-----------+          QUIT       +--------------------+

                Figure 1: RRP Server Finite State Machine





Hollenbeck, Srivastava     Expires June 2000                    [Page 5]


Internet-Draft        Registry Registrar Protocol          December 1999


  Initially, the server waits for a client connection and authentication
  (PRE).  All client connections MUST be authenticated. If the
  authentication fails, the server gives the client another chance to
  identify itself (WFR). If the authentication fails again, the server
  disconnects (DIS).  Otherwise, the server waits for a request from the
  client (WFC).  Upon receiving a request, the server executes it and
  responds to the client with the result (EXE). The server then waits
  again for another request from the client (WFC). If the client sends a
  QUIT command, the server ends the session and disconnects (DIS). To
  keep its state in sync with that of the server, the client SHOULD wait
  for a response from the server before sending another request on the
  same connection.  The following table summarizes these states:

        PRE     Waiting for client connection and authentication
        WFR     Waiting for authentication retry
        WFC     Waiting for a command from an authenticated client
        EXE     Executing a command
        DIS     Disconnected

  The WFR and WFC states MAY time out. An implementation SHOULD define
  inactivity timeout periods for these states based on System-specific
  factors, including (but not limited to) resource availability and
  security risk. In the absence of other factors, a default timeout
  period of 10 minutes SHOULD be used. The server MAY disconnect if the
  server is in one of these states and no message is received from the
  client during the timeout period.

4.1 Request Format

  An RRP request nominally consists of a command name, an entity block,
  command options, and an end-of-command delimiter. Command options and
  entity blocks collectively define command parameters and their
  specification is order independent; examples provided in this document
  specify entity blocks before command options.

    CommandName [EntityBlock] [CommandOptions] EndOfCommand

  A command name specifies the type of an RRP request.  A command is a
  word or abbreviation terminated by a carriage-return linefeed (crlf)
  sequence.

    CommandName<crlf>

  An entity block specifies the data in an RRP request. It consists of
  attribute name-value pairs specifying the entity and all of the
  attributes of the entity.  Each attribute name-value pair starts with
  the attribute name, followed by a colon, the attribute value, and is
  finally terminated by a carriage-return linefeed sequence.  Entity



Hollenbeck, Srivastava     Expires June 2000                    [Page 6]


Internet-Draft        Registry Registrar Protocol          December 1999


  blocks are optional for some requests.

    entityName:entityValue<crlf>
    attributeName:attributeValue<crlf>

  Command options specify control parameters for an RRP request. A
  command option starts with a dash, followed by the option name, a
  colon, the option value, and is finally terminated by a carriage-
  return linefeed sequence.

    -commandOptionName:commandOptionValue<crlf>

  An EndOfCommand delimiter specifies the end of an RRP request.  It
  consists of a dot (".") in column one followed by a carriage-return
  linefeed sequence.

    .<crlf>

4.2 Response Format

  An RRP response starts with a three-digit response code, followed by a
  space, an ASCII text description of the response, a carriage-return
  linefeed sequence, and zero or more attribute name-value pair lines.
  An RRP response is terminated by a dot in column one followed by a
  carriage-return linefeed sequence.

    ResponseCode<space>responseDescription<crlf>
    [attributeName:attributeValue<crlf>]
    .<crlf>

4.3 Protocol Commands

  Implementations of RRP commands MUST provide "all or nothing" success
  and failure operation. Failed command execution MUST leave the System
  in the same state it was in before the command was attempted and
  failed.

  All RRP commands include features to provide idempotency. Command
  features that are not idempotent are explained fully as needed as part
  of the appropriate command description.

4.3.1 ADD

  This command allows a registrar to register a domain name or a name
  server in the System.

4.3.1.1 Registering a Domain Name




Hollenbeck, Srivastava     Expires June 2000                    [Page 7]


Internet-Draft        Registry Registrar Protocol          December 1999


  The request to register a domain name MUST contain the following data:

  - The "EntityName" parameter set to value "Domain".
  - Fully qualified second level domain name in the "DomainName" parameter.

  The request to register a domain name MAY contain 1 or more, and a
  maximum of 13, fully qualified name servers hosting the domain name in
  multiple instances of the "NameServer" parameter. The name servers
  MUST have already been registered in the registry. Implementations MAY
  allow specification of name servers associated with domains registered
  in other TLDs. For example, an implementation MAY allow use of ccTLD
  name servers for gTLD domain name registration.

  The request to register a domain name MAY contain the initial
  registration period in years for the domain being registered in a
  single instance of the "Period" parameter. The System MUST provide a
  default initial registration period in years if the "Period" parameter
  is not provided. The acceptable year values for the "Period" parameter
  are implementation specific.

  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-specified default value MUST be used for
  the initial registration period. If the domain name is successfully
  registered, the System MUST return the registration expiration date in
  the "RegistrationExpirationDate" attribute in the response.

  Authorized User: All registrars MAY use the ADD command to register
  domain names.

  Examples

  A registrar registers a domain name without specifying name servers:

  C:add<crlf>
  C:EntityName:Domain<crlf>
  C:DomainName:example.com<crlf>
  C:-Period:10<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:RegistrationExpirationDate:2009-09-22 10:27:00.000<crlf>
  S:status:ACTIVE<crlf>
  S:.<crlf>

  A registrar registers a domain name using previously-registered name servers:

  C:add<crlf>
  C:EntityName:Domain<crlf>



Hollenbeck, Srivastava     Expires June 2000                    [Page 8]


Internet-Draft        Registry Registrar Protocol          December 1999


  C:DomainName:example2.com<crlf>
  C:-Period:10<crlf>
  C:NameServer:ns1.example.com<crlf>
  C:NameServer:ns2.example.com<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:RegistrationExpirationDate:2000-09-22 10:27:00.000<crlf>
  S:status:ACTIVE<crlf>
  S:.<crlf>

4.3.1.2 Registering a Name Server

  The request to register a name server MUST contain the following data:

  - The "EntityName" parameter set to value "NameServer".
  - Fully qualified server name of the name server in the "NameServer"
  parameter.

  If the name server being registered is the child of a registered
  domain name, the name server registration request MUST include one or
  more, and a maximum of 13, name server IP addresses in multiple
  instances of the "IPAddress" parameter. Name servers 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 name servers in multiple zone files.

  The registrar MUST register the name server in the System before using
  it to host domain names. Further, the name server MUST be registered
  through the same registrar that is the current registrar of its parent
  domain name. The System MAY allow any registrar to use the name server
  to host domain names.

  Authorized User: All registrars MAY use the ADD command to register
  name servers.

  Examples

  A registrar registers a new name server in an existing domain name:

  C:add<crlf>
  C:EntityName:NameServer<crlf>
  C:NameServer:ns1.example.com<crlf>
  C:IPAddress:198.41.1.11<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:.<crlf>

4.3.2 CHECK



Hollenbeck, Srivastava     Expires June 2000                    [Page 9]


Internet-Draft        Registry Registrar Protocol          December 1999


  This command allows a registrar to determine if a domain name or name
  server has been registered in the System.

4.3.2.1 Domain Name Check

  The request to determine if a domain name is registered MUST contain
  the following data:

  - The "EntityName" parameter set to value "Domain".
  - Fully qualified second level domain name in the "DomainName" parameter.

  The System MUST provide a positive or negative response to document
  domain name availability at the moment the command is executed.

  Authorized User: All registrars MAY use the CHECK command to determine
  if a domain name has been registered or not.

  Examples

  A registrar checks the availability of a domain name in the System:

  C:check<crlf>
  C:EntityName:Domain<crlf>
  C:DomainName:example.com<crlf>
  C:.<crlf>
  S:211 Domain not available<crlf>
  S:.<crlf>

4.3.2.2 Name Server Check

  The request to determine if a name server is registered MUST contain
  the following data:

  - The "EntityName" parameter set to value "NameServer".
  - Fully qualified server name in the "NameServer" parameter.

  The System MUST provide a positive or negative response to document
  name server availability at the moment the command is executed. If the
  name server has been registered, the System MUST return the IP
  address(es) of the name server.

  Authorized User: All registrars MAY use the CHECK command to determine
  if a name server has been registered or not.

  Examples

  A registrar checks the availability of a server name in the System:




Hollenbeck, Srivastava     Expires June 2000                   [Page 10]


Internet-Draft        Registry Registrar Protocol          December 1999


  C:check<crlf>
  C:EntityName:Nameserver<crlf>
  C:Nameserver:ns1.example.com<crlf>
  C:.<crlf>
  S:213 Nameserver name not available<crlf>
  S:ipAddress:192.10.10.10<crlf>
  S:.<crlf>

4.3.3 DEL

  This command allows a registrar to delete (cancel the registration) of
  a domain name or delete a name server.

4.3.3.1 Deleting a Domain Name

  The request to cancel the registration of a domain name MUST contain
  the following data:

  - The "EntityName" parameter set to value "Domain".
  - Fully qualified second level domain name in the "DomainName" parameter.

  A request to delete a domain name SHOULD cause the deletion of all
  name servers that are children of the domain name being deleted. The
  name servers SHOULD be deleted if they are not actively hosting other
  domains. A domain MUST not be deleted if it has child name servers
  hosting other domains.

  Authorized User: The current registrar of a domain name MAY use the
  DEL command to delete a domain name from the System.

  Examples

  A registrar deletes a domain name, implicitly deleting all name servers
  registered in the domain:

  C:del<crlf>
  C:EntityName:Domain<crlf>
  C:DomainName:example.com<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:.<crlf>

4.3.3.2 Deleting a Name Server

  The request to delete a name server MUST contain the following data:

  - The "EntityName" parameter set to value "NameServer".
  - Fully qualified name of the name server in the "NameServer" parameter.



Hollenbeck, Srivastava     Expires June 2000                   [Page 11]


Internet-Draft        Registry Registrar Protocol          December 1999


  A name server MUST not be deleted if it is hosting domains. Deleting
  such domains or name servers is prohibited because their deletion WILL
  result in orphaning the hosted domains.

  Authorized User: The current registrar of a name server MAY use the
  DEL command to delete a name server from the System.

  Examples

  A registrar deletes a name server that is not hosting domains:

  C:del<crlf>
  C:EntityName:NameServer<crlf>
  C:NameServer:ns1.registrarA.com<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:.<crlf>

  A registrar tries to delete a name server that is hosting domains:

  C:del<crlf>
  C:EntityName:NameServer<crlf>
  C:NameServer:ns1.registrarA.com<crlf>
  C:.<crlf>
  S:532 Domain names linked with name server<crlf>
  S:.<crlf>

4.3.4 DESCRIBE

  This command allows a registrar to obtain general information about an
  RRP implementation. The command MAY contain the following parameters:

  - The "Target" parameter set to value "Protocol".

  The implementation MUST return the protocol version number whether or
  not the request contains the "Target" parameter.

  Authorized User: All registrars MAY use the DESCRIBE command.

  Examples

  A registrar obtains general information about an RRP implementation:

  C:describe<crlf>
  C:-Target:Protocol<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:Protocol:RRP 1.1.0<crlf>



Hollenbeck, Srivastava     Expires June 2000                   [Page 12]


Internet-Draft        Registry Registrar Protocol          December 1999


  S:.<crlf>

4.3.5 MOD

  This command allows a registrar to update a registered domain name or
  a name server. The command allows the following operations on an
  attribute value for both single-valued and multi-valued attributes:

  - Add an attribute value. The value to be added MUST be unique among the
  values of the attribute. For a single-valued attribute, it replaces the
  current value.
  - Remove an attribute value. The value to be removed MUST exist. Further,
  an attribute value cannot be removed if it is the only value of a required
  attribute.

  Attribute values to be removed are identified by tagging with an "="
  suffix.

4.3.5.1 Domain Modification

  The request to modify a registered domain name MUST contain the
  following data:

  - The "EntityName" parameter set to value "Domain".
  - Fully qualified second level domain name in the "DomainName" parameter.

  The registrar can perform the following update operations on the
  domain name:

  - Update the name servers of the domain name by setting one or more instances
  of the "NameServer" parameter.
  - Update the status of the domain name by setting one or more instances of
  the "Status" parameter. Valid values for the "Status" parameter are defined
  in Section 6.

  Authorized User: The current registrar of a domain name MAY use the
  MOD command to modify the attributes of a domain name.

  Examples

  A registrar removes one name server (ns1) from a domain and adds a new name
  server (ns3) to the same domain:

  C:mod<crlf>
  C:EntityName:Domain<crlf>
  C:DomainName:example.com<crlf>
  C:NameServer:ns3.registrarA.com<crlf>
  C:NameServer:ns1.registrarA.com=<crlf>



Hollenbeck, Srivastava     Expires June 2000                   [Page 13]


Internet-Draft        Registry Registrar Protocol          December 1999


  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:.<crlf>

4.3.5.2 Name Server Modification

  The request to update a name server MUST contain the following data:
  - The "EntityName" parameter set to value "NameServer".
  - Fully qualified server name of the name server in the "NameServer"
  parameter.

  The registrar can perform the following update operations on the name
  server:
  - Update the "NameServer" attribute of the name server. This allows a
  registrar to change the name of a name server while preserving all existing
  associations.
  - Update the IP addresses of the name server by setting one or more instances
  of the "IPAddress" parameter.

  Authorized User: The current registrar of a name server MAY use the
  MOD command to modify the attributes of a domain name.

  Examples

  A registrar changes the name and IP address of a name server:

  C:mod<crlf>
  C:EntityName:NameServer<crlf>
  C:NameServer:ns1.registrarA.com<crlf>
  C:NewNameServer:ns2.registrarA.com<crlf>
  C:IPAddress:198.42.1.11<crlf>
  C:IPAddress:198.41.1.11=<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:.<crlf>

4.3.6 QUIT

  This command allows a registrar to close an RRP connection. A response
  MUST be sent before closing the connection.

  Authorized User: All registrars MAY use the QUIT command.

  Examples

  A registrar ends an RRP session and closes an existing connection:

  C:quit<crlf>



Hollenbeck, Srivastava     Expires June 2000                   [Page 14]


Internet-Draft        Registry Registrar Protocol          December 1999


  C:.<crlf>
  S:220 Command completed successfully. Server closing connection<crlf>
  S:.<crlf>

4.3.7 RENEW

  This command allows a registrar to renew a domain name in the System.
  The request to renew a domain name MUST contain the following data:

  - The "EntityName" parameter set to value "Domain".
  - Fully qualified second level domain name in the "DomainName" parameter.

  The request to renew a domain name MAY contain the renewal period in
  years for the domain being renewed in a single instance of a "Period"
  parameter and a single instance of a "CurrentExpirationYear"
  parameter. These parameters MUST appear together if either is
  specified, though the order in which the parameters appear is
  insignificant. The "Period" parameter identifies the number of years
  to be added to the registration. The "CurrentExpirationYear" parameter
  identifies the current expiration year, and is required to ensure that
  repeated attempts to retry this command do not result in multiple
  successful renewals. The System MUST provide a default number of
  renewal years if the "Period" and "CurrentExpirationYear" parameters
  are not provided. Repeated use of this command without the "Period"
  and "CurrentExpirationYear" parameters may result in repeated
  successful renewals since idempotency is not provided when these
  parameters are not used. The acceptable year values for the "Period"
  parameter are implementation specific subject to syntax restrictions.

  The System renews the domain name for a period specified by the
  registrar. If the domain name renewal is completed successfully, the
  System MUST return the new registration expiration date in the
  "RegistrationExpirationDate" attribute in the response.

  Authorized User: The current registrar of a domain name MAY use the
  RENEW command.

  Examples

  A registrar renews a domain name using a specified renewal period:

  C:renew<crlf>
  C:EntityName:Domain<crlf>
  C:DomainName:example.com<crlf>
  C:-Period:9<crlf>
  C:-CurrentExpirationYear:2001<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>



Hollenbeck, Srivastava     Expires June 2000                   [Page 15]


Internet-Draft        Registry Registrar Protocol          December 1999


  S:RegistrationExpirationDate:2010-09-22 10:27:00.000<crlf>
  S:.<crlf>

4.3.8 SESSION

  This command allows a registrar to establish an RRP session. A
  registrar can also use this command to change their password. The
  request to establish an RRP connection MUST contain the following
  command parameters:

  - The "Id" parameter set to the registrar's System user ID.
  - The "Password" parameter set to the registrar's current System password.

  The request to establish an RRP session MAY contain a new password for
  the registrar in a single instance of the "NewPassword" parameter.

  The registrar MUST send this command to the System before any other
  command.  If the command fails due to invalid information (such as an
  invalid registrar ID or password), the registrar can resend this
  request with corrected information. If the command fails a second
  time, the System SHOULD close the connection.

  Authorized User: All registrars MAY use the SESSION command.

  Examples

  A registrar establishes an RRP session:

  C:session<crlf>
  C:-Id:registrarA<crlf>
  C:-Password:i-am-registrarA<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:.<crlf>

4.3.9 STATUS

  This command allows a registrar to determine the current status of a
  domain name or name server.

4.3.9.1 Domain Status

  The request to query a domain name MUST contain the following data:

  - The "EntityName" parameter set to value "Domain".
  - Fully qualified second level domain name in the "DomainName" parameter.

  The response from the System MAY contain the following data:



Hollenbeck, Srivastava     Expires June 2000                   [Page 16]


Internet-Draft        Registry Registrar Protocol          December 1999


  - Fully qualified second level domain name in the "DomainName" attribute.
  - Fully qualified server names of name servers hosting the domain name in
  multiple instances of the "NameServer" attribute.
  - Registration expiration date in the "RegistrationExpirationDate"
  attribute.
  - ID of the current registrar of the domain name in the "Registrar"
  attribute.
  - Date the domain name was transferred by the current registrar in the
  "RegistrarTransferDate" attribute.
  - Current statuses of the domain name in multiple instances of the
  "Status" attribute.
  - Date the domain name was originally registered in the "CreatedDate"
  attribute.
  - ID of the registrar that originally registered the domain name in the
  "CreatedBy" attribute.
  - Date the domain name was last updated in the "UpdatedDate" attribute.
  - ID of the entity (either a registrar or the registry) that last updated
  the domain name in the "UpdatedBy" attribute.

  Authorized User: The current registrar of a domain name MAY use the
  STATUS command to view current domain name attributes.

  Examples

  The current registrar of a domain name queries the domain name:

  C:status<crlf>
  C:EntityName:Domain<crlf>
  C:DomainName:example.com<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:DomainName:example.com<crlf>
  S:NameServer:ns2.registrarA.com<crlf>
  S:NameServer:ns3.registrarA.com<crlf>
  S:RegistrationExpirationDate:2010-09-22 10:27:00.000<crlf>
  S:Registrar:registrarA<crlf>
  S:RegistrarTransferDate:1998-09-22 10:27:00.000<crlf>
  S:Status:ACTIVE<crlf>
  S:CreatedDate:1998-09-22 10:27:00.000<crlf>
  S:CreatedBy:registrarA<crlf>
  S:UpdatedDate:2002-09-22 10:27:00.000<crlf>
  S:UpdatedBy:registrarA<crlf>
  S:.<crlf>

  A registrar queries a domain name currently registered by another registrar:

  C:status<crlf>
  C:EntityName:Domain<crlf>



Hollenbeck, Srivastava     Expires June 2000                   [Page 17]


Internet-Draft        Registry Registrar Protocol          December 1999


  C:DomainName:example.com<crlf>
  C:.<crlf>
  S:531 Authorization failed<crlf>
  S:.<crlf>

4.3.9.2 Name Server Status

  The request to query a name server MUST contain the following data:

  - The "EntityName" parameter set to value "NameServer".
  - Fully qualified name of the name server in the "NameServer" parameter.

  The response from the System MAY contain the following data:

  - Fully qualified name of the name server in the "NameServer" attribute.
  - IP addresses of the name server in multiple instances of the
  "IPAddress" attribute.
  - ID of the current registrar of the name server in the "Registrar"
  attribute.
  - Date the name server was transferred by the current registrar in the
  "RegistrarTransferDate" attribute.
  - Date the name server was registered in the "CreatedDate" attribute.
  - ID of the entity that registered the name server in the "CreatedBy"
  attribute.
  - Date the name server was last updated in the "UpdatedDate" attribute.
  - ID of the entity that last updated the name server in the "UpdatedBy"
  attribute.

  Authorized User: The current registrar of a name server MAY use the
  STATUS command to view current domain name attributes.

  Examples

  The current registrar of a name server queries the name server:

  C:status<crlf>
  C:EntityName:NameServer<crlf>
  C:NameServer:ns1.registrarA.com<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:NameServer:ns1.registrarA.com<crlf>
  S:IPAddress:198.42.1.11<crlf>
  S:Registrar:registrarA<crlf>
  S:RegistrarTransferDate:1998-09-22 10:27:00.000<crlf>
  S:CreatedDate:1998-09-22 10:27:00.000<crlf>
  S:CreatedBy:registrarA<crlf>
  S:UpdatedDate:2002-09-22 10:27:00.000<crlf>
  S:UpdatedBy:registrarA<crlf>



Hollenbeck, Srivastava     Expires June 2000                   [Page 18]


Internet-Draft        Registry Registrar Protocol          December 1999


  S:.<crlf>

  A registrar queries a name server that was registered by another registrar:

  C:status<crlf>
  C:EntityName:NameServer<crlf>
  C:NameServer:ns1.registrarA.com<crlf>
  C:.<crlf>
  S:531 Authorization failed<crlf>
  S:.<crlf>

4.3.10 TRANSFER

  This command allows a registrar to transfer a domain name from another
  registrar to itself and to approve or reject transfer requests
  initiated by other registrars. The request to transfer a domain name
  MUST contain the following data:

  - The "EntityName" parameter set to value "Domain".
  - Fully qualified second level domain name in the "DomainName" parameter.

  The System must notify the potential losing registrar when a domain
  transfer request has been received. The losing registrar SHOULD then
  explicitly approve or reject the transfer. A request to approve or
  reject a transfer request MUST contain a single instance of the
  "Approve" parameter with a value of "Yes" to approve the transfer or a
  value of "No" to reject the transfer. An implementation MAY provide a
  default approval or rejection action to be taken if the losing
  registrar does not explicitly approve or reject the transfer request.
  The criteria used by registrars to approve or deny requested transfers
  are typically based on business policies that are beyond the scope of
  this document.

  Name servers MUST be implicitly transferred when their parent domain
  name is transferred.

  Authorized User: All registrars MAY use the TRANSFER command.

  Examples

  A registrar requests transfer of a domain name from another registrar:

  C:transfer<crlf>
  C:EntityName:Domain<crlf>
  C:DomainName:example.com<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:.<crlf>



Hollenbeck, Srivastava     Expires June 2000                   [Page 19]


Internet-Draft        Registry Registrar Protocol          December 1999


  The original registrar approves the transfer request:

  C:transfer<crlf>
  C:-Approve:Yes<crlf>
  C:EntityName:Domain<crlf>
  C:DomainName:example.com<crlf>
  C:.<crlf>
  S:200 Command completed successfully<crlf>
  S:.<crlf>

5. Response Codes

  RRP commands may return a variety of response codes to signify normal
  completion or error conditions. This section documents all of the
  defined RRP response codes.

5.1 Response Code Summary

  200 Command completed successfully
  This is the normal response for successful completion of most RRP
  commands.

  210 Domain name available
  This is the normal response for successful completion of an RRP CHECK
  command for a domain name that is not currently registered.

  211 Domain name not available
  This is the normal response for successful completion of an RRP CHECK
  command for a domain name that is currently registered.

  212 Nameserver name available
  This is the normal response for successful completion of an RRP CHECK
  command for a name server that is not currently registered.

  213 Nameserver name not available
  This is the normal response for successful completion of an RRP CHECK
  command for a name server that is currently registered.

  220 Command completed successfully. Server closing connection
  This is the normal response for successful completion of an RRP QUIT
  command.  It may also be returned by other RRP commands if a transient
  situation is noted that requires closing the connection after
  successfully completing the RRP command.

  420 Command failed due to server error. Server closing connection
  A transient server error has caused RRP command failure and session
  termination. A new session must be established before continued
  processing can be attempted.



Hollenbeck, Srivastava     Expires June 2000                   [Page 20]


Internet-Draft        Registry Registrar Protocol          December 1999


  421 Command failed due to server error. Client should try again
  A transient server error has caused RRP command failure. A subsequent
  retry may produce successful results.

  500 Invalid command name
  A client-specified RRP command name was not recognized as a valid RRP
  command name.

  501 Invalid command option
  A client-specified RRP command parameter was not recognized as a valid
  RRP command parameter.

  502 Invalid entity value
  The "value" of an entity name-value pair is invalid. Command blocks
  that require an "EntityName" parameter also require a value that
  specifies the entity name, and the provided value is invalid.

  503 Invalid attribute name
  A client-specified RRP command parameter was not recognized as a valid
  RRP command parameter.

  504 Missing required attribute
  A parameter required to execute the RRP command was not provided by
  the client. The command should be retried with all required parameters
  specified.

  505 Invalid attribute value syntax
  A supplied parameter value is syntactically incorrect. For example, a
  year value digit such as "5" may be required but the client provided a
  string of characters such as "five".

  506 Invalid option value
  A client-specified value for an RRP command parameter is out-of-bounds
  or otherwise not within acceptable System limits.

  507 Invalid command format
  The specified command does not resemble a well-formed RRP command. The
  command should be retried using the proper command structure and
  syntax.

  508 Missing required entity
  An entity required for command completion was not provided by the
  client. For example, the CHECK command requires specification of
  either a "Domain" entity or a "Nameserver" entity.

  509 Missing command option
  A command parameter that isn't really optional (such as the registrar
  ID in a SESSION command) was not provided by the client. The command



Hollenbeck, Srivastava     Expires June 2000                   [Page 21]


Internet-Draft        Registry Registrar Protocol          December 1999


  should be retried with all needed parameters.

  520 Server closing connection. Client should try opening new connection; <why>
  A timeout event has been detected, and the client's session is being
  ended.  The System SHOULD define timeout periods to begin a client
  command, complete a client command, and for the duration of an open
  session. The reason for the timeout MUST be provided at the end of the
  response code string.

  521 Too many sessions open. Server closing connection
  A System-defined limit on the number of open connections has been
  exceeded, and it is impossible to establish a new session at the
  moment. It may be possible to establish a session by waiting for a few
  moments or by closing existing unused sessions.

  530 Authentication failed
  The client-supplied registrar identifier or password was not
  recognized by the System. A subsequent retry with valid values may
  produce successful results. Repeated authorization failures MAY result
  in termination of the TCP connection.

  531 Authorization failed
  Registrars may not view or alter data associated with either the
  registry or another registrar. This response code is typically
  returned when a registrar attempts to view or modify data belonging to
  either the registry or another registrar. A typical situation includes
  doing a STATUS command for a domain registered to another registrar.

  532 Domain names linked with name server
  The name server is hosting active domains. This error occurs when a
  registrar is trying to delete a server that is the name server for
  active domains.  The registry MUST not allow the registrar to delete
  this server. All of the domain names using this server MUST be
  modified to use a different name server before the name server can be
  deleted.

  533 Domain name has active name servers
  The domain name has active name servers. The registrar is trying to
  delete a domain name that is a parent domain of an active name server,
  i.e., a server that is hosting active domains. All of the name servers
  within the domain MUST be removed from service before the domain can
  be deleted.

  534 Domain name has not been flagged for transfer
  The registrar is trying to approve or reject a domain name transfer
  for a domain name that is not pending transfer.

  535 Restricted IP address



Hollenbeck, Srivastava     Expires June 2000                   [Page 22]


Internet-Draft        Registry Registrar Protocol          December 1999


  IANA identifies certain IP address ranges that are not valid for
  normal use.  The registrar is trying to use an IP address that is in a
  restricted IP address range as identified by IANA.

  536 Domain already flagged for transfer
  The registrar tried to perform a transfer command for a domain name
  that is awaiting approval of an earlier transfer request.

  540 Attribute value is not unique
  A supplied attribute value is not unique. This occurs when the
  registrar is adding a domain name that already exists in the registry,
  a server that already exists in the registry, or an IP address that is
  already being used by another server in the registry. Another
  possibility occurs when performing domain modifications and the
  registrar is adding a server that is already in the list of servers
  for the domain name or setting a domain name to a status to which it
  is already set. The RRP STATUS command MAY be used to determine
  current domain name status before attempting to change the status.
  When modifying or adding a name server, the IP address of the name
  server might not be unique. The registry MUST not allow IP addresses
  to be used by more than one server.

  541 Invalid attribute value
  A supplied parameter value is invalid. Examples of invalid attribute
  values include an invalid IP address, an invalid domain name, an
  invalid server name, or an invalid renewal period.

  542 Invalid old value for an attribute
  A current attribute value to be modified is invalid. The registrar is
  trying to modify an attribute of a server or a domain name that does
  not exist in the registry.

  543 Final or implicit attribute cannot be updated
  The registrar is attempting to modify an attribute that is only
  modifiable by the registry. Registrars can not modify final or
  implicit attribute values.

  544 Entity on hold
  The attempted operation was rejected because the entity is on HOLD
  status. If the HOLD status was set by the registrar, the status can be
  changed using the MOD command and the requested command can be
  retried. If the HOLD status was set by the registry, the registrar
  must contact the registry to change the status before the command can
  be successful.

  545 Entity reference not found
  A required entity reference was not found. This occurs when the
  registrar tries to add a new name server and the parent domain of the



Hollenbeck, Srivastava     Expires June 2000                   [Page 23]


Internet-Draft        Registry Registrar Protocol          December 1999


  name server does not exist in the registry. It also occurs when the
  user is trying to add a new name server to a domain name when the name
  server does not exist in the registry.

  546 Credit limit exceeded
  The registrar's credit limit has been exceeded. This is an
  implementation specific error that occurs when a potentially billable
  operation, such as adding a domain name, renewing a domain name, or
  transferring a domain name, is attempted and the registrar does not
  have sufficient financial standing with the registry to complete the
  operation.

  547 Invalid command sequence
  RRP commands are issued using a well-formed syntax that requires entry
  of command structures in particular sequences. This response code
  indicates that an ill-formed command was received and rejected.

  548 Domain is not up for renewal
  A RENEW command was attempted during a period in which the domain can
  not be renewed. Implementations MAY limit renewal periods to
  particular time frames, such as within 90 days of the domain's
  expiration. This response indicates that the RENEW command was
  received outside of the System-defined domain renewal period.

  549 Command failed
  A System error prevented successful completion of the requested RRP
  command.  Retrying the command might produce success, but a repeated
  failure indicates a System error condition.

  550 Parent domain not registered
  The parent domain of a name server being registered is not registered.
  This occurs when the registrar tries to add a new name server and the
  parent domain for the server does not exist in the registry.

  551 Parent domain status does not allow for operation
  The status of the parent domain does not allow the requested
  operation. This occurs when a registrar tries to modify a server whose
  parent domain is flagged as LOCK or HOLD in the registry.

  552 Domain status does not allow for operation
  The status of the domain does not allow the requested operation. This
  occurs when a registrar tries to modify or delete a domain that is
  flagged as LOCK or HOLD in the registry.

  553 Operation not allowed. Domain pending transfer
  The status of the domain does not allow the requested operation. The
  registrar is attempting to delete a domain that is pending approval or
  denial of a transfer request.



Hollenbeck, Srivastava     Expires June 2000                   [Page 24]


Internet-Draft        Registry Registrar Protocol          December 1999


  554 Domain already registered
  A registrar tried to register a domain name that has already been
  registered by the same registrar.

  555 Domain already renewed
  A registrar tried to renew a domain using the same parameters as
  specified for an earlier, successful renewal. This will commonly occur
  when executing the same RENEW command more than once.

  556: Maximum registration period exceeded
  A registrar tried to renew a domain registration without specifying a
  renewal period (the System default was used), and the resulting new
  registration period exceeds the System-defined maximum registration
  period. If there is renewal time available with the System-defined
  maximum registration period it may be possible to retry the RENEW
  command with specified renewal period parameters.

5.2 Command-Response Correspondence

  The session between the client and the server is intended to be an
  alternating dialogue. Each command issued by a client MUST be acted
  upon by the server, which MUST return a response code to document the
  success or failure of command execution. "Success" means that the
  command completed normal execution without error.  "Failure" means
  that the System did not complete the command as requested. Failure may
  be due to either syntax, semantic, data, or System errors.

  A complete list of response codes for each RRP command is listed
  below.

  Command: ADD
  Success: 200, 220
  Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535, 540,
  541, 545, 546, 547, 549, 550, 554

  Command: CHECK
  Success: 210, 211, 212, 213
  Failure: 220, 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 541, 547,
  549

  Command: DEL
  Success: 200, 220
  Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 532, 533,
  541, 544, 545, 547, 549, 551, 552, 553

  Command: DESCRIBE
  Success: 200, 220
  Failure: 420, 421, 500, 501, 506, 507, 509, 520, 547, 549



Hollenbeck, Srivastava     Expires June 2000                   [Page 25]


Internet-Draft        Registry Registrar Protocol          December 1999


  Command: MOD
  Success: 200, 220
  Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535, 540,
  541, 542, 543, 544, 545, 547, 549, 550, 551, 552, 553

  Command: QUIT
  Success: 220
  Failure: 420, 421, 500, 507, 520, 547, 549

  Command: RENEW
  Success: 200, 220
  Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 541, 545,
  546, 547, 548, 549, 552, 553, 555, 556

  Command: SESSION
  Success: 200, 220
  Failure: 420, 421, 500, 501, 506, 507, 508, 509, 520, 521, 530, 531, 547,
  549

  Command: STATUS
  Success: 200, 220
  Failure: 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520, 531,
  541, 545, 547, 549

  Command: TRANSFER
  Success: 200, 220
  Failure: 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520, 531,
  534, 536, 541, 544, 545, 546, 547, 549, 552, 553

6. Domain Status Codes

  The status of a domain can be viewed using the RRP STATUS command and
  modified using the RRP MOD command. Both the registry and the
  sponsoring registrar MAY view and change the status of a domain. The
  criteria for status changes are highly dependent on registry and
  registrar business models and are thus beyond the scope of this
  specification.

  The domain's status SHOULD have a direct bearing on whether or not the
  domain appears in the appropriate TLD zone file and whether or not the
  domain can be modified. A domain can have more than one assigned
  status, e.g., REGISTRAR-HOLD and REGISTRAR-LOCK. If a domain is in
  ACTIVE status, then the domain name can only be in this status.  When
  a registrar sets a domain name to REGISTRAR-LOCK, the registry MUST
  automatically remove the ACTIVE status. When the registrar removes the
  REGISTRAR-LOCK and other domain statuses, the registry MUST
  automatically set the domain name status to ACTIVE.




Hollenbeck, Srivastava     Expires June 2000                   [Page 26]


Internet-Draft        Registry Registrar Protocol          December 1999


6.1 Domain Status Code Description

  ACTIVE: This is the default status of a domain at registration time.
  The registry sets the domain to this status. The domain is modifiable
  by the registrar. The domain can be renewed. The domain SHALL be
  included in the zone file when in this status if the domain has at
  least one associated name server.

  REGISTRY-LOCK: The registry sets the domain to this status. The domain
  cannot be modified or deleted by the registrar. The registry MUST
  remove the REGISTRY-LOCK status for the registrar to modify the
  domain. The domain can be renewed. The domain SHALL be included in the
  zone file when in this status if the domain has at least one
  associated name server.

  REGISTRY-HOLD: The registry sets the domain to this status. The domain
  cannot be modified or deleted by the registrar. The registry MUST
  remove the REGISTRY-HOLD status for the registrar to modify the
  domain. The domain can be renewed. The domain SHALL NOT be included in
  the zone file when in this status.

  REGISTRAR-HOLD: The registrar of the domain sets the domain to this
  status. The domain can not be modified or deleted when in this status.
  The registrar MUST remove REGISTRAR-HOLD status to modify the domain.
  The domain can be renewed. The domain SHALL NOT be included in the
  zone file when in this status.

  REGISTRAR-LOCK: The registrar of the domain sets the domain to this
  status. The domain cannot be modified or deleted when in this status.
  The registrar MUST remove REGISTRAR-LOCK status to modify the domain.
  The domain can be renewed. The domain SHALL be included in the zone
  file when in this status.

  REGISTRY-DELETE-NOTIFY: A domain is set on this status if it has
  expired and has child name servers that are hosting other domains.
  Only the registry may set this status. The domain SHALL be included in
  the zone file when in this status if the domain has at least one
  associated name server.

7. Formal Syntax

  The following syntax specification uses the augmented Backus-Naur Form
  (BNF) as described in [ABNF].

  ; ABNF specification for Registry Registrar Protocol (RRP) v1.1.0
  ; Note that character string literals are case insensitive.

  ; Lexical tokens



Hollenbeck, Srivastava     Expires June 2000                   [Page 27]


Internet-Draft        Registry Registrar Protocol          December 1999


  space = %x20 ; " "
  dot = %x2E ; "."
  dash = %x2D ; "-"
  underscore = %x5F ; "_"
  colon = %x3A ; ":"
  cr = %x0D ; ASCII carriage return
  lf = %x0A ; ASCII linefeed
  crlf = cr lf
  alpha = %x41-5A / %x61-7A ; A-Z / a-z
  digit = %x30-39 ; 0-9
  dns-char = alpha / digit / dash
  id-char = alpha / digit / underscore / dash
  id-prefix = alpha / digit
  id-word = id-prefix *id-char
  printable-char = %x20-7E ; ASCII " " - "~"

  ; Start of basic grammar.
  year = 4digit
  month = 2digit
  day = 2digit
  ymd = year dash month dash day
  hour = 2digit
  minute = 2digit
  second = 2digit
  milli-second = 3digit
  hms = hour colon minute colon second dot milli-second
  time-stamp = ymd space hms
  ip-address = 1*3digit dot 1*3digit dot 1*3digit dot 1*3digit
  password = 4*16printable-char
  option-name = 1*128id-word
  option-tag = dash option-name
  option-value = 1*128id-word
  attribute-name = 1*128id-word
  attribute-value = 1*128printable-char
  attribute-line = attribute-name colon attribute-value crlf
  response = 3digit space 1*printable-char crlf
  version-number = "RRP" space 1*digit dot 1*digit dot 1*digit
  label = id-prefix *61dns-char id-prefix
  sldn = label dot label
  servername = *(label dot) sldn
  period = %x31-39 / (%x31-39 %x30-39) ; "1" - "9" or "10" - "99"
  period-option = dash "Period" colon period crlf
  yesno = "Yes" / "No"

  ; RRP commands and responses.
  rrp = add / check / delete / describe / mod / quit / renew /
        session / status / transfer




Hollenbeck, Srivastava     Expires June 2000                   [Page 28]


Internet-Draft        Registry Registrar Protocol          December 1999


  add = add-request add-response
  check = check-request check-response
  delete = del-request del-response
  describe = describe-request describe-response
  mod = mod-request mod-response
  quit = quit-request quit-response
  renew = renew-request renew-response
  session = session-request session-response
  status = status-request status-response
  transfer = transfer-request transfer-response

  ; ADD command.
  add-request = add-domain-request / add-nameserver-request
  add-response = add-domain-response / add-nameserver-response
  add-domain-request = "add" crlf
   "EntityName" colon "Domain" crlf
   "DomainName" colon sldn crlf
   [period-option]
   0*13("NameServer" colon servername crlf)
   dot crlf
  add-nameserver-request = "add" crlf
   "EntityName" colon "NameServer" crlf
   "NameServer" colon servername crlf
   1*("IPAddress" colon ip-address crlf)
   dot crlf
  add-domain-response = response
   "RegistrationExpirationDate" colon time-stamp crlf
   "status" colon 1*digit crlf
   dot crlf
  add-nameserver-response = response
   dot crlf

  ; CHECK command.
  check-request = check-domain-request / check-nameserver-request
  check-response = check-domain-response / check-nameserver-response
  check-domain-request = "check" crlf
   "EntityName" colon "Domain" crlf
   "DomainName" colon sldn crlf
   dot crlf
  check-nameserver-request = "check" crlf
   "EntityName" colon "NameServer" crlf
   "NameServer" colon servername crlf
   dot crlf
  check-domain-response = response
   dot crlf
  check-nameserver-response = available-check-nameserver-response /
                              notavailable-check-nameserver-response
  available-check-nameserver-response = response



Hollenbeck, Srivastava     Expires June 2000                   [Page 29]


Internet-Draft        Registry Registrar Protocol          December 1999


   dot crlf
  notavailable-check-nameserver-response = response 1*("IPAddress" colon ip-address crlf)
   dot crlf

  ; DEL command.
  del-request = del-domain-request / del-nameserver-request
  del-response = response
   dot crlf
  del-domain-request = "del" crlf
   "EntityName" colon "Domain" crlf
   "DomainName" colon sldn crlf
   dot crlf
  del-nameserver-request = "del" crlf
   "EntityName" colon "NameServer" crlf
   "NameServer" colon servername crlf
   dot crlf

  ; DESCRIBE command.
  describe-request = "describe" crlf
   [target-option]
   *(option-tag colon option-value crlf)
   dot crlf
  describe-response = response
   "Protocol" colon version-number crlf
   *attribute-line
   dot crlf
  target-option = dash "Target" colon "Protocol" crlf

  ; MOD command.
  mod-request = mod-domain-request / mod-nameserver-request
  mod-response = response
   *attribute-line
   dot crlf
  mod-domain-request = "mod" crlf
   "EntityName" colon "Domain" crlf
   "DomainName" colon sldn crlf
   *(add-attribute-value-line /
   remove-attribute-value-line /
   replace-attribute-value-line)
   dot crlf
  mod-nameserver-request = "mod" crlf
   "EntityName" colon "NameServer" crlf
   "NameServer" colon servername crlf
   ["NewNameServer" colon attribute-value crlf]
   *(add-attribute-value-line /
   remove-attribute-value-line /
   replace-attribute-value-line)
   dot crlf



Hollenbeck, Srivastava     Expires June 2000                   [Page 30]


Internet-Draft        Registry Registrar Protocol          December 1999


  add-attribute-value-line =
   attribute-name colon new-attribute-value
  remove-attribute-value-line =
   attribute-name colon old-attribute-value "="
  replace-attribute-value-line =
   attribute-name colon old-attribute-value "="
   new-attribute-value
  old-attribute-value = attribute-value
  new-attribute-value = attribute-value

  ; QUIT command.
  quit-request = "quit" crlf
   dot crlf
  quit-response = response
   dot crlf

  ; RENEW command.
  renew-request = "renew" crlf
   "EntityName" colon "Domain" crlf
   "DomainName" colon sldn crlf
   [renew-period-option]
   dot crlf
  expiration-year-option = dash "CurrentExpirationYear" colon year crlf
  renew-period-option = period-option expiration-year-option /
                        expiration-year-option period-option
  renew-response = response
   "RegistrationExpirationDate" colon time-stamp crlf
   dot crlf

  ; SESSION command.
  session-request = "session" crlf
   registrar-id-option
   registrar-password-option
   [registrar-newpassword-option]
   dot crlf
  session-response = response
   dot crlf
  registrar-id-option = dash "Id" colon option-value crlf
  registrar-password-option =
   dash "Password" colon password crlf
  registrar-newpassword-option =
   dash "NewPassword" colon password crlf

  ; STATUS command.
  status-request = status-domain-request /
                   status-nameserver-request
  status-response = response
   *attribute-line



Hollenbeck, Srivastava     Expires June 2000                   [Page 31]


Internet-Draft        Registry Registrar Protocol          December 1999


   dot crlf
  status-domain-request = "status" crlf
   "EntityName" colon "Domain" crlf
   "DomainName" colon sldn crlf
   dot crlf
  status-nameserver-request = "status" crlf
   "EntityName" colon "NameServer" crlf
   "NameServer" colon servername crlf
   dot crlf

  ; TRANSFER command.
  transfer-request = "transfer" crlf
   [approve-option]
   "EntityName" colon "Domain" crlf
   "DomainName" colon sldn crlf
   dot crlf
  transfer-response = response
   "RegistrationExpirationDate" colon time-stamp crlf
   dot crlf
  approve-option = dash "Approve" colon yesno crlf

  ; End of grammar.

8. Internationalization

  RRP is defined using 7-bit US-ASCII characters. Other character sets
  and character codes are not currently supported.

9. Known Issues

  RRP was not designed to provide bulk data query features. The primary
  goal of the original protocol designers was to provide a fast, light
  weight transactional protocol that could be implemented with minimal
  need for database queries that would take a "long" time to complete or
  that would return a "large" amount of data. Implementers SHOULD
  consider developing offline reporting features to provide bulk data
  for registrar reporting in a fashion suitable for the given registry-
  registrar operating environment.

  This version of RRP does contain a few limitations noted over the
  course of several months of operational experience with live domain
  name registrars.  Later versions of this protocol or its successors
  should strive to resolve or address each of the following issues:

  The DESCRIBE command should return information describing System-
  defined default implementation values.

  Use of the RENEW command without the "CurrentExpirationYear" and



Hollenbeck, Srivastava     Expires June 2000                   [Page 32]


Internet-Draft        Registry Registrar Protocol          December 1999


  "Period" parameters does not provide idempotency. Repeated execution
  of a RENEW command without these parameters can result in multiple
  successful RENEW commands, which may not be the desired action if a
  registrar is retrying a RENEW command due to network connectivity
  problems.

  Time stamps returned by RRP do not include time zone identifiers and
  SHOULD be interpreted as local registry time.

  The protocol does not provide features for a registrar to become aware
  of domain transfer requests and responses. Systems must rely on means
  outside of the protocol, such as electronic mail, to inform registrars
  of transfer requests and responses.

  The protocol does not provide features for a registrar to determine
  all of the domains served by a name server. Systems must provide this
  information using a method outside of the protocol, such as through
  periodic extracts from a System database.

  The protocol does not provide features to manage lame delegation of
  name servers. Any registrar may "use" name servers registered by
  another registrar.  When a registrar tries to delete a domain or name
  server it is quite possible that name servers in the domain to be
  deleted or the name server to be deleted will be associated with other
  live domains, precluding immediate deletion.  Systems must rely on
  means outside of the protocol to manage lame delegation of name
  servers.

  The use of "=" within the MOD command to indicate a value to be
  removed is somewhat confusing. A more explicit means of identifying
  old and new attribute values within the protocol syntax could make
  this feature more obvious.

  The CHECK command also returns name server IP addresses when returning
  positive confirmation of the registration of a name server.  This
  extra information may be useful, but it is inconsistent with the
  limited function of the command.  The command should return a positive
  or negative response and nothing more.

  The formal protocol syntax described in this document requires a
  specific order for the elements of a command entity block and command
  options. The NSI Registry's server-side implementation of the protocol
  provides the additional flexibility of allowing order independent
  specification of options and entity block elements. Client-side
  implementers are strongly urged to observe the order of command
  elements as specified here to ensure compliance if the more restricted
  form is enforced in the future.




Hollenbeck, Srivastava     Expires June 2000                   [Page 33]


Internet-Draft        Registry Registrar Protocol          December 1999


10. Security Considerations

  Misuse of the Registry Registrar Protocol can have catastrophic
  operational consequences for registrants, registrars, and registries.
  As such, all registrars must be authenticated prior to all
  interactions with the registry.  In addition, all data exchanged
  between the registrar and the registry must be protected to avoid
  unintended disclosure of information.

11. IANA Considerations

  IANA assigned TCP port 648 for RRP use in November 1998. No other
  action is required of IANA to support operation of this protocol.

  IANA has reserved certain IPv4 address ranges as described in
  [ALLOCATION].  Implementers MUST ensure that name server IP addresses
  do not fall into one of the reserved address ranges to avoid
  operational DNS errors.

12. References

  [ABNF] D. Crocker (Editor) and P. Overell: "Augmented BNF for Syntax
  Specifications: ABNF", RFC 2234, November 1997.

  [ALLOCATION] K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, and J.
  Postel:  "Internet Registry IP Allocation Guidelines", BCP 12, RFC
  2050, November 1996.

  [MUSTSHOULD] S. Bradner: "Key Words for Use in RFCs to Indicate
  Requirement Levels", BCP 14, RFC 2119, March 1997.

  [SSL] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
  Netscape Communications Corp., November 18, 1996.

  [TLS] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", RFC
  2246, January 1999.

13. Acknowledgments

  Many people have contributed significantly to this document and the
  protocol it describes. Brad McMillen and Neeran Saraf deserve special
  mention as co-authors of an earlier internal protocol specification.
  Other content contributors to the earlier internal specification
  include Aristotle Balogh, Chris Bason, Mark Kosters, Jasdip Singh, and
  Yibing Wu. Finally, significant contributors to the review of this
  document include Steve Mahlstedt and Chris Smith.

14. Authors' Address



Hollenbeck, Srivastava     Expires June 2000                   [Page 34]


Internet-Draft        Registry Registrar Protocol          December 1999


  Scott Hollenbeck                          Manoj Srivastava
  Network Solutions, Inc. Registry          Network Solutions, Inc. Registry
  505 Huntmar Park Dr.                      505 Huntmar Park Dr.
  Herndon, VA 20170                         Herndon, VA 20170
  USA                                       USA
  shollenb@netsol.com                       manojs@netsol.com

15. Full Copyright Statement

  Copyright (C) The Internet Society 1999.  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.


















Hollenbeck, Srivastava     Expires June 2000                   [Page 35]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/