Network Working Group                                           F. Baker
Internet-Draft                                             Cisco Systems
Expires: July 11, 2005                                      B. Carpenter
                                                         IBM Corporation
                                                        January 10, 2005


          Structure of an International Emergency Alert System
                      draft-baker-alert-system-00

Status of this Memo

   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 become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 11, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The authors propose a way in which people could be warned of an
   impending event in a geographic region.  This is similar to and may
   use services such as the US Emergency Alert System, but differs in
   that message distribution is targeted only to the affected locality.





Baker & Carpenter        Expires July 11, 2005                  [Page 1]


Internet-Draft         International Alert System           January 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Facilities the proposal depends on . . . . . . . . . . . . . .  4
     2.1   Warning Center . . . . . . . . . . . . . . . . . . . . . .  4
     2.2   Distributing alerts to regional centers  . . . . . . . . .  5
       2.2.1   Authenticated Electronic Mail  . . . . . . . . . . . .  5
       2.2.2   Polled delivery via the World Wide Web . . . . . . . .  6
     2.3   Warning Interpretation Policy  . . . . . . . . . . . . . .  6
     2.4   Distribution of alert messages to the general
           population . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.4.1   Mobile Telephone Text Message Services . . . . . . . .  7
       2.4.2   Broadcast services such as radio or television
               (regional broadcast) . . . . . . . . . . . . . . . . .  8
       2.4.3   Presence-based services (subscription) . . . . . . . .  8
       2.4.4   Message-based services (subscription)  . . . . . . . .  8

   3.  Implementing an alert service  . . . . . . . . . . . . . . . .  9

   4.  Call to Action . . . . . . . . . . . . . . . . . . . . . . . . 10

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.1   SMTP Specifications (for information)  . . . . . . . . . . . 14
   8.2   S/MIME specifications (for information)  . . . . . . . . . . 14
   8.3   PGP Specifications (for information) . . . . . . . . . . . . 15
   8.4   Telephony specifications and references (for information)  . 15

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15

   A.  I am Alive . . . . . . . . . . . . . . . . . . . . . . . . . . 17

   B.  Common Alerting Protocol . . . . . . . . . . . . . . . . . . . 18

       Intellectual Property and Copyright Statements . . . . . . . . 19










Baker & Carpenter        Expires July 11, 2005                  [Page 2]


Internet-Draft         International Alert System           January 2005


1.  Introduction

   The earthquake near Sumatra and subsequent tsunami throughout the
   Indian Ocean on 26 December 2004 resulted in a large number of
   deaths; early estimates suggest six digit figures, with the hardest
   hit being remote regions of Sumatra.  In the aftermath of this event,
   many countries have sent aid of various kinds, and the Internet
   community has asked itself whether the Internet might have been used
   to help.

   This note proposes a system that could be used to quickly warn people
   in an identified geographic region of an impending event, such as a
   tsunami, hurricane or typhoon, or attack.  It builds on existing
   technologies that are presently used for other purposes: given a
   alert from an appropriate Warning Center, the Internet (using, for
   example, Internet Mail and S/MIME) could be used to deliver an
   authenticated message to a set of mobile telephone operators, who in
   turn could send an SMS broadcast to mobile telephones in affected
   regions, alert of the event.  The same email could trigger public and
   private organizations to initiate necessary support services such as
   evacuation orders or provision of shelter and emergency medical
   response.  Such an approach would, of course, not warn everyone -
   everyone does not carry a mobile telephone, and everyone who does
   would not necessarily read it.  But it would warn a large percentage,
   which might help.

   This is similar to and may use services such as the US Emergency
   Alert System.  The Emergency Alert System (EAS) is the national alert
   system designed primarily to allow the President to address the
   nation reliably during major national disasters, using media such as
   television, radio, and potentially mobile telephone in the future.
   It differs in that message distribution is targeted only to the
   affected locality, such as the mobile telephone cells in a given
   city, along a coastline, or along the projected path of a storm, and
   actively reaches out to its audience rather than depending on them
   being passively watching at the time.















Baker & Carpenter        Expires July 11, 2005                  [Page 3]


Internet-Draft         International Alert System           January 2005


2.  Facilities the proposal depends on

   The proposal depends on the existence and use of four fundamental
   types of systems:

   o  An Warning Center, such as the NOAA Pacific Tsunami alert Center
      (http://www.prh.noaa.gov/ptwc/) or the US Geological Survey
      Earthquake Hazards Program (http://neic.usgs.gov/neis/bulletin/).

   o  A mailing list of people interested in alerts from the alert
      center, with internet connectivity and continuous monitoring of
      such alerts.

   o  An appropriate policy for the interpretation of such alerts.

   o  Mobile telephone text message delivery, whether unicast or cell
      broadcast, by the indicated operators, possibly other media such
      as radio or television.

   Each of these systems exists or could be made to exist.  What is
   necessary is implementation.

2.1  Warning Center

   Research and Warning Centers exist in some parts of the world for
   certain kinds of events.  Generally speaking, they monitor seismic
   activity or other appropriate indicators, and issue alerts to
   interested parties.  These alerts consist of web pages posted (such
   as Figure 1), facsimile messages sent to appropriate parties, and so
   on.

   What is necessary to implement an alert system is a prediction of
   what regions might be affected and approximately when.  This may
   entail development of simulations or other predictive tools at the
   laboratories, to determine who needs an alert and what the alert
   should say.  Ideally, the alert should be simple, accurate, and
   clear, such as: "coastal regions of <your country> may experience a
   tsunami of <a stated> magnitude between the hours of <start> and
   <finish>".












Baker & Carpenter        Expires July 11, 2005                  [Page 4]


Internet-Draft         International Alert System           January 2005


   .................. TSUNAMI INFORMATION BULLETIN ..................
   ATTENTION: NOTE REVISED MAGNITUDE.
   THIS MESSAGE IS FOR INFORMATION ONLY. THERE IS NO TSUNAMI WARNING
   OR WATCH IN EFFECT.
   AN EARTHQUAKE HAS OCCURRED WITH THESE PRELIMINARY PARAMETERS
    ORIGIN TIME -  0059Z 26 DEC 2004
    COORDINATES -   3.4 NORTH   95.7 EAST
    LOCATION    -  OFF W COAST OF NORTHERN SUMATERA
    MAGNITUDE   -  8.5
   EVALUATION
    REVISED MAGNITUDE BASED ON ANALYSIS OF MANTLE WAVES.
    THIS EARTHQUAKE IS LOCATED OUTSIDE THE PACIFIC. NO DESTRUCTIVE
    TSUNAMI THREAT EXISTS FOR THE PACIFIC BASIN BASED ON HISTORICAL
    EARTHQUAKE AND TSUNAMI DATA.
    THERE IS THE POSSIBILITY OF A TSUNAMI NEAR THE EPICENTER.
   THIS WILL BE THE ONLY BULLETIN ISSUED FOR THIS EVENT UNLESS
   ADDITIONAL INFORMATION BECOMES AVAILABLE.
   THE WEST COAST/ALASKA TSUNAMI WARNING CENTER WILL ISSUE BULLETINS
   FOR ALASKA - BRITISH COLUMBIA - WASHINGTON - OREGON - CALIFORNIA.
   **************************************************************

                    Figure 1: Sample Warning Message


2.2  Distributing alerts to regional centers

   There are many possible ways to distribute the message to regional
   authorities.  Traditional approaches include FAX, the World Wide Web,
   and standard electronic mail.

2.2.1  Authenticated Electronic Mail

   Delivery of such a message via the Internet can be accomplished in a
   number of ways: mail, instant messaging, or other approaches.  For
   the present purpose, the simplest approach would seem to be the use
   of the Simple Mail Transfer Protocol (SMTP) [RFC2821].  It requires,
   in essence, the creation of appropriate mailing lists, perhaps
   managed by the early Warning Centers themselves, of appropriate
   contacts in government and service providers.  Operationally, if the
   operators prefer, another service could be used.

   The great danger in such is that miscreants might send messages that
   appear similar to the same targets, spoofing the source.  Such an
   event would severely damage the credibility and therefore the utility
   of such a system.  As such, it is critical that an authenticated
   electronic mail message be used.  Proof of authenticity might be
   provided using facilities such as S/MIME [RFC3850][RFC3851] or PGP
   [RFC3156].



Baker & Carpenter        Expires July 11, 2005                  [Page 5]


Internet-Draft         International Alert System           January 2005


2.2.2  Polled delivery via the World Wide Web

   WWW (http or https) may also be used on a polled basis to deliver
   alerts.  Such a system avoids many of the security issues mentioned
   regarding electronic mail, but has two unfortunate properties:
   polling must be sufficiently frequent to ensure timeliness of the
   delivery of the alert, and the frequency presents a scaling issue.

   An approach to this might be built using Really Simple Syndication
   (RSS).  This is a lightweight XML format designed for sharing
   headlines and other Web content.  Alert centers might use such a
   system as a way to publish their alerts (Figure 1) permitting
   receivers to trigger automated actions when they occur.

2.3  Warning Interpretation Policy

   The receivers of the alert need to know what to do with it.  This
   necessarily requires human response.  However, policies should be on
   record indicating the appropriate response to likely alerts.  An
   example of such a policy might be:

        "In the event that a tsunami alert is given of magnitude
        exceeding <a stated value>, request mobile telephone operators
        in the region to issue an SMS Broadcast in the cells along the
        coast containing the text (in the local language) 'a tsunami
        alert is in effect for this region between the hours of <start>
        and <finish>.  For further information, contact <>'.  In
        addition, notify local authorities to evacuate the indicated
        coastal regions."

   The contact point should be a telephone number, Web URL, or other
   appropriate information distribution vehicle.

2.4  Distribution of alert messages to the general population

   The initial alert from the Warning Center is of necessity to a
   limited audience: government, NGO, and private-sector service
   organizations that consider the likely impact of the crisis and when
   appropriate distribute the alert to the general population.  The
   objective is to issue accurate, practical, understandable, and timely
   messages to the set of people who may be affected, and to limit
   distribution to only those.

   For practical reasons, it is most likely that the initial alert will
   be distributed in the English language and directed to people who can
   understand elementary English.  Local re-distribution may of course
   be more appropriate in the most widely understood local language.
   Relevant standards for character set encoding, generally



Baker & Carpenter        Expires July 11, 2005                  [Page 6]


Internet-Draft         International Alert System           January 2005


   unicode-based, should be used.  It is suggested that the original,
   probably English, version should be attached.  In any case, simple
   standard phrases should be used to assist comprehension.

   The key consideration here is efficiently reaching people using
   services that they are likely to be using.  The most logical services
   include those that provide some sense of locality and are likely to
   be in active use.  Examples of such services include:

      Mobile Telephone Text Message Services (cell broadcast)

      Broadcast services such as radio or television (regional
      broadcast)

      Presence-based services (subscription)

      Message-based services (subscription)


2.4.1  Mobile Telephone Text Message Services

   The GSM Short Message Service (SMS) provides the ability to send and
   receive text messages to and from mobile telephones.  The text can
   comprise of words or numbers or an alphanumeric combination.  SMS was
   created as part of the GSM Phase 1 standard.  Each short message is
   up to 160 characters is length when Latin alphabets are used, and 70
   characters in length when non-Latin alphabets such as Arabic and
   Chinese are used.

   Other mobile telephone services, such as CDMA and proprietary
   systems, have similar capabilities, and there also exist various
   paging services that may be useful.  For the purposes of this
   suggestion, these may be treated as equivalent, although the
   technical aspects differ and interplay between them may require
   careful consideration.

   Mobile telephone text messages provide two important characteristics
   for this type of service:

   o  The use of mobile telephones and pagers is very popular in most
      parts of the world, and

   o  Unlike the Internet, such a service is inherently aware of
      locality, as every active mobile telephone is registered in a
      cell, which has locality.

   Such a system includes the United States' Emergency Alert System,
   which is a cell-broadcast-based text message system under



Baker & Carpenter        Expires July 11, 2005                  [Page 7]


Internet-Draft         International Alert System           January 2005


   development.

2.4.2  Broadcast services such as radio or television (regional
      broadcast)

   Radio and TV broadcast signals can be modified or interrupted for
   emergency alerts.  Such systems include the US Emergency Broadcast
   System, which is used to advise citizens of issues of national or
   regional crisis, including the advance of severe storms.  These have
   the advantage that they are often active background noise, and
   therefore can gain attention and distribute messages quickly.  They
   have the disadvantage that they do not actively solicit attention,
   however; if the radio and TV are off, or the potential listener is
   asleep or otherwise engaged, the message may be missed or ignored.

2.4.3  Presence-based services (subscription)

   Internet services suffer in regard to a system of this type in that
   the Internet conveys no knowledge of geographic location, only
   topological location.  However, one could imagine a service that
   enabled a person (or their travel agent) to subscribe an Instant
   Messaging "handle" for alerts within a specific region, and if the
   handle happens to be "present" at when an alert is active would
   deliver the alert to the user.

2.4.4  Message-based services (subscription)

   Internet services suffer in regard to a system of this type in that
   the Internet conveys no knowledge of geographic location, only
   topological location.  However, one could imagine a service that
   enabled a person (or their travel agent) to subscribe an electronic
   mail address for alerts within a specific region.  If an alert is
   presented for that region, the service would send an authenticated
   electronic mail message recommending the user monitor the URL of the
   appropriate Warning Center.
















Baker & Carpenter        Expires July 11, 2005                  [Page 8]


Internet-Draft         International Alert System           January 2005


3.  Implementing an alert service

   It should be clear, at this point, how such a service would be
   implemented, but let us recap.

   Centers exist that monitor seismic activity and provide information
   to appropriate response centers.  These should be enhanced with
   appropriate technology to predict the effects on appropriate regions,
   such as "coastal regions of <a stated country> may experience a
   tsunami of <a stated> magnitude approximately <N> hours after an
   earthquake of <a stated> magnitude in <a stated place>."

   These centers should send a signed electronic mail message to a
   predetermined set of response centers.  This predetermination is very
   likely based on subscription: if someone wants to be told, they might
   do well to say so, and there might be a cost involved.  This message
   should state the necessary information in terms of the type of event
   predicted, the probable magnitude, and the time frame during which it
   might occur.  Having authenticated the message, receivers should
   notify appropriate public and private parties to provide services as
   needed, such as opening shelters or preparing to offer emergency
   medical response, and should request mobile telephone operators to
   notify subscribers whose telephones are registered in a specified
   region.

   The mobile telephone operators should interpret the region as a set
   of mobile telephone cells.  For example, "coastal regions" to them
   constitute the set of mobile telephone cells nearest the coast.  They
   should then determine what telephones are registered in the indicated
   cells, and send a specified message to each such telephone.

   An unfortunate side-effect of such a service is that many people in a
   region will get an alert of something that might not in fact require
   any action on their part.  A key part of the system would be some
   indication of where people could go for further information.  This
   might be a URL for a web site, a telephone number where a recorded
   message might be found, or other information source.

   Radio and TV alerts should be similarly deployed, and presence-based
   or message-based services should be similarly triggered.











Baker & Carpenter        Expires July 11, 2005                  [Page 9]


Internet-Draft         International Alert System           January 2005


4.  Call to Action

   There are a variety of calls to action that result here, and some
   actions that are not required but may be advisable.

   Alert centers for relevant types of disasters need to exist, and
   lists of contact points must be negotiated.  These are beyond the
   scope of this note, but they are critical to it.

   There is no requirement for new Internet standards at this time to
   deploy a service.  However, new standards such as a publish/subscribe
   mechanism in electronic mail might make the tool easier to use, and
   better tools for S/MIME or PGP use would assist in the use of the
   system, especially mail tool implementations that automatically sign
   and verify emails.

   There is no requirement for new GSM/3GPP standards for deployment.
   However, deployment of cell broadcast in regions it is not will make
   the service easier to deploy.  CDMA and Wideband CDMA do not at this
   point support cell broadcast, but a similar service can be deployed
   by determining the registration in a cell and sending unicast
   messages to it.  A key issue, though, is that SMS messages are often
   significantly delayed experiencing delays of several hours, and in
   some cases days.  Messages sent from the same locality are frequently
   not as delayed, but they too experience some variability in delivery
   times.  For this to be truly useful, delays in message delivery need
   to be improved.

   What is required is the organizational interlinking a service such as
   we have described, and the focus on active alerts rather than
   passive-or-no alerts.  This may be a responsibility shouldered by
   governments within a region, of employers, or of private
   entrepreneurs; it will require partnership with mobile telephone
   services at a minimum.

   A problem with the prediction and alert related to geologic events is
   that it is very difficult to tell the exact effect that a geological
   event will have on the oceans, although the potential effects of
   large geological events are more reliably predicted.  What this
   implies is that there is plenty of room for the funding of research
   in prediction.

   The stringent requirement for surety can be offset with frequent
   training as evidenced by the U.S.  Emergency Alert System.  The
   frequent tests alert the populace to the probability of an event
   encouraging the populace to obtain further information from the local
   news services.  A simpler well rehearsed system is much more
   effective than a complex infrequently tested one!



Baker & Carpenter        Expires July 11, 2005                 [Page 10]


Internet-Draft         International Alert System           January 2005


5.  IANA Considerations

   This document makes no request of the IANA.

   Note to RFC Editor: in the process assigning numbers and building
   IANA registries prior to publication, this section will have served
   its purpose.  It may therefore be removed upon publication as an RFC.












































Baker & Carpenter        Expires July 11, 2005                 [Page 11]


Internet-Draft         International Alert System           January 2005


6.  Security Considerations

   The greatest concern this raises is not for the Internet, but for the
   public and private services that might implement this procedure.  The
   system could be rendered useless if easily spoofed, as real alerts
   might then be ignored among spoofed alerts.  In addition, inaccurate
   or spoofed alerts may result in human panic or avoidable loss of
   property or life.

   As a direct result, the use of an authenticated delivery service such
   as authenticated mail is critical - the receiver of a alert must be
   able to verify that the alert was sent by a trusted source, and the
   trusted source must be worthy of that trust.

   At this point, a system of this sort should not be completely
   automated - it should have a human in the loop at critical points.
   The reason is that while there is excellent science supporting this
   sort of activity, it has not been reduced to a science.  Not all
   earthquakes result in tsunamis, and not all storm cells result in
   cyclones.  One wishes to ensure that predictions delivered to the
   general public have a significant probability of proving accurate.
   Therefore, public safety personnel trained and authorized to make
   such decisions should be involved at the point where policy is
   applied.

   Consideration should be given to the management of the keys and
   mailing lists used in such a system.  They should be periodically
   tested, to ensure that they are kept up to date and that the
   supporting tools work properly.  In the US, the phrase "this is a
   test of the Emergency Broadcast System" is well known to consumers,
   and the procedure it is part of constitutes such a test.  It would
   also be well for senders and receivers of authenticated messages to
   use software that automates the signing and verification of messages,
   as in the heat of the moment these steps may be overlooked.

















Baker & Carpenter        Expires July 11, 2005                 [Page 12]


Internet-Draft         International Alert System           January 2005


7.  Acknowledgements

   This document was written using the XML2RFC document development
   tool, and the XMLMind Editor with Bill Fenner's RFC development
   plugins.

   Suggestions were offered by a number of reviewers, including Bob
   Hinden, Bob Wyman, Dale Barr, Harald Tveit Alvestrand, James Seng,
   Jonathan Rosenberg, Leslie Daigle, Ned Freed, Paul Hoffman, Rob
   Austein, Sally Floyd, and Ted Hardie.  These were of course helpful
   and greatly appreciated.








































Baker & Carpenter        Expires July 11, 2005                 [Page 13]


Internet-Draft         International Alert System           January 2005


8.  References

8.1  SMTP Specifications (for information)

   [RFC2505]  Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs",
              BCP 30, RFC 2505, February 1999.

   [RFC2554]  Myers, J., "SMTP Service Extension for Authentication",
              RFC 2554, March 1999.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC3030]  Vaudreuil, G., "SMTP Service Extensions for Transmission
              of Large and Binary MIME Messages", RFC 3030, December
              2000.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)", RFC
              3461, January 2003.

   [RFC3848]  Newman, C., "ESMTP and LMTP Transmission Types
              Registration", RFC 3848, July 2004.

   [RFC3885]  Allman, E. and T. Hansen, "SMTP Service Extension for
              Message Tracking", RFC 3885, September 2004.

8.2  S/MIME specifications (for information)

   [RFC2634]  Hoffman, P., "Enhanced Security Services for S/MIME", RFC
              2634, June 1999.

   [RFC2785]  Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
              Attacks on the Diffie-Hellman Key Agreement Method for
              S/MIME", RFC 2785, March 2000.

   [RFC3114]  Nicolls, W., "Implementing Company Classification Policy
              with the S/MIME Security Label", RFC 3114, May 2002.

   [RFC3183]  Dean, T. and W. Ottaway, "Domain Security Services using
              S/MIME", RFC 3183, October 2001.

   [RFC3850]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Certificate Handling", RFC
              3850, July 2004.



Baker & Carpenter        Expires July 11, 2005                 [Page 14]


Internet-Draft         International Alert System           January 2005


   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, July 2004.

   [RFC3853]  Peterson, J., "S/MIME Advanced Encryption Standard (AES)
              Requirement for the Session Initiation Protocol (SIP)",
              RFC 3853, July 2004.

8.3  PGP Specifications (for information)

   [RFC1991]  Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message
              Exchange Formats", RFC 1991, August 1996.

   [RFC2015]  Elkins, M., "MIME Security with Pretty Good Privacy
              (PGP)", RFC 2015, October 1996.

   [RFC2440]  Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
              "OpenPGP Message Format", RFC 2440, November 1998.

   [RFC3156]  Elkins, M., Del Torto, D., Levien, R. and T. Roessler,
              "MIME Security with OpenPGP", RFC 3156, August 2001.

8.4  Telephony specifications and references (for information)

   [ETSI.TS.44.012]
              European Technology Standards Institute (ETSI), "Short
              Message Service Cell Broadcast (SMSCB) support on the
              mobile radio interface", ETSI TS 44.012, 2001.

   [NDIS]     Telecommunications Industry Association, "Effective
              Disaster alerts. Working Group on Natural Disaster
              Information Systems", 2000.

   [TIA-136-630]
              Telecommunications Industry Association, "Broadcast
              Teleservice Transport - Broadcast Air Interface Transport
              Service (BATS)", TIA/EIA TIA/EIA-136-630, 1999.


Authors' Addresses

   Fred Baker
   Cisco Systems
   1121 Via Del Rey
   Santa Barbara, California  93117
   USA

   EMail: fred@cisco.com



Baker & Carpenter        Expires July 11, 2005                 [Page 15]


Internet-Draft         International Alert System           January 2005


   Brian Carpenter
   IBM Corporation
   Sauemerstrasse 4
   8803 Rueschlikon
   Switzerland

   EMail: brc@zurich.ibm.com












































Baker & Carpenter        Expires July 11, 2005                 [Page 16]


Internet-Draft         International Alert System           January 2005


Appendix A.  I am Alive

   In Japan, there is a service intended to help people who have been
   affected by a disaster to comfort those who are concerned about them;
   this is called the "I am Alive" service.  In essence, it provides a
   database in which a victim may post a brief note indicating their
   status and plans, or a concerned party may register concern, and they
   can be told about each other even though they are temporarily unable
   to directly communicate.  An overview of the service may be found at
   http://www.isoc.org/inet2000/cdproceedings/8l/8l_3.htm.

   Similar services may be of value in other places.  If such exist, it
   would be helpful if either the message announcing the alert or a
   subsequent message after the event indicated how to easily access the
   service.




































Baker & Carpenter        Expires July 11, 2005                 [Page 17]


Internet-Draft         International Alert System           January 2005


Appendix B.  Common Alerting Protocol

   OASIS has developed an XML-based protocol for distributing alerts,
   called the "Common Alerting Protocol".  CAP is getting significant
   traction in the realms of Homeland Security, Emergency Manager's
   organizations, etc.  Additional information on CAP may be found at:
   http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency.
   The CAP V1.0 "standard" may be found at:
   http://www.oasis-open.org/committees/download.php/6334/oasis-200402-c
   ap-core-1.0.pdf.









































Baker & Carpenter        Expires July 11, 2005                 [Page 18]


Internet-Draft         International Alert System           January 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Baker & Carpenter        Expires July 11, 2005                 [Page 19]