Code change:
control application were shown in Section 2.2 of RFC7390. An application group can be named in many ways through different <del> types of identifiers, such as numbers, URIs or other strings.  An application group name or identifier, if explicitly encoded in a CoAP request, is typically included in the path component or in the query component of a Group URI.  It may also be encoded using the Uri-Host Option RFC7252 in case application group members implement a virtual CoAP server specific to that application group.  The application group can then be identified by the value of the Uri-Host Option and each virtual server serves one specific application group.  However, encoding the application group in the Uri-Host Option is not the preferred method because in this case the application group cannot be encoded in a Group URI, and also the Uri-Host Option is being used for another purpose than encoding the host part of a URI as intended by RFC7252 - which is potentially confusing.  Appendix A of I-D.ietf- core-resource-directory shows an example registration of an application group into a Resource Directory (RD), along with the CoAP group it uses and the resources supported by the application group. In this example an application group identifier is not explicitly encoded in the RD nor in CoAP requests made to the group, but it implicitly follows from the CoAP group used for the request.  So there is a one-to-one binding between the CoAP group and the application group.  The "NoSec" security group is used. A best practice for encoding application group into a Group URI is to use one URI path component to identify the application group and use the following URI paths component(s) to identify the resource within this application group.  For example, /<groupname>/res1 or /base/<groupname>/res1/res2 conform to this practice.  An application group identifier (like <groupname>) should be as short as possible when used in constrained networks. </del> <ins> types of identifiers, such as name string, number, URI or other type of string.  An application group name may be explicitly encoded in a CoAP Group URI, or it may be not included in the Group URI.  This is an implementation-specific decision.  If the application group name is explicitly encoded in a CoAP Group URI, it can be encoded within one of the URI path component: this is the most common and RECOMMENDED method to encode the application group name.  A best practice for encoding application group into a Group URI is to use one URI path component to identify the application group and use the following URI paths component(s) to identify the resource within this application group.  For example, /<groupname>/res1 or /base/<groupname>/res1/res2 conform to this practice.  An application group name (like <groupname>) should be as short as possible when used in constrained networks. URI query component: using this method, the query may consist of the group name (?<groupname>) or it may be one parameter of the query (?g=<groupname> or ?param1=value1&gn=<groupname>). URI host subcomponent: using this method, the application group becomes equal to the CoAP group.  This can only be used if there is a one-to-one mapping between CoAP groups and application groups. URI port subcomponent: using this method, the application group is identified by a number that is encoded in some way in the destination port. There are also methods to encode the application group name within the CoAP request even though it is not encoded within the Group URI. Examples of such methods are: encode in a Uri-Host Option RFC7252 which is added to the CoAP request by the client before sending it out.  Each CoAP server that is part of the CoAP group, receiving this request, decodes the Uri-Host Option and treats it as an application group name. (It can also treat the application group name in this Option as a "virtual CoAP server" specific to that application group, exactly in the same way that the Uri-Host Option was intended to allow support for multiple virtual servers hosted on the same port.  The net effect of both treatments is the same.) encode in a new (custom/application-specific) CoAP Option which is added to the CoAP request by the client before sending it out. Each CoAP server that is part of the CoAP group, receiving this request, would by design understand this Option, would decode it, and treat it as an application group name. Finally, it is possible to not encode the application group name at all within the CoAP request.  This yields the most compact representation on the wire.  In this case, each CoAP server needs to determine the application group based on contextual information, such as client identity and/or target resource.  For example, each application group on a server could have a unique set of resources that does not overlap with any resources of other application groups. Appendix A of I-D.ietf-core-resource-directory shows an example registration of an application group into a Resource Directory (RD), along with the CoAP group it uses and the resources supported by the application group.  In this example an application group name "lights" is encoded in the "ep" (endpoint) attribute of the RD registration entry.  The CoAP group is ff35:30:2001:db8:f1::8000:1 and the "NoSec" security group is used. </ins> A security group is identified by a stable and invariant string used as group name, which is generally not related with other kinds of

Related discussion:
text: The best practice is something I can get behind, although I suggest using no identifier on the wire (and just the disjunct set of resources) as a byte saving alternative when the administrative effort of ensuring path uniqueness can be afforded.
Thanks; we do need to improve the current text on these aspects. On Uri-Host and your example "URL" where authority component includes the application group: in this group communication example the sending client would normally DNS-resolve "URL" to a particular multicast IP address, then send the CoAP request to this multicast IP address destination, without including any Uri-Host Option. This works as long as you have a unique 1:1 association between application-group and CoAP-group. In case multiple application-groups map to a single CoAP-group, this doesn't work anymore : a client could be e.g. configured to always include the "Uri-Host" Option to indicate the hostname. Still not the preferred approach I would think. Btw I can't follow answer A2 on the CoAP-Faq, unfortunately: formulation is too complex. In some (common?) constrained use cases, the DNS name would not even be configured in the client and the client would just be configured directly with the IPv6 multicast address of the CoAP group to send it to. Then, the application-group would need to be encoded in some way still, e.g. using the Uri-Path Option. Now what our original text tried to suggest is to "misuse" a Uri-Host Option for that. So instead of using an option like: Uri-Path = group123 You would instead use an option: Uri-Host = group123 So this is not a "real" URI hostname but rather a low-level hack to let the client's CoAP stack insert by force an additional option just before sending out the CoAP request. The receiver's CoAP stack would just parse it as the ID of the application-group and not really as a URI-host. Because this gets confusing and potentially messy (proven by the present discussion !) we don't recommend it. So, trying to reiterate if one has configured Group URIs of the form coap://[mcast-ip-address]/resource on the client then by default the Uri-Host Option would get elided. The above mentioned "hack" is to put it back to encode application-group.