Re: [core] Report on first Resource Directory plugtest

[Christian M. Amsüss <[e-mail]>]

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

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

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.

[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?

Best regards
Christian

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn