Subject: Re: Last Call: <draft-nottingham-rfc5988bis-05.txt> (Web Linking) to Proposed Standard

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 May 2017 21:18:32 +0200

Review of draft-nottingham-rfc5988bis-05.txt
Reviewer: Carsten Bormann
Review result: Ready with a few issues

(This is not a complete review, but in its present state might serve
to initiate discussion of items relevant to RFC 6690 and thus
draft-ietf-core-links-json.)

This specification updates RFC 5988.  The objectives for this update
are not clearly stated, but it seems to be based on experience with
RFC 5988 as well as based on advances possible with the publication of
RFC 7230.

# Major technical

T1: The draft does not take position what should happen when
serializations allowed by RFC 5988 but not by the present spec occur,
e.g.: ;type=text/plain (would now need to be ;type="text/plain").

T2: The draft says "Serialisations SHOULD coordinate their target
attributes to avoid conflicts in semantics or syntax."  To me it seems
that this gives link applications such as the one specified in RFC
6690 the go-ahead to define their own registries of target attributes.
The draft should take a position on this.

# Minor technical

T3: One of the major items of progress that this specification exhibits
is that target attributes are no longer defined by the ABNF of the
link-header serialization (which usually has two alternatives, one of
which may be forgotten) but by the ABNF of the attribute value string
itself.  ANBF tools usually can process ABNF rules, but not directly
the bare ABNF "alternations" (rule RHS) used here.  This may also make
it a bit harder to reference the ABNF from a dependent specification,
as there is no rule name for that alternation given.

# Minor editorial

E1: The abstract should probably mention that this replaces RFC 5988.

# Nits

The spec seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
does not include the phrase in its RFC 2119 key words list.  (Pet
peeve.)

s/ for indicate/ for indicating/

Grüße, Carsten

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 May 2017 11:51:57 +1000

Hi Carsten,

Thanks for the review. Responses below.

> On 3 May 2017, at 5:18 am, Carsten Bormann <[email-masked]> wrote:
> 

It assumes the general approach we take in HTTP; absent more specific requirements, recipients need to be permissive. Perhaps it would be good to link to <http://httpwg.org/specs/rfc7230.html#conformance> somewhere near the top...

> The draft should take a position on this.

Seems reasonable; will do.

> as there is no rule name for that alternation given.

This is the approach we took in RFC732x; it more accurately models how parsing and extensibility are done. 

> E1: The abstract should probably mention that this replaces RFC 5988.

I will consult the oracle (Alexey) and determine what the current preferred approach is here. 

> does not include the phrase in its RFC 2119 key words list.  (Pet

Already fixed in source.

> s/ for indicate/ for indicating/

Ack.

Thanks again!

--
Mark Nottingham   https://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 3 May 2017 08:03:11 +0200

> It assumes the general approach we take in HTTP; absent more specific requirements, recipients need to be permissive. Perhaps it would be good to link to <http://httpwg.org/specs/rfc7230.html#confo…

"Need to"?

"Unless noted otherwise, a recipient MAY attempt to recover a usable 
protocol element from an invalid construct. HTTP does not define 
specific error handling mechanisms except when they have a direct impact 
on security, since different applications of the protocol require 
different error handling strategies. For example, a Web browser might 
wish to transparently recover from a response where the Location header 
field doesn't parse according to the ABNF, whereas a systems control 
client might consider any form of error recovery to be dangerous." -- 
<https://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.2.5.p.9>

So in RFC 7230 this is truly OPTIONAL.

> ...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 May 2017 17:17:22 +1000

> On 3 May 2017, at 4:03 pm, Julian Reschke <[email-masked]> wrote:
> 
> "Need to"?
> 
> "Unless noted otherwise, a recipient MAY attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery to be dangerous." -- <https://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.2.5.p.9>
> 

That's correct. 

The attitude that we took in the HTTP specs was that there are so many possible use cases for HTTP, we can't constrain their error handling, unless it's a serious security or interop issue.

The problem is that many people want close compatibility with the error handling of the biggest HTTP clients -- browsers. We talked about defining a profile of HTTP for them; it's currently being written as Fetch (but not in the IETF).

When we do RFC723xbis, we might want to reconsider whether this was a good path to take.

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Wed, 3 May 2017 09:57:08 +0200

> e.g.: ;type=text/plain (would now need to be ;type="text/plain").

FWIW, it's allowed in RFC 5988, but there's a five year old erratum 
about it (<https://www.rfc-editor.org/errata_search.php?eid=3158>). 
Unfortunately, the status is "held for document update", not "approved".

(And yes, there's the orthogonal topic that people are not aware of 
errata, see my experiment to improve that: 
<https://greenbytes.de/tech/webdav/rfc5988.html#header.link>).

Best regards, Julian

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 4 May 2017 11:56:31 +0100

> Unfortunately, the status is "held for document update", not "approved".
The change was not purely in the "oh, this is what we meant" category, 
so I think "held for document update" is fine. The change was 
incorporated in draft-nottingham-rfc5988bis-05.txt.