Subject: RE: [Ecrit] Issue 15 (civic location validation)

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 20 Oct 2005 22:34:44 -0500

Hi Henning,

I guess that I had assumed that one would only provision down to the
coarsest level of information required to get the call to where it needs
to go. So while your example is a contrived one, for call routing does
it really matter? For display purposes at the PSAP it is a different
matter, but it is also out of scope.

Given this, I would be a little bit concerned about firstly the real
value of providing such warnings (to whom are they provided, and how are
they to be actioned), and secondly the potential processing costs to
produce.

Cheers
James

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, 21 October 2005 1:05 PM
> To: Winterbottom, James
> Cc: Abbott, Nadine B; [email-masked]
> Subject: Re: [Ecrit] Issue 15 (civic location validation)
> 
> It's hard to discuss this in the abstract, but I think they are
> essentially the same.
> 
> Input: location (geo or civic) in both cases
> Output: URL(s) and possible warnings about approximations made or a
> failure indication if no (unique) match is possible
> 
> I think having the warning is useful even in the "real" resolution
since
>   this can be used for debugging. As hard as we try, we can't rule out
> that somebody injects partially-incorrect location information into
the
> system. As a slightly contrived example, imagine that I validate "123
> Main Street". At the time of validation, the validation system only
> knows that "100-500 Main Street" exists, based on MSAG data, and thus
> returns a valid response. If I then make a real call a week later,
with
> the same address and the mapping database has been updated to capture
> individual house numbers, 123 Main Street may no longer be (strictly)
> valid.
> 
> Henning

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Oct 2005 23:43:36 -0400

> matter, but it is also out of scope.

Since there's no cost in doing this validation, it seems 
counterproductive to disallow it. In addition, PSAP boundaries sometimes 
change. If you didn't validate the 123 part of Main Street before and 
you now split Main Street, with 1-50 in one PSAP and 50-99 in another 
(and 123 invalid), you have a problem. Again, not likely, but why make 
the system worse than it has to be, at no decrease in complexity?

> they to be actioned), and secondly the potential processing costs to

I think processing costs are a non-issue, as the database lookup cost on 
a longer key is essentially the same as on one slightly smaller key 
(they just get hashed). In any event, this is a protocol functionality. 
If a particular implementation or installation wants to ignore all but 
the city, for example, it can choose to do that, with the appropriate 
indication.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Oct 2005 08:57:15 -0400

I believe they are essentially identical functions, where the differences
are small enough that in the code it doesn't matter.  NENA made them
separate for what I believe were not good enough reasons.

In actuality, in both cases, you try a direct match with what you are given.
If you get a "hit", you return "good".  The fact that "good" for validation
is literally a single bit, while in the mapping case you get a URI is an
imperceptible difference.

If you don't get a hit, you start eliminating fields, starting at the most
specific and working your way back until you find a match.  For validation,
depending on where you find a match, you may select all the values of the
next most specific field to offer as alternatives (East Main St, West Main
St).  For mapping, you return the "default route" for the valid field you
got to.  That's a difference, but not much of one.

There is possibly one difference that matters.  There are far more queries
to the validation database than to the mapping database IF the mapping is
delayed to the time of a call.  You can make an argument that you don't want
to have run-away validation queries getting in the way of mapping queries,
which argues for separate actual databases.  My view is that mapping is
done, and cached early, and also done at call time, so the number of queries
for the mapping is likely higher than for validation, and this argument
would not hold.  NENA i2 only has call time mapping, so it works there.

You also don't require the same reliability in the validation query as the
mapping query (say 3 nines instead of 5 nines).  Not clear this makes a big
difference these days.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Thursday, October 20, 2005 11:44 PM
To: Winterbottom, James
Cc: [email-masked]
Subject: Re: [Ecrit] Issue 15 (civic location validation)

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Oct 2005 09:58:31 -0400

> mapping query (say 3 nines instead of 5 nines).  Not clear this makes a big

I would argue that reliability argues for integration. Validation works 
both ways: "my civic/geo address is valid" and "mapping would work if 
tried". If validation goes to some different place and uses different 
code, you can't be sure that the real mapping would work.

Plus, if we assume that end system obtain a mapping at boot time rather 
than at call time, separating the two seems a bit strange. You'd do the 
mapping (which also tells you if the address is valid) and then 
occasionally also ask a validator. (Nomadic systems would presumably do 
mapping and validation each time they connect.) Not sure what good that 
would accomplish, besides extra end system complexity and error cases.

In addition, it's not clear to me how you could afford a less reliable 
validation system. For the not-unlikely case where you plug in your 
nomadic network device to make an emergency call, validation better work 
as reliably as mapping and better not add delay.

In general, it's easier to make a single system reliable than to have 
two, since a single, larger system has more total resources that can be 
shared and spared.

Based on (painful) experience, simplicity and generality wins. For SIP, 
I wish we would have pushed back harder on doing things several ways in 
a number of places. I'm trying to learn from that experience...

Henning