< draft-ietf-ecrit-data-only-ea-02.txt   draft-ietf-ecrit-data-only-ea-03.txt >
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft NeuStar, Inc. Internet-Draft NeuStar, Inc.
Intended status: Experimental H. Schulzrinne Intended status: Experimental H. Schulzrinne
Expires: January 11, 2012 Columbia U. Expires: September 13, 2012 Columbia U.
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
July 10, 2011 March 12, 2012
Common Alerting Protocol (CAP) based Emergency Alerts using the Session Data-Only Emergency Calls
Initiation Protocol (SIP) draft-ietf-ecrit-data-only-ea-03.txt
draft-ietf-ecrit-data-only-ea-02.txt
Abstract Abstract
The Common Alerting Protocol (CAP) is a document format for RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'
exchanging emergency alerts and public warnings. CAP is mainly used describes how devices use the Internet to place emergency calls and
for conveying alerts and warnings between authorities and from how Public Safety Answering Points (PSAPs) can handle Internet
authorities to citizen/individuals. This document describes how multimedia emergency calls natively. The exchange of multimedia
devices use CAP to issue emergency alerts. traffic typically involves a SIP session establishment starting with
a SIP INVITE that negotiates various parameters for that session.
In some cases, however, the transmission of application data is
everything that is needed. Examples of such environments include a
temperature sensors issuing alerts, or vehicles sending crash data.
Often these alerts are conveyed as one-shot data transmissions and in
some rare cases they may require a session to be established. These
type of interactions are called 'data-only emergency calls'.
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 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 January 11, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 5 3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 8
4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 7 4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Profiling of the CAP Document Content . . . . . . . . . . 7 4.2. Profiling of the CAP Document Content . . . . . . . . . . 8
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. 425 (Bad Alert Message) Response Code . . . . . . . . . . 9 5.1. 425 (Bad Alert Message) Response Code . . . . . . . . . . 10
5.2. The AlertMsg-Error Header Field . . . . . . . . . . . . . 9 5.2. The AlertMsg-Error Header Field . . . . . . . . . . . . . 10
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. Registration of the 'application/cap+xml' MIME type . . . 16 8.1. Registration of the 'application/cap+xml' MIME type . . . 17
8.2. IANA Registration for 425 Response Code . . . . . . . . . 17 8.2. IANA Registration for 425 Response Code . . . . . . . . . 18
8.3. IANA Registration of New AlertMsg-Error Header Field . . . 17 8.3. IANA Registration of New AlertMsg-Error Header Field . . . 18
8.4. IANA Registration for the SIP AlertMsg-Error Codes . . . . 18 8.4. IANA Registration for the SIP AlertMsg-Error Codes . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The Common Alerting Protocol (CAP) [cap] is an XML document format RFC 6443 [RFC6443] describes how devices use the Internet to place
for exchanging emergency alerts and public warnings. CAP is mainly emergency calls and how Public Safety Answering Points (PSAPs) can
used for conveying alerts and warnings between authorities and from handle Internet multimedia emergency calls natively. The exchange of
authorities to citizen/individuals. This document describes how multimedia traffic typically involves a SIP session establishment
data-only emergency calls are able to utilize the same CAP document starting with a SIP INVITE that negotiates various parameters for
format. that session.
Emergency alerts containing data are similar to regular emergency In some cases, however, there is only application data to be conveyed
calls in the sense that they require emergency call routing from the end devices to a PSAP or some other intermediary. Examples
functionality and may even have the same location requirements. On of such environments includes sensors issuing alerts, or vehicles
the other hand, the communication interaction may occur without sending crash data. These messages may be one-shot data
establishment of a voice or video channel. transmissions (i.e., SIP message handling that requires no
establishment of a session) and interactions where a sequence of
messages are transmitted in which case a session setup is useful to
ensure that all messages are indeed routed to the same PSAP. These
type of interactions are called 'data-only emergency calls'.
Data-only emergency alerts are similar to regular emergency calls in Data-only emergency calls are nevertheless similar to regular
the sense that they require emergency call routing functionality and emergency calls in the sense that they require the emergency
may even have the same location requirements. On the other hand, the indications, emergency call routing functionality and may even have
initial communication interaction will not lead to the establishment the same location requirements. However, the communication
of a voice or video channel. interaction will not lead to the exchange of Real-Time Protocol
packets, such as voice, video data or real-time text.
Based on the deployment experience with non-IP based systems, two The Common Alerting Protocol (CAP) [cap] is a document format for
major deployment scenarios are envisaged: exchanging emergency alerts and public warnings. CAP is mainly used
for conveying alerts and warnings between authorities and from
authorities to citizen/individuals.
This document uses the CAP payload to convey the semantic of a data-
only emergency call. Note that further data may be added using the
already available 'additional data' structure
[I-D.ietf-ecrit-additional-data]. Whenever data can be encoded in
the additional data structure it shall be used.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Architectural Overview
This section illustrates two envisioned usage modes; targeted and
location-based emergency alert routing.
1. Emergency alerts containing only data are targeted to a recipient 1. Emergency alerts containing only data are targeted to a recipient
responsible for evaluating the next steps, which could include: responsible for evaluating the next steps, which could include:
1. Sending an alert containing only data toward a Public Safety 1. Sending an alert containing only data toward a Public Safety
Answering Point (PSAP); Answering Point (PSAP);
2. Establishing an emergency call with a PSAP that could include 2. Establishing a third-party initiated emergency call that
audio/video as well as data could include audio, video, and data.
2. Emergency alerts targeted to a Service URN used for IP-based 2. Emergency alerts targeted to a Service URN used for IP-based
emergency calls where the recipient is not known to the 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 and a PIDF-LO payload in a SIP MESSAGE) or could be (e.g., a CAP and a PIDF-LO payload in a SIP MESSAGE).
included along with establishment of an audio/video channel (e.g.
SIP INVITE)
We describe these two cases in more detail in Section 3.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document utilizes terminology introduced in
[I-D.ietf-atoca-requirements]. In particular, the terms for author,
originator, receiver and recipient, are relevant for this document.
The originator and the receiver are SIP-based entities while the
author and the recipient are entities that relate to the alert
message delivery, when this is relevant for the communication.
3. Architectural Overview
This section illustrates two envisioned usage modes; targeted and Figure 1 shows a deployment variant where a sensor, is pre-configured
location-based emergency alert routing. Figure 1 shows a deployment (using techniques outside the scope of this document) to issue an
variant where a sensor, as the author and originator of the alert, is alert to an aggregator that processes these messages and performs
pre-configured (using techniques outside the scope of this document) whatever steps are necessary to appropriately react on the alert.
to issue an alert to a receiver or an aggregator, a special form of For example, a security firm may use different sensor inputs to
mediator, that processes these messages and performs whatever steps dispatch their security staff to a building they protect or to
are necessary to appropriately react on the alert. For example, a initiate a third-party emergency call.
security firm may use different sensor inputs to dispatch their
security staff to a building they protect or to initiate a third
party emergency call.
+------------+ +------------+ +------------+ +------------+
| Sensor | | Aggregator | | Sensor | | Aggregator |
| | | | | | | |
+---+--------+ +------+-----+ +---+--------+ +------+-----+
| | | |
Sensors | Sensors |
trigger | trigger |
emergency | emergency |
alert | alert |
skipping to change at page 7, line 9 skipping to change at page 8, line 9
|<-------------------| | |<-------------------| |
| | | | | |
| | | | | |
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
Since alerts structured via CAP require a "push" medium. The To convey CAP payloads the SIP MESSAGE [RFC3428] is used for
following SIP requests MAY carry the CAP payload defined in this exchanges where no session establishment is needed, i.e.., one-shot
document: INVITE [RFC3261], UPDATE [RFC3311], MESSAGE [RFC3428], INFO message exchange, and the SIP INVITE [RFC3261] where the
[RFC6086], NOTIFY [RFC3265], and PUBLISH [RFC3903]. The MIME type is establishment of session is useful (e.g., when multiple independent
set to 'application/cap+xml'. messages have to be logically tied together).
The MIME type is set to 'application/cap+xml'.
If the server does not support the functionality required to fulfill If the server does not support the functionality required to fulfill
the request then a 501 Not Implemented MUST be returned by RFC 3261 the request then a 501 Not Implemented MUST be returned by RFC 3261
[RFC3261]. This is the appropriate response when a UAS does not [RFC3261]. This is the appropriate response when a UAS does not
recognize the request method and is not capable of supporting it for recognize the request method and is not capable of supporting it for
any user. any user.
The 415 Unsupported Media Type error MUST be returned by RFC 3261 The 415 Unsupported Media Type error MUST be returned by RFC 3261
[RFC3261] if the server is refusing to service the request because [RFC3261] if the server is refusing to service the request because
the message body of the request is in a format not supported by the the message body of the request is in a format not supported by the
skipping to change at page 9, line 24 skipping to change at page 10, line 24
425 (Bad Alert Message) 425 (Bad Alert Message)
The 425 response code is a rejection of the request due to its The 425 response code is a rejection of the request due to its
included alert content, indicating that it was malformed or not included alert content, indicating that it was malformed or not
satisfactory for the recipient's purpose. satisfactory for the recipient's purpose.
A SIP intermediary can also reject an alert it receives from a UA A SIP intermediary can also reject an alert it receives from a UA
when it understands that the provided alert is malformed. when it understands that the provided alert is malformed.
Section 5.2 describes a AlertMsg-Error header field with more details Section 5.2 describes an AlertMsg-Error header field with more
about what was wrong with the alert message in the request. This details about what was wrong with the alert message in the request.
header field MUST be included in the 425 response. This header field MUST be included in the 425 response.
It is only appropriate to generate a 425 response when the responding It is only appropriate to generate a 425 response when the responding
entity has no other information in the request that are usable by the entity has no other information in the request that are usable by the
responder. responder.
A 425 response code MUST NOT be sent in response to a request that A 425 response code MUST NOT be sent in response to a request that
lacks an alert message entirely, as the user agent in that case may lacks an alert message entirely, as the user agent in that case may
not support this extension at all. not support this extension at all.
A 425 response is a final response within a transaction, and MUST NOT A 425 response is a final response within a transaction, and MUST NOT
skipping to change at page 10, line 40 skipping to change at page 11, line 40
not standardized - meaning an operator can change the strings - but not 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 as an The AlertMsg-Error header field MAY be included in any response as 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 an MESSAGE to a PSAP. The PSAP example, a UA includes an alert in an MESSAGE to a PSAP. The PSAP
can accept this MESSAGE, thus creating a dialog, even though his UA can accept this MESSAGE, thus creating a dialog, even though his UA
determined the alert message contained in the MESSAGE was bad. The determined the alert message contained in the MESSAGE was bad. The
PSAP merely includes a AlertMsg-Error header value in the 200 OK to PSAP merely includes an AlertMsg-Error header value in the 200 OK to
the MESSAGE informing the UA that the MESSAGE was accepted but the the MESSAGE informing the UA that the MESSAGE was accepted but the
alert provided was bad. alert provided was bad.
If, on the other hand, the PSAP cannot accept the MESSAGE without a If, on the other hand, the PSAP cannot accept the MESSAGE without a
suitable alert message, a 425 response is sent. 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 MESSAGE may also sends a 425 with a AlertMsg- properly process the MESSAGE may also sends a 425 with a AlertMsg-
Error code. Error code.
skipping to change at page 12, line 7 skipping to change at page 13, line 7
purpose of the alert" purpose of the alert"
AlertMsg-Error: 103 ; code="Alert Payload was corrupted" AlertMsg-Error: 103 ; code="Alert Payload was corrupted"
Additionally, if an LR cannot or chooses not to process the alert Additionally, if an LR cannot or chooses not to process the alert
message from a SIP request, a 500 (Server Internal Error) SHOULD be message from a SIP request, a 500 (Server Internal Error) SHOULD be
used with or without a configurable Retry-After header field. used with or without a configurable Retry-After header field.
6. Example 6. Example
Figure 3 shows a CAP document indicating a BURLARY alert issued by a Figure 3 shows a CAP document indicating a BURGLARY alert issued by a
sensor with the identity 'sensor1@domain.com'. The location of the sensor called 'sensor1@domain.com'. The location of the sensor can
sensor can be obtained from the attached location information be obtained from the attached location information provided via the
provided via the 'geolocation' header contained in the SIP MESSAGE 'geolocation' header contained in the SIP MESSAGE structure.
structure. Additionally, the sensor provided some data long with the Additionally, the sensor provided some data long with the alert
alert message using proprietary information elements only to be message using proprietary information elements only to be processed
processed by the receiver, a SIP entity acting as an aggregator. by the receiver, a SIP entity acting as an aggregator. This example
This example reflects the description in Figure 1. reflects the description in Figure 1.
MESSAGE sip:aggregator@domain.com SIP/2.0 MESSAGE sip:aggregator@domain.com SIP/2.0
Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70 Max-Forwards: 70
From: sip:sensor1@domain.com;tag=49583 From: sip:sensor1@domain.com;tag=49583
To: sip:aggregator@domain.com To: sip:aggregator@domain.com
Call-ID: asd88asd77a@1.2.3.4 Call-ID: asd88asd77a@1.2.3.4
Geolocation: <cid:abcdef@domain.com> Geolocation: <cid:abcdef@domain.com>
;routing-allowed=yes ;routing-allowed=yes
Supported: geolocation Supported: geolocation
skipping to change at page 14, line 10 skipping to change at page 15, line 10
</presence> </presence>
--boundary1-- --boundary1--
Figure 3: Example Message conveying an Alert Figure 3: Example Message conveying an Alert
7. Security Considerations 7. Security Considerations
This section discusses security considerations when SIP user agents This section discusses security considerations when SIP user agents
issue emergency alerts utilizing CAP. Location specific threats are issue emergency alerts utilizing CAP. Location specific threats are
not unique to this document and are discussed in not unique to this document and are discussed in
[I-D.ietf-ecrit-trustworthy-location] and [I-D.ietf-ecrit-trustworthy-location] and [RFC6442].
[I-D.ietf-sipcore-location-conveyance].
The ECRIT emergency services architecture [I-D.ietf-ecrit-phonebcp] The ECRIT emergency services architecture [I-D.ietf-ecrit-phonebcp]
considers classical individual-to-authority emergency calling and the considers classical individual-to-authority emergency calling and the
identity of the emergency caller does not play a role at the time of identity of the emergency caller does not play a role at the time of
the call establishment itself, i.e., a response to the emergency call the call establishment itself, i.e., a response to the emergency call
will not depend on the identity of the caller. In case of emergency will not depend on the identity of the caller. In case of emergency
alerts generated by devices, like sensors, the processing may be alerts generated by devices, like 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 may get triggered based on certain sensor
input that may have been caused by other factors than the actual input that may have been caused by other factors than the actual
skipping to change at page 20, line 24 skipping to change at page 21, line 24
[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, January 2001. Types", RFC 3023, January 2001.
[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, November 2003. 10646", STD 63, RFC 3629, November 2003.
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-17 (work in progress), draft-ietf-ecrit-phonebcp-20 (work in progress),
March 2011. September 2011.
[I-D.ietf-sipcore-location-conveyance] [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442,
for the Session Initiation Protocol", December 2011.
draft-ietf-sipcore-location-conveyance-08 (work in
progress), May 2011.
[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,
June 2002. June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002. UPDATE Method", RFC 3311, October 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
skipping to change at page 21, line 9 skipping to change at page 22, line 8
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[I-D.ietf-ecrit-additional-data]
Rosen, B., Tschofenig, H., and R. Marshall, "Additional
Data related to an Emergency Call",
draft-ietf-ecrit-additional-data-02 (work in progress),
October 2011.
10.2. Informative References 10.2. Informative References
[I-D.ietf-atoca-requirements] [I-D.ietf-atoca-requirements]
Schulzrinne, H., Norreys, S., Rosen, B., and H. Rosen, B., Schulzrinne, H., Tschofenig, H., and S.
Tschofenig, "Requirements, Terminology and Framework for Norreys, "Requirements, Terminology and Framework for
Exigent Communications", draft-ietf-atoca-requirements-01 Exigent Communications", draft-ietf-atoca-requirements-02
(work in progress), January 2011. (work in progress), October 2011.
[I-D.ietf-ecrit-trustworthy-location] [I-D.ietf-ecrit-trustworthy-location]
Tschofenig, H., Schulzrinne, H., and B. Aboba, Tschofenig, H., Schulzrinne, H., and B. Aboba,
"Trustworthy Location Information", "Trustworthy Location Information",
draft-ietf-ecrit-trustworthy-location-02 (work in draft-ietf-ecrit-trustworthy-location-02 (work in
progress), May 2011. progress), May 2011.
[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, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[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,
November 2002. November 2002.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, December 2011.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
470 Conrad Dr 470 Conrad Dr
Mars, PA 16046 Mars, PA 16046
US US
Phone: Phone:
Email: br@brianrosen.net Email: br@brianrosen.net
 End of changes. 24 change blocks. 
110 lines changed or deleted 128 lines changed or added

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