draft-ietf-sipcore-sip-push-14.txt   draft-ietf-sipcore-sip-push-15.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track M. Arnold Intended status: Standards Track M. Arnold
Expires: March 3, 2019 Metaswitch Networks Expires: March 30, 2019 Metaswitch Networks
August 30, 2018 September 26, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-14 draft-ietf-sipcore-sip-push-15
Abstract Abstract
This document describes how a Push Notification Service (PNS) can be This document describes how a Push Notification Service (PNS) can be
used to wake suspended Session Initiation Protocol (SIP) User Agents used to wake suspended Session Initiation Protocol (SIP) User Agents
(UAs), using push notifications, for the UA to be able to send (UAs), using push notifications, for the UA to be able to send
binding refresh REGISTER requests and to receive receive incoming SIP binding refresh REGISTER requests and to receive receive incoming SIP
requests. The document defines new SIP URI parameters and new requests. The document defines new SIP URI parameters and new
feature-capability indicators that can be used in SIP messages to feature-capability indicators that can be used in SIP messages to
indicate support of the mechanism defined in this document, to indicate support of the mechanism defined in this document, to
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 3, 2019. This Internet-Draft will expire on March 30, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 6 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 6
4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 6 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 7
4.1. Request Push Notifications from Network . . . . . . . . . 6 4.1. Request Push Notifications from Network . . . . . . . . . 7
4.2. Query Network Push Notification Capabilities . . . . . . 9 4.2. Query Network Push Notification Capabilities . . . . . . 9
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 9 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 10
5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 9 5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Trigger Periodic Binding Refresh . . . . . . . . . . . . 10 5.2. Trigger Periodic Binding Refresh . . . . . . . . . . . . 10
5.3. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 10 5.3. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 11
5.3.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 10 5.3.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 11
5.3.2. Initial Request for Dialog or Stand-Alone Request . . 12 5.3.2. Initial Request for Dialog or Stand-Alone Request . . 13
6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 15
6.1. 555 (Push Notification Service Not Supported) Response 6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 16
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 16
6.2. 556 (Push Notification Failed) Response Code . . . . . . 15 6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 16
6.3. sip.pns Feature-Capability Indicator . . . . . . . . . . 16 6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 16
6.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 16 6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 17
6.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 17 6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 17
6.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 17 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 17 7.1. 555 (Push Notification Service Not Supported) Response
7. PNS Registration Requirements . . . . . . . . . . . . . . . . 18 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. pn-provider, pn-param and pn-prid URI Parameters for Apple 7.2. 556 (Push Notification Failed) Response Code . . . . . . 18
Push Notification service . . . . . . . . . . . . . . . . . . 18 7.3. sip.pns Feature-Capability Indicator . . . . . . . . . . 18
9. pn-provider, pn-param and pn-prid URI Parameters for Google 7.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 19
Firebase Cloud Messaging (FCM) push notification service . . 19 7.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 19
10. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 7.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 19
(Generic Event Delivery Using HTTP Push) . . . . . . . . . . 19 7.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. PNS Registration Requirements . . . . . . . . . . . . . . . . 20
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 9. pn-provider, pn-param and pn-prid URI Parameters for Apple
12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 20 Push Notification service . . . . . . . . . . . . . . . . . . 20
12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 21 10. pn-provider, pn-param and pn-prid URI Parameters for Google
12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 21 Firebase Cloud Messaging (FCM) push notification service . . 21
12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 21 11. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030
12.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 21 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 21
12.2.1. 555 (Push Notification Service Not Supported) . . . 21 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 22 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
12.3. SIP Global Feature-Capability Indicator . . . . . . . . 22 13.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 23
12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 22 13.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 23
12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 22 13.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 23
12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 23 13.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 23
12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 23 13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 23
12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 24 13.2.1. 555 (Push Notification Service Not Supported) . . . 23
12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 24 13.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 24
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 13.3. SIP Global Feature-Capability Indicator . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 13.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . 25 13.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . 26 13.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 13.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 26
13.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 26
13.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 27
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
15.1. Normative References . . . . . . . . . . . . . . . . . . 28
15.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
In order to save resources (e.g., battery life) some devices In order to save resources (e.g., battery life) some devices
(especially mobile devices) and operating systems will suspend (especially mobile devices) and operating systems will suspend
applications when not used. In some cases, internal timers cannot be applications when not used. In some cases, internal timers cannot be
used to wake such applications, nor will incoming network traffic used to wake such applications, nor will incoming network traffic
wake the application. Instead, one way to wake the application is by wake the application. Instead, one way to wake the application is by
using a Push Notification Service (PNS). Typically each operating using a Push Notification Service (PNS). Typically each operating
system uses a dedicated PNS. For example, Apple iOS devices use the system uses a dedicated PNS. For example, Apple iOS devices use the
skipping to change at page 11, line 48 skipping to change at page 12, line 12
proxy MAY consider the interval too small based on its own policy so proxy MAY consider the interval too small based on its own policy so
as to reduce load on the system. as to reduce load on the system.
Otherwise, if the pn-provider SIP URI parameter identifies a type of Otherwise, if the pn-provider SIP URI parameter identifies a type of
PNS that the proxy does not support, or if the REGISTER request does PNS that the proxy does not support, or if the REGISTER request does
not contain all additional information required for the specific type not contain all additional information required for the specific type
of PNS, the proxy MUST either forward the request (e.g., if the proxy of PNS, the proxy MUST either forward the request (e.g., if the proxy
knows that a downstream proxy supports the type of PNS) or send a SIP knows that a downstream proxy supports the type of PNS) or send a SIP
555 (Push Notification Service Not Supported) response to the 555 (Push Notification Service Not Supported) response to the
REGISTER request. If the proxy sends a SIP 555 (Push Notification REGISTER request. If the proxy sends a SIP 555 (Push Notification
Service Not Supported) response Section 6.1, the proxy SHOULD insert Service Not Supported) response Section 7.1, the proxy SHOULD insert
a Feature-Caps header field with a 'sip.pns' feature-capability a Feature-Caps header field with a 'sip.pns' feature-capability
indicator in the response, identifying the type of each PNS that the indicator in the response, identifying the type of each PNS that the
proxy supports. The decision whether to forward the request, or to proxy supports. The decision whether to forward the request, or to
send a response, is done based on local policy. send a response, is done based on local policy.
If the proxy supports the type of PNS identified by the pn-provider If the proxy supports the type of PNS identified by the pn-provider
SIP URI parameter, the proxy MUST insert a Feature-Caps header field SIP URI parameter, the proxy MUST insert a Feature-Caps header field
with a 'sip.pns' feature-capability indicator, identifying the type with a 'sip.pns' feature-capability indicator, identifying the type
of PNS, in the REGISTER request before forwarding the REGISTER of PNS, in the REGISTER request before forwarding the REGISTER
request towards the registrar. This will inform downstream proxies request towards the registrar. This will inform downstream proxies
skipping to change at page 15, line 32 skipping to change at page 15, line 46
of this document. Similarly, if the Request-URI of the SIP request of this document. Similarly, if the Request-URI of the SIP request
only contains any pn-provider SIP URI parameter, but no other pn- SIP only contains any pn-provider SIP URI parameter, but no other pn- SIP
URI parameters, e.g., because the SIP UA has not included them in a URI parameters, e.g., because the SIP UA has not included them in a
REGISTER request (Section 4.2), the proxy is not able to request a REGISTER request (Section 4.2), the proxy is not able to request a
push notification towards the UA. If the proxy has knowledge that push notification towards the UA. If the proxy has knowledge that
the UA is wake, and that the UA is able to receive the SIP request, the UA is wake, and that the UA is able to receive the SIP request,
the proxy MAY forwards the request towards the UA. Otherwise the the proxy MAY forwards the request towards the UA. Otherwise the
proxy MUST reject the SIP request with a 480 (Temporarily proxy MUST reject the SIP request with a 480 (Temporarily
Unavailable) or a 556 (Push Notification Failed) response. Unavailable) or a 556 (Push Notification Failed) response.
6. Grammar 6. Support Of Longlived SIP Dialogs
6.1. 555 (Push Notification Service Not Supported) Response Code Some SIP dialogs might have a long lifetime, with little activity.
For example, when the SIP event notification mechanism [RFC6665] is
used, there might be a long period between mid-dialog SIP NOTIFY
requests are sent. Because of this a SIP UA might get suspended, and
needs to be awaken in order to be able to receive mid-dialog
requests.
When the proxy receives a SIP request for a new dialog, or a stand-
alone SIP request, addressed towards a UA, the request will contain
information (pn- SIP URI parameters) that allows proxy to request
push notifications towards the UA Section 5.3.2. However, this
information will not be present in mid-dialog requests towards the
UA. Instead, the proxy need to support a mechanism where it stores
the information needed to request a push notification towards the UA
and be able to find and retrieve that information when it receives a
mid-dialog request. This section defines such mechanism. The UA and
proxy procedures in this section are applied in addition to the
generic procedures defined in this specification.
6.1. SIP UA Behavior
6.1.1. Initial Request for Dialog
When the UA sends in initial request for a dialog, or a 2xx response
to such requests, if the UA is willing to receive push notifications
triggered by incoming mid-dialog requests, the UA MUST include a 'pn-
purk' SIP URI parameter in the Contact header of the request or
response. The UA MUST include a parameter value identical to the the
last 'sip.pnspurk' feature-capability indicator that it received in a
REGISTER response.
The UA decision whether it is willing to receive push notifications
triggered by incoming mid-dialog requests is done based on local
policy. Such policy might be based on the type of SIP dialog, the
type of media (if any) negotiated for the dialog [RFC3264], etc.
6.2. SIP Proxy Behavior
6.2.1. REGISTER
When the proxy receives an initial REGISTER request for a
registration from the UA, if the proxy supports requesting push
notifications, triggered by mid-dialog requests, towards the
registered UA, the proxy MUST store the information (the pn- SIP URI
parameters) needed to request push notifications associated with the
registration towards the UA. In addition the proxy MUST generate a
unique (within the context of the proxy) value, referred to as the
PURK (Proxy Unique Registration Key), that is unique within the
context of the proxy and that can be used as a key to retrieve the
information. When the proxy receives the associated 2xx REGISTER
response, it adds a 'sip.pnspurk' feature-capability indicator with
the PURK value to the associated 2xx REGISTER response. When the
proxy receives a binding refresh REGISTER request, it MUST add a
'sip.pnspurk' feature-capability indicator with the previously
generated key as the value to the associated 2xx REGISTER response.
The PURK value MUST be generated in such a way so that it cannot be
used to retrieve information about the user or associate it with
registrations. It can be generated e.g., by utilizing a
cryptographically secure random function.
In order to prevent client fingerprinting, the proxy MUST
periodically generate a new PURK value (even if pn- parameters did
not change) and provide the new value to the UA in a 2xx binding
refresh REGISTER response. However, as long as there are ongoing
dialogs associated with the old value, the proxy MUST store it so
that it can request push notifications towards the UA when it
receives a mid-dialog request addressed towards the UA.
6.2.2. Initial Request for Dialog
When the proxy receives an initial request for a dialog from the UA,
and if the request contains a 'pn-purk' SIP URI parameter in the
Contact header field with a PURK value that the proxy has generated
Section 6.2.2, the proxy MUST add a Record-Route header to the
request, to insert itself in the dialog route [RFC3261].
When the proxy receives an initial request for a dialog addressed
towards the UA, and if the proxy has generated a PURK value
associated with the pn- parameters included in the SIP-URI of the
request Section 6.2.2, the proxy MUST add a Record-Route header to
the request, to insert itself in the dialog route [RFC3261].
6.2.3. Mid-Dialog Request
When the proxy receives a mid-dialog request addressed towards the
UA, if the request contains a 'pn-purk' SIP URI parameter and if the
proxy is able to retrieve the stored information needed to request a
push notification towards the UA (Section 6.2.1), the proxy MUST
request a push notification towards the UA. Once the proxy has
received the triggered REGISTER request, and the associated
successful response, the proxy can forward the mid-dialog request
towards the UA.
As described in Section 5.3.2, while waiting for the push
notification request to succeed, and the associated REGISTER request
to arrive from the SIP UA, the proxy needs to take into consideration
that the transaction associated with the NOTIFY request will
eventually time out at the sender of the request (UAC), and the
sender will consider the transaction a failure.
7. Grammar
7.1. 555 (Push Notification Service Not Supported) Response Code
The 555 response code is added to the "Server-Error" Status-Code The 555 response code is added to the "Server-Error" Status-Code
definition. 555 (Push Notification Service Not Supported) is used to definition. 555 (Push Notification Service Not Supported) is used to
indicate that the server did not support the push notification indicate that the server did not support the push notification
service identified in a 'pn-provider' SIP URI parameter. service identified in a 'pn-provider' SIP URI parameter.
The use of the SIP 555 response code is defined for SIP REGISTER The use of the SIP 555 response code is defined for SIP REGISTER
responses. responses.
6.2. 556 (Push Notification Failed) Response Code 7.2. 556 (Push Notification Failed) Response Code
The 556 response code is added to the "Server-Error" Status-Code The 556 response code is added to the "Server-Error" Status-Code
definition. 556 (Push Notification Failed) is used to indicate that definition. 556 (Push Notification Failed) is used to indicate that
the server failed to request a push notification from the push the server failed to request a push notification from the push
notification service identified in a 'pn-provider' SIP URI parameter. notification service identified in a 'pn-provider' SIP URI parameter.
The use of the SIP 556 response code is defined for responses to SIP The use of the SIP 556 response code is defined for responses to SIP
requests initiating dialogs, and responses to stand-alone SIP requests initiating dialogs, and responses to stand-alone SIP
requests. requests.
6.3. sip.pns Feature-Capability Indicator 7.3. sip.pns Feature-Capability Indicator
The sip.pns feature-capability indicator, when included in a Feature- The sip.pns feature-capability indicator, when included in a Feature-
Caps header field of a SIP REGISTER request or a SIP 2xx response to Caps header field of a SIP REGISTER request or a SIP 2xx response to
a REGISTER request, indicates that the entity associated with the a REGISTER request, indicates that the entity associated with the
indicator supports, and will use, the SIP push mechanism and the push indicator supports, and will use, the SIP push mechanism and the push
notification service identified by the indicator value. When notification service identified by the indicator value. When
included in a 555 (Push Notification Service Not Supported) response included in a 555 (Push Notification Service Not Supported) response
to a REGISTER request, the the indicator indicates that the entity to a REGISTER request, the the indicator indicates that the entity
associated with the indicator supports the SIP push mechanism, and associated with the indicator supports the SIP push mechanism, and
the push notification service(s) identified by the indicator value. the push notification service(s) identified by the indicator value.
The values defined for the pn-provider SIP URI parameter are used as The values defined for the pn-provider SIP URI parameter are used as
indicator values. indicator values.
pns-fc = "+sip.pns" EQUAL LDQUOT pns-list RDQUOT pns-fc = "+sip.pns" EQUAL LDQUOT pns-list RDQUOT
pns-list = pns *(COMMA pns) pns-list = pns *(COMMA pns)
pns = tag-value pns = tag-value
; tag-value as defined in RFC 3840 ; tag-value as defined in RFC 3840
6.4. sip.vapid Feature-Capability Indicator 7.4. sip.vapid Feature-Capability Indicator
The sip.vapid feature-capability indicator, when included in a SIP The sip.vapid feature-capability indicator, when included in a SIP
2xx response to a SIP REGISTER request, indicates that the entity 2xx response to a SIP REGISTER request, indicates that the entity
associated with the indicator supports, and will use, the Voluntary associated with the indicator supports, and will use, the Voluntary
Application Server Identification (VAPID) [RFC8292] mechanism when Application Server Identification (VAPID) [RFC8292] mechanism when
requesting push notifications towards the SIP UA associated with the requesting push notifications towards the SIP UA associated with the
SIP registration. The indicator value is a public key identifying SIP registration. The indicator value is a public key identifying
the entity, that can be used by a SIP UA to restrict subscriptions to the entity, that can be used by a SIP UA to restrict subscriptions to
that entity. that entity.
vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT
vapid = tag-value vapid = tag-value
; tag-value as defined in RFC 3840 ; tag-value as defined in RFC 3840
6.5. sip.pnsreg Feature-Capability Indicator 7.5. sip.pnsreg Feature-Capability Indicator
The sip.pnsreg feature-capability indicator, when included in a SIP The sip.pnsreg feature-capability indicator, when included in a SIP
2xx response to a SIP REGISTER request, indicates that the entity 2xx response to a SIP REGISTER request, indicates that the entity
associated with the indicator expects to receive binding refresh associated with the indicator expects to receive binding refresh
REGISTER requests from the SIP UA associated with the registration REGISTER requests from the SIP UA associated with the registration
before the registration expires, without the entity having to request before the registration expires, without the entity having to request
push notifications towards the SIP UA in order to trigger the push notifications towards the SIP UA in order to trigger the
REGISTER requests. The indicator value is the minimum value (given REGISTER requests. The indicator value is the minimum value (given
in seconds) before the registration expiration when the entity in seconds) before the registration expiration when the entity
expects to receive the REGISTER request. expects to receive the REGISTER request.
pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT
reg = 1*DIGIT reg = 1*DIGIT
; DIGIT as defined in RFC 3261 ; DIGIT as defined in RFC 3261
6.6. sip.pnsreg Media Feature Tag 7.6. sip.pnsreg Media Feature Tag
The sip.pnsreg media feature tag, when included in the SIP Contact The sip.pnsreg media feature tag, when included in the SIP Contact
header field of a SIP REGISTER request, indicates that the SIP UA header field of a SIP REGISTER request, indicates that the SIP UA
associated with the tag is able to send binding refresh REGISTER associated with the tag is able to send binding refresh REGISTER
requests associated with the registration without being awaken by requests associated with the registration without being awaken by
push notifications. The media feature tag has no values. push notifications. The media feature tag has no values.
pnsreg-mt = "+sip.pnsreg" pnsreg-mt = "+sip.pnsreg"
6.7. SIP URI Parameters 7.7. SIP URI Parameters
The section defines new SIP URI parameters, by extending the grammar The section defines new SIP URI parameters, by extending the grammar
for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows: for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows:
uri-parameter =/ pn-provider / pn-param / pn-prid uri-parameter =/ pn-provider / pn-param / pn-prid
pn-provider = "pn-provider" EQUAL pvalue pn-provider = "pn-provider" EQUAL pvalue
pn-param = "pn-param" EQUAL pvalue pn-param = "pn-param" EQUAL pvalue
pn-prid = "pn-prid" EQUAL pvalue pn-prid = "pn-prid" EQUAL pvalue
; pvalue as defined in RFC 3261 ; pvalue as defined in RFC 3261
; EQUAL as defined in RFC 3261 ; EQUAL as defined in RFC 3261
; COLON as defined in RFC 3261 ; COLON as defined in RFC 3261
The format and semantics of pn-prid and pn-param are The format and semantics of pn-prid and pn-param are
specific to the pn-provider value. specific to the pn-provider value.
Parameter value characters that are not part of pvalue needs to be Parameter value characters that are not part of pvalue needs to be
escaped, as defined in RFC 3261. escaped, as defined in RFC 3261.
7. PNS Registration Requirements 8. PNS Registration Requirements
When a new value is registered to the PNS Sub-registry, a reference When a new value is registered to the PNS Sub-registry, a reference
to a specification which describes the PNS associated with the value to a specification which describes the PNS associated with the value
is provided. That specification MUST contain the following is provided. That specification MUST contain the following
information: information:
o The value of the pn-provider SIP URI parameter. o The value of the pn-provider SIP URI parameter.
o How the pn-prid SIP URI parameter value is retrieved and set by o How the pn-prid SIP URI parameter value is retrieved and set by
the SIP UA. the SIP UA.
o How the pn-param SIP URI parameter (if required for the specific o How the pn-param SIP URI parameter (if required for the specific
PNS provider) value is retrieved and set by the SIP UA. PNS provider) value is retrieved and set by the SIP UA.
8. pn-provider, pn-param and pn-prid URI Parameters for Apple Push 9. pn-provider, pn-param and pn-prid URI Parameters for Apple Push
Notification service Notification service
When the Apple Push Notification service (APNs) is used, the PNS- When the Apple Push Notification service (APNs) is used, the PNS-
related SIP URI parameters are set as described below. related SIP URI parameters are set as described below.
The value of the pn-provider URI parameter is "apns". The value of the pn-provider URI parameter is "apns".
Example: pn-provider = apns Example: pn-provider = apns
The value of the pn-param URI parameter is the APNs App ID, which is The value of the pn-param URI parameter is the APNs App ID, which is
encoded by two values, separated by a period (.): Team ID and Bundle encoded by two values, separated by a period (.): Team ID and Bundle
ID. The Team ID is provided by Apple and is unique to a development ID. The Team ID is provided by Apple and is unique to a development
team. The Bundle ID is unique to a development team, and is a string team. The Bundle ID is unique to a development team, and is a string
that will match a single application or a group of applications. that will match a single application or a group of applications.
Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp
The value of the pn-prid URI parameter is the device token, which is The value of the pn-prid URI parameter is the device token, which is
a unique identifier assigned by Apple to a specific app on a specific a unique identifier assigned by Apple to a specific app on a specific
device. device.
Example: pn-prid = 00fc13adff78512 Example: pn-prid = 00fc13adff78512
For more information on the APNs App ID: For more information on the APNs App ID:
https://developer.apple.com/library/content/documentation/General/ https://developer.apple.com/library/content/documentation/General/
Conceptual/DevPedia-CocoaCore/AppID.html Conceptual/DevPedia-CocoaCore/AppID.html
skipping to change at page 19, line 21 skipping to change at page 21, line 29
https://developer.apple.com/library/content/documentation/General/ https://developer.apple.com/library/content/documentation/General/
Conceptual/DevPedia-CocoaCore/AppID.html Conceptual/DevPedia-CocoaCore/AppID.html
For more information on the APNs device token: For more information on the APNs device token:
https://developer.apple.com/library/content/documentation/NetworkingI https://developer.apple.com/library/content/documentation/NetworkingI
nternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_re nternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_re
f/doc/uid/TP40008194-CH8-SW13 f/doc/uid/TP40008194-CH8-SW13
9. pn-provider, pn-param and pn-prid URI Parameters for Google Firebase 10. pn-provider, pn-param and pn-prid URI Parameters for Google
Cloud Messaging (FCM) push notification service Firebase Cloud Messaging (FCM) push notification service
When Firebase Cloud Messaging (FCM) is used, the PNS related URI When Firebase Cloud Messaging (FCM) is used, the PNS related URI
parameters are set as described below. parameters are set as described below.
The value of the pn-provider URI parameter is "fcm". The value of the pn-provider URI parameter is "fcm".
The value of the pn-param URI parameter is the Project ID. The value of the pn-param URI parameter is the Project ID.
The value of the pn-prid URI parameter is the Registration token, The value of the pn-prid URI parameter is the Registration token,
which is generated by the FCM SDK for each client app instance. which is generated by the FCM SDK for each client app instance.
For more information on the Project ID and Registration token: For more information on the Project ID and Registration token:
https://firebase.google.com/docs/cloud-messaging/concept-options https://firebase.google.com/docs/cloud-messaging/concept-options
10. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 11. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030
(Generic Event Delivery Using HTTP Push) (Generic Event Delivery Using HTTP Push)
When Generic Event Delivery Using HTTP Push is used, the PNS related When Generic Event Delivery Using HTTP Push is used, the PNS related
URI parameters are set as described below. URI parameters are set as described below.
The value of the pn-provider URI parameter is "webpush". The value of the pn-provider URI parameter is "webpush".
The value of the pn-param URI parameter MUST NOT be used. The value of the pn-param URI parameter MUST NOT be used.
The value of the pn-prid URI parameter is the push subscription URI. The value of the pn-prid URI parameter is the push subscription URI.
See RFC 8030 for more details: See RFC 8030 for more details:
Note that encryption for web push [RFC8291] is not used, therefore Note that encryption for web push [RFC8291] is not used, therefore
parameters for message encryption are not defined in this parameters for message encryption are not defined in this
specification. Web push permits the sending of a push message specification. Web push permits the sending of a push message
without a payload without encryption. without a payload without encryption.
11. Security Considerations 12. Security Considerations
Different mechanisms exist for authenticating and authorizing devices Different mechanisms exist for authenticating and authorizing devices
and users registering with a PNS. The mechanisms for authorizing and and users registering with a PNS. The mechanisms for authorizing and
authenticating the users are PNS-specific, and are outside the scope authenticating the users are PNS-specific, and are outside the scope
of this document. In addition to the information that needs to be of this document. In addition to the information that needs to be
exchanged between a device and the PNS in order to establish a push exchanged between a device and the PNS in order to establish a push
notification subscription, the mechanism defined in this document notification subscription, the mechanism defined in this document
does not require any additional information to be exchanged between does not require any additional information to be exchanged between
the device and the PNS. the device and the PNS.
skipping to change at page 20, line 43 skipping to change at page 23, line 5
[RFC8292] defines a mechanism which allows a proxy to identity itself [RFC8292] defines a mechanism which allows a proxy to identity itself
to a PNS, by signing a JWT sent to the PNS using a key pair. The to a PNS, by signing a JWT sent to the PNS using a key pair. The
public key serves as an identifier of the proxy, and can be used by public key serves as an identifier of the proxy, and can be used by
devices to restrict push notifications to the proxy associated with devices to restrict push notifications to the proxy associated with
the key. the key.
The mechanism in this document does not require a proxy to include The mechanism in this document does not require a proxy to include
any payload (in addition to possible payload used for the PNS itself) any payload (in addition to possible payload used for the PNS itself)
when requesting push notifications. when requesting push notifications.
12. IANA considerations 13. IANA considerations
12.1. SIP URI Parameters 13.1. SIP URI Parameters
This section defines new SIP URI Parameters that extend the "SIP/SIPS This section defines new SIP URI Parameters that extend the "SIP/SIPS
URI Parameters" sub-registry [RFC3969] under the sip-parameters URI Parameters" sub-registry [RFC3969] under the sip-parameters
registry: http://www.iana.org/assignments/sip-parameters. registry: http://www.iana.org/assignments/sip-parameters.
12.1.1. pn-provider 13.1.1. pn-provider
Parameter Name: pn-provider Parameter Name: pn-provider
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
12.1.2. pn-param 13.1.2. pn-param
Parameter Name: pn-param Parameter Name: pn-param
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
12.1.3. pn-prid 13.1.3. pn-prid
Parameter Name: pn-prid Parameter Name: pn-prid
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
12.2. SIP Response Codes 13.2. SIP Response Codes
12.2.1. 555 (Push Notification Service Not Supported) 13.2.1. 555 (Push Notification Service Not Supported)
This section defines a new SIP response code that extends the This section defines a new SIP response code that extends the
"Response Codes" sub-registry [RFC3261] under the sip-parameters "Response Codes" sub-registry [RFC3261] under the sip-parameters
registry: http://www.iana.org/assignments/sip-parameters. registry: http://www.iana.org/assignments/sip-parameters.
Response Code Number: 555 Response Code Number: 555
Default Reason Phrase: Push Notification Service Not Supported Default Reason Phrase: Push Notification Service Not Supported
12.2.2. 556 (Push Notification Failed) 13.2.2. 556 (Push Notification Failed)
This section defines a new SIP response code that extends the This section defines a new SIP response code that extends the
"Response Codes" sub-registry [RFC3261] under the sip-parameters "Response Codes" sub-registry [RFC3261] under the sip-parameters
registry: http://www.iana.org/assignments/sip-parameters. registry: http://www.iana.org/assignments/sip-parameters.
Response Code Number: 556 Response Code Number: 556
Default Reason Phrase: Push Notififcation Failed Default Reason Phrase: Push Notififcation Failed
12.3. SIP Global Feature-Capability Indicator 13.3. SIP Global Feature-Capability Indicator
12.3.1. sip.pns 13.3.1. sip.pns
This section defines a new feature-capability indicator that extends This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" sub-registry the "SIP Feature-Capability Indicator Registration Tree" sub-registry
[RFC6809] under the sip-parameters registry: [RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Name: sip.pns Name: sip.pns
Description: This feature-capability indicator, when included in a Description: This feature-capability indicator, when included in a
Feature-Caps header field of a SIP REGISTER request or a SIP 2xx Feature-Caps header field of a SIP REGISTER request or a SIP 2xx
skipping to change at page 22, line 41 skipping to change at page 25, line 5
the indicator value. When included in a 555 (Push Notification the indicator value. When included in a 555 (Push Notification
Service Not Supported) response to a REGISTER request, the the Service Not Supported) response to a REGISTER request, the the
indicator indicates that the entity associated with the indicator indicates that the entity associated with the
indicator supports the SIP push mechanism, and the push indicator supports the SIP push mechanism, and the push
notification service(s) identified by the indicator value. notification service(s) identified by the indicator value.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
12.3.2. sip.vapid 13.3.2. sip.vapid
This section defines a new feature-capability indicator that extends This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" sub-registry the "SIP Feature-Capability Indicator Registration Tree" sub-registry
[RFC6809] under the sip-parameters registry: [RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Name: sip.vapid Name: sip.vapid
Description: This feature-capability indicator, when included in a Description: This feature-capability indicator, when included in a
SIP 2xx response to a SIP REGISTER request, indicates that the SIP 2xx response to a SIP REGISTER request, indicates that the
skipping to change at page 23, line 20 skipping to change at page 25, line 27
the Voluntary Application Server Identification (VAPID) the Voluntary Application Server Identification (VAPID)
mechanism when requesting push notifications towards the SIP UA mechanism when requesting push notifications towards the SIP UA
associated with the SIP registration. The indicator value is a associated with the SIP registration. The indicator value is a
public key identifying the entity, that can be used by a SIP UA public key identifying the entity, that can be used by a SIP UA
to restrict subscriptions to that entity. to restrict subscriptions to that entity.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
12.3.3. sip.pnsreg 13.3.3. sip.pnsreg
This section defines a new feature-capability indicator that extends This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" sub-registry the "SIP Feature-Capability Indicator Registration Tree" sub-registry
[RFC6809] under the sip-parameters registry: [RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Name: sip.pnsreg Name: sip.pnsreg
Description: This feature-capability indicator, when included in a Description: This feature-capability indicator, when included in a
SIP 2xx response to a SIP REGISTER request, indicates that the SIP 2xx response to a SIP REGISTER request, indicates that the
skipping to change at page 23, line 44 skipping to change at page 26, line 22
the entity having to request push notifications towards the SIP the entity having to request push notifications towards the SIP
UA in order to trigger the REGISTER requests. The indicator UA in order to trigger the REGISTER requests. The indicator
value is the minimum value (given in seconds) before the value is the minimum value (given in seconds) before the
registration expireation when the entity expects to receive the registration expireation when the entity expects to receive the
REGISTER request. REGISTER request.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
12.4. SIP Media Feature Tag 13.4. SIP Media Feature Tag
12.4.1. sip.pnsreg
13.4.1. sip.pnsreg
This section defines a new media feature tag that extends the "SIP This section defines a new media feature tag that extends the "SIP
Media Feature Tag Registration Tree" sub-registry [RFC3840] under the Media Feature Tag Registration Tree" sub-registry [RFC3840] under the
Media Feature Tag registry: https://www.iana.org/assignments/media- Media Feature Tag registry: https://www.iana.org/assignments/media-
feature-tags/media-feature-tags.xhtml. feature-tags/media-feature-tags.xhtml.
Media feature tag name: sip.pnsreg Media feature tag name: sip.pnsreg
Summary of the media feature indicated by this feature tag: This Summary of the media feature indicated by this feature tag: This
media feature tag, when included in the SIP Contact header media feature tag, when included in the SIP Contact header
skipping to change at page 24, line 32 skipping to change at page 27, line 26
Related standards or documents: [RFCXXXX] Related standards or documents: [RFCXXXX]
Security considerations: This media feature tag does not introduce Security considerations: This media feature tag does not introduce
new security considerations, as it simply indicates support for new security considerations, as it simply indicates support for
a basic SIP feature. If an attacker manages to remove the media a basic SIP feature. If an attacker manages to remove the media
feature tag, push notifications towards the client will be feature tag, push notifications towards the client will be
requested. requested.
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
12.5. PNS Sub-registry Establishment 13.5. PNS Sub-registry Establishment
This section creates a new sub-registry, "PNS", under the sip- This section creates a new sub-registry, "PNS", under the sip-
parameters registry: http://www.iana.org/assignments/sip-parameters. parameters registry: http://www.iana.org/assignments/sip-parameters.
The purpose of the sub-registry is to register SIP URI pn-provider The purpose of the sub-registry is to register SIP URI pn-provider
values. values.
When a SIP URI pn-provider value is registered in the sub-registry, When a SIP URI pn-provider value is registered in the sub-registry,
it needs to meet the "Specification Required" policies defined in it needs to meet the "Specification Required" policies defined in
[RFC8126]. [RFC8126].
skipping to change at page 25, line 13 skipping to change at page 28, line 4
[RFC8126]. [RFC8126].
This sub-registry is defined as a table that contains the following This sub-registry is defined as a table that contains the following
three columns: three columns:
Value: The token under registration Value: The token under registration
Description: The name of the Push Notification Service (PNS) Description: The name of the Push Notification Service (PNS)
Document: A reference to the document defining the registration Document: A reference to the document defining the registration
This specification registers the following values: This specification registers the following values:
Value Description Document Value Description Document
------- -------------------------------------- ---------- ------- -------------------------------------- ----------
apns Apple Push Notification service [RFC XXXX] apns Apple Push Notification service [RFC XXXX]
fcm Firebase Cloud Messaging [RFC XXXX] fcm Firebase Cloud Messaging [RFC XXXX]
webpush Generic Event Delivery Using HTTP Push [RFC XXXX] webpush Generic Event Delivery Using HTTP Push [RFC XXXX]
13. Acknowledgements 14. Acknowledgements
Thanks to Mickey Arnold, Paul Kyzivat, Dale Worley, Ranjit Avasarala, Thanks to Mickey Arnold, Paul Kyzivat, Dale Worley, Ranjit Avasarala,
Martin Thomson, Mikael Klein, Susanna Sjoholm, Kari-Pekka Perttula, Martin Thomson, Mikael Klein, Susanna Sjoholm, Kari-Pekka Perttula,
Liviu Chircu, Roman Shpount and Yehoshua Gev for reading the text, Liviu Chircu, Roman Shpount and Yehoshua Gev for reading the text,
and providing useful feedback. and providing useful feedback.
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
skipping to change at page 26, line 37 skipping to change at page 29, line 25
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server [RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server
Identification (VAPID) for Web Push", RFC 8292, Identification (VAPID) for Web Push", RFC 8292,
DOI 10.17487/RFC8292, November 2017, <https://www.rfc- DOI 10.17487/RFC8292, November 2017, <https://www.rfc-
editor.org/info/rfc8292>. editor.org/info/rfc8292>.
14.2. Informative References 15.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
editor.org/info/rfc3264>.
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the
Session Initiation Protocol's (SIP) Non-INVITE Session Initiation Protocol's (SIP) Non-INVITE
Transaction", RFC 4320, DOI 10.17487/RFC4320, January Transaction", RFC 4320, DOI 10.17487/RFC4320, January
2006, <https://www.rfc-editor.org/info/rfc4320>. 2006, <https://www.rfc-editor.org/info/rfc4320>.
[RFC4321] Sparks, R., "Problems Identified Associated with the [RFC4321] Sparks, R., "Problems Identified Associated with the
Session Initiation Protocol's (SIP) Non-INVITE Session Initiation Protocol's (SIP) Non-INVITE
Transaction", RFC 4321, DOI 10.17487/RFC4321, January Transaction", RFC 4321, DOI 10.17487/RFC4321, January
2006, <https://www.rfc-editor.org/info/rfc4321>. 2006, <https://www.rfc-editor.org/info/rfc4321>.
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
"Managing Client-Initiated Connections in the Session "Managing Client-Initiated Connections in the Session
Initiation Protocol (SIP)", RFC 5626, Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009, <https://www.rfc- DOI 10.17487/RFC5626, October 2009, <https://www.rfc-
editor.org/info/rfc5626>. editor.org/info/rfc5626>.
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665,
DOI 10.17487/RFC6665, July 2012, <https://www.rfc-
editor.org/info/rfc6665>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, [RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291,
DOI 10.17487/RFC8291, November 2017, <https://www.rfc- DOI 10.17487/RFC8291, November 2017, <https://www.rfc-
editor.org/info/rfc8291>. editor.org/info/rfc8291>.
Authors' Addresses Authors' Addresses
 End of changes. 42 change blocks. 
84 lines changed or deleted 203 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/