Change:
All URIs of RD APIs are discovered standalone, and no relative URI or path-appending is required any more. Therefore, the term "Base URIs" and the distinction between "rd-lookup-base" and "lookup-type" in the RD lookup API are obsolete. This has already been , and , if I understood his response correctly (which I'm unsure about, thus tagging this for review).
I'd consider toning down the default value recommendations a different issue; is it fine with you apart from that? (Note to self: I accidentally dropped the "res:= " parameter here; that's another topic and shouldn't go in that commit.)
There is still some weirdness here: The "URIs" here are still parameters for URI templates, not the actual URIs that will be used for accesses.
Good point. Going from to should address that, I'll update accordingly.
I've updated the pull request to address the comments, and fixed some oversights of mine. While the first commit has been modified, the changes should largely be review friendly in that the three last commits are the newly introduced ones for NAME template weirdness NAME "recommended" → "example" rewording and some more "base" occurrences I had missed, together with clearer naming of the "RD registration URI" instead of just "RD (base) URI" which might cause confusion with the "RD URIs" (the "RD lookup URIs" and the "RD group URI") in general.
Merged as agreed in last call.
It is argued that a recommended base path is not appropriate. At line 593: "the value /rd is recommended", should be: "the value /rd is an example value". Hello Peter, among those, I just happened to note that instead of (say) being advertised as URL (which would then have triggered string-appending "/ep" to it), the individual records are now advertised. Much appreciated; this makes implementation of resource trees smoother! (Actually I found an inconsistency of my implementation of -09, and looking it up, it was fixed in this version I had not read before). It does add one easily fixed quirx, however: In the lookup URI template, there's now /{+rd-looup-base}/{lookup-type}. Is that distinction still needed? The base can't be discovered now any more, so I'd say this now should be | URI Template: /{+type-lookup}{?d,...} | | type-lookup := RD lookup location (mandatory). Discovered for a given | type in .well-known/core by its resource type, where it SHOULD be | listed. The recommended value for this variable is: | "/rd-lookup/{type}". Mandatory to be present for types "ep" and | "res", optional for "d" and "gp". (Or maybe you they can stay "base URIs", but be many; that's only terminology then). I've gone through the rest of the document; "is used to discover the base URI for RD Lookup operations" would need to speak of "URIs". Sounds good now. The term "Simple directory discovery" was dropped from the descriptions but survived in 5.3.3; it should probably say "simple registration" there. Other notes (some on nitpicking level, but if we're at WGLC level I suppose that's OK): 5.2 mentions '"URL" is used to discover the base URI for RD group operations'. Shouldn't this be "URL"? (Unsure as not yet really familiar with all the groupcom things). 5.2 lists HTTP support but no HTTP response codes 5.2 first request/response example: needless quotes about a ct 5.3 example: The HTTP requester will probably want to set a con= too unless it actually sends the HTTP request from its port 80. 'The domain lookup returns every lookup domain with a base RD resource value (e.g. "/rd") encapsulated within angle brackets.' (and similarly the following group paragraph): This sounds contradictory to the example given later (which returns '<>;d="domain1"'), where nothing is encapsulated in the angle brackets. 9.3 "con" entry: Since the latest changes this should include "path" too. 10.1.2: In the requests from the CT, the domain parameter is given per-resource in the payload. Isn't that exclusively used as a query parameter in registration? Later in the group setup POST, the semicolons after the <> are missing in the payload, and the colon in 'coap//' in the con parameter, which has abundant quotation marks. 10.2: "./well-known/core" -> "/." I haven't updated my implementation yet, but don't see any trouble on that road. Looks good to me, all things considered. Best regards Christian To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
Hi Christian, Thank for the feedback; see below. Christian Amsüss schreef op 2017-03-16 17:43: Good to read. URIs it will be; rd-lookup-base is also used later; and is an understandable concept. agreed. not yet. No opinion. see what the co-authors think. Correct; correct, again. good suggestions Yep, have to solve that one way or the other. mistakes come and go, in spite of github change it, thanks for looking at it. thanks again. there is also another instance; also here mistakes come and go. Many thanks, peter

Discussion:
expected that RDs will also be discoverable via other methods depending on the deployment. <del> Discovery of the RD URI paths is performed by sending either a multicast or unicast GET request to "/.well-known/core" and including a Resource Type (rt) parameter RFC6690 with the value "core.rd" in the query string.  Likewise, a Resource Type parameter value of "core.rd-lookup*" is used to discover the base URI for RD Lookup </del> <ins> Discovery of the RD registration URI path is performed by sending either a multicast or unicast GET request to "/.well-known/core" and including a Resource Type (rt) parameter RFC6690 with the value "core.rd" in the query string.  Likewise, a Resource Type parameter value of "core.rd-lookup*" is used to discover the URIs for RD Lookup </ins> operations, and "core.gp" is used to discover the URI path for RD Group operations.  Upon success, the response will contain a payload with a link format entry for each RD function discovered, indicating

YES (Unicast only) The following example shows an endpoint discovering an RD using this <del> interface, thus learning that the base RD resource is, in this example, at /rd and that the content-format delivered by the server hosting the resource is application/link-format (ct=40).  Note that it is up to the RD to choose its RD resource paths. </del> <ins> interface, thus learning that the RD registration resource is, in this example, at /rd, and that the content-format delivered by the server hosting the resource is application/link-format (ct=40).  Note that it is up to the RD to choose its RD resource paths. </ins> The following example shows the way of indicating that a client may request alternate content-formats.  The Content-Format code attribute

Content-Format 40 (application/link-format) indicated as well as a more application-specific content format (picked as 65225 in this example; this is in the experimental space, not an assigned value). <del> The base RD resource values /rd, /rd-lookup, and /rd-group are example values.  This server only implements some of the interfaces described in this document. </del> <ins> The RD resource paths /rd, /rd-lookup, and /rd-group are example values.  This server only implements some of the interfaces described in this document. </ins> 5.3.

<del> RD URI (mandatory).  This is the location of the RD, as obtained from discovery. </del> <ins> RD registration URI (mandatory).  This is the location of the RD, as obtained from discovery. </ins> Endpoint name (mandatory).  The endpoint name is an identifier that MUST be unique within a domain.  The maximum length of

The following example shows an EP registering a group with the name "lights" which has two endpoints to an RD using this interface.  The <del> base location value /rd-group is an example RD location discovered in a request similar to example-discovery. </del> <ins> RD group path /rd-group is an example RD location discovered in a request similar to example-discovery. </ins> 6.2.

8.2. Access control SHOULD be performed separately for the RD <del> registration, Lookup, and group API base paths, as different endpoints may be authorized to register with an RD from those authorized to lookup endpoints from the RD.  Such access control SHOULD be performed in as fine-grained a level as possible.  For example access control for lookups could be performed either at the domain, endpoint or resource level. </del> <ins> registration, Lookup, and group API paths, as different endpoints may be authorized to register with an RD from those authorized to lookup endpoints from the RD.  Such access control SHOULD be performed in as fine-grained a level as possible.  For example access control for lookups could be performed either at the domain, endpoint or resource level. </ins> 8.3.

10.2.2. LWM2M defines a registration interface based on the REST API, <del> described in rd.  The base URI path of the LWM2M Resource Directory is specified to be "/rd". </del> <ins> described in rd.  The RD registration URI path of the LWM2M Resource Directory is specified to be "/rd". </ins> LWM2M endpoints register object IDs, for example </1>, to indicate that a particular object type is supported, and register object