Protocol Action: 'Extensible Provisioning Protocol (EPP)' to Draft Standard
The IESG <iesg-secretary@ietf.org> Mon, 29 January 2007 19:12 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbvm-0001vA-6D; Mon, 29 Jan 2007 14:12:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbvj-0001uV-W5 for ietf-announce@ietf.org; Mon, 29 Jan 2007 14:12:40 -0500
Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBbvh-0003DT-M4 for ietf-announce@ietf.org; Mon, 29 Jan 2007 14:12:39 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 79AF92ACA4; Mon, 29 Jan 2007 19:12:07 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HBbvD-0003tz-7u; Mon, 29 Jan 2007 14:12:07 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1HBbvD-0003tz-7u@stiedprstage1.ietf.org>
Date: Mon, 29 Jan 2007 14:12:07 -0500
X-Spam-Score: -2.8 (--)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Extensible Provisioning Protocol (EPP)' to Draft Standard
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Errors-To: ietf-announce-bounces@ietf.org
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 mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce