Hi Carsten, Thanks for the review. Responses below. > On 3 May 2017, at 5:18 am, Carsten Bormann <cabo@xxxxxxx> 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/