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),
> >
> > (removing DNS-SD from the thread because I do not expect those topics
> > to be particularly interesting there)
> >
> > On Fri, Apr 13, 2018 at 09:04:33AM +0200, peter van der Stok wrote:
> >> to be filled into the github, I hope.
> >
> > yes, as I am finally going thorough the existing issues and changes.
> >
> > On Fri, Apr 13, 2018 at 09:14:27AM +0200, Carsten Bormann wrote:
> >>> * Can there be a Location-Query option in a registration response?
> >>>   (Probably not, we just didn’t say that.)
> >>
> >> Why not?
> >> (Sorry, I missed out on responding to Jim’s earlier message on this.
> >> I’m trying to find out why we need to restrict the server’s flexibility in
> choosing the URI here.
> >> Maybe there is a good reason, I’d just like it to be more explicitly
> >> stated.)
> >
> > The good reason is that we are using URI templates in the registration
> > update operation: {+location}{?lt,con,extra-attrs*}
> >
> > While it should be intuitively obvious that for location="x://y/z?a=b"
> > and lt="42", the produced URI is "x://y/z?a=b&lt=42", RFC6570 Section
> > 3.2.8 does not describe peeking back at what has been expanded to the
> > left side, but prescribes a "?" to be used before the first value, so
> > the produced URI would be "x://y/z?a=b?lt=42" (or possibly
> > ?a=b%3Flt=42 but not ?a=b&lt=42).
> >
> > If I'm reading RFC6570 wrong here, Location-Path can be allowed and
> > I'd be happy.
> >
> > Otherwise, we have to choose between using formal URI templates here
> > (vs. saying that some query parameters can be appended) and allowing
> > Location-Query. (Requiring anyone to understand ?foo=bar?baz=qux as
> > two keyswould be madness so it’s not an option.)
> 
> I must admit that I read
> 
> 
>    o  append "?" to the result string if this is the first defined value
>       or append “&” thereafter;
> 
> as doing the right thing, but then maybe I don’t understand “the first defined
> value” (of what?).
> 
> We could also use formal URI templates and just say that they are to be
> interpreted in the sensible way described above.
> 
> (I’m not a fan of RFC 6570 URI templates at all, because the approach is full of
> brokenness of the kind you describe(*); but it was available at the time…)

I would agree that I would not have read this as needing to have two "?" characters in the query parameters.  My issue is that I worry about the case that an RD decides to use foo=XXX as the location query and then some application decides to use foo as a query parameter in the extra parameters or in a link description.  This works fine on RD implementation #1 because it is just using a location path to point to the end point, but when it hits RD implementation #2 which is using the location query as well it starts failing.  

It is also slightly a pain because it is harder to combine query parameters than it is to just use a path, but that can easily be dealt with.

Jim

> 
> >
> >>> 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.
> 
> 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…