Draft: draft-ietf-webpush-protocol

Commentary: Also : Updated Alt - Svc references Clarified that subscription expiration returns 404 to avoid conflict with 410 for receipts Moved 429 and 413 cases from section 5 to appropriate operational sections Return 400 for requests with invalid subscription sets 
 This is good . I have a further question about 400 responses when subscription sets / receipt subscriptions are invalid , but I 'll raise an issue . 
 In , notes that the creation of a subscription - either by the user agent or application server - should be rejected if the secondary information is invalid . I think that for a user agent , this is fine . They only talk to a single push service . However , for the receipt subscription there is a potential hazard . In that direction , the application server has no overt knowledge about the relationship between two push resources . That means that it is left to guess which are the same and which are different . Are and the same ? Would it be reasonable to expect that I can take the receipt subscription returned from the former and pass it to the latter ? I think that we need a simple rule here : if the origin ( scheme , host , port ) is the same , then the application server SHOULD attempt to reuse the receipt subscription . That makes the choice in correct and safe . It makes the example deployment above more difficult , but I do n't think that we have anyone doing this ( /cc for comment here ) . If a server can not validate that a receipt subscription that it provided itself , then we have a big issue . This also avoids the implication from the proposed text that says that a receipt subscription obtained from has to be validated somehow when passed to . 
 Agreed , these are not the same . If the receipt resource is relative as shown in the PR , then I 'd expect it to be relative to the scheme , host , and port matching . 
 How about : For future receipt requests to the same origin <   , the application server SHOULD include the returned receipt subscription to allow the push service to aggregate receipts . The push service SHOULD return the same receipt subscription in its response , although it MAY return a new receipt subscription if it is unable to reuse the one provided by the application server . 
 WFM 
 To be presented at IETF95 for further discussion - original on the mailing list . 
 Based on discussion at IETF 95 - will create a pull request for review that integrates the receipt simplification proposal and the addition of " subscription sets " for application server receipts .
Paragraph (version A):
In cases where normative language needs to be emphasized, this
document falls back on established shorthands for expressing
interoperability requirements on implementations: the capitalized
words "MUST", "MUST NOT", "SHOULD" and "MAY".  The meaning of these
is described in RFC2119.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Paragraph (version A):
This resource is used to create push message subscriptions (see
message_subscription).  A URL for the push service is configured
into user agents.
Paragraph (version B):
This resource is used to create push message subscriptions
(message_subscription).  A URL for the push service is configured
into user agents.
Paragraph (version A):
A push resource is used by the application server to request the
delivery of a push message (see send).  A link relation of type
"urn:ietf:params:push" identifies a push resource.
Paragraph (version A):
A push message resource is created to identify push messages that
have been accepted by the push service.  The push message resource
is also used to acknowledge receipt of a push message.
Paragraph (version A):
A receipt subscribe resource is used by an application server to
create a receipt subscription (see receipt_subscription).  A link
relation of type "urn:ietf:params:push:receipts" identifies a
receipt subscribe resource.
Paragraph (version A):
An application server request_receipt for push messages using a
receipt subscription.  A link relation of type
"urn:ietf:params:push:receipt" is identifies a receipt
subscription.
Paragraph (version B):
An application server send of a push message using a push
resource.  A link relation of type "urn:ietf:params:push"
identifies a push resource.
Paragraph (version B):
The push service creates a push message resource to identify push
messages that have been send.  The push message resource is also
deleted by the user agent to acknowledge_message of a push
message.
Paragraph (version B):
An application server request_receipt for push messages using a
receipt subscription.  A link relation of type
"urn:ietf:params:push:receipt" identifies a receipt subscription.
Paragraph (version B):
The push service shares the same default port number (443/TCP) with
HTTPS, but MAY also advertise the IANA allocated TCP System Port 1001
using HTTP alternative services RFC7838.
Paragraph (version A):
A response with a 201 (Created) status code includes a URI for a new
push message subscription resource in the Location header field.
Paragraph (version A):
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 A):
The push service MUST provide a URI for a receipt subscribe resource
in a link relation of type "urn:ietf:params:push:receipts".
Paragraph (version A):
An application-specific method is used to distribute the push and
receipt subscribe URIs to the application server.  Confidentiality
protection and application server authentication MUST be used to
ensure that these URIs are not disclosed to unauthorized recipients
(see authorization).
Paragraph (version A):
The push service MAY provide a URI for a subscription set resource in
a link relation of type "urn:ietf:params:push:set".  If provided, the
push service supports subscription sets.  If available, the user
agent SHOULD use the subscription set to receive push messages rather
than individual push message subscriptions.
Paragraph (version A):
The push service MAY return new subscription sets in response to
different subscription requests from the same user agent.  This
allows the push service to control the grouping of the push message
subscriptions.
Paragraph (version A):
Collecting multiple push message subscriptions into a subscription
set can represent a significant efficiency improvement for a push
service.  For that reason, if a subscription set is returned in a
push message subscription response, the user agent SHOULD include
this subscription set in subsequent push message subscription
requests to the push service.
Paragraph (version A):
The user agent adds a subscription set link relation to the request
to create a push message subscription.  This gives the push service
the option to create the new subscription within that subscription
set.
Paragraph (version A):
A push service MAY return a 429 (Too Many Requests) status code
RFC6585 to reject requests which omit a subscription set or contain
an invalid subscription set.
Paragraph (version B):
A 201 (Created) response indicates that the a push subscription was
created.  A URI for the push message subscription resource that was
created in response to the request MUST be returned in the Location
header field.
Paragraph (version B):
The push service MUST provide a URI for the push resource
corresponding to the push message subscription in a link relation of
type "urn:ietf:params:push".
Paragraph (version B):
An application-specific method is used to distribute the push URI to
the application server.  Confidentiality protection and application
server authentication MUST be used to ensure that this URI is not
disclosed to unauthorized recipients (authorization).
Paragraph (version B):
Collecting multiple push message subscriptions into a subscription
set can represent a significant efficiency improvement for a push
service.  The push service MAY provide a URI for a subscription set
resource in a link relation of type "urn:ietf:params:push:set".
Paragraph (version B):
When a subscription set is returned in a push message subscription
response, the user agent SHOULD include this subscription set in a
link relation of type "urn:ietf:params:push:set" in subsequent
requests to create new push message subscriptions.
Paragraph (version B):
A push service MUST return a 400 (Bad Request) status code for
requests which contain an invalid subscription set.  A push service
MAY return a 429 (Too Many Requests) status code RFC6585 to reject
requests which omit a subscription set.
Paragraph (version A):
An application server requests the creation of a receipt subscription
by sending a HTTP POST request to the receipt subscribe resource
distributed to the application server by a user agent.
Paragraph (version A):
A successful response with a 201 (Created) status code includes a URI
for the receipt subscription resource in the Location header field.
Paragraph (version A):
An application server that sends push messages to a large population
of user agents incurs a significant load if it has to monitor a
receipt subscription for each user agent.  Reuse of receipt
subscriptions is critical in reducing load on application servers.  A
receipt subscription can be used for all resources that have the same
receipt subscribe URI.
Paragraph (version A):
A push service SHOULD provide the same receipt subscribe URI to all
user agents.  Application servers SHOULD reuse receipt subscription
URIs if the receipt subscribe URI provided with the push resource is
identical to the one used to create the receipt subscription.
Checking that the receipt subscribe URI is identical allows the
application server to avoid creating unnecessary receipt
subscriptions.
Paragraph (version A):
A push service MAY return a 413 (Payload Too Large) status code
RFC7231 in response to requests that include an entity body that is
too large.  Push services MUST NOT return a 413 status code in
responses to an entity body that is 4k (4096 bytes) or less in size.
Paragraph (version A):
An application server can use the "urn:ietf:params:push:receipt" link
relation type to request a confirmation from the push service when a
push message is delivered and acknowledged by the user agent.
Paragraph (version A):
The application sets the link relation value to a receipt
subscription URI.  This receipt subscription resource MUST be created
from the same receipt subscribe resource which was returned with the
push message subscription response (see message_subscription).
Paragraph (version B):
An application server can include the RFC7240 with the "respond-
async" preference to request confirmation from the push service when
a push message is delivered and then acknowledged by the user agent.
Paragraph (version B):
For subsequent receipt requests to the same origin RFC6454, the
application server SHOULD include the returned receipt subscription
in a link relation of type "urn:ietf:params:push:receipt".  This
gives the push service an option to aggregate the receipts.  The push
service SHOULD return the same receipt subscription in its response,
although it MAY return a new receipt subscription if it is unable to
reuse the one provided by the application server.
Paragraph (version B):
A push service MUST return a 400 (Bad Request) status code for
requests which contain an invalid receipt subscription.  If a push
service wishes to limit the number of receipt subscriptions that it
maintains, it MAY return a 429 (Too Many Requests) status code
RFC6585 to reject receipt requests which omit a receipt subscription.
Paragraph (version A):
An application server MAY include an Urgency header field in its
request for push message delivery.  This header field indicates the
message urgency.  The push service MUST not forward the Urgency
header field to the user agent.  An push message without the Urgency
header field is forwarded as though it included a value of "normal".
Paragraph (version B):
An application server MAY include an Urgency header field in its
request for push message delivery.  This header field indicates the
message urgency.  The push service MUST not forward the Urgency
header field to the user agent.  An push message without the Urgency
header field defaults to a value of "normal".
Paragraph (version A):
A user agent can also request the contents of the push message
subscription resource immediately by including a RFC7240 with a
"wait" parameter set to "0".  In response to this request, the push
service MUST generate a server push for all push messages that have
not yet been delivered.
Paragraph (version B):
A user agent can also request the contents of the push message
subscription resource immediately by including a RFC7240 with a
"wait" preference set to "0".  In response to this request, the push
service MUST generate a server push for all push messages that have
not yet been delivered.
Paragraph (version A):
There are minor differences between receiving push messages for a
subscription and a subscripion set.
Paragraph (version B):
There are minor differences between receiving push messages for a
subscription and a subscripion set.  If a subscription set is
available, the user agent SHOULD use the subscription set to monitor
for push messages rather than individual push message subscriptions.
Paragraph (version A):
A user agent can request the contents of the push message
subscription set resource immediately by including a RFC7240 with a
"wait" parameter set to "0".  In response to this request, the push
service MUST generate a server push for all push messages that have
not yet been delivered.
Paragraph (version B):
A user agent can request the contents of the push message
subscription set resource immediately by including a RFC7240 with a
"wait" preference set to "0".  In response to this request, the push
service MUST generate a server push for all push messages that have
not yet been delivered.
Paragraph (version A):
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 receives the acknowledgement and the application
has requested a delivery receipt, the push service MUST return a 204
(No Content) response to the application server monitoring the
receipt subscription.
Paragraph (version A):
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 push a
failure response with a status code of 410 (Gone) to the application
server monitoring the receipt subscription resource.
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 return a 410
(Gone) to the application server monitoring the receipt subscription.
Paragraph (version A):
A server that wishes to redistribute load can do so using alternative
services I-D.ietf-httpbis-alt-svc.  Alternative services allows for
redistribution of load whilst maintaining the same URIs for various
resources.  User agents can ensure a graceful transition by using the
GOAWAY frame once it has established a replacement connection.
Paragraph (version A):
Storage of push messages based on the TTL header field comprises a
potentially significant amount of storage for a push service.  A push
service is not obligated to store messages indefinitely.  A push
service is able to indicate how long it intends to retain a message
to an application server using the TTL header field (see ttl).
Paragraph (version A):
Push messages that are stored and not delivered to a user agent are
delivered when the user agent recommences monitoring.  Stored push
messages SHOULD include a Last-Modified header field (see Section 2.2
of RFC7232) indicating when delivery was requested by an application
server.
Paragraph (version A):
A GET request to a push message subscription resource that has only
expired messages results in response as though no push message were
ever sent.
Paragraph (version A):
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 B):
A server that wishes to redistribute load can do so using HTTP
alternative services RFC7838.  HTTP alternative services allows for
redistribution of load while maintaining the same URIs for various
resources.  A user agent can ensure a graceful transition by using
the GOAWAY frame once it has established a replacement connection.
Paragraph (version B):
Storage of push messages based on the TTL header field comprises a
potentially significant amount of storage for a push service.  A push
service is not obligated to store messages indefinitely.  A push
service is able to indicate how long it intends to retain a message
to an application server using the TTL header field (ttl).
Paragraph (version B):
Push messages that are stored and not delivered to a user agent are
delivered when the user agent recommences monitoring.  Stored push
messages SHOULD include a Last-Modified header field (Section 2.2 of
RFC7232) indicating when delivery was requested by an application
server.
Paragraph (version B):
A GET request to a push message subscription resource with only
expired messages results in a response as though no push message was
ever sent.
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 a 413 (Payload Too Large) status code RFC7231
in response to requests that include an entity body that is too
large.  Push services MUST NOT return a 413 status code in responses
to an entity body that is 4k (4096 bytes) or less in size.
Paragraph (version B):
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 service can remove a subscription at any time.  If a user
agent or application server has an outstanding request to a
subscription resource (see monitor-subscription), this can be
signaled by returning a 400-series status code, such as 410 (Gone).
Paragraph (version A):
A user agent or application server can request that a subscription be
removed by sending a DELETE request to the push message subscription
or receipt subscription URI.
Paragraph (version A):
A push service MUST return a 400-series status code, such as 404 (Not
Found) or 410 (Gone) if an application server attempts to send a push
message to a removed or expired push message subscription.
Paragraph (version A):
A push service MAY expire a subscription set at any time which MUST
also expire all push message subscriptions in the set.  If a user
agent has an outstanding request to a push subscription set (see
monitor-set) this can be signaled by returning a 400-series status
code, such as 410 (Gone).
Paragraph (version B):
A push service can remove a subscription at any time.  If a user
agent or application server has an outstanding request to a
subscription resource (monitor-subscription), this MUST be signaled
by returning a 404 (Not Found) status code.
Paragraph (version B):
A push service MUST return a 404 (Not Found) status code if an
application server attempts to send a push message to a removed or
expired push message subscription.
Paragraph (version B):
A user agent can remove its push message subscription by sending a
DELETE request to the corresponding URI.  An application server can
remove its receipt subscription by sending a DELETE request to the
corresponding URI.
Paragraph (version B):
A push service MAY expire a subscription set at any time which MUST
also expire all push message subscriptions in the set.  If a user
agent has an outstanding request to a push subscription set (monitor-
set) this can be signaled by returning a 400-series status code, such
as 410 (Gone).
Paragraph (version A):
Push message reliability can be important if messages contain
information critical to the state of an application.  Repairing state
can be costly, particularly for devices with limited communications
capacity.  Knowing that a push message has been correctly received
avoids costly retransmissions, polling and state resynchronization.
Paragraph (version B):
Push message reliability can be important if messages contain
information critical to the state of an application.  Repairing state
can be expensive, particularly for devices with limited
communications capacity.  Knowing that a push message has been
correctly received avoids retransmissions, polling, and state
resynchronization.
Paragraph (version A):
This need not be perfect as long as the resulting anonymity set
(see RFC6973, Section 6.1.1) is sufficiently large.  A push URI
necessarily identifies a push service or a single server instance.
It is also possible that traffic analysis could be used to
correlate subscriptions.
Paragraph (version B):
This need not be perfect as long as the resulting anonymity set
(RFC6973, Section 6.1.1) is sufficiently large.  A push URI
necessarily identifies a push service or a single server instance.
It is also possible that traffic analysis could be used to
correlate subscriptions.
Paragraph (version A):
Authorization is managed using capability URLs for the push message
subscription, push, and receipt subscription resources (see CAP-URI).
A capability URL grants access to a resource based solely on
knowledge of the URL.
Paragraph (version B):
Authorization is managed using capability URLs for the push message
subscription, push, and receipt subscription resources (CAP-URI).  A
capability URL grants access to a resource based solely on knowledge
of the URL.
Paragraph (version A):
Capability URLs act as bearer tokens.  Knowledge of a push message
subscription URI implies authorization to either receive push
messages or delete the subscription.  Knowledge of a push URI implies
authorization to send push messages.  Knowledge of a push message URI
allows for reading and acknowledging that specific message.
Knowledge of a receipt subscription URI implies authorization to
receive push receipts.  Knowledge of a receipt subscribe URI implies
authorization to create subscriptions for receipts.
Paragraph (version A):
Note that the same receipt subscribe URI could be returned for
multiple push message subscriptions.  Using the same value for a
large number of subscriptions allows application servers to reuse
receipt subscriptions, which can provide a significant efficiency
advantage.  A push service that uses a common receipt subscribe URI
loses control over the creation of receipt subscriptions.  This can
result in a potential exposure to denial of service; stateless
resource creation can be used to mitigate the effects of this
exposure.
Paragraph (version B):
Capability URLs act as bearer tokens.  Knowledge of a push message
subscription URI implies authorization to either receive push
messages or delete the subscription.  Knowledge of a push URI implies
authorization to send push messages.  Knowledge of a push message URI
allows for reading and acknowledging that specific message.
Knowledge of a receipt subscription URI implies authorization to
receive push receipts.
Paragraph (version A):
A malicious application with a valid push URI could use the greater
resources of a push service to mount a denial of service attack on a
user agent.  Push services SHOULD limit the rate at which push
messages are sent to individual user agents.  A push service or user
agent MAY delete that receive too many push messages.
Paragraph (version B):
A malicious application with a valid push URI could use the greater
resources of a push service to mount a denial of service attack on a
user agent.  Push services SHOULD limit the rate at which push
messages are sent to individual user agents.
Paragraph (version B):
A push service or user agent MAY also delete that receive too many
push messages.
Paragraph (version A):
This link relation type is used to identify a resource for
subscribing to delivery confirmations for push messages.