< draft-ietf-ecrit-data-only-ea-11.txt   draft-ietf-ecrit-data-only-ea-12.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: September 2, 2016 Columbia U. Expires: January 19, 2017 Columbia U.
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
R. Gellens R. Gellens
March 1, 2016 July 18, 2016
Data-Only Emergency Calls Data-Only Emergency Calls
draft-ietf-ecrit-data-only-ea-11.txt draft-ietf-ecrit-data-only-ea-12.txt
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 SIP session establishment starting with emergency services involves a SIP session establishment starting with
a SIP INVITE that negotiates various parameters for that session. a SIP INVITE that negotiates various parameters for that session.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 September 2, 2016. This Internet-Draft will expire on January 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4
4. Protocol Specification . . . . . . . . . . . . . . . . . . . 6 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 6
4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 6 4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Profiling of the CAP Document Content . . . . . . . . . . 7 4.2. Profiling of the CAP Document Content . . . . . . . . . . 7
4.3. Sending a Data-Only Emergency Call . . . . . . . . . . . 8 4.3. Sending a Data-Only Emergency Call . . . . . . . . . . . 8
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 8 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. 425 (Bad Alert Message) Response Code . . . . . . . . . . 9 5.1. 425 (Bad Alert Message) Response Code . . . . . . . . . . 9
5.2. The AlertMsg-Error Header Field . . . . . . . . . . . . . 9 5.2. The AlertMsg-Error Header Field . . . . . . . . . . . . . 9
6. Updates to the CAP Message . . . . . . . . . . . . . . . . . 11 6. Call Backs . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Call Backs . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Handling Large Amounts of Data . . . . . . . . . . . . . . . 11
8. Handling Large Amounts of Data . . . . . . . . . . . . . . . 11 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10.1. Registration of the
11.1. Registration of the 'application/emergencyCall.cap+xml' 'application/EmergencyCallData.cap+xml' MIME type . . . 17
MIME type . . . . . . . . . . . . . . . . . . . . . . . 17 10.2. IANA Registration of 'cap' Additional Data Block . . . . 18
11.2. IANA Registration of 'cap' Additional Data Block . . . . 18 10.3. IANA Registration for 425 Response Code . . . . . . . . 18
11.3. IANA Registration for 425 Response Code . . . . . . . . 18 10.4. IANA Registration of New AlertMsg-Error Header Field . . 19
11.4. IANA Registration of New AlertMsg-Error Header Field . . 19 10.5. IANA Registration for the SIP AlertMsg-Error Codes . . . 19
11.5. IANA Registration for the SIP AlertMsg-Error Codes . . . 19 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
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.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
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 [I-D.ietf-ecrit-additional-data]. Accordingly, it is
introduced to the SIP message with a Call-Info header field with a introduced to the SIP message with a Call-Info header field with a
purpose of "emergencyCall.cap". The header field may contain a URI purpose of "EmergencyCallData.cap". The header field may contain a
that is used by the recipient (or in some cases, an intermediary) to URI that is used by the recipient (or in some cases, an intermediary)
obtain the CAP message. Alternative, the Call-Info header field may to obtain the CAP message. Alternative, the Call-Info header field
contain a Content Indirect url [RFC2392] and the CAP message included may contain a Content Indirect url [RFC2392] and the CAP message
in the body of the message. In either case, the CAP message is included in the body of the message. In the latter case, the CAP
located in a MIME block of the type 'application/ message is located in a MIME block of the type 'application/
emergencyCall.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 UAS does not recognize the request method and is not capable when a UAS does not recognize the request method and is not capable
of supporting it for any user. 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 11, line 10 skipping to change at page 11, line 10
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"
Additionally, if an entity cannot or chooses not to process the alert Additionally, if an entity 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. Updates to the CAP Message 6. Call Backs
If the sender anticipates that the content of the CAP message may
need to be updated during the lifecycle of the event referred to in
the message, it may include an update block as defined in
[I-D.rosen-ecrit-addldata-subnot].If the sender includes an update
block and does not have a globally reachable URI, then the UA must
register it's contact with a Registrar, and include a GRUU in in the
update block
7. Call Backs
This document does not describe any method for the recipient to call This document does not describe any method for the recipient to call
back the sender of a data-only call. Usually, these alerts are sent back the sender of a data-only call. Usually, these alerts are sent
by automata, which do not have a mechanism to receive calls of any by automata, which do not have a mechanism to receive calls of any
kind. The identifier in the 'From' header field may be useful to kind. The identifier in the 'From' header field may be useful to
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.
8. 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
[I-D.ietf-ecrit-additional-data], which involves making the data [I-D.ietf-ecrit-additional-data], which involves making the data
available via HTTPS (either at the originator or at another entity), available via HTTPS (either at the originator or at another entity),
placing a URI to the data in the 'Call-Info' header field, and the placing a URI to the data in the 'Call-Info' header field, and the
recipient using HTTPS to retrieve the data. The CAP message itself recipient using HTTPS to retrieve the data. The CAP message itself
can be sent by-reference using this mechanism, as well as any or all can be sent by-reference using this mechanism, as well as any or all
of the Additional Data blocks that may contain sensor-specific data. of the Additional Data blocks that may contain sensor-specific data.
9. Example 8. Example
Figure 3 shows a CAP document indicating a BURGLARY alert issued by a This example shows a CAP document indicating a BURGLARY alert issued
sensor called 'sensor1@domain.com'. The location of the sensor can by a sensor called 'sensor1@domain.com'. The location of the sensor
be obtained from the attached location information provided via the can be obtained from the attached location information provided via
'geolocation' header field contained in the SIP MESSAGE structure. the 'geolocation' header field contained in the SIP MESSAGE
Additionally, the sensor provided some data along with the alert structure. Additionally, the sensor provided some data along with
message, using proprietary information elements intended only to be the alert message, using proprietary information elements intended
processed by the receiver, a SIP entity acting as an aggregator. only to be processed by the receiver, a SIP entity acting as an
This example reflects the description in Figure 1. aggregator.
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
Accept: application/pidf+xml, application/emergencyCall.cap+xml Accept: application/pidf+xml,application/EmergencyCallData.cap+xml
CSeq: 1 MESSAGE CSeq: 1 MESSAGE
Call-Info: cid:abcdef2@domain.com;purpose=emergencyCall.cap Call-Info: cid:abcdef2@domain.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/emergencyCall.cap+xml Content-Type: application/EmergencyCallData.cap+xml
Content-ID: <abcdef2@domain.com> Content-ID: <abcdef2@domain.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"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1"> <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
<identifier>S-1</identifier> <identifier>S-1</identifier>
<sender>sip:sensor1@domain.com</sender> <sender>sip:sensor1@domain.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>
skipping to change at page 13, line 46 skipping to change at page 13, line 35
<gbp:retention-expiry>2010-11-14T20:00:00Z <gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry> </gbp:retention-expiry>
</gp:usage-rules> </gp:usage-rules>
<gp:method>802.11</gp:method> <gp:method>802.11</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp> <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
--boundary1-- --boundary1--
Figure 3: Example Message conveying an Alert to an Aggregator Figure 3: Example Message conveying an Alert to an aggregator
Figure 4 shows the same CAP document sent as a data-only emergency This shows the same CAP document sent as a data-only emergency call
call towards a PSAP. towards a PSAP.
MESSAGE urn:service:sos SIP/2.0 MESSAGE urn:service:sos SIP/2.0
Via: SIP/2.0/TCP sip:aggreg.1.example.com;branch=z9hG4bK776abssa Via: SIP/2.0/TCP sip:aggreg.1.example.com;branch=z9hG4bK776abssa
Max-Forwards: 70 Max-Forwards: 70
From: sip:aggregator@example.com;tag=32336 From: sip:aggregator@example.com;tag=32336
To: 112 To: 112
Call-ID: asdf33443a@example.com Call-ID: asdf33443a@example.com
Route: sip:psap1.example.gov Route: sip:psap1.example.gov
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/emergencyCall.cap+xml Accept: application/pidf+xml,application/EmergencyCallData.cap+xml
Call-info: cid:abcdef2@domain.com;purpose=emergencyCall.cap Call-info: cid:abcdef2@domain.com;purpose=EmergencyCallData.cap
CSeq: 1 MESSAGE CSeq: 1 MESSAGE
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/emergencyCall.cap+xml Content-Type: application/EmergencyCallData.cap+xml
Content-ID: <abcdef2@example.com> Content-ID: <abcdef2@example.com>
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1"> <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
<identifier>S-1</identifier> <identifier>S-1</identifier>
<sender>sip:sensor1@domain.com</sender> <sender>sip:sensor1@domain.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>
skipping to change at page 15, line 40 skipping to change at page 15, line 31
</gp:usage-rules> </gp:usage-rules>
<gp:method>802.11</gp:method> <gp:method>802.11</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp> <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
--boundary1-- --boundary1--
Figure 4: Example Message conveying an Alert to a PSAP Figure 4: Example Message conveying an Alert to a PSAP
10. Security Considerations 9. Security Considerations
This section discusses security considerations when SIP user agents This section discusses security considerations when SIP user agents
issue emergency alerts utilizing MESSAGE and CAP. Location specific issue emergency alerts utilizing MESSAGE and CAP. Location specific
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
skipping to change at page 17, line 5 skipping to change at page 16, line 45
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 [RFC4474], to use of SIP security mechanisms, such as SIP Identity [RFC4474], to
tie the CAP message to the SIP message. To provide protection of the tie the CAP message to the SIP message. To provide protection of the
entire SIP message exchange between neighboring SIP entities, the entire SIP message exchange between neighboring SIP entities, the
usage of TLS is MANDATORY. usage of TLS is MANDATORY.
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. against a compromised sensor sending crafted alerts.
11. IANA Considerations 10. IANA Considerations
10.1. Registration of the 'application/EmergencyCallData.cap+xml' MIME
11.1. Registration of the 'application/emergencyCall.cap+xml' MIME type type
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/ Subject: Registration of MIME media type application/
emergencyCall.cap+xml EmergencyCallData.cap+xml
MIME media type name: application MIME media type name: application
MIME subtype name: cap+xml MIME subtype name: cap+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset; Indicates the character encoding of Optional parameters: charset; Indicates the character encoding of
enclosed XML. Default is UTF-8 [RFC3629]. enclosed XML. Default is UTF-8 [RFC3629].
skipping to change at page 18, line 20 skipping to change at page 18, line 20
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: 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.
11.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
'Additional Data Blocks' defined in [I-D.ietf-ecrit-additional-data]. 'Emergency Call Data Types' of the Emergency Call Additional Data
The token is "cap" and the reference is this document. Registry defined in [I-D.ietf-ecrit-additional-data]. The token is
"cap", the Data About is "The Call" and the reference is this
document.
11.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
Registry: Registry:
Response Code Reference Response Code Reference
------------------------------------------ --------- ------------------------------------------ ---------
Request Failure 4xx Request Failure 4xx
425 Bad Alert Message [this doc] 425 Bad Alert Message [this doc]
This SIP Response code is defined in Section 5. This SIP Response code is defined in Section 5.
11.4. IANA Registration of New AlertMsg-Error Header Field 10.4. IANA Registration of New AlertMsg-Error Header Field
The SIP AlertMsg-error header field is created by this document, with The SIP AlertMsg-error header field is created by this document, with
its definition and rules in Section 5, to be added to the IANA its definition and rules in Section 5, to be added to the IANA
Session Initiation Protocol (SIP) Parameters registry with two Session Initiation Protocol (SIP) Parameters registry with two
actions: actions:
1. Update the Header Fields registry with 1. Update the Header Fields registry with
Registry: Registry:
Header Name compact Reference Header Name compact Reference
skipping to change at page 19, line 27 skipping to change at page 19, line 27
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 yes [this doc]
11.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
Reference: [this doc] Reference: [this doc]
skipping to change at page 20, line 17 skipping to change at page 20, line 17
101 "Alert Payload was not present or could not be found" [this doc] 101 "Alert Payload was not present or could not be found" [this doc]
102 "Not enough information to determine 102 "Not enough information to determine
the purpose of the alert" [this doc] the purpose of the alert" [this doc]
103 "Alert Payload was corrupted" [this doc] 103 "Alert Payload was corrupted" [this doc]
Details of these error codes are in Section 5. Details of these error codes are in Section 5.
12. Acknowledgments 11. Acknowledgments
The authors would like to thank the participants of the Early Warning The authors would like to thank the participants of the Early Warning
adhoc meeting at IETF#69 for their feedback. Additionally, we would adhoc meeting at IETF#69 for their feedback. Additionally, we would
like to thank the members of the NENA Long Term Direction Working like to thank the members of the NENA Long Term Direction Working
Group for their feedback. Group for their feedback.
Additionally, we would like to thank Martin Thomson, James Additionally, we would like to thank Martin Thomson, James
Winterbottom, Shida Schubert, Bernard Aboba, and Marc Linsner for Winterbottom, Shida Schubert, Bernard Aboba, and Marc Linsner for
their review comments. their review comments.
13. References 12. References
13.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[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,
<http://www.rfc-editor.org/info/rfc2392>. <http://www.rfc-editor.org/info/rfc2392>.
skipping to change at page 21, line 37 skipping to change at page 21, line 37
<http://www.rfc-editor.org/info/rfc6442>. <http://www.rfc-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,
<http://www.rfc-editor.org/info/rfc6881>. <http://www.rfc-editor.org/info/rfc6881>.
[I-D.ietf-ecrit-additional-data] [I-D.ietf-ecrit-additional-data]
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-37 (work in Call", draft-ietf-ecrit-additional-data-38 (work in
progress), October 2015. progress), April 2016.
[I-D.rosen-ecrit-addldata-subnot]
Rosen, B., "Updating Additional Data related to an
Emergency Call using Subscribe/ Notify", draft-rosen-
ecrit-addldata-subnot-01 (work in progress), November
2013.
13.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, <http://www.rfc-editor.org/info/rfc7378>. December 2014, <http://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,
<http://www.rfc-editor.org/info/rfc4474>. <http://www.rfc-editor.org/info/rfc4474>.
 End of changes. 30 change blocks. 
80 lines changed or deleted 65 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/