Re: [Ecrit] Can I get some love for draft-marshall-similar-location?

["Rosen, Brian" <[e-mail]>]

It is a national matter what "valid" means.

In North America, and I believe in the EU, "valid" means dispatch valid, not just route valid.  If all calls within a state route to the same URI, a location which has the state, but is otherwise not unique (in a dispatch sense) will be marked "invalid".  This is EXACTLY the same as current practice.  In North America, MSAG validation is required to put a route in the SR DB and ALI, and it is dispatch valid.

I am not at all sure why batch validation makes any sense.  While it might have some small value when a LIS is initially loaded, in normal operation, addresses are entered one at a time, and validation should be done at entry (one at a time).

Since there is no draft on batch validation, and so far, no requests, I think that this draft should proceed.  If you care to write a draft that provides a batch validation service with multiple levels of validation, I'd be happy to read and comment on it.

Brian

On Oct 23, 2013, at 12:54 AM, James Winterbottom <[e-mail]> wrote:

> Hi Brian,
> 
> I am ambivalent to this draft. I do't think it is essential but I don't think that it hurts to have it either.
> I would prefer a more efficient way for a LIS to perform mass location validation than post multiple LoST queries with the validation attribute set and that the functionality in similar-location be provided in that protocol/solution.
> 
> I think that it is important to remember that a valid location in the terms of this WG is one that will result in the call being routed to the right PSAP, it doesn't require location to be accurate enough for dispatch. Indeed we do not have a mechanism for requesting validation for the latter case and this has caused some issues within other SDOs. If the similar-location draft or something similar proceeds then adding a means to request different levels of validation may also be a good idea.
> 
> 
> Cheers
> James
> 
> 
> On 23/10/2013, at 6:03 AM, "Rosen, Brian" <[e-mail]> wrote:
> 
>> <longEmail>
>> I presented this draft in Berlin.  There is some support for it, mostly from the NENA guys.  I think it's pretty helpful.  It solves two problems.
>> 
>> When you get a location that you want to put into a LIS, you should validate it BEFORE you use it for an emergency call.  So, you send a LoST query and specify validation.
>> 
>> What is valid?
>> 
>> That's undoubtedly a national matter, but one way to look at it is that it's a set of elements in the LI that describes a UNIQUE location that responders can respond to.  A really simple case is a residence that is addressed by a house number, a street name, a city name, a state/province, and a country.  Provided that the combination of these elements is the location of one house, it's probably valid.
>> 
>> But, let's say that there is also a county in the name.  I give you two scenarios.  In both scenarios, there are two municipalities with the same name in the state/province, but they are in different counties.
>> 
>> In one of the scenarios, the street name only occurs in one of the two municipalities.  In the other scenario, it's in both of them.
>> 
>> So, if I send LI that does not have a county, does have the street and (duplicated) municipality, in scenario one, is it valid?  It is UNIQUE, you know where it is, because there is no Apple Street in Hooverville, Baskin County, but there is an Apple Street in Hooverville, Robbins County.
>> 
>> Now, it is a national matter whether the LoST server accepts the lack of a county name for scenario 1.  In most areas I am familiar with, County is not required unless it's needed to differentiate as it is in Scenario 2.
>> 
>> But, the LoST server does know what the County is, and even in Scenario 1, it might be a really good idea to confirm with the user entering the address that the address is in Robbins County.
>> 
>> In the current RFC5222 definition of LoST, there is no way for the server to return the County name.  In Scenario 2, it would return County on the invalid list, indicating that County was missing, and needs to be provided.  But in Scenario 1, it could either do the same (always require County, even if the address is unique without it), or just return Country, State, Street and House Number as valid.
>> 
>> What the draft does is extend LoST to allow it to return LI to inform the querier that this address is valid, and is in Robbins County.  That lets the LIS confirm with the user, and it also let's it populate the LIS entry with the County, which is a good thing to do if it is confirmed by the user.
>> 
>> The other problem it solves is how to help the user in Scenario 2.  The query presented has invalid LI, and the response will indicate that County is invalid.  But, the only thing the LIS can do is demand that the user some how come up with the name of the County.
>> 
>> A better response would be that the LI given is invalid, but it could be either 124 Apple St, Hooverville, Baskin County, NJ, US or it could be 124 Apple St, Hooverville, Robbins County, NJ, US.  That is, it could offer one or more valid addresses as possible candidates for the LI that was offered in the query.
>> 
>> The LoST server may not be able to return a small number of valid locations the LI in the query suggests, but if it could, a response of "not that, but could it be ….?" is very useful.
>> 
>> This also requires that the LoST server return LI.
>> 
>> We'd really like to push this draft through ecrit.  NENA does really need it, and we think it's generally useful for many countries.
>> 
>> Can I get some love here?
>> 
>> </longEmail>
>> Brian
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit