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

[Erik Wilde <[e-mail]>]

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:[e-mail] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |