draft-ietf-ecrit-data-only-ea-14.txt   draft-ietf-ecrit-data-only-ea-15.txt 
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft NeuStar, Inc. Internet-Draft NeuStar, Inc.
Intended status: Standards Track H. Schulzrinne Intended status: Standards Track H. Schulzrinne
Expires: May 3, 2018 Columbia U. Expires: October 25, 2018 Columbia U.
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
R. Gellens R. Gellens
October 30, 2017 Core Technology Consulting
April 23, 2018
Data-Only Emergency Calls Data-Only Emergency Calls
draft-ietf-ecrit-data-only-ea-14 draft-ietf-ecrit-data-only-ea-15
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. various parameters for that session.
skipping to change at page 1, line 42 skipping to change at page 1, line 43
transaction. transaction.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 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 October 25, 2018.
This Internet-Draft will expire on May 3, 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
(https://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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 16 skipping to change at page 3, line 16
RFC 6443 [RFC6443] describes how devices use the Internet to place RFC 6443 [RFC6443] describes how devices use the Internet to place
emergency calls and how Public Safety Answering Points (PSAPs) handle emergency calls and how Public Safety Answering Points (PSAPs) handle
Internet multimedia emergency calls natively. The exchange of Internet multimedia emergency calls natively. The exchange of
multimedia traffic for emergency services involves a SIP session multimedia traffic for emergency services involves a SIP session
establishment starting with a SIP INVITE that negotiates various establishment starting with a SIP INVITE that negotiates various
parameters for that session. parameters for that session.
In some cases, however, there is only application data to be conveyed In some cases, however, there is only application data to be conveyed
from the end devices to a PSAP or an intermediary. Examples of such from the end devices to a PSAP or an intermediary. Examples of such
environments includes sensors issuing alerts, or vehicles sending environments includes sensors issuing alerts, or certain types of
crash data. These messages may be one-shot alerts to emergency medical monitors. These messages may be one-shot alerts to emergency
authorities and do not require establishment of a session. These authorities and do not require establishment of a session. These
type of interactions are called 'data-only emergency calls'. In this type of interactions are called 'data-only emergency calls'. In this
document, we use the term "call" so that similarities between data- document, we use the term "call" so that similarities between data-
only (non-interactive) alerts and sessions with interactive media are only (non-interactive) alerts and sessions with interactive media are
more obvious. more obvious.
Data-only emergency calls are similar to regular emergency calls in Data-only emergency calls are similar to regular emergency calls in
the sense that they require the emergency indications, emergency call the sense that they require the emergency indications, emergency call
routing functionality and may even have the same location routing functionality and may even have the same location
requirements. However, the communication interaction will not lead requirements. However, the communication interaction will not lead
to the exchange of interactive media, that is, Real-Time Protocol to the exchange of interactive media, that is, Real-Time Protocol
packets, such as voice, video data or real-time text. packets, such as voice, video data or real-time text.
The Common Alerting Protocol (CAP) [cap] is a document format for The Common Alerting Protocol (CAP) [cap] is a format for exchanging
exchanging emergency alerts and public warnings. CAP is mainly used emergency alerts and public warnings. CAP is mainly used for
for conveying alerts and warnings between authorities and from conveying alerts and warnings between authorities and from
authorities to citizen/individuals. This document is concerned with authorities to citizen/individuals. This document is concerned with
citizen to authority "alerts", where the alert is a call without any citizen to authority "alerts", where the alert is a call without any
interactive media. interactive media.
This document describes a method of including a CAP message in a SIP This document describes a method of including a CAP message in a SIP
transaction, either by value (the CAP message is in the body of the transaction by defining it as a block of "additional data" as defined
message, using a CID) or by reference (a URI is included in the in [RFC7852]. The CAP message is included either by value (the CAP
message, which when dereferenced returns the CAP message) by defining message is in the body of the message, using a CID) or by reference
it as a block of "additional data" as defined in (a URI is included in the message, which when dereferenced returns
[I-D.ietf-ecrit-additional-data]. The additional data mechanism is the CAP message). The additional data mechanism is also used to send
also used to send alert specific data beyond that available in the alert specific data beyond that available in the CAP message. This
CAP message. This document also describes how a SIP MESSAGE document also describes how a SIP MESSAGE [RFC3428] transaction can
[RFC3428] transaction can be used to send a data-only call. be used to send a data-only call.
2. Terminology 2. Terminology
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Architectural Overview 3. Architectural Overview
This section illustrates two envisioned usage modes: targeted and This section illustrates two envisioned usage modes: targeted and
skipping to change at page 4, line 24 skipping to change at page 4, line 24
1. Sending a non-interactive call containing only data toward a 1. Sending a non-interactive call containing only data toward a
Public Safety Answering Point (PSAP); Public Safety Answering Point (PSAP);
2. Establishing a third-party initiated emergency call towards a 2. Establishing a third-party initiated emergency call towards a
PSAP that could include audio, video, and data. PSAP that could include audio, video, and data.
2. Emergency alerts may be targeted to a Service URN used for IP- 2. Emergency alerts may be targeted to a Service URN used for IP-
based emergency calls where the recipient is not known to the based emergency calls where the recipient is not known to the
originator. In this scenario, the alert may contain only data originator. In this scenario, the alert may contain only data
(e.g., a CAP, Geolocation header field and one or more Call-Info (e.g., a CAP, Geolocation header field and one or more Call-Info
header fields containing Additional Data header fields containing Additional Data [RFC7852] in a SIP
[I-D.ietf-ecrit-additional-data] in a SIP MESSAGE). MESSAGE).
Figure 1 shows a deployment variant where a sensor is pre-configured Figure 1 shows a deployment variant where a sensor is pre-configured
(using techniques outside the scope of this document) to issue an (using techniques outside the scope of this document) to issue an
alert to an aggregator that processes these messages and performs alert to an aggregator that processes these messages and performs
whatever steps are necessary to appropriately react to the alert. whatever steps are necessary to appropriately react to the alert.
For example, a security firm may use different sensor inputs to For example, a security firm may use different sensor inputs to
dispatch their security staff to a building they protect or to dispatch their security staff to a building they protect or to
initiate a third-party emergency call. initiate a third-party emergency call.
+------------+ +------------+ +------------+ +------------+
skipping to change at page 5, line 41 skipping to change at page 5, line 41
route the alert message to. A possible receiver is a PSAP and the route the alert message to. A possible receiver is a PSAP and the
recipient of the alert may be a call taker. In the generic case, recipient of the alert may be a call taker. In the generic case,
there is very likely no prior relationship between the originator and there is very likely no prior relationship between the originator and
the receiver, e.g., a PSAP. A PSAP, for example, is likely to the receiver, e.g., a PSAP. A PSAP, for example, is likely to
receive and accept alerts from entities it cannot authorize. This receive and accept alerts from entities it cannot authorize. This
scenario corresponds to the classic emergency services use case and scenario corresponds to the classic emergency services use case and
the description in [RFC6881] is applicable. In this use case, the the description in [RFC6881] is applicable. In this use case, the
only difference between an emergency call and an emergency data-only only difference between an emergency call and an emergency data-only
call is that the former uses INVITE, creates a session, and call is that the former uses INVITE, creates a session, and
negotiates one or more media streams, while the latter uses MESSAGE, negotiates one or more media streams, while the latter uses MESSAGE,
does not create a session, and does not have media. does not create a session, and does not have interactive media.
+-----------+ +----------+ +----------+ +----------+ +-----------+
+--------+ | ESRP | | PSAP | |Sensor or | | ESRP | | PSAP |
| Sensor | | | | | |Aggregator| | | | |
+---+----+ +---+-------+ +---+------+ +----+-----+ +---+------+ +----+------+
| | | | | |
Sensors | | Sensors | |
trigger | | trigger | |
emergency | | emergency | |
alert | | alert | |
| | | | | |
| | | | | |
| MESSAGE with CAP | | | MESSAGE with CAP | |
| (including Service URN, | | (including Service URN, |
| such as urn:service:sos) | | such as urn:service:sos) |
|------------------->| | |-------------------| |
| | | | | |
| ESRP performs | | ESRP performs |
| emergency alert | | emergency alert |
| routing | | routing |
| | MESSAGE with CAP | | | MESSAGE with CAP |
| | (including identity info) | | | (including identity info) |
| |----------------------------->| | |----------------------------->|
| | | | | |
| | PSAP | | PSAP
| | processes | | processes
| | emergency | | emergency
| | alert | | alert
| | 200 (OK) | | | 200 (OK) |
| |<-----------------------------| | |<-----------------------------|
| | | | | |
| 200 (OK) | | | 200 (OK) | |
|<-------------------| | |<------------------| |
| | | | | |
| | | | | |
Figure 2: Location-Based Emergency Alert Routing Figure 2: Location-Based Emergency Alert Routing
4. Protocol Specification 4. Protocol Specification
4.1. CAP Transport 4.1. CAP Transport
A CAP message may be sent in the initial message of any SIP A CAP message may be sent in the initial message of any SIP
transaction. However, this document only addresses sending a CAP transaction. However, this document only addresses sending a CAP
message in a SIP INVITE that initiates an emergency call, or in a SIP message in a SIP INVITE that initiates an emergency call, or in a SIP
MESSAGE transaction for a one-shot, data-only emergency call. MESSAGE transaction for a one-shot, data-only emergency call.
Behavior with other transactions is not defined. Behavior with other transactions is not defined.
The CAP message is included in a SIP message as an additional-data The CAP message is included in a SIP message as an additional-data
block [I-D.ietf-ecrit-additional-data]. Accordingly, it is block [RFC7852]. Accordingly, it is introduced to the SIP message
introduced to the SIP message with a Call-Info header field with a with a Call-Info header field with a purpose of
purpose of "EmergencyCallData.cap". The header field may contain a "EmergencyCallData.cap". The header field may contain a URI that is
URI that is used by the recipient (or in some cases, an intermediary) used by the recipient (or in some cases, an intermediary) to obtain
to obtain the CAP message. Alternative, the Call-Info header field the CAP message. Alternative, the Call-Info header field may contain
may contain a Content Indirect url [RFC2392] and the CAP message a Content Indirect url [RFC2392] and the CAP message included in the
included in the body of the message. In the latter case, the CAP body of the message. In the latter case, the CAP message is located
message is located in a MIME block of the type 'application/ in a MIME block of the type 'application/emergencyCallData.cap+xml'.
emergencyCallData.cap+xml'.
If the SIP server does not support the functionality required to If the SIP server does not support the functionality required to
fulfill the request then a 501 Not Implemented MUST be returned as fulfill the request then a 501 Not Implemented MUST be returned as
specified in RFC 3261 [RFC3261]. This is the appropriate response specified in RFC 3261 [RFC3261]. This is the appropriate response
when a User Agent Server (UAS) does not recognize the request method when a User Agent Server (UAS) does not recognize the request method
and is not capable of supporting it for any user. and is not capable of supporting it for any user.
The 415 Unsupported Media Type error MUST be returned as specified in The 415 Unsupported Media Type error MUST be returned as specified in
RFC 3261 [RFC3261] if the SIP server is refusing to service the RFC 3261 [RFC3261] if the SIP server is refusing to service the
request because the message body of the request is in a format not request because the message body of the request is in a format not
skipping to change at page 8, line 29 skipping to change at page 8, line 29
information is already available in other SIP header fields. information is already available in other SIP header fields.
Populating information twice into different parts of the message Populating information twice into different parts of the message
may lead to inconsistency. may lead to inconsistency.
parameter: The <parameter> element MAY contain additional parameter: The <parameter> element MAY contain additional
information specific to the sender. information specific to the sender.
area: It is RECOMMENDED to omit this element when constructing a area: It is RECOMMENDED to omit this element when constructing a
message. If the CAP message already contains an <area> element, message. If the CAP message already contains an <area> element,
then the specified location information SHOULD be copied into the then the specified location information SHOULD be copied into the
PIDF-LO structure of the 'geolocation' header field. PIDF-LO structure referenced by the 'geolocation' header field.
4.3. Sending a Data-Only Emergency Call 4.3. Sending a Data-Only Emergency Call
A data-only emergency call is sent using a SIP MESSAGE transaction A data-only emergency call is sent using a SIP MESSAGE transaction
with a CAP URI or body as described above in a manner similar to how with a CAP URI or body part as described above in a manner similar to
an emergency call with interactive media is sent, as described in how an emergency call with interactive media is sent, as described in
[RFC6881]. The MESSAGE transaction does not create a session nor [RFC6881]. The MESSAGE transaction does not create a session nor
send media, but otherwise, the header content of the transaction, establish interactive media streams, but otherwise, the header
routing, and processing of data-only calls are the same as those of content of the transaction, routing, and processing of data-only
other emergency calls. calls are the same as those of other emergency calls.
5. Error Handling 5. Error Handling
This section defines a new error response code and a header field for This section defines a new error response code and a header field for
additional information. additional information.
5.1. 425 (Bad Alert Message) Response Code 5.1. 425 (Bad Alert Message) Response Code
This SIP extension creates a new location-specific response code, This SIP extension creates a new location-specific response code,
defined as follows: defined as follows:
skipping to change at page 11, line 26 skipping to change at page 11, line 26
obtain more information, but any such mechanism is not defined in obtain more information, but any such mechanism is not defined in
this document. The CAP message may contain related contact this document. The CAP message may contain related contact
information for the sender. information for the sender.
7. Handling Large Amounts of Data 7. Handling Large Amounts of Data
It is not atypical for sensors to have large quantities of data that It is not atypical for sensors to have large quantities of data that
they may wish to send. Including large amounts of data in a MESSAGE they may wish to send. Including large amounts of data in a MESSAGE
is not advisable, because SIP entities are usually not equipped to is not advisable, because SIP entities are usually not equipped to
handle very large messages. In such cases, the sender SHOULD make handle very large messages. In such cases, the sender SHOULD make
use of the by-reference mechanisms defined in use of the by-reference mechanisms defined in [RFC7852], which
[I-D.ietf-ecrit-additional-data], which involves making the data involves making the data available via HTTPS (either at the
available via HTTPS (either at the originator or at another entity), originator or at another entity), placing a URI to the data in the
placing a URI to the data in the 'Call-Info' header field, and the 'Call-Info' header field, and the recipient using HTTPS to retrieve
recipient using HTTPS to retrieve the data. The CAP message itself the data. The CAP message itself can be sent by-reference using this
can be sent by-reference using this mechanism, as well as any or all mechanism, as well as any or all of the Additional Data blocks that
of the Additional Data blocks that may contain sensor-specific data. may contain sensor-specific data.
8. Example 8. Example
The following example shows a CAP document indicating a BURGLARY The following example shows a CAP document indicating a BURGLARY
alert issued by a sensor called 'sensor1@domain.com'. The location alert issued by a sensor called 'sensor1@domain.com'. The location
of the sensor can be obtained from the attached location information of the sensor can be obtained from the attached location information
provided via the 'geolocation' header field contained in the SIP provided via the 'geolocation' header field contained in the SIP
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
skipping to change at page 15, line 45 skipping to change at page 15, line 45
threats are not unique to this document and are discussed in threats are not unique to this document and are discussed in
[RFC7378] and [RFC6442]. [RFC7378] and [RFC6442].
The ECRIT emergency services architecture [RFC6443] considers classic The ECRIT emergency services architecture [RFC6443] considers classic
individual-to-authority emergency calling where the identity of the individual-to-authority emergency calling where the identity of the
emergency caller does not play a role at the time of the call emergency caller does not play a role at the time of the call
establishment itself, i.e., a response to the emergency call does not establishment itself, i.e., a response to the emergency call does not
depend on the identity of the caller. In the case of emergency depend on the identity of the caller. In the case of emergency
alerts generated by devices such as sensors, the processing may be alerts generated by devices such as sensors, the processing may be
different in order to reduce the number of falsely generated different in order to reduce the number of falsely generated
emergency alerts. Alerts may get triggered based on certain sensor emergency alerts. Alerts could get triggered based on certain sensor
input that may have been caused by factors other than the actual input that might have been caused by factors other than the actual
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 may 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 authorized 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. These mechanisms can
be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity
skipping to change at page 18, line 24 skipping to change at page 18, line 24
Author/Change controller: IETF ECRIT working group Author/Change controller: IETF ECRIT working group
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml RFC 3023 [RFC3023], and many of the considerations application/xml RFC 3023 [RFC3023], 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 [I-D.ietf-ecrit-additional-data]. The token is Registry defined in [RFC7852]. The token is "cap", the Data About is
"cap", the Data About is "The Call" and the reference is this "The Call" and the reference is this document.
document.
10.3. IANA Registration for 425 Response Code 10.3. IANA Registration for 425 Response Code
In the SIP Response Codes registry, the following is added In the SIP Response Codes registry, the following is added
Reference: RFC-XXXX (i.e., this document) Reference: RFC-XXXX (i.e., this document)
Response code: 425 (recommended number to assign) Response code: 425 (recommended number to assign)
Default reason phrase: Bad Alert Message Default reason phrase: Bad Alert Message
skipping to change at page 20, line 45 skipping to change at page 20, line 45
[cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v.
1.1", October 2005. 1.1", October 2005.
[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-
<https://www.rfc-editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[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-
<https://www.rfc-editor.org/info/rfc3428>. editor.org/info/rfc3428>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5234>. editor.org/info/rfc5234>.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, DOI 10.17487/RFC3023, January 2001, Types", RFC 3023, DOI 10.17487/RFC3023, January 2001,
<https://www.rfc-editor.org/info/rfc3023>. <https://www.rfc-editor.org/info/rfc3023>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", RFC 6442, for the Session Initiation Protocol", RFC 6442,
DOI 10.17487/RFC6442, December 2011, DOI 10.17487/RFC6442, December 2011, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6442>. editor.org/info/rfc6442>.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling", Communications Services in Support of Emergency Calling",
BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
<https://www.rfc-editor.org/info/rfc6881>. <https://www.rfc-editor.org/info/rfc6881>.
[I-D.ietf-ecrit-additional-data] [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
J. Winterbottom, "Additional Data Related to an Emergency J. Winterbottom, "Additional Data Related to an Emergency
Call", draft-ietf-ecrit-additional-data-38 (work in Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
progress), April 2016. <https://www.rfc-editor.org/info/rfc7852>.
12.2. Informative References 12.2. Informative References
[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>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006, DOI 10.17487/RFC4474, August 2006, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4474>. editor.org/info/rfc4474>.
[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-
<https://www.rfc-editor.org/info/rfc3325>. editor.org/info/rfc3325>.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet "Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, DOI 10.17487/RFC6443, December Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
2011, <https://www.rfc-editor.org/info/rfc6443>. 2011, <https://www.rfc-editor.org/info/rfc6443>.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
skipping to change at page 22, line 45 skipping to change at page 22, line 45
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Hannes Tschofenig Hannes Tschofenig
ARM Limited ARM Limited
Austria Austria
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Randall Gellens Randall Gellens
Core Technology Consulting
Email: rg+ietf@randy.pensive.org Email: rg+ietf@coretechnologyconsulting.com
URI: http://www.coretechnologyconsulting.com
 End of changes. 31 change blocks. 
103 lines changed or deleted 101 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/