idnits 2.17.1 draft-ietf-ecrit-data-only-ea-05.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 (February 25, 2013) is 4078 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3428' is defined on line 823, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) == Outdated reference: A later version (-38) exists of draft-ietf-ecrit-additional-data-06 == 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 (~~), 5 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: Standards Track H. Schulzrinne 5 Expires: August 29, 2013 Columbia U. 6 H. Tschofenig 7 Nokia Siemens Networks 8 February 25, 2013 10 Data-Only Emergency Calls 11 draft-ietf-ecrit-data-only-ea-05.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. 26 These type of interactions are called 'data-only emergency calls'. 27 This document describes a container for the data based on the Common 28 Alerting Protocol (CAP) and its transmission using the SIP MESSAGE 29 transaction. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 29, 2013. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 5 67 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 8 68 4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 8 69 4.2. Profiling of the CAP Document Content . . . . . . . . . . 8 70 4.3. Sending a Data-Only Emergency Call . . . . . . . . . . . . 9 71 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.1. 425 (Bad Alert Message) Response Code . . . . . . . . . . 10 73 5.2. The AlertMsg-Error Header Field . . . . . . . . . . . . . 10 74 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 8.1. Registration of the 'application/cap+xml' MIME type . . . 19 78 8.2. IANA Registration for 425 Response Code . . . . . . . . . 20 79 8.3. IANA Registration of New AlertMsg-Error Header Field . . . 20 80 8.4. IANA Registration for the SIP AlertMsg-Error Codes . . . . 21 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 87 1. Introduction 89 RFC 6443 [RFC6443] describes how devices use the Internet to place 90 emergency calls and how Public Safety Answering Points (PSAPs) can 91 handle Internet multimedia emergency calls natively. The exchange of 92 multimedia traffic typically involves a SIP session establishment 93 starting with a SIP INVITE that negotiates various parameters for 94 that session. 96 In some cases, however, there is only application data to be conveyed 97 from the end devices to a PSAP or some other intermediary. Examples 98 of such environments includes sensors issuing alerts, or vehicles 99 sending crash data. These messages may be one-shot alerts to 100 emergency authorities and do not require establishment of a session. 101 These type of interactions are called 'data-only emergency calls'. 102 In this document, we use the term "call" so that similarities between 103 full sessions with interactive media can be exploited. 105 Data-only emergency calls are similar to regular emergency calls in 106 the sense that they require the emergency indications, emergency call 107 routing functionality and may even have the same location 108 requirements. However, the communication interaction will not lead 109 to the exchange of interactive media, that is, Real-Time Protocol 110 packets, such as voice, video data or real-time text. 112 This document does not define a mechanism for updates to the data 113 contained in data-only emergency calls. 115 The Common Alerting Protocol (CAP) [cap] is a document format for 116 exchanging emergency alerts and public warnings. CAP is mainly used 117 for conveying alerts and warnings between authorities and from 118 authorities to citizen/individuals. This document is concerned with 119 citizen to authority "alerts", where the alert is sent without any 120 interactive media. 122 CAP payload is used to convey the alert data which is contained in 123 the body of a SIP MESSAGE. Note that further data may be added using 124 the already available 'additional data' structure 125 [I-D.ietf-ecrit-additional-data]. Whenever data can be encoded in 126 the additional data structure it shall be used. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 3. Architectural Overview 136 This section illustrates two envisioned usage modes; targeted and 137 location-based emergency alert routing. 139 1. Emergency alerts containing only data are targeted to a 140 intermediary recipient responsible for evaluating the next steps. 141 These steps could include: 143 1. Sending an alert containing only data toward a Public Safety 144 Answering Point (PSAP); 146 2. Establishing a third-party initiated emergency call towards a 147 PSAP that could include audio, video, and data. 149 2. Emergency alerts targeted to a Service URN used for IP-based 150 emergency calls where the recipient is not known to the 151 originator. In this scenario, the alert may contain only data 152 (e.g., a CAP and a PIDF-LO payload in a SIP MESSAGE). 154 Figure 1 shows a deployment variant where a sensor, is pre-configured 155 (using techniques outside the scope of this document) to issue an 156 alert to an aggregator that processes these messages and performs 157 whatever steps are necessary to appropriately react on the alert. 158 For example, a security firm may use different sensor inputs to 159 dispatch their security staff to a building they protect or to 160 initiate a third-party emergency call. 162 +------------+ +------------+ 163 | Sensor | | Aggregator | 164 | | | | 165 +---+--------+ +------+-----+ 166 | | 167 Sensors | 168 trigger | 169 emergency | 170 alert | 171 | MESSAGE with CAP | 172 |----------------------------->| 173 | | 174 | Aggregator 175 | processes 176 | emergency 177 | alert 178 | 200 (OK) | 179 |<-----------------------------| 180 | | 181 | | 183 Figure 1: Targeted Emergency Alert Routing 185 In Figure 2 a scenario is shown whereby the alert is routed using 186 location information and the Service URN. An emergency services 187 routing proxy (ESRP) may use LoST to determine the next hop proxy to 188 route the alert message to. A possible receiver is a PSAP and the 189 recipient of the alert may be call taker. In the generic case, there 190 is very likely no prior relationship between the originator and the 191 receiver, e.g. PSAP. A PSAP, for example, is likely to receive and 192 accept alerts from entities it cannot authorize. This scenario 193 corresponds more to the classical emergency services use case and the 194 description in [I-D.ietf-ecrit-phonebcp] is applicable. 196 +-----------+ +----------+ 197 +--------+ | ESRP | | PSAP | 198 | Sensor | | | | | 199 +---+----+ +---+-------+ +---+------+ 200 | | | 201 Sensors | | 202 trigger | | 203 emergency | | 204 alert | | 205 | | | 206 | | | 207 | MESSAGE with CAP | | 208 | (including Service URN, | 209 | such as urn:service:sos) | 210 |------------------->| | 211 | | | 212 | ESRP performs | 213 | emergency alert | 214 | routing | 215 | | MESSAGE with CAP | 216 | | (including identity info) | 217 | |----------------------------->| 218 | | | 219 | | PSAP 220 | | processes 221 | | emergency 222 | | alert 223 | | 200 (OK) | 224 | |<-----------------------------| 225 | | | 226 | 200 (OK) | | 227 |<-------------------| | 228 | | | 229 | | | 231 Figure 2: Location-Based Emergency Alert Routing 233 4. Protocol Specification 235 4.1. CAP Transport 237 A CAP message may be sent on the initial message of any SIP 238 transaction. However, this document only describes specific behavior 239 when used with a SIP MESSAGE transaction for a one-shot, data-only 240 emergency call. Behavior with other transactions is not defined. 241 The CAP message is sent in the body of the message. The MIME type is 242 set to 'application/cap+xml'. 244 If the server does not support the functionality required to fulfill 245 the request then a 501 Not Implemented MUST be returned as specified 246 in RFC 3261 [RFC3261]. This is the appropriate response when a UAS 247 does not recognize the request method and is not capable of 248 supporting it for any user. 250 The 415 Unsupported Media Type error MUST be returned as specified in 251 RFC 3261 [RFC3261] if the server is refusing to service the request 252 because the message body of the request is in a format not supported 253 by the server for the requested method. The server MUST return a 254 list of acceptable formats using the Accept, Accept-Encoding, or 255 Accept-Language header field, depending on the specific problem with 256 the content. 258 4.2. Profiling of the CAP Document Content 260 The usage of CAP MUST conform to the specification provided with 261 [cap]. For the usage with SIP the following additional requirements 262 are imposed: 264 sender: A few sub-categories for putting a value in the 265 element have to be considered: 267 Originator is a SIP entity, Author indication irrelevant: When 268 the alert was created by a SIP-based originator and it is not 269 useful to be explicit about the author of the alert then the 270 element MUST be populated with the SIP URI of the user 271 agent. 273 Originator is a non-SIP entity, Author indication irrelevant: In 274 case that the alert was created by a non-SIP based entity and 275 the identity of this original sender wants to be preserved then 276 this identity MUST be placed into the element. In 277 this category the it is not useful to be explicit about the 278 author of the alert. The specific type of identity being used 279 will depends on the technology being used by the original 280 originator. 282 Author indication relevant: In case the author is different from 283 the actual originator of the message and this distinction 284 should be preserved then the element MUST NOT contain 285 the SIP URI of the user agent. 287 incidents: The element MUST be present. This incident 288 identifier MUST be chosen in such a way that it is unique for a 289 given combination. Note that the 290 element is optional and may not be present. 292 scope: The value of the element MAY be set to "Private" if 293 the alert is not meant for public consumption. The 294 element is, however, not used by this specification since the 295 message routing is performed by SIP and the respective address 296 information is already available in other SIP headers. Populating 297 information twice into different parts of the message may lead to 298 inconsistency. 300 parameter: The element MAY contain additional 301 information specific to the sendor. 303 area: It is RECOMMENDED to omit this element when constructing a 304 message. In case that the CAP message already contained an 305 element then the specified location information SHOULD be copied 306 into the PIDF-LO structure of the 'geolocation' header. 308 4.3. Sending a Data-Only Emergency Call 310 A data-only emergency call is sent using a SIP MESSAGE transaction 311 with a CAP body as described above in a manner similar to how an 312 emergency call with interactive media is sent, as described in 313 [I-D.ietf-ecrit-phonebcp]. The MESSAGE transaction does not create a 314 session or send media, but otherwise, the header content of the 315 transaction, routing, and processing of data-only calls are the same 316 as those of other emergency calls. 318 5. Error Handling 320 This section defines a new error response code and a header field for 321 additional information. 323 5.1. 425 (Bad Alert Message) Response Code 325 This SIP extension creates a new location-specific response code, 326 defined as follows, 328 425 (Bad Alert Message) 330 The 425 response code is a rejection of the request due to its 331 included alert content, indicating that it was malformed or not 332 satisfactory for the recipient's purpose. 334 A SIP intermediary can also reject an alert it receives from a UA 335 when it understands that the provided alert is malformed. 337 Section 5.2 describes an AlertMsg-Error header field with more 338 details about what was wrong with the alert message in the request. 339 This header field MUST be included in the 425 response. 341 It is only appropriate to generate a 425 response when the responding 342 entity has no other information in the request that are usable by the 343 responder. 345 A 425 response code MUST NOT be sent in response to a request that 346 lacks an alert message entirely, as the user agent in that case may 347 not support this extension at all. 349 A 425 response is a final response within a transaction, and MUST NOT 350 terminate an existing dialog. 352 5.2. The AlertMsg-Error Header Field 354 The AlertMsg-Error header provides additional information about what 355 was wrong with the original request. In some cases the provided 356 information will be used for debugging purposes. 358 The AlertMsg-Error header field has the following ABNF [RFC5234]: 360 message-header /= AlertMsg-Error 361 ; (message-header from 3261) 362 AlertMsg-Error = "AlertMsg-Error" HCOLON 363 ErrorValue 364 ErrorValue = error-code 365 *(SEMI error-params) 366 error-code = 1*3DIGIT 367 error-params = error-code-text 368 / generic-param ; from RFC3261 369 error-code-text = "code" EQUAL quoted-string ; from RFC3261 371 HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is 372 defined in RFC5234 [RFC5234]. 374 The AlertMsg-Error header field MUST contain only one ErrorValue to 375 indicate what was wrong with the alert payload the recipient 376 determined was bad. 378 The ErrorValue contains a 3-digit error code indicating what was 379 wrong with the alert in the request. This error code has a 380 corresponding quoted error text string that is human understandable. 381 The text string are OPTIONAL, but RECOMMENDED for human readability, 382 similar to the string phrase used for SIP response codes. That said, 383 the strings are complete enough for rendering to the user, if so 384 desired. The strings in this document are recommendations, and are 385 not standardized - meaning an operator can change the strings - but 386 MUST NOT change the meaning of the error code. Similar to how RFC 387 3261 specifies, there MUST NOT be more than one string per error 388 code. 390 The AlertMsg-Error header field MAY be included in any response as an 391 alert message was in the request part of the same transaction. For 392 example, a UA includes an alert in an MESSAGE to a PSAP. The PSAP 393 can accept this MESSAGE, thus creating a dialog, even though his UA 394 determined the alert message contained in the MESSAGE was bad. The 395 PSAP merely includes an AlertMsg-Error header value in the 200 OK to 396 the MESSAGE informing the UA that the MESSAGE was accepted but the 397 alert provided was bad. 399 If, on the other hand, the PSAP cannot accept the transaction without 400 a suitable alert message, a 425 response is sent. 402 A SIP intermediary that requires the UA's alert message in order to 403 properly process the transaction may also sends a 425 with a 404 AlertMsg-Error code. 406 This document defines an initial list of error code ranges for any 407 SIP response, including provisional responses (other than 100 Trying) 408 and the new 425 response. There MUST be no more than one AlertMsg- 409 Error code in a SIP response. 411 AlertMsg-Error: 100 ; code="Cannot Process the Alert Payload" 413 AlertMsg-Error: 101 ; code="Alert Payload was not present or could 414 not be found" 416 AlertMsg-Error: 102 ; code="Not enough information to determine the 417 purpose of the alert" 419 AlertMsg-Error: 103 ; code="Alert Payload was corrupted" 421 Additionally, if an entity cannot or chooses not to process the alert 422 message from a SIP request, a 500 (Server Internal Error) SHOULD be 423 used with or without a configurable Retry-After header field. 425 6. Example 427 Figure 3 shows a CAP document indicating a BURGLARY alert issued by a 428 sensor called 'sensor1@domain.com'. The location of the sensor can 429 be obtained from the attached location information provided via the 430 'geolocation' header contained in the SIP MESSAGE structure. 431 Additionally, the sensor provided some data long with the alert 432 message using proprietary information elements only to be processed 433 by the receiver, a SIP entity acting as an aggregator. This example 434 reflects the description in Figure 1. 436 MESSAGE sip:aggregator@domain.com SIP/2.0 437 Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse 438 Max-Forwards: 70 439 From: sip:sensor1@domain.com;tag=49583 440 To: sip:aggregator@domain.com 441 Call-ID: asd88asd77a@1.2.3.4 442 Geolocation: 443 ;routing-allowed=yes 444 Supported: geolocation 445 Accept: application/pidf+xml, application/cap+xml 446 CSeq: 1 MESSAGE 447 Content-Type: multipart/mixed; boundary=boundary1 448 Content-Length: ... 450 --boundary1 452 Content-Type: cap+xml 453 Content-ID: 454 456 457 S-1 458 sip:sensor1@domain.com 459 2008-11-19T14:57:00-07:00 460 Actual 461 Alert 462 Private 463 abc1234 464 465 Security 466 BURGLARY 467 Expected 468 Likely 469 Moderate 470 SENSOR 1 471 472 SENSOR-DATA-NAMESPACE1 473 123 474 475 476 SENSOR-DATA-NAMESPACE2 477 TRUE 478 479 480 482 --boundary1 484 Content-Type: application/pidf+xml 485 Content-ID: 486 487 495 496 497 498 499 500 32.86726 -97.16054 501 502 503 504 505 false 506 507 2010-11-14T20:00:00Z 508 509 510 802.11 511 512 2010-11-04T20:57:29Z 513 514 515 --boundary1-- 517 Figure 3: Example Message conveying an Alert to an Aggregator 519 Figure 4 shows the same CAP document sent as a data-only emergency 520 call towards a PSAP. 522 MESSAGE urn:service:sos SIP/2.0 523 Via: SIP/2.0/TCP sip:aggregator.1.example.com;branch=z9hG4bK776abssa 524 Max-Forwards: 70 525 From: sip:aggregator@example.com;tag=32336 526 To: 112 527 Call-ID: asdf33443a@example.com 528 Route: sip:psap1.example.gov 529 Geolocation: 530 ;routing-allowed=yes 531 Supported: geolocation 532 Accept: application/pidf+xml, application/cap+xml 533 CSeq: 1 MESSAGE 534 Content-Type: multipart/mixed; boundary=boundary1 535 Content-Length: ... 537 --boundary1 539 Content-Type: cap+xml 540 Content-ID: 541 543 544 S-1 545 sip:sensor1@domain.com 546 2008-11-19T14:57:00-07:00 547 Actual 548 Alert 549 Private 550 abc1234 551 552 Security 553 BURGLARY 554 Expected 555 Likely 556 Moderate 557 SENSOR 1 558 559 SENSOR-DATA-NAMESPACE1 560 123 561 562 563 SENSOR-DATA-NAMESPACE2 564 TRUE 566 567 568 570 --boundary1 572 Content-Type: application/pidf+xml 573 Content-ID: 574 575 583 584 585 586 587 588 32.86726 -97.16054 589 590 591 592 593 false 594 595 2010-11-14T20:00:00Z 596 597 598 802.11 599 600 2010-11-04T20:57:29Z 601 602 603 --boundary1-- 605 Figure 4: Example Message conveying an Alert to a PSAP 607 7. Security Considerations 609 This section discusses security considerations when SIP user agents 610 issue emergency alerts utilizing MESSAGE and CAP. Location specific 611 threats are not unique to this document and are discussed in 612 [I-D.ietf-ecrit-trustworthy-location] and [RFC6442]. 614 The ECRIT emergency services architecture [RFC6443] considers 615 classical individual-to-authority emergency calling and the identity 616 of the emergency caller does not play a role at the time of the call 617 establishment itself, i.e., a response to the emergency call will not 618 depend on the identity of the caller. In case of emergency alerts 619 generated by devices, like sensors, the processing may be different 620 in order to reduce the number of falsely generated emergency alerts. 621 Alerts may get triggered based on certain sensor input that may have 622 been caused by other factors than the actual occurrence of an alert 623 relevant event. For example, a sensor may simply be malfunctioning. 624 For this purpose not all alert messages are directly sent to a PSAP 625 but rather may be pre-processed by a separate entity, potentially 626 under supervision by a human, to filter alerts and potentially 627 correlate received alerts with others to obtain a larger picture of 628 the ongoing situation. 630 In any case, for alerts that are initiated by sensors the identity 631 may play an important role in deciding whether to accept or ignore an 632 incoming alert message. With the scenario shown in Figure 1 it is 633 very likely that only authorized sensor input will be processed. For 634 this purpose it needs to be ensured that no alert messages from an 635 unknown origin are accepted. Two types of information elements can 636 be used for this purpose: 638 1. SIP itself provides security mechanisms that allow the 639 verification of the originator's identity. These mechanisms can 640 be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity 641 [RFC4474]. The latter provides a cryptographic assurance while 642 the former relies on a chain of trust model. 644 2. CAP provides additional security mechanisms and the ability to 645 carry additional information about the sender's identity. 646 Section 3.3.2.1 of [cap] specifies the signing algorithms of CAP 647 documents. 649 In addition to the desire to perform identity-based access control 650 the classical communication security threats need to be considered, 651 including integrity protection to prevent forgery and replay of alert 652 messages in transit. To deal with replay of alerts a CAP document 653 contains the mandatory , , elements and an 654 optional element. These attributes make the CAP document 655 unique for a specific sender and provide time restrictions. An 656 entity that has received a CAP message already within the indicated 657 timeframe is able to detect a replayed message and, if the content of 658 that message is unchanged, then no additional security vulnerability 659 is created. Additionally, it is RECOMMENDED to make use of SIP 660 security mechanisms, such as SIP Identity [RFC4474], to tie the CAP 661 message to the SIP message. To provide protection of the entire SIP 662 message exchange between neighboring SIP entities the usage of TLS is 663 mandatory. 665 Note that none of the security mechanism in this document protect 666 against a compromised sensor sending crafted alerts. 668 8. IANA Considerations 670 8.1. Registration of the 'application/cap+xml' MIME type 672 To: ietf-types@iana.org 674 Subject: Registration of MIME media type application/ cap+xml 676 MIME media type name: application 678 MIME subtype name: cap+xml 680 Required parameters: (none) 682 Optional parameters: charset; Indicates the character encoding of 683 enclosed XML. Default is UTF-8 [RFC3629]. 685 Encoding considerations: Uses XML, which can employ 8-bit 686 characters, depending on the character encoding used. See RFC 687 3023 [RFC3023], Section 3.2. 689 Security considerations: This content type is designed to carry 690 payloads of the Common Alerting Protocol (CAP). 692 Interoperability considerations: This content type provides a way to 693 convey CAP payloads. 695 Published specification: RFC XXX [Replace by the RFC number of this 696 specification]. 698 Applications which use this media type: Applications that convey 699 alerts and warnings according to the CAP standard. 701 Additional information: OASIS has published the Common Alerting 702 Protocol at http://www.oasis-open.org/committees/ 703 documents.php&wg_abbrev=emergency 705 Person and email address to contact for further information: Hannes 706 Tschofenig, Hannes.Tschofenig@nsn.com 708 Intended usage: Limited use 710 Author/Change controller: IETF ECRIT working group 712 Other information: This media type is a specialization of 713 application/xml RFC 3023 [RFC3023], and many of the considerations 714 described there also apply to application/cap+xml. 716 8.2. IANA Registration for 425 Response Code 718 In the SIP Response Codes registry, the following is added 720 Reference: RFC-XXXX (i.e., this document) 722 Response code: 425 (recommended number to assign) 724 Default reason phrase: Bad Alert Message 726 Registry: 727 Response Code Reference 728 ------------------------------------------ --------- 729 Request Failure 4xx 730 425 Bad Alert Message [this doc] 732 This SIP Response code is defined in Section 5. 734 8.3. IANA Registration of New AlertMsg-Error Header Field 736 The SIP AlertMsg-error header field is created by this document, with 737 its definition and rules in Section 5, to be added to the IANA sip- 738 parameters registry with two actions: 740 1. Update the Header Fields registry with 742 Registry: 743 Header Name compact Reference 744 ----------------- ------- --------- 745 AlertMsg-Error [this doc] 747 2. In the portion titled "Header Field Parameters and Parameter 748 Values", add 750 Predefined 751 Header Field Parameter Name Values Reference 752 ----------------- ------------------- ---------- --------- 753 AlertMsg-Error code yes [this doc] 755 8.4. IANA Registration for the SIP AlertMsg-Error Codes 757 This document creates a new registry for SIP, called "AlertMsg-Error 758 Codes". AlertMsg-Error codes provide reason for the error discovered 759 by recipients, categorized by action to be taken by error recipient. 760 The initial values for this registry are shown below. 762 Registry Name: AlertMsg-Error Codes 764 Reference: [this doc] 766 Registration Procedures: Specification Required 768 Code Default Reason Phrase Reference 769 ---- --------------------------------------------------- --------- 770 100 "Cannot Process the Alert Payload" [this doc] 772 101 "Alert Payload was not present or could not be found" [this doc] 774 102 "Not enough information to determine 775 the purpose of the alert" [this doc] 777 103 "Alert Payload was corrupted" [this doc] 779 Details of these error codes are in Section 5. 781 9. Acknowledgments 783 The authors would like to thank the participants of the Early Warning 784 adhoc meeting at IETF#69 for their feedback. Additionally, we would 785 like to thank the members of the NENA Long Term Direction Working 786 Group for their feedback. 788 Additionally, we would like to thank Martin Thomson, James 789 Winterbottom, Shida Schubert, Bernard Aboba, and Marc Linsner for 790 their review comments. 792 10. References 794 10.1. Normative References 796 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 797 Requirement Levels", March 1997. 799 [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. 800 1.1", October 2005. 802 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 803 Types", RFC 3023, January 2001. 805 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 806 10646", STD 63, RFC 3629, November 2003. 808 [I-D.ietf-ecrit-phonebcp] 809 Rosen, B. and J. Polk, "Best Current Practice for 810 Communications Services in support of Emergency Calling", 811 draft-ietf-ecrit-phonebcp-20 (work in progress), 812 September 2011. 814 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 815 for the Session Initiation Protocol", RFC 6442, 816 December 2011. 818 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 819 A., Peterson, J., Sparks, R., Handley, M., and E. 820 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 821 June 2002. 823 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 824 and D. Gurle, "Session Initiation Protocol (SIP) Extension 825 for Instant Messaging", RFC 3428, December 2002. 827 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 828 Specifications: ABNF", STD 68, RFC 5234, January 2008. 830 [I-D.ietf-ecrit-additional-data] 831 Rosen, B., Tschofenig, H., Marshall, R., and R. Randy, 832 "Additional Data related to an Emergency Call", 833 draft-ietf-ecrit-additional-data-06 (work in progress), 834 February 2013. 836 10.2. Informative References 838 [I-D.ietf-ecrit-trustworthy-location] 839 Tschofenig, H., Schulzrinne, H., and B. Aboba, 840 "Trustworthy Location", 841 draft-ietf-ecrit-trustworthy-location-04 (work in 842 progress), October 2012. 844 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 845 Authenticated Identity Management in the Session 846 Initiation Protocol (SIP)", RFC 4474, August 2006. 848 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 849 Extensions to the Session Initiation Protocol (SIP) for 850 Asserted Identity within Trusted Networks", RFC 3325, 851 November 2002. 853 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 854 "Framework for Emergency Calling Using Internet 855 Multimedia", RFC 6443, December 2011. 857 Authors' Addresses 859 Brian Rosen 860 NeuStar, Inc. 861 470 Conrad Dr 862 Mars, PA 16046 863 US 865 Phone: 866 Email: br@brianrosen.net 868 Henning Schulzrinne 869 Columbia University 870 Department of Computer Science 871 450 Computer Science Building 872 New York, NY 10027 873 US 875 Phone: +1 212 939 7004 876 Email: hgs+ecrit@cs.columbia.edu 877 URI: http://www.cs.columbia.edu 879 Hannes Tschofenig 880 Nokia Siemens Networks 881 Linnoitustie 6 882 Espoo 02600 883 Finland 885 Phone: +358 (50) 4871445 886 Email: Hannes.Tschofenig@gmx.net 887 URI: http://www.tschofenig.priv.at