Change:
important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility.  The discovery of resources provided by an HTTP Web Server is typically <del> called Web Linking RFC5988.  The use of Web Linking for the </del> <ins> called Web Linking RFC8288.  The use of Web Linking for the </ins> description and discovery of resources hosted by constrained web servers is specified by the CoRE Link Format RFC6690.  However, RFC6690 only describes how to discover resources from the web server

Discussion:
Rather than redefining RFC6690, we now just allow the common subset. As this touched some 5988 references, I fixed the ref-to-obsolete-rfc issues right in here in a follow-up commit.
The outcome of the 2018-10-24 interim w/rt of the use of Modernized Link Format is what I'd outline like this: The WG has no interest in keeping 6690 alive by having a bis links-json/-cbor was pushed back to the WG, and it looks like it won't follow the troublesome parts of 6690 any more Therefore, my proposed course of action is to Remove Modernized Link Format, leaving it in only as a set of limitations the submitted links MUST follow. (Effectively creating a subset of Link Format that can be expected to be interoperable even as people implemented Modernized Link Format or similar, but not specifying any new behavior). currently we say that submitted documents SHOULD be in that subset, but mandate that Modernized Link Format be applied by the server in order to allow the rare 6690-impossible things. State that for some use cases, Link Format is therefore not suitable, and other formats (like links-json or CoRAL, both informative references) need to be used to be able to express some links. (Maybe in the interop spec) point out where variation is to be expected given widespread bugs in RFC6690 implementations. As Peter pointed out, that should be a matter of days to do plus something in the order of magnitude of a week for reviews -- I'll be starting to write the text Soon, so we'll have a proposed text for Bangkok. Any comments before I start?
HI Christian, Most of your conclusions I agree with. If there is no 6690bis, what will the value of 6690 be in the future? Indeed the RD will accept link format (MUST support) but with the cited restrictions. I prefer constraints (restrictions) over modernized link format. The RD recommends to follow links-json syntax; Once links-json is published , the RD should probably be updated as well. The new links-json document should explicitly cite that it follows RFC 3986 for URI evaluation; for the moment it is a bit vague about that. It is mainly a syntactical document.

It provides an algorithm to map link-format to link-json and vice -versa but does not inform the reader about the associated rules change. Peter chrysn schreef op 2018-10-24 18:28: Links: [1] URL [2] URL [3] URL
I think it'll be just something one supports to accommodate old devices or devices built to match old requirements – and it's the only thing we have right now that's feasible on embedded. We could have something in that says "MUST support (limited) 6690 link-format, and SHOULD support other formats like links-json. It is expected that once the working group picks a successor to link-format, that document will update this to mandate support for the new format" (and probably downgrade MUST to SHOULD on 6690). Then, links-json when done would minimally update RD to say say that links-json is now a MUST. Yes; my request to to make it do that unfortunately hit it after WGLC, but now that IESG has passed it back and there's no WG drive to keep 6690 or full 6690 compatibility alive, I think we can make sure it does. The algorithm can stay valid for limited link-format, and I guess there won't be any published algorithm that covers all 6690 cases.
I forgot to reference this in PR , but this issue can be closed once that's merged. The parts about links-json were left out as PR goes in a different direction, given the general uncertainty of what new link format will be exactly. Christian Amsüss wrote: 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. 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. Here's one example from RFC 6690 [3] expressed in CoRAL: OLD: ;ct=40;title="Sensor Index", ;rt="temperature-c";if="sensor", ;rt="light-lux";if="sensor", ;anchor="/sensors/temp";rel="describedby", ;anchor="/sensors/temp";rel="alternate" NEW: #using #using lf = hosts { lf:ct "40" } hosts { lf:rt "temperature-c" lf:if "sensor" describedby alternate } hosts { lf:rt "light-lux" lf:if "sensor" } 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. 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 "URL", 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] URL [2] URL [3] URL [4] URL [5] URL [6] URL