jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-pubsub

Commentary: removed duplicate description of hierarchy , a constraint to allow only one topic to be created at a time , text to allow additional target attributes in links for created topics
A CoAP pub/sub broker SHOULD allow Clients to create new topics on
the broker using CREATE.  Some exceptions are for fixed brokerless
devices and pre-configured brokers in dedicated installations.  A
client wishing to create a topic MUST use a CoAP POST to the pub/sub
API with a payload indicating the desired topic.  The topic
specification sent in the payload MUST use a supported serialization
of the CoRE link format RFC6690.  The target of the link MUST be a
URI formatted string.  The client MUST indicate the desired content
format for publishes to the topic by using the ct (Content Format)
link attribute in the link-format payload.  The client MAY indicate
the lifetime of the topic by including the Max-Age option in the
CREATE request.
Topics may be created as sub-topics of other topics.  A client MAY
create a topic with a ct (Content Format) link attribute value which
describes a supported serialization of the CoRE link format RFC6690
such as application/link-format (ct=40) or its JSON or CBOR
serializations.  If a topic is created which describes a link
serialization, that topic may then have sub-topics created under it
as shown in create-sub-fig.
A CoAP pub/sub broker SHOULD allow Clients to create new topics on
the broker using CREATE.  Some exceptions are for fixed brokerless
devices and pre-configured brokers in dedicated installations.  A
client wishing to create a topic MUST use a CoAP POST to the pub/sub
API with a payload indicating the desired topic.  The topic
specification sent in the payload MUST use a supported serialization
of the CoRE link format RFC6690.  The target of the link MUST be a
URI formatted string.  The client MUST indicate the desired content
format for publishes to the topic by using the ct (Content Format)
link attribute in the link-format payload.  Additional link target
attributes and relation values may be included in the topic
specification link whena topic is created.
The client MAY indicate the lifetime of the topic by including the
Max-Age option in the CREATE request.
A topic creator MUST include exactly one content format link
attribute value (ct) in the create payload.  If the Broker does not
support the indicated format for both publish and subscribe, it MUST
reject the operation with an error code of 4.00 "Bad Request".
A topic creator MUST include exactly one content format link
attribute value (ct) in the create payload.  If the Broker does not
support the indicated format for both publish and subscribe, or if
there is more than one "ct" value included in the request, the Broker
MUST reject the operation with an error code of 4.00 "Bad Request".
Only one topic may be created per request.  If there is more than one
link included in a CREATE request, the Broker MUST reject the
operation with an erroro code of 4.00 "Bad Request".
Draft: draft-ietf-core-pubsub

Commentary: 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 . ) .
The Constrained Application Protocol (CoAP) RFC7252 supports machine-
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
situation the same device may act either as a server or a client.
The Constrained Application Protocol (CoAP) RFC7252 supports machine-
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
situation the same device may act either as a server, a client, or
both.
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.
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.
includes a schems and authority for the Broker, for example
"coaps://10.0.0.13:5684/EP-33543/sen/3303/0/5700".
includes a scheme and authority for the Broker, for example
"coaps://10.0.0.13:5684/EP-33543/sen/3303/0/5700".
If the Broker is unable to serve a certain client that is sending
publish messages too fast, the Broker SHOULD respond with Response
Code 4.29, "Too Many Requests" I-D.keranen-core-too-many-reqs and set
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
indicated time.
If the Broker is unable to serve a certain client that is sending
publish messages too fast, the Broker SHOULD respond with Response
Code 4.29, "Too Many Requests" I-D.ietf-core-too-many-reqs and set
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
indicated time.
Draft: draft-ietf-core-pubsub

Commentary: draft version to upload for IETF 102
Topics in the broker may be created in hierarchies (see {create})
with parent topics having sub-topics.  For a discovery the broker may
choose to not expose the sub-topics in order to limit amount of topic
links sent in a discovery response.  The client can then perform
discovery for the parent topics it wants to discover the sub-topics.
A CoAP pubsub Broker SHOULD allow Clients to create new topics on the
Broker using CREATE.  Some exceptions are for fixed Brokerless
devices and pre-configured Brokers in dedicated installations.  A
client wishing to create a topic MUST use CoAP POST to the pubsub API
with a payload indicating the desired topic.  The topic specification
sent in the payload MUST use a supported serialization of the CoRE
link format RFC6690.  The target of the link MUST be a URI formatted
string.  The client MUST indicate the desired content format for
publishes to the topic by using the ct (Content Format) link
attribute in the link-format payload.  The client MAY indicate the
lifetime of the topic by including the Max-Age option in the CREATE
request.
A CoAP pub/sub broker SHOULD allow Clients to create new topics on
the broker using CREATE.  Some exceptions are for fixed brokerless
devices and pre-configured brokers in dedicated installations.  A
client wishing to create a topic MUST use a CoAP POST to the pub/sub
API with a payload indicating the desired topic.  The topic
specification sent in the payload MUST use a supported serialization
of the CoRE link format RFC6690.  The target of the link MUST be a
URI formatted string.  The client MUST indicate the desired content
format for publishes to the topic by using the ct (Content Format)
link attribute in the link-format payload.  The client MAY indicate
the lifetime of the topic by including the Max-Age option in the
CREATE request.
Topic hierarchies can be created by creating parent topics.  A parent
topic is created with a POST using ct (Content Format) link attribute
value which describes a supported serialization of the CoRE link
format RFC6690, such as application/link-format (ct=40) or its JSON
or CBOR serializations.  If a topic is created which describes a link
serialization, that topic may then have sub-topics created under it
as shown in create-sub-fig.
Draft: draft-ietf-core-pubsub

Commentary: The description should be just a few words ( )
Description: Add No Content response to GET to the existing
definition of the 2.07 response code.
Draft: draft-ietf-core-pubsub

Commentary: change MAY to SHOULD and add clarifying text
A CoAP pubsub broker MAY allow Clients to create new topics on the
broker using CREATE.  A client wishing to create a topic MUST use
CoAP POST to the pubsub API with a payload indicating the desired
topic.  The topic specification sent in the payload MUST use a
supported serialization of the CoRE link format RFC6690.  The target
of the link MUST be a URI formatted string.  The client MUST indicate
the desired content format for publishes to the topic by using the ct
(Content Format) link attribute in the link-format payload.  The
client MAY indicate the lifetime of the topic by including the Max-
Age option in the CREATE request.
A CoAP pubsub broker SHOULD allow Clients to create new topics on the
broker using CREATE.  Some exceptions are for fixed brokerless
devices and pre-configured brokers in dedicated installations.  A
client wishing to create a topic MUST use CoAP POST to the pubsub API
with a payload indicating the desired topic.  The topic specification
sent in the payload MUST use a supported serialization of the CoRE
link format RFC6690.  The target of the link MUST be a URI formatted
string.  The client MUST indicate the desired content format for
publishes to the topic by using the ct (Content Format) link
attribute in the link-format payload.  The client MAY indicate the
lifetime of the topic by including the Max-Age option in the CREATE
request.