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

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 20 Oct 2005 21:55:57 -0500

I wonder if the LUMP concept and NENA i2 validation concept aren't quite
different things. I see the NENA i2 validation as a precursory step to
storing location in database to be handed out to clients on request to
ensure that a route can be determined for it. LUMP and the ECRIT mapping
protocol is much more in line with the behaviour of the VPC/ERDB
functionality, that is, given a location please provide a route to a
destination. I don't think that the ERDB protocol supports a partial
match concept, it either works, it fails, or it may redirect. Or have I
missed the point?

James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Henning Schulzrinne
> Sent: Friday, 21 October 2005 12:42 PM
> To: Abbott, Nadine B
> Cc: [email-masked]
> Subject: Re: [Ecrit] Issue 15 (civic location validation)
> 
> Nadine,
> 
> I can't speak for the proponents of other solutions, but in my LUMP
> proposal, validation is built into the system and does not require a
> separate mechanism. (It may be useful to provide flags requesting
> specific matching behavior, although I think most of this can be
handled
> by appropriate 'warning' responses.)
> 
> Given that almost all of the information in lookup and validation are
> the same, I think the overall system complexity would increase by
> separating the two. Plus, one might argue that this would open up an
> opportunity for the validation to succeed, while the "real" query
> doesn't, or vice versa.
> 
> Henning
> 
> Abbott, Nadine B wrote:
> > Henning,
> >
> > In the migratory work done on location validation in NENA, we
allowed
> > for several cases:
> > 	- Match
> > 	- Match, after some processing (e.g., adjustments in
> > abbreviations, etc., this distinction is not so important as the
next
> > two, I think)
> > 	- Ambiguous match (more than one match at some level (this would
> > be your "known not to exist", I believe)
> > 	- No match  (this would be your "did not match", I believe).
> >
> > In the failure cases, the location validation response may return
some
> > assistance:
> > 	e.g., for ambiguous match, we allow for return some of the best
> > alternative possible matches;
> > 	for ambiguous match and no match, we allow for return of a URI
> > where more help might be available to create a valid address.
> >
> > I wonder if it might be possible to consider whether the mapping
> > protocol could provide a set of similar responses, or at least
provide a
> > URI(s) for where the mapping client might go for the kind of support
> > available in the migratory solution?
> >
> > The NENA migratory solution for this function uses standard Web
Services
> > protocol.
> > Is there any interest in leveraging any of this work?
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

------------------------------------------------------------------------------------------------
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:05:14 -0400

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