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

From: "Abbott, Nadine B" <[email-masked]>
Date: Thu, 20 Oct 2005 08:52:20 -0400

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?

Thanks,
Nadine Abbott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Schulzrinne
Sent: Wednesday, October 19, 2005 9:26 PM
To: Roger Marshall
Cc: [email-masked]
Subject: Re: [Ecrit] Issue 15 (civic location validation)

I had raised a related issue in a slightly-tangential way a few days
back.

I think there are two somewhat separate issues:

- if validation means "is a mapping request during an actual emergency 
going to return a URL or an error code", then I don't see how this 
requires anything at all since the mapping system can't know whether 
it's being called in test or in a real emergency (and it shouldn't
matter).

- if validation means "provide an error indication and maybe hints as to

how to fix the problem", there might be a difference between test and 
"real" operation. In "real" mode, the mapping protocol might provide a 
URL even if the street name can't be found if the whole town has the 
same PSAP. In "validation" mode, it would presumably tell the client to 
go fix the problem. It is not clear to me, however, that this *requires*

two modes. One could simply return a warning indicator that part of the 
location didn't match. As I mentioned, depending on the underlying 
database, validation could mean anything from "your cubicle number 
exists" to "I don't know anything about streets, but I recognize your
city".

Thus, this requires more details on what we want from validation. Given 
that the depth of validation depends as much on the data available as on

the protocol, maybe the requirement is that the protocol can perform a 
partial match on civic locations and, importantly, indicate when it 
either did not match ("no clue") or failed to match ("known not to 
exist") part of the location information.

Henning

Roger Marshall wrote:
> A couple of questions around validation to revisit (from 9/14).  This 
> needs an answer, one way or the other - in light of needing to publish

> the next ECRIT requirements draft version.
> 
> The item below is listed as critical within the ECRIT issue-tracker, 
> (issue 15)
> at: http://www.ietf-ecrit.org:8080/ecrit-req/
> 
> L6.  Validation of civic location: It MUST be possible to validate an 
> address prior to its use in an actual emergency call.
> 
> # is this a protocol requirement or an architecture requirement?
> # when should this validation take place? 
> 
> Please comment on the above two questions.
> 
> Thanks.
> 
> Roger Marshall.
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>On Behalf Of Brian Rosen
>>Sent: Wednesday, May 18, 2005 6:47 AM
>>To: [email-masked]
>>Subject: [Ecrit] Text for I7
>>
>>I7.  Traceable resolution: The entity requesting mapping
>>SHOULD be able to definitively and securely determine the 
>>entity or entities who provided the emergency address 
>>resolution information.
>>
>>
>>
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/ecrit
>>
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Oct 2005 22:42:26 -0400

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