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

[Mark Nottingham <[e-mail]>]

Hi Carsten,

Thanks for the review. Responses below.

> On 3 May 2017, at 5:18 am, Carsten Bormann <[e-mail]> wrote:
> 
> 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").

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...


> 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.

Seems reasonable; will do.


> # 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.

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


> # Minor editorial
> 
> 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. 


> # 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.)

Already fixed in source.


> s/ for indicate/ for indicating/

Ack.

Thanks again!


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