Skip to main content

Last Call Review of draft-ietf-core-links-json-07
review-ietf-core-links-json-07-artart-lc-nottingham-2017-04-10-00

Request Review of draft-ietf-core-links-json
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2017-04-21
Requested 2017-04-07
Requested by Alexey Melnikov
Authors Kepeng Li , Akbar Rahman , Carsten Bormann
I-D last updated 2017-04-10
Completed reviews Artart Last Call review of -07 by Mark Nottingham (diff)
Secdir Last Call review of -07 by Paul Wouters (diff)
Genart Last Call review of -07 by Elwyn B. Davies (diff)
Assignment Reviewer Mark Nottingham
State Completed
Request Last Call review on draft-ietf-core-links-json by ART Area Review Team Assigned
Reviewed revision 07 (document currently at 10)
Result Ready w/issues
Completed 2017-04-10
review-ietf-core-links-json-07-artart-lc-nottingham-2017-04-10-00
This specification is a relatively straightforward mapping of the format
described in RFC6690 (itself a serialisation of RFC5988bis links) into JSON and
CBOR. I don't have deep knowledge of CBOR, but given the editorship of the
document, I trust it's seen adequate review in that regard.

The only potential issue is how this is achieved. Rather than defining two new
serialisations of RFC5988bis links (into JSON and CBOR), it describes how to
re-serialise RFC6690 documents into JSON and CBOR. This means that any
constraints upon RFC6690 documents are also mirrored into these formats; e.g.,
the target IRI is constrained to be a URI in 6690, and therefore can also only
be a URI in JSON and CBOR, despite these formats' ability to easily convey
non-ASCII content.

In other words, the specification currently defines these link formats in terms
of the Link header (as defined in section 5 of RFC5988) -- along with all of
the foibles of HTTP header syntax -- rather than their abstract model (defined
in Section 3).

Whether or not this is a problem depends on what's desired; if 6690 is seen as
effectively a profile of 5988, then it makes sense to express it in those
terms. If the full range of links capable of being expressed in 5988 is
desired, creating new serialisations of 5988 links (without a hop through 6690)
is preferable.

If the current approach is kept, it'd be nice to clarify this situation a bit
in the Introduction.