Extensible Provisioning Protocol (EPP) Transport Over TCP
RFC 3734

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

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 EPP