On Apr 26, 2017, at 8:51 AM, Carsten Bormann <cabo(_at_)tzi(_dot_)org> wrote:
On Apr 25, 2017, at 23:25, Carsten Bormann <cabo(_at_)tzi(_dot_)org> wrote:
OK, let me start typing that errata report then.
Below is a draft errata report.
Is this information correct?
No. An RFC that isn't interoperable (in this case, because it
contradicts its own normative references) is a design error.
I don't agree with the entire contents of RFC6690. The abstract alone is
enough for me to drop it in the nearest recycling bin; the design has
nothing to do with REST (an architectural style, not an architecture).
Nevertheless, the error (a non-interoperable design error) in RFC6690 is in
section 4.1. It is either a bad URI template (if the examples are correct)
or a bad description of how to process that template.
/.well-known/core{?search*}
RFC6570 requires that the above template's values be pct-encoded during
expansion, so the examples given in 4.1:
The following are examples of valid query URIs:
o ?href=/foo matches a link-value that is anchored at /foo
o ?href=/foo* matches a link-value that is anchored at a URI that
starts with /foo
o ?foo=bar matches a link-value that has a target attribute named
foo with the exact value bar
o ?foo=bar* matches a link-value that has a target attribute named
foo, the value of which starts with bar, e.g., bar or barley
o ?foo=* matches a link-value that has a target attribute named foo
are almost all wrong. They would have to be
The following are examples of valid query URIs:
o ?href=%2Ffoo matches a link-value that is anchored at /foo
o ?href=%2Ffoo%2A matches a link-value that is anchored at a URI that
starts with /foo
o ?foo=bar matches a link-value that has a target attribute named
foo with the exact value bar
o ?foo=bar%2A matches a link-value that has a target attribute named
foo, the value of which starts with bar, e.g., bar or barley
o ?foo=%2A matches a link-value that has a target attribute named foo
Alternatively, if the examples are correct, the specification needs to replace
the above URI template with a more accurate list of such templates to match
the examples:
/.well-known/core
/.well-known/core?href={+reference}
/.well-known/core?anchor={+anchor}
/.well-known/core?type={+mt}
/.well-known/core{?rel}
/.well-known/core{?rev}
/.well-known/core{?hreflang}
/.well-known/core{?media}
/.well-known/core{?title}
/.well-known/core{?rt}
/.well-known/core{?if}
/.well-known/core{?sz}
/.well-known/core{?link-extension*}
/.well-known/core?href={+reference}*
/.well-known/core?anchor={+anchor}*
/.well-known/core?type={+mt}*
/.well-known/core{?rel}*
/.well-known/core{?rev}*
/.well-known/core{?hreflang}*
/.well-known/core{?media}*
/.well-known/core{?title}*
/.well-known/core{?rt}*
/.well-known/core{?if}*
/.well-known/core{?sz}*
/.well-known/core{?link-extension*}*
... [note that this still has an ambiguity problem for href string
values that happen to end in "*"]
and then the text in 4.1 should be fixed as well:
Original Text:
Value Strings are percent-decoded
([RFC3986], Section 2.1) before matching; similarly,
Corrected Text:
Value Strings for the href, anchor, and type attributes (reserved templates)
are not percent-decoded ([RFC3986], Section 2.1) before matching;
for all other templates, Value Strings are percent-decoded only once
before matching; note that a value which originally contained a
percent-encoded triplet of "%20" would be encoded as "%2520" by a
non-reserved template expansion and restored here as "%20". Similarly,
The above would make RFC6690 consistent with its normative references.
A more sensible design would separate the response format (which is fine
as a media type) from the query syntax (which doesn't need to be limited
to link attributes anyway).
....Roy