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]

 



> On Apr 25, 2017, at 14:50, Herbert Van de Sompel <hvdsomp@xxxxxxxxx> wrote:
> 
> On Tue, Apr 25, 2017 at 2:35 PM, Erik Wilde <erik.wilde@xxxxxxxx> 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





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