ietf
[Top] [All Lists]

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

2017-04-25 08:08:34

On Apr 25, 2017, at 14:50, Herbert Van de Sompel 
<hvdsomp(_at_)gmail(_dot_)com> wrote:

On Tue, Apr 25, 2017 at 2:35 PM, Erik Wilde 
<erik(_dot_)wilde(_at_)dret(_dot_)net> wrote:
hello carsten.

On 2017-04-24 14:55, Carsten Bormann wrote:
it would be better to make sure that serializations of web links actually can 
represent web links and not just some of the information that they convey. 
that train may have left the station with RFC 6690, but maybe for the JSON 
and CBOR serializations that can be changed.
Right.  Can you be more specific what you would want to see here?

two possibilities:

- to do things well it would be better to have web link serializations that 
cover *all* of RFC 5988 (bis). that's a hard thing to do and will take a 
while.


As Erik previously indicated, it would be great if this could be done as part 
of RFC5988bis.

Yes.

But covering all of RFC 5988 is mainly hard because of the vagaries of HTTP 
header field encoding.
We don’t have that problem in RFC 6690, so it is easy to have RFC 6690 and 
links-json as a proper subset if we want to.

 - for the RFC 6690-based variants under consideration right now, it would be 
helpful to very explicitly point out that they are *not* general-purpose 
serializations of web links, but instead inherit the limitations of the 
underlying spec.


That would, indeed, be good. But, in case RFC5988bis would spec a (JSON) 
serialization, it seems to me that it would be rather helpful for the CORE 
community if the RFC 6690 JSON serialization would be based on it. 

I would hope so, but remember that links-json is already out there.

The RFC 6690 JSON serialization is pretty much a no-brainer, and there are no 
obvious ways to do things very different (well, you could choose a different 
name for “href”, but that would not be very bright).   CBOR adds a few bike 
sheds, but these can be painted in the same color with little effort.

If a superset RFC 5988 JSON serialization deviates from this (i.e., is not a 
proper superset), I think this would require some willful effort.
(I’m happy to be proven wrong; that’s why I was asking if any specifics are 
known here already.)

Grüße, Carsten