Re: [core] Report on first Resource Directory plugtest

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Carsten Bormann <[e-mail]>
> Sent: Friday, April 13, 2018 6:01 AM
> To: "Christian M. Amsüss" <[e-mail]>
> Cc: peter van der Stok <[e-mail]>; Jim Schaad
> <[e-mail]>; Core WG mailing list <[e-mail]>
> Subject: Re: [core] Report on first Resource Directory plugtest
> 
> On Apr 13, 2018, at 13:03, Christian M. Amsüss <[e-mail]>
> wrote:
> >
> > Hello Peter, Carsten,
> > hello Jim (responding cross-thread to the Location-Query point),
> >
> >>> Ceterum censeo RFC6690 esse revidendam.
> >>
> >> Well, the general feeling was that instead of going for a 6690bis, we
> >> maybe want to let the link-format just fade out (In favor of
> >> links-json/-cbor).
> >
> > link-json/-cbor is not helping with the issue of [1].
> 
> No; the intention would be to develop links-json/-cbor in such a way that
> itself doesn’t have the issue.
> (I.e., decouple it a bit from the idiosyncrasies of RFC 6690.)
> 
> > Whoever receives a link-format+json document and wants to follow a
> > link given there needs to take the href and the anchor, and look up in
> > RFC6690 Section 2.1, which is the very root of my misgivings about the
> > situation.
> 
> Not if we don’t define it that way.
> 
> Generally, the idea is that an RD consumer is not affected by this (we always
> use absolute URIs), and an RD submitter  would be affected only if it uses
> legacy link-format.
> 
> > [1]:
> >
> https://mailarchive.ietf.org/arch/msg/core/LS0ccxtH8nEVuy73iZoRkkfBpmw
> >
> >>> * Production and parsing of invalid RFC6690 (which link attributes
> >>>   need to be quoted,
> >>
> >> Right.  I think we really should be following RFC 8288 here and
> >> asking implementations to be robust to the misguided “this attribute
> >> needs to be quoted” decisions we made in RFC 6690.
> >>
> >> Maybe we can put a few updates to 6690 in links-json?
> >
> > I don't know from a procedural PoV -- can we? And how far can that go?
> 
> In updating a document, we can go as far as we want.
> But of course we want to be reasonable and make sure we don’t invalidate
> existing implementations of link-format.
> Instead of doing a link-format v2, the idea is live with v1 and move over to
> JSON/CBOR.

Doing this is going to make my life as an implementor really a mess.  I will no longer be able to simply have a single representation of the internal data structure and do the parsing as serialization to a common format.  I am now going to need to remember what the original representation was and do the serializations differently based on that value.   In addition to this, all of my internal calls to setup the link format to begin with need to have this distinction so that things get serialized correctly.   What would this mean for serializing out /.well-known/core - are the meanings different if one serializes to cbor as opposed to link-format?   I think this would make more problems that it would solve.

Jim

> 
> Grüße, Carsten
> 
> (*) the usual mistake of trying to describe operations on the data model level
> in terms of operations on the serialization level.  That got fixed in RFC 8288,
> but not in RFC 6570 templates.  In the end, I believe we’ll be much better off
> with a CORAL-like representations of URIs…