Subject: RE: [Ecrit] Issue 15

From: "Roger Marshall" <[email-masked]>
Date: Fri, 13 Jan 2006 23:30:27 -0800

Issue 15, (http://www.ietf-ecrit.org:8080/ecrit-req/issue15):

Changing subject line to include the issue number (15), for tracking.
We've generated lots of discussion on this subject, and from what I can
tell, as a result it looks like most folks think that there is a place
for validation under certain (maybe alternate) circumstances.  I'm
therefore leaving the following requirement intact:

   Lo1.  Validation of Civic Location: It MUST be possible to validate a
      civic location prior to its use in an actual emergency call.

      Motivation: Location validation provides an opportunity to help
      assure ahead of time, whether successful mapping to the
      appropriate PSAP will likely occur when it is required.
      Validation may also help to avoid delays during emergency call
      setup due to invalid locations.

If there is disagreement with leaving this in, please comment.

Thanks.

Roger Marshall.

>-----Original Message-----
>From: Ted Hardie [mailto:[email-masked]] 
>Sent: Friday, December 23, 2005 12:38 PM
>To: [email-masked]; 'Winterbottom, James'; 'James M. Polk'; 
>Roger Marshall; [email-masked]
>Subject: RE: [Ecrit] Issue
>
>At 8:22 AM -0500 12/23/05, Brian Rosen wrote:
>>This is not a provisioning issue, at least not a provisioning 
>issue for 
>>the mapping database.  In some circumstances, it's a 
>provisioning issue 
>>for a LIS, but with respect to the mapping protocol, it's an 
>>operational requirement.
>>
>>Repeating myself, the requirement is that ecrit provides a 
>mechanism to 
>>confirm the validity of an address.  Validity in this case means:
>>	If the address was to be used for an emergency call, it 
>would be 
>>recognized in the database and a valid mapping would be returned
>>	If the address was used for dispatch, it is an address that the 
>>responders would recognize and be able to send help
>
>Thanks for very clearly separating those two out.  The first 
>actually breaks into two cases:  1) there is enough data 
>provide a mapping, but the data are incomplete or incorrect in 
>some way known to the system; 2) the data are correct and 
>complete and in some way known.
>
>How often case one happens depends a lot on the way in which 
>the locality has organized  its PSAPs.  If a municipality has 
>a single PSAP, a correct mapping can be returned if there is a 
>municipality in the location object, even if no other data is present.
>There are lots of other cases where partial information or 
>partially correct information can still be sufficient to 
>generate a good mapping; as long as you do not presume that 
>the query is hamstrung to be exact-match only, good results 
>can come from incomplete data in non-trivial numbers of cases.
> 
>What you want to return to a query in the case of "available 
>mapping, but a location object that is incomplete" depends on 
>whether the query is associated with an actual emergency or is 
>specific to validation.
>
>If the query being made is specifically a validation query, it 
>should return the mapping and an indication that the data is 
>not complete (or elements are not correct); if the query is an 
>emergency query, it should simply return the mapping.  
>Distinguishing between the two cases with a query flag is an 
>obvious choice, and I think most of us believe that's a good 
>thing to do.
>
>Going beyond that to your second case, there is a question 
>about whether what validation query is testing against is the 
>address's correctness/completeness for dispatch. I think it is 
>logical to assume it is. 
>
>I *think* then, what the requirement boils down to is that the 
>error results for negative returns to validation queries 
>should  distinguish among location objects that are too 
>incomplete for dispatch, those that are complete but appear to 
>have data that is not in the database, and those in which the 
>data are known to be wrong (cites a floor in a building higher 
>than is possible, for example). 
>
>We could go beyond that, to citing which data elements are 
>known to be wrong, and there are cases where we might be able 
>to cite which data elements are missing (though this gets 
>complicated fast, as you will run into lots of "Must include 
>either municipality or county name with a street address).  I 
>personally suspect punting that level of specificity to a free 
>text field is okay; you'll only get it when validating an 
>address, and the most valuable data may actually be who to 
>call to work out the problem (rather than possibly difficult 
>to interpret data).
>
>				regards,
>					Ted Hardie
>

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