Subject: [Ecrit] Validation Functionality in LoST

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 09 Jun 2006 18:48:33 +0200

Hi all,

consider the following example:

<?xml version="1.0"?>
<findLoSTByCivic validate="true" xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:ietf:params:xml:ns:lost1 schema4lost.xsd">
     <civicLocation>
         <p2:country>Germany</p2:country>
         <p2:A1>Bavaria</p2:A1>
         <p2:A3>Munich</p2:A3>
         <p2:A6>Neu Perlach</p2:A6>
         <p2:HNO>96</p2:HNO>
         <p2:PC>81675</p2:PC>
     </civicLocation>
     <service>urn:service:sos.police</service>
</findLoSTByCivic>

This is a query with civic location information and 'validation' 
enabled. Based on this query the following response is generated:

<?xml version="1.0" encoding="UTF-8"?>
<responseCivic timeToLive="10000" xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" 
xsi:schemaLocation="urn:ietf:params:xml:ns:lost1 schema4lost.xsd">
     <displayName>Munich Police Department</displayName>
     <region>
         <p2:country>Germany</p2:country>
         <p2:A1>Bavaria</p2:A1>
         <p2:A3>Munich</p2:A3>
     </region>
     <validation>
         <p2:country>Germany</p2:country>
         <p2:A1>Bavaria</p2:A1>
         <p2:A3>Munich</p2:A3>
         <p2:A6>Neu Perlach</p2:A6>
         <p2:PC>81675</p2:PC>
     </validation>
     <uri>sip:[email-masked]</uri>
     <uri>xmpp:[email-masked]</uri>
     <dialstring>110</dialstring>
</responseCivic>

The validation element indicates that the civic address could be 
compared against a database and the indicated fields returned a match. 
Note that one child element, namely house number (i.e., 
<p2:HNO>96</p2:HNO>) couldn't be matched and is therefore not included 
in the response.

Is this the functionality we are looking for?
What would be a resonable response for geospatial information?

Ciao
Hannes

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 11 Jun 2006 13:02:22 -0400

I think this is somewhat more complicated than necessary. By  
definition, validated information is the same as that provided by the  
querier, so it would be sufficient to say something like

<validated>country A1 A3</validated>

For geo, the only validation would be that the combination of long/ 
lat exists on planet earth. It would be helpful to return a bit more  
detail about the PSAP, e.g., the country it is located in. That way,  
if I flip longitude and latitude, I might get a clue that maybe that  
equatorial-African PSAP doesn't quite make sense when I'm querying  
from Greenwich, England.

On Jun 9, 2006, at 12:48 PM, Hannes Tschofenig wrote:

> compared against a database and the indicated fields returned a  
> match. Note that one child element, namely house number (i.e.,  
> <p2:HNO>96</p2:HNO>) couldn't be matched and is therefore not  
> included in the response.
>
>

---

From: Andrew Newton <[email-masked]>
Date: Sun, 11 Jun 2006 16:43:11 -0400

With the version that lists the elements and their contents, it  
perhaps offers a means for the validation to correct one of the data  
items... say if it were typosed or something.  I'm not sure if that  
is important or not.  Otherwise, just listing the element names is  
fine by me.

-andy

On Jun 11, 2006, at 1:02 PM, Henning Schulzrinne wrote:

> definition, validated information is the same as that provided by  
> the querier, so it would be sufficient to say something like
>
> lat exists on planet earth. It would be helpful to return a bit  
> more detail about the PSAP, e.g., the country it is located in.  
> That way, if I flip longitude and latitude, I might get a clue that  
> maybe that equatorial-African PSAP doesn't quite make sense when  
> I'm querying from Greenwich, England.
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 11 Jun 2006 17:03:14 -0400

Returning a "normalized" address is something that the USPS does on  
their web site. As a server-optional feature, this seems somewhat  
useful, as long as we don't get too fancy (such as offering 10  
choices of what the address might have been).

On Jun 11, 2006, at 4:43 PM, Andrew Newton wrote:

> perhaps offers a means for the validation to correct one of the  
> data items... say if it were typosed or something.  I'm not sure if  
> that is important or not.  Otherwise, just listing the element  
> names is fine by me.
>

---

From: Andrew Newton <[email-masked]>
Date: Sun, 11 Jun 2006 18:15:35 -0400

Henning Schulzrinne wrote:
> As a server-optional feature, this seems somewhat 
> useful, as long as we don't get too fancy (such as offering 10 choices 
> of what the address might have been).

I agree.  If it gets any more "fancy" than this, then we need to drop 
back to just listing the elements.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 12 Jun 2006 15:14:20 -0400

I think this is fine, but we may need a little more intelligence.  Consider
the following cases:

Country, State/Province (A1), City(A3), Street and House Number correct,
County (A2) wrong

Country, State/Province, Street and House number correct, county missing,
city wrong

County, State/Province, County, City, House Number correct, Street wrong

In the first case, (wrong county) the ideal response would be to respond
with the fields that are correct, meaning the county would not be in the
list.

In the second case it would probably not be a good idea to respond with
anything but Country & State.  If the City is wrong, you probably don't look
at the Street.

In the final case, you definitely don't return the House Number if the
street name is wrong.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 12 Jun 2006 15:18:32 -0400

I have direct, relevant experience doing exactly this.  It's hard, but
worthwhile.  Agree that you don't want to respond with a lot of possible
answers.  10 is maybe too big, 5 might be closer.  There is a lot of
subtlety in how you do this.  None-the-less, I think it's very worthwhile to
try.

I could try to write a fairly clear algorithm for how you would do this with
U.S. style addresses, and then we can see what we say for others.

Brian

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Sunday, June 11, 2006 4:43 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [Ecrit] Validation Functionality in LoST

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Jun 2006 15:26:22 -0400

This seems like a separate functionality, i.e., not something returned 
by the standard query, but by some other request type. Only some servers 
are likely to implement such functionality.

Once you have 5, you have to allow essentially an infinite number of 
responses. For anything other than 0 or 1, the user has to decide which 
one to pick, so it can't be automated.

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 12 Jun 2006 15:36:34 -0400

I'm fine if it's a separate query.  I think you DO want a human to look at
it, even if it's only one possibility.  There are too many cases where there
may only be one choice, but it's the wrong choice.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Jun 2006 15:50:07 -0400

I'm interpreting the examples as below as that a list of validated 
elements would be sufficient. Clearly, the server has to be smarter and 
not just do an element-by-element comparison. In most cases, elements 
below the "wrong" element can never be right. Counties, at least in the 
US, are exceptions since they are not necessary for uniqueness. 
Obviously, the use of A2 may vary across countries, so we can probably 
only provide general guidance to implementors, such as "in general, 
anything below the wrong element is not returned in the list, except 
where the element is not necessary to make an address unique."

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 12 Jun 2006 22:55:59 +0200

Looking forward to see your algorithm.

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 12 Jun 2006 18:49:45 -0500

I agree, if you have a problem, you can't rely on the automatic solution.  

I have used these automated "you-meant-this-address" services a little recently and unless they actually resolve to one address, they tend to be a little nuts.  In my case, I grew up using one suburb name that is no longer the officially sanctioned suburb for that street, so when I use the old suburb name, I get a list of 10 woefully inaccurate alternatives.  The problem is that the algorithm has to assume that you have made a mistake in any field, which leads to some interesting alternatives.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, 13 June 2006 5:37 AM
> To: 'Henning Schulzrinne'
> Cc: [email-masked]
> Subject: RE: [Ecrit] Validation Functionality in LoST
> 
> > subtlety in how you do this.  None-the-less, I think it's very
> worthwhile
> to
> > try.
> >

------------------------------------------------------------------------------------------------
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]

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 14 Jun 2006 12:07:04 +0100

> equatorial-African PSAP doesn't quite make sense when I'm querying  

Nitpick: depending on your sign convention, you'll get either somewhere
*off* equatorial Africa (about midway between Mogadishu and the Seychelles)
or somewhere near Santana, Brazil, just north of the mouth of the Amazon.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |