Change:
See URL
The words server , directory server, and endpoint change meaning in the text dependent on the advance of the process. I find it confusing. Can we agree on the terminology "constrained endpoint" and "RD" and use that throughout this text?
Text updated, it now says "The Resource Directory MUST NOT..." and a note where it'd say "registree-ep" if is merged.
Merged this version. Jim would AFAIR have preferred the other way (execute then confirm) for semantic clarity, but I think that extremely-constrained ("no simultaneous exchanges") clients should be considered here as devices caring about return codes should do the full thing anyway.
Two of the current implementations have different behavior when it comes to simple registrations: Jim's sends an ACK, but belays the Success response to when the .well-known/core has been obtained. Mine sends Success anyway to acknowledge the EP's intent to register, and only logs an error if something later goes wrong. I think that Jim's is the better behavior; mine was motivated by consideration for clients that have a limited number of open exchanges (1), and might answer 5.03 for as long as they have outstanding CONs themselves. IMO we should either prescribe Jim's behavior or add a warning that the Success indication does not necessarily mean too much. Which would you prefer?
I prefer the success return, and having understood that things are out of control for the registering node. Option 2 involves keeping channels open, and for how long?, are retries possible? We are discussing here very low power, always sleeping nodes. Without a proxy their life is impossible anyway.
I've written conflicting PRs to either allow both () or prescribe immediate responses (). Either would be fine with me, "prescribe fetch-then-respond" does not sound like a consensus candidate from the comments. NAME and other authors: any preferences? I have a slight preference for accept-both.
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. I see what you mean: also the return of 2.04 shows in the example but not in the specification. This warrants additional text to specify the simple registration text. will add the simple registration template to the text.
Added template in section 5.3.1. simple registration
Ad "GET /.well-known/core": Our templates are already verbose, redundant with CoAP ("4.00 Bad Request and 400 Bad Request: Malformed request.", surprise) and at the same time not exhaustive (see ); I've come to accept that. But the GET section on the endpoint's .well-known/core is the very functionality that is described in RFC6690 Section 4. What is gained by duplicating that specification and selectively picking some possible error codes? I suggest we remove that part. Ad simple registration interface: Any particular reason you picked precisely ep and d to be eligible? lt definitely makes sense, and so do extra-attrs (they are our extension point, and not having them would exclude simple registration from extensibility). A pull request to that respect is pending (see link below) together with .
I think that's in a good state now with , , and the separator paragraph before the GET operation in #simple. I might have missed the point of this issue though, so not closing right away; NAME please close if you think this issue is done.

Discussion:
request as it would per registration.  The context of the registration is taken from the requesting server's URI. <ins> The Resource Directory MUST NOT query the endpoint's data before sending the response; this is to accomodate very limited endpoints. The success condition only indicates that the request was valid (ie. the passed parameters are valid per se), not that the link data could be obtained or parsed or was successfully registered into the RD. </ins> The simple registration request interface is specified as follows: EP -> RD