Subject: [Ecrit] Does it make sense to email to urn:service:sos?

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 30 Jan 2009 18:20:50 -0500

The subject of emailing an emergency request comes up from time to time.
So far, we've dismissed the idea primarily because email is not a real
time protocol.

In the U.S., we have started working towards supporting SMS for
emergency use.  The objection raised is "SMS is not a real time
protocol".

My response to the SMS issue is "although it's certainly true that it
isn't a real time protocol, and messages can be delayed by minutes,
hours, or even days, people use it as if it was real time, and deal with
the reality that it isn't.  Many users have an expectation that they
should be able to text to the emergency service".

Is that not true, perhaps to somewhat less degree, for email?  Users are
indeed less likely to treat email as real time, but in fact they often
use it as if it was.

Let us consider what it would take to allow email for emergency
services:
1. We would need a way to convey location in SMTP
2. We would need a way to mark an emergency email
3. We would need a way to route an emergency email
It goes without saying that a PSAP could send a reply email to the
originator.

2 and 3 could clearly be virtually identical to what we use for calls:
"dial string" translation to urn:service:sos, LoST routing to a URI,
regular email routing to that URI.  1 would require a new feature in
SMTP.  I'm not sure there is any analog to the "recognize the local dial
string, translate to the service urn, retarget to the PSAP URI", but it
does seem like a straightforward thing for an email server to do.

Does this make any sense?  Is there a good reason NOT to do it?

Brian

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 31 Jan 2009 14:31:19 +0200

Hi Brian, 

we have already everything in place that would allow emergency email to
work. 

Here are the building blocks: 

* LoST
* mails can obviously carry location as location is just another MIME type
* mechanisms to obtain location 

LoST allows different <uri> elements to be returned. In the examples we
spoke about SIP related URIs (including tel URIs) and XMPP URIs. Obviously
one can also put a mailto: URI in there. 

So, if the end point uses LoST to obtain the mailto: URI then it could send
the emergency email there. 

One important question is: Would email provider be interested in deploying
this? I suspect "no". Hence, it is better not to mark the mail as an
emergency email in the same way as we did the marking with the Service URN
in SIP. Instead, the theme would be to mark it for those you care and if
there is someone who does not care then it still gets routed to the right
place (rather than dropped on the floor). The fear that a user could do
fraud by marking emails as emergency emails is not really an issue for email
at all.

It might be possible to operate dedicated email providers only responsible
for handling emergency email routing as many email clients allow multiple
accounts to be maintained quite transparently.

The next important question is whether the PSAP operator really want this.
We all know that email does not really have a strong notion of security.
Even though there is DKIM standardized it isn't widely used. As such, there
is essentially no cryptographic identity with email the PSAP operators get
and email operators will not deploy new security security mechanisms for
this purpose either since the email operators will not like the emergency
email concept as it adds new obligations for them and no (monetary) benefit.
PSAPs might receive a lot of fake emergency mails and it might make them
difficult to figure out which onces are real.

The final aspect is on location suitable for dispatch: While our protocols
would support ways to fetch location by the PSAP operator from the access
provider using, for example, the location by reference concept we so far
know that (despite initial indications of interest) operators rather prefer
a model where they do not send anything to the end host. Even though the
location aspect is independent of the actual application service (voice, IM,
email, etc.) most operators would not see it that way. Hence, they would
only hand out location to the PSAP if the regulator forces them (and
sometimes not even then). This is more an procedural aspect than a technical
one.  
 
Did you think about an opt-in variant or not? 

Ciao
Hannes

PS: I see James already writing an RPH extension for email :-)

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Rosen, Brian
>Sent: 31 January, 2009 01:21
>To: [email-masked]
>Subject: [Ecrit] Does it make sense to email to urn:service:sos?
>
>So far, we've dismissed the idea primarily because email is 
>not a real time protocol.
>
>In the U.S., we have started working towards supporting SMS 
>for emergency use.  The objection raised is "SMS is not a real 
>time protocol".
>
>My response to the SMS issue is "although it's certainly true 
>that it isn't a real time protocol, and messages can be 
>delayed by minutes, hours, or even days, people use it as if 
>it was real time, and deal with the reality that it isn't.  
>Many users have an expectation that they should be able to 
>text to the emergency service".
>
>Is that not true, perhaps to somewhat less degree, for email?  
>Users are indeed less likely to treat email as real time, but 
>in fact they often use it as if it was.
>
>1. We would need a way to convey location in SMTP 2. We would 
>need a way to mark an emergency email 3. We would need a way 
>to route an emergency email It goes without saying that a PSAP 
>could send a reply email to the originator.
>
>"dial string" translation to urn:service:sos, LoST routing to 
>a URI, regular email routing to that URI.  1 would require a 
>new feature in SMTP.  I'm not sure there is any analog to the 
>"recognize the local dial string, translate to the service 
>urn, retarget to the PSAP URI", but it does seem like a 
>straightforward thing for an email server to do.
>

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 31 Jan 2009 17:09:59 -0600

SWIW

- email has no guarantee of delivery
- no guarantee of delivery to the right endpoint
- no guarantee of delivery to the an endpoint application that won't 
filter said message into the wrong directory/folder
- had a HIGH likelihood of SPAM on the recepient's end
- SPAM could in general become the biggest issue wrt actually having 
someone at the PSAP have to "look" at each and every message because 
no one can build in the proper automated filters to cover all 
possible misspellings of a legitimate email message
- every email application will have to be revved to incorporate 
location into some kind of user identifying indication this is for 
sos (maybe this is merely having the "urn:service:sos" in the To: 
header).  Many (most) users do not upgrade their mailers too often 
(like their home routers)... so this upgrade path will be an issue, 
because it likely cannot be universally expected by the network to be in place.
- MTAs don't have the ability to understand where "I am" to insert 
location, given the number of users that either

         -- use a generic application on any computer to access their email, or
         -- have a VPN

for example, I use the same laptop with an out of date email 
application (Eudora -- that's not supported anymore, and even if it 
was -- which version do I have?). I'm connecting via a VPN today from 
a suburb of Fort Worth through Cisco's Richardson facility (which is 
a suburb of Dallas) through Cisco San Jose (California).  Last wee I 
was in Barcelona, Spain.  I used the same VPN server in Richardson to 
get to the Cisco San Jose campus.  The only thing that changed was my 
origination point, one that cannot be tied to an IP address, because 
any VPN that I use going through Richardson - which gives my laptop 
one from its own address range.

To make matters worse, I have access to 16 other VPN connection 
points other than Richardson (in case I cannot get through via 
Richardson).  Some times these are accessed automatically, sometimes 
I purposely connect to another Cisco site than Richardson directly.

How does Cisco understand where I am connecting from?

I'm mostly focused on location URIs being inserted by a server in the 
network thinking it knows where I am (i.e., what we (use to?) call a 
"sighter" function).