hi Mark, Carsten,
Sorry to be a bit late to the game.
Two things:
1. I would be very interested in documents serialized according to
application/link-format+json as described in the I-D, especially in the
context of an I-D Erik Wilde and I are authoring regarding Link Sets, see
https://datatracker.ietf.org/doc/draft-wilde-linkset-link-rel/
2. Regarding Mark's comment "This means that any constraints upon RFC6690
documents are also
mirrored into these formats": Mark mentions IRIs as a concern. I am also
concerned about the rules for interpretation of (the Context IRI of) links
as described in Section 2.1 of 6690 (
https://tools.ietf.org/html/rfc6690#section-2.1). It seems to me that these
also introduce constraints that go beyond 5988. I may be mistaken with that
regard because I have never fully understood that section of 6690 (i.e. the
use of "base URI", "origin", "Context URI"). But, when compared to 5988,
the section comes across as imposing constraints that are intended to allow
the straightforward use of relative URIs in constrained environments as a
means to decrease the payload. If my interpretation is correct, then I
would very much favor spec-ing the json link format in terms of 5988 rather
than 6690.
Cheers
Herbert Van de Sompel
On Tue, Apr 11, 2017 at 9:33 AM, Carsten Bormann <cabo(_at_)tzi(_dot_)org>
wrote:
Hi Mark,
thank you a lot for another thoughtful review.
I don’t have an opinion yet on what we should do here, so I’ll supply some
more background first.
The present spec is first and foremost intended to round-trip with RFC
6690, which is indeed stuck a bit on HTTP Link header field syntax.
However, the way this is used in practice is not meant to inherit the
complexities of HTTP header field coding. E.g., for CoRE Resource
Directory and its DNS-SD compatibility, we want to represent a DNS-SD
instance identifier (which is UTF-8) as a link attribute. This is not a
problem in JSON or CBOR, but also not in the way RFC 6690 is being used,
i.e. as a UTF-8 based format.
I haven’t checked yet what 5988bis brings to the table and how to track
this in 6690 or possibly a 6690bis. There is no point in Big Web and Thing
Web diverging here, so we should follow the lead. But maybe that would
touch both 6690 and the present document once 5988bis is done.
More importantly, we haven’t really put a lot of thinking into IRI
support. The CoAP data type “string” which is used for URI components such
as Uri-Path is UTF-8, so we could embrace them by extending the rules in
section 6 of RFC 7252 to cover IRIs. I’m sure that, in practice, CoAP
implementations already do this — it is not distinguishable in the CoAP
packet whether the (decomposed) CoAP Uri components have been derived from
URIs or IRIs. But the metadata formats (6690 and its JSON/CBOR
representations; various other JSON and CBOR based formats, e.g. from OCF)
are still based on RFC 3986 URIs, except where they also use the CoAP
decomposed form (e.g., CORAL).
While this is outside the scope of the CoRE WG, I personally would like to
explore how link-format+cbor/+json could be useful for the Big Web. If
embracing IRIs there is all we need to make this happen, maybe that can be
added with a warning that IRIs have to be converted back to URIs for 6690
link-format.
Grüße, Carsten
On Apr 11, 2017, at 05:49, Mark Nottingham <mnot(_at_)mnot(_dot_)net> wrote:
Reviewer: Mark Nottingham
Review result: Ready with Issues
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.
_______________________________________________
art mailing list
art(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/art
_______________________________________________
art mailing list
art(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/art
--
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
http://orcid.org/0000-0002-0715-6126
==