Grandpa Ham – Grandpa Can do IT!

• @Disaster_Guy make sure the notification system can send and receive IPAWS Alerts. #

• Working on the UAT Plan for the #IPAWS OPEN patch release 2.00.01. Includes #NIEM code lists as retrievable #EDXL Value lists. #

There is a lot of talk lately about CAP compliance (and/or conformance) in alerting products.  At it is there.  It is, in fact, happening but there is compliance and then there is compliance with a wink. For example, IPAWS-OPEN 2.0 itself is only CAP 1.1 compliant and not IPAWS Profile compliant (yet). March is the goal at this point for CAP 1.2 and IPAWS Profile. Typical of any Government Program, we are trying to catch up with ourselves. But at least we are succeeding. (Note: we also have to be completely compliant. Compliance with a wink does not work very well in middleware.)

Also CAP 1.2 Compliance can be defined at many levels. (How many vendor products can actually digitally sign CAP 1.2 messages in accordance with the spec? I know it is optional, but compliance at one level means doing all the mandatory. At another level, it is also being able to do all of the optional.)

How about CAP IPAWS Profile compliance? The profile specifies Message Conformance, Message Producer Conformance and Message Consumer conformance. The rules for each are in the spec. Again is it all or just what is mandatory? (Hint: vendors will need to be able to do a LOT of the optional to be functional for their user base.)

Finally, there is the ability to send and/or receive messages from FEMA’s IPAWS aggregator. You will need to be able to do that. Particularly for CMAS which is scheduled to be operational in 2012 (Testing with the carriers begins very soon.) I can help with the last one. Many companies have signed up to begin development and test. Some have not. Give me a call or send e-mail. I can help.

How can testing begin even without 1.2 in place at IPAWS-OPEN? It can. The functional interface will be virtually unchanged for CAP 1.2 and most CAP 1.2 messages will also validate as CAP 1.1. The only difference is a couple of responseType values and the way the optional digital signature is configured on the message. (So those will not work with us until March. 🙂 )

• @n3rcc IPAWS will be an incremental roll out. There are now 7 different guidance documents. Patience. You will see success over time. #

What have we done to the Common Alerting Protocol (CAP)?  In 2003, CAP 1.0 was released a simple, straightforward XML schema for alerting. It was, and is, a great idea and has achieved almost worldwide acceptance. As with any great idea, folks have discovered a need to tweak here and there and to impose their own rules for usage, security, etc.  The great thing is that the basic structure remains in tact. The devil, however, remains in the details of implementation in systems throughout the world.  We are on CAP 1.2.  Europe has adopted CAP 1.1.  Canada has published its own CAP Canadian Profile.  We, in the U.S., also have the CAP IPAWS profile as an OASIS TC Committee specification and a requirement for broadcast of messages through  FEMA’s Integrated Public Alert and Warning System (IPAWS).

I am currently trying to define a document to help CAP message origination software builders build an appropriate message for use in the world of FEMA’s IPAWS.  This world includes both “regular CAP” and IPAWS Profile CAP, including its variations (EAS, NOAA NWEM, and CMAS).  It is no small task. There are at least seven different documents that need to be “amalgamated” for the purpose (one of which has not even been formalized in writing yet):

• The first is the actual CAP Standard; now version 1.2 (OASIS Common Alerting Protocol, Version 1.2, OASIS Standard, 01 July2010).
• This is modified by the CAP IPAWS profile specification (Common Alerting Protocol, v.1.2 USA Integrated Public Alert and Warning System Profile Version 1.0, Committee Specification 01, 13 October 2009).
• For messages bound for Emergency Alert System (EAS) disseminators there is the CAP ECIG recommendation (ECIG Recommendations for a CAP EAS Implementation Guide, EAS CAP Industry Group – ECIG, EAS-CAP Implementation Guide SubCommittee, Version 1.0, 17 May2010).
• For messages bound for broadcast via NOAA Radio, there are additional rules (National Weather Service Instruction 10-1701, Text Product Formats and Codes, February 12, 2003).
• For messages bound for cell phone broadcast there are rules requires to implement the ATIS/TIA Standard (Joint ATIS/TIA CMAS Federal Alert Gateway to CMSP Gateway Interface Specification, October 2009)
• Originators will also need the documentation for connection to IPAWS-OPEN itself (Federal Emergency Management Agency (FEMA), Integrated Public Alert and Warning System (IPAWS) Open Platform for Emergency Networks (IPAWS-OPEN v2) Web-Service Interface Design Guidance Version 1.2, November 12, 2010).  Note: the document is provided to external vendors and programs upon completion of MOA documentation.
• Finally there will be formal rules on originator approval; NWEM and EAS Alert Originator Approval and Permission Procedures for IPAWS COGs (to be published).

My goal is to provide this document in iterations (think beta versions) to IPAWS-OPEN partners with completed MOAs. It will take some time, but, eventually, a formal version will also be published.   Your input will be appreciated.

• IPAWS-OPEN 2.0 has 21 company/organizations approved for testing. It is all moving forward. #
• Going home on VRE from DC. Meetings with CTIA on CMAS and PSAP vendor on IPAWS. If you know the acronyms, you know there is progress. #

• RT @trevbhatt Dyslexic devil worshippers sell their souls to Santa #
• @LosRanchosEM I have no update on Framework. Wish I did. #

I sent out the first 8 sets of credentials to independent interoperable systems this week.  The test environment can now actually be used.  Those of you who are familiar with FEMA procedures know what it took.  Whew!!!!

For those who may not be totally familiar with IPAWS-OPEN, Check my permanent page on IPAWS.

It has finally happened.  The process for getting access to the IPAWS-OPEN 2.0 Test capability is in place.  You must fill out a request questionnaire first.  This questionnaire will soon be available on the FEMA IPAWS web site.  Until it is available, makers/developer/program managers of emergency management software and Alert dissemination systems can send email to “open AT eyestreet.com”  requesting the questionnaire.  We will use that information to construct a Memorandum of  Agreement that you will sign and return to me.  I will obtain a valid Government signature and return the MOA to you along with a programmers Manual, valid system endpoint for the IPAWS 2.0 web services, and an x509 signature to be used in accessing those end points.  Please be patient.  There is some pent-up demand and it will take a while before everyone is taken care of. We will be giving priority to current OPEN operational systems and to EAS dissemination systems that need to help broadcasters meet the infamous “180 day clock.”  But we will get to you.