[CAP] Fwd: Re: CAP 1.2?

[Art Botterell]

Forwarded on behalf of Doug Alport:

-----Original Message-----
From: Doug Allport [mailto:Doug at AllportGroup.com]
Sent: October 23, 2007 1:52 PM
To: 'cap-list at lists.incident.com'
Subject: RE: [CAP] CAP 1.2?


We Canadian's have created a CAP Canadian Profile that includes the
following:

1. 	Additional info blocks be limited in use to additional languages

2. 	Event (and code) from comprehensive event list required

3. 	Nationally recognized location code for geopolitical area required.
Our Standard Geographical Classification (SGC) includes code down to the
smallest of towns, townships, etc.  More specific location  
identification is
encouraged.

This approach allows for filtering/forwarding of alerts to commonly
recognized locations and events. It also makes it very easy for a  
unilingual
person to feel comfortable about issuing alerts to a population with two
first languages, as events, location names, etc. may be pulled from
translation tables.

If there is a 2.0, we have compiled a list of suggestions:

1.	Multiple <info> segment use be limited to the purpose of supporting
additional languages.

2.	<info> segment elements <category>, <responseType>, <urgency>,
<severity>, <certainty>, <eventCode>, <effective>, <onset>,  
<expires>, and
<senderName> be associated with <alert>, rather than <info>, as they  
relate
to all languages, and need not be duplicated in each <info> block.

3.	<areaDesc> be associated with <info>, so that it is supported in the
various languages of the alert.

4.	<resource> and associated resource elements, as well as <web>,
<contact>, and <parameter>, be allowed for with both <alert> (in  
support of
all languages), and <info> (in support of the specific language).

5.	<category> be optional.

6.	<msgType> include a value such as "Bulletin", which would be
different than an "Alert". Such uses would include annual public safety
notices regarding smoke detectors, winter tires, etc.

7.	<parameter> value name of "Update", with values "Same" and
"Revised", be used to identify if an <Info> segment has or has not been
updated, when the <alert> is an update

To this list, we'll probably look to add a solution for clearly
distinguishing between an agency issuing on behalf of another. This  
would
cover mutual aid agreements we've uncovered, and where a PSAP might  
issue on
behalf of multiple jurisdictions.

While I have your attention, a diverse group of public and private
stakeholders is about to formalize the strategic and business plan  
for the
Canadian Association for Public Alerting and Notification  
(www.capan.ca).
The association is to serve as the national clearing house for public  
alerts
and notices, in support of the growing number of communications  
companies,
internet service providers, search engines, etc. that are trying to  
deliver
related services to the public...and to emergency managers for situation
awareness needs. Authentication and validation of alerts against  
registered
issuer profiles is a function defined for CAPAN. A key objective is  
to see
that when the bell is rung, alerts/notices from all levels of  
government,
utilities, etc. are readily available by location, using common search
engines, information channels, public service numbers, location based  
RSS
feeds, etc.

Cheers,

Doug Allport
Allport Group Inc.
(613) 271-1040