RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing

"Brian Rosen" <br@brianrosen.net> Mon, 27 September 2004 19:26 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24517 for <sipping-emergency-web-archive@ietf.org>; Mon, 27 Sep 2004 15:26:13 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1GF-000450-UZ for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 15:34:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC15R-0006El-Kl; Mon, 27 Sep 2004 15:23:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC12n-0003xn-Ko for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 15:20:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24103 for <sipping-emergency@ietf.org>; Mon, 27 Sep 2004 15:20:15 -0400 (EDT)
Message-Id: <200409271920.PAA24103@ietf.org>
Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1AT-0003z6-EN for sipping-emergency@ietf.org; Mon, 27 Sep 2004 15:28:13 -0400
Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CC12i-00009B-IU; Mon, 27 Sep 2004 14:20:12 -0500
From: Brian Rosen <br@brianrosen.net>
To: 'Marc Linsner' <mlinsner@cisco.com>, sipping-emergency@ietf.org
Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing
Date: Mon, 27 Sep 2004 15:20:09 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcSkxXTmmCEkcjN4RAuSCNbECjVxvwAAMVUA
In-Reply-To: <010401c4a4c5$6f91b870$2c0d0d0a@mlinsnerzk7abh>
X-PopBeforeSMTPSenders: br@brianrosen.net,brosen
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Content-Transfer-Encoding: 7bit
X-BeenThere: sipping-emergency@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: sipping-emergency.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping-emergency@ietf.org>
List-Help: <mailto:sipping-emergency-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=subscribe>
Sender: sipping-emergency-bounces@ietf.org
Errors-To: sipping-emergency-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Content-Transfer-Encoding: 7bit

Agreed that you COULD change the way the system works now to have a
translation from postal address to dispatch address.  They don't do that
now, but they could.  In that regard, maybe a bad example.  If you were to
propose that the system have a translation, then some kind of spec would
have to be written that said that, which might be a new deliverable.

Misspellings, missing or extra directionals (North, Southwest, ..),
confusion between Main Street and Main Drive, etc. are better examples.
The point is to make sure that the call will be routed correctly,
and responders will be dispatched correctly BEFORE the location is needed to
do so, and the only way we know how to do that is to compare the address
against some kind of master list.

Brian

> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Monday, September 27, 2004 3:09 PM
> To: 'Brian Rosen'; sipping-emergency@ietf.org
> Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency
> calling and routing
> 
> In-line.....
> 
> > -----Original Message-----
> > From: sipping-emergency-bounces@ietf.org
> > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Brian Rosen
> > Sent: Monday, September 27, 2004 12:04 PM
> > To: 'James M. Polk'; 'Peterson, Jon'; sipping-emergency@ietf.org
> > Cc: mankin@psg.com
> > Subject: RE: [Sipping-emergency] proposed charter,new wg on
> > emergency calling and routing
> > Importance: Low
> >
> >
> > When you place an emergency call, the location is used to
> > determine where to send the call, and it is used to dispatch
> > responders.  If the location you supply does not match
> > anything the call center recognizes, the wrong thing may
> > happen.  What you want to do is to compare the address you
> > have against a list maintained by the emergency response
> > system to make sure they know where that is.
> >
> > An example is illustrative.  If you ask me my home address,
> > I'd tell you that it is 470 Conrad Drive, Mars, PA.  However,
> > that is NOT the address that should be used to determine
> > where to send an emergency call from my home.  That is
> > because the post office boundary is not the same as the
> > emergency call system boundary.
> 
> So?  As long as '470 Conrad Drive, Mars, PA.' is unique, modern data
> processing can handle it.
> 
> If you were to determine the
> > serving ERC without validation, you would send my emergency
> > call to the Butler County ERC, which serves Mars, rather than
> > to the NEWCOM center that serves Pine Township, where I live.
> 
> Validation and routing are 2 separate issues.  If in fact, 470
> Conrad.....,
> is a good address, the routing function (which will be based on data from
> the ERC entities) better get it right and send the call the NEWCOM center
> as
> you describe.  All that validation *may* offer is to verify that you (the
> end-user) didn't spell Conrad as Conard (or put Street instead of Drive,
> etc.)!  I realize there are locales that utilize a different 'location'
> address for emergency purposes than the postal address, but the IETF can't
> fix this.
> 
> I'm not against validation, but your example isn't the real reason for
> validation.
> 
> >
> [snip]
> 
> -Marc Linsner-
> 
> 




_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency