draft-ietf-sipcore-sip-push-02.txt   draft-ietf-sipcore-sip-push-03.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track December 21, 2017 Intended status: Standards Track January 4, 2018
Expires: June 24, 2018 Expires: July 8, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-02 draft-ietf-sipcore-sip-push-03
Abstract Abstract
This document describes how push notification mechanisms can be used This document describes how push notification mechanisms can be used
to wake up suspended Session Initiation Protocol (SIP) User Agents to wake up suspended Session Initiation Protocol (SIP) User Agents
(UAs), in order to be able to receive and generate SIP requests. The (UAs), in order to be able to receive and generate SIP requests. The
document defines new SIP URI parameters, that can be used in a SIP document defines new SIP URI parameters, that can be used in a SIP
REGISTER request to provide push notification information from the REGISTER request to provide push notification information from the
SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in
this document) that will send a push request to the push server in this document) that will send a push request to the push server in
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 June 24, 2018. This Internet-Draft will expire on July 8, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
5.1. PNS Provider Information . . . . . . . . . . . . . . . . 6 5.1. PNS Provider Information . . . . . . . . . . . . . . . . 6
5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 6 5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 6
5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 7
6. Network Address Translator (NAT) Considerations . . . . . . . 8 6. Network Address Translator (NAT) Considerations . . . . . . . 8
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. 555 (Push Notification Service Not Supported) Response 7.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 8 7.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 8
7.3. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 8 7.3. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 8
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 9 8. PNS Registration Requirements . . . . . . . . . . . . . . . . 9
9. pn-provider, pn-param and pn-prid URI parameters for Apple 9. pn-provider, pn-param and pn-prid URI Parameters for Apple
Push Notification service . . . . . . . . . . . . . . . . . . 9 Push Notification service . . . . . . . . . . . . . . . . . . 9
10. pn-provider, pn-param and pn-prid URI parameters for Google 10. pn-provider, pn-param and pn-prid URI Parameters for Google
Firebase Cloud Messaging (FCM) push notification service . . 10 Firebase Cloud Messaging (FCM) push notification service . . 10
11. Security considerations . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 11 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 11
12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 11 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 11
12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 11 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 11
12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 11 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 11
12.1.4. pn-enckey . . . . . . . . . . . . . . . . . . . . . 12 12.1.4. pn-enckey . . . . . . . . . . . . . . . . . . . . . 12
12.1.5. pn-enccode . . . . . . . . . . . . . . . . . . . . . 12 12.1.5. pn-enccode . . . . . . . . . . . . . . . . . . . . . 12
12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 12 12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 12
12.3. SIP Global Feature-Capability Indicator . . . . . . . . 12 12.3. SIP Global Feature-Capability Indicator . . . . . . . . 12
12.4. PNS Sub-registry Establishment . . . . . . . . . . . . . 13 12.4. PNS Sub-registry Establishment . . . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative references . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative references . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
In order to save resources (e.g, battery life) some devices and In order to save resources (e.g, battery life) some devices and
operating systems require suspended Session Initiation Protocol (SIP) operating systems require suspended Session Initiation Protocol (SIP)
User Agents (UAs) [RFC3261] to be woken up using a push notification User Agents (UAs) [RFC3261] to be woken up using a push notification
service. Typically each operating system uses a dedicated push service. Typically each operating system uses a dedicated push
notification service. For example, Apple iOS devices use the Apple notification service. For example, Apple iOS devices use the Apple
Push Notification service (APNs). Push Notification service (APNs).
skipping to change at page 3, line 28 skipping to change at page 3, line 28
push server in order to trigger a push notification towards the SIP push server in order to trigger a push notification towards the SIP
UA. UA.
When a SIP UA registers to a Push Notification Service (PNS), it will When a SIP UA registers to a Push Notification Service (PNS), it will
receive a unique Push Resource ID (PRID) associated to that receive a unique Push Resource ID (PRID) associated to that
registration. The SIP UA will provide the PRID to the SIP network in registration. The SIP UA will provide the PRID to the SIP network in
a SIP REGISTER request. A SIP proxy (e.g., the SIP registrar) will a SIP REGISTER request. A SIP proxy (e.g., the SIP registrar) will
store a mapping between the registered contact and the PRID. store a mapping between the registered contact and the PRID.
When the SIP proxy receives (or, in case the SIP proxy is also When the SIP proxy receives (or, in case the SIP proxy is also
registrar, initiates) a SIP request for a new session, or a stand- registrar, initiates) a SIP request for a new dialog, or a stand-
alone SIP request, addressed towards a SIP UA, or when the SIP proxy alone SIP request, addressed towards a SIP UA, or when the SIP proxy
determines that the SIP UA needs to perform a re-registration, the determines that the SIP UA needs to perform a re-registration, the
SIP proxy will send a push request to the push notification service SIP proxy will send a push request to the push notification service
used by the SIP UA, using the push resource ID associated with the used by the SIP UA, using the push resource ID associated with the
registered contact of the SIP UA, in order to trigger a push registered contact of the SIP UA, in order to trigger a push
notification towards the SIP UA. The SIP proxy will then forward the notification towards the SIP UA. Once the SIP UA receives the push
SIP request towards the SIP UA using normal SIP routing procedures. notification, it will be to receive the SIP request, and to generate
Once the SIP UA receives the push notification, it will be to receive a SIP request (e.g., a SIP REGISTER) itself. The proxy can use the
the SIP request, and to generate a SIP request (e.g., a SIP REGISTER) receipt of the REGISTER request as a trigger to forward SIP request
itself. towards the UA, using normal SIP routing procedures.
Different push notification mechanisms exist today. Some are based Different push notification mechanisms exist today. Some are based
on there standardized mechanism defined in [RFC8030], while others on there standardized mechanism defined in [RFC8030], while others
are proprietary (e.g., the Apple Push Notification service). are proprietary (e.g., the Apple Push Notification service).
Figure 1 shows the generic push notification architecture supported Figure 1 shows the generic push notification architecture supported
by the mechanism in this document. by the mechanism in this document.
+--------+ +--------------+ +-----------------+ +--------+ +--------------+ +-----------------+
| SIP UA | | Push Service | | SIP Proxy | | SIP UA | | Push Service | | SIP Proxy |
+--------+ +--------------+ +-----------------+ +--------+ +--------------+ +-----------------+
skipping to change at page 5, line 11 skipping to change at page 5, line 11
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Push Resource ID (PRID) 3. Push Resource ID (PRID)
When an entity registers with a PNS it receives a unique Push When an entity registers with a PNS it receives a unique Push
Resource ID (PRID), which is a value associated with the Resource ID (PRID), which is a value associated with the
registration. registration.
The format of the PRID may vary depending on the PNS provider. The The format of the PRID may vary depending on the PNS provider.
PRID may be part of a URI that can be used to retrieve the address
and port of the PNS when sending push requests to the PNS. The PRID
may also be a token value, in which case the address and port of the
PNS needs to be provided using other means.
The details regarding discovery of the PNS, and the procedures for The details regarding discovery of the PNS, and the procedures for
the push notification registration and maintenance are outside the the push notification registration and maintenance are outside the
scope of this document. The information needed to contact the PNS is scope of this document. The information needed to contact the PNS is
typically pre-configured in the operating system (OS) of the device. typically pre-configured in the operating system (OS) of the device.
4. SIP User Agent (UA) Behavior 4. SIP User Agent (UA) Behavior
Once the SIP UA has registered with the PNS and received the PRID Once the SIP UA has registered with the PNS and received the PRID
(using the protocol and procedures associated with the PNS), and when (using the protocol and procedures associated with the PNS), and when
skipping to change at page 6, line 9 skipping to change at page 6, line 4
the SIP proxy, the REGISTER request will create NAT bindings allowing the SIP proxy, the REGISTER request will create NAT bindings allowing
incoming SIP requests to reach the UA. If the SIP proxy triggered incoming SIP requests to reach the UA. If the SIP proxy triggered
the push notification because it wants to forward a SIP request the push notification because it wants to forward a SIP request
towards the UA, the receipt of the REGISTER request can be used by towards the UA, the receipt of the REGISTER request can be used by
the proxy as a trigger to forward the request. the proxy as a trigger to forward the request.
As long as the SIP UA wants the SIP proxy to continue sending push As long as the SIP UA wants the SIP proxy to continue sending push
requests, the UA MUST include a pn-provider, pn-prid and a pn-param requests, the UA MUST include a pn-provider, pn-prid and a pn-param
(if required for the specific PNS provider) SIP URI parameter in (if required for the specific PNS provider) SIP URI parameter in
every re-registration SIP REGISTER request sent towards the proxy. every re-registration SIP REGISTER request sent towards the proxy.
Note that, in some cases, the PNS might update the PRID value, in Note that, in some cases, the PNS might update the PRID value, in
which case the pn-prid URI parameter within the re-registration which case the pn-prid URI parameter within the re-registration
REGISTER request will contain the new value. REGISTER request will contain the new value.
If the SIP UA at some point wants to stop the SIP proxy from sending If the SIP UA at some point wants to stop the SIP proxy from sending
push requests, the UA MUST send a SIP REGISTER request without the push requests, the UA MUST send a SIP REGISTER request without the
URI parameters described above. URI parameters described above, or remove the registration.
If the SIP UA expects to receive payload in the push notification, If the SIP UA expects to receive payload in the push notification,
the UA MAY add a pn-enckey and a pn-encsec SIP Contact header field the UA MAY add a pn-enckey and a pn-encsec SIP Contact header field
SIP URI parameter, in order to allow encryption of the data using the SIP URI parameter, in order to allow encryption of the data using the
mechanism in [RFC8291]. The pn-enckey URI parameter contains the mechanism in [RFC8291]. The pn-enckey URI parameter contains the
public key, and the pn-encsec URI parameter contains the public key, and the pn-encsec URI parameter contains the
authentication secret [RFC8291]. authentication secret [RFC8291]. The format of such payload is
outside the scope of this document.
NOTE: End-to-end encryption of the payload between the SIP proxy and NOTE: End-to-end encryption of the payload between the SIP proxy and
the SIP UA cannot be used if the push notification request payload the SIP UA cannot be used if the push notification request payload
contains information that needs to be accessible by the PNS provider. contains information that needs to be accessible by the PNS provider.
5. SIP Proxy Behavior 5. SIP Proxy Behavior
5.1. PNS Provider Information 5.1. PNS Provider Information
The PNS provider is retrieved from the pn-provider SIP URI parameter. The PNS provider is retrieved from the pn-provider SIP URI parameter.
skipping to change at page 7, line 5 skipping to change at page 6, line 47
If the SIP UA needs to perform periodic re-registrations, the proxy If the SIP UA needs to perform periodic re-registrations, the proxy
needs to have information about when those re-registrations are to be needs to have information about when those re-registrations are to be
performed. The proxy either needs to contain the SIP registrar performed. The proxy either needs to contain the SIP registrar
functionality, or the proxy needs to retrieve the information from functionality, or the proxy needs to retrieve the information from
the registrar using some other mechanism. the registrar using some other mechanism.
When the SIP proxy receives an indication that the SIP UA needs to When the SIP proxy receives an indication that the SIP UA needs to
perform a re-registration, the proxy triggers a push request towards perform a re-registration, the proxy triggers a push request towards
the push notification server associated with the PRID. the push notification server associated with the PRID.
Note that the re-registration needs to be triggered early enough, in
order for the re-registration request to reach the registrar before
the registration expires.
5.3. SIP Request 5.3. SIP Request
When the SIP proxy receives a SIP REGISTER request that contains a When the SIP proxy receives a SIP REGISTER request that contains a
pn-provider SIP URI parameter value that the proxy does not support, pn-provider SIP URI parameter value that the proxy does not support,
or if the REGISTER request does not contain all information required or if the REGISTER request does not contain all information required
for the specific PNS provider, the proxy MUST either forward the for the specific PNS provider, the proxy MUST either forward the
request (e.g., if the proxy is aware of another proxy that supports request (e.g., if the proxy is aware of another proxy that supports
the PNS provider) or send a SIP 555 (Push Notification Service Not the PNS provider) or send a SIP 555 (Push Notification Service Not
Supported) response to the REGISTER request. If the proxy sends a Supported) response to the REGISTER request. If the proxy sends a
SIP 555 (Push Notification Service Not Supported), the proxy SHOULD SIP 555 (Push Notification Service Not Supported), the proxy SHOULD
skipping to change at page 7, line 32 skipping to change at page 7, line 32
parameter in the response, in order to inform the SIP UA that the parameter in the response, in order to inform the SIP UA that the
proxy supports the PNS indicated by the pn-provider SIP URI parameter proxy supports the PNS indicated by the pn-provider SIP URI parameter
value. value.
When the SIP proxy receives (or, in case the proxy is the SIP When the SIP proxy receives (or, in case the proxy is the SIP
registrar, creates) a SIP request for a new dialog (e.g., a SIP registrar, creates) a SIP request for a new dialog (e.g., a SIP
INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE
request) aimed for a SIP UA, if the Request-URI of the request request) aimed for a SIP UA, if the Request-URI of the request
contains a pn-provider, a pn-prid and a pn-param (if required for the contains a pn-provider, a pn-prid and a pn-param (if required for the
specific PNS provider) SIP URI parameter, the proxy triggers a push specific PNS provider) SIP URI parameter, the proxy triggers a push
request towards the PNS associated with the PRID. After that, the request towards the PNS associated with the PRID. After that the
proxy forwards the SIP request towards the UA using normal SIP proxy forwards the SIP request towards the UA using normal SIP
procedures. procedures.
As the push notification will trigger the SIP UA to perform a re- As the push notification will trigger the SIP UA to perform a re-
registration, the SIP proxy can use the receipt of the SIP REGISTER registration, the SIP proxy can use the receipt of the SIP REGISTER
request as a trigger to forward SIP request towards the UA. request as a trigger to forward SIP request towards the UA.
The SIP proxy MUST NOT transport the SIP request as push request The SIP proxy MUST NOT transport the SIP request as push request
payload, instead of forwarding the request using normal SIP payload, instead of forwarding the request using normal SIP
procedures. procedures.
If the SIP proxy is not able to contact the push notification
provider, or even retrieve the PNS provider, the proxy SHOULD reject
the SIP request.
If the SIP proxy is able to assume that the SIP UA is awake, and that If the SIP proxy is able to assume that the SIP UA is awake, and that
the UA is able to receive the SIP request, the proxy MAY choose to the UA is able to receive the SIP request, the proxy MAY choose to
not trigger a push notification request before trying to forward the not trigger a push notification request before trying to forward the
SIP request towards the UA. The mechanisms for making such SIP request towards the UA. The mechanisms for making such
assumption might be dependent on implementation or deployment assumption might be dependent on implementation or deployment
architecture, and are outside the scope of this document. architecture, and are outside the scope of this document.
If the SIP proxy is not able to contact the push notification
provider, or to forward the SIP request to the SIP UA, the proxy MUST
reject the SIP request.
6. Network Address Translator (NAT) Considerations 6. Network Address Translator (NAT) Considerations
Whenever the SIP UA receives a push notification, if the UA is Whenever the SIP UA receives a push notification, if the UA is
located behind a Network Address Translator (NAT), the UA might need located behind a Network Address Translator (NAT), the UA might need
to take actions in order to establish a binding in the NAT, in order to take actions in order to establish a binding in the NAT, in order
for an incoming SIP request to reach the UA. By performing the re- for an incoming SIP request to reach the UA. By performing the re-
registration the UA will establish such NAT binding. registration the UA will establish such NAT binding.
7. Grammar 7. Grammar
skipping to change at page 9, line 35 skipping to change at page 9, line 35
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.
o Whether there are any restrictions regarding usage of payload o Whether there are any restrictions regarding usage of payload
encryption [RFC8291] with the associated PNS. encryption [RFC8291] with the associated PNS.
9. 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
skipping to change at page 10, line 21 skipping to change at page 10, line 21
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
10. pn-provider, pn-param and pn-prid URI parameters for Google 10. pn-provider, pn-param and pn-prid URI Parameters for Google
Firebase 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 Sender ID. The value of the pn-param URI parameter is the Sender 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 Sender ID and Registration token: For more information on the Sender ID and Registration token:
https://firebase.google.com/docs/cloud-messaging/concept-options https://firebase.google.com/docs/cloud-messaging/concept-options
11. Security considerations 11. Security Considerations
In addition to the information exchanged between a device and its PNS In addition to the information exchanged between a device and its PNS
in order to establish a push notification subscription, the mechanism in order to establish a push notification subscription, the mechanism
in this document does not require entities to provide any additional in this document does not require entities to provide any additional
information to the PNS. information to the PNS.
Push notification mechanisms provide different methods to ensure that Push notification mechanisms provide different methods to ensure that
malicious user cannot trigger push notifications to a device. Users malicious user cannot trigger push notifications to a device. Users
of the mechanism in this document MUST take measures to prevent push of the mechanism in this document MUST take measures to prevent push
notifications from being sent to a device from a malicious user. notifications from being sent to a device from a malicious user.
skipping to change at page 14, line 7 skipping to change at page 14, line 7
fcm Firebase Cloud Messaging [RFC XXXX] fcm Firebase Cloud Messaging [RFC XXXX]
13. Acknowledgements 13. 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 and Kari-Pekka Perttula Martin Thomson, Mikael Klein, Susanna Sjoholm and Kari-Pekka Perttula
for reading the text, and providing useful feedback. for reading the text, and providing useful feedback.
14. References 14. References
14.1. Normative references 14.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 14, line 37 skipping to change at page 14, line 37
Indicate Support of Features and Capabilities in the Indicate Support of Features and Capabilities in the
Session Initiation Protocol (SIP)", RFC 6809, Session Initiation Protocol (SIP)", RFC 6809,
DOI 10.17487/RFC6809, November 2012, <https://www.rfc- DOI 10.17487/RFC6809, November 2012, <https://www.rfc-
editor.org/info/rfc6809>. editor.org/info/rfc6809>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
Event Delivery Using HTTP Push", RFC 8030, Event Delivery Using HTTP Push", RFC 8030,
DOI 10.17487/RFC8030, December 2016, <https://www.rfc- DOI 10.17487/RFC8030, December 2016, <https://www.rfc-
editor.org/info/rfc8030>. editor.org/info/rfc8030>.
14.2. Informative references 14.2. Informative References
[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>.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
 End of changes. 23 change blocks. 
33 lines changed or deleted 35 lines changed or added

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