errata logo graphic

Found 7 records.

Status: Verified (1)

RFC3986, "Uniform Resource Identifier (URI): Generic Syntax", January 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2525

Status: Verified
Type: Technical

Reported By: Christopher Yeleighton
Date Reported: 2010-09-17
Verifier Name: Alexey Melnikov
Date Verified: 2010-11-12

Section 3.1 says:

Advice for designers of new URI schemes can be found in [RFC2718].

It should say:

Advice for designers of new URI schemes can be found in [RFC4395].

Notes:

The document [RFC2718] is for designers of designers of new URL schemes only. It has been obsoleted by [RFC4395] that covers all URI schemes.

[RFC4395]
T. Hansen, T. Hardie, T. and L. Masinter,
"Guidelines and Registration Procedures for New URI Schemes",
RFC 4395, February 2006.


Status: Held for Document Update (3)

RFC3986, "Uniform Resource Identifier (URI): Generic Syntax", January 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2624

Status: Held for Document Update
Type: Technical

Reported By: Peter Saint-Andre
Date Reported: 2010-11-11
Held for Document Update by: Peter Saint-Andre
Date Held: 2011-03-30

Section Appendix B says:

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

It should say:

/^(([^:\/?#]+):)?(\/\/([^\/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?/

Notes:

This is a copy of Erratum #1933, reported against RFC 2396.


Errata ID: 2033

Status: Held for Document Update
Type: Editorial

Reported By: Tanaka Akira
Date Reported: 2010-02-05
Held for Document Update by: Alexey Melnikov

Section 3.3. says:

      path-empty    = 0<pchar>

It should say:

      path-empty    = ""

Notes:

According to ABNF, 0<pchar> is interpreted as
zero repeatation of the prose-val: pchar.

However pchar is an non-terminal.
So I think the production should be follows:
path-empty = 0pchar

However this production means a empty string.
So
path-empty = ""
is more clear.

Appendix A. has also the same production.


Errata ID: 2933

Status: Held for Document Update
Type: Editorial

Reported By: Bjoern Hoehrmann
Date Reported: 2011-08-13
Held for Document Update by: Peter Saint-Andre
Date Held: 2012-02-27

Section 5.2.2. says:

T.path = merge(Base.path, R.path);

It should say:

T.path = merge(Base, R);

Notes:

In 5.2.3. the "If the base URI has a defined authority component" condition requires knowing the authority component, so passing just the path component is misleading.

During discussion of this issue, Roy Fielding noted: "No, this is not an error in the algorithm. The algorithm is just saying that you need to merge the two paths. The two paths are not parameters to a function, nor is the merge procedure limited to those two parameters." Saving this report as "Hold For Document Update" so that future implementers do not experience the same confusion.


Status: Rejected (3)

RFC3986, "Uniform Resource Identifier (URI): Generic Syntax", January 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3330

Status: Rejected
Type: Technical

Reported By: David Sheets
Date Reported: 2012-08-29
Rejected by: Barry Leiba
Date Rejected: 2012-09-04

Section Appendix A says:

fragment      = *( pchar / "/" / "?" )

It should say:

fragment      = *( pchar / "/" / "?" / "#" )

Notes:

Appendix B's regex doesn't fail with this correction. Additionally, this gives freedom to media type designers. Specifically, the ((path?),(query?),(fragment?)) subsyntax could be reused in hypermedia type design as the "?" delimiter transitions path => query and the "#" delimiter transitions query => fragment. It also follows the pattern:
path = *( pchar / "/" )
query = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" / "#" )
--VERIFIER NOTES--
This is something that should be looked at further, but it is not an error in the spec and is unlikely to be a direct change we'd make in a revision of the spec.

Some applications at the time the specification was written parsed the fragment from left to right, and others parsed from right to left, which means they would get different results if "#" were allowed inside of a fragment. That's why it was not allowed in the ABNF. It's possible that situation has improved in the years since, but it would be difficult to test so many implementations. Deciding the right way to handle this goes beyond what can be handled by an erratum.


Errata ID: 1783

Status: Rejected
Type: Editorial

Reported By: Christopher Yeleighton
Date Reported: 2009-05-15
Rejected by: Peter Saint-Andre
Date Rejected: 2010-09-15

Section 3.1. says:

Advice for designers of new URI schemes can be found in [RFC2718].

It should say:

Advice for designers of new URL schemes can be found in [RFC2718].

Notes:

[RFC2718] does not contain advice for designers of new URN schemes; it is applies to URL schemes only and it is titled accordingly.
The information as published is misleading.
--VERIFIER NOTES--
Given that RFC 4395 ("Guidelines and Registration Procedures for New URI Schemes") obsoletes the referenced RFC 2718 ("Guidelines for new URL Schemes"), this erratum is best considered in error.


Errata ID: 2717

Status: Rejected
Type: Editorial

Reported By: Winfred Qin
Date Reported: 2011-02-14
Rejected by: Peter Saint-Andre
Date Rejected: 2011-05-16

Section 3 says:

      hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty

It should say:

      hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-noscheme
                  / path-rootless
                  / path-empty

Notes:

There are four ABNF rules for path, but the following words says:

'These restrictions result in five different ABNF rules for a path (Section 3.3)'

And in section 3.3, there are five rules.
--VERIFIER NOTES--
PSA: There is no error here, because the hierarchical part excludes
paths that are not preceded by "//", whereas the path rule includes
paths that are not preceded by "//" (thus five rules for "path" but
only four rules for "hier-part").


Report New Errata