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

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 12 Jul 2009 21:58:16 +0300

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
 
>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>Elizabeth F. Klute
>Sent: 12 July, 2009 20:28
>To: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: [CAP] Definition of Warning Categories
>
>Thanks Art,
>
>I was struggeling on how to answer but could not have done it better!
>Elizabeth Klute, Director Disaster Management
>
>----- Original Message -----
>From: [email-masked] 
><[email-masked]>
>To: [email-masked] <[email-masked]>; 
>[email-masked] <[email-masked]>
>Sent: Sun Jul 12 11:51:43 2009
>Subject: Re: [CAP] Definition of Warning Categories
>
>On Jul 12, 2009, at 7/12/09 3:58 AM, Hannes Tschofenig wrote:
>> I was wondering whether there is somewhere a more verbose / more 
>> complete description of the semantic of the individual values.
>
>No, and that's deliberate.  Considering the high levels of 
>uncertainty that so often surround emergent events, the CAP 
>designers (first in the CAP Working Group and later within 
>OASIS) struggled to balance completeness against specificity.  
>There was also a concern that we could get bogged down in 
>trying to perfect the taxonomies and wind up with no standard at all.
>
>So the definitions were deliberately left somewhat open-ended 
>and contextual... some would go so far as to say "vague" and 
>I, for one, wouldn't argue.
>
>- Art
>
>
>
>_______________________________________________
>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_abbre
>v=emergency
>CAP-list mailing list
>[email-masked]
>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.
>_______________________________________________
>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_abbre
>v=emergency
>CAP-list mailing list
>[email-masked]
>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.
>

---

From: Art Botterell <[email-masked]>
Date: Sun, 12 Jul 2009 12:23:12 -0700

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 12 Jul 2009 16:17:37 -0400

I'm also not convinced that categories are all that useful, at least  
among different kinds emergencies. It seems a bit far-fetched to say  
"I want to know if there's a tsunami, but not a tornado or chemical  
leak, affecting my area". There are likely to be non-emergency  
categories, such as school closings or traffic alerts, that may have  
more limited appeal, but may use the same basic infrastructure.

Henning

On Jul 12, 2009, at 3:23 PM, Art Botterell wrote:

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

---

From: "David Aylward \(Comcare\)" <[email-masked]>
Date: Sun, 12 Jul 2009 16:41:44 -0400

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)
[email-masked]
 
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: [email-masked]
[mailto:[email-masked]] On Behalf Of Art Botterell
Sent: Sunday, July 12, 2009 3:23 PM
To: [email-masked]; [email-masked]
Subject: Re: [CAP] Definition of Warning Categories

- Art

On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote:

> Now, with the work on
http://tools.ietf.org/html/draft-rosen-sipping-cap-03

_______________________________________________
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
[email-masked]
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.

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 12 Jul 2009 20:58:07 -0500

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 15 Jul 2009 15:09:19 +0200

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. 

Secondly, surely we should be seeking some alignment of warning types between the different delivery mechanisms. 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.

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.

CMAS CBS Message Identifier for Presidential Level Alerts.
CMAS CBS Message Identifier for Extreme Alerts with Severity of Extreme, Urgency of Immediate, and Certainty of Observed.
CMAS CBS Message Identifier for Extreme Alerts with Severity of Extreme, Urgency of Immediate, and Certainty of Likely.
CMAS CBS Message Identifier for Extreme Alerts with Severity of Extreme, Urgency of Expected, and Certainty of Observed.
CMAS CBS Message Identifier for Extreme Alerts with Severity of Extreme, Urgency of Expected, and Certainty of Likely.
CMAS CBS Message Identifier for Severe Alerts with Severity of Severe, Urgency of Immediate, and Certainty of Observed.
CMAS CBS Message Identifier for Severe Alerts with Severity of Severe, Urgency of Immediate, and Certainty of Likely.
CMAS CBS Message Identifier for Severe Alerts with Severity of Severe, Urgency of Expected, and Certainty of Observed.
CMAS CBS Message Identifier for Severe Alerts with Severity of Severe, Urgency of Expected, and Certainty of Likely.
CMAS CBS Message Identifier for Child Abduction Emergency (or Amber Alert).
CMAS CBS Message Identifier for the Required Monthly Test.
CMAS CBS Message Identifier for CMAS Exercise.
CMAS CBS Message Identifier for operator defined use.
CMAS CBS Message Identifier for future extension.

I don't see any alignment between these lists and those in the internet-drafts, yet surely you will have the same content providers generating these messages, and the same receivers receiving these messages.

Note that the ETWS set are already in deployment (they formed part of 3GPP release 8). I believe the CMAS ones are based on input discussed first in ATIS.

ITU-T SG2 also believe they are playing in this space.

regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James M. Polk
> Sent: Monday, July 13, 2009 2:58 AM
> To: David Aylward (Comcare); 'Art Botterell'; 
> [email-masked]; [email-masked]
> Cc: Timothy Grapes; [email-masked]
> Subject: Re: [earlywarning] [CAP] Definition of Warning Categories
> 
> All
> 
> 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.
> 
> 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.
> 
> 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
> 
> >"broadcast to the world" standard.  It is excellent for that 
> purpose, 
> >but not for the more refined purpose you are pursuing.
> >
> >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.
> >
> >
> >This communication is intended for the use of the recipient 
> to which it 
> >is addressed, and may contain confidential, personal and/or 
> privileged 
> >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.
> >
> >
> Art Botterell
> >leading to missed alerts either because of differing 
> interpretations of 
> >categories or of unforeseen events that don't fit our preconceived 
> > > 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
> > > to certain type of events: you might indicate something like 
> > > location and the type of events you are interested in.
> > >
> >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.
> >http://www.oasis-open.org/committees/comments/form.php?wg_abb
> rev=emerge
> >ncy
> >CAP-list mailing list

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 15 Jul 2009 09:22:38 -0400

> 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…
These are all subjects that were discussed at some length at
the recent Geneva workshop on alert identifiers.  It's also
apparent that there are many active user communities worldwide
who have evolved their implementations, secretariats, and
administrative processes.  The WMO has its own ecosystem
based on international agreements and has served as a point
of convergence - especially with Eliot Christian's presence.

Somehow the dialogue on this list seems disconnected from
this larger active global ecosystem.  It's not clear what you do
about this, but the "they should come here" approach will not
work.

--tony

-- 
Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 15 Jul 2009 16:21:17 +0300

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. 

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

Thanks for these pointers. Interesting to see that there are different
categories being used compared to the CAP work.

Ciao
Hannes

>> To: David Aylward (Comcare); 'Art Botterell'; [email-masked]; 
>> [email-masked]
>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.
>> 
>> necessarily need to care, therefore I will likely NOT want 
>to get this 
>> messages.
>> 
>what they 
>Protocol.

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 15 Jul 2009 10:18:03 -0400

Hi Hannes,
> Are there meeting minutes available from the workshop?
>   
All docs are at
<http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html>
The output is Doc. 4.1
> What specific part do you think is disconnected from the "global
> ecosystem"?
User communities and implementors.  These are active, globally
distributed communities that seem to have their own networks of
communication and collaboration.  Many are not in the "West."
Even in West, they are stovepiped in different agencies and disciplines.

I appreciate the challenge, as my Q.4/17 standards group in ITU-T is
responsible for the international version of the CAP Standard, X.1303,
including the ASN.1 translation, and it's constantly a "wack a mole"
effort of keeping track of who is doing what.
> As we have learned already from the previous discussion about the emergency
> services categories there is no single overall community to talk to, as this
> community seems to be quite fragmented. From my citizen-to-authority
> emergency services experience I can tell you that you cannot create such a
> "single community" regardless of how much work you spend. 
>   
Yes and no.  The authority-to-citizen realm has been around for
many decades, and threads through countless generic and specialized
local, national, regional, and international bodies/agencies and
activities. 
You can't ignore them.   On the other hand, you don't want to spend
all of your efforts playing the liaison game and getting no work done.

Eliot Christian has spent the past several years facilitating US national
and now global coordination among these communities - especially with
respect to CAP use.  He works full time doing this in Geneva for one
of the core international organizations in this arena - WMO.  As he
indicated:
> WMO recently compiled responses to a questionnaire concerning 
> official alerting authorities. This should give us a database of 
> alerting authorities of the 132 responding nations. A WMO office 
> in China (Hong Kong Observatory) is putting that online. I imagine 
> we can use this as a seed for rationalizing among the various 
> official directories that exist at other international venues.
Seems like a good path forward.

--tony

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 15 Jul 2009 16:39:52 +0300

Hi Tony, 

>the recent Geneva workshop on alert identifiers.

>  It's also 
>administrative processes.  The WMO has its own ecosystem based 
>on international agreements and has served as a point of 
>convergence - especially with Eliot Christian's presence.
>
>Somehow the dialogue on this list seems disconnected from this 
>larger active global ecosystem.  It's not clear what you do 
>about this, but the "they should come here" approach will not work.

What specific part do you think is disconnected from the "global ecosystem"?

Ciao
Hannes

---

From: [email-masked]
Date: Wed, 15 Jul 2009 12:44:24 -0400 (EDT)

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

---

From: Art Botterell <[email-masked]>
Date: Wed, 15 Jul 2009 10:02:19 -0700

On Wed, Jul 15, 2009 at 6:39 AM, Hannes Tschofenig <
[email-masked]> wrote:

>  From my citizen-to-authority emergency services experience I can tell you
> that you cannot create such a

I think that's right.  Emergency services don't function as a separate
community, but rather as a facet of the larger communities and cultures they
serve.  Notions like "authority" and even "emergency" are constructed very
differently in different places and in different contexts.

(For an example of how subtle and controversial even seemingly simple
notions of emergency response can be, see my blog entry on standards of
practice for public warning at <http://www.incident.com/blog>... I'm
presenting it at the Natural Hazards Workshop in Boulder Colorado this
week.  Note also that "public warning" in the tactical sense and "early
warning" of significant events are themselves quite different topics.)

What we're really talking about here seems to be how to apply SIP to urgent
one-to-many notifications.  Maybe if it were explicit that narrower, more
technical goal would be more tractable.

- Art

---

From: Art Botterell <[email-masked]>
Date: Wed, 15 Jul 2009 10:13:06 -0700

On Wed, Jul 15, 2009 at 9:44 AM, <[email-masked]> wrote:

> such may not reflect non-US regional considerations, policies, etc.

Um... I'm not sure that's entirely correct.  The basis of the CAP design was
social science research on warning message effectiveness, and both that body
of research and the membership of the original CAP Working Group were quite
international.

It's true that a lot of the application of CAP has taken place in the U.S.,
and that's a constant concern.  However, we've managed to keep CAP
international enough that the ITU was able to endorse it (as recommendation
x.1303).

Profiles, as long at they're truly profiles (which is to say, strict subsets
of the CAP specification) enable different communities to define local
usages without breaking basic compatibility with other CAP implementations.
Again, it's been a struggle sometimes to prevent profiles from becoming
localized extensions of the standard, which wouldn't be interoperable, but I
think we've done reasonably well so far.

I'd also suggest that it may be confusing to talk about CAP in the same
breath with GeoRSS or Atom.  CAP is a content structure, while RSS and Atom
are indexing schemes that themselves refer to other content, including
sometimes CAP.

- Art

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 15 Jul 2009 20:27:02 +0300

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.
>>
>> 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.
>>
>>>
>warning types 
>>>between the different delivery mechanisms.
>>
>>>-01 that are aligned with each other, but bear no relationship with 
>>>those being defined in other bodies.
>>
>>>For example 3GPP TS 22.268 defines the umbrella for warnings 
>provided 
>>>by the cell broadcast service
>>>
>>>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.
>>>
>>>> say. I just won't reach for my (whatever) device if it's 
>just out of 
>>>> my reach.
>>>>
>>>> > > I should provide a bit more feedback about the 
>background to my 
>>>> > > question.
>>>> > >
>>>> > > we wanted to define an event package for SIP that 
>allows you to 
>>>> > > "subscribe"

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 15 Jul 2009 20:25:07 +0300

Hi Art, 

~snip~

#	What we're really talking about here seems to be how to apply SIP to
urgent one-to-many notifications.  Maybe if it were explicit that narrower,
more technical goal would be more tractable.

For me the scope of the work is quite narrow.

I re-wrote the requirements, terminology and framework document
http://tools.ietf.org/id/draft-norreys-ecrit-authority2individuals-requireme
nts-03.txt
based also on your feedback to re-scope the work. 

Then, there is the SIP CAP document 
http://tools.ietf.org/html/draft-rosen-sipping-cap-04
(It needs to get re-written a bit to better incorporate the new terminology.
Maybe requesting specific warning categories is a bad idea and needs to be
deleted.)

There is also a document
http://tools.ietf.org/id/draft-rosen-ecrit-lost-early-warning-01.txt that
may be needed to discover servers dynamically. But this is clearly more into
the future.

Looking at the XMPP work
http://xmpp.org/extensions/xep-0127.html
we could get away with only a single document, namely the SIP CAP stuff.

I would scope the initial work in that way. 

Ciao
Hannes	

	- Art

---

From: "Timothy Grapes" <[email-masked]>
Date: Mon, 13 Jul 2009 10:57:03 -0400

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
[email-masked]
http://www.evotecinc.com/
"When your work speaks for itself, don't interrupt"
- Henry J. Kaiser

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Sunday, July 12, 2009 9:58 PM
To: David Aylward (Comcare); 'Art Botterell'; [email-masked];
[email-masked]

All

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.

James

>machine to machine routing based on incident type, role and similar
factors,
> > location and

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 17 Jul 2009 09:06:23 -0400

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.

Brian

> From: [email-masked] [mailto:earlywarning-
> [email-masked]] On Behalf Of Timothy Grapes
> Sent: Monday, July 13, 2009 10:57 AM
> To: 'James M. Polk'; 'David Aylward (Comcare)'; 'Art Botterell';
> Cc: [email-masked]
> This
> >http://www.oasis-
> open.org/committees/comments/form.php?wg_abbrev=emergency
> >CAP-list mailing list

---

From: "Timothy Grapes" <[email-masked]>
Date: Fri, 17 Jul 2009 09:29:42 -0400

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:
<contentKeyword>
<valueListUrn>valueListUrn</valueListUrn>
<value>value</value>
</contentKeyword>
where the content of <valueListUrn> is the Uniform Resource Name of a
published
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>
within
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
message
processor, event stage, resource code and response type.
Subelements
• valueListUrn
• value
Used In contentObject

Thanks,
Tim Grapes

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, July 17, 2009 9:06 AM
To: 'Timothy Grapes'; 'James M. Polk'; 'David Aylward (Comcare)'; 'Art
Botterell'; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [earlywarning] [CAP] Definition of Warning Categories

Brian