Network Working Group Eric Brunner-Williams INTERNET-DRAFT Ayesha Damaraju Ning Zhang NeuStar February, 2001 Expires August 2001 Extensible Registry Protocol (XRP) 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: ...message payload... XRP peers are named using the "addr-spec" syntax specified in "Internet Message Format" (draft-drums-msg-fmt-09), i.e., 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 (as a URI prefix) Example: Identification of XRP profile after BEEP session establishment S: S: S: RPY 0 0 . 0 162 S: Content-Type: application/beep+xml S: S: S: S: S: S: S: END C: RPY 0 0 . 0 52 C: Content-Type: application/beep+xml C: C: 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: C: C: ABYTXORERLTABYL]]> C: C: C: END S: S: RPY 0 1 . 264 99 S: Content-Type: application/beep+xml S: S: 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: C: C: ABYTXORERLTABYL]]> C: C: C: END S: S: RPY 0 1 . 264 190 S: Content-Type: application/beep+xml S: S: authorization failed 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: C: C: ABYTXORERLTABYL]]> C: C: C: END S: S: RPY 0 1 . 264 99 S: Content-Type: application/beep+xml S: S: 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 and ended with the XRP tag . For example, to exchange the following message body that conforms the XML schema definition of XRP messages: Brunner, et al Expires August 2001 [Page 9] Internet-Draft Extensible Registry Protocol (XRP) February 2001 999 ERROR REASON 2001-01-20 REG-1234 ABC-12345-XYZ The corresponding BEEP message encoding will be as follows: C: MSG 1 2 . 42 560 C: Content-Type: text/xml C C: C: C: C: C: 999 C: ERROR REASON C: C: C: 2001-01-20 C: REG-1234 C: ABC-12345-XYZ C: C: C: 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 element that identifies the start of the command 2. A command option corresponding to one of the valid XRP commands 3. A element that uniquely identifies the command to both the client and the server consisting of the following child elements: a) A element that contains the date of the commands execution b) A 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 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 type and parameters ... ... transaction-id element contents ... Brunner, et al Expires August 2001 [Page 11] Internet-Draft Extensible Registry Protocol (XRP) February 2001 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 parameters ... ... transaction-id element contents ... 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 body ... ... transaction identifier element contents ... 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: nnn message text ... response data ... ... transaction identifier elements of the original request ... 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: ... object specific data ... yyyy-mm-dd clientXX ABC-12345-XYZ 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: yyyy-mm-dd clientXX ABC-12345-XYZ 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: ... object specific fields ... Brunner, et al Expires August 2001 [Page 15] Internet-Draft Extensible Registry Protocol (XRP) February 2001 yyyy-mm-dd clientXX ABC-12345-XYZ 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: nnn message text ... object specific elements ... yyyy-mm-dd clientXX ABC-12345-XYZ 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: ... object specific identification fields ... yyyy-mm-dd clientXX ABC-12345-XYZ 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: nnn message text ... object specific elements ... yyyy-mm-dd clientXX ABC-12345-XYZ Brunner, et al Expires August 2001 [Page 17] Internet-Draft Extensible Registry Protocol (XRP) February 2001 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: ... object specific fields ... yyyy-mm-dd clientXX ABC-12345-ZYZ 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: nnn message text ... object specific elements ... Brunner, et al Expires August 2001 [Page 18] Internet-Draft Extensible Registry Protocol (XRP) February 2001 yyyy-mm-dd clientXX ABC-12345-XYZ 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: ... object specific identifier fields ... yyyy-mm-dd clientYY ABC-12345-XYZ yyyy-mm-dd clientXX ABC-12345-XYZ 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: ... object specific identifier fields ... yyyy-mm-dd clientYY ABC-12345-XYZ 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: nnn message text ... object specific identifier fields ... yyyy-mm-dd clientYY ABC-12345-XYZ yyyy-mm-dd clientYY ABC-12345-XYZ 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: ... object specific identifier fields ... yyyy-mm-dd clientYY ABC-12345-XYZ 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: ... object specific identifier fields ... yyyy-mm-dd clientYY ABC-12345-XYZ yyyy-mm-dd clientXX ABC-12345-XYZ 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: nnn message text ... object specific fields ... yyyy-mm-dd clientXX ABC-12345-XYZ The server processes the request and sends a "response" element, along with the "reply". Example: nnn message text ... object specific elements ... yyyy-mm-dd clientXX Brunner, et al Expires August 2001 [Page 23] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ABC-12345-XYZ 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: ... object specific fields ... yyyy-mm-dd clientXX ABC-12345-XYZ 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: Brunner, et al Expires August 2001 [Page 24] Internet-Draft Extensible Registry Protocol (XRP) February 2001 nnn message text ... object specific fields ... yyyy-mm-dd clientYY ABC-12345-XYZ 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: ... object specific fields ... yyyy-mm-dd clientXX ABC-12345-XYZ The server on successfully processing the request responds with a "response" element, along with the object specific data element "query-response". Example: Brunner, et al Expires August 2001 [Page 25] Internet-Draft Extensible Registry Protocol (XRP) February 2001 nnn message text ... object specific fields ... yyyy-mm-dd clientYY ABC-12345-XYZ 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: ... object specific identifier fields ... yyyy-mm-dd clientYY ABC-12345-XYZ 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 nnn message text ... object specific fields identifying registrar identifiers ... yyyy-mm-dd clientYY ABC-12345-XYZ 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: yyyy-mm-dd clientXX ABC-12345-XYZ Brunner, et al Expires August 2001 [Page 27] Internet-Draft Extensible Registry Protocol (XRP) February 2001 yyyy-mm-dd clientXX ABC-12345-XYZ 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: yyyy-mm-dd clientXX ABC-12345-XYZ yyyy-mm-dd clientXX ABC-12345-XYZ-id> The server must respond with a success or failure reply. Example: nnn ... message text ... yyyy-mm-dd clientXX ABC-12345-XYZ-id> 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 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 or 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 attempts that can be attempted on an open connection. The XRP server MUST close an open connection if three 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 , work in progress. (To be replaced by the RFC name when this memo is published.) [EPP] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 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", 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", 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: AD-1234 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 Ayesha L. Damaraju 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: Systems Engineer 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: NeuLevel 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:
1120 Vermont Avenue Washington DC 20005 US
Line - The line element contains the address in RIPE style. Example:
123 king street, washington, dc, 20005, us
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: 1120 Vermont Avenue City - The city element contains the city or area of the contact. This is a ICANN required element. Example: Washington State - The state element contains the state or province of the contact. This is an ICANN required element. Example: DC 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: 20005 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: US 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: +1.8005551212 +1.8005551200 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: ayesha.damaraju@NeuLevel.biz 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: yyyy-mm-ddT12:00:00.0Z clientXX 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: yyyy-mm-ddT12:00:00.0Z clientXX 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: yyyy-mm-ddT12:00:00.0Z clientXX 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 yyyy-mm-dd clientXX ABC-12345-XYZ 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: none 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: field1 value1 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: ns1.neulevel.biz 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: 101.1.1.1 ::FFF:102.1.1.2 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: registrar001 yyyy-mm-ddT12:00:00.0Z Created - Element contains the reference to the registrar that created the object and date and time of object creation. Example: yyyy-mm-ddT12:00:00.0Z registrar001 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: yyyy-mm-ddT12:00:00.0Z registrar001 Authorization Identifier - This is a transaction identifier of the registrar who successfully completed the most recent transfer transaction. Example: yyyy-mm-dd registrar001 ABC-12345-XYZ 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: neulevel.biz 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 ns1.neulevel.biz 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: NY01.neulevel.net 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: registrar001 yyyy-mm-ddT12:00:00.0Z Registrant Identifier - Element contains the registrant identifier of the registrant. Example: coca-cola-000001 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: John-R-Doe-00001 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 yyyy-mm-ddT12:00:00.0Z Registration Period - The registration period element contains the date and time identifying the length of domain-names registration period. Example: 2 Restricted TLD Authorization - Element contains the authorization of the registrant, to register a domain in the restricted .tld. Example: authorized Created - Element contains the reference to the registrar that created the object and date and time of object creation. Example: yyyy-mm-ddT12:00:00.0Z clientXX Modified - Element contains the reference to the registrar that modified the object and date and time of object creation. Example: yyyy-mm-ddT12:00:00.0Z clientXX Authorization Identifier - This is a transaction identifier of the original creation transaction or the most recent successful transfer transaction. Example: yyyy-mm-dd registrat001 ABC-12345-XYZ 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: active 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: coca-cola0000001 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: coca-cola [A-Za-z]*cola|cola[0-9]* coca 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: coco-cola US nnnnnnnn nnnnnnn yyyy-mm-dd live 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: lee-f-bailey0001 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: registrar001 yyyy-mm-ddT12:00:00.0Z 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: 2 Expiration date - The expiration date element contains the date and time identifying the end of the object's registration period. Example: yyyy-mm-ddT12:00:00.0Z Created - Element contains the reference to the registrar id that created the object and date and time of object creation. Example: yyyy-mm-dd registrar0001 Modified - Element contains the reference to the registrar id that modified the object and date and time of object creation. Example: yyyy-mm-ddT12:00:00.0Z registrar001 Authorization Identifier - This is a transaction identifier of the original creation transaction or the most recent successful transfer transaction. Example: yyyy-mm-dd registrar001 ABC-12345-XYZ 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: field1 value1 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: coca-cola-000001 Registrant Name - Each object must contain only one registrant name - the businesses or entity name. Example: Coca-Cola Company 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:
1120 Vermont Avenue Washington DC US 20005
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:
...
Street - The street element contains the street line of a postal address. Example: 1120 Vermont Avenue City - The city element contains the city or area of the contact. This is an ICANN required element. Example: Washington State - The state element contains the state or province of the contact. This is a ICANN required element. Example: DC 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: 20005 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: US 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: JB-Griffen000001 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: 123456789 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: 4231 Sponsoring Registrar - Element contains the registrar identifier of the sponsoring registrar client. Example: registrar001 Created - Element contains the reference to the registrar id that created the object and date and time of object creation. Example: yyyy-mm-ddT12:00:00.0Z registrar001 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: yyyy-mm-ddT12:00:00.0Z registrar001 Authorization Identifier - This is a transaction identifier of the original creation transaction or the most recent successful transfer transaction. Example: yyyy-mm-dd registrar001 ABC-12345-XYZ 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: active 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: field1 value1 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: registrar0000001 Registrar Name - Each object must contain only one registrar name, the businesses name. Example: INWW 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:
1120 Vermont Avenue Washington DC US 20005
Line - The line element contains the address in RIPE style. Example:
...
Street - The street element contains the street line of a postal address. Example: 1120 Vermont Avenue 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: Washington State - The state element contains the state or province of the contact. This is a ICANN required element. Example: DC 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: 20005 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: US Web Address - The URL of the Registrar's homepage. Example: http://www.nuelevel.biz 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: nnnnnnnnn 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: 4231 123456 ICANN Certification ID - the Registrar certification number assigned by ICANN to each fully qualified registrar. Example: dddddddddd 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: Clive-L-Forley01 Created - Element contains the reference to the registrar that created the object and date and time of object creation. Example: yyyy-mm-ddT12:00:00.0Z registrar001 Modified - Element contains the reference to the registrar that modified the object and date and time of object creation. Example: yyyy-mm-ddT12:00:00.0Z registrar001 Authorization Identifier - This is a transaction id of the original creation transaction or the most recent transfer transaction. Example: Brunner, et al Expires August 2001 [Page 52] Internet-Draft Extensible Registry Protocol (XRP) February 2001 yyyy-mm-dd registrar001 ABC-12345-XYZ 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: active 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. John R. Doe NeuStar 1120 Vermont Ave. Washington DC 20005 US +1.8005551212 +1.8005551212 Brunner, et al Expires August 2001 [Page 54] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ayesha.damaraju@NeuLevel.com ... transaction id data ... 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: ... success reply ... J-R-Doe-0001 ... transaction id data ... 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. ... success reply ... ... transaction id data ... 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. coca-cola.biz ns1.neulevel.biz INWW-ab123456789 registrant000001 John-R-Doe001 Jim-V-Brown002 2 ... transaction id data ... 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: ... success reply ... coca-cola.biz yyyy-mm-dd ... transaction id data ... 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: coca-cola.biz yyyy-mm-dd ... notification identifier elements ... 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. Brunner, et al Expires August 2001 [Page 60] Internet-Draft Extensible Registry Protocol (XRP) February 2001 coca-cola coca-cola US nnnnnnnn nnnnnnn yyyy-mm-dd 2 Jim-N-Smith00001 L-L-Bean00002 Jane-W-Lawyer0003 registrar001 ... transaction id data ... 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: ... success reply ... nnnnnnnnn yyyy-mm-dd ... transaction id data ... Brunner, et al Expires August 2001 [Page 61] Internet-Draft Extensible Registry Protocol (XRP) February 2001 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. registrant00001 John-R-Doe00001 1120 Vermont Ave. Brunner, et al Expires August 2001 [Page 62] Internet-Draft Extensible Registry Protocol (XRP) February 2001 Washington DC 20005 US ... transaction id data ... 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: ... success reply ... registrant00001 ... transaction id data ... 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: John-R-Doe0001 ... transaction id data ... The server on completion of processing the request must respond with a success/ failure result with no data element in "response" element. Example: ... success/failure reply ... ... transaction id data ... 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. cns1.coca-cola.net ... transaction id data ... The server on completion of processing the request must respond with a success/failure result with no data element in "response" element. Example: ... success reply ... ... transaction id data ... 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: coca-cola.biz ... transaction id data ... 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: ... success/failure reply ... ... transaction id data ... Brunner, et al Expires August 2001 [Page 66] Internet-Draft Extensible Registry Protocol (XRP) February 2001 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: coca-cola0000111 ... transaction id data ... 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: ... success/failure reply ... Brunner, et al Expires August 2001 [Page 67] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ... transaction id data ... 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: registrant00001 ... transaction id data ... 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: ... success/failure reply ... Brunner, et al Expires August 2001 [Page 68] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ... transaction id data ... 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: Brunner, et al Expires August 2001 [Page 69] Internet-Draft Extensible Registry Protocol (XRP) February 2001 AD-0001 John R. Doe Coca Cola Company 144 new lane, washington, DC 20005, us +1.8005551212 +1.8005551212 ... transaction id data ... 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: ... success/failure reply ... ... transaction id data ... .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: ns1.example.tld 10.10.1.20 10.10.1.30 10.10.1.1 ... transaction id data ... 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: Brunner, et al Expires August 2001 [Page 71] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ... success/failure reply ... ... transaction id data ... 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: Brunner, et al Expires August 2001 [Page 72] Internet-Draft Extensible Registry Protocol (XRP) February 2001 example3.biz Jane-W-Smith0001 ns3.coca-cola.net ... transaction id data ... 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: ... success/failure reply ... ... transaction id data ... 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: bill-s-watson00003 Bill S. Watson ... transaction id data ... 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: ... success/failure reply ... ... transaction id data ... .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: registrant0001 John R. Doe active ... transaction id data ... 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 ... success/failure reply ... ... transaction id data ... 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. coca-cola.biz 2 Brunner, et al Expires August 2001 [Page 76] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ... transaction id data ... 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: ... success reply ... coca-cola.biz yyyy-mm-dd ... transaction id data ... 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. coca-cola000001 2 ... transaction id data ... 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: ... success reply ... coca-cola00001 yyyy-mm-dd ... transaction id data ... 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. JA-0002 ... authorization elements ... ... transaction id data ... Brunner, et al Expires August 2001 [Page 80] Internet-Draft Extensible Registry Protocol (XRP) February 2001 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: ... success reply ... JA-0002 registrar001 registrar002 pending yyyy-mm-dd yyyy-mm-dd ... transaction id data ... 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: JA-0002 CLT100 CLT200 pending yyyy-mm-dd Brunner, et al Expires August 2001 [Page 81] Internet-Draft Extensible Registry Protocol (XRP) February 2001 yyyy-mm-dd ... notification id data ... 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. ns1.coca-cola.net ... authorization elements ... Brunner, et al Expires August 2001 [Page 83] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ... transaction id data ... 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: ... success reply ... ns1.coca-cola.net registrar001 registrar002 pending yyyy-mm-dd yyyy-mm-dd ... transaction id data ... Example: Notification to losing registrar ns1.coca-cola.com registrar001 registrar002 pending Brunner, et al Expires August 2001 [Page 84] Internet-Draft Extensible Registry Protocol (XRP) February 2001 yyyy-mm-dd yyyy-mm-dd ... notification id data ... 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. coca-cola.biz ... authorization elements ... Brunner, et al Expires August 2001 [Page 86] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ... transaction id data ... 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. ... success reply ... coca-cola'biz registrar001 CLT200 pending yyyy-mm-dd yyyy-mm-dd ... transaction id data ... Example: Notification to losing registrar. example.tld registrar001 registrar002 pending yyyy-mm-dd Brunner, et al Expires August 2001 [Page 87] Internet-Draft Extensible Registry Protocol (XRP) February 2001 yyyy-mm-dd ... notification id data ... 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. JA-0002 ... authorization elements ... Brunner, et al Expires August 2001 [Page 89] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ... transaction id data ... 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: ... success reply ... JA-0002 registrar001 registrar002 pending yyyy-mm-dd yyyy-mm-dd ... transaction id data ... 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: registrant00001 registrar001 Brunner, et al Expires August 2001 [Page 90] Internet-Draft Extensible Registry Protocol (XRP) February 2001 registrar002 pending yyyy-mm-dd yyyy-mm-dd ... notification id data ... 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. AB-12345678 ... authorization elements ... ... transaction id data ... 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: ... success reply ... AD-123456 L.L. Bean CEO 1120 Vermont Ave. Washington DC 20005 US +1.8005551212 +1.8005551212 aye.damaraju@NeuLevel.com yyyy-mm-dd CLN100 Brunner, et al Expires August 2001 [Page 92] Internet-Draft Extensible Registry Protocol (XRP) February 2001 yyyy-mm-dd CLN200 yyyy-mm-ddy CLN200 yyyy-mm-dd CLN200 ... ... transaction id data ... 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. ns1.coca-cola.biz ... transaction id data ... 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: ... success reply ... ns1.example.tld yyyy-mm-dd CLN100 10.10.1.20 yyyy-mm-dd CLN200 yyyy-mm-dd CLN200 yyyy-mm-dd ... ... Brunner, et al Expires August 2001 [Page 94] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ... transaction id data ... 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. coca-cola.biz Brunner, et al Expires August 2001 [Page 95] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ... transaction id data ... 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: ... success reply ... coca-cola.biz yyyy-mm-dd CLN10 yyyy-mm-dd registrar002 yyyy-mm-dd registrar001 CNT100 CNT200 registrar000001 ns3.example3.tld ns1.example.tld active yyyy-mm-dd yyyy-mm-dd CLN400 ... Brunner, et al Expires August 2001 [Page 96] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ... transaction id data ... 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. nnnnnnnnn ... transaction id data ... 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: ... success reply ... 123456789 coca-cola.biz JBLegal0000005 LLOwner000006 LawOffice0002 coca-cola < iprop:country>us < iprop:reference>12345678 < iprop:date>yyyy-mm-dd CLN100 yyyy-mm-dd CLN200 yyyy-mm-dd yyyy-mm-dd CLN200 yyyy-mm-dd CLN500 ... ... transaction id data ... 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. coca-cola-123456 ... transaction id data ... 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: ... success reply ... coca-cola line L.L. Bean active yyyy-mm-dd CLN10 yyyy-mm-dd CLN20 yyyy-mm-dd INWW-asdfd-12345 nnnnnnnnnnnnnn ... transaction id data ... 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. INWW-asdfd-12345 ... transaction id data ... 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: ... success reply ... Brunner, et al Expires August 2001 [Page 101] Internet-Draft Extensible Registry Protocol (XRP) February 2001 INWW line David Taylor active yyyy-mm-dd INWW-asdfd-12345 yyyy-mm-dd INWW-asdfd-12345 yyyy-mm-dd INWW-asdfd-12345 nnnnnnnnnnnnn ... transaction id data ... 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: CNT100 CNT300 ... transaction id data ... 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: ... success reply ... CNT100 CNT300 Brunner, et al Expires August 2001 [Page 103] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ... transaction id data ... 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: ns1.example.tld ns2.example.tld ... transaction id data ... 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: ... success reply ... ns1.example.tld ns2.example.tld ... transaction id data ... 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: Brunner, et al Expires August 2001 [Page 105] Internet-Draft Extensible Registry Protocol (XRP) February 2001 example1.biz example2.biz ... transaction id data ... 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: ... success reply ... HP.biz example2.biz ... transaction id data ... 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: nnnnnnnnn nnnnnnnnn ... transaction id data ... 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: ... success reply ... nnnnnnnnn nnnnnnnnn ... transaction id data ... 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: coca-cola-12345 MBI-12345 ... transaction id data ... 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: ... success reply ... Brunner, et al Expires August 2001 [Page 108] Internet-Draft Extensible Registry Protocol (XRP) February 2001 coca-cola12345 MBI-12345 ... transaction id data ... 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: INWW12345 . . . Register.com1234 Brunner, et al Expires August 2001 [Page 109] Internet-Draft Extensible Registry Protocol (XRP) February 2001 ... transaction id data ... 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: ... success reply ... INWW-12345 . . . Register.com12345 ... transaction id data ... 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: ... transaction id data ... The server on successful processing the request must respond to the client with object specific registrar identifiers for all registrars in the registry. Example: ... success reply ... registrar-001 registrar-002 . . . registrar-100 ... transaction id data ... 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]