Hi Carsten,
Thanks for the review. Responses below.
On 3 May 2017, at 5:18 am, Carsten Bormann <cabo(_at_)tzi(_dot_)org> 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/