clarify discovery of application groups using well-known/core for #29

draft-ietf-core-groupcomm-bis.md

@@ -279,11 +279,21 @@ The configuration of groups and membership may be performed at different moments
 
 ### Group Discovery ###
 
-It is possible for CoAP endpoints to discover application groups as well as CoAP groups, by using the RD-Groups usage pattern of the CoRE Resource Directory (RD), as defined in Appendix A of {{I-D.ietf-core-resource-directory}}. In particular, an application group can be registered to the RD, specifying the reference IP multicast address, hence its associated CoAP group. The registration is typically performed by a Commissioning Tool. Later on, CoAP endpoints can discover the registered application groups and related CoAP group, by using the lookup interface of the RD.
+It is possible for CoAP endpoints to discover application groups as well as CoAP groups, by using the RD-Groups usage pattern of the CoRE Resource Directory (RD), as defined in Appendix A of {{I-D.ietf-core-resource-directory}}. In particular, an application group can be registered to the RD, specifying the reference IP multicast address of its associated CoAP group. The registration of groups is typically performed by a Commissioning Tool. Later on, CoAP endpoints can discover the registered application groups and related CoAP group(s), by using the lookup interface of the RD.
 
-CoAP endpoints can also discover application groups by performing a group discovery query using the /.well-known/core resource. Such a request may be sent to a known CoAP group multicast address associated to application group(s), or to the All CoAP Nodes multicast address.
+CoAP endpoints can also discover application groups and/or CoAP groups using a GET request on the /.well-known/core resource. Such a request may be sent to a known CoAP group multicast address that is associated to one or more application group(s), or to the All CoAP Nodes multicast address; and the request may be sent with or without a query component. These particular details of the request are selected depending on the intented discovery action of the client and on the particular encoding of group names in names and/or attributes of resources which is application-specific. The following types of request may typically be used:
 
-When secure communication is provided with Group OSCORE (see {{chap-oscore}}), the approach described in {{I-D.tiloca-core-oscore-discovery}} and also based on the RD can be used, in order to discover the security group to join.
+* Discovery of all application groups that are part of a CoAP group. For example, in case the application group name is encoded in the URI path as "/grp/\<groupname\>" then the discovery query may use URI "/.well-known/core?href=/grp/*" and it is sent to the IP multicast address of the CoAP group. The query matches any application group name.
+
+* Discovery of a particular application group with a known name. For example, in case the known application group name is "mygroup1" and is encoded in the URI path as "/grp/\<groupname\>" then the discovery query may use URI "/.well-known/core?href=/grp/mygroup1" and it is sent to the IPv6 All CoAP Nodes multicast address of a particular chosen scope (e.g. site-local, or realm-local). The result of this query is a list of CoAP servers that are a member of "mygroup1".
+
+* Discovery of all application groups of a particular type. For example, in case the application group type is "mytype1" and is encoded as a resource type (rt) attribute of the application group resource, and the application group resource is "/grp/\<groupname\>" then the discovery query may use URI "/.well-known/core?rt=mytype1" and it is sent to the All CoAP Nodes multicast address. The query result is a list of CoAP servers that have at least one application group of type "mytype1" and each server response identifies one or more application group name(s) of type "mytype1".
+
+* Discovery of all application groups that are configured on the client's 6LoWPAN wireless mesh network. In the following example a request without query is used. So, the URI "/.well-known/core" is used and the request is sent to the IPv6 All CoAP Nodes multicast address of realm-local scope. Each CoAP server (including any application group members) will return a list of its resources, which in this example includes the resources used to encode the application group name. If each application group resource is known to be "/g/\<groupname\>" then the client marks each returned resource under the root resource "/g" as a discovered application group. Not using a query has the disadvantage that potentially a lot of response traffic will be generated on the mesh network, including responses from servers that are not a member of any application group. But it may be needed in particular use cases, e.g. if some of the CoAP servers do not support the optional link format query functionality (as mentioned in {{Section 4.1 of RFC6690}}).
+
+Note that all the above examples are application-specific; there is currently no standard way of encoding application group names or CoAP group names in CoAP resources and/or CoRE link attributes.
+
+When secure communication is provided with Group OSCORE (see {{chap-oscore}}), the approach described in {{I-D.tiloca-core-oscore-discovery}} also based on the RD can be used, in order to discover the security group to join.
 
 In particular, the responsible OSCORE Group Manager registers its own security groups to the RD, as links to its own corresponding resources for joining the security groups {{I-D.ietf-ace-key-groupcomm-oscore}}. Later on, CoAP endpoints can discover the registered security groups and related application groups, by using the lookup interface of the RD, and then join the security group through the respective Group Manager.