Subject: [Sipping] comments on draft-rosen-sipping-cap-00

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Aug 2007 17:42:22 -0400

A late follow-up on some of the comments on this draft:

I think there are actually (at least) three levels of authority-to- 
citizen alerts, with equivalents today:

(1) The "Big One": This is the emergency alert system (EAS), i.e.,  
the annoying buzz sound on the radio and the "This is a test. This is  
only a test. If this were a real emergency, Cheney would be at an  
undisclosed location and you would be on your own, up a (big) creek  
without a paddle."

These alerts presumably only occur very rarely, hopefully never.  
Precise geographic targeting is less important than immediate and  
efficient delivery to very large populations. Delivery would likely  
be assured by repeated attempts, rather than confirmation.

Multicast, whether SSM or some ALM version, sounds like a reasonable  
approach for that. Even flooding, if tightly access-controlled, may  
be appropriate, given the rarity and immediacy requirement.

(2) Local events of some urgency: severe weather advisory, boil water  
alert (we had one recently after a water treatment plant failure  
where some communities used the 'reverse 911' system), "amber alert",  
school closing. Many communities use "reverse 911" phone systems for  
that and there are commercial services that offer this as a service.  
Some of these services target a school district, rather than a  
community or may be internal to a (large) corporation, such as  
Walmart or the US Postal Service. [I have no idea whether either of  
these companies use such systems.] Generally tightly geographically  
targeted since the information is useless or harmful outside the  
targeted geographic area. You don't want to tell somebody on a  
different water system to boil their water unnecessarily and you  
certainly don't want to wake them at 5 in the morning.

Phone calls seem to scale today, so I see no reason that SIP  
notifications couldn't. Frequency of these alerts might be a few a  
year. Clearly, subscriptions have to contain filters on events and  
locations, but we already have the necessary tools for both.  
Subscriptions would also likely have much longer refresh intervals,  
measured in months. Delivery rates today are hundreds of calls a  
minute, so SIP notification/IM or similar systems can certainly  
provide equivalent or better service.

There is really only a modest difference between a MESSAGE and a SUB/ 
NOT system here, with the latter having the slight advantage that we  
have filters and named events already.

(3) Local events of modest urgency: school delays, cancellation of  
boil water alerts, street closings, "rash of burglaries in the area".  
This is probably best served by email alerts since you presumably  
don't want to wake anybody at that moment. Indeed, my town (Leonia,  
NJ) has a police-run mailing list for such announcements. Anybody can  
sign up and it is community-targeted.

In all cases, there's the question whether the alert is meant for  
immediate human consumption (plain text, say) or CAP. I can see uses  
for both and it seems best to allow the client to pick the format.

Some alerts presumably will go out on all three modalities or the  
same event will trigger alerts on all three systems at different  
times. (Email alert when hurricane is named; SIP notification when  
evacuation is ordered; EAS when it's time to head for the storm  
shelter.)

Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 17 Aug 2007 18:57:16 -0400

One bone to pick and one worry with this, otherwise I generally agree:

There is a requirement to NOT send only "human readable text".  Not every
human can read text in whatever language you send it.  You need to classify
every message in ways that systems for disabled folks can render it
appropriately.  You want some pretty structured language so that automatic
translation into different languages works.  This is one of the reasons why
EAS has been mandated to change to CAP.

I'm a little wary of location based email; not because I don't think it can
be made to work, but because it seems like a lot of work to make it work.  I
think you still have to get the location of the recipient or some other
target into the routing.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, August 16, 2007 5:42 PM
> To: sipping
> Subject: [Sipping] comments on draft-rosen-sipping-cap-00
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 Aug 2007 21:38:57 -0400

> EAS has been mandated to change to CAP.

I see the need for both, by choice of the consumer. Not every device  
will be able to interpret CAP in a meaningful way.

The language issue isn't solved by CAP, as much of the text between  
<> is still in, say, English. I'm picking the CAP 1.0 example,  
truncated:

<?xml version = "1.0" encoding = "UTF-8"?>
<alert xmlns = "http://www.incident.com/cap/1.0">

<event>Homeland Security Advisory System Update</event>
<urgency>Immediate</urgency>
<severity>Severe</severity>
<certainty>Likely</certainty>
<senderName>U.S. Government, Department of Homeland Security</ 
senderName>
<headline>Homeland Security Sets Code ORANGE</headline>
<description>The Department of Homeland Security has elevated the  
Homeland
Security Advisory System threat level to ORANGE / High in response to
intelligence which may indicate a heightened threat of terrorism.</ 
description>

This doesn't make much sense if you only speak Chinese. (It doesn't  
make much sense in English, but that's not a language problem.)

> think you still have to get the location of the recipient or some  

The location-based email is only useful for residential users.  
However, many users will want to get alerts based on their primary  
residence anyway, regardless of their current physical location.  
(When I'm working in NYC or traveling with my cell phone, I still  
want school closing alerts for my town in NJ, not NYC or Chicago.)

For those uses, I don't see this as a difficult problem. LoST can  
trivially announce a corresponding sign-up URL for a community, say.

As I mentioned, this works today, with no heavy lifting. We just have  
to be realistic what it is useful for; real-time alerts for travelers  
are probably not among those.

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 18 Aug 2007 09:05:23 -0400

> <> is still in, say, English. I'm picking the CAP 1.0 example,
My message said "structured language".  Turns out that there are ways you
can express things in a restricted domain such that machine language
translation works much better.  That isn't a CAP problem completely, but it
helps when you know where things like addresses are.  The more structure you
have, the more likely it will work.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 18 Aug 2007 10:48:52 -0400

I don't think we're disagreeing, but it's not clear to me that such  
translation is best performed by the end system. It seems much easier  
to have a well-tuned and tested application running at the NYPD than  
relying on Babelfish in an end system, structured or not.

To be clearer: I think both end systems ("consumers", "citizens")  
should be able to subscribe to either a CAP version or a text  
version. Intermediaries, provided by local authorities or some not- 
for-profit or commercial service bureau, can offer translation  
services, based on the structured version.

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 18 Aug 2007 14:14:57 -0400

Yeah, I can see that working.  I don't think the translation is in the end
device, but we need the structured text to create a cascade: the translator
subscribes to the event, people who need the translation subscribe to that.

Brian

> Sent: Saturday, August 18, 2007 10:49 AM
> To: Brian Rosen
> Cc: 'sipping'
> Subject: Re: [Sipping] comments on draft-rosen-sipping-cap-00
>