idnits 2.17.1 draft-baker-alert-system-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 655. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 645. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 10, 2005) is 7044 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) -- Missing reference section? 'RFC2821' on line 502 looks like a reference -- Missing reference section? 'RFC3850' on line 537 looks like a reference -- Missing reference section? 'RFC3851' on line 541 looks like a reference -- Missing reference section? 'RFC3156' on line 560 looks like a reference -- Missing reference section? 'RFC2505' on line 496 looks like a reference -- Missing reference section? 'RFC2554' on line 499 looks like a reference -- Missing reference section? 'RFC3030' on line 505 looks like a reference -- Missing reference section? 'RFC3207' on line 509 looks like a reference -- Missing reference section? 'RFC3461' on line 512 looks like a reference -- Missing reference section? 'RFC3848' on line 516 looks like a reference -- Missing reference section? 'RFC3885' on line 519 looks like a reference -- Missing reference section? 'RFC2634' on line 524 looks like a reference -- Missing reference section? 'RFC2785' on line 527 looks like a reference -- Missing reference section? 'RFC3114' on line 531 looks like a reference -- Missing reference section? 'RFC3183' on line 534 looks like a reference -- Missing reference section? 'RFC3853' on line 545 looks like a reference -- Missing reference section? 'RFC1991' on line 551 looks like a reference -- Missing reference section? 'RFC2015' on line 554 looks like a reference -- Missing reference section? 'RFC2440' on line 557 looks like a reference -- Missing reference section? 'NDIS' on line 570 looks like a reference -- Missing reference section? 'TIA-136-630' on line 574 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Expires: July 11, 2005 B. Carpenter 5 IBM Corporation 6 January 10, 2005 8 Structure of an International Emergency Alert System 9 draft-baker-alert-system-00 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 11, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The authors propose a way in which people could be warned of an 45 impending event in a geographic region. This is similar to and may 46 use services such as the US Emergency Alert System, but differs in 47 that message distribution is targeted only to the affected locality. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Facilities the proposal depends on . . . . . . . . . . . . . . 4 54 2.1 Warning Center . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2 Distributing alerts to regional centers . . . . . . . . . 5 56 2.2.1 Authenticated Electronic Mail . . . . . . . . . . . . 5 57 2.2.2 Polled delivery via the World Wide Web . . . . . . . . 6 58 2.3 Warning Interpretation Policy . . . . . . . . . . . . . . 6 59 2.4 Distribution of alert messages to the general 60 population . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.4.1 Mobile Telephone Text Message Services . . . . . . . . 7 62 2.4.2 Broadcast services such as radio or television 63 (regional broadcast) . . . . . . . . . . . . . . . . . 8 64 2.4.3 Presence-based services (subscription) . . . . . . . . 8 65 2.4.4 Message-based services (subscription) . . . . . . . . 8 67 3. Implementing an alert service . . . . . . . . . . . . . . . . 9 69 4. Call to Action . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 8.1 SMTP Specifications (for information) . . . . . . . . . . . 14 79 8.2 S/MIME specifications (for information) . . . . . . . . . . 14 80 8.3 PGP Specifications (for information) . . . . . . . . . . . . 15 81 8.4 Telephony specifications and references (for information) . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 85 A. I am Alive . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 B. Common Alerting Protocol . . . . . . . . . . . . . . . . . . . 18 89 Intellectual Property and Copyright Statements . . . . . . . . 19 91 1. Introduction 93 The earthquake near Sumatra and subsequent tsunami throughout the 94 Indian Ocean on 26 December 2004 resulted in a large number of 95 deaths; early estimates suggest six digit figures, with the hardest 96 hit being remote regions of Sumatra. In the aftermath of this event, 97 many countries have sent aid of various kinds, and the Internet 98 community has asked itself whether the Internet might have been used 99 to help. 101 This note proposes a system that could be used to quickly warn people 102 in an identified geographic region of an impending event, such as a 103 tsunami, hurricane or typhoon, or attack. It builds on existing 104 technologies that are presently used for other purposes: given a 105 alert from an appropriate Warning Center, the Internet (using, for 106 example, Internet Mail and S/MIME) could be used to deliver an 107 authenticated message to a set of mobile telephone operators, who in 108 turn could send an SMS broadcast to mobile telephones in affected 109 regions, alert of the event. The same email could trigger public and 110 private organizations to initiate necessary support services such as 111 evacuation orders or provision of shelter and emergency medical 112 response. Such an approach would, of course, not warn everyone - 113 everyone does not carry a mobile telephone, and everyone who does 114 would not necessarily read it. But it would warn a large percentage, 115 which might help. 117 This is similar to and may use services such as the US Emergency 118 Alert System. The Emergency Alert System (EAS) is the national alert 119 system designed primarily to allow the President to address the 120 nation reliably during major national disasters, using media such as 121 television, radio, and potentially mobile telephone in the future. 122 It differs in that message distribution is targeted only to the 123 affected locality, such as the mobile telephone cells in a given 124 city, along a coastline, or along the projected path of a storm, and 125 actively reaches out to its audience rather than depending on them 126 being passively watching at the time. 128 2. Facilities the proposal depends on 130 The proposal depends on the existence and use of four fundamental 131 types of systems: 133 o An Warning Center, such as the NOAA Pacific Tsunami alert Center 134 (http://www.prh.noaa.gov/ptwc/) or the US Geological Survey 135 Earthquake Hazards Program (http://neic.usgs.gov/neis/bulletin/). 137 o A mailing list of people interested in alerts from the alert 138 center, with internet connectivity and continuous monitoring of 139 such alerts. 141 o An appropriate policy for the interpretation of such alerts. 143 o Mobile telephone text message delivery, whether unicast or cell 144 broadcast, by the indicated operators, possibly other media such 145 as radio or television. 147 Each of these systems exists or could be made to exist. What is 148 necessary is implementation. 150 2.1 Warning Center 152 Research and Warning Centers exist in some parts of the world for 153 certain kinds of events. Generally speaking, they monitor seismic 154 activity or other appropriate indicators, and issue alerts to 155 interested parties. These alerts consist of web pages posted (such 156 as Figure 1), facsimile messages sent to appropriate parties, and so 157 on. 159 What is necessary to implement an alert system is a prediction of 160 what regions might be affected and approximately when. This may 161 entail development of simulations or other predictive tools at the 162 laboratories, to determine who needs an alert and what the alert 163 should say. Ideally, the alert should be simple, accurate, and 164 clear, such as: "coastal regions of may experience a 165 tsunami of magnitude between the hours of and 166 ". 168 .................. TSUNAMI INFORMATION BULLETIN .................. 169 ATTENTION: NOTE REVISED MAGNITUDE. 170 THIS MESSAGE IS FOR INFORMATION ONLY. THERE IS NO TSUNAMI WARNING 171 OR WATCH IN EFFECT. 172 AN EARTHQUAKE HAS OCCURRED WITH THESE PRELIMINARY PARAMETERS 173 ORIGIN TIME - 0059Z 26 DEC 2004 174 COORDINATES - 3.4 NORTH 95.7 EAST 175 LOCATION - OFF W COAST OF NORTHERN SUMATERA 176 MAGNITUDE - 8.5 177 EVALUATION 178 REVISED MAGNITUDE BASED ON ANALYSIS OF MANTLE WAVES. 179 THIS EARTHQUAKE IS LOCATED OUTSIDE THE PACIFIC. NO DESTRUCTIVE 180 TSUNAMI THREAT EXISTS FOR THE PACIFIC BASIN BASED ON HISTORICAL 181 EARTHQUAKE AND TSUNAMI DATA. 182 THERE IS THE POSSIBILITY OF A TSUNAMI NEAR THE EPICENTER. 183 THIS WILL BE THE ONLY BULLETIN ISSUED FOR THIS EVENT UNLESS 184 ADDITIONAL INFORMATION BECOMES AVAILABLE. 185 THE WEST COAST/ALASKA TSUNAMI WARNING CENTER WILL ISSUE BULLETINS 186 FOR ALASKA - BRITISH COLUMBIA - WASHINGTON - OREGON - CALIFORNIA. 187 ************************************************************** 189 Figure 1: Sample Warning Message 191 2.2 Distributing alerts to regional centers 193 There are many possible ways to distribute the message to regional 194 authorities. Traditional approaches include FAX, the World Wide Web, 195 and standard electronic mail. 197 2.2.1 Authenticated Electronic Mail 199 Delivery of such a message via the Internet can be accomplished in a 200 number of ways: mail, instant messaging, or other approaches. For 201 the present purpose, the simplest approach would seem to be the use 202 of the Simple Mail Transfer Protocol (SMTP) [RFC2821]. It requires, 203 in essence, the creation of appropriate mailing lists, perhaps 204 managed by the early Warning Centers themselves, of appropriate 205 contacts in government and service providers. Operationally, if the 206 operators prefer, another service could be used. 208 The great danger in such is that miscreants might send messages that 209 appear similar to the same targets, spoofing the source. Such an 210 event would severely damage the credibility and therefore the utility 211 of such a system. As such, it is critical that an authenticated 212 electronic mail message be used. Proof of authenticity might be 213 provided using facilities such as S/MIME [RFC3850][RFC3851] or PGP 214 [RFC3156]. 216 2.2.2 Polled delivery via the World Wide Web 218 WWW (http or https) may also be used on a polled basis to deliver 219 alerts. Such a system avoids many of the security issues mentioned 220 regarding electronic mail, but has two unfortunate properties: 221 polling must be sufficiently frequent to ensure timeliness of the 222 delivery of the alert, and the frequency presents a scaling issue. 224 An approach to this might be built using Really Simple Syndication 225 (RSS). This is a lightweight XML format designed for sharing 226 headlines and other Web content. Alert centers might use such a 227 system as a way to publish their alerts (Figure 1) permitting 228 receivers to trigger automated actions when they occur. 230 2.3 Warning Interpretation Policy 232 The receivers of the alert need to know what to do with it. This 233 necessarily requires human response. However, policies should be on 234 record indicating the appropriate response to likely alerts. An 235 example of such a policy might be: 237 "In the event that a tsunami alert is given of magnitude 238 exceeding , request mobile telephone operators 239 in the region to issue an SMS Broadcast in the cells along the 240 coast containing the text (in the local language) 'a tsunami 241 alert is in effect for this region between the hours of 242 and . For further information, contact <>'. In 243 addition, notify local authorities to evacuate the indicated 244 coastal regions." 246 The contact point should be a telephone number, Web URL, or other 247 appropriate information distribution vehicle. 249 2.4 Distribution of alert messages to the general population 251 The initial alert from the Warning Center is of necessity to a 252 limited audience: government, NGO, and private-sector service 253 organizations that consider the likely impact of the crisis and when 254 appropriate distribute the alert to the general population. The 255 objective is to issue accurate, practical, understandable, and timely 256 messages to the set of people who may be affected, and to limit 257 distribution to only those. 259 For practical reasons, it is most likely that the initial alert will 260 be distributed in the English language and directed to people who can 261 understand elementary English. Local re-distribution may of course 262 be more appropriate in the most widely understood local language. 263 Relevant standards for character set encoding, generally 264 unicode-based, should be used. It is suggested that the original, 265 probably English, version should be attached. In any case, simple 266 standard phrases should be used to assist comprehension. 268 The key consideration here is efficiently reaching people using 269 services that they are likely to be using. The most logical services 270 include those that provide some sense of locality and are likely to 271 be in active use. Examples of such services include: 273 Mobile Telephone Text Message Services (cell broadcast) 275 Broadcast services such as radio or television (regional 276 broadcast) 278 Presence-based services (subscription) 280 Message-based services (subscription) 282 2.4.1 Mobile Telephone Text Message Services 284 The GSM Short Message Service (SMS) provides the ability to send and 285 receive text messages to and from mobile telephones. The text can 286 comprise of words or numbers or an alphanumeric combination. SMS was 287 created as part of the GSM Phase 1 standard. Each short message is 288 up to 160 characters is length when Latin alphabets are used, and 70 289 characters in length when non-Latin alphabets such as Arabic and 290 Chinese are used. 292 Other mobile telephone services, such as CDMA and proprietary 293 systems, have similar capabilities, and there also exist various 294 paging services that may be useful. For the purposes of this 295 suggestion, these may be treated as equivalent, although the 296 technical aspects differ and interplay between them may require 297 careful consideration. 299 Mobile telephone text messages provide two important characteristics 300 for this type of service: 302 o The use of mobile telephones and pagers is very popular in most 303 parts of the world, and 305 o Unlike the Internet, such a service is inherently aware of 306 locality, as every active mobile telephone is registered in a 307 cell, which has locality. 309 Such a system includes the United States' Emergency Alert System, 310 which is a cell-broadcast-based text message system under 311 development. 313 2.4.2 Broadcast services such as radio or television (regional 314 broadcast) 316 Radio and TV broadcast signals can be modified or interrupted for 317 emergency alerts. Such systems include the US Emergency Broadcast 318 System, which is used to advise citizens of issues of national or 319 regional crisis, including the advance of severe storms. These have 320 the advantage that they are often active background noise, and 321 therefore can gain attention and distribute messages quickly. They 322 have the disadvantage that they do not actively solicit attention, 323 however; if the radio and TV are off, or the potential listener is 324 asleep or otherwise engaged, the message may be missed or ignored. 326 2.4.3 Presence-based services (subscription) 328 Internet services suffer in regard to a system of this type in that 329 the Internet conveys no knowledge of geographic location, only 330 topological location. However, one could imagine a service that 331 enabled a person (or their travel agent) to subscribe an Instant 332 Messaging "handle" for alerts within a specific region, and if the 333 handle happens to be "present" at when an alert is active would 334 deliver the alert to the user. 336 2.4.4 Message-based services (subscription) 338 Internet services suffer in regard to a system of this type in that 339 the Internet conveys no knowledge of geographic location, only 340 topological location. However, one could imagine a service that 341 enabled a person (or their travel agent) to subscribe an electronic 342 mail address for alerts within a specific region. If an alert is 343 presented for that region, the service would send an authenticated 344 electronic mail message recommending the user monitor the URL of the 345 appropriate Warning Center. 347 3. Implementing an alert service 349 It should be clear, at this point, how such a service would be 350 implemented, but let us recap. 352 Centers exist that monitor seismic activity and provide information 353 to appropriate response centers. These should be enhanced with 354 appropriate technology to predict the effects on appropriate regions, 355 such as "coastal regions of may experience a 356 tsunami of magnitude approximately hours after an 357 earthquake of magnitude in ." 359 These centers should send a signed electronic mail message to a 360 predetermined set of response centers. This predetermination is very 361 likely based on subscription: if someone wants to be told, they might 362 do well to say so, and there might be a cost involved. This message 363 should state the necessary information in terms of the type of event 364 predicted, the probable magnitude, and the time frame during which it 365 might occur. Having authenticated the message, receivers should 366 notify appropriate public and private parties to provide services as 367 needed, such as opening shelters or preparing to offer emergency 368 medical response, and should request mobile telephone operators to 369 notify subscribers whose telephones are registered in a specified 370 region. 372 The mobile telephone operators should interpret the region as a set 373 of mobile telephone cells. For example, "coastal regions" to them 374 constitute the set of mobile telephone cells nearest the coast. They 375 should then determine what telephones are registered in the indicated 376 cells, and send a specified message to each such telephone. 378 An unfortunate side-effect of such a service is that many people in a 379 region will get an alert of something that might not in fact require 380 any action on their part. A key part of the system would be some 381 indication of where people could go for further information. This 382 might be a URL for a web site, a telephone number where a recorded 383 message might be found, or other information source. 385 Radio and TV alerts should be similarly deployed, and presence-based 386 or message-based services should be similarly triggered. 388 4. Call to Action 390 There are a variety of calls to action that result here, and some 391 actions that are not required but may be advisable. 393 Alert centers for relevant types of disasters need to exist, and 394 lists of contact points must be negotiated. These are beyond the 395 scope of this note, but they are critical to it. 397 There is no requirement for new Internet standards at this time to 398 deploy a service. However, new standards such as a publish/subscribe 399 mechanism in electronic mail might make the tool easier to use, and 400 better tools for S/MIME or PGP use would assist in the use of the 401 system, especially mail tool implementations that automatically sign 402 and verify emails. 404 There is no requirement for new GSM/3GPP standards for deployment. 405 However, deployment of cell broadcast in regions it is not will make 406 the service easier to deploy. CDMA and Wideband CDMA do not at this 407 point support cell broadcast, but a similar service can be deployed 408 by determining the registration in a cell and sending unicast 409 messages to it. A key issue, though, is that SMS messages are often 410 significantly delayed experiencing delays of several hours, and in 411 some cases days. Messages sent from the same locality are frequently 412 not as delayed, but they too experience some variability in delivery 413 times. For this to be truly useful, delays in message delivery need 414 to be improved. 416 What is required is the organizational interlinking a service such as 417 we have described, and the focus on active alerts rather than 418 passive-or-no alerts. This may be a responsibility shouldered by 419 governments within a region, of employers, or of private 420 entrepreneurs; it will require partnership with mobile telephone 421 services at a minimum. 423 A problem with the prediction and alert related to geologic events is 424 that it is very difficult to tell the exact effect that a geological 425 event will have on the oceans, although the potential effects of 426 large geological events are more reliably predicted. What this 427 implies is that there is plenty of room for the funding of research 428 in prediction. 430 The stringent requirement for surety can be offset with frequent 431 training as evidenced by the U.S. Emergency Alert System. The 432 frequent tests alert the populace to the probability of an event 433 encouraging the populace to obtain further information from the local 434 news services. A simpler well rehearsed system is much more 435 effective than a complex infrequently tested one! 437 5. IANA Considerations 439 This document makes no request of the IANA. 441 Note to RFC Editor: in the process assigning numbers and building 442 IANA registries prior to publication, this section will have served 443 its purpose. It may therefore be removed upon publication as an RFC. 445 6. Security Considerations 447 The greatest concern this raises is not for the Internet, but for the 448 public and private services that might implement this procedure. The 449 system could be rendered useless if easily spoofed, as real alerts 450 might then be ignored among spoofed alerts. In addition, inaccurate 451 or spoofed alerts may result in human panic or avoidable loss of 452 property or life. 454 As a direct result, the use of an authenticated delivery service such 455 as authenticated mail is critical - the receiver of a alert must be 456 able to verify that the alert was sent by a trusted source, and the 457 trusted source must be worthy of that trust. 459 At this point, a system of this sort should not be completely 460 automated - it should have a human in the loop at critical points. 461 The reason is that while there is excellent science supporting this 462 sort of activity, it has not been reduced to a science. Not all 463 earthquakes result in tsunamis, and not all storm cells result in 464 cyclones. One wishes to ensure that predictions delivered to the 465 general public have a significant probability of proving accurate. 466 Therefore, public safety personnel trained and authorized to make 467 such decisions should be involved at the point where policy is 468 applied. 470 Consideration should be given to the management of the keys and 471 mailing lists used in such a system. They should be periodically 472 tested, to ensure that they are kept up to date and that the 473 supporting tools work properly. In the US, the phrase "this is a 474 test of the Emergency Broadcast System" is well known to consumers, 475 and the procedure it is part of constitutes such a test. It would 476 also be well for senders and receivers of authenticated messages to 477 use software that automates the signing and verification of messages, 478 as in the heat of the moment these steps may be overlooked. 480 7. Acknowledgements 482 This document was written using the XML2RFC document development 483 tool, and the XMLMind Editor with Bill Fenner's RFC development 484 plugins. 486 Suggestions were offered by a number of reviewers, including Bob 487 Hinden, Bob Wyman, Dale Barr, Harald Tveit Alvestrand, James Seng, 488 Jonathan Rosenberg, Leslie Daigle, Ned Freed, Paul Hoffman, Rob 489 Austein, Sally Floyd, and Ted Hardie. These were of course helpful 490 and greatly appreciated. 492 8. References 494 8.1 SMTP Specifications (for information) 496 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", 497 BCP 30, RFC 2505, February 1999. 499 [RFC2554] Myers, J., "SMTP Service Extension for Authentication", 500 RFC 2554, March 1999. 502 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 503 April 2001. 505 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 506 of Large and Binary MIME Messages", RFC 3030, December 507 2000. 509 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 510 Transport Layer Security", RFC 3207, February 2002. 512 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 513 Extension for Delivery Status Notifications (DSNs)", RFC 514 3461, January 2003. 516 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types 517 Registration", RFC 3848, July 2004. 519 [RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for 520 Message Tracking", RFC 3885, September 2004. 522 8.2 S/MIME specifications (for information) 524 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 525 2634, June 1999. 527 [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 528 Attacks on the Diffie-Hellman Key Agreement Method for 529 S/MIME", RFC 2785, March 2000. 531 [RFC3114] Nicolls, W., "Implementing Company Classification Policy 532 with the S/MIME Security Label", RFC 3114, May 2002. 534 [RFC3183] Dean, T. and W. Ottaway, "Domain Security Services using 535 S/MIME", RFC 3183, October 2001. 537 [RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail 538 Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 539 3850, July 2004. 541 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 542 Extensions (S/MIME) Version 3.1 Message Specification", 543 RFC 3851, July 2004. 545 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 546 Requirement for the Session Initiation Protocol (SIP)", 547 RFC 3853, July 2004. 549 8.3 PGP Specifications (for information) 551 [RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message 552 Exchange Formats", RFC 1991, August 1996. 554 [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy 555 (PGP)", RFC 2015, October 1996. 557 [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, 558 "OpenPGP Message Format", RFC 2440, November 1998. 560 [RFC3156] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, 561 "MIME Security with OpenPGP", RFC 3156, August 2001. 563 8.4 Telephony specifications and references (for information) 565 [ETSI.TS.44.012] 566 European Technology Standards Institute (ETSI), "Short 567 Message Service Cell Broadcast (SMSCB) support on the 568 mobile radio interface", ETSI TS 44.012, 2001. 570 [NDIS] Telecommunications Industry Association, "Effective 571 Disaster alerts. Working Group on Natural Disaster 572 Information Systems", 2000. 574 [TIA-136-630] 575 Telecommunications Industry Association, "Broadcast 576 Teleservice Transport - Broadcast Air Interface Transport 577 Service (BATS)", TIA/EIA TIA/EIA-136-630, 1999. 579 Authors' Addresses 581 Fred Baker 582 Cisco Systems 583 1121 Via Del Rey 584 Santa Barbara, California 93117 585 USA 587 EMail: fred@cisco.com 588 Brian Carpenter 589 IBM Corporation 590 Sauemerstrasse 4 591 8803 Rueschlikon 592 Switzerland 594 EMail: brc@zurich.ibm.com 596 Appendix A. I am Alive 598 In Japan, there is a service intended to help people who have been 599 affected by a disaster to comfort those who are concerned about them; 600 this is called the "I am Alive" service. In essence, it provides a 601 database in which a victim may post a brief note indicating their 602 status and plans, or a concerned party may register concern, and they 603 can be told about each other even though they are temporarily unable 604 to directly communicate. An overview of the service may be found at 605 http://www.isoc.org/inet2000/cdproceedings/8l/8l_3.htm. 607 Similar services may be of value in other places. If such exist, it 608 would be helpful if either the message announcing the alert or a 609 subsequent message after the event indicated how to easily access the 610 service. 612 Appendix B. Common Alerting Protocol 614 OASIS has developed an XML-based protocol for distributing alerts, 615 called the "Common Alerting Protocol". CAP is getting significant 616 traction in the realms of Homeland Security, Emergency Manager's 617 organizations, etc. Additional information on CAP may be found at: 618 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency. 619 The CAP V1.0 "standard" may be found at: 620 http://www.oasis-open.org/committees/download.php/6334/oasis-200402-c 621 ap-core-1.0.pdf. 623 Intellectual Property Statement 625 The IETF takes no position regarding the validity or scope of any 626 Intellectual Property Rights or other rights that might be claimed to 627 pertain to the implementation or use of the technology described in 628 this document or the extent to which any license under such rights 629 might or might not be available; nor does it represent that it has 630 made any independent effort to identify any such rights. Information 631 on the procedures with respect to rights in RFC documents can be 632 found in BCP 78 and BCP 79. 634 Copies of IPR disclosures made to the IETF Secretariat and any 635 assurances of licenses to be made available, or the result of an 636 attempt made to obtain a general license or permission for the use of 637 such proprietary rights by implementers or users of this 638 specification can be obtained from the IETF on-line IPR repository at 639 http://www.ietf.org/ipr. 641 The IETF invites any interested party to bring to its attention any 642 copyrights, patents or patent applications, or other proprietary 643 rights that may cover technology that may be required to implement 644 this standard. Please address the information to the IETF at 645 ietf-ipr@ietf.org. 647 Disclaimer of Validity 649 This document and the information contained herein are provided on an 650 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 651 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 652 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 653 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 654 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 655 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 657 Copyright Statement 659 Copyright (C) The Internet Society (2005). This document is subject 660 to the rights, licenses and restrictions contained in BCP 78, and 661 except as set forth therein, the authors retain all their rights. 663 Acknowledgment 665 Funding for the RFC Editor function is currently provided by the 666 Internet Society.