Extensible Provisioning Protocol (EPP) Transport over TCP
RFC 5734
| Document | Type |
RFC - Internet Standard
(August 2009; Errata)
Obsoletes RFC 4934
Also known as STD 69
Was draft-hollenbeck-rfc4934bis (individual in app area)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5734 (Internet Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Alexey Melnikov | ||
| Send notices to | chris.newman@sun.com, Ed.Lewis@neustar.biz | ||
Network Working Group S. Hollenbeck
Request for Comments: 5734 VeriSign, Inc.
STD: 69 August 2009
Obsoletes: 4934
Category: Standards Track
Extensible Provisioning Protocol (EPP) Transport over TCP
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. This document obsoletes RFC 4934.
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) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Hollenbeck Standards Track [Page 1]
RFC 5734 EPP TCP Transport August 2009
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 ................................................6
5. Transport Considerations ........................................6
6. Internationalization Considerations .............................7
7. IANA Considerations .............................................7
8. Security Considerations .........................................7
9. TLS Usage Profile ...............................................8
10. Acknowledgements ..............................................11
11. References ....................................................11
11.1. Normative References .....................................11
11.2. Informative References ...................................12
Appendix A. Changes from RFC 4934 ................................13
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
[RFC5730]. TCP is described in [RFC0793]. This document obsoletes
RFC 4934 [RFC4934].
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
straightforward. 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 EPP server MUST return an EPP <greeting> to the client after the
TCP session has been established.
Hollenbeck Standards Track [Page 2]
RFC 5734 EPP TCP Transport August 2009
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 with a CLOSE call.
A client MAY end an EPP session by issuing a CLOSE call.
Show full document text