Draft: draft-ietf-core-groupcomm-bis

Commentary: 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 do n't quite follow how this is not " as intended in  " : 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 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 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 is n'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 . 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 " " where authority component includes the application group : in this group communication example the sending client would normally DNS - resolve " " 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 does n'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 ca n'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 :    = group123 You would instead use an option :    = 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 do n'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 . This has the issue that the application - group name is n't present in the Group URI . if one has configured Group URIs of the form on the client then normally by default the authority gets resolved to some IP multicast address before sending it out , and thus while sending it the Uri - Host Option is NOT included in the CoAP encoding but elided . So the receiving server does n't see the application - group ID because it 's not encoded in the request data . ( We assume here that multiple application - groups use the same CoAP - group . ) Maybe we should discuss this further ; what 's the effort here / who ensures it / unique between what and what ? 
 Initial text proposed in above PR ! We 'll merge it in by tomorrow evening , as an improvement ( hopefully ) . What is not included yet is a statement saying that we do n't recommend using the non - Group - URI methods of encoding application group name . To do so we would need to clearly state why that is not recommended ; still not clear at this moment what the disadvantages of these are .
Paragraph (version A):
An application group can be named in many ways through different
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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>).
Paragraph (version B):
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.
Paragraph (version B):
URI port subcomponent: using this method, the application group is
identified by a number that is encoded in some way in the
destination port.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.