jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-webpush-protocol

Commentary: LGTM , just one nit . 
 I think that having the push service return the link relation on requests to subscriptions ( and subscription sets ) is enough . I think that perhaps it was to push messages in error . 
 cc
Paragraph (version A):
Each push message is pushed as the response to a synthesized GET
request in a PUSH_PROMISE.  This GET request is made to the push
message resource that was created by the push service when the
application server requested message delivery.  The response headers
SHOULD provide a URI for the push resource corresponding to the push
message subscription in a link relation of type
"urn:ietf:params:push" and a URI for the receipt subscribe resource
in a link relation of type "urn:ietf:params:push:receipt".  The
response body is the entity body from the most recent request sent to
the push resource by the application server.
Paragraph (version B):
Each push message is pushed as the response to a synthesized GET
request in a PUSH_PROMISE.  This GET request is made to the push
message resource that was created by the push service when the
application server requested message delivery.  The response headers
SHOULD provide a URI for the push resource corresponding to the push
message subscription in a link relation of type
"urn:ietf:params:push".  The response body is the entity body from
the most recent request sent to the push resource by the application
server.
Paragraph (version A):
Each push message is pushed as the response to a synthesized GET
request sent in a PUSH_PROMISE.  This GET request is made to the push
message resource that was created by the push service when the
application server requested message delivery.  The synthetic request
MUST provide a URI for the push resource corresponding to the push
message subscription in a link relation of type
"urn:ietf:params:push".  This enables the user agent to differentiate
the source of the message.  The response headers SHOULD provide a URI
for the receipt subscribe resource in a link relation of type
"urn:ietf:params:push:receipt".  The response body is the entity body
from the most recent request sent to the push resource by an
application server.
Paragraph (version B):
Each push message is pushed as the response to a synthesized GET
request sent in a PUSH_PROMISE.  This GET request is made to the push
message resource that was created by the push service when the
application server requested message delivery.  The synthetic request
MUST provide a URI for the push resource corresponding to the push
message subscription in a link relation of type
"urn:ietf:params:push".  This enables the user agent to differentiate
the source of the message.  The response body is the entity body from
the most recent request sent to the push resource by an application
server.
Draft: draft-ietf-webpush-protocol

Commentary: Removed references to HTTP cache headers and  
 LGTM 
 Tracking Darshak Thakore feedback : There was ambiguity about the type of " expiration information " returned : Also I 'm assuming here that the " expiration information " refers to the expiration info of the push messages ( i.e their TTL ) , correct ? has a small clarification : but an example should be developed . 
 As discussed on the , the use of HTTP cache headers for graceful subscription expiration was deprecated .
Paragraph (version A):
In response to this request, the push server MUST generate a server
push for all push messages that have not yet been delivered.  In
addition, the push service SHOULD return link references to the push
and receipt subscribe resources, plus expiration information for the
subscription.
Paragraph (version B):
In response to this request, the push server MUST generate a server
push for all push messages that have not yet been delivered.  In
addition, the push service SHOULD return link references to the push
and receipt subscribe resources.
Paragraph (version A):
A push service might choose to set a fixed expiration time.  If a
resource has a known expiration time, expiration information is
included in responses to requests that create the resource, or in
requests that retrieve a representation of the resource.
Paragraph (version A):
Expiration is indicated using either the Expires header field, or by
setting a "max-age" parameter on a Cache-Control header field (see
RFC7234).  The Cache-Control header field MUST also include the
"private" directive.
Draft: draft-ietf-webpush-protocol

Commentary: closed closed renamed draft - thomson - webpush- to draft - ietf - webpush- updated the HTTP/2 reference updated the alt - svc reference 
 From   feedback :     header to Section 5 example Reference in Section 5.1 
 From   review : Section 5 - In the example , Is the post operation to the right URL ? Is that just an editorial oversight or is that the intended URL ? Current example : POST /p / LBhhw0OohO - Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Probably should be : POST /p / JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 The current example is incorrect . It should match the urn : ietf : params : push link relation returned in the Subscription response - /p / JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV - and distributed to the application server .
Paragraph (version A):
Examples in this document use the RFC7230.  Many of the exchanges can
be completed using HTTP/1.1, where HTTP/2 is necessary, the more
verbose frame format from I-D.ietf-httpbis-http2 is used.
Paragraph (version B):
Examples in this document use the RFC7230.  Many of the exchanges can
be completed using HTTP/1.1, where HTTP/2 is necessary, the more
verbose frame format from RFC7540 is used.
Paragraph (version A):
A user agent requests the delivery of new push messages by making a
GET request to a push message subscription resource.  The push
service does not respond to this request, it instead uses I-D.ietf-
httpbis-http2 to send the contents of push messages as they are sent
by application servers.
Paragraph (version B):
A user agent requests the delivery of new push messages by making a
GET request to a push message subscription resource.  The push
service does not respond to this request, it instead uses RFC7540 to
send the contents of push messages as they are sent by application
servers.
Paragraph (version A):
The application server requests the delivery of receipts from the
push server by making a HTTP GET request to the receipt subscription
resource.  The push service does not respond to this request, it
instead uses I-D.ietf-httpbis-http2 to send push receipts when
messages are acknowledged (acknowledge_message) by the user agent.
Paragraph (version B):
The application server requests the delivery of receipts from the
push server by making a HTTP GET request to the receipt subscription
resource.  The push service does not respond to this request, it
instead uses RFC7540 to send push receipts when messages are
acknowledged (acknowledge_message) by the user agent.
Draft: draft-thomson-webpush-protocol

Commentary: probably is n't closed by this .
Paragraph (version B):
The push server MUST push a response with a status code of 5XX (TBD)
if the user agent fails to acknowledge the receipt of the push
message or the push server fails to deliver the message prior to its
expiration.