draft-ietf-sipcore-sip-push-07.txt   draft-ietf-sipcore-sip-push-08.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: August 20, 2018 Metaswitch Networks Expires: September 1, 2018 Metaswitch Networks
February 16, 2018 February 28, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-07 draft-ietf-sipcore-sip-push-08
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 awake suspended Session Initiation Protocol (SIP) User Agents used to awake suspended Session Initiation Protocol (SIP) User Agents
(UAs), for the UA to be able to receive and send SIP requests. The (UAs), for the UA to be able to receive and send SIP requests. The
document defines new SIP URI parameters and new feature-capability document defines new SIP URI parameters and new feature-capability
indicators that can be used in SIP messages to indicate support of indicators that can be used in SIP messages to indicate support of
the mechanism defined in this document, to exchange PNS information the mechanism defined in this document, to exchange PNS information
between the SIP User Agent (UA) and the SIP entity that will request between the SIP User Agent (UA) and the SIP entity that will request
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 August 20, 2018. This Internet-Draft will expire on September 1, 2018.
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 29 skipping to change at page 2, line 29
5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. REGISTER Request . . . . . . . . . . . . . . . . . . 9 5.3.1. REGISTER Request . . . . . . . . . . . . . . . . . . 9
5.3.2. Initial Request for Dialog or Stand-Alone Request . . 10 5.3.2. Initial Request for Dialog or Stand-Alone Request . . 10
6. Network Address Translator (NAT) Considerations . . . . . . . 11 6. Network Address Translator (NAT) Considerations . . . . . . . 11
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. 555 (Push Notification Service Not Supported) Response 7.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 12 7.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 12
7.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 12 7.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 12
7.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 13 7.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 13
7.5. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 13 7.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 13
7.6. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 14
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 14 8. PNS Registration Requirements . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . 14 Push Notification service . . . . . . . . . . . . . . . . . . 14
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 . . 15 Firebase Cloud Messaging (FCM) push notification service . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 16 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 16
12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 16 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 16
12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 16 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 16
12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 16 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 17
12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 16 12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 17
12.3. SIP Global Feature-Capability Indicator . . . . . . . . 17 12.3. SIP Global Feature-Capability Indicator . . . . . . . . 17
12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 17 12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 17
12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 17 12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 18
12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 18 12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 18
12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 18 12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 19
12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 18 12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 19
12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 19 12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 20
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . 20 14.1. Normative References . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 awake such applications, nor will incoming network traffic used to awake such applications, nor will incoming network traffic
awake the application. Instead, the only way to awake the awake the application. Instead, the only way to awake the
application is by using a Push Notification Service (PNS). Typically application is by using a Push Notification Service (PNS). Typically
each operating system uses a dedicated PNS. For example, Apple iOS each operating system uses a dedicated PNS. For example, Apple iOS
skipping to change at page 6, line 16 skipping to change at page 6, line 16
regarding the push notification registration and maintenance are regarding the push notification registration and maintenance are
outside the scope of this document. The information needed to outside the scope of this document. The information needed to
contact the PNS is typically pre-configured in the operating system contact the PNS is typically pre-configured in the operating system
of the device. of the device.
4. SIP User Agent (UA) Behavior 4. SIP User Agent (UA) Behavior
Once the SIP UA has registered with the PNS, has received the PRID Once the SIP UA has registered with the PNS, has 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
the UA wants to receive push notifications, the UA MUST send a SIP the UA wants to receive push notifications, the UA MUST send a SIP
REGISTER request using normal SIP procedures. The UA MUST include a REGISTER request using normal SIP procedures. The UA MUST include
pn-provider, a pn-prid and a pn-param (if required for the specific the following SIP URI parameters in the SIP Contact header field URI
PNS) SIP URI parameter in the SIP Contact header field URI of the of the REGISTER request: pn-provider, pn-prid and pn-param (if
REGISTER request. The pn-provider URI parameter identifies the PNS, required for the specific PNS). The pn-provider URI parameter
the pn-prid URI parameter contains the PRID value and the pn-param identifies the PNS, the pn-prid URI parameter contains the PRID value
URI parameter contains additional PNS-specific information. and the pn-param URI parameter contains additional PNS-specific
information.
When the UA receives a 2xx response to the REGISTER request, if the When the UA receives a 2xx response to the REGISTER request, if the
response contains a Feature-Caps header field with a 'sip.pns' response contains a Feature-Caps header field with a 'sip.pns'
feature-capability indicator with a parameter value identifying the feature-capability indicator with a parameter value identifying the
same PNS that was identified by the pn-provider URI parameter in the same PNS that was identified by the pn-provider URI parameter in the
REGISTER request, the UA can assume that a SIP proxy will request REGISTER request, the UA can assume that a SIP proxy will request
push notifications towards the UA. In other cases, the UA MUST NOT push notifications towards the UA. In other cases, the UA MUST NOT
assume that push notifications will be requested, and the actions assume that push notifications will be requested, and the actions
taken by the UA might be dependent on implementation or deployment taken by the UA 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.
skipping to change at page 9, line 41 skipping to change at page 9, line 43
proxy MUST either forward the request (e.g., if the proxy knows that proxy MUST either forward the request (e.g., if the proxy knows that
a downstream proxy supports the PNS) or send a SIP 555 (Push a downstream proxy supports the PNS) or send a SIP 555 (Push
Notification Service Not Supported) response to the REGISTER request. Notification Service Not Supported) response to the REGISTER request.
If the proxy sends a SIP 555 (Push Notification Service Not If the proxy sends a SIP 555 (Push Notification Service Not
Supported) response, the proxy SHOULD insert a Feature-Caps header Supported) response, the proxy SHOULD insert a Feature-Caps header
field with a 'sip.pns' feature-capability indicator in the response, field with a 'sip.pns' feature-capability indicator in the response,
identifying each PNS that the proxy supports. identifying each PNS that the proxy supports.
If the proxy supports the PNS identified by the pn-provider SIP URI If the proxy supports the PNS identified by the pn-provider SIP URI
parameter, the proxy MUST insert a Feature-Caps header field with a parameter, the proxy MUST insert a Feature-Caps header field with a
'sip.pns' feature-capability indicator in the REGISTER request before 'sip.pns' feature-capability indicator, identifying the PNS, in the
forwarding the REGISTER request (unless the proxy is the registrar, REGISTER request before forwarding the REGISTER request (unless the
in which case the proxy will terminate the REGISTER request). This proxy is the registrar, in which case the proxy will terminate the
will inform downstream proxies that the proxy supports, and will REGISTER request). This will inform downstream proxies that the
request, push notifications towards the UA. proxy supports, and will request, push notifications towards the UA.
If the proxy inserted a Feature-Caps header field with a 'sip.pns' If the proxy inserted a Feature-Caps header field with a 'sip.pns'
feature-capability indicator in the REGISTER request (see above), feature-capability indicator in the REGISTER request (see above),
when the proxy receives (or, in case the proxy is the SIP registrar, when the proxy receives (or, in case the proxy is the SIP registrar,
creates) a 2xx response to the REGISTER request, the proxy MUST creates) a 2xx response to the REGISTER request, the proxy MUST
insert a Feature-Caps header field with a 'sip.pns' feature- insert a Feature-Caps header field with a 'sip.pns' feature-
capability indicator in the response, identifying the PNS. This will capability indicator in the response, identifying the PNS. This will
inform the UA that the proxy supports, and will request, push inform the UA that the proxy supports, and will request, push
notifications towards the UA. The proxy MUST only indicate support notifications towards the UA. The proxy MUST only indicate support
of the same PNS that was identified in the pn-provider SIP URI of the same PNS that was identified in the pn-provider SIP URI
skipping to change at page 11, line 20 skipping to change at page 11, line 23
If the push notification request fails (see PNS-specific If the push notification request fails (see PNS-specific
documentation for details), the proxy MUST reject the SIP request documentation for details), the proxy MUST reject the SIP request
with a 555 (Push Notification Service Not Supported) response. with a 555 (Push Notification Service Not Supported) response.
NOTE: As described above, the reason the proxy needs to wait for the NOTE: As described above, the reason the proxy needs to wait for the
REGISTER response before forwarding the SIP request is to make sure REGISTER response before forwarding the SIP request is to make sure
that the REGISTER request has been accepted by the SIP registrar, and that the REGISTER request has been accepted by the SIP registrar, and
that the registered contact matches the Request-URI of the SIP that the registered contact matches the Request-URI of the SIP
request to be forwarded. request to be forwarded.
If the proxy does not receive the REGISTER request from the UA within
a given time after the proxy has requested the push notification, the
proxy MUST reject the request with a 404 (Not Found) response. The
time value is set based on local policy.
The proxy MUST NOT include the SIP request as payload in the The proxy MUST NOT include the SIP request as payload in the
requested push message. requested push message.
If the proxy has knowledge that the UA is awake, and that the UA is If the proxy has knowledge that the UA is awake, and that the UA is
able to receive the SIP request without first sending a REGISTER able to receive the SIP request without first sending a REGISTER
request, the proxy MAY choose to not request a push notification request, the proxy MAY choose to not request a push notification
towards the UA (and wait for the associated REGISTER request and 2xx towards the UA (and wait for the associated REGISTER request and 2xx
response) before it tries to forward the SIP request towards the UA. response) before it tries to forward the SIP request towards the UA.
The mechanisms for getting such knowledge might be dependent on The mechanisms for getting such knowledge might be dependent on
implementation or deployment architecture, and are outside the scope implementation or deployment architecture, and are outside the scope
skipping to change at page 12, line 22 skipping to change at page 12, line 26
service identified in a 'pn-provider' SIP URI parameter, or that the service identified in a 'pn-provider' SIP URI parameter, or that the
server failed to request a push notification from the push server failed to request a push notification from the push
notification service. notification service.
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 to SIP requests initiating dialogs and responses responses, responses to SIP requests initiating dialogs and responses
to stand-alone SIP requests. to stand-alone SIP requests.
7.2. sip.pns Feature-Capability Indicator 7.2. sip.pns Feature-Capability Indicator
The sip.pns feature-capability indicator is used in a SIP request, or The sip.pns feature-capability indicator, when included in a Feature-
in a SIP 2xx response to a REGISTER request, to indicate that the Caps header field of a SIP REGISTER request or a SIP 2xx response to
entity associated with the indicator supports, and will use, the push a REGISTER request, indicates that the entity associated with the
notification service identified by the indicator value. The feature- indicator supports, and will use, the SIP push mechanism and the push
capability indicator is used in a SIP 555 (Push Notification Service notification service identified by the indicator value. When
Not Supported) response to a REGISTER request to indicate which push included in a 555 (Push Notification Service Not Supported) response
notification services the entity associated with the indicator to a REGISTER request, the the indicator indicates that the entity
supports. The values defined for the pn-provider SIP URI parameter associated with the indicator supports the SIP push mechanism, and
are used. the push notification service(s) identified by the indicator value.
The values defined for the pn-provider SIP URI parameter are used as
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
7.3. sip.vapid Feature-Capability Indicator 7.3. sip.vapid Feature-Capability Indicator
The sip.vapid feature-capability indicator is used in a SIP 2xx The sip.vapid feature-capability indicator, when included in a SIP
response to a SIP REGISTER request to indicate 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 contains a public key SIP registration. The indicator value is a public key identifying
identifying the entity, that can be used by a SIP UA to restrict the entity, that can be used by a SIP UA to restrict subscriptions to
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
7.4. sip.pnsreg Feature-Capability Indicator 7.4. sip.pnsreg Feature-Capability Indicator
The sip.pnsreg feature-capability indicator is used in a 2xx response The sip.pnsreg feature-capability indicator, when included in a SIP
to a SIP REGISTER request to indicate that the entity associated with 2xx response to a SIP REGISTER request, indicates that the entity
the indicator expects to receive re-registration REGISTER requests associated with the indicator expects to receive re-registration
before the registration expires. The indicator value indicates the REGISTER requests from the SIP UA associated with the registration
minimum value (given in seconds) before the registration expireation before the registration expires, without the entity having to request
when the entity expects to receive the REGISTER request. push notifications towards the SIP UA in order to trigger the
REGISTER requests. The indicator value is the minimum value (given
in seconds) before the registration expireation when the entity
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
7.5. SIP URI Parameters ; DIGIT as defined in RFC 3261
7.5. sip.pnsreg Media Feature Tag
The sip.pnsreg media feature tag, when included in the SIP Contact
header field of a SIP REGISTER request, indciates that the SIP UA
associated with the tag is able to send re-registration REGISTER
requests associated with the registration without being awaken by
push notifications. The media feature tag has no values.
pns-mt = "+sip.pnsreg"
7.6. 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
skipping to change at page 15, line 13 skipping to change at page 15, line 35
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 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 Sender 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
11. Security Considerations 11. 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
skipping to change at page 17, line 18 skipping to change at page 18, line 5
12.3. SIP Global Feature-Capability Indicator 12.3. SIP Global Feature-Capability Indicator
12.3.1. sip.pns 12.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 REGISTER response, indicates Feature-Caps header field of a SIP REGISTER request or a SIP 2xx
that the server supports the SIP push mechanism. The value response to a REGISTER request, indicates that the entity
indicates the push notification service supported by the server. associated with the indicator supports, and will use, the SIP
push mechanism and the push notification service identified by
the indicator value. When included in a 555 (Push Notification
Service Not Supported) response to a REGISTER request, the the
indicator indicates that the entity associated with the
indicator supports the SIP push mechanism, and the push
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 12.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
Feature-Caps header field of a REGISTER response, indicates that SIP 2xx response to a SIP REGISTER request, indicates that the
the server supports the Voluntary Application Server entity associated with the indicator supports, and will use,
Identification (VAPID) mechanism, defined in RFC 8292. The value the Voluntary Application Server Identification (VAPID)
is a public key of the server. mechanism when requesting push notifications towards the SIP UA
associated with the SIP registration. The indicator value is a
public key identifying the entity, that can be used by a SIP UA
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 12.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
Feature-Caps header field of a SIP REGISTER response, indicates SIP 2xx response to a SIP REGISTER request, indicates that the
that the server supports the case where the client will send a entity associated with the indicator expects to receive
re-registration REGISTER request, without the use of a push re-registration REGISTER requests from the SIP UA associated
notification, before the registration expires. The indicator with the registration before the registration expires, without
value indicates the minimum time before the registration expires the entity having to request push notifications towards the SIP
that the server expects the client to send the REGISTER requests. UA in order to trigger the REGISTER requests. The indicator
value is the minimum value (given in seconds) before the
registration expireation when the entity expects to receive the
REGISTER request.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
12.4. SIP Media Feature Tag 12.4. SIP Media Feature Tag
12.4.1. sip.pnsreg 12.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 a Contact header field of media feature tag, when included in the SIP Contact header
a REGISTER request, indicates that the client is able to send field of a SIP REGISTER request, indciates that the SIP UA
re-registration REGISTER requests without being awaken by a push associated with the tag is able to send re-registration
notification. REGISTER requests associated with the registration without
being awaken by push notifications.
Values appropriate for use with this feature tag: none Values appropriate for use with this feature tag: none
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 12.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,
 End of changes. 33 change blocks. 
85 lines changed or deleted 123 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/