Original text:
to-machine communication across networks of constrained devices. CoAP uses a request/response model where clients make requests to servers in order to request actions on resources.  Depending on the <del> situation the same device may act either as a server or a client. </del>  One important class of constrained devices includes devices that are intended to run for years from a small battery, or by scavenging connecting to a device from the Internet unless the connection was initiated by the device. <del> This document specifies the means for nodes with limited reachability to communicate using simple extensions to CoAP.  The extensions enable publish-subscribe communication using a Broker node that enables store-and-forward messaging between two or more nodes. Furthermore the extensions facilitate many-to-many communication using CoAP. </del>  2. indicated by a link-format content-format.  Sub-topics are also topics and may have their own sub-topics, forming a tree structure of unique paths that is implemented using URIs.  The full URI of a topic <del> includes a schems and authority for the Broker, for example </del>  "coaps://10.0.0.13:5684/EP-33543/sen/3303/0/5700". 3.5. If the Broker is unable to serve a certain client that is sending publish messages too fast, the Broker SHOULD respond with Response <del> Code 4.29, "Too Many Requests" I-D.keranen-core-too-many-reqs and set </del>  the Max-Age Option to indicate the number of seconds after which the client can retry.  The Broker MAY stop creating notifications from the publish messages from this client and to this topic for the

Reviewer comments:
This mechanism is also useful for cases where the pub/sub paradigm instead of classic req/resp is desired (one-to-many, many-to-one, many-to-many communications, etc.).

Revised text:
to-machine communication across networks of constrained devices. CoAP uses a request/response model where clients make requests to servers in order to request actions on resources.  Depending on the  <ins> situation the same device may act either as a server, a client, or both. </ins> One important class of constrained devices includes devices that are intended to run for years from a small battery, or by scavenging connecting to a device from the Internet unless the connection was initiated by the device.  <ins> For some applications the client/server and request/response communication model is not optimal but publish-subscribe communication with potentially many senders and/or receivers and communication via topics rather than directly with endpoints may fit better. This document specifies simple extensions to CoAP for enabling publish-subscribe communication using a Broker node that enables store-and-forward messaging between two or more nodes.  This model facilitates communication of nodes with limited reachability, enables simple many-to-many communication, and eases integration with other publish-subscribe systems. </ins> 2. indicated by a link-format content-format.  Sub-topics are also topics and may have their own sub-topics, forming a tree structure of unique paths that is implemented using URIs.  The full URI of a topic  <ins> includes a scheme and authority for the Broker, for example </ins> "coaps://10.0.0.13:5684/EP-33543/sen/3303/0/5700". 3.5. If the Broker is unable to serve a certain client that is sending publish messages too fast, the Broker SHOULD respond with Response  <ins> Code 4.29, "Too Many Requests" I-D.ietf-core-too-many-reqs and set </ins> the Max-Age Option to indicate the number of seconds after which the client can retry.  The Broker MAY stop creating notifications from the publish messages from this client and to this topic for the