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