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: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
>On Behalf Of Rosen, Brian
>Sent: 31 January, 2009 01:21
>To: ecrit at ietf.org
>Subject: [Ecrit] Does it make sense to email to urn:service:sos?
>
>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
>Ecrit at ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit
>
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit