NSI Registry Registrar Protocol (RRP) Version 1.1.0
RFC 2832
Document | Type |
RFC - Informational
(May 2000; No errata)
Updated by RFC 3632
Was draft-hollenbeck-rrp (individual)
|
|
---|---|---|---|
Authors | Manoj Srivastava , Scott Hollenbeck | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2832 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group S. Hollenbeck Request for Comments: 2832 M. Srivastava Category: Informational Network Solutions, Inc. Registry May 2000 NSI Registry Registrar Protocol (RRP) Version 1.1.0 Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) 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" to document the protocol implementation developed by the Network Solutions, Inc. Registry. 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 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.net/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, Hollenbeck & Srivastava Informational [Page 1] RFC 2832 NSI Registry Registrar Protocol May 2000 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 ........................................ 5 3. Connection Model ............................................. 5 4. Protocol Description ......................................... 6 4.1 Request Format .............................................. 7 4.2 Response Format ............................................. 8 4.3 Protocol Commands ........................................... 8 4.3.1 ADD ....................................................... 8 4.3.2 CHECK ..................................................... 11 4.3.3 DEL ....................................................... 12 4.3.4 DESCRIBE .................................................. 14 4.3.5 MOD ....................................................... 14 4.3.6 QUIT ...................................................... 16 4.3.7 RENEW ..................................................... 17 4.3.8 SESSION ................................................... 18 4.3.9 STATUS .................................................... 18 4.3.10 TRANSFER ................................................. 21 5. Response Codes ............................................... 23 5.1 Response Code Summary ....................................... 23 5.2 Command-Response Correspondence ............................. 28 6. Domain Status Codes .......................................... 29 6.1 Domain Status Code Description .............................. 30 7. Formal Syntax ................................................ 30 8. Internationalization ......................................... 35 9. Known Issues ................................................. 35 10. Security Considerations ..................................... 37 11. IANA Considerations ......................................... 37 12. References .................................................. 37Show full document text