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

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 1 Feb 2009 12:07:28 +0200

Hi James,  

I agree with many of your statements. 

I also agree with the installed base that does not support this
functionality. This almost sounds like the VoIP emergency story to me. 

I also agree with the location aspect. Also like in VoIP. 

Ciao
Hannes

>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).
>
>
>At 06:31 AM 1/31/2009, Hannes Tschofenig wrote:
>>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?
>> >
>> >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
>> >
>>
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ecrit
>

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

---

From: ken carlberg <[email-masked]>
Date: Sun, 1 Feb 2009 07:52:24 -0500

Gentleman,

This note probably goes a bit beyond what Brian first brought up, but  
there are other things to keep in mind...

The fact that email runs over TCP and its adaptive algorithms helps  
diminish enthusiasm in augmenting email.  But as Brian indirectly  
points out, its the buffer consumption at intermediate servers (ie,  
MTAs) where the bottleneck occurs.  And keep in mind that large  
companies will generally have several MTAs needed to simply exit their  
stub domain.  In my old company of 40k+ employees, we would receive  
email messages from admins every November asking that we don't send  
the dancing Santa video during December to decrease the chances of the  
outgoing MTA getting clogged.

And while I also agree with a number of points brought up by James,  
its important to note that this is under the context of SMTP.  X.400  
has extensions that distinguish the importance of email in order to  
get past the MTA bottleneck problem.  Now, before folks say that X.400  
is really a blip in the overall installed based of email systems, I'll  
agree with you.  Its deployment is mostly confined to organizations  
that must have prioritization of email -- eg, DoD, MoD, NATO.  And  
NATO is of particular importance on this example because while it is a  
restricted federation from the perspective of the rest of the  
Internet, it still represents a collection of separate administrative  
domains, thereby escaping the counter argument that its purely a  
walled garden.  (Note that the collection tier-1 ISPs is also a type  
of restricted federation in terms of participants).  But the point is  
that X.400 has a market because it does something that is not  
standardized with SMTP during emergencies, or importantly, event- 
driven spikes of traffic load.

So, if we go back to Brian's original point of "we want to mark  
emergency mail", I think a couple of questions to ask is in what form  
and to what degree of versatility do you want this marking?  And is  
the form to be binary (eg, SoS in the URL), or is it to be something  
more along the lines of rfc-4412 and an additional header in the SMTP  
message?

For your reading entertainment purposes only, you can look at an  
expired (and somewhat incomplete) draft-rfc on the subject at
http://ftp.iasi.roedu.net/Docs/internet-drafts/draft-schmeing-smtp-priorities-05.txt

cheers,

-ken

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 1 Feb 2009 16:26:13 +0200

To Brian: Are you thinking about an opt-in solution or not?  

To Ken: "form to be binary (eg, SoS in the URL), or is it to be something
more along the lines of rfc-4412"

The marking Brian mentioned is from http://www.ietf.org/rfc/rfc5031.txt. I
wouldn't call it binary given that it allows to express different types of
emergencies. 

Ciao
Hannes

>From: ken carlberg [mailto:[email-masked]] 
>Sent: 01 February, 2009 14:52
>To: Hannes Tschofenig
>Cc: 'James M. Polk'; 'Rosen, Brian'; [email-masked]
>Subject: Re: [Ecrit] Does it make sense to email to urn:service:sos?
>
>Gentleman,
>
>This note probably goes a bit beyond what Brian first brought 
>up, but there are other things to keep in mind...
>
>The fact that email runs over TCP and its adaptive algorithms 
>helps diminish enthusiasm in augmenting email.  But as Brian 
>indirectly points out, its the buffer consumption at 
>intermediate servers (ie,
>MTAs) where the bottleneck occurs.  And keep in mind that 
>large companies will generally have several MTAs needed to 
>simply exit their stub domain.  In my old company of 40k+ 
>employees, we would receive email messages from admins every 
>November asking that we don't send the dancing Santa video 
>during December to decrease the chances of the outgoing MTA 
>getting clogged.
>
>And while I also agree with a number of points brought up by 
>James, its important to note that this is under the context of 
>SMTP.  X.400 has extensions that distinguish the importance of 
>email in order to get past the MTA bottleneck problem.  Now, 
>before folks say that X.400 is really a blip in the overall 
>installed based of email systems, I'll agree with you.  Its 
>deployment is mostly confined to organizations that must have 
>prioritization of email -- eg, DoD, MoD, NATO.  And NATO is of 
>particular importance on this example because while it is a 
>Internet, it still represents a collection of separate 
>administrative domains, thereby escaping the counter argument 
>that its purely a walled garden.  (Note that the collection 
>tier-1 ISPs is also a type of restricted federation in terms 
>of participants).  But the point is that X.400 has a market 
>because it does something that is not standardized with SMTP 
>during emergencies, or importantly, event- driven spikes of 
>traffic load.
>
>So, if we go back to Brian's original point of "we want to 
>mark emergency mail", I think a couple of questions to ask is 
>in what form and to what degree of versatility do you want 
>this marking?  And is the form to be binary (eg, SoS in the 
>URL), or is it to be something more along the lines of 
>rfc-4412 and an additional header in the SMTP message?
>
>For your reading entertainment purposes only, you can look at 
>an expired (and somewhat incomplete) draft-rfc on the subject 
>at 
>>> - no guarantee of delivery to the an endpoint application 
>that won't 
>>> filter said message into the wrong directory/folder
>>> - 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
>>>
>>> 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.
>>>
>>> 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).
>>>
>>>
>>>> * mails can obviously carry location as location is just another 
>>>> MIME type
>>>> 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
>>>> fear that a user could do fraud by marking emails as emergency 
>>>> emails is not really an issue for email at all.
>>>>
>>>> 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
>>>> 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.
>>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 2 Feb 2009 06:05:24 -0500

Hannes,

not disagreeing, but email has also become a favorite tool for  
automated event notifications, in the absence of other widely-deployed  
and interoperable mechanisms. In limited scenarios, such as automated  
alarms, this may be more robust than alternatives (such as IM and SMS).

Compared to SMS, the sender (if it directly submits the email, rather  
than through a queueing sendmail) gets a good indication that the  
email has reached the destination domain.

One could imagine special-purpose setups, such as an alarm monitoring  
company or a chemical plant with automated sensors, where  
authentication is not a big deal (since the alarm company/chemical  
company can easily cryptographically sign the email via S/MIME and the  
number of such companies is modest on a local level and their  
identities are known).

In other words, I have a hard time picturing the local police chief  
telling their citizenry to send email when the house is on fire, but  
specialized arrangements may make sense, given the widely deployed  
infrastructure.

Henning

On Jan 31, 2009, at 7:31 AM, Hannes Tschofenig wrote:

> Hi Brian,
>
> we have already everything in place that would allow emergency email  
> to
> work.
>
> LoST allows different <uri> elements to be returned. In the examples  
> we
> So, if the end point uses LoST to obtain the mailto: URI then it  
> could send
> the emergency email there.
>
> 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.
>
> 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.
> 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.
> them
> difficult to figure out which onces are real.
>
> 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.
>
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Rosen, Brian
>> 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".
>>
>> 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.
>>
>> 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.
>>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 2 Feb 2009 13:11:59 +0200

I agree with you, Henning. In his short mail Brian left a couple of
things unanswered including the scenarios where he envisions emergency
email to be used.  

Hannes

>On Behalf Of ext Henning Schulzrinne
>Sent: 02 February, 2009 13:05
>To: Hannes Tschofenig
>Cc: 'Rosen, Brian'; [email-masked]
>automated event notifications, in the absence of other 
>widely-deployed and interoperable mechanisms. In limited 
>scenarios, such as automated alarms, this may be more robust 
>than alternatives (such as IM and SMS).
>
>Compared to SMS, the sender (if it directly submits the email, 
>rather than through a queueing sendmail) gets a good 
>indication that the email has reached the destination domain.
>
>One could imagine special-purpose setups, such as an alarm 
>monitoring company or a chemical plant with automated sensors, 
>where authentication is not a big deal (since the alarm 
>company/chemical company can easily cryptographically sign the 
>email via S/MIME and the number of such companies is modest on 
>a local level and their identities are known).
>
>In other words, I have a hard time picturing the local police 
>chief telling their citizenry to send email when the house is 
>on fire, but specialized arrangements may make sense, given 
>the widely deployed infrastructure.
>
>Henning
>
>> to work.
>> we spoke about SIP related URIs (including tel URIs) and XMPP URIs.
>> Obviously
>> So, if the end point uses LoST to obtain the mailto: URI 
>then it could 
>> those you care and if there is someone who does not care 
>then it still 
>> 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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 2 Feb 2009 09:51:56 -0500

See inline

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of James M. Polk
> Sent: Saturday, January 31, 2009 6:10 PM
> To: Hannes Tschofenig; 'Rosen, Brian'; [email-masked]
Neither does SMS.  Really, "guarantee of delivery" could mean many things,
some of which apply to sip

> - no guarantee of delivery to the right endpoint
Neither does SMS, nor SIP.  What is "right"?  The one you intended?

> - no guarantee of delivery to the an endpoint application that won't
Definitely true of sip (think spit filtering).  Somewhat more true than SMS
which typically is not filtered into directories

> - had a HIGH likelihood of SPAM on the recepient's end
Increasingly true of SMS, but this is true, sadly

> - 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 doubt about it.  Not clear that is reason enough to kill the idea, but
it's certainly an issue.  On the other hand, that would argue that no
improvement to email other than spam related improvements should be
accepted.

> because it likely cannot be universally expected by the network to be
> in place.
Yes.  Also true of every other system (SMS, SIP, legacy wireline/wireless
networks, ...)

>          -- use a generic application on any computer to access their
Each email client has to be upgraded, but if that happened, it works.  The
MTA doesn't know where the user is unless the user tells them.  Same as SIP.

>          -- have a VPN
This is exactly the same problem as a SIP softclient, with the same answer.

> 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
If you were using an outdated version of X-lite to make phone calls, you
would have all of these problems, exactly the same way.

> Richardson).  Some times these are accessed automatically, sometimes
The access network tells your PC, your PC tells the client, the client tells
the server.

> 
> 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).
I think the client adds location.  The client queries via LoST.  The MTA is
transparent.

Just like a SIP server.  The server may be able to help an un-upgraded
client, just like some SIP servers could, but it wouldn't always work, and
VPNs are examples of things that wouldn't work.

> >So, if the end point uses LoST to obtain the mailto: URI then it could
> send
> >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
> >fraud by marking emails as emergency emails is not really an issue for
> email
> >at all.
> >
> there
> >is essentially no cryptographic identity with email the PSAP operators
> get

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 2 Feb 2009 09:55:49 -0500

You can invent scenarios where it makes more sense to use email that other
scenarios, but you can't stop people from using it in any scenario they want
to (that is, the emergency system can't filter email based on the scenario).

Brian

> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Monday, February 02, 2009 6:12 AM
> To: ext Henning Schulzrinne; Hannes Tschofenig
> Cc: Rosen, Brian; [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 2 Feb 2009 09:55:41 -0500

There is no priority for emergency calls in the PSTN today.  I would not
expect any tomorrow, although I'd like to allow it (RPH).  

I would not expect any priority for emergency SMS.

I would not expect any priority for emergency email.

I am not sure what the right thing to do with marking is.  The easiest thing
is to recognize the "dial string" and translate that to the "PSAP URI" using
LoST.  That would be a mailto, and would get the email to the right place.

What should the "dial string" for email be?  I'm not sure.

Brian

> Of ken carlberg
> Sent: Sunday, February 01, 2009 7:52 AM
> To: Hannes Tschofenig
> >>> MIME
> >>> with
> >>> such,
> >>> not
> >>> not

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 2 Feb 2009 17:04:02 +0200

Hi Brian, 

>There is no priority for emergency calls in the PSTN today.  I 
>would not expect any tomorrow, although I'd like to allow it (RPH).  
>

Thanks for saying that. 

>
>I am not sure what the right thing to do with marking is.  The 
>easiest thing is to recognize the "dial string" and translate 
>that to the "PSAP URI" using LoST.  That would be a mailto, 
>and would get the email to the right place.
>
I believe it could be anything since there is no user expectation about it
yet.
I could imagine that a button on the UI would do it. 

This relates to the question of the usage scenario: Henning mentioned one
where there isn't a user. Hence, the problem does not come up in the first
place. 
When you think about users that opt-in for a usage of emergency mail then
they could be told how to use it.
The additional advantage of the opt-in solution is that you could deal much
better with security. 

Ciao
Hannes

>On Behalf 
>administrative 
>> >> 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
>network to 
>> >> be in place.
>access their 
>> >> 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.
>> >>
>> >> sometimes I purposely connect to another Cisco site than 
>Richardson 
>> >> directly.
>> >>
>> >> 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).
>> >>
>> >>
>> >>> 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
>> >>> such, there is essentially no cryptographic identity with email 
>> >>> the PSAP operators get and email operators will not deploy new
>> >> security security
>> >>> PSAPs might receive a lot of fake emergency mails and it might 
>> >>> make them difficult to figure out which onces are real.
>> >>>
>> >>> protocols would support ways to fetch location by the PSAP 
>> >>> operator from the access provider using, for example, 
>the location 
>> >>> by
>> >> reference
>> >>> 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.
>> >>>
>> >>>> The subject of emailing an emergency request comes up from time 
>> >>>> to time.
>> >>>> Many users have an expectation that they should be able to text 
>> >>>> to the emergency service".
>> >>>>

---

From: ken carlberg <[email-masked]>
Date: Mon, 2 Feb 2009 10:12:59 -0500

> expect any tomorrow, although I'd like to allow it (RPH).

within in the U.S. and 911-type service, couldn't agree more.   
However, my understanding is that Japan does mark and prioritize 911- 
type calls.

> I would not expect any priority for emergency email.

i would agree as well in the general case and the bulk of the  
installed base, as per Hannes' earlier comment on the topic.  my  
feeling is that we'll see some proprietary work for internal  
deployments in large companies  sometime in the near term.

-ken

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 2 Feb 2009 10:17:33 -0500

I stand corrected about some jurisdictions having priority for emergency
voice calls.

Brian

> Sent: Monday, February 02, 2009 10:13 AM
> To: Brian Rosen
> Cc: 'Hannes Tschofenig'; Rosen, Brian; [email-masked]

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 2 Feb 2009 16:51:20 +0100

To be clear to everyone reading this, "priority" in this case means special handling as a distinct class of traffic, and not necessarily handling at the expense of other traffic. 

As has already been indicated, there are countries that do this.

regards

Keith

> On Behalf Of Brian Rosen
> Sent: Monday, February 02, 2009 2:56 PM
> To: 'ken carlberg'; 'Hannes Tschofenig'
> There is no priority for emergency calls in the PSTN today.  
> I would not expect any tomorrow, although I'd like to allow 
> it (RPH).  
> 
> I am not sure what the right thing to do with marking is.  
> The easiest thing is to recognize the "dial string" and 
> translate that to the "PSAP URI" using LoST.  That would be a 
> mailto, and would get the email to the right place.
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of ken carlberg
> location to

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 2 Feb 2009 17:08:06 +0100

My question would be: "Do such alarms fall into the definition of emergency calls?"

Certainly in the UK they do not go near a PSAP. Mostly nowadays they go to some private contractor or security firm who sends one of their own people to investigate before the police are summoned. Some burglar alarms do still end up in the local police station, but do not form part of the normal emergency response handling.

So, if part of the definition of emergency service is that it is a public service, then I would guess it would be difficult to call these an emergency service.

regards

Keith

> On Behalf Of Henning Schulzrinne
> Sent: Monday, February 02, 2009 11:05 AM
> To: Hannes Tschofenig
> not disagreeing, but email has also become a favorite tool 
> for automated event notifications, in the absence of other 
> Compared to SMS, the sender (if it directly submits the 
> email, rather than through a queueing sendmail) gets a good 
> monitoring company or a chemical plant with automated 
> sensors, where authentication is not a big deal (since the 
> alarm company/chemical company can easily cryptographically 
> sign the email via S/MIME and the number of such companies is 
> modest on a local level and their identities are known).
> 
> emergency email 
> examples 
> really want 
> > from the access provider using, for example, the location 
> by reference

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 2 Feb 2009 15:06:59 -0500

However, current PSTN emergency calls suffer from both "Emergency butt 
calls", and people making "Emergency" calls as a way of 
testing/demonstrating that an unsubscribed handset is functional 
(apparently a big problem in European "flea market" scenarios).

Quite analogous to spam.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.