Extensible Provisioning Protocol (EPP) Domain Name Mapping
draft-hollenbeck-epp-rfc3731bis-05

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Extensible Provisioning Protocol 
         (EPP)' to Draft Standard 

The IESG has approved the following documents:

- 'Extensible Provisioning Protocol (EPP) '
   <draft-hollenbeck-epp-rfc3730bis-05.txt> as a Draft Standard
- 'Extensible Provisioning Protocol (EPP) Domain Name Mapping '
   <draft-hollenbeck-epp-rfc3731bis-06.txt> as a Draft Standard
- 'Extensible Provisioning Protocol (EPP) Host Mapping '
   <draft-hollenbeck-epp-rfc3732bis-05.txt> as a Draft Standard
- 'Extensible Provisioning Protocol (EPP) Contact Mapping '
   <draft-hollenbeck-epp-rfc3733bis-07.txt> as a Draft Standard
- 'Extensible Provisioning Protocol (EPP) Transport Over TCP '
   <draft-hollenbeck-epp-rfc3734bis-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-05.txt

Ballot Text

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.

RFC Editor Note