RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

RFC 3915, "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", September 2004

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 8305
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gavin Brown
Date Reported: 2025-02-21
Verifier Name: Orie Steele
Date Verified: 2025-03-28

Section 4.1.2 says: 

When an <info> command has been processed successfully, the EPP
<resData> element MUST contain child elements as described in [2]. In
addition, the EPP <extension> element MUST contain a child
<rgp:infData> element that identifies the registry grace period
namespace and the location of the registry grace period schema.  The
<rgp:infData> element contains a single <rgp:rgpStatus> element that
contains a single attribute "s" whose value describes the current
grace period status of the domain.  Possible status values are
described in section Section 3.1.

It should say:

When an <info> command has been processed successfully, the EPP
<resData> element MUST contain child elements as described in [2]. In
addition, the EPP <extension> element MUST contain a child
<rgp:infData> element that identifies the registry grace period
namespace and the location of the registry grace period schema.  The
<rgp:infData> element contains one or more <rgp:rgpStatus> elements that
each contain a single attribute "s" whose value describes one of the the
current grace period status of the domain.  Possible status values are
described in section Section 3.1.

Notes:

The XML schema in Section 5 sets the maximum number of occurrences of the <rgpStatus> element to be unbounded, meaning that any number of elements may be present.

This correction updates the text to reflect the XML schema.

Status: Rejected (1)

RFC 3915, "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", September 2004

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 8306
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Gavin Brown
Date Reported: 2025-02-21
Rejected by: Orie Steele
Date Rejected: 2025-03-28

Section 4.2.5 says: 

When an extended <update> command without a restore report has been
processed successfully, the EPP response is as described in the EPP
domain mapping [2] except that an extension element is added to
describe grace period status as a result of processing the <update>
command.  The extension element contains a single child element
(<upData>) that itself contains a single child element (<rgpStatus>)
that contains a single attribute "s" whose value MUST be
"pendingRestore" if the <restore> request has been accepted.

It should say:

When an extended <update> command without a restore report has been
processed successfully, the EPP response is as described in the EPP
domain mapping [2] except that an extension element is added to
describe grace period status as a result of processing the <update>
command.  The extension element contains a single child element
(<upData>) that itself contains one more <rgpStatus> child elements,
each of which contain a single attribute "s" whose value describes
one of the current grace period status of the domain. Possible status
values are described in section Section 3.1. At least one <rgpStatus>
element MUST have an "s" attribute with a value of "pendingRestore"
if the <restore> request has been accepted.

Notes:

The XML schema in Section 5 sets the maximum number of occurrences of the <rgpStatus> element to be unbounded, meaning that any number of elements may be present.

This correction updates the text to reflect the XML schema.
--VERIFIER NOTES--
Offlist discussions concluded that the <update> response could only contain a single <rgpStatus> element.

Report New Errata



Advanced Search