idnits 2.17.1 draft-ietf-atoca-requirements-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 12, 2012) is 4400 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5582' is defined on line 610, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ATOCA H. Schulzrinne 3 Internet-Draft Columbia University 4 Intended status: Informational S. Norreys 5 Expires: September 13, 2012 BT Group 6 B. Rosen 7 NeuStar, Inc. 8 H. Tschofenig 9 Nokia Siemens Networks 10 March 12, 2012 12 Requirements, Terminology and Framework for Exigent Communications 13 draft-ietf-atoca-requirements-03.txt 15 Abstract 17 Before, during and after emergency situations various agencies need 18 to provide information to a group of persons or to the public within 19 a geographical area. While many aspects of such systems are specific 20 to national or local jurisdictions, emergencies span such boundaries 21 and notifications need to reach visitors from other jurisdictions. 23 This document provides terminology, requirements and an architectural 24 description for protocols exchanging alerts between IP-based end 25 points. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 13, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Classical Early Warning Situations . . . . . . . . . . . . 3 63 1.2. Exigent Communications . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Originator . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.2. Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.3. Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.4. Receiver . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1. Small Group Alert Delivery . . . . . . . . . . . . . . . . 8 71 3.2. Mass Alert Delivery . . . . . . . . . . . . . . . . . . . 8 72 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.1. Requirements for the Discovery of an Alert 74 Distribution Server . . . . . . . . . . . . . . . . . . . 10 75 4.2. Requirements for Multicast/Broadcast Alert Message 76 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Appendix A. Supplementary Requirements . . . . . . . . . . . . . 14 84 A.1. Requirements for Alert Subscription . . . . . . . . . . . 14 85 A.2. Point-to-Point Alert Delivery . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 1.1. Classical Early Warning Situations 92 During large-scale emergencies, public safety authorities need to 93 reliably communicate with citizens in the affected areas, to provide 94 warnings, indicate whether citizens should evacuate and how, and to 95 dispel misinformation. Accurate information can reduce the impact of 96 such emergencies. 98 Traditionally, emergency alerting has used church bells, sirens, 99 loudspeakers, radio and television to warn citizens and to provide 100 information. However, techniques, such as sirens and bells, provide 101 limited information content; loud speakers cover only very small 102 areas and are often hard to understand, even for those not hearing 103 impaired or fluent in the local language. Radio and television offer 104 larger information volume, but are hard to target geographically and 105 do not work well to address the "walking wounded" or other 106 pedestrians. Both are not suitable for warnings, as many of those 107 needing the information will not be listening or watching at any 108 given time, particularly during work/school and sleep hours. 110 This problem has been illustrated by the London underground bombing 111 on July 7, 2006, as described in a government report [July2005]. The 112 UK authorities could only use broadcast media and could not, for 113 example, easily announce to the "walking wounded" where to assemble. 115 1.2. Exigent Communications 117 With the usage of the term 'Exigent Communications' this document 118 aims to generalize the concept of conveying alerts to IP-based 119 systems and at the same time to describe the actors that participate 120 in the messaging communication. More precisely, exigent 121 communications is defined as: 123 Communication that requirs immediate action or remedy. 124 Information about the reason for action and details about the 125 steps that have to be taken are provided in the alert message. 127 An alert message (or warning message) is a cautionary advice about 128 something imminent (especially imminent danger or other 129 unpleasantness). In the context of exigent communication such an 130 alert message refers to a future, ongoing or past event as the 131 signaling exchange itself may relate to different stages of the 132 lifecycle of the event. The alert message itself, and not the 133 signaling protocol that convey it, provides sufficient context 134 about the specific state of the lifecycle the alert message refers 135 to. 137 On a high level the communication occurs in two phases with the 138 subscription phase sometimes being implicit: 140 Subscription: 142 In this step Recipients express their interest in receiving 143 certain types of alerts. This step happens prior to the actual 144 delivery of the alert. This expression of interest may be in form 145 of an explicit communication step by having the Receiver send a 146 subscribe message (potentially with an indication of the type of 147 alerts they are interested in, the duration of the subscription 148 and a number of other indicators). For example, parents may want 149 to be alerted of emergencies affecting the school attended by 150 their children and adult children may need to know about 151 emergencies affecting elderly parents. The subscription step may, 152 however, also happen outside the Internet communication 153 infrastructure and instead by the Recipient signing a contract and 154 thereby agreeing to receive certain alerts. The Receiver, a 155 software application, still needs to be configured in such a way 156 that incoming alerts are accepted, processed and passed up to the 157 user interface alerting a Recipient. Additionally, certain 158 subscriptions may happen without the Recipient's explicit consent 159 and without the Receiver sending a subscription. For example, a 160 Tsunami flood alert may be delivered to all Receivers in case they 161 are located in a specific geographical area. 163 It is important to note that a protocol interaction initiated by 164 the Receiver may need to take place to subscribe to certain types 165 of alerts. In some other cases the subscription does not require 166 such interaction from the Receiver. Orthogonal to the need to 167 have a protocol interaction is the question of opt-in vs. opt-out. 168 Whether the Recipient, as a human actor, needs to consent to 169 receive certain types of alerts is a policy decision that is 170 largely outside the scope of a technical specification. 172 Alert Delivery: 174 In this step the alert message is distributed to one or multiple 175 Receivers. The Receiver as a software module that presents the 176 alert message to the Recipient. The alert encoding is 177 accomplished via the Common Alerting Protocol (CAP) and such an 178 alert message contains useful information needed for dealing with 179 the imminent danger. 181 Note that an alert receiver software modules may not necessarily only 182 be executed on end devices humans typically carry around, such as 183 mobile phones, Internet tablets, or laptops. Instead, alerts may 184 well be directly sent to displays in subway stations, or electronic 185 bill boards. Furthermore, a software module that obtains an alert 186 may not necessarily need to interact with a human (as the Recipient) 187 but may instead use it as input to another process to trigger 188 automated behaviors, such as closing vents during a chemical spill or 189 activating sirens or other warning systems in commercial buildings. 191 This document provides terminology, requirements and an architectural 192 description. Note that the requirements focus on the communication 193 protocols for subscription and alert delivery rather than on the 194 content of the alert message itself. With the usage of CAP these 195 alert message content requirements are delegated to the Authors and 196 Originators of alerts. 198 2. Terminology 200 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in [RFC2119], with the 203 important qualification that, unless otherwise stated, these terms 204 apply to the design of a protocol conveying warning messages, not its 205 implementation or application. 207 Alert messages are typically produced by humans and consumed by 208 users, Authors and Recipients in our system, are the sources and 209 sinks of alert messages. 211 The Author is a human responsible for creating the content of the 212 alert message, and to make a decision about the intended recipients, 213 even though the exact list of recipients may be unknown to the Author 214 at the time of writing the alert message. Instead, the recipients 215 may, for example, be described in terms of a geographical region, or 216 recipients with interest in a specific alert type. 218 The Recipient is a consumer of the delivered alert message. It is a 219 human reading the alert message. 221 From the user's perspective, all alert message transfer activities 222 are performed by a monolithic Message Handling Service (MHS), even 223 though the actual service can be provided by many independent 224 organizations. The Message Handling Service (MHS) performs a single 225 end-to-end transfer of warning messages on behalf of the Author to 226 reach the Recipients. 228 Figure 1 shows the relationships among transfer participants. 229 Transfers typically entail one or more Relays. However, direct 230 delivery from the Originator to Receiver is possible. 232 ++==========++ ++===========++ 233 || Author || || Recipient || 234 ++====++====++ ++===========++ 235 || /\ 236 || || 237 \/ || 238 +----------+ +---++----+ 239 | | | | 240 /-+----------+----------------------------+---------+---\ 241 | | | Message Handling | | | 242 | |Originator| System (MHS) |Receiver | | 243 | | | | | | 244 | +---++-----+ +---------+ | 245 | || /\ | 246 | || || | 247 | \/ || | 248 | +---------+ +---------+ +-+--++---+ | 249 | | Relay +======-=>| Relay +=======>| Relay | | 250 | +---------+ +----++---+ +---------+ | 251 | || | 252 | || | 253 | \/ | 254 | +---------+ | 255 | | Gateway +--> | 256 | +---------+ | 257 \-------------------------------------------------------/ 259 Legend: === and || lines indicate primary (possibly 260 indirect) transfers or roles 262 Figure 1: Relationships Among MHS Actors 264 2.1. Originator 266 The Originator ensures that a warning message is valid for transfer 267 and then submits it to a Relay. A message is valid if it conforms to 268 both communication and warning message encapsulation standards and 269 local operational policies. The Originator can simply review the 270 message for conformance and reject it if it finds errors, or it can 271 create some or all of the necessary information. 273 The Originator serves the Author and can be the same entity in 274 absence of a human crafting alert messages. 276 The Originator also performs any post-submission, Author-related 277 administrative tasks associated with message transfer and delivery. 278 Notably, these tasks pertain to sending error and delivery notices, 279 and enforcing local policies. The Author creates the message, but 280 the Originator handles any transmission issues with it. 282 2.2. Relay 284 The Relay performs MHS-level transfer-service routing and store-and- 285 forward, by transmitting or retransmitting the message to its 286 Recipients. The Relay may add history information (e.g., the SIP 287 History Info [RFC4244] serves as a good example of the type of 288 information that may be conveyed) or security related protection 289 (e.g., as available with SIP Identity [RFC4474]) but does not modify 290 the envelope information or the message content semantics. 292 A Message Handling System (MHS) network consists of a set of Relays. 293 This MHS network is typically above any underlying IP network but may 294 involve technologies like IP multicast. 296 2.3. Gateway 298 A Gateway connects heterogeneous communication infrastructures and 299 its purpose is to emulate a Relay and the closer it comes to this, 300 the better. A Gateway needs the ability to modify message content. 302 Differences between the different communication systems can be as 303 small as minor syntax variations, but they usually encompass 304 significant, semantic distinctions. Hence, the Relay function in a 305 Gateway presents a significant design challenge, if the resulting 306 performance is to be seen as nearly seamless. The challenge is to 307 ensure end-to-end communication between the communication services, 308 despite differences in their syntax and semantics. 310 2.4. Receiver 312 The Receiver performs final delivery and is typically responsible for 313 ensuring that the appropriate user interface rendering is executed to 314 interact with the Recipient. 316 3. Framework 318 Section 1 describes the basic two steps that are involved with the 319 alert message handling, namely subscription and alert delivery. From 320 an architectural point of view there are, however, a few variations 321 possible depending on the characteristics of the subscription process 322 and the style of message delivery. This section offers more details 323 on the communication architecture. Note that this document does not 324 mandate a specific deployment architecture. Instead it aims to 325 illustrate how various different protocol components fit together to 326 present the reader with the 'big picture'. 328 3.1. Small Group Alert Delivery 330 We start our description with the so-called "school closed" example 331 where school authorities send alerts to all parents to notify them 332 about the fact that their children cannot attend school. Parents 333 subscribe to these events when their children start attending the 334 school and unsubscribe when they are finished with a particular 335 school. The subscription procedures establishes some form of group 336 communication by requiring an initial registration procedure. 337 Typically, alert messages stay within the closed group and are not 338 shared with others and alert message delivery is point-to-point with 339 whatever communication protocol is most suitable. This also means 340 that the alerts reach those who have subscribed rather than those who 341 are in the vicinity of the school. The number of Recipients is 342 typically rather small, in the order of hundreds to several 343 thousands. 345 A variation of the "school closed" example is an explicit 346 subscription model where no closed group pattern exists. The main 347 difference to the former case is in the authorization model. 348 Consider a traveler who would like to receive weather alerts about a 349 specific geographical region. He may have to manually search for how 350 to subscribe to alerts for the desired region, potentially looking a 351 different subscription points for different types of alerts. As an 352 automated version of this procedure some form of discovery may help 353 to find these subscription servers. The approach described in 354 [I-D.rosen-ecrit-lost-early-warning] is one possible way to discovery 355 such alert subscription servers. The number of alert message 356 Recipients is much larger than in the previous school example but 357 will typically stay below the millions. 359 These alert delivery examples are supported by a number of 360 standardized communication protocols, such as SIP, XMPP, eMail, or 361 RSS feeds. 363 Note that there are optimizations for application layer alert 364 delivery that mimic a multicast delivery with the help of Relays. 365 However, a subscription is still necessary by the Receiver and the 366 last-hop delivery of the alert is still done using unicast 367 transmission. 369 While these two examples are important for many deployments they are 370 not in focus of the ATOCA working group. 372 3.2. Mass Alert Delivery 374 With the next category we move to a scenario where large number of 375 Recipients shall be notified but the subscription itself is implicit, 376 as it is the case when persons are within a specific region that can 377 easily be reached by making use of broadcast link layer technologies. 378 The placement of the actors from Figure 1 is thereby important. An 379 Originator distributes the alert message to Relays within the 380 geographically affected area. Those Relays are located within 381 Internet Service Providers so that multicast and broadcast 382 communication protocols can be utilized for efficient distribution to 383 a large number of Recipients within the affected area. When the 384 alert message delivery has to be accomplished at the network layer 385 then various requirements, such as the ability to traverse NATs and 386 firewalls, have to be met by such a protocol. In this scenario the 387 number of alert message Recipients is very large, potentially in the 388 millions. 390 As a variation of the previously described model consider an alert 391 distribution with subscriptions to the alerts. Figure 2 shows the 392 architecture. 394 A discovery server ensures that Receivers are able to learn the local 395 alert distribution servers. Once a Receiver had discovered a local 396 alert distribution server it sends a subscribe message to it. As a 397 response, it will receive information about the security credentials 398 the alert distribution server is going to use for subsequent alert 399 delivery. 401 When an Author creates an alert for distribution the affected region 402 will be indicated and so the alert will be sent to a Relay within the 403 realm of the local alert distribution server and a notification will 404 be sent to all the subscribed Receivers. 406 ,-----------. 407 | Discovery | 408 | Server | 409 `...........' 410 : 411 : 412 ,''''''''''''''''''''''''\ : 413 | Local ,------. | : 414 | Alert | Local| | : ................... 415 | Distribution | Relay|.|..: Alert | +------+ Author | 416 | Server `......'-+<------------------+-|Sender| O | 417 | | | Notification | | | /|\ | 418 '`'''''''''''''''''+'''''' | +------+ / \ | 419 ^ Alert | `-----------------' 420 Subscr. +---------+ 421 | | Notification 422 | | 423 | V 424 ..................... 425 | +------+ Recipient| 426 | |Recvr | O | 427 | | | /|\ | 428 | +------+ / \ | 429 `-------------------' 431 Figure 2: Multicast/Broadcast Alert Delivery Mechanism with Explicit 432 Subscription 434 4. Requirements 436 The requirements listed below focus on the goal of mass alert 437 distribution, which has to utilize multicast/broadcast communication 438 for scalability reasons. The requirements for point-to-point alert 439 delivery are shown in Appendix A for completeness reasons only since 440 the focus of the IETF ATOCA working group is on the multicast/ 441 broadcast alert delivery. 443 4.1. Requirements for the Discovery of an Alert Distribution Server 445 Req-D1: 447 The protocol solution MUST allow a receiver to discover a local 448 alert distribution server, as discussed in Section 3 and shown in 449 Figure 2, and to discover the necessary security credentials for 450 subsequent alert message distribution. 452 4.2. Requirements for Multicast/Broadcast Alert Message Delivery 454 Req-B1: 456 The protocol solution MUST leverage multicast/broadcast 457 technologies. This implies non-TCP transport and congestion 458 control being considered. 460 Req-B2: 462 The protocol solution MUST allow delivery of messages 463 simultaneously to a large audience. 465 Req-B3: 467 The protocol solution MUST be able to traverse firewalls and NATs 468 as they are common in today's deployments. 470 5. IANA Considerations 472 This document does not require actions by IANA. 474 6. Security Considerations 476 Figure 1 shows the actors for delivering an alert message assuming 477 that a prior subscription has taken place already. The desired 478 security properties of an MHS for conveying alerts will depend on the 479 number of administrative domains involved. Each administrative 480 domain can have vastly different operating policies and trust-based 481 decision-making. One obvious example is the distinction between 482 alert messages that are exchanged within an closed group (such as 483 alert messages received by parents affecting the school attended by 484 their children) and alert messages that are exchanged between 485 independent organizations (e.g., in case of large scale disasters). 486 The rules for handling both types of communication architectures tend 487 to be quite different. That difference requires defining the 488 boundaries of each. 490 Operation of communication systems that are used to convey alert 491 messages are typically carried out by different providers (or 492 operators). Since each be in operated in an independent 493 administrative domain it is useful to consider administrative domain 494 boundaries in the description to facilitate discussion about designs, 495 policies and operations that need to distinguish between internal 496 issues and external entities. Most significant is that the entities 497 communicating across administrative boundaries typically have the 498 added burden of enforcing organizational policies concerning external 499 communications. For example, routing alerts between administrative 500 domains can create requirements, such as needing to route alert 501 messages between organizational partners over specially trusted 502 paths. 504 The communication interactions are subject to the policies of that 505 domain, which cover concerns such as these: 507 o Reliability 508 o Access control 509 o Accountability 510 o Content evaluation, adaptation, and modification 512 Many communication systems make the distinction of administrative 513 domains since they impact the requirements on security solutions. 514 However, with the distribution of alert messages a number of 515 additional security threats need to be addressed. Due to the nature 516 of alerts it is quite likely that end device implementations will 517 offer user interface enhancements to get the Recipients attention 518 whenever an alert arrives, which is an attractive property for 519 adversaries to exploit. Below we list the most important threats any 520 solution will have to deal with. 522 Originator Impersonation: 524 An attacker could then conceivably attempt to impersonate the 525 Originator of an alert message. This threat is particularly 526 applicable to those deployment environments where authorization 527 decisions are based on the identity of the Originator. 529 Alert Message Forgery: 531 An attacker could forge or alter an alert message in order to 532 convey custom messages to Recipients to get their immediate 533 attention. 535 Replay: 537 An attacker could obtain previously distributed alert messages and 538 to replay them at a later time in the hope that Recipients could 539 be tricked into believing they are fresh. 541 Unauthorized Distribution: 543 When a Receiver receives an alert message it has to determine 544 whether the Author distributing the alert messages is genuine to 545 avoid accepting messages that are injected by malicious entities 546 with the potential desire to at least get the immediate attention 547 of the Recipient. 549 Amplification Attack: 551 An attacker may use the Message Handling System to inject a single 552 alert message for distribution that may then be instantly turned 553 into potentially millions of alert messages for distribution. 555 One important security challenge is related to authorization. When 556 an alert message arrives at the Receiver then certain security checks 557 may need to be performed to ensure that the alert message meets 558 certain criteria. The final consumer of the alert message is, 559 however, the Recipient - a human. From a security point of view the 560 work split between the Recipient and the Receiver for making the 561 authorization decision is important, particularly when an alert 562 message is rejected due to a failed security verification by the 563 Receiver. False positives may be fatal but accepting every alert 564 message lowers the trustworthiness in the overall system. 566 7. Acknowledgments 568 This document re-uses text from [RFC5598]. The authors would like to 569 thank Dave Crocker for his work. 571 The authors would like to thank Martin Thomson, Carl Reed, Leopold 572 Murhammer, and Tony Rutkowski for their comments. 574 At IETF#79 the following persons provided feedback leading to changes 575 in this document: Keith Drage, Scott Bradner, Ken Carberg, Keeping 576 Li, Martin Thomson, Igor Faynberg, Mark Wood, Peter Saint-Andre. 578 8. References 580 8.1. Normative References 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, March 1997. 585 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 586 July 2009. 588 8.2. Informative References 590 [I-D.rosen-ecrit-lost-early-warning] 591 Rosen, B., Schulzrinne, H., and H. Tschofenig, "A Uniform 592 Resource Name (URN) for Early Warning Emergency Services 593 and Location-to-Service Translation (LoST) Protocol 594 Usage", draft-rosen-ecrit-lost-early-warning-01 (work in 595 progress), July 2009. 597 [July2005] 598 , ., "Report of the 7 July Review Committee, ISBN 1 599 85261 878 7", (PDF document), http://www.london.gov.uk/ 600 assembly/reports/7july/report.pdf, June 2006. 602 [RFC4244] Barnes, M., "An Extension to the Session Initiation 603 Protocol (SIP) for Request History Information", RFC 4244, 604 November 2005. 606 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 607 Authenticated Identity Management in the Session 608 Initiation Protocol (SIP)", RFC 4474, August 2006. 610 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 611 Framework", RFC 5582, September 2009. 613 Appendix A. Supplementary Requirements 615 A.1. Requirements for Alert Subscription 617 The requirements listed below refer to the alert subscription phase 618 as it is used to tailor alert message delivery in a point-to-point 619 alert delivery scenario. As noted in the main part of the document 620 these requirements are not the main focus of the ATOCA work. 622 Req-S1: 624 The protocol solution MUST allow a potential Recipient to indicate 625 the language used by alert messages. 627 Req-S2: 629 The protocol solution MUST allow a potential Recipient to express 630 the geographical area it wants to receive alerts about. 632 Req-S3: 634 The protocol solution MUST allow a potential Recipient to indicate 635 preferences about the type of alerts it wants to receive. 637 Req-S4: 639 The protocol solution MUST allow a potential Recipient to express 640 preference for certain media types. The support for different 641 media types depends on the content of the warning message but also 642 impacts the communication protocol. This functionality is, for 643 example, useful for hearing and vision impaired persons. 645 A.2. Point-to-Point Alert Delivery 647 Req-P1: 649 The protocol solution MUST build on existing communication 650 protocols and support the delivery of alert messages. Examples of 651 such protocols are SIP, XMPP, Atom, eMail. 653 Req-P2: 655 The protocol solution MUST allow targeting notifications to 656 specific subscribers. 658 Authors' Addresses 660 Henning Schulzrinne 661 Columbia University 662 Department of Computer Science 663 450 Computer Science Building 664 New York, NY 10027 665 US 667 Phone: +1 212 939 7004 668 Email: hgs+ecrit@cs.columbia.edu 669 URI: http://www.cs.columbia.edu 671 Steve Norreys 672 BT Group 673 1 London Road 674 Brentwood, Essex CM14 4QP 675 UK 677 Phone: +44 1277 32 32 20 678 Email: steve.norreys@bt.com 679 Brian Rosen 680 NeuStar, Inc. 681 470 Conrad Dr 682 Mars, PA 16046 683 US 685 Phone: 686 Email: br@brianrosen.net 688 Hannes Tschhofenig 689 Nokia Siemens Networks 690 Linnoitustie 6 691 Espoo 02600 692 Finland 694 Phone: +358 (50) 4871445 695 Email: Hannes.Tschofenig@gmx.net 696 URI: http://www.tschofenig.priv.at