Change:
See issue discussion. Closes: URL Action if not commented on: merge.
copa -> coap
Thanks, fixed and merged.
Preparing for the IETF100 presentation I reviewed the role of groups in the RD, and given they are introduced with a focus on being discoverable multicast groups, I think I may have left that out of consideration when generalizing the lookup operations. There might be a class of desirable lookup operations that queries for resources on a multicast address: "Which resources are there in a multicast group?", the answer to which question would be typed links targetting a multicast address; in terms of -12's lookup examples: Req: GET /rd-lookup/XXX&rt="light" ;rt="light";anchor="coap://[ff35:30:2001:db8::1]", ;rt="light";anchor="coap://[ff35:30:2001:db8::1]" I'm unsure as to how that query should be formed exactly, and which links should be listed (those available on some devices? those on all?), but I think that those links should be in some form discoverable. Are such links something we want to make discoverable in an RD? Do we have enough information to decide which resources are accessible in a group? What metadata do we have on those links? (Eg. is it rt="light" if all nodes that have such a relative reference say it is?) If we can't or don't want supply those links (yet), is it justified to introduce groups as a "logical grouping of endpoints for the purpose of group communications", when all there is to it w/rt group communication is the ability to tell its multicast address in a group attribute? Strawman proposal assuming all links are valid candidates: Add an optional-to-implement lookup interface Group Resource (URL). It returns only links whose anchor was originally a relative reference, and re-interprets them once for each addressed group the link's endpoint is member of. Links that have become duplicate (as keyed by target, anchor and rel) are aggregated into one link, and their attribute lists are reduced to only those attributes common to all links in the aggregate. (rt=, if= and ct= attributes are not filtered out when they mismatch between the aggregated links, but are limited to their intersection value set.) The links are filtered after aggregation, and can match as aggregates, match their group or match an attribute present on all the endpoints whose links were aggregated.
Hi Chris, valid question. I seem to remember that in a distant past the links were specified with the group in the con parameter. That was then still possible. Add the links in the payload? FYI: RFC 7390 specifies names and MC addresses. chrysn schreef op 2017-11-12 06:46:
Hi Chris, not sure if I understood completely. A group lookup is like an ep lookup with multiple ep targets. The following seems a reasonable query to me: GET /rd-lookup/gp?con="coap://[ff35:30:2001:db8::1] which returns all eps with the specified MC address. The next query can be specified to find the resources of the returned eps. Seems perfectly OK to me; may be introduce such an example?
Hi Chris, a proposed addition to RD section 7.4 lookup examples Section 7.3 of RD says: “A search criterion matches an endpoint if it matches the endpoint itself or any of the groups it is contained in, and one on a resource if it matches the resource, the resource's endpoint, or any of the endpoint's groups.” Accordingly, the following example is proposed: Suppose a group light exists with two registrations, with endpoint names mylt1 and mylt2, where each registration contains one resource with rt=light. A resource lookup is wanted that requests the resources belonging to group lights. The RD returns the resources that are returned by the sequential invocation of the resource lookup of mylt1 and mylt2. Req: GET /rd-lookup/res?gp=light&rt=light Res: 2.05 Content <coap://[2001:db8:3::125]:61616/res/0;rt=”light”;ep=”myep1”;ct=40; anchor=”coap://[2001:db8:3:125]:61616”, <coap://[2001:db8:3::127]:61616/res/0;rt=”light”;ep=”myep2”;ct=40; anchor=”coap://[2001:db8:3:127]:61616”
The last example proposed already works. What I'm talking about in this issue is finding which resources there are that are, ie. which paths are reasonable to pack into a request going to a multicast address. As agreed in the last meeting, that issue can be solved by an additional document if the need arises. I'm writing a one-paragraph PR to add a statement about this, but the issue can be closed both by accepting that PR and by rejecting it with "no reason to say that, because any extension can be added later, no ned to enumerate them".
Note from far-later: If we accept the new-groups branch, this issue will be trivially solved as each group can be queried for its resources at and similar. All the open questions of how to know which resources are shared are resolved by that data being explicitly input into the RD.

Discussion:
lookup mechanism for the resources that can be accessed on a group's multicast address (ie. no lookup will return links like "<coap://[ff35:30:2001:db8::1]/light>;..." for a group registered <del> with "con=copa://[ff35...]").  Such an additional lookup interface </del> <ins> with "con=coap://[ff35...]").  Such an additional lookup interface </ins> could be specified in an extension document. 7.3.