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: more details on encoding application group name, for
Reading the paragraph after "An application group can be named in many ways", I was left a bit confused: Why should it be encoded in the Uri-Query? That'd need coordination among all applications running on that host (for it is interfering with the query argument space that's usually left for the application to use). The common partitioning of applications inside a host is left-to-right in the URI, and that puts it in the very last spot. I think I do see what is meant by the discouragement of using the Uri-Host, but doubt that it'd be immediately obvious to general readers. How I understand Uri-Host to be impractical here is that while the request is sent to a well-defined and named URI, the response is a representation of the same URI with the individual server's IP replaced into the authority component, and if two application groups on the same CoAP group use the same path, then there may be clashes, not on the request-response layer (where the responses are bound to request for a particular host name) but in the client's cache of the responses. (And once one is at the point where application groups in the same CoAP group have a disjunct path set, one can do away with identification altogether and just address the unique path). I don't quite follow how this is not "as intended in RFC7252": It is an identifier for who is being addressed, and as such just part of the URI. (For example, if I define my lights group to be named URL and name the resource , then the host name is exactly the group name, and already needs to be put into the request unless there is known URI aliasing). See also URL on "send a Uri-Host" option, with the caveat that I'm a strong proponent of answer A2. Furthermore, the text seems to imply that virtual hosting is something a server would need to go out of its way to implement. It isn't: The Uri-Host option is critical, and a host needs to make the conscious decision to ignore that option; otherwise it's just as much part of finding the addressed resource as all the other Uri-* options are.