Draft: draft-ietf-core-resource-directory

Commentary: 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    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 wo n't follow the troublesome parts of 6690 any more Therefore , my proposed course of action is to     , leaving it in only as a set of limitations the submitted links MUST follow . ( Effectively creating a subset of   that can be expected to be interoperable even as people implemented    or similar , but not specifying any new behavior ) . currently we say that submitted documents SHOULD be in that subset , but mandate that    be applied by the server in order to allow the rare 6690 - impossible things . State that for some use cases ,   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  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 .  chrysn schreef op 2018 - 10 - 24 18:28 : Links : [ 1 ] [ 2 ] [ 3 ] 
 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 wo n'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 .
Mailing list commentary: wrote : Adoption is now on the agenda of the T2TRG summary meeting in Bangkok [ 1 ] . The draft has n'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 does n'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 do n'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 " " , which is specific to ( and adopted by CoRAL ) and not part of RFC 8288 [ 4 ] . So I do n'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 ? [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]
Paragraph (version A):
This specification requires readers to be familiar with all the terms
and concepts that are discussed in RFC3986, RFC5988 and RFC6690.
Readers should also be familiar with the terms and concepts discussed
in RFC7252.  To describe the REST interfaces defined in this
specification, the URI Template format is used RFC6570.
Paragraph (version B):
This specification requires readers to be familiar with all the terms
and concepts that are discussed in RFC3986, RFC8288 and RFC6690.
Readers should also be familiar with the terms and concepts discussed
in RFC7252.  To describe the REST interfaces defined in this
specification, the URI Template format is used RFC6570.
Paragraph (version A):
The resource directory architecture is illustrated in fig-arch.  A
Resource Directory (RD) is used as a repository for Web Links RFC5988
describing resources hosted on other web servers, also called
endpoints (EP).  An endpoint is a web server associated with a
scheme, IP address and port.  A physical node may host one or more
endpoints.  The RD implements a set of REST interfaces for endpoints
to register and maintain sets of Web Links (called resource directory
registration entries), and for endpoints to lookup resources from the
RD.  An RD can be logically segmented by the use of Sectors.  This
information hierarchy is shown in fig-hierarchy.
Paragraph (version B):
The resource directory architecture is illustrated in fig-arch.  A
Resource Directory (RD) is used as a repository for Web Links RFC8288
describing resources hosted on other web servers, also called
endpoints (EP).  An endpoint is a web server associated with a
scheme, IP address and port.  A physical node may host one or more
endpoints.  The RD implements a set of REST interfaces for endpoints
to register and maintain sets of Web Links (called resource directory
registration entries), and for endpoints to lookup resources from the
RD.  An RD can be logically segmented by the use of Sectors.  This
information hierarchy is shown in fig-hierarchy.
Paragraph (version A):
The security considerations as described in Section 7 of RFC5988 and
Section 6 of RFC6690 apply.  The "/.well-known/core" resource may be
protected e.g. using DTLS when hosted on a CoAP server as described
in RFC7252.  DTLS or TLS based security SHOULD be used on all
resource directory interfaces defined in this document.
Paragraph (version B):
The security considerations as described in Section 5 of RFC8288 and
Section 6 of RFC6690 apply.  The "/.well-known/core" resource may be
protected e.g. using DTLS when hosted on a CoAP server as described
in RFC7252.  DTLS or TLS based security SHOULD be used on all
resource directory interfaces defined in this document.
Paragraph (version A):
The query parameter MUST be both a valid URI query key RFC3986 and a
parmname as used in RFC5988.
Paragraph (version B):
The query parameter MUST be both a valid URI query key RFC3986 and a
token as used in RFC8288.