RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (1)

RFC 3986, "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
Publication Format(s) : TEXT

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: Reported (4)

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

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

Errata ID: 4547
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: siva elango ramaswamy
Date Reported: 2015-12-01

Section 5.4.2 says:

5.4.2.  Abnormal Examples

   Although the following abnormal examples are unlikely to occur in
   normal practice, all URI parsers should be capable of resolving them
   consistently.  Each example uses the same base as that above.

   Parsers must be careful in handling cases where there are more ".."
   segments in a relative-path reference than there are hierarchical
   levels in the base URI's path.  Note that the ".." syntax cannot be
   used to change the authority component of a URI.

      "../../../g"    =  "http://a/g"
      "../../../../g" =  "http://a/g"

It should say:

5.4.2.  Abnormal Examples

   Although the following abnormal examples are unlikely to occur in
   normal practice, all URI parsers should be capable of resolving them
   consistently.  Each example uses the same base as that above.

   Parsers must be careful in handling cases where there are more ".."
   segments in a relative-path reference than there are hierarchical
   levels in the base URI's path.  Note that the ".." syntax cannot be
   used to change the authority component of a URI.

      "../../../g"    =  "http://a/../g"
      "../../../../g" =  "http://a/../../g"

Notes:

The example which was taken from RFC 1808 had proper resolved URL ( 5.2 ).

As the base URL has two levels ( http://a/b/c/ ) and if the relative url's have two ".." segments then from the resolved URI both the hierarchical levels can be removed to form the resolved URL, as below:

../../g = http://a/g

and if there are more ".." segments than hierarchical level in base URI's path... then the number of ".." segments that doesn't have corresponding segments in base URI should be left as is in the resolved URI, like below

"../../../g" = "http://a/../g"

Errata ID: 4789
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Dinar Qurbanov
Date Reported: 2016-08-31

Section 5.2.3 says:

   o  If the base URI has a defined authority component and an empty
      path, then return a string consisting of "/" concatenated with the
      reference's path; otherwise,

It should say:

   o  If the base URI has a defined authority component and an empty 
      path, or if the base URI's path is ending with "/..", then return 
      a string consisting of base's path concatenated with "/" and then 
      concatenated with the reference's path; otherwise,

Notes:

this is about case when reference does not have scheme and authority and its path is not starting with "/".

Errata ID: 4942
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: r. de raat
Date Reported: 2017-02-19

Section 3.2.2. Host says:

Such a name consists of a sequence of domain labels separated by ".",
each domain label starting and ending with an alphanumeric character
and possibly also containing "-" characters.  The rightmost domain
label of a fully qualified domain name in DNS may be followed by a
single "." and should be if it is necessary to distinguish between
the complete domain name and some local domain.

   reg-name    = *( unreserved / pct-encoded / sub-delims )

If the URI scheme defines a default for host, then that default

It should say:

Such a name consists of a sequence of domain labels separated by ".",
each domain label starting and ending with an alphanumeric character
and possibly also containing "-" characters.  The rightmost domain
label of a fully qualified domain name in DNS may be followed by a
single "." and should be if it is necessary to distinguish between
the complete domain name and some local domain.

   reg-name    = *( unreserved / pct-encoded / "-" / ".")

If the URI scheme defines a default for host, then that default

Notes:

sub-delims are defined as "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" these are not characters that are allowed in host, domain or tld names, in addition the sub-delims do not sontain the "-" and "."
therefore the reg-name (fully qualified domain name) definition is incorrect

The same issue appears in "Appendix A."

Errata ID: 5428
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Kevin Layer
Date Reported: 2018-07-17

Section 4.2 says:

      relative-part = "//" authority path-abempty
                    / path-absolute
                    / path-noscheme
                    / path-empty

It should say:

      relative-part = "//" authority path-abempty
                    / path-absolute
                    / path-noscheme
		    / path-abempty    ; this was added
                    / path-empty

Notes:

As written, the ABNF excludes "/" being a valid URI. It is hard to believe that href="/" when converted to a URI, would be illegal.

Report New Errata