Movatterモバイル変換


[0]ホーム

URL:


Search RFCs

Advanced Search

RFC Editor

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]. Inaddition, the EPP <extension> element MUST contain a child<rgp:infData> element that identifies the registry grace periodnamespace and the location of the registry grace period schema.  The<rgp:infData> element contains a single <rgp:rgpStatus> element thatcontains a single attribute "s" whose value describes the currentgrace period status of the domain.  Possible status values aredescribed 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]. Inaddition, the EPP <extension> element MUST contain a child<rgp:infData> element that identifies the registry grace periodnamespace and the location of the registry grace period schema.  The<rgp:infData> element contains one or more <rgp:rgpStatus> elements thateach contain a single attribute "s" whose value describes one of the thecurrent grace period status of the domain.  Possible status values aredescribed 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 beenprocessed successfully, the EPP response is as described in the EPPdomain mapping [2] except that an extension element is added todescribe 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 beenprocessed successfully, the EPP response is as described in the EPPdomain mapping [2] except that an extension element is added todescribe 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 describesone of the current grace period status of the domain. Possible statusvalues 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



IABIANAIETFIRTFISEISOCIETF Trust
ReportsPrivacy StatementSite MapContact Us

Advanced Search

[8]ページ先頭

©2009-2026 Movatter.jp