Draft: draft-ietf-webpush-protocol

Commentary: Note : push service , not push server . Otherwise , this looks good .
Paragraph (version A):
A message delivery confirmation sent from the push server to the
application server.
Paragraph (version B):
A message delivery confirmation sent from the push service to the
application server.
Paragraph (version A):
The push server MUST provide a URI for the push resource
corresponding to the push message subscription using a link relation
of type "urn:ietf:params:push".
Paragraph (version A):
The push server MUST provide a URI for a receipt subscribe resource
in a link relation of type "urn:ietf:params:push:receipt".
Paragraph (version B):
The push service MUST provide a URI for the push resource
corresponding to the push message subscription using a link relation
of type "urn:ietf:params:push".
Paragraph (version B):
The push service MUST provide a URI for a receipt subscribe resource
in a link relation of type "urn:ietf:params:push:receipt".
Paragraph (version A):
Each push message is pushed in response to a synthesized GET request.
The GET request is made to the push message resource that was created
by the push server when the application server requested message
delivery.  The response body is the entity body from the most recent
request sent to the push resource.
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.
Paragraph (version B):
Each push message is pushed in response to a synthesized GET request.
The 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 body is the entity body from the most recent
request sent to the push resource.
Paragraph (version B):
In response to this request, the push service 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):
If the application has requested a delivery receipt, the push server
MUST deliver a response to the application server monitoring the
receipt subscription resource.
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 RFC7540 to send push receipts when messages are
acknowledged (acknowledge_message) by the user agent.
Paragraph (version A):
Each receipt is pushed in response to a synthesized GET request.  The
GET request is made to the same push message resource that was
created by the push server when the application server requested
message delivery.  A successful response includes a 410 (GONE) status
code with no data.
Paragraph (version A):
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.
Paragraph (version B):
If the push service receives the acknowledgement and the application
has requested a delivery receipt, the push service MUST deliver a
success response to the application server monitoring the receipt
subscription resource.
Paragraph (version B):
If the push service does not receive the acknowledgement within a
reasonable amount of time, then the message is considered to be not
yet delivered.  The push service SHOULD continue to retry delivery of
the message until its advertised expiration.
Paragraph (version B):
The push service MAY cease to retry delivery of the message prior to
its advertised expiration due to scenarios such as an unresponsive
user agent or operational constraints.  If the application has
requested a delivery receipt, then the push service MUST deliver a
failure response to the application server monitoring the receipt
subscription resource.
Paragraph (version B):
The application server requests the delivery of receipts from the
push service 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.
Paragraph (version B):
Each receipt is pushed in response to a synthesized GET request.  The
GET request is made to the same push message resource that was
created by the push service when the application server requested
message delivery.  A successful response includes a 410 (GONE) status
code with no data.
Paragraph (version B):
If the user agent fails to acknowledge the receipt of the push
message and the push service ceases to retry delivery of the message
prior to its advertised expiration, then the push service MUST push a
failure response with a status code of 5XX (TBD).
Paragraph (version A):
Push services might need to limit the size and number of stored push
messages to avoid overloading.  In addition to using the 413 (Payload
Too Large) status code for too large push messages, a push service
MAY expire push messages prior to any advertised expiration time.  A
push service can reduce the impact push message retention by reducing
the time-to-live of push messages.
Paragraph (version B):
Push services might need to limit the size and number of stored push
messages to avoid overloading.  To limit the size of messages, the
push service MAY return the 413 (Payload Too Large) status code for
messages that are too large.  To limit the number of stored push
messages, the push service MAY either expire messages prior to their
advertised Time-To-Live or reduce their advertised Time-To-Live.
Paragraph (version A):
A push server that does not support reliable delivery over
intermittent network connections or failing applications on devices,
forces the device to acknowledge receipt directly to the application
server, incurring additional power drain in order to establish
(usually secure) connections to the individual application servers.
Paragraph (version B):
A push service that does not support reliable delivery over
intermittent network connections or failing applications on devices,
forces the device to acknowledge receipt directly to the application
server, incurring additional power drain in order to establish
(usually secure) connections to the individual application servers.
Paragraph (version A):
The public key for a subscription ensures that applications using
that subscription can identify messages from unknown sources and
discard them.  This depends on the public key only being disclosed to
entities that are authorized to send messages on the channel.  The
push server does not require access to this public key.
Paragraph (version B):
The public key for a subscription ensures that applications using
that subscription can identify messages from unknown sources and
discard them.  This depends on the public key only being disclosed to
entities that are authorized to send messages on the channel.  The
push service does not require access to this public key.