Code change:
This allows registration without endpoint names, which is important for clients that only keep their absolutely essential cryptographic state (see URL, which this closes). The wording in simple registration was changed to not repeat the individual parameters of registration but to only refer there.
Currently, we prescribe that the registering endpoint needs to identify itself with at least an endpoint name, while we allow the RD to be configured to assign a domain based on its configuration. We could allow the endpoint identifier to be absent as well, at least in principle (eg. make it a "SHOULD be set" but no syntactical requirement on its presence), and the RD's configuration then would need to set an endpoint name (like it can now do with a domain), or the RD would refuse the registration like it can now do for unauthenticated hosts. (The RD interface right now doesn't allow a 4.01 Unauthorized response, even though the security considerations indicate that that can happen.) This would allow endpoints that have just enough persistent state to have their cryptographic identity in form of a PSK to register at the RD. Note that for those cases (and PSK seems not to be too uncommon in the CoRE security scenarios), the RD already needs to have received (or have a way to fetch) configuration about that key, which easily can contain a default (or the only permissible) endpoint name for that key. I'd write a pull request to that respect unless controversial discussion about this starts here. (This was fleshed out from in a discussion with Pekka Nikander during ACM ICN about very constrained devices).
First, domain is optional. The RD should not invent a domain for registrations that did not include a domain parameter. If the RD sets the endpoint name, then a client should be able to learn it from the registration resource, which will then depend on the implementation of read from the rd resource returning the registration parameters in the link for the registration resource, and/or the inclusion of a "self" link in the registration resource that includes "ep" as a link attribute.
Currently, we say that "When this parameter is elided, the RD MAY associate the endpoint with a configured default domain." (And it doesn't say that that default would be the absent domain). It'd need to learn it from the registration resource's metadata (because the registration resource contains right what the host posted, and a self-link would be semantically ambiguous there), but it can be looked up like that: POST /rd: ;rt="temp" Created, Location: /registration/42 GET /rd-lookup/ep?href=/registration/42 Content: ;con="coaps://your-address";ep="what-i-decided" I doubt that those nodes would be really interested in doing that (I reckon they'd even tend to do simple registrations which won't even tell them their registration resource), but they can. Best regards Christian
To add to my example, the client could just as well have asked to get the same result, although I'd recommend that a client in that situation should use the query instead. NAME would that lookup interface address your concerns? Unless not, I'd go ahead and write a patch that allows such behavior (but makes it clear that this can only be used where explicitly configured or allowed in a given setting).
The changes in implement the proposed. With many things now using registration resources rather than names (cf. ), I frankly don't see a reason to mandate names anywhere (Why would a group need a name? The operations don't require it, and we sure can store one if the user desires; same for the end point…), but I won't stir that any further (we should finish rather than starting such discussions; I'd be game for it, but milestones says hurry), as just allowing the name to be configured is sufficient for the ACM ICN use case.

Related discussion:
text: requests at the requesting server's default discovery URI to obtain the link-format payload to register. <del> The endpoint MUST include the endpoint name and MAY include the registration parameters d, lt and extra-attrs, in the POST request as per registration.  The context of the registration is taken from the requesting server's URI. </del> <ins> The endpoint includes the same registration parameters in the POST request as it would per registration.  The context of the registration is taken from the requesting server's URI. </ins> The endpoints MUST be deleted after the expiration of their lifetime. Additional operations cannot be executed because no registration