The IESG has approved the following documents: - 'Extensible Provisioning Protocol (EPP) Transport Over TCP ' <draft-hollenbeck-epp-rfc3734bis-05.txt> as a Draft Standard - 'Extensible Provisioning Protocol (EPP) ' <draft-hollenbeck-epp-rfc3730bis-04.txt> as a Draft Standard - 'Extensible Provisioning Protocol (EPP) Domain Name Mapping ' <draft-hollenbeck-epp-rfc3731bis-05.txt> as a Draft Standard - 'Extensible Provisioning Protocol (EPP) Host Mapping ' <draft-hollenbeck-epp-rfc3732bis-04.txt> as a Draft Standard - 'Extensible Provisioning Protocol (EPP) Contact Mapping ' <draft-hollenbeck-epp-rfc3733bis-06.txt> as a Draft Standard These documents have been reviewed in the IETF but are not the products of an IETF Working Group. The IESG contact person is Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-rfc3730bis-04.txt 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. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
