Re: [core] Modernized Link Format

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

Hello Klaus,

thanks for comment.

On Thu, Oct 11, 2018 at 01:47:30PM +0200, Klaus Hartke wrote:
> at <coap://example.com:1234/.well-known/core>...
> 
>     <foo/bar>
> 
> ....would resolve to the following URI under the old rules...
> 
>     coap://example.com:1234/foo/bar
> 
> ....and  to the following URI under the new rules...
> 
>     coap://example.com:1234/.well-known/foo/bar
> 
> ....regardless of whether "rel" is the implicit "hosts" relation type
> as in this example or any other relation type.
> 
> Is that correct?

Yes. (In neither document, an explicit or implicit rel has an impact on
the reference resolution.)

> While the impact of this change on existing deployments might be low,
> it's a breaking change and as such IMO requires an RFC that updates or
> obsoletes RFC 6609.

The new interpretation is only used when an application explicitly
specifies it (as does the RD). Applications "in the wild" are, as it is
written now, not affected.


The choices we have in RD are, to my understanding, as follows:

a) What is in -15: Bend link-format only when used in RD (or any other
  document that opts in to that -- I figure core-interfaces will)

b) Update 6690...

  b1) ... in a 6690bis

  b2) ... in Resource Directory

c) Use 6690 interpretation in RD


We've ruled out c) over the last year b/c it means that features of the
RD will not be available (ie. some links can not be expressed in any
serialization format) until one can actually use a format that doesn't
suffer from 6690's weird resolution rules (ie. CoRAL or 6690bis).
Moreover, if we went by c, any deployed RD would keep us from a 6690bis,
for an RD implementation needs to resolve URIs.

Among b and a, a was picked because hopes were that would allow for the
fastest progress of RD which is way behind schedule; also, it allows
doing b1 later easily. I'm all for doing any of the b options, but I
don't rather not have them delay the RD.

What puts me off b1 a bit is that it'll attract fixes to other oddities
of 6690 too (eg. clarifying rel=hosts, recommending against
whitespace-separated values), delaying RD by a year or more. (And that's
not even thinking of the links-json process).

Say we wanted to go for b2, as you suggest. Is that possible at all,
procedurally? How thorough would an investigation into the current users
need to be to allow re-using the content format number and media type?
(I have asked around and not seen or heard of a single implementation of
RFC6690 that relies on the odd behaviors, but obviously didn't ask all
readers of 6690. It appears to me that not even the original authors
were fully aware of their rules, or all examples would start with `<x`
rather than with `</x` for brevity.)


Best regards
Christian

-- 
Ceterum censeo RFC6690 esse revidendam.
 -- me, in mails from April on that topic