Re: [earlywarning] [CAP] Definition of Warning Categories
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [earlywarning] [CAP] Definition of Warning Categories



While valid points have been made on both sides, I do suggest that the
EDXL-DE be reviewed against your requirements to determine how it may
address your needs.  Without opening the hood further, it appears it could
do the trick in concert with registration processes etc. and a distribution
framework such  as OPEN.

Thanks,
Tim Grapes
Evolution Technologies, Inc.
An SDVOB "Service Disabled Veteran-Owned Business"
Office:    (703) 654-6075
Mobile:  (703) 304-4829
Fax:         (703) 654-6001
tgrapes at evotecinc.com
http://www.evotecinc.com/
"When your work speaks for itself, don't interrupt"
- Henry J. Kaiser

-----Original Message-----
From: James M. Polk [mailto:jmpolk at cisco.com] 
Sent: Sunday, July 12, 2009 9:58 PM
To: David Aylward (Comcare); 'Art Botterell'; earlywarning at ietf.org;
cap-list at incident.com
Cc: Timothy Grapes; ltincher at evotecinc.com
Subject: Re: [earlywarning] [CAP] Definition of Warning Categories

All

While I might agree with the reasons you have stated for the 
vagueness of categories, I have to look at Henning's example as a why 
I don't necessarily want "all warnings" from a geography. For 
example, he rightfully stated that just because I listed Tsunami 
warnings as something I care about, I should also care about the 
chemical leaks, or Tornados in my area too.

And there's the rub - who decides what warnings I get?

If I subscribe to (conceivably) all warnings in my area, do I really 
care when Dave has falen and can't reach his beer? Is that so 
monumental to anyone else?  Local policy might dictate that yeah - 
everyone should do what it takes to get Dave his beer, but I don't 
necessarily need to care, therefore I will likely NOT want to get 
this messages.

Too many warning messages will create a "cry wolf" mode of me 
eventually believing none of them are useful, regardless of what they 
say. I just won't reach for my (whatever) device if it's just out of my
reach.

Perhaps general categories ought to be looked at, because I think I 
can see exactly where Hannes is going, and I believe I'm in the same 
ballpark as him thinking this ought  to be a little more specific for 
subscriptions.

James

At 03:41 PM 7/12/2009, David Aylward \(Comcare\) wrote:
>Hannes:
>
>That is exactly what I was talking about, but CAP was not designed for
that.
>It is a
>"broadcast to the world" standard.  It is excellent for that purpose, but
>not for the more refined purpose you are pursuing.
>
>The OASIS EDXL Distribution Element was designed for exactly that purpose:
>machine to machine routing based on incident type, role and similar
factors,
>and primarily as Art suggests in the "wholesale", inter-organization world.
>
>
>Organizations (and individuals connected to them) subscribe to "hear" about
>incident types within certain geographies.
>
>We have talked in the past, Hannes, about "core services", the purpose of
>them is to provision queries such as you suggest, and govern rights to send
>and receive such messages.
>
>Lots of work has been done on these ideas outside of the message-specific
>standards that they would enable.
>
>
>David K. Aylward, President
>COMCARE Emergency Response Technology Group
>1351 Independence Court, SE
>Washington, DC 20003
>202.255.3215 (mobile)
>202.295.0136 (office)
>202.521.4047 (fax)
>daylward at comcare.org
>
>This communication is intended for the use of the recipient to which it is
>addressed, and may contain confidential, personal and/or privileged
>information. Please contact us immediately if you are not the intended
>recipient of this communication, and do not copy, distribute, or take
action
>relying on it. Any communication received in error, or subsequent reply,
>should be deleted or destroyed.
>
>
>-----Original Message-----
>From: cap-list-bounces at lists.incident.com
>[mailto:cap-list-bounces at lists.incident.com] On Behalf Of Art Botterell
>Sent: Sunday, July 12, 2009 3:23 PM
>To: earlywarning at ietf.org; cap-list at incident.com
>Subject: Re: [CAP] Definition of Warning Categories
>
>I'm wondering whether it might be simpler, at least in the near term,
>to let consumers subscribe to selected sources rather than to topical
>categories.  That pushes the question of message authoritativeness /
>jurisdiction  /credibility out of the CAP infrastructure and into the
>larger field of inter-agency and inter-jurisidictional coordination,
>where it more properly belongs.
>
>Taxonomies tend to be culturally loaded and can never be guaranteed to
>be complete.  Thus there's a real risk of "categorical disconnects"
>leading to missed alerts either because of differing interpretations
>of categories or of unforeseen events that don't fit our preconceived
>categories.  Maybe someday we'll have a reliable taxonomy of the
>unexpected, but right now a degree of deliberate imprecision seems to
>be the best we can do... and I sometimes wonder whether even that is
>more helpful than it is risky.
>
>- Art
>
>
>On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote:
>
> > I should provide a bit more feedback about the background to my
> > question.
> >
> > If you only set the value in the category field for the purpose of
> > human
> > consumption then there is not really an interoperability issue.
> >
> > Now, with the work on
>http://tools.ietf.org/html/draft-rosen-sipping-cap-03
> > we wanted to define an event package for SIP that allows you to
> > "subscribe"
> > to certain type of events: you might indicate something like
> > location and
> > the type of events you are interested in.
> >
> > Now, the semantic of the category field suddently matters. With the
> > individuals-to-citizen emergency services we tried to come up with a
> > description of the emergency services categories, see RFC 5031.
> >
> > Ciao
> > Hannes
>
>_______________________________________________
>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.
>
>
>
>_______________________________________________
>earlywarning mailing list
>earlywarning at ietf.org
>https://www.ietf.org/mailman/listinfo/earlywarning


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.