Re: [ietf-provreg] RFC 3730 (EPP)

Joe Abley <jabley@isc.org> Tue, 30 January 2007 17:26 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwka-00042e-6b for provreg-archive@ietf.org; Tue, 30 Jan 2007 12:26:32 -0500
Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwkX-0008OX-Kx for provreg-archive@ietf.org; Tue, 30 Jan 2007 12:26:32 -0500
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id l0UHB4hQ004923 for <ietf-provreg-outgoing@nic.cafax.se>; Tue, 30 Jan 2007 18:11:04 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id l0UHB4FM007484 for ietf-provreg-outgoing; Tue, 30 Jan 2007 18:11:04 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f
Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id l0UHB382014677 for <ietf-provreg@cafax.se>; Tue, 30 Jan 2007 18:11:03 +0100 (MET)
Received: from yxu1a17.hopcount.ca ([199.212.90.17]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.64 (FreeBSD)) (envelope-from <jabley@isc.org>) id 1HBwXA-000OEL-1c; Tue, 30 Jan 2007 17:12:40 +0000
In-Reply-To: <32ec3a6d0701300845qb7a3707l2bba8eadbabb5321@mail.gmail.com>
References: <20070129183848.GB3026@afilias.info> <C1E3B5E3.2FBFB%jgould@verisign.com> <32ec3a6d0701300845qb7a3707l2bba8eadbabb5321@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <09190293-5894-43B9-9A71-DB9A64CDA052@isc.org>
Cc: ietf-provreg@cafax.se
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@isc.org>
Subject: Re: [ietf-provreg] RFC 3730 (EPP)
Date: Tue, 30 Jan 2007 12:10:56 -0500
To: Owen Borseth <owen@name.com>
X-Mailer: Apple Mail (2.752.3)
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290

On 30-Jan-2007, at 11:45, Owen Borseth wrote:

> Also, is there a way to view the RFC replacement documents that are
> pending publication? I poked around the IETF website but didn't really
> find anything.

See attached message for the individual draft names. Google knows how  
to find them by name, or you can try:

http://www.ietf.org/internet-drafts/draft-hollenbeck-epp- 
rfc3734bis-05.txt
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp- 
rfc3730bis-04.tx
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp- 
rfc3731bis-05.txt
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp- 
rfc3732bis-04.txt
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp- 
rfc3733bis-06.txt


Joe

Begin forwarded message:

> From: The IESG <iesg-secretary@ietf.org>
> Date: 29 January 2007 14:12:07 EST (CA)
> 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) 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
>