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]