OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [earlywarning] [CAP] Definition of Warning Categories

Hi Brian,

FYI, the DE contains a ContentKeyword in the ContentObject  element which
might be a valid usage of this element in context of wrapping and
distributing a warning message.

You're correct that it doesn't define categories.  But if usage policies
were defined and then categories were to be defined, agreed to and
maintained under governance in an accessible location, ContentKeyword
provides a consistent application of those categories. 

I'm sure valid debate may ensue, but this is one reason this type of
flexibility was built into the DE.  I'm only suggesting this be considered
as an existing available solution / usage of the DE rather than discounting
it as an option up front.

Element contentKeyword
Type List and Associated Value(s)
Usage OPTIONAL, MAY use multiple
Definition The topic related to the message data and content, as it may
determine message
distribution and presentation decisions.
Comments 1. The list and associated value(s) is in the form:
where the content of <valueListUrn> is the Uniform Resource Name of a
list of values and definitions, and the content of <value> is a string
(which may
represent a number) denoting the value itself.
2. Multiple instances of the <value>, MAY occur with a single <valueListUrn>
the <contentKeyword> container.
3. Multiple instances of <contentKeyword> MAY occur within a single
<contentObject> container.
Examples of things <contentKeyword> might be used to describe include
processor, event stage, resource code and response type.
Used In contentObject

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

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Friday, July 17, 2009 9:06 AM
To: 'Timothy Grapes'; 'James M. Polk'; 'David Aylward (Comcare)'; 'Art
Botterell'; earlywarning@ietf.org; cap-list@incident.com
Cc: ltincher@evotecinc.com
Subject: RE: [earlywarning] [CAP] Definition of Warning Categories

Many of us know all about the DE.

Of course, we really, really, really would appreciate CAP and EDXL being
brought into alignment fully.  We do wish to use CAP.  

But EDXL-DE doesn't help with this discussion of categories, because it
doesn't define them either.


> -----Original Message-----
> From: earlywarning-bounces@ietf.org [mailto:earlywarning-
> bounces@ietf.org] On Behalf Of Timothy Grapes
> Sent: Monday, July 13, 2009 10:57 AM
> To: 'James M. Polk'; 'David Aylward (Comcare)'; 'Art Botterell';
> earlywarning@ietf.org; cap-list@incident.com
> Cc: ltincher@evotecinc.com
> Subject: 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@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@cisco.com]
> Sent: Sunday, July 12, 2009 9:58 PM
> To: David Aylward (Comcare); 'Art Botterell'; earlywarning@ietf.org;
> cap-list@incident.com
> Cc: Timothy Grapes; ltincher@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@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@lists.incident.com
> >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art
> Botterell
> >Sent: Sunday, July 12, 2009 3:23 PM
> >To: earlywarning@ietf.org; cap-list@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@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@ietf.org
> >https://www.ietf.org/mailman/listinfo/earlywarning
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]