Re: [art] Artart last call review of draft-ietf-core-links-json-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.wilde@xxxxxxxx |
           | http://dret.net/netdret    |
           | http://twitter.com/dret    |




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]