Change:
which the registration request is received. Endpoints that register with a base that contains a path <del> component cannot meaningfully use RFC6690 Link Format due to its prevalence of the Origin concept in relative reference resolution.  Those applications should use different representations of links to which limitedlinkformat is not applicable (e.g.  I-D.hartke-t2trg-coral). </del> <ins> component cannot efficiently express their registrations in Limited Link Format (limitedlinkformat).  Those applications should use different representations of links to which limitedlinkformat is not applicable (e.g.  I-D.hartke-t2trg- coral). </ins> Additional registration attributes (optional).  The endpoint can pass any parameter registered at iana-registry to the

Discussion:
This is fixing as set out in URL Still marked as a draft as the outstanding changes are still: [ ] Adjusting the examples (along with all the other pending example fixes) [ ] Adjusting the appendix texts [ ] Read through it once more because that doesn't happen in the first pass.
This PR now executes the steps set out in URL and should resolve all of NAME example items -- most of it is about not having to repeat the anchor again all the time.
thanks, this looks good.
Looking in the master branch .md doc: some examples use a coap:// URI (not secure) that use the port 5684, which is normally reserved for coaps:// (secure). Better use other port numbers for these examples, e.g. ones in the dynamic range, or currently unallocated ones?
I think for the next I-D I'll be doing examples in, I'll just write a script that sets up the examples in an implementation and sniffs out the examples content. Thanks for spotting yet another case of example inconsistency. (Those should be using coaps as that's what the base URI is updated to).
Link Format doesn't require the quote characters (") for an attribute value for rt and if attributes, in case just a single value is encoded. So e.g. from an example in the draft could be: I presume above would be a typical encoding by the RD, going for the most efficient one. (As a side note: leaving out the quote characters only works for non-URI values, see URL . But that's the case here.)
In Appendix B.2: It looks like /t is an alternative for /sensors/temp , but there's no resource /sensors/temp. For clarify maybe replace to Also in the text below it; replace all "/sensors/temp" by "/temp" then.
(Sorry for not making a pull request of this - Github doesn't allow me to, it seems.) Existing master branch text: ~ Proposed update: ~ (Note: 'rt' are unquoted here following shortest RFC6690 allowed encoding of 'rt'. Other attributes may be unquoted also per RFC 6690 but I wasn't sure what is best here.)
In many examples, the "anchor" attribute is included if the target URI of the link is an absolute URI.

For example like below: Here the anchor is not needed because the origin of the target URI already specifies the context/anchor; per RFC 6690 URL rule (b) . For constrained devices and networks it is very important to minimize the payload sizes where possible, so I think the RD SHOULD in this case return the most efficient form possible by leaving out the anchor parameter per link where this is unnecessary to include. New proposed text of above example: And similar changes to be made for other examples. Also I'd like to note that including the anchor additionally with the same information seems strange, given that the "hosts" relation type was defined as it is to get rid of the anchor in most cases - serving the needs of constrained systems.
Result of the last interim's discussion was that yes we can go ahead with this (after checking through the implementations list again and making the adequate changes to the text). I'm holding off the other "examples" fixes (, , , ) for then to keep the diffs more readable.
For my reference, what needs checking is the list at URL against the current understanding.
Fixed in eb62d317c4d9a650002bcee8c8fcc619134b7c4c Hello CoRE group, I'm looking for and evaluating implementations of the RFC6690 discovery process to help making decisions on the document formats usable for the Resource Directory. So far, I'm aware of RIOT, URL, Copper4Cr, leshan, wakaama, ncoap, californium, CoAP.NET, and the coap Ruby gem. I've also looked at other SDO's use of 6690: OMA LWM2M appears not to use anchor at all[8]. OCF are the first I found who actually build a link from resolving the href relative to the anchor (which is one of the RFC6690 peculiarities I'm trying to find users of), but use a serialization that is neither RFC6690 nor links-json exactly (judging from [9]). Please send me any links you have on consumers of link-format data, producers of link-format data that actually output anchor values, or other SDOs that rely on the precise resolution rules of RFC6690. Thanks in advance Christian Notes from looking through the known ones: RIOT: Tested by advertising an RD with instead of (which are equivalent in 6690); then it fails to register.

Copper4Cr: not tested, but the absence of 'anchor' in [1] and its callers indicates it won't represent links correctly when anchor is set (and does not ignore them if it can't handle them either). leshan: like Copper, see [2], plus tokenizes wrongly. wakaama: like Copper, see [3] ncoap: similar to Copper, see [4], though to be fair, it exposes the URI via a getUriReference indicating the caller would need to know how to resolve it. I found no caller whom I could check for whether it's using it right. californium: similar situation, see [5]. The href gets passed out as a WebLink, whose getURI method only considers the href. CoAP.NET: I don't grade copied homework, please look at californium's sheets coap Ruby gem: same situation at [7], href is passed out as uri via accessor while anchor is passed along in atteribute if present. I had looks at contiki, libcoap, lobaro, txThings -- but none of them appears to implement link-format parsing in the library. [1]: URL [2]: URL [3]: URL [4]: URL [5]: URL [6]: URL [7]: URL [8]: URL [9]: URL To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
Hello Reviewers, CoRE and IESG members, thanks for your input to the Resource Directory document, and your patience while it was being processed. Before the individual point to point responses can go out, this mail is to address the general status, and answer a few points that were brought up by different reviewers (it will be referred back to in the point to point responses). In summary, the points raised in the reviews led to the changes of the recently uploaded [-26], and where no changes were made, the reasoning behind the choices in the document is outlined below or in the following mails. (Either way, short of aggregated nits paragraphs, all points are responded to in the following mails). A few larger issues evolved from the review comments being discussed in the interim meetings, so please expect a -27 at a later point (after IETF109) with the changes mentioned below.

Kind regards Christian [-26]: URL Preface References into the issue tracker are primarily intended for bookkeeping and to give you access to the altered text if you're curious -- but for general review purposes, the responses are self-contained. Anticipated changes We have opted to submit a new version that should clear out all the other comments, so that the remaining work can be focused and swift: Replay and Freshness (OPEN-REPLAY-FRESHNESS) The comment on DTLS replay made us reevaluate the security properties of operations on the registration resource. While these are successively harder going from DTLS without replay protection to DTLS with replay protection and hardest with OSCORE, the text as it is is still vulnerable to an attacker stopping a reoccurring registration, or undoing alterations in registration attributes. Mitigation from a concurrent document (the Echo mechanism of I-D.ietf-core-echo-request-tag in event freshness mode) is planned, but the text is not complete yet. Necessity of the value in all responses The requirements around Limited Link Format and the necessity to express all looked up links in fully resolved form have stemmed from different ways RFC6690 has been read, both in the IETF community and by implementers. A comment from Esko Dijk has shown a clear error in one of the readings. That reading is single-handedly responsible for most of the overhead in the wire format (savings can go up to 50%), which is of high importance to the CoRE field. Due to that, it is the WG's and authors' intention to remove the reading from the set of interpretations that led to the rules set forth. The change will not render any existing RD server implementation incompatible (older RDs would merely be needlessly verbose), and the known implementations of Link-Format parsers can easily be updated. The updates to the document could not be completed in time with the rest of the changes, because a) it requires revisiting the known implementations for confirmation and b) will affect almost every example that contains lookup results. Server authorization (OPEN-SERVER) The two areas of "how is the RD discovery secured" and "what do applications based on the RD need to consider" jointly opened up new questions about server authorization and the linkage between a client's intention and the server's promises that may easily not conclusde in timeframe reasonable for RD.

While steps have been taken to address the issue both on the RD discovery and the applications side (URL), the ongoing discussions in the working group may turn up with a less cumbersome phrasing for these parts. There's a few small open issues Esko brought up on the issue tracker that could not be addressed in time; most of them are about enhancing the examples, which best happens after the anchor cleanup anyway. Repeated topics A few common topics came up in multiple reviews, and are addressed in the following section; the individual responses can be found in follow-up mails, and refer to the common topics as necesary. GENERIC-FFxxDB "Where do the ff35:30:2001:... addresses come from?" response: There's a coverage gap between RFC3849 (defining example unicast addresses) and RFC3306 (defining unicast-prefix-based multicast addresses). For lack of an agreed-on example multicast address, the used ones were created by applying the unicast-prefix derivation process to the example address. The results (ff35:30:2001:db8::1) should be intuitively recognizable both as a multicast address and as an example address. The generated address did, however, fail to follow the guidance of RFC 3307 and set the first bit of the Group ID. Consequently, the addresses were changed from ff35:30:2001:db8::x to ff35:30:2001:db8::8000:x, which should finally be a legal choice of a group address for anyone operating the 2001:db8:: site. (The changes can be viewed at URL). GENERIC-6MAN "Whas this discussed with 6MAN?" response: Not yet; a request for feedback was sent out recently. (Mail at URL). GENERIC-WHOPICKSMODEL "How does the client know which security policies the RD supports?" response: The client can only expect any level of trustworthiness if there is a claim to that in the RD's credentials. Typically, though, that claim will not be encoded there, but implied. For example, when configuring an application that relies authenticated endpoint names, then telling the application to use the RD authenticated via PKI as URL should only be done if the configurator is sure that URL will do the required checks on endpoint names.

Some clarification has been added in URL GENERIC-SUBJECT "Section 7.1 says: '... can be transported in the subject.' -- where precisely?" response: That text was only meant to illustrate to the reader what such a policy could contain, not to set one (which would require more precision). It has been made more explicit that this is merely setting the task for the policies. As an example, some more precision is given by referring to SubjectAltName dNSName entries. Changes in URL (If you have read up to this point, please continue reading the follow-up mails addressing the individual reviewer's points.)