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@xxxxxxx> 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@xxxxxxxx> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/art
>
_______________________________________________
art mailing list
art@xxxxxxxx
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
==
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
http://orcid.org/0000-0002-0715-6126
==