Technical Summary
This set of documents advances EPP to draft standard and documents the
implementations used to make that advancement.
Working Group Summary
This is the product of an individual submitter, though the working group
mailing list of PROVREG (now closed) was used to collect implementation
reports and discuss the implementations.
Protocol Quality
This document was reviewed for the IESG by Ted Hardie.This ballot
includes a down reference to RFC 2246 which was called out in the last
call as required by RFC 3967. Because the dependency between EPP and TLS
follows a well-defined modular interface, the IESG has chosen to allow
this down reference under RFC 3967.
Note to RFC Editor
In Section 2.3, draft-hollenbeck-epp-rfc3730bis-04
OLD:
"An EPP client MAY request a <greeting> from an EPP server at any time by
sending a <hello> to a server."
NEW:
"An EPP client MAY request a <greeting> from an EPP server at any time
between a successful <login> command and a <logout> command by sending a
<hello> to a server."
In draft-hollenbeck-epp-rfc3734bis, Section 4:
OLD:
The data field of the TCP header MUST contain an EPP data unit. The
EPP data unit contains two fields: a 32-bit header that describes the
total length of the data unit, and the EPP XML instance. The length
of the EPP XML instance is determined by subtracting four octets from
the total length of the data unit. A receiver must successfully read
that many octets to retrieve the complete EPP XML instance before
processing the EPP message.
NEW:
The EPP data unit contains two fields: a 32-bit header that describes
the total length of the data unit, and the EPP XML instance. The
length of the EPP XML instance is determined by subtracting four
octets from the total length of the data unit. A receiver must
successfully read that many octets to retrieve the complete EPP XML
instance before processing the EPP message.