Change:
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

Discussion:
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