Extensible Provisioning Protocol (EPP) Transport Over TCP
RFC 3734
Document | Type |
RFC - Proposed Standard
(March 2004; No errata)
Obsoleted by RFC 4934
|
|
---|---|---|---|
Author | Scott Hollenbeck | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3734 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ted Hardie | ||
Send notices to | (None) |
Network Working Group S. Hollenbeck Request for Comments: 3734 VeriSign, Inc. Category: Standards Track March 2004 Extensible Provisioning Protocol (EPP) Transport Over TCP Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions Used In This Document. . . . . . . . . . . . 2 2. Session Management . . . . . . . . . . . . . . . . . . . . . . 2 3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . . 3 4. Data Unit Format . . . . . . . . . . . . . . . . . . . . . . . 5 5. Transport Considerations . . . . . . . . . . . . . . . . . . . 5 6. Internationalization Considerations. . . . . . . . . . . . . . 6 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References. . . . . . . . . . . . . . . . . . 7 10.2. Informative References. . . . . . . . . . . . . . . . . 8 11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 Hollenbeck Standards Track [Page 1] RFC 3734 EPP TCP Transport March 2004 1. Introduction This document describes how the Extensible Provisioning Protocol (EPP) is mapped onto a single client-server TCP connection. Security services beyond those defined in EPP are provided by the Transport Layer Security (TLS) Protocol [RFC2246]. EPP is described in [RFC3730]. TCP is described in [RFC793]. 1.1. 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]. 2. Session Management Mapping EPP session management facilities onto the TCP service is straight forward. An EPP session first requires creation of a TCP connection between two peers, one that initiates the connection request and one that responds to the connection request. The initiating peer is called the "client", and the responding peer is called the "server". An EPP server MUST listen for TCP connection requests on a standard TCP port assigned by IANA. The client MUST issue an active OPEN call, specifying the TCP port number on which the server is listening for EPP connection attempts. The server MUST respond with a passive OPEN call, which the client MUST acknowledge to establish the connection. The EPP server MUST return an EPP <greeting> to the client after the TCP session has been established. An EPP session is normally ended by the client issuing an EPP <logout> command. A server receiving an EPP <logout> command MUST end the EPP session and close the TCP connection through an active CLOSE call. The client MUST respond with a passive CLOSE call. A client MAY end an EPP session by issuing an active CLOSE call. A server SHOULD respond with a passive CLOSE call. A server MAY limit the life span of an established TCP connection. EPP sessions that are inactive for more than a server-defined period MAY be ended by a server issuing an active CLOSE call. A server MAY also close TCP connections that have been open and active for longer than a server-defined period. Peers SHOULD respond to an active CLOSE call with a passive CLOSE call. The closing peer MAY issue an ABORT call if the responding peer does not respond to the active CLOSE call. Hollenbeck Standards Track [Page 2] RFC 3734 EPP TCP Transport March 2004 3. Message Exchange With the exception of the EPP server greeting, EPP messages are initiated by the EPP client in the form of EPP commands. An EPPShow full document text