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

["Hannes Tschofenig" <[e-mail]>]

Hey Carl, 

>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).

I like the idea of carrying generic alerting payloads. This is probably
something we should pick up. 

Ciao
Hannes

>
>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
>>
>
>
>_______________________________________________
>earlywarning mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/earlywarning
>