Draft: draft-ietf-core-resource-directory

Commentary: Both drafts for the examples ( HEAD^ and [ 129 ] ) contributed more to confusion than to clarification . Leaving absolute references in to have extensibility , but the text now says that it does n't mean much until specified . ( As discussed in Monday 's telco ) . [ 129 ] : 
 Updated as I missed some text on the same topic . 
 Christian , thanks . this looks beter . schreef op 2018 - 06 - 27 15:47 : Links : [ 1 ] [ 2 ] [ 3 ] 
 compare on group for remote endpoint . Should this do the remote lookup or can it just be ignored for attribute comparison I am not quite sure what you mean by attribute comparison . When it is about registration attributes , no remote lookup seems necessary to me . If I do the lookup of /rd / gp - lookup?rt = foobar And one of the groups has the following /rd - group / xxx https://otherrd / rd - group / yyy I would follow the local group definition to find out if the resource type is defined on some resource in the group , however the question is do I need to go and query the other group which is not local in order to do the same tree walking when doing attribute comparisons . Not that this applies to remote endpoint registrations in a group as well . Thanks for the example . Indeed following the latest text , the comparison should include the remote registration . The text could include words like tree walking is done locally only ; personally I would not be too happy about that . Apparently the text should say something about remote groups and tree walking . I will add the issue to github . 
 Let 's not go into specifying distributed RDs but just keep the door open to not have clients break when one is even though it behaves like a regular  ( see longer comment at ) . Concrete proposal from there : Would it help if we changed the example to say GET Res : 2.05 Content ; con="coap://[2001 : db8:3::123 ] : " ; ep="node1";et="";ct="40";lt="600 " , < /rd / efgh;con="coap://[2001 : db8:3::124 ] : " ; ep="node2";et="";ct="40";lt="600 " ? It would just indicate that the registration resource is hosted by the same RD but on another protocol ( presumably because the endpoint registered using coap+tcp , and that Location ca n't just jump protocols ) . 
 The semantics of having a foreign URI in the endpoint lookup or group are now completely left to further specification since / .
Mailing list commentary: Hello , , We should look at why we are requiring idempotency here . From what I can tell , this is because CoAP servers and clients are easier to implement if they can rely on the operation to be idempotent , but they are looking at the very same request being sent again in a relatively short time frame . An additional use case here is stability in presence of " semi - simple " clients that POST their .well - known / core to the directory resource every few hours and never try to parse the Location returned . If those change the registration resource address every time , an observation on the endpoint lookup becomes needlessly noisy . As long as those are the cases we consider , I think that it is sufficient to specify that the registration operation must return the same response to a CoAP request with the same requester / security context , code , options and payload within EXCHANGE_LIFETIME . The concern for observation stability is more a matter of implementation quality , where me can recommend but need not specify . I think the more convenient thing to do is to say that resources are compared against the full path , and registrations and group resources ( they can be matched too ) are matched against whatever is returned in endpoint lookup . That would be more intuitive to the user of the lookup ( matching against what is returned ) . I think that this is out of scope for RD itself . What I 'd like to have in RD is the text that ensures that clients will not get upset when they see absolute URIs in group or endpoint lookups . We are not actually describing a distributed here , this is only to keep the door open for such extensions . Would it help if we changed the example to say GET Res : 2.05 Content ; con="coap://[2001 : db8:3::123 ] : " ; ep="node1";et="";ct="40";lt="600 " , ; con="coap://[2001 : db8:3::124 ] : " ; ep="node2";et="";ct="40";lt="600 " ? It would just indicate that the registration resource is hosted by the same RD but on another protocol ( presumably because the endpoint registered using coap+tcp , and that  ca n't just jump protocols ) . My expectation is that lt= is the registered value and never decreases . ( For an additional value that indicates where the registration is in its lifetime , I ' ve suggested lt - age in draft - amsuess - core - rd - replication-01 -- but only because there 's an application for it there ) . Having lt decrease is problematic with caching ( admittedly , so is lt - age ) . What use cases do we have for exposing a lifetime in the endpoint lookup at all ? ( If we have none , an RD might just as well not display a lifetime ) . ep = node1 would be ... well not technically illegal ( the template would put the ep in extra - attrs , and the server hopefully not store it there ) ; it is an attribute that is not changing and therefore SHOULD NOT be included in the update by the client . A changed ep would not create a new registration ( we 're at a registration resource already ) , but simply be refused . The text is already pretty explicit : " If the parameter is set in an update , it is stored by the RD as the new Base URI under which to interpret the links of the registration , following the same restrictions as in the registration . If the parameter is not set and was set explicitly before , the previous context value is kept unmodified . If the parameter is not set and was not set explicitly before either , the source address and source port of the update request are stored as the context . " This allows for clients that do not keep a good eye on their addresses but have their OS pick the latest one . Note that nobody other than the endpoint ( or CT if created by one ) may manipulate a registration resource . ( If we wanted to allow other hosts to manipulate a different endpoint 's registration , we 'd need something like a ? ct = keep or change in semantics to allow that -- but I 'd like to have a good reason to do that in the first place ) . It should be neither ; that request is empty and so is the response . The RD will need to probe for the content format of its own ( possibly trying its preferred content format first , falling back to an empty accept or 40 ) . The best equivalent of " and look there expecting this content format " would be HTTP 's link header ( a la ' POST /.w - k / c?ep = node1 , : ; ct="40 64 504 " ' ) , and we ca n't do that in CoAP , at the very least not in a simple registration . I think that the more important question behind is of whether the RD should ( or may ) wait with a response until it has fetched the .w - k / c of the endpoint . The example shows " respond first , then ask details " , which we might consider prescribing given that highly constrained clients might not manage to multi - task the request and the response . ( Dealing 5.03 Sorry I ' m Busy until their pending request is answered or expired ) . Best regards Christian ( updating the issue tracker in parallel )
Paragraph (version A):
The registration message is a list of links to registration resources
of the endpoints that belong to that group.  The registration
resources MAY be located on different hosts than the group hosting
RD.  In that case the endpoint link points to the registration
resource on the other RD.  The commissioning tool SHOULD NOT attempt
to enter a foreign registration in a group unless it found it in the
group RD's lookup results, or has other reasons to assume that the
foreign registration will be accepted.
Paragraph (version B):
The registration message is a list of links to registration resources
of the endpoints that belong to that group.  The CT can use any URI
reference discovered using endpoint lookup from the same server or
obtained by registering an endpoint using third party registration
and enter it into a group.  The use of other URIs is not specified in
this document and can be defined in others.
Paragraph (version A):
A Resource Directory can report endpoints or groups in lookup that
are not hosted at the same address.  While the setup and management
of such a distributed system is out of scope for this document,
lookup clients MUST be prepared to see arbitrary URIs as registration
or group resources in the results.
Paragraph (version B):
A Resource Directory can report endpoints or groups in lookup that
are not hosted at the same address.  Lookup clients MUST be prepared
to see arbitrary URIs as registration or group resources in the
results and treat them as opaque identifiers; the precise semantics
of such links are left to future specifications.