Re: [core] Modernized Link Format

[Klaus Hartke <[e-mail]>]

Christian Amsüss wrote:
> The last state I know are our discussions from March, since which
> representations (formerly fat links) have been re-introduced.
>
> Has CoRAL received any reviews since then? Is it progressing towards
> adoption by T2TRG?

Adoption is now on the agenda of the T2TRG summary meeting in Bangkok
[1]. The draft hasn't seen any significant reviews since March,
though.

> Would we need to / should we, if the RD were to forego fixing RFC6690
> and rely on CoRAL to express what can't be said with link-format, do in
> terms of implementation limits and profiles? Should there be a dedicated
> profile for "CoRAL used as link-format replacement", or would you expect
> the default profile to work here?

While the default profile technically works, it's not as efficient as
it can get since it doesn't assign numeric identifiers, e.g., to the
"hosts" relation type and RFC 6690 link attributes. So there should be
a profile that does for "Link Format in CoRAL" what
draft-ietf-core-links-json-10#section-2.3 [2] does for "Link Format in
CBOR". I don't know if that has to be a profile that is dedicated to
this application or if it'd make sense, for example, to have a general
"CoRE Profile" that works also for /.well-known/core and other CoRE WG
specifications.

> Are there yet examples of a
> .well-known/core file expressed in CoRAL?

Here's one example from RFC 6690 [3] expressed in CoRAL:

OLD:

</sensors>;ct=40;title="Sensor Index",
</sensors/temp>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor",
<http://www.example.com/sensors/t123>;anchor="/sensors/temp";rel="describedby",
</t>;anchor="/sensors/temp";rel="alternate"

NEW:

#using <http://www.iana.org/assignments/relation/>
#using lf = <http://TBD/>

hosts </sensors> {
    lf:ct "40"
}

hosts </sensors/temp> {
    lf:rt "temperature-c"
    lf:if "sensor"
    describedby <http://www.example.com/sensors/t123>
    alternate </t>
}

hosts </sensors/light> {
    lf:rt "light-lux"
    lf:if "sensor"
}

> I'm all for the approach, but at what time frame can it be realized, and

I think it'd make sense to have at least one or two interop events, so
it depends on how quickly the draft gets adopted, implementations
created, interoperability confirmed, reviews done.

While I think the draft is already in quite a good state, I would
probably rather lean towards getting it right than rushing it out.

> which working groups will need to be involved at which stage to avoid
> surprises at IESG review? (Eg. equating target attributes with literal
> properties under http://TBD/ is something that could need feedback from
> RFC8288's WG^Wauthors^H or other RDF-using WGs.)

RFC 8288 gives some license to deviate from the spec where it makes
sense in different link serialization formats. For example,  Atom
allows IANA-registered link relation types to be serialized as URIs
using the prefix "http://www.iana.org/assignments/relation/", which is
specific to Atom (and adopted by CoRAL) and not part of RFC 8288 [4].
So I don't think there's a hard dependency on feedback from the RFC
8288 authors. Review from the RFC 8288 authors and other working
groups would be welcome, of course.

One thing that could raise eyebrows is if the CoRE WG started to
assign numeric identifiers to all IANA-registered link relation types
[5]. I thought of doing that in draft-hartke-core-apps-07 [6], but am
now not so sure if that is the right path.

Does anything else come to your mind that could lead to surprises at
IESG review?

Klaus

[1] https://github.com/t2trg/2018-ietf103
[2] https://tools.ietf.org/html/draft-ietf-core-links-json-10#section-2.3
[3] https://tools.ietf.org/html/rfc6690#page-14
[4] https://tools.ietf.org/html/rfc8288#appendix-A.2
[5] https://www.iana.org/assignments/link-relations/link-relations.xhtml
[6] https://tools.ietf.org/html/draft-hartke-core-apps-07#section-6.2