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

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" <Brian.Rosen@neustar.biz> 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
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit