idnits 2.17.1 draft-ietf-ecrit-data-only-ea-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 9, 2012) is 4186 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) == Outdated reference: A later version (-38) exists of draft-ietf-ecrit-additional-data-05 == Outdated reference: A later version (-14) exists of draft-ietf-ecrit-trustworthy-location-04 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft NeuStar, Inc. 4 Intended status: Experimental H. Schulzrinne 5 Expires: May 13, 2013 Columbia U. 6 H. Tschofenig 7 Nokia Siemens Networks 8 November 9, 2012 10 Data-Only Emergency Calls 11 draft-ietf-ecrit-data-only-ea-04.txt 13 Abstract 15 RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' 16 describes how devices use the Internet to place emergency calls and 17 how Public Safety Answering Points (PSAPs) can handle Internet 18 multimedia emergency calls natively. The exchange of multimedia 19 traffic typically involves a SIP session establishment starting with 20 a SIP INVITE that negotiates various parameters for that session. 22 In some cases, however, the transmission of application data is 23 everything that is needed. Examples of such environments include a 24 temperature sensors issuing alerts, or vehicles sending crash data. 25 Often these alerts are conveyed as one-shot data transmissions and in 26 some rare cases they may require a session to be established. These 27 type of interactions are called 'data-only emergency calls'. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 13, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 5 66 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 8 67 4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2. Profiling of the CAP Document Content . . . . . . . . . . 8 69 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.1. 425 (Bad Alert Message) Response Code . . . . . . . . . . 10 71 5.2. The AlertMsg-Error Header Field . . . . . . . . . . . . . 10 72 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 8.1. Registration of the 'application/cap+xml' MIME type . . . 17 76 8.2. IANA Registration for 425 Response Code . . . . . . . . . 18 77 8.3. IANA Registration of New AlertMsg-Error Header Field . . . 18 78 8.4. IANA Registration for the SIP AlertMsg-Error Codes . . . . 19 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 85 1. Introduction 87 RFC 6443 [RFC6443] describes how devices use the Internet to place 88 emergency calls and how Public Safety Answering Points (PSAPs) can 89 handle Internet multimedia emergency calls natively. The exchange of 90 multimedia traffic typically involves a SIP session establishment 91 starting with a SIP INVITE that negotiates various parameters for 92 that session. 94 In some cases, however, there is only application data to be conveyed 95 from the end devices to a PSAP or some other intermediary. Examples 96 of such environments includes sensors issuing alerts, or vehicles 97 sending crash data. These messages may be one-shot data 98 transmissions (i.e., SIP message handling that requires no 99 establishment of a session) and interactions where a sequence of 100 messages are transmitted in which case a session setup is useful to 101 ensure that all messages are indeed routed to the same PSAP. These 102 type of interactions are called 'data-only emergency calls'. 104 Data-only emergency calls are nevertheless similar to regular 105 emergency calls in the sense that they require the emergency 106 indications, emergency call routing functionality and may even have 107 the same location requirements. However, the communication 108 interaction will not lead to the exchange of Real-Time Protocol 109 packets, such as voice, video data or real-time text. 111 The Common Alerting Protocol (CAP) [cap] is a document format for 112 exchanging emergency alerts and public warnings. CAP is mainly used 113 for conveying alerts and warnings between authorities and from 114 authorities to citizen/individuals. 116 This document uses the CAP payload to convey the semantic of a data- 117 only emergency call. Note that further data may be added using the 118 already available 'additional data' structure 119 [I-D.ietf-ecrit-additional-data]. Whenever data can be encoded in 120 the additional data structure it shall be used. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 3. Architectural Overview 130 This section illustrates two envisioned usage modes; targeted and 131 location-based emergency alert routing. 133 1. Emergency alerts containing only data are targeted to a recipient 134 responsible for evaluating the next steps, which could include: 136 1. Sending an alert containing only data toward a Public Safety 137 Answering Point (PSAP); 139 2. Establishing a third-party initiated emergency call that 140 could include audio, video, and data. 142 2. Emergency alerts targeted to a Service URN used for IP-based 143 emergency calls where the recipient is not known to the 144 originator. In this scenario, the alert may contain only data 145 (e.g., a CAP and a PIDF-LO payload in a SIP MESSAGE). 147 Figure 1 shows a deployment variant where a sensor, is pre-configured 148 (using techniques outside the scope of this document) to issue an 149 alert to an aggregator that processes these messages and performs 150 whatever steps are necessary to appropriately react on the alert. 151 For example, a security firm may use different sensor inputs to 152 dispatch their security staff to a building they protect or to 153 initiate a third-party emergency call. 155 +------------+ +------------+ 156 | Sensor | | Aggregator | 157 | | | | 158 +---+--------+ +------+-----+ 159 | | 160 Sensors | 161 trigger | 162 emergency | 163 alert | 164 | MESSAGE with CAP | 165 |----------------------------->| 166 | | 167 | Aggregator 168 | processes 169 | emergency 170 | alert 171 | 200 (OK) | 172 |<-----------------------------| 173 | | 174 | | 176 Figure 1: Targeted Emergency Alert Routing 178 In Figure 2 a scenario is shown whereby the alert is routed using 179 location information and the Service URN. An emergency services 180 routing proxy (ESRP) may use LoST to determine the next hop proxy to 181 route the alert message to. A possible receiver is a PSAP and the 182 recipient of the alert may be call taker. In the generic case, there 183 is very likely no prior relationship between the originator and the 184 receiver, e.g. PSAP. A PSAP, for example, is likely to receive and 185 accept alerts from entities it cannot authorize. This scenario 186 corresponds more to the classical emergency services use case and the 187 description in [I-D.ietf-ecrit-phonebcp] is applicable. 189 +-----------+ +----------+ 190 +--------+ | ESRP | | PSAP | 191 | Sensor | | | | | 192 +---+----+ +---+-------+ +---+------+ 193 | | | 194 Sensors | | 195 trigger | | 196 emergency | | 197 alert | | 198 | | | 199 | | | 200 | MESSAGE with CAP | | 201 | (including Service URN, | 202 | such as urn:service:sos) | 203 |------------------->| | 204 | | | 205 | ESRP performs | 206 | emergency alert | 207 | routing | 208 | | MESSAGE with CAP | 209 | | (including identity info) | 210 | |----------------------------->| 211 | | | 212 | | PSAP 213 | | processes 214 | | emergency 215 | | alert 216 | | 200 (OK) | 217 | |<-----------------------------| 218 | | | 219 | 200 (OK) | | 220 |<-------------------| | 221 | | | 222 | | | 224 Figure 2: Location-Based Emergency Alert Routing 226 4. Protocol Specification 228 4.1. CAP Transport 230 To convey CAP payloads the SIP MESSAGE [RFC3428] is used for 231 exchanges where no session establishment is needed, i.e.., one-shot 232 message exchange, and the SIP INVITE [RFC3261] where the 233 establishment of session is useful (e.g., when multiple independent 234 messages have to be logically tied together). 236 The MIME type is set to 'application/cap+xml'. 238 If the server does not support the functionality required to fulfill 239 the request then a 501 Not Implemented MUST be returned by RFC 3261 240 [RFC3261]. This is the appropriate response when a UAS does not 241 recognize the request method and is not capable of supporting it for 242 any user. 244 The 415 Unsupported Media Type error MUST be returned by RFC 3261 245 [RFC3261] if the server is refusing to service the request because 246 the message body of the request is in a format not supported by the 247 server for the requested method. The server MUST return a list of 248 acceptable formats using the Accept, Accept-Encoding, or Accept- 249 Language header field, depending on the specific problem with the 250 content. 252 4.2. Profiling of the CAP Document Content 254 The usage of CAP MUST conform to the specification provided with 255 [cap]. For the usage with SIP the following additional requirements 256 are imposed: 258 sender: A few sub-categories for putting a value in the 259 element have to be considered: 261 Originator is a SIP entity, Author indication irrelevant: When 262 the alert was created by a SIP-based originator and it is not 263 useful to be explicit about the author of the alert then the 264 element MUST be populated with the SIP URI of the user 265 agent. 267 Originator is a non-SIP entity, Author indication irrelevant: In 268 case that the alert was created by a non-SIP based entity and 269 the identity of this original sender wants to be preserved then 270 this identity MUST be placed into the element. In 271 this category the it is not useful to be explicit about the 272 author of the alert. The specific type of identity being used 273 will depends on the technology being used by the original 274 originator. 276 Author indication relevant: In case the author is different from 277 the actual originator of the message and this distinction wants 278 to be preserved then the element MUST NOT contain the 279 SIP URI. 281 incidents: The element MUST be present whenever there is 282 a possibility that alert information needs to be updated. The 283 initial message will then contain an incident identifier carried 284 in the element. This incident identifier MUST be 285 chosen in such a way that it is unique for a given combination. Note that the element 287 is optional and may not be present. 289 scope: The value of the element MUST be set to "Private" as 290 the alert is not meant for public consumption. The 291 element is, however, not used by this specification since the 292 message routing is performed by SIP and the respective address 293 information is already available in other SIP headers. Populating 294 information twice into different parts of the message may lead to 295 inconsistency. 297 parameter: The element MAY contain additional 298 information specific to the sensor. 300 area: It is RECOMMENDED to omit this element when constructing a 301 message. In case that the CAP message already contained an 302 element then the specified location information MUST be copied 303 into the PIDF-LO structure of the 'geolocation' header. 305 5. Error Handling 307 This section defines a new error response code and a header field for 308 additional information. 310 5.1. 425 (Bad Alert Message) Response Code 312 This SIP extension creates a new location-specific response code, 313 defined as follows, 315 425 (Bad Alert Message) 317 The 425 response code is a rejection of the request due to its 318 included alert content, indicating that it was malformed or not 319 satisfactory for the recipient's purpose. 321 A SIP intermediary can also reject an alert it receives from a UA 322 when it understands that the provided alert is malformed. 324 Section 5.2 describes an AlertMsg-Error header field with more 325 details about what was wrong with the alert message in the request. 326 This header field MUST be included in the 425 response. 328 It is only appropriate to generate a 425 response when the responding 329 entity has no other information in the request that are usable by the 330 responder. 332 A 425 response code MUST NOT be sent in response to a request that 333 lacks an alert message entirely, as the user agent in that case may 334 not support this extension at all. 336 A 425 response is a final response within a transaction, and MUST NOT 337 terminate an existing dialog. 339 5.2. The AlertMsg-Error Header Field 341 The AlertMsg-Error header provides additional information about what 342 was wrong with the original request. In some cases the provided 343 information will be used for debugging purposes. 345 The AlertMsg-Error header field has the following ABNF [RFC5234]: 347 message-header /= AlertMsg-Error 348 ; (message-header from 3261) 349 AlertMsg-Error = "AlertMsg-Error" HCOLON 350 ErrorValue 351 ErrorValue = error-code 352 *(SEMI error-params) 353 error-code = 1*3DIGIT 354 error-params = error-code-text 355 / generic-param ; from RFC3261 356 error-code-text = "code" EQUAL quoted-string ; from RFC3261 358 HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is 359 defined in RFC5234 [RFC5234]. 361 The AlertMsg-Error header field MUST contain only one ErrorValue to 362 indicate what was wrong with the alert payload the recipient 363 determined was bad. 365 The ErrorValue contains a 3-digit error code indicating what was 366 wrong with the alert in the request. This error code has a 367 corresponding quoted error text string that is human understandable. 368 The text string are OPTIONAL, but RECOMMENDED for human readability, 369 similar to the string phrase used for SIP response codes. That said, 370 the strings are complete enough for rendering to the user, if so 371 desired. The strings in this document are recommendations, and are 372 not standardized - meaning an operator can change the strings - but 373 MUST NOT change the meaning of the error code. Similar to how RFC 374 3261 specifies, there MUST NOT be more than one string per error 375 code. 377 The AlertMsg-Error header field MAY be included in any response as an 378 alert message was in the request part of the same transaction. For 379 example, a UA includes an alert in an MESSAGE to a PSAP. The PSAP 380 can accept this MESSAGE, thus creating a dialog, even though his UA 381 determined the alert message contained in the MESSAGE was bad. The 382 PSAP merely includes an AlertMsg-Error header value in the 200 OK to 383 the MESSAGE informing the UA that the MESSAGE was accepted but the 384 alert provided was bad. 386 If, on the other hand, the PSAP cannot accept the MESSAGE without a 387 suitable alert message, a 425 response is sent. 389 A SIP intermediary that requires the UA's alert message in order to 390 properly process the MESSAGE may also sends a 425 with a AlertMsg- 391 Error code. 393 This document defines an initial list of error code ranges for any 394 SIP response, including provisional responses (other than 100 Trying) 395 and the new 425 response. There MUST be no more than one AlertMsg- 396 Error code in a SIP response. 398 AlertMsg-Error: 100 ; code="Cannot Process the Alert Payload" 400 AlertMsg-Error: 101 ; code="Alert Payload was not present or could 401 not be found" 403 AlertMsg-Error: 102 ; code="Not enough information to determine the 404 purpose of the alert" 406 AlertMsg-Error: 103 ; code="Alert Payload was corrupted" 408 Additionally, if an LR cannot or chooses not to process the alert 409 message from a SIP request, a 500 (Server Internal Error) SHOULD be 410 used with or without a configurable Retry-After header field. 412 6. Example 414 Figure 3 shows a CAP document indicating a BURGLARY alert issued by a 415 sensor called 'sensor1@domain.com'. The location of the sensor can 416 be obtained from the attached location information provided via the 417 'geolocation' header contained in the SIP MESSAGE structure. 418 Additionally, the sensor provided some data long with the alert 419 message using proprietary information elements only to be processed 420 by the receiver, a SIP entity acting as an aggregator. This example 421 reflects the description in Figure 1. 423 MESSAGE sip:aggregator@domain.com SIP/2.0 424 Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse 425 Max-Forwards: 70 426 From: sip:sensor1@domain.com;tag=49583 427 To: sip:aggregator@domain.com 428 Call-ID: asd88asd77a@1.2.3.4 429 Geolocation: 430 ;routing-allowed=yes 431 Supported: geolocation 432 Accept: application/pidf+xml, application/cap+xml 433 CSeq: 1 MESSAGE 434 Content-Type: multipart/mixed; boundary=boundary1 435 Content-Length: ... 437 --boundary1 439 Content-Type: cap+xml 440 Content-ID: 441 443 444 S-1 445 sip:sensor1@domain.com 446 2008-11-19T14:57:00-07:00 447 Actual 448 Alert 449 Private 450 abc1234 451 452 Security 453 BURGLARY 454 Expected 455 Likely 456 Moderate 457 SENSOR 1 458 459 SENSOR-DATA-NAMESPACE1 460 123 461 462 463 SENSOR-DATA-NAMESPACE2 464 TRUE 465 466 467 469 --boundary1 471 Content-Type: application/pidf+xml 472 Content-ID: 473 474 482 483 484 485 486 487 32.86726 -97.16054 488 489 490 491 492 false 493 494 2010-11-14T20:00:00Z 495 496 497 802.11 498 499 2010-11-04T20:57:29Z 500 501 502 --boundary1-- 504 Figure 3: Example Message conveying an Alert 506 7. Security Considerations 508 This section discusses security considerations when SIP user agents 509 issue emergency alerts utilizing CAP. Location specific threats are 510 not unique to this document and are discussed in 511 [I-D.ietf-ecrit-trustworthy-location] and [RFC6442]. 513 The ECRIT emergency services architecture [I-D.ietf-ecrit-phonebcp] 514 considers classical individual-to-authority emergency calling and the 515 identity of the emergency caller does not play a role at the time of 516 the call establishment itself, i.e., a response to the emergency call 517 will not depend on the identity of the caller. In case of emergency 518 alerts generated by devices, like sensors, the processing may be 519 different in order to reduce the number of falsely generated 520 emergency alerts. Alerts may get triggered based on certain sensor 521 input that may have been caused by other factors than the actual 522 occurrence of an alert relevant event. For example, a sensor may 523 simply be malfunctioning. For this purpose not all alert messages 524 are directly sent to a PSAP but are rather pre-processed by a 525 separate entity, potentially under supervision by a human, to filter 526 alerts and potentially correlate received alerts with others to 527 obtain a larger picture of the ongoing situation. These two message 528 routing examples are shown in Figure 1 and in Figure 2. 530 In any case, for alerts that are initiated by sensors the identity 531 may play an important role in deciding whether to accept or ignore an 532 incoming alert message. With the scenario shown in Figure 1 it is 533 very likely that only authorized sensor input will be processed. For 534 this purpose it needs to be ensured that no alert messages from an 535 unknown origin are accepted. Two types of information elements can 536 be used for this purpose: 538 1. SIP itself provides security mechanisms that allow the 539 verification of the originator's identity. These mechanisms can 540 be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity 541 [RFC4474]. The latter provides a cryptographic assurance while 542 the former relies on a chain of trust model. 544 2. CAP provides additional security mechanisms and the ability to 545 carry additional information about the sender's identity. 546 Section 3.3.2.1 of [cap] specifies the signing algorithms of CAP 547 documents. 549 In addition to the desire to perform identity-based access control 550 the classical communication security threats need to be considered, 551 including integrity protection to prevent forgery and replay of alert 552 messages in transit. To deal with replay of alerts a CAP document 553 contains the mandatory , , elements and an 554 optional element. These attributes make the CAP document 555 unique for a specific sender and provide time restrictions. An 556 entity that has received a CAP message already within the indicated 557 timeframe is able to detect a replayed message and, if the content of 558 that message is unchanged, then no additional security vulnerability 559 is created. Additionally, it is RECOMMENDED to make use of SIP 560 security mechanisms, such as SIP Identity [RFC4474], to tie the CAP 561 message to the SIP message. To provide protection of the entire SIP 562 message exchange between neighboring SIP entities the usage of TLS is 563 mandatory. 565 Note that none of the security mechanism in this document protect 566 against a compromised sensor sending crafted alerts. 568 8. IANA Considerations 570 8.1. Registration of the 'application/cap+xml' MIME type 572 To: ietf-types@iana.org 574 Subject: Registration of MIME media type application/ cap+xml 576 MIME media type name: application 578 MIME subtype name: cap+xml 580 Required parameters: (none) 582 Optional parameters: charset; Indicates the character encoding of 583 enclosed XML. Default is UTF-8 [RFC3629]. 585 Encoding considerations: Uses XML, which can employ 8-bit 586 characters, depending on the character encoding used. See RFC 587 3023 [RFC3023], Section 3.2. 589 Security considerations: This content type is designed to carry 590 payloads of the Common Alerting Protocol (CAP). 592 Interoperability considerations: This content type provides a way to 593 convey CAP payloads. 595 Published specification: RFC XXX [Replace by the RFC number of this 596 specification]. 598 Applications which use this media type: Applications that convey 599 alerts and warnings according to the CAP standard. 601 Additional information: OASIS has published the Common Alerting 602 Protocol at http://www.oasis-open.org/committees/ 603 documents.php&wg_abbrev=emergency 605 Person and email address to contact for further information: Hannes 606 Tschofenig, Hannes.Tschofenig@nsn.com 608 Intended usage: Limited use 610 Author/Change controller: IETF ECRIT working group 612 Other information: This media type is a specialization of 613 application/xml RFC 3023 [RFC3023], and many of the considerations 614 described there also apply to application/cap+xml. 616 8.2. IANA Registration for 425 Response Code 618 In the SIP Response Codes registry, the following is added 620 Reference: RFC-XXXX (i.e., this document) 622 Response code: 425 (recommended number to assign) 624 Default reason phrase: Bad Alert Message 626 Registry: 627 Response Code Reference 628 ------------------------------------------ --------- 629 Request Failure 4xx 630 425 Bad Alert Message [this doc] 632 This SIP Response code is defined in Section 5. 634 8.3. IANA Registration of New AlertMsg-Error Header Field 636 The SIP AlertMsg-error header field is created by this document, with 637 its definition and rules in Section 5, to be added to the IANA sip- 638 parameters registry with two actions: 640 1. Update the Header Fields registry with 642 Registry: 643 Header Name compact Reference 644 ----------------- ------- --------- 645 AlertMsg-Error [this doc] 647 2. In the portion titled "Header Field Parameters and Parameter 648 Values", add 650 Predefined 651 Header Field Parameter Name Values Reference 652 ----------------- ------------------- ---------- --------- 653 AlertMsg-Error code yes [this doc] 655 8.4. IANA Registration for the SIP AlertMsg-Error Codes 657 This document creates a new registry for SIP, called "AlertMsg-Error 658 Codes". AlertMsg-Error codes provide reason for the error discovered 659 by recipients, categorized by action to be taken by error recipient. 660 The initial values for this registry are shown below. 662 Registry Name: AlertMsg-Error Codes 664 Reference: [this doc] 666 Registration Procedures: Specification Required 668 Code Default Reason Phrase Reference 669 ---- --------------------------------------------------- --------- 670 100 "Cannot Process the Alert Payload" [this doc] 672 101 "Alert Payload was not present or could not be found" [this doc] 674 102 "Not enough information to determine 675 the purpose of the alert" [this doc] 677 103 "Alert Payload was corrupted" [this doc] 679 Details of these error codes are in Section 5. 681 9. Acknowledgments 683 The authors would like to thank the participants of the Early Warning 684 adhoc meeting at IETF#69 for their feedback. Additionally, we would 685 like to thank the members of the NENA Long Term Direction Working 686 Group for their feedback. 688 Additionally, we would like to thank Martin Thomson, James 689 Winterbottom, Shida Schubert, Bernard Aboba, and Marc Linsner for 690 their review comments. 692 10. References 694 10.1. Normative References 696 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 697 Requirement Levels", March 1997. 699 [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. 700 1.1", October 2005. 702 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 703 Types", RFC 3023, January 2001. 705 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 706 10646", STD 63, RFC 3629, November 2003. 708 [I-D.ietf-ecrit-phonebcp] 709 Rosen, B. and J. Polk, "Best Current Practice for 710 Communications Services in support of Emergency Calling", 711 draft-ietf-ecrit-phonebcp-20 (work in progress), 712 September 2011. 714 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 715 for the Session Initiation Protocol", RFC 6442, 716 December 2011. 718 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 719 A., Peterson, J., Sparks, R., Handley, M., and E. 720 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 721 June 2002. 723 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 724 and D. Gurle, "Session Initiation Protocol (SIP) Extension 725 for Instant Messaging", RFC 3428, December 2002. 727 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 728 Specifications: ABNF", STD 68, RFC 5234, January 2008. 730 [I-D.ietf-ecrit-additional-data] 731 Rosen, B., Tschofenig, H., and R. Marshall, "Additional 732 Data related to an Emergency Call", 733 draft-ietf-ecrit-additional-data-05 (work in progress), 734 October 2012. 736 10.2. Informative References 738 [I-D.ietf-ecrit-trustworthy-location] 739 Tschofenig, H., Schulzrinne, H., and B. Aboba, 740 "Trustworthy Location", 741 draft-ietf-ecrit-trustworthy-location-04 (work in 742 progress), October 2012. 744 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 745 Authenticated Identity Management in the Session 746 Initiation Protocol (SIP)", RFC 4474, August 2006. 748 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 749 Extensions to the Session Initiation Protocol (SIP) for 750 Asserted Identity within Trusted Networks", RFC 3325, 751 November 2002. 753 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 754 "Framework for Emergency Calling Using Internet 755 Multimedia", RFC 6443, December 2011. 757 Authors' Addresses 759 Brian Rosen 760 NeuStar, Inc. 761 470 Conrad Dr 762 Mars, PA 16046 763 US 765 Phone: 766 Email: br@brianrosen.net 768 Henning Schulzrinne 769 Columbia University 770 Department of Computer Science 771 450 Computer Science Building 772 New York, NY 10027 773 US 775 Phone: +1 212 939 7004 776 Email: hgs+ecrit@cs.columbia.edu 777 URI: http://www.cs.columbia.edu 779 Hannes Tschofenig 780 Nokia Siemens Networks 781 Linnoitustie 6 782 Espoo 02600 783 Finland 785 Phone: +358 (50) 4871445 786 Email: Hannes.Tschofenig@gmx.net 787 URI: http://www.tschofenig.priv.at