hello.
just adding my voice here and since i am collaborating with herbert on
this, my position is relatively clear.
On 2017-04-18 14:47, Herbert Van de Sompel wrote:
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.
very much agreed, it would be great to have a generic way of serializing
links as standalone resources (ideally in a way that is able to preserve
their context, so that relative URIs are well-defined). my concern is
that RFC 6690 was not intended to do this (it adds constraints to RFC
5988), and thus draft-ietf-core-links-json has the same limitations.
to be fair, the draft does not intend to define a general-purpose web
link serialization, it is simply intended as a serialization of the
specialized model defined in RFC 6690.
i am not sure what the best way forward is. the representations defined
in this draft are tantalizingly close to general-purpose serializations
of RFC 5988. but the draft is clearly intended to be (one more) building
block in the "CoRE-only" universe. two suggestions:
- add language that makes it clear that because of the limitations of
RFC 6690, the media types in this draft should not be considered as
general-purpose serializations of web links.
- consider adding a serialization of web links to RFC 5988bis. this
would address the problem of how to serialize web links outside of the
HTTP link header field.
cheers,
dret.
--
erik wilde | mailto:erik(_dot_)wilde(_at_)dret(_dot_)net |
| http://dret.net/netdret |
| http://twitter.com/dret |