draft-ietf-ecrit-data-only-ea-20.txt   draft-ietf-ecrit-data-only-ea-21.txt 
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft Internet-Draft
Intended status: Standards Track H. Schulzrinne Intended status: Standards Track H. Schulzrinne
Expires: August 2, 2020 Columbia U. Expires: August 17, 2020 Columbia U.
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
R. Gellens R. Gellens
Core Technology Consulting Core Technology Consulting
January 30, 2020 February 14, 2020
Non-Interactive Emergency Calls Non-Interactive Emergency Calls
draft-ietf-ecrit-data-only-ea-20 draft-ietf-ecrit-data-only-ea-21
Abstract Abstract
RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'
describes how devices use the Internet to place emergency calls and describes how devices use the Internet to place emergency calls and
how Public Safety Answering Points (PSAPs) handle Internet multimedia how Public Safety Answering Points (PSAPs) handle Internet multimedia
emergency calls natively. The exchange of multimedia traffic for emergency calls natively. The exchange of multimedia traffic for
emergency services involves a Session Initiation Protocol (SIP) emergency services involves a Session Initiation Protocol (SIP)
session establishment starting with a SIP INVITE that negotiates session establishment starting with a SIP INVITE that negotiates
various parameters for that session. These calls involve a person, various parameters for that session. These calls involve a person,
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 2, 2020. This Internet-Draft will expire on August 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 4 skipping to change at page 3, line 4
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Registration of the 10.1. Registration of the
'application/EmergencyCallData.cap+xml' MIME type . . . 17 'application/EmergencyCallData.cap+xml' MIME type . . . 17
10.2. IANA Registration of 'cap' Additional Data Block . . . . 18 10.2. IANA Registration of 'cap' Additional Data Block . . . . 18
10.3. IANA Registration for 425 Response Code . . . . . . . . 18 10.3. IANA Registration for 425 Response Code . . . . . . . . 18
10.4. IANA Registration of New AlertMsg-Error Header Field . . 19 10.4. IANA Registration of New AlertMsg-Error Header Field . . 19
10.5. IANA Registration for the SIP AlertMsg-Error Codes . . . 19 10.5. IANA Registration for the SIP AlertMsg-Error Codes . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
[RFC6443] describes how devices use the Internet to place emergency [RFC6443] describes how devices use the Internet to place emergency
calls and how Public Safety Answering Points (PSAPs) handle Internet calls and how Public Safety Answering Points (PSAPs) handle Internet
multimedia emergency calls natively. The exchange of multimedia multimedia emergency calls natively. The exchange of multimedia
traffic for emergency services involves a SIP session establishment traffic for emergency services involves a SIP session establishment
starting with a SIP INVITE that negotiates various parameters for starting with a SIP INVITE that negotiates various parameters for
that session. that session.
skipping to change at page 10, line 37 skipping to change at page 10, line 37
similar to the string phrase used for SIP response codes. The similar to the string phrase used for SIP response codes. The
strings in this document are recommendations, and are not strings in this document are recommendations, and are not
standardized -- meaning an operator can change the strings -- but standardized -- meaning an operator can change the strings -- but
MUST NOT change the meaning of the error code. Similar to how RFC MUST NOT change the meaning of the error code. Similar to how RFC
3261 specifies, there MUST NOT be more than one string per error 3261 specifies, there MUST NOT be more than one string per error
code. code.
The AlertMsg-Error header field MAY be included in any response if an The AlertMsg-Error header field MAY be included in any response if an
alert message was in the request part of the same transaction. For alert message was in the request part of the same transaction. For
example, a UA includes an alert in a MESSAGE to a PSAP. The PSAP can example, a UA includes an alert in a MESSAGE to a PSAP. The PSAP can
accept this MESSAGE, thus creating a dialog, even though its UA accept this MESSAGE, even though its UA determined that the alert
determined that the alert message contained in the MESSAGE was bad. message contained in the MESSAGE was bad. The PSAP merely includes
The PSAP merely includes an AlertMsg-Error header field value in the an AlertMsg-Error header field value in the 200 OK to the MESSAGE,
200 OK to the MESSAGE, thus informing the UA that the MESSAGE was thus informing the UA that the MESSAGE was accepted but the alert
accepted but the alert provided was bad. provided was bad.
If, on the other hand, the PSAP cannot accept the transaction without If, on the other hand, the PSAP cannot accept the transaction without
a suitable alert message, a 425 response is sent. a suitable alert message, a 425 response is sent.
A SIP intermediary that requires the UA's alert message in order to A SIP intermediary that requires the UA's alert message in order to
properly process the transaction may also sends a 425 with an properly process the transaction may also sends a 425 with an
AlertMsg-Error code. AlertMsg-Error code.
This document defines an initial list of AlertMsg-Error values for This document defines an initial list of AlertMsg-Error values for
any SIP response, including provisional responses (other than 100 any SIP response, including provisional responses (other than 100
Trying) and the new 425 response. There MUST be no more than one Trying) and the new 425 response. There MUST be no more than one
AlertMsg-Error code in a SIP response. AlertMsg-Error code in a SIP response. AlertMsg-Error values sent in
provisional responses must be sent using the mechanism defined in
[RFC3262]; or, if that mechanism is not negotiated, it must be
repeated in the final response to the transaction.
AlertMsg-Error: 100 ; code="Cannot Process the Alert Payload" AlertMsg-Error: 100 ; code="Cannot Process the Alert Payload"
AlertMsg-Error: 101 ; code="Alert Payload was not present or could AlertMsg-Error: 101 ; code="Alert Payload was not present or could
not be found" not be found"
AlertMsg-Error: 102 ; code="Not enough information to determine the AlertMsg-Error: 102 ; code="Not enough information to determine the
purpose of the alert" purpose of the alert"
AlertMsg-Error: 103 ; code="Alert Payload was corrupted" AlertMsg-Error: 103 ; code="Alert Payload was corrupted"
skipping to change at page 12, line 13 skipping to change at page 12, line 15
MESSAGE structure. Additionally, the sensor provided some data along MESSAGE structure. Additionally, the sensor provided some data along
with the alert message, using proprietary information elements with the alert message, using proprietary information elements
intended only to be processed by the receiver, a SIP entity acting as intended only to be processed by the receiver, a SIP entity acting as
an aggregator. an aggregator.
MESSAGE sip:aggregator@example.com SIP/2.0 MESSAGE sip:aggregator@example.com SIP/2.0
Via: SIP/2.0/TCP sensor1.example.com;branch=z9hG4bK776sgdkse Via: SIP/2.0/TCP sensor1.example.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70 Max-Forwards: 70
From: sip:sensor1@example.com;tag=49583 From: sip:sensor1@example.com;tag=49583
To: sip:aggregator@example.com To: sip:aggregator@example.com
Call-ID: asd88asd77a@2001:DB8:0:0FF Call-ID: asd88asd77a@2001:db8::ff
Geolocation: <cid:abcdef@example.com> Geolocation: <cid:abcdef@example.com>
;routing-allowed=yes ;routing-allowed=yes
Supported: geolocation Supported: geolocation
Accept: application/pidf+xml,application/EmergencyCallData.cap+xml Accept: application/pidf+xml,application/EmergencyCallData.cap+xml
CSeq: 1 MESSAGE CSeq: 1 MESSAGE
Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
skipping to change at page 12, line 24 skipping to change at page 12, line 26
Geolocation: <cid:abcdef@example.com> Geolocation: <cid:abcdef@example.com>
;routing-allowed=yes ;routing-allowed=yes
Supported: geolocation Supported: geolocation
Accept: application/pidf+xml,application/EmergencyCallData.cap+xml Accept: application/pidf+xml,application/EmergencyCallData.cap+xml
CSeq: 1 MESSAGE CSeq: 1 MESSAGE
Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/EmergencyCallData.cap+xml Content-Type: application/EmergencyCallData.cap+xml
Content-ID: <abcdef2@example.com> Content-ID: <abcdef2@example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1"> <?xml version="1.0" encoding="UTF-8"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
<identifier>S-1</identifier> <identifier>S-1</identifier>
<sender>sip:sensor1@example.com</sender> <sender>sip:sensor1@example.com</sender>
<sent>2008-11-19T14:57:00-07:00</sent> <sent>2008-11-19T14:57:00-07:00</sent>
<status>Actual</status> <status>Actual</status>
<msgType>Alert</msgType> <msgType>Alert</msgType>
<scope>Private</scope> <scope>Private</scope>
<incidents>abc1234</incidents> <incidents>abc1234</incidents>
<info> <info>
<category>Security</category> <category>Security</category>
<event>BURGLARY</event> <event>BURGLARY</event>
skipping to change at page 13, line 7 skipping to change at page 13, line 9
<senderName>SENSOR 1</senderName> <senderName>SENSOR 1</senderName>
<parameter> <parameter>
<valueName>SENSOR-DATA-NAMESPACE1</valueName> <valueName>SENSOR-DATA-NAMESPACE1</valueName>
<value>123</value> <value>123</value>
</parameter> </parameter>
<parameter> <parameter>
<valueName>SENSOR-DATA-NAMESPACE2</valueName> <valueName>SENSOR-DATA-NAMESPACE2</valueName>
<value>TRUE</value> <value>TRUE</value>
</parameter> </parameter>
</info> </info>
</alert> </alert>
--boundary1 --boundary1
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: <abcdef2@example.com> Content-ID: <abcdef2@example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence <presence
xmlns="urn:ietf:params:xml:ns:pidf" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp= xmlns:gbp=
"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com"> entity="pres:alice@atlanta.example.com">
skipping to change at page 16, line 20 skipping to change at page 16, line 20
occurrence of an alert-relevant event. For example, a sensor may occurrence of an alert-relevant event. For example, a sensor may
simply be malfunctioning. For this reason, not all alert messages simply be malfunctioning. For this reason, not all alert messages
are directly sent to a PSAP, but rather may be pre-processed by a are directly sent to a PSAP, but rather may be pre-processed by a
separate entity, potentially under supervision by a human, to filter separate entity, potentially under supervision by a human, to filter
alerts and potentially correlate received alerts with others to alerts and potentially correlate received alerts with others to
obtain a larger picture of the ongoing situation. obtain a larger picture of the ongoing situation.
In any case, for alerts initiated by sensors, the identity could play In any case, for alerts initiated by sensors, the identity could play
an important role in deciding whether to accept or ignore an incoming an important role in deciding whether to accept or ignore an incoming
alert message. With the scenario shown in Figure 1 it is very likely alert message. With the scenario shown in Figure 1 it is very likely
that only authorized sensor input will be processed. For this that only authenticated sensor input will be processed. For this
reason, it needs to be possible to refuse to accept alert messages reason, it needs to be possible to refuse to accept alert messages
from an unknown origin. Two types of information elements can be from an unknown origin. Two types of information elements can be
used for this purpose: used for this purpose:
1. SIP itself provides security mechanisms that allow the 1. SIP itself provides security mechanisms that allow the
verification of the originator's identity. These mechanisms can verification of the originator's identity, such as P-Asserted-
be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity Identity [RFC3325] or SIP Identity [RFC8224]. The latter
[RFC8224]. The latter provides a cryptographic assurance while provides a cryptographic assurance while the former relies on a
the former relies on a chain of trust model. chain of trust model. These mechanisms can be reused.
2. CAP provides additional security mechanisms and the ability to 2. CAP provides additional security mechanisms and the ability to
carry further information about the sender's identity. carry further information about the sender's identity.
Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP
documents. documents.
In addition to the desire to perform identity-based access control, In addition to the desire to perform identity-based access control,
the classic communication security threats need to be considered, the classic communication security threats need to be considered,
including integrity protection to prevent forgery or replay of alert including integrity protection to prevent forgery or replay of alert
messages in transit. To deal with replay of alerts, a CAP document messages in transit. To deal with replay of alerts, a CAP document
contains the mandatory <identifier>, <sender>, <sent> elements and an contains the mandatory <identifier>, <sender>, <sent> elements and an
optional <expire> element. Together, these elements make the CAP optional <expire> element. Together, these elements make the CAP
document unique for a specific sender and provide time restrictions. document unique for a specific sender and provide time restrictions.
An entity that has already received a CAP message within the An entity that has already received a CAP message within the
indicated timeframe is able to detect a replayed message and, if the indicated timeframe is able to detect a replayed message and, if the
content of that message is unchanged, then no additional security content of that message is unchanged, then no additional security
vulnerability is created. Additionally, it is RECOMMENDED to make vulnerability is created. Additionally, it is RECOMMENDED to make
use of SIP security mechanisms, such as SIP Identity [RFC8224], to use of SIP security mechanisms, such as the SIP Identity PASSporT
tie the CAP message to the SIP message. To provide protection of the [RFC8225], to tie the CAP message to the SIP message. To provide
entire SIP message exchange between neighboring SIP entities, the protection of the entire SIP message exchange between neighboring SIP
usage of TLS is REQUIRED. entities, the usage of TLS is REQUIRED.
Note that none of the security mechanism in this document protect Note that none of the security mechanism in this document protect
against a compromised sensor sending crafted alerts. Privacy against a compromised sensor sending crafted alerts. Privacy
provided for any emergency calls, including non-interactive messages, provided for any emergency calls, including non-interactive messages,
is subject to local regulations. is subject to local regulations.
10. IANA Considerations 10. IANA Considerations
10.1. Registration of the 'application/EmergencyCallData.cap+xml' MIME 10.1. Registration of the 'application/EmergencyCallData.cap+xml' MIME
type type
skipping to change at page 18, line 20 skipping to change at page 18, line 20
Additional information: OASIS has published the Common Alerting Additional information: OASIS has published the Common Alerting
Protocol at http://www.oasis-open.org/committees/ Protocol at http://www.oasis-open.org/committees/
documents.php&wg_abbrev=emergency documents.php&wg_abbrev=emergency
Person and email address to contact for further information: Hannes Person and email address to contact for further information: Hannes
Tschofenig, hannes.tschofenig@gmx.net Tschofenig, hannes.tschofenig@gmx.net
Intended usage: Limited use Intended usage: Limited use
Author/Change controller: IETF ECRIT working group Author/Change controller: The IESG
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [RFC7303], and many of the considerations application/xml [RFC7303], and many of the considerations
described there also apply to application/cap+xml. described there also apply to application/cap+xml.
10.2. IANA Registration of 'cap' Additional Data Block 10.2. IANA Registration of 'cap' Additional Data Block
This document registers a new block type in the sub-registry called This document registers a new block type in the sub-registry called
'Emergency Call Data Types' of the Emergency Call Additional Data 'Emergency Call Data Types' of the Emergency Call Additional Data
Registry defined in [RFC7852]. The token is "cap", the Data About is Registry defined in [RFC7852]. The token is "cap", the Data About is
skipping to change at page 19, line 32 skipping to change at page 19, line 32
Header Name compact Reference Header Name compact Reference
----------------- ------- --------- ----------------- ------- ---------
AlertMsg-Error [this doc] AlertMsg-Error [this doc]
2. In the portion titled "Header Field Parameters and Parameter 2. In the portion titled "Header Field Parameters and Parameter
Values", add Values", add
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
----------------- ------------------- ---------- --------- ----------------- ------------------- ---------- ---------
AlertMsg-Error code yes [this doc] AlertMsg-Error code no [this doc]
10.5. IANA Registration for the SIP AlertMsg-Error Codes 10.5. IANA Registration for the SIP AlertMsg-Error Codes
This document creates a new registry for SIP, called "AlertMsg-Error This document creates a new registry for SIP, called "AlertMsg-Error
Codes". AlertMsg-Error codes provide reasons for an error discovered Codes". AlertMsg-Error codes provide reasons for an error discovered
by a recipient, categorized by the action to be taken by the error by a recipient, categorized by the action to be taken by the error
recipient. The initial values for this registry are shown below. recipient. The initial values for this registry are shown below.
Registry Name: AlertMsg-Error Codes Registry Name: AlertMsg-Error Codes
skipping to change at page 21, line 5 skipping to change at page 21, line 5
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<https://www.rfc-editor.org/info/rfc2392>. <https://www.rfc-editor.org/info/rfc2392>.
[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, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002,
<https://www.rfc-editor.org/info/rfc3262>.
[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H.,
Huitema, C., and D. Gurle, "Session Initiation Protocol Huitema, C., and D. Gurle, "Session Initiation Protocol
(SIP) Extension for Instant Messaging", RFC 3428, (SIP) Extension for Instant Messaging", RFC 3428,
DOI 10.17487/RFC3428, December 2002, DOI 10.17487/RFC3428, December 2002,
<https://www.rfc-editor.org/info/rfc3428>. <https://www.rfc-editor.org/info/rfc3428>.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, Format", RFC 4119, DOI 10.17487/RFC4119, December 2005,
<https://www.rfc-editor.org/info/rfc4119>. <https://www.rfc-editor.org/info/rfc4119>.
skipping to change at page 22, line 11 skipping to change at page 22, line 17
[RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed.,
"Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378,
December 2014, <https://www.rfc-editor.org/info/rfc7378>. December 2014, <https://www.rfc-editor.org/info/rfc7378>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224, Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018, DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>. <https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002, DOI 10.17487/RFC3325, November 2002,
<https://www.rfc-editor.org/info/rfc3325>. <https://www.rfc-editor.org/info/rfc3325>.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
<https://www.rfc-editor.org/info/rfc5222>. <https://www.rfc-editor.org/info/rfc5222>.
 End of changes. 21 change blocks. 
28 lines changed or deleted 40 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/