Automatic Crash Notification (ACN) Initiative

The ComCARE Alliance ACN Data Set Working Group has published a draft XML-based ACN data standard for the "Vehicular Emergency Incident Data Exchange Format." It is not designed as a data transmission protocol, but as a recommended data exchange format. The draft standard is being developed in accordance with the recommendations of the National Mayday Readiness Initiative (NMRI)... Currently, when Telematics Service Providers (TSPs), such as OnStar and ATX Technologies, receive location and/or ACN data into their systems, they verbally relay the information to emergency responders. The goal of creating this standard is to provide TSPs a means to distribute data electronically to multiple responders. The draft ACN standard is the first step in a process to enable the electronic flow of information from a TSP to multiple public safety agencies, including 9-1-1 centers, hospitals, transportation agencies and emergency responders dispatched to an accident scene. A uniform standard is a critical element to allow for the introduction of electronic data into the emergency response system. In order to provide a complete picture of what elements were needed in this standard, ComCARE has coordinated a diverse committee from its member organizations, which includes: Acuo Technologies, the Association of Public-Safety Communications Officials International (APCO), ATX Technologies, the California Highway Patrol, Centurion Solutions, ESRI, Gannett Fleming, Intel Corporation, InterTrak Tracking Services, Medical Priority, the National Academies of Emergency Dispatch, the National Association of State EMS Directors, the National Emergency Number Association (NENA), OnStar, Response Services Center (AAA), Roadside Telematics Corporation, Televoke, Valley Health System, and the Virginia Division of Emergency Communications..."

Creation of the XML DTD/Schema: "The first phase of the process focused on developing a comprehensive list of data elements for the data set. The group formally published the initial list of data elements for comment and incorporated such comments into an XML DTD (document type definition) file. The XML dtd was a list of all elements within the data set, but it did not indicate specific formats and units of measurement that are required for each element. The next phase of the working group was to define specific data formats and relationships among the elements and move the document from a dtd file to an XML schema. To that end, the ACN Data Set Working Group formed three subcommittees to address particular sections of the data set. The subcommittees were as follows:

• Incident Data Subcommittee: This group addressed general incident information, such as latitude and longitude, source information, and public safety agency information. Barb Thornburg, NENA Data Committee Chair, chaired this subcommittee.
• Vehicle Data Subcommittee: This group addressed vehicle data of all types, including commercial vehicles, such as vehicle type, license number, airbag data, seatbelt data, etc. Jasmin Jijina, General Motors/OnStar Senior Engineering Associate, chaired this subcommittee.
• Medical and Crash Data Subcommittee: This group addressed the medical and crash data elements of the data set, such as occupant breathing, occupant age, delta velocity, crash pulse, personal medical data, etc. Dr. Greg Mears, EMS Medical Director for the State of North Carolina and board member of the State EMS Directors chaired this subcommittee. [from the Overview]

"The ComCARE Alliance is a broad-based national coalition of more than 80 organizations that includes nurses, physicians, emergency medical technicians, 9-1-1 directors, wireless companies, public safety and health officials, law enforcement groups, automobile companies, consumer organizations, telematics suppliers, safety groups, and others who are working to encourage the deployment of life saving wireless communications networks and technologies that will more efficiently connect America's mobile public to emergency agencies. The goal of the ComCARE Alliance is to promote a comprehensive "end-to-end system" to enhance public safety. This system includes initiatives aimed at preventing motor vehicle fatalities, developing ubiquitous wireless enhanced 9-1-1 systems, automatically sending a wireless emergency call with enhanced data and information to the appropriate emergency personnel following a vehicle crash, and providing more timely, appropriate responses to crashes and other emergencies. This "chain of survival" includes linking existing technology - smart cars equipped with telematics, wireless telecommunications, intelligent transportation applications, and advanced emergency care - to respond to life threatening situations. This effort will save a significant number of lives each year and reduce the severity of injuries..."

• ACN Initiative website
• ACN Draft Standard
• "Recommended Vehicular Emergency Incident Data Exchange Format." From the ComCare Alliance. October 2002. 6 pages. [cache]
• "ComCARE Alliance Publishes XML-Based Emergency Incident Data Set Recommendation"
• "Comcare Working Group Submits Vehicular Emergency Incident Data Set To Other Groups." Announcement 2002-11-12.
• ACN XML DTD [cache]
• ACN XML DTD annotated
• "ACN Data Set Working Group" - Overview of work in ComCARE Insider May 2002.
• About ACN

Common Alerting Protocol (CAP)

The Common Alerting Protocol "is an open, non-proprietary standard data interchange format that can be used to collect all types of hazard warnings and reports locally, regionally and nationally, for input into a wide range of information-management and warning dissemination systems. The specification has been under development since 2001 through the efforts of an international ad-hoc Common Alerting Protocol Technical Working Group composed of technical and public safety experts. The developers have implemented the protocol in a number of prototype demonstrations. The chief benefits for public safety include (1) better coordination of warnings to the public across the wide range of available warning and notification systems; (2) reduction of workload on warning issuers, since a single warning message is compatible with all kinds of warning delivery systems; (3) enhanced situational awareness, since CAP will permit the aggregation of all kinds of warning messages from all sources for comparison and pattern recognition."

• CAP website
• CAP Version 0.7, March 07, 2003:
  • Data Dictionary. [cache]
  • Message Diagram
  • XML Schema [cache]
• "OASIS Standardizes Emergency Data Exchange Language (EDXL) Specifications."
• CAP Cookbook. "A collection of application notes, supporting documents and commentaries about the Common Alerting Protocol. This is a wiki, a collaborative editing environment, which means that the documents here are undergoing editing and revision by a variety of authors." The use of this resource is not restricted to OASIS members, as explained in the announcement.
• "Common Alerting Protocol (CAP) Provides XML Interchange Format for Public Safety Reports."

Common Intrusion Detection Signatures Standard (CIDSS)

"The purpose of the Common Intrusion Detection Signatures Standard (CIDSS) is to define a common data format for storing signatures from different intrusion detection systems. This Internet-Draft describes a common data format to represent information contained in signatures of intrusion detection systems, and explains the rationale for using this common format. The proposed format is a dialect of the Extensible Markup Language (XML). An XML Document Type Definition is developed, and examples are provided." [abstract from the Internet Draft]

The specification and IDS Signature Translator tool have been developed at the Polish-Japanese Institute of Information Technology under the direction of Adam Wierzbicki. As of 2004-11 "the translator was able to translate signatures of Snort and Dragon IDS into the common format; it has also been partially tested with Shoki, ISS RealSecure, and Cisco NetRanger."

• "Common Intrusion Detection Signatures Standard." By Tomasz Kruszona and dr Adam Wierzbicki (Polish-Japanese Institute of Information Technology). Intrusion Detection Signatures Working Group. IETF Internet Draft: 'draft-wierzbicki-cidss-01.txt'. March 2005, expires September 2005. 29 pages.
• CIDSS Homepage
• "Common Intrusion Detection Signatures Standard." IETF Internet Draft. October 2004.
• CIDSS XML Schema (2004)
• IDS Signature Translator. Developed under the GNU General Public License.
• CIDSS Specification [source PDF]
• Contact: translator@b59.net
• Polish-Japanese Institute of Information Technology

Critical Infrastructure Protection Initiative (CIPI)

The Open GIS Consortium (OGC) Critical Infrastructure Protection Initiative (CIPI) "is an OGC Interoperability Initiative designed to test the application of interoperable technology to meet Critical Infrastructure Detection, Prevention, Planning, Response, and Recovery challenges... Timely, accurate geospatial information and geoprocessing services -- easily accessible and capable of being shared across federal, state, and local jurisdictions and multiple security levels -- are fundamental to Critical Infrastructure Protection. Homeland Security will be seriously hampered without the real-time ability to quickly visualize patterns of activity and understand the multi-layered, location-based context of emergency situations."

On January 09, 2003, Open GIS announced the successful kick-off meeting for Phase 2 of its Critical Infrastructure Protection Initiative (CIPI-2). "CIPI aims to test the application of interoperable technology to help national, state, provincial, and other local governments, commercial, and non-government organizations better manage emergency situations. The initiative does this by coordinating geospatial data and services to meet critical infrastructure protection needs. The Geography Division of the U.S. Census Bureau is sponsoring CIPI-2 and will use OGC's rapid-prototyping process to develop two prototype systems: an online system to update governmental unit boundary information for existing incorporated places, and a system based on OpenGIS Specifications for serving Topologically Integrated Geographic Encoding and Referencing (TIGER) data. Census will utilize the OGC Interoperability Program process to collaborate with industry participants Syncline, Galdos Systems, Northrop Grumman Information Technology, TASC, ESRI and Intergraph. Existing implementations of OpenGIS interface specifications, including Web Map Server (WMS), Styled Layer Descriptor (SLD), Web Feature Server (WFS), and Geography Markup Language (GML) will form the basis for the development of these two pilot applications. In addition, a collaborative Working Group, including Intergraph, ESRI, Galdos, Syncline and other OGC members will focus on developing aspects of a variety of OGC Interface Specifications to enhance the ability to create distributed GML Feature Collections. This work will be coordinated with the OGC Specification Program and will support development of shared features for Spatial Data Infrastructures. The resulting technology will be demonstrated in March 2003..."

• CIPI website
• "OGC Announces Critical Infrastructure Protection Initiative Phase 2 Kickoff." Announcement 2003-01-09.
• Critical Infrastructure Protection Initiative Overview
• "Geography Markup Language (GML)."

Emergency Data Exchange Language (EDXL)

While the OASIS Emergency Management TC progresses the CAP specification toward a version 2.0, its Members are working with other organizations to develop the first components of the Emergency Data Exchange Language (EDXL). The EDXL standards activity is coordinated with DHS/FEMA (as part of the Disaster Management eGov Initiative) and with the Emergency Interoperability Consortium (EIC); hosting services are provided by the Comcare Alliance. Background information on EDXL is presented in a January 2005 Memorandum of Agreement (MOA) which "establishes an alliance between the Department of Homeland Security (DHS) and the Emergency Interoperability Consortium (EIC) to promote the design, development, release and use of XML schema-based standards or other standards, tools, and processes that will help solve data sharing problems..." According to the accompanying announcement, "The next generation of data sharing standards, being developed with the leadership of emergency response organizations, is called Emergency Data Exchange Language (EDXL). It goes beyond alerting to address the routing and substance of a wide variety of interagency emergency messaging..."

According to a report from EIC ("Creating an Emergency Data Exchange Language"):

EDXL was proposed as a "cooperative effort to define a NIMS-compliant family of shared data exchange specifications encompassing: Incident Notification and Situation Reports; Status Reporting; Resource Requests and Dispatch; Analytical Data; Geospatial Information; Identification and Authentication.

The first design principle for EDXL will be collaboration and transparency; the second will be adopting, promoting and spreading the work that has already been done to other professions (particularly with the very extensive GJXDM dictionary), i.e. no re-inventing of wheels; the third principle will be speed to deployment. The Disaster Management eGov Initiative (managed by DHS' Disaster Management Program) is providing organizational resources and technical support. The involvement of all emergency practitioner groups is encouraged. The ComCARE Alliance has been tasked by DHS to facilitate these groups' participation...

EDXL is intended to "comprise three layers of data exchange standards utilizing XML data syntax and services:

• EDXL Vocabulary: Specified data elements and taxonomies to apply common terminology to data sharing regarding emergency incidents, conditions, resources, activities and outcomes. This will draw heavily on current common-vocabulary efforts (Justice Data Dictionary, FEMA resource typing, NIMS, etc) and the XML standards cited above. This project will support emergency organizations reviewing the XML and taxonomy work product of other professions to find commonalities (the 'common terms' project).
• EDXL Messages: We will develop formats for messages (XML documents) using the EDXL Vocabulary to implement routing of emergency messages (a draft 'header' has been produced, trialed and submitted for standards approval) and business processes such as emergency response resources reports, queries, updates, cancellations and error-handling. The current focus is on resource messages.
• EDXL Interfaces: Technical protocols and formats for routing of EDXL messages over various kinds of data networks and systems, based on SOAP and web-services standards, but generalized for use in a wide variety of communications environments. Our goal is to make it simple and straightforward for vendors to write interfaces from their products to EDXL."

EDXL Initiative Overview from the Comcare Alliance:

"The goal of the EDXL initiative is to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. The effort focuses on standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession is involved. Once standardized, any technology vendor or organization can easily develop their XML-based messaging interface.

The EDXL Practitioners group drives priorities and requirements for specific EDXL messages sets and messaging components. The objective is to rapidly deliver implementable standard messages in an incremental fashion directly to emergency response agencies in the trenches, providing seamless communication and coordination supporting each particular process. The effort first addresses the most urgent needs and proceeds to subsequent message sets in a prioritized fashion. The goal is to incrementally develop and deliver standards...

The EDXL initiative is a national effort including a diverse and representative group of local, state and federal emergency response organizations and professionals, following a multi-step process. A group of practitioners from leading emergency response organizations prioritize specific message sets and define base requirements...

Standard Message Sets: [Several] EDXL components and message sets [have been] identified to date for standardization activity. It is important to distinguish between the 'Distribution Element' vs. the other message sets; 'Distribution Element' may be thought of as a container which facilitates the routing of message sets (any properly formatted XML emergency message) to recipients. The message sets (e.g., Alerts, Resource Management) are carried as payloads that are routed by the Distribution Element...

• Distribution Element: An EDXL 'Distribution Element' has been developed [and] the OASIS Emergency Management Technical Committee is reviewing it to make it a public standard... The Distribution Element carries and routes 'payload' message sets (such as Alerts or Resource Management), by specifying key routing information such as incident type and affected geography, as well as basic information such as incident ID, message type and sending agency. A series of demonstrations starting in October 2004 verified application of the Distribution Element by demonstrating generation, receipt and update of common message sets across different emergency technology tools owned by a diversity of government jurisdictions and emergency response agencies. A growing number of emergency technology vendors are using the Distribution Element in ongoing demonstrations and are prepared to incorporate it into their production systems when it becomes an official standard...

• Alert Message Set: The Common Alerting Protocol (CAP) was developed by many of the same parties and processes as EDXL. It was originally sponsored by the Partnership for Public Warning and became an official OASIS standard in 2004. It has been adopted as a payload within EDXL messages, due to the flexibility of the EDXL 'open container model'. CAP messages facilitate the exchanging of hazard emergency alerts and public warnings. Any other accepted standard XML format can also be the payload carried and routed by the EDXL distribution element.

• Resource Message Set: The initial EDXL practitioner group said last fall [2004] that its next priority was message sets regarding Resource Messaging (RM). They asked for messages to request (or respond to requests) for persons and things required in emergencies. A draft document addressing a Resource Message has been developed and is being considered by the Standards Working Group. A number of detailed scenarios are being analyzed to determine the wide range of specific interagency and inter-profession resource messages.

• Geographic Information Systems (GIS): Following Resource Management Messaging, the next priority is to provide message sets addressing GIS information. The GIS message set addresses the need to identify, track, trend, or forecast events and resources. This message set also addresses the need to establish the geospatial context; to communicate about geographic features and things through standard symbols and associated information. For example, a GIS message may assist an emergency responder to assess the geographic scope of an event, to locate a required resource, to pinpoint where a resource needs to report, or to assess other geographic considerations related to an event. The symbology for this message will be 'consumed' from efforts led by FEMA, FGDC and other applicable efforts developing common mapping symbols.

• Situation Status: Situation status is a report providing the overall status of an event and the subsequent emergency response.

• Other specific message sets: Additional message needs will be addressed as the Practitioners raise the need for them..." [adapted from the document "Emergency Data Exchange Language (EDXL) Overview and Phased Approach" (Evolution Technologies)]

• "OASIS Standardizes Emergency Data Exchange Language (EDXL) Specifications."

• [June 20, 2006] "Emergency Data Exchange Language (EDXL) Distribution Element Ratified as OASIS Standard." In June 2006, OASIS anounced that the membership had "approved the Emergency Data Exchange Language Distribution Element (EDXL-DE) version 1.0 as an OASIS Standard, a status that signifies the highest level of ratification. Developed by the OASIS Emergency Management Technical Committee, EDXL-DE facilitates emergency information sharing and data exchange across local, regional, tribal, national, and international organizations in the public and private sectors...EDXL began in 2004 as a project of the Disaster Management eGov Initiative of the DHS as a means to enhance inter-agency emergency data communications. DHS partnered with industry members of the Emergency Interoperability Consortium to bring the work to OASIS for advancement and standardization..."

References:

• "Emergency Data Exchange Language (EDXL)."
• DHS and EIC Memorandum of Agreement as a basis for EDXL standards development: "The next generation of data sharing standards, being developed with the leadership of emergency response organizations, is called Emergency Data Exchange Language (EDXL). It goes beyond alerting to address the routing and substance of a wide variety of interagency emergency messaging..." See the January 2005 announcement and text of the agreement:
  • "Emergency Interoperability Consortium Announces Agreement with Department of Homeland Security to Promote Data Sharing During Emergencies. Groundbreaking Public/Private Sector Alliance Will Promote the Development of Standards for Sharing Emergency Response Information."
  • DHS and EIC Memorandum of Agreement. January 2005. "This agreement establishes an alliance between the Department of Homeland Security (DHS) and the Emergency Interoperability Consortium (EIC) to promote the design, development, release and use of XML schema-based standards or other standards, tools, and processes that will help solve data sharing problems..."
  • Signed MOA between DHS and the EIC, to promote the development of data standards for emergency management communication. Approved by Steve Cooper (DHS CIO) on September 10, 2004; approved by Barry C. West (DHS CIO/Director ITSD) on September 08, 2004; signed by Matt Walton (Chairman, EIC) on January 13, 2005. Posted by Elysa Jones on June 20, 2005. [source PDF]
• "Emergency Data Exchange Language (EDXL). Overview and Phased Approach." From Evolution Technologies, provided by Timothy Grapes. March 10, 2005. 4 pages. [source .DOC, alt version, ComCARE]
• Participants in the EDXL Process. From Comcare.org.
• Companies/Organizations Participating in EDXL Demonstrations
• Emergency Data Interoperability Demonstration. October 27, 2004.
• "Creating an Emergency Data Exchange Language." From the Emergency Interoperability Consortium (EIC). March 01, 2005. Contact Lee Tincher. [cache]
• Emergency Data Exchange Language (EDXL) - In relation to the OASIS Emergency Management TC and the CAP specification
• Emergency Data Exchange Language (EDXL) Distribution Element. Draft 5/2/05. 8 pages. See context. "This draft describes a standard message distribution framework for data sharing among emergency information systems using the XML-based Emergency Data Exchange Language (EDXL). This format may be used over any data transmission system, including but not limited to the SOAP HTTP binding." Posted by Elysa Jones to the OASIS Emergency Management TC document repository on 2005-05-03. [source .DOC]

Emergency XML (EM-XML) Consortium

Note: See now the OASIS Emergency Management Technical Committee. This section retained for historical reference.

The formation of the Emergency XML (EM-XML) Consortium [alternately: EMXML] was announced in October 2002. Founding members included: AlertTech, BizCom USA, Blue292, ESRI, E Team, Inc., International Analytics (Division of Ship Analytics), NC4, SAIC, Visual Risk, WebEOC. "The Consortium wishes to promote and establish commercial interoperability standards for companies providing software solutions to emergency management personnel, particularly first responders...Recognizing the urgent need to provide first responders and others involved in preparing for, responding to and recovering from emergencies of all kinds with the support they need, the companies have committed to creating an open XML-based standard for emergency management data exchange. This will ensure that first responders, emergency and event managers, public health agency officials and executive management in both the public and private sectors can create and immediately share critical information during an emergency or major event..."

What is the EM-XML Consortium? A parent organization, for which the OASIS Emergency Management TC is one constituent part. "Since the announcement of the EM-XML Consortium in October 2002, the group has attracted the attention of numerous public and private companies, individuals, and agencies. Currently totaling a representation in excess of 40 institutions, this effort is focused on researching, designing, developing, deploying, and evangelizing standards in the world of incident and emergency management. The Consortium's rapid growth and exposure has not only allowed it to help begin defining future of incident and emergency management standards, but it also began to impact them today. To accommodate the growth and further focus the work [of the Consortium], an Executive Committee (EC) and a Technical Committee (TC) have been formed. This provides a more well-defined and efficient structure, with each committee serving its own unique functions. The EM-XML EC is chaired by Matt Walton, Founder and Vice Chairman of E Team, and focuses on the public and Federal outreach and education of the efforts of the TC, as well as incident and emergency management issues in general. This group provides guidance and direction for development of interoperability standards focused on incident and emergency management. Currently, the group meets quarterly and membership is free. Additional information about the EM-XML EC can be requested by sending email to Matt (mwalton@eteam.com). R. Allen Wyke, CIO of Blue292, chairs the TC. It focuses on the design and creation of XML-based standards to support incident and emergency management interoperability. This group, formally known as the Emergency Management Technical Committee (EM TC), is housed within OASIS, 'a not-for-profit, global consortium that drives the development, convergence and adoption of e-business standards.' Additional information about the EM TC, which has weekly calls and requires membership in OASIS, can be obtained from the Website or by sending email to R. Allen Wyke." From "Understanding the EM-XML Consortium," a document describing the EM-XML Consortium and its relation to the OASIS Emergency Management TC, 2003-04-22.

• "Leaders in the Emergency Management Industry Form EXML Consortium to Establish Interoperability Standards." Announcement 2002-10-14. [source]
• "E Team First to Offer Interoperable Incident Management System for Homeland Security. Release 2 - Government Edition Enables All Players Critical to an Emergency Response to Collaborate In Real Time ." Announcement 2002-12-17.
• "Q&A: Dr. Ivan Walks on the Need For Info-Sharing." By Dan Verton. In Computerworld (November 06, 2002).

IEEE Incident Management Working Group (IMWG)

The WG was formed to "research, compile, analyze, and consolidate information leading to the publication of a standards message set for Incident management; this scope initially will be limited to address message sets from Emergency Management Center (EMC) to the Traffic Management Center (TMC) and Emergency Telephone System (ETS)... Message sets for Incident Management include all message sets generated and transmitted between the emergency management subsystem to all other subsystems. and providers. These include, the Emergency Telephone System, Fleet and Freight Management, Information Service Provider, other Emergency Management Centers, Planning Subsystem, Traffic Management, and Transit Management. Therefore a standard message set will reduce the duplication of messages among the various subsystems and a common set of message will help providers or services to interact more effectively..."

IEEE 1512-2000, Standard for Common Incident Management Message Sets for use by Emergency Management Centers, is the base standard for incident management message sets. Providing incident management message sets common to traffic management, public safety and hazardous materials incident response activities, it supports communications among Multi-Modal Transportation Management Centers, Public Safety Agencies, Fleet and Freight Management Centers, Information Service Providers, Traffic Management Centers. Companion volumes are being developed in four areas: (1) Traffic Management: Traffic management message sets for use by transportation and public safety agencies in transportation incident management. (2) Public Safety: Message sets for interagency coordina - tion, dispatching and asset management for use by transportation and public safety agencies in transportation incident management. (3) Hazardous Materials: Message sets for communications dealing with management of hazardous materials during a transportation incident. (4) Data Dictionary: A data dictionary of the data elements and structures used in the 1512 family of standards..." See the IEEE Std 1512 - 2000 Fact Sheet.

2003 Revision of IEEE Std 1512-2000 to include XML: "The base standard (IEEE Std 1512-2000) was published in 2000 under the leadership of Chester Chandler, who was the IMWG Chair. This standard covers center identification, where centers can go off-line or on-line, as well as ways to describe the incident, such as numbering, splitting, or merging them, etc. Most importantly, it contains an incident description that can continue to expand as more centers add to or update the information. It also includes messages relating to emergency response plans. This standard was demonstrated by operating a prototype messaging system between the Florida SunGuide and Lockheed-Martin exhibit booths at ITS America's 11th Annual Meeting and Exposition in Miami in 2000. A revision to this standard is expected to be published in 2003. This revision will add sections for CORBA and Extensible Markup Language (XML) implementation, as well as adding some minor new data elements..." [From "Incident Management Message Sets," in Florida Department of Transportation (FDOT) SunGuide, November 2002]

Standard for Hazardous Material Incident Management Message Sets for Use by Emergency Management Centers. In October 2002, the volume for exchange data concerning Hazardous Materials (HazMat) was officially published (IEEE Std 1512.3 TM-2002). [It] ... provides a common framework for communication to online databases about the materials involved in transportation emergencies. The standard addresses data collection on hazardous and non-hazardous substances from databases maintained by shippers, carriers, fleet and freight management centers, and other parties. This information concerns such topics as toxicity, explosive danger, flammability, environmental damage, set-backs and evacuation areas. IEEE 1512.3 also sets a uniform format for transmissions from emergency sites to government agencies and other parties to eliminate confusion in how the data is interpreted...] This standard was developed under the leadership of Michael Ritchie of the Minnesota Department of Transportation (MinnDOT), the HazMat Sub-Committee Chair. The standard includes sections on CORBA and XML, as well as the required Abstract Syntax Notation One (ASN.1)..." [also from SunGuide 2002-11]

• Incident Management Working Group home page
• About the IMWG
• "Incident Management Message Sets." In SunGuide Disseminator [Florida Department of Transportation - FDOT], November 2002.
• IEEE P1512 Standards Overview
• XML hints: From the Minutes of the 2002-03-15 meeting. "Item 5: Status of Phase III. We really need to develop supplements to allow the 1512 Family of Standards in a manner to support CORBA and XML... and, February 2001 Minutes, Report on 'XML and Imports in Standards Development' by Dave Kelley: "... the 1512 standard is using XML. The 1512 Demo puts all the data out in XML. ASN1 will however be the standard protocol used for the expression of 1512 data..."
• Contact: Ann Lorscheider (North Carolina Department of Transportation)

IETF Incident Object Description and Exchange Format (IODEF)

"... the free exchange of incident information and statistics among involved parties and the responsible Computer Security Incident Response Teams (CSIRTs) is crucial for both reactionary analysis of current intruder activity and proactive identification of trends that can lead to incident prevention. The purpose of the Incident Handling working group is to define data formats for communication between (a) a CSIRT and its constituency (e.g., users, customers, trusted reporters) which reports system misuse; (b) a CSIRT and parties involved in an incident investigation (e.g., law enforcement, attacking site); and (c) collaborating CSIRTs sharing information. This format will support the now largely human-intensive dimension of the incident handling process. It will represent the product of various incremental data gathering and analysis operations performed by a CSIRT from the time when the system misuse was initially reported (perhaps by an automated system) till ultimate resolution..."

• IETF Extended Incident Handling Working Group
• Incident Object Description and Exchange Format Data Model and Extensible Markup Language (XML) Document Type Definition
• Incident Object Description and Exchange Format (IODEF)
• "Requirements for Format for Incident Report Exchange (FINE)."

IETF Intrusion Detection Exchange Format (IDMEF)

"Security incidents are becoming more common and more serious, and intrusion detection systems are becoming of increasing commercial importance. Numerous intrusion detection systems are important in the market and different sites will select different vendors. Since incidents are often distributed over multiple sites, it is likely that different aspects of a single incident will be visible to different systems. Thus it would be advantageous for diverse intrusion detection systems to be able to share data on attacks in progress. The purpose of the Intrusion Detection Working Group is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to management systems which may need to interact with them. The Intrusion Detection Working Group will coordinate its efforts with other IETF Working Groups..."

• IETF Intrusion Detection Exchange Format Working Group
• Intrusion Detection Message Exchange Format Data Model and Extensible Markup Language (XML) Document Type Definition
• The Intrusion Detection Exchange Protocol (IDXP)
• Intrusion Detection Message Exchange Format

OASIS Emergency Management TC: CAP, EDXL-DE, EDXL-RM, HAVE

The OASIS Emergency Management TC supports development and adoption of several standards relating to public safety and emergency management, including (1) alerting, warning, and informing responders and the public (2) incident reporting and tracking; (3) resource identification, tasking and tracking.

• CAP (Common Alerting Protocol)
• EDXL-DE (Emergency Data Exchange Language Distribution Element)
• EDXL-RM (Emergency Data Exchange Language Resource Messaging)
• HAVE (Emergency Data Exchange Language Hospital AVailability Exchange - HAVE)

In November 2005, OASIS announced that the Common Alerting Protocol (CAP) version 1.1 had been approved as an OASIS Standard. "CAP v1.1 enhancements include flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions; multilingual and multi-audience messaging; phased and delayed effective times and expirations; enhanced message update and cancellation features; template support for framing complete and effective warning messages; compatibility with digital encryption and signature; and a facility for digital images and audio. The OASIS TC seeks input from those in the international community to advance CAP in alignment with other specifications in its Emergency Data Exchange Language (EDXL) suite."

On April 01, 2004 OASIS announced that the Common Alerting Protocol Committee Draft version 1.0 of February 10, 2004 approved by the TC and balloted to the OASIS membership had resulted in this Committee Draft being approved as an OASIS Standard. A new "CAP 1.0 Fact Sheet" has also been released. See additional details in the press release of 2004-05-05: "Common Alerting Protocol (CAP) Ratified as OASIS Standard."

[February 26, 2004]   Common Alerting Protocol Version 1.0 Approved by OASIS Emergency Management TC.    Members of the OASIS Emergency Management Technical Committee have approved a Committee Draft specification for the Common Alerting Protocol Version 1.0 and have recommended its advancement for approval by OASIS as an OASIS standard. The Common Alerting Protocol (CAP) is "a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task. CAP also facilitates the detection of emerging patterns in local warnings of various kinds, such as might indicate an undetected hazard or hostile act. And CAP provides a template for effective warning messages based on best practices identified in academic research and real-world experience." The TC was chartered to "design, develop, and release XML Schema-based standards that begin to solve the real-world problems of incident preparedness, response, and emergency management; these standards are not only to provide a framework for data exchange, but also for functionality and service accessibility, all with the common goal of seamless application and data interoperability. The Emergency Management TC's scope includes: unified incident identification; emergency GIS data accessibility and usage; notifications methods and messages; situational reporting; source tasking; asset and resources management; monitoring and data acquisition systems; staff, personnel and organizational management."

[January 10, 2003]   OASIS Members Form Emergency Management Technical Committee.    Affiliates of seven OASIS member companies (Blue292, Inc., E Team, Inc., SunGard Planning Solutions, DMI-S, NC4, Wells Fargo N.A., Ship Analytics) have created a new Emergency Management Technical Committee to "advance the fields of incident preparedness and response in addition to emergency management." Blue292, Inc. intends to contribute a notification specification and form data collection specification to the technical committee at its first meeting for consideration as the basis for work. The TC members will "design, develop, and release XML Schema-based standards that begin to solve associated 'real-world' problems of data communication and technology interoperability. These standards will not only provide a framework for data exchange, but also for functionality and service accessibility, all with the common goal of seamless application and data interoperability. The TC's scope of activity is to include: unified incident identification; emergency GIS data accessibility and usage; notifications methods and messages; situational reporting; source tasking; asset and resources management; monitoring and data acquisition systems; staff, personnel and organizational management." The TC Chairs include Allen Wyke (Blue292, Chair) and Rick Carlton (E Team, Inc., Vice Chair).

[October 30, 2003]   OASIS Emergency Management TC Approves Common Alerting Protocol (CAP) Draft.    A Committee Draft for the Common Alerting Protocol Version 1.0 has been approved by members of the OASIS Emergency Management Technical Committee and has been released for 30-day public review. The Common Alerting Protocol is "a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task. CAP also facilitates the detection of emerging patterns in local warnings of various kinds, such as might indicate an undetected hazard or hostile act. And CAP provides a template for effective warning messages based on best practices identified in academic research and real-world experience." The OASIS TC was chartered to "advance the fields of incident and emergency preparedness and response, to be accomplished by designing, developing, and releasing XML Schema-based core and metadata standards to help facilitate and improve the real-world interoperability problems around incident and emergency management." Public review of the CAP Version 1.0 CD and comments are invited through November 30, 2003.

• OASIS Emergency Management TC. Main reference page.
• Emergency Management TC FAQ document
• Members Approve Common Alerting Protocol (CAP) v1.1 as OASIS Standard
• "CAP 1.0 Fact Sheet." Date: 3/1/2004. From the OASIS TC. "The Common Alerting Protocol (CAP) is the OASIS Emergency Management Technical Committee's first standard for homeland security and civil emergency management. CAP is a simple, flexible data interchange format for collecting and distributing 'all-hazard' safety notifications and emergency warnings over information networks and public alerting systems..."
• Emergency Management Technical Committee. News story.
• Announcement and Call for Participation: Emergency Management TC
• "OASIS Members Form Emergency Management Technical Committee. Consortium to Advance Incident Preparedness and Response." 2003-02-10.
• Emergency Management TC website
• List archives for TC discussion. Subscribe using the subscription manager
• List archives for public 'emergency-comment' list
• CAP Cookbook. "A collection of application notes, supporting documents and commentaries about the Common Alerting Protocol. This is a wiki, a collaborative editing environment, which means that the documents here are undergoing editing and revision by a variety of authors." The use of this resource is not restricted to OASIS members, as explained in the announcement.

OpenSec Advisory and Notification Markup Language (ANML)

The Open Security Organization is developing an Advisory and Notification Markup Language (ANML). First in a planned suite of related standards, the Advisory and Notification Markup Language (ANML) "is an XML-based specification for describing advisories and other types of notifications. ANML intends to solve the inconsistent use of terminology by software vendors in their advisories and make it easy for applications to read these advisories. This will make way for the necessary tools to automatically update systems. Although ANML will have its biggest impact for security advisories, it can be used for any type of notification. Some examples include bug-fixes, feature enhancement, upgrade availability, and many more." The developers solicit involvement from interested parties. Other standards planned for development include: (1) System Information Markup Language (SIML) -- an XML-based specification for describing a system's properties and providing a detailed inventory of software, hardware, and configuration information; (2) Software Description Markup Language (SDML) -- an XML-based specification for describing the properties of software and its environment. ANML, SIML, and SDML are designed to form the core of the OpenSec Framework. The OpenSec Framework is a set of guidelines on how to use these technologies to aid system management. The OpenSec goal is to be able to send an SDML file to a web service that will respond with an ANML file. A system manager will compare elements of the ANML file to elements of the SIML file to assess the system and install the necessary updates."

• The Open Security Organization
• "Why We Need ANML"
• Microsoft Security Bulletin MS02-072 in ANML format
• OpenSec standards
• Contact: Nasseam Elkarra