[CAP] CAP Deployments

[Art Botterell]

Hannes -

I'm not sure the field is mature enough for current deployments to be  
described as "typical," but I can mention a few of approaches I've  
seen...  maybe some of our other actors will chime in with additions  
and corrections.

So far dissemination approach I've seen most often exposes a  
collection of non-expired CAP messages via HTTP, indexed using either  
an RSS or Atom file.  Clients can poll the index and, if there's  
something new, retrieve and process the new CAP messages.  (This is an  
example of the "buffer" functionality, where the server persists each  
alert until it expires for the benefit of "latecomer" clients.)

Implementers of that web-feed approach include the U.S. Weather  
Service, U.S. Geological Survey, State of California and Contra Costa  
County systems.  (The Contra Costa system also "escalates" its most  
urgent messages to the California EDIS system, which also features  
selected content from the federal Weather Service, serving as a simple  
example of how CAP services may be federated across systems with  
different operators.)

A completely different approach to dissemination is taken in "Digital  
Emergency Alert System" deployments where CAP messages are multiplexed  
into digital TV transmissions, terrestrially and by satellite.  That  
system achieves the buffering function by periodically retransmitting  
active messages, a technique sometimes called a "data carrousel."   
There's been some R&D work done on using digital AM & FM channels as  
well, but I'm not aware of any deployments of that just yet.  There's  
also been use of a satellite audio broadcasting service called  
WorldSpace in a CAP deployment in Sri Lanka.

Yet another approach, somewhat closer to a conventional web-services  
model, has been taken in the HazCollect system being developed by our  
National Weather Service.  That involves aggregating CAP alerts in an  
XML message broker called DMIS (operated by a different federal  
agency), then forwarding them through a gateway that converts them  
into a native text format based on the WMO standards for distribution  
over a legacy satellite network and ultimately over VHF audio weather  
information radio stations.

And although I haven't actually seen one I've heard of some  
implementations using XMPP ("Jabber") in either a point-to-point or a  
pub-sub mode.

Of course, those are just the transport arrangements.  Any of them can  
forward CAP messages generated "manually" using input screens, some of  
them including GIS mapping functionality, as well as automatic alerts  
generated by sensor systems, and also alerts rendered into CAP from  
other formats.  Likewise, there are a wide variety of consumers of CAP  
content, regardless of the transport mechanism.  Some display  
information graphically, as text, as maps or as both.  Others do text- 
to-speech conversion.  Still others actuate lights, buzzers, sirens  
and the like.

Obviously the whole point of CAP is to allow maximum freedom to "mix  
and match" various orgination, transport and presentation schemes.

And then there's the issue of authentication and trust models.  As  
we've been discussing, so far most systems have relied on trusted  
servers with access controlled by passwords, and trusted links using  
SSL or just hard-to-attack channels like high-power TV transmissions.   
That's becoming less satisfactory as we move toward federated "systems  
of systems" that aren't entirely controlled by a single entity.

And I know folks get tired of hearing me recite that old Internet  
dictum that "we must resist the temptation to standardize what we  
don't yet understand" but I think it really applies here.  We're still  
in the let-a-hundred-flowers-bloom period; although we're starting to  
see what we think may be some recurring patterns, I think it's  
probably way premature to certify any of them as durable best practices.

- Art


On Mar 18, 2009, at 3/18/09 12:11 PM, Hannes Tschofenig wrote:

> Hi all,
>
> Based on some of the recent discussions on the list I was wondering  
> how CAP
> is currently deployed. I would like to learn something about the
> architectural differences.
>
> Thanks.
>
> Ciao
> Hannes
>
> PS: I tried to describe some possible architectural variants in  
> Section 3 of
> draft-norreys-ecrit-authority2individuals-requirements-02 (see
> http://tinyurl.com/cm7fp9) but I am not sure I correctly captured the
> important differences. Btw, I will change the terminology in that  
> document
> with the next document version.
>
>
> _______________________________________________
> This list is for public discussion of the Common Alerting Protocol.   
> This list is NOT part of the formal record of the OASIS Emergency  
> Management TC.  Comments for the OASIS record should be posted using  
> the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
> CAP-list mailing list
> CAP-list at lists.incident.com
> http://lists.incident.com/mailman/listinfo/cap-list
>
> This list is not for announcements, advertising or advocacy of any  
> particular program or product other than the CAP itself.