Draft: draft-ietf-core-resource-directory

Commentary: This is fixing as set out in 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 does n't happen in the first pass . 
 This PR now executes the steps set out in and should resolve all of 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 ) . 
   does n'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 . But that 's the case here . ) 
 In  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 does n't allow me to , it seems . ) Existing master branch text : ~ Proposed update : ~ ( Note : ' rt ' are unquoted here following shortest  allowed encoding of ' rt ' . Other attributes may be unquoted also per RFC 6690 but I was n'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 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 against the current understanding . 
 Fixed in
Mailing list commentary: 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 , , Copper4Cr , leshan , wakaama , ncoap , californium , CoAP.NET , and the coap Ruby gem . I ' ve also looked at other SDO 's use of 6690 : OMA LWM2 M 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 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
Hello , 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 ] : 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    and the necessity to express all looked up links in fully resolved form have stemmed from different ways has been read , both in the IETF community and by implementers . A comment from 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 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 . While steps have been taken to address the issue both on the RD discovery and the applications side ( ) , 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
Paragraph (version A):
In link-format serialization, it is expressed in the "anchor"
attribute.  It defaults to that document's URI.
Paragraph (version A):
Note that depending on the particular server's architecture, such a
link could be anchored at the RD server's root, at the discovery site
(as in this example) or at individual RD components.  The latter is
to be expected when different applications are run on the same
server.
Paragraph (version B):
Note that depending on the particular server's architecture, such a
link could be anchored at the RD server's root (as in this example),
or at individual RD components.  The latter is to be expected when
different applications are run on the same server.
Paragraph (version A):
For media types to which limitedlinkformat applies (i.e. documents in
application/link-format), the RD only needs to accept representations
in Limited Link Format as described there.  Its behavior with
representations outside that subset is implementation defined.
Paragraph (version B):
For media types to which limitedlinkformat applies (i.e. documents in
application/link-format), request bodies MUST be expressed in Limited
Link Format.
Paragraph (version A):
Endpoints that register with a base that contains a path
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).
Paragraph (version B):
Endpoints that register with a base that contains a path
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).
Paragraph (version A):
Resource lookup results in links that are semantically equivalent to
the links submitted to the RD by the registrant.  The links and link
parameters returned by the lookup are equal to the originally
submitted ones, except that the target and anchor references are
fully resolved.
Paragraph (version A):
Links that did not have an anchor attribute are therefore returned
with the base URI of the registration as the anchor.  Links of which
href or anchor was submitted as a (full) URI are returned with these
attributes unmodified.
Paragraph (version B):
Resource lookup results in links that are semantically equivalent to
the links submitted to the RD by the registrant.  The links and link
parameters returned by the lookup are equal to the originally
submitted ones, except that the target reference is fully resolved,
and that the anchor reference is fully resolved if it is present in
the lookup result at all.
Paragraph (version B):
Links that did not have an anchor attribute in the registration are
returned without an anchor attribute.  Links of which href or anchor
was submitted as a (full) URI are returned with the respective
attribute unmodified.
Paragraph (version B):
The interpretation of RFC6690 used in resolution-rules was shown
to be faulty.  Along with a correction, the common implementations
of link-format were surveyed again and it was found that the only
one that employed the faulty interpretation can still safely be
upgraded.  These were removed from the set considered for Limited
Link Format, making the set of valid Limited Link Format documents
larger.
Paragraph (version B):
As a consequence, the prescribed serialization of RD output can be
roughly halved in bytes.
Paragraph (version B):
There might be additional usage patterns that are possible with
the new set of constraints, but there is insufficient
implementation and deployment experience with them to warrant a
change changes on that front at this point.  The specification can
later be extended compatibly to allow these cases and drop the
requirement of Limited Link Format.