To:
Owen Borseth <owen@name.com>
Cc:
ietf-provreg@cafax.se
From:
Joe Abley <jabley@isc.org>
Date:
Tue, 30 Jan 2007 12:10:56 -0500
In-Reply-To:
<32ec3a6d0701300845qb7a3707l2bba8eadbabb5321@mail.gmail.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] RFC 3730 (EPP)
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 >