Re: [core] [art] Artart last call review of draft-ietf-core-links-json-07

["Roy T. Fielding" <[e-mail]>]

> On Apr 26, 2017, at 8:51 AM, Carsten Bormann <[e-mail]> wrote:
> 
> On Apr 25, 2017, at 23:25, Carsten Bormann <[e-mail]> 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