Re: [core] Report on first Resource Directory plugtest

[Carsten Bormann <[e-mail]>]

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

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