[CAP] Fwd: Re: CAP 1.2?

[Rex Brooks]

Thanks Art,

Does your implementation of Mailman keep an archive? I'm going into 
head-down mode on EDXL-RM starting the end of this week, and don't 
know when I'll come up for air, but when I do, there is already a 
pretty full plate, and I don't want this fine post to get lost in the 
shuffle if I forward it before the TC is ready to move on CAP 2.0 or 
1.2. I have saved it locally in a growing file for CAP 2.0 on the 
computer I use for emails, but with Murphy always lurking it would be 
great if there was another archive to which I could resort if mine 
gets crashed.

Thanks again,
Rex

At 7:39 PM -0700 10/23/07, Art Botterell wrote:
>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
>_______________________________________________
>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://eastpac.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.


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670