Draft: draft-thomson-webpush-protocol

Commentary: This is a work in progress , but ready for an initial review . I will add more commits to the branch for dealing with IANA registration of the header field . I also need to do some massaging of Section 7.2 to account for changes there . I 'll have a follow - up pull request that deals with learning the server TTL . I think that the simplest thing to do would be to have the server echo the header field , using a lower value if it does n't support it . Application servers can discover the maximum by sending a large value , like . The alternative is a declarative push service policy , but I want to encourage an adaptive policy with respect to TTL . 
 An alternative to echoing the TTL is just using the header field , as is currently described . I think that might actually be sufficient . That still leaves user agents unable to determine whether they need a full resync though . We need something for . 
 Looking at the semantics of and in relation to and , I think that it would be unwise to use them here . Current plan is to echo . 
 It was less clear that this was needed than was , but the idea is that it would be good for a user agent ( or maybe an application server too ) to be able to learn the maximum TTL that a push service was willing to maintain . 
 Discussed today : conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity . 
 It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity . 
 There is a related failure case in the current draft related to acknowledgements : 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 . 
 Discussed . Discovery of maximum TTL is not required at this time . 
 This is just for the request from the application server to the push service .
Paragraph (version B):
A push service can improve the reliability of push message delivery
considerably by storing push messages for a period.  User agents are
often only intermittendly connected, and so benefit from having short
term message storage at the push service.
Paragraph (version B):
Delaying delivery might also be used to batch communication with the
user agent, thereby conserving radio resources.
Paragraph (version B):
Some push messages are not useful once a certain period of time
elapses.  Delivery of messages after they have ceased to be relevant
is wasteful.  For example, if the push message contains a call
notification, receiving a message after the caller has abandoned the
call is of no value; the application at the user agent is forced to
suppress the message so that it does not generate a useless alert.
Paragraph (version B):
An application server can use the TTL header field to limit the time
that a push message is retained by a push service.  The TTL header
field contains a value in seconds that describes how long a push
message is retained by the push service.
Paragraph (version B):
Once the TTL period elapses, the push service MUST remove the push
message and cease any attempt to deliver it to the user agent.  A
push service might retain values for a short duration after the TTL
period to account for time accounting errors in processing.  For
instance, distributing a push message within a server cluster might
accrue errors due to clock variation, or processing and transit
delays.
Paragraph (version B):
A push service is not obligated to account for time spent by the
application server in sending a push message to the push service, or
delays incurred while sending a push message to the user agent.  An
application server needs to account for transit delays in selecting a
TTL header field value.
Paragraph (version B):
Absence of the TTL header field is interpreted as equivalent to a
zero value.  Push messages with a zero TTL indicate that storage is
not needed and that the message can be dropped if the user agent
isn't immediately available to receive the message.  Push messages
with a zero TTL can be delivered very efficiently.
Paragraph (version B):
A push service MAY choose to retain a push message for a shorter
duration than that requested.  It indicates this by including a TTL
header field in the response that includes the actual TTL.  This TTL
value MUST be less than or equal to the value provided by the
application server.
Paragraph (version A):
Push services typically store messages for some time to allow for
limited recovery from transient faults.  If a push message is stored,
but not delivered, the push service can indicate the probable
duration of storage by including expiration information in the
response to the push request.
Paragraph (version A):
A push service is not obligated to store messages indefinitely.  If a
user agent is not actively monitoring for push messages, those
messages can be lost or overridden by newer messages on the same
subscription.
Paragraph (version A):
Push messages that were 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 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 (see ttl).
Paragraph (version B):
A user agent that does not actively monitor for push messages will
not receive messages that expire during that interval.
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 (see Section 2.2
of RFC7232) indicating when delivery was requested by an application
server.
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.
Paragraph (version B):
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):
This protocol defines new HTTP header fields in iana.header.fields.
New link relation types are identified using the URNs defined in
iana.urns.
Paragraph (version B):
HTTP header fields are registered within the "Message Headers"
registry maintained at <https://www.iana.org/assignments/message-
headers/>.
Paragraph (version B):
The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force".