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

[[e-mail]]

CAP was originally developed based primarily on US requirements and as
such may not reflect non-US regional considerations, policies, etc. This
may be why groups outside the US are developing profiles with extensions -
which is not necessarily good for interoperability. That said, there is
some coordination of these activities occurring in OASIS as part of the
CAP profiling and CAP 2.0 activity.

I am sure Art can add more of a perspective on this.

Another touch point is that the European community is defining and
prototyping an event based alerting architecture that is coordinated with
the INSPIRE (pan-European spatial data infrastructure) activity. The
architecture is payload agnostic and can support any number of alerting
payload encodings (CAP, GeoRSS, Atom based, other).

Carl



 > Hi Keith,
>
>>Firstly, I am not sure the identification of the types of
>>warnings I wish to subscribe to, and the nature of the
>>warning, are necessarily one and the same thing, yet that
>>seems to be assumed by the drafts.
>
> If you want to subscribe to certain alerts then there better should be a
> relationship otherwise the point of including any information about
> desired
> alerts is a bit mood.
>
> Henning was a bit doubtful of the benefit of subscribing to separate
> categories of alerts. Someone else suggested that this should be left to a
> manual procedure of picking the right server that has a certain type of
> alert messages to distribute, e.g., weather alerts.
>
>>
>>Secondly, surely we should be seeking some alignment of
>>warning types between the different delivery mechanisms.
>
> This is not the feedback I got from others.
>
>>I
>>note that we have lists in
>>http://tools.ietf.org/html/draft-rosen-sipping-cap-04 and
>>http://tools.ietf.org/html/draft-rosen-ecrit-lost-early-warning
>>-01 that are aligned with each other, but bear no relationship
>>with those being defined in other bodies.
>
> Well. I took these terms from the categories in the CAP specification.
>
>
>>
>>For example 3GPP TS 22.268 defines the umbrella for warnings
>>provided by the cell broadcast service
>>
>>http://www.3gpp.org/ftp/Specs/html-info/22268.htm
>>
>>This defines a structure that incorporates at least ETWS for
>>the far east, and CMAS for north america. Europe is still
>>working on a coordinated set of requirements.
>>
>>and you will find the message identifiers for these two in
>>3GPP TS 23.041
>>
>>http://www.3gpp.org/ftp/Specs/html-info/23041.htm
>>
>>Including recent expansions which have not yet appeared in the
>>published document these come down to:
>>
>>ETWS CBS Message Identifier for earthquake warning message.
>>ETWS CBS Message Identifier for tsunami warning message.
>>ETWS CBS Message Identifier for earthquake and tsunami
>>combined warning message.
>>ETWS CBS Message Identifier for test message.
>>ETWS CBS Message Identifier for messages related to other
>>emergency types.
>>ETWS CBS Message Identifier for future extension.
>
> Thanks for these pointers. Interesting to see that there are different
> categories being used compared to the CAP work.
>
>
> Ciao
> Hannes
>
>>regards
>>
>>Keith
>>
>>
>>
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of James M. Polk
>>> Sent: Monday, July 13, 2009 2:58 AM
>>> To: David Aylward (Comcare); 'Art Botterell'; [e-mail];
>>> [e-mail]
>>> Cc: Timothy Grapes; [e-mail]
>>> 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)
>>> >[e-mail]
>>> >
>>> >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: [e-mail]
>>> >[mailto:[e-mail]] On Behalf Of
>>> Art Botterell
>>> >Sent: Sunday, July 12, 2009 3:23 PM
>>> >To: [e-mail]; [e-mail]
>>> >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_abb
>>> rev=emerge
>>> >ncy
>>> >CAP-list mailing list
>>> >[e-mail]
>>> >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
>>> >[e-mail]
>>> >https://www.ietf.org/mailman/listinfo/earlywarning
>>>
>>> _______________________________________________
>>> earlywarning mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>
>>_______________________________________________
>>earlywarning mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/earlywarning
>>
>
> _______________________________________________
> earlywarning mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/earlywarning
>