Draft: draft-ietf-core-resource-directory

Commentary: This decides the open question of how to match the in a query in favor of client simplicity . Closes : would that change be OK with you and solve the issue ? 
 I know what an absolute form is , where do I find out what a path absolute form is 
 path - absolute is an ABNF in RFC3986 , described as " begins with a ' / ' but not ' // ' " . 
 I agree with the addition . This means that one can match against an absolute registration target as well . 
  in 
 It 's a trade - off between not being a surprise to the RD implementation ( with b , it needs to compare values that it has not seen in that form ) versus not being a surprise to the lookup client ( with a , it queries for something it does not see in that form in the query result ) . I think that the latter is preferable .
Mailing list commentary: Here are some more questions on the document . 1 . The registration text in section 5.3 says that the interface is idempotent , however it is not clear to me just how idempotent this is supposed to be . It is obvious that the goal is to make sure that a different resource is not created , however I am not clear what is supposed to happen with some of the parameters such as the ' lt ' parameter . One way to implement this is to just make it a POST to the previously existing resource which would inherit old attributes on the endpoint . The other way is to say we are going to create a new resource , it just has the same address . It is not clear which , if any , of these two methods is to be used . Never mind I found the answer to this one . Need to think if I want clearer language . 2 . When doing an endpoint lookup , I assume that the ' lt ' parameter would be the same as the one registered at creation . Is there / should there be a parameter which is a TTL value ? 3 . How are href comparisons done . a ) compare against what was registered b ) Resolve what was registered and the href in the current context and compare c ) something I did not think of 4 . compare on group for remote endpoint . Should this do the remote lookup or can it just be ignored for attribute comparison 5 . Value of lt = should it be the set parameter or the time left - how would time left be represented outherwise - should it be represented . 6 . Inferred context based on source IP when an update is done . If no con is provided , is that supposed to be checked again to see if it is " right " ? Only if we did the infer to begin with ? 7 . I do n't understand the presence of the content - format for the empty message posted for simple registration . This seems to be odd if the content is empty . 8 Is there supposed to be a way for simple registration to return an error message ? As written this is not necessarily done . Specifically , the response to the post can be executed before the query to /.well - known / core is done and the registration is attempted .
Paragraph (version A):
Note that "href" is also a valid search criterion and matches target
references.  Like all search criteria, on a resource lookup it can
match the target reference of the resource link itself, but also the
registration resource of the endpoint that registered it, or any
group resource that endpoint is contained in.
Paragraph (version B):
Note that "href" is also a valid search criterion and matches target
references.  Like all search criteria, on a resource lookup it can
match the target reference of the resource link itself, but also the
registration resource of the endpoint that registered it, or any
group resource that endpoint is contained in.  Queries for resource
link targets MUST be in absolute form and are matched against a
resolved link target.  Queries for groups and endpoints SHOULD be
expressed in path-absolute form if possible and MUST be expressed in
absolute form otherwise; the RD SHOULD recognize either.