RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (3)

RFC 5730, "Extensible Provisioning Protocol (EPP)", August 2009

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 1878
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2009-09-11
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-11

Throughout the document, when it says:

a)  [[ global ]]

   RFC 4646

b)  [[ global ]]

   [RFC4646]

c)  [[ Section 9.1 ]]

   [RFC4646]  Phillips, A. and M. Davis, "Tags for Identifying
              Languages", BCP 47, RFC 4646, September 2006.

It should say:

a)

   RFC 5646

b)

   [RFC5646]

c)

   [RFC5646]  Phillips, A., Ed., and M. Davis, Ed., "Tags for
              Identifying Languages", BCP 47, RFC 5646,
              September 2009.

Notes:

Unfortunately, RFC 5730 has been published just three days before
RFC 5646, which has obsoleted RFC 4646 and performed a significant
revision of the Language Tag syntax and IANA registry.

I hope that it was not intended to tie EPP to the old Language Tag
architecture. The new one is much better aligned with ISO, the UN
statistics department, and Unicode, and will be generally adopted.

The intent of this Errata Note is to give the author and the IESG
an opportunity to confirm that EPP shall not be tied to the old
LangTag architecture and the now obsolete RFC 4646.

Errata ID: 1846
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Scott Hollenbeck
Date Reported: 2009-09-02
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-06

Section 2.4 says:

o  An OPTIONAL <svcExtension> element that contains one or more
   <extURI> elements that contain namespace URIs representing
   object extensions supported by the server.

o  A <dcp> (data collection policy) element that contains child

It should say:

  o  An OPTIONAL <svcExtension> element that contains one or more
     <extURI> elements that contain namespace URIs representing
     object extensions supported by the server.

-  A <dcp> (data collection policy) element that contains child

Notes:

The description of the <dcp> element, which extends to the description of the OPTIONAL <expiry> element, is indented one level too deep. The <dcp> element should be described at the same level as the <svcMenu> element instead of being indented as if it were a child of the <svcMenu> element.

Errata ID: 1877
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2009-09-11
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-11

Section 2.4, pg.8 says:

   -  An <svDate> element that contains the server's current date and
|     time in Universal Coordinated Time (UTC).

It should say:

   -  An <svDate> element that contains the server's current date and
|     time in Coordinated Universal Time (UTC).

Notes:

Rationale: Use of established, official terminology.

Note: There are other variants of "Universal Time" (mostly of
historical interest now), and hence, the term initially
had been written as "Universal Time, Coordinated", giving
rise to the acronym "UTC" that parallels the precursor "UT1".

Status: Held for Document Update (1)

RFC 5730, "Extensible Provisioning Protocol (EPP)", August 2009

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 1876
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2009-09-11
Held for Document Update by: Alexey Melnikov
Date Held: 2009-09-11

Throughout the document, when it says:

a)  Section 1, 2nd paragraph:

|  EPP content is identified by MIME media type application/epp+xml.
   Registration information for this media type is included in an
   appendix to this document.

b)  Section 6, last paragraph:

   A MIME media type registration template is included in Appendix B.

c)  Appendix B, first two items

   MIME media type name: application

   MIME subtype name: epp+xml

It should say:

a)

|  EPP content is identified by the media type application/epp+xml.
   Registration information for this media type is included in an
   appendix to this document.

b) 

   A media type registration template is included in Appendix B.

c)

   Media type name: application

   Subtype name: epp+xm

Notes:

Rationale:

As explained in Section 1 od BCP 13, RFC 4288, the concept of a
"Media Type" formalized for the first time in the MIME RFCs has gained
significance far beyond the narrow area of Internet Mail. Therefore,
the related terms should not be used in the colloquial form including
"MIME" that did not even appear in RFC 2045; in particular, the
colloquial term "MIME Type" (or "MIME Media Type") should generally
be avoided in favor of the (original and) more appropriate bare
"Media Type".

I'd expect that a Full Standard RFC follows the established
terminology of the IETF, and that it uses the revised Media Type
registration boilerplate published in RFC 4288 (December 2005),
even when it merely updates/re-parents an existing registration.

EPP has not even a standardized transport binding to Internet Email.
Hence, tying the terminology to MIME seems even more inappropriate
here.

Alexey Melnikov: I can't see anybody be confused by use of MIME type where use of "media type" would be slightly more appropriate.

Report New Errata



Advanced Search