[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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
>





Home | Date list | Subject list