Subject: RE: [Ecrit] Changes in LoST -02

From: "Desjardins, Pierre" <[email-masked]>
Date: Thu, 2 Nov 2006 16:16:33 -0500

Very nice indeed!

A couple of questions/comments:

(1) Section 6.4.8 Civic Address Validation
	To determine if an element is <invalid> relative to other
elements would seem to imply some sort of ordering on the relative
importance of elements. If that is the case shouldn't the ordering be
explicitly stated so that behavior of servers is consistent in that
respect.

(2) Section 9 Location Profiles 
	Items 2 and 3 -- Don't you want to make sure that the formal
definition of the XML elements include a namespace that it other than
the LoST or basic profiles namespaces?

Pier

----------
Pierre Desjardins
Dir. Technology Management
Positron Public Safety Systems
www.positron911.com
+1 514 345 2255

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Thursday, October 26, 2006 4:56 PM
To: [email-masked]
Subject: [Ecrit] Changes in LoST -02

Changes:

- each request now has its own response;

- rewrite of introduction and, to a lesser extent, other sections for
continuity and to remove redundancy;

- location profiles to describe allowable location types;

- ServiceBoundary by reference, not just by value;

- include mechanism, to allow clients to specify which information they
want the server to return;

- <valid>, <invalid>, <unchecked> indicate which pieces of civic address
data have been checked, are invalid and have not been checked,
respectively;

Open issues:

- syntax for error responses (the proposal in the draft has known
problems);

- expiration time - absolute or relative;

- handling of 'include' (specifies minimum set vs. strict set) - this
primarily affects the cacheability of responses

Henning

_______________________________________________
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: Andrew Newton <[email-masked]>
Date: Thu, 2 Nov 2006 19:15:24 -0500

> explicitly stated so that behavior of servers is consistent in that

I do not think it is necessary, but I'm willing to be convinced  
otherwise. As I understand it, a machine will not be making  
corrections if an address is invalid; that's the job of a human who  
can judge the proper context for themselves.

> the LoST or basic profiles namespaces?

I believe the formal Relax NG definition for <location> and  
<serviceBoundary> do that, unless we just got that wrong.  BTW, the  
profile IDs are not XML namespace IDs.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 2 Nov 2006 19:35:50 -0500

> can judge the proper context for themselves.
I think it is necessary.  Effectively, I think you HAVE to have an order.
The error return effectively says "you have a good country, state/province
and community name, but I don't see a Willow Street in Anywhere, PA"
Without order, what you are saying is "well, somewhere in my database, there
is a state named PA, and I also have an Anywhere, although it may or may not
be in PA, but I don't have any streets named Willow anywhere in my database.

We were talking about this in a NENA meeting this morning.  It would be nice
if you, for example, misspelled the name of the community, but got
everything else right, that the error you got was "all fields good except
for community name".  But there is no feasible way to do that unless there
is exactly one Willow street in the state of PA, which is unlikely.  The
best you can do is say "there is no Anywher" in PA.  

If your entry was 100 Main St, Anywher, PA, you don't want "Street Valid"
just because there is a 100 Main St, Somewhere, PA.

Brian

---

From: Andrew Newton <[email-masked]>
Date: Thu, 2 Nov 2006 19:55:30 -0500

> just because there is a 100 Main St, Somewhere, PA.

Again, who is gonna be issuing a correction?  A computer or a human?   
If a human is doing address validation for 123 Willow Street,  
Anywhere PA and the computer says, "You have something wrong with  
either Willow as a street or Anywhere as a city."  I would hope the  
human could figure it out.

The permutations of Anywhere is valid as a city for PA but not CA,  
MD,... and Willow is valid as a street for Anywhere as a city in PA  
and Anywhere as a city in NY.... can get complex fast.

All of this is a far cry from the originally stated requirement,  
which was a boolean flag for the address being valid or invalid.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 02 Nov 2006 20:25:53 -0500

I'm not sure we're all that far apart. Clearly, there is a (rough) 
implied hierarchy in address validation, but I don't think one needs to 
specify the precise algorithm in a standard. One reasonable mechanism 
might be:

(1) Match complete address in database, using all fields that are in the 
database, omitting others. If ok, return list of all such fields.

(2) Remove the house number.

(3) Remove the street address components.

(4.1) If (3) fails, prune back to country and A1 through A6. Repeat.

(4.2) If (4.1) fails, prune back to country and A1 through A5. Repeat.

(4.3) etc.

The details could depend a bit on the country, but that's ok, since the 
authoritative database is likely going to be country-specific.

What is beyond the scope of the draft is to do guessing, such as "No 
Mian Street but maybe you meant Main Street" or "No North Main Street, 
just North-East Main Street". Simply indicating that there's an error 
should in almost all cases be sufficient to identify the problem, 
particularly for the common spelling mistakes. If not, one needs more 
elaborate mechanisms, such as the listing of all streets in a city or a 
map, where somebody can find their home by neighboring streets.

Even without standards, this is all pretty much common sense for 
implementors. Whether a national body, such as NENA, wants to provide 
guidance on elements that should always be treated as a unit and a 
hierarchy is another issue.

Henning

Andrew Newton wrote:
> Again, who is gonna be issuing a correction?  A computer or a human?  If 
> a human is doing address validation for 123 Willow Street, Anywhere PA 
> and the computer says, "You have something wrong with either Willow as a 
> street or Anywhere as a city."  I would hope the human could figure it out.
> 
> MD,... and Willow is valid as a street for Anywhere as a city in PA and 
> Anywhere as a city in NY.... can get complex fast.
> 
> All of this is a far cry from the originally stated requirement, which 
> was a boolean flag for the address being valid or invalid.
> 
> -andy
> 
> 
> ------------------------------------------------------------------------
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 2 Nov 2006 20:40:12 -0500

On Nov 2, 2006, at 8:25 PM, Henning Schulzrinne wrote:

> The details could depend a bit on the country, but that's ok, since  
> the authoritative database is likely going to be country-specific.

This sounds very reasonable to me.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 2 Nov 2006 20:49:43 -0500

We're talking past each other.

I want something simple and easy to describe and use.

Ultimately, the correction comes from a human.  All the computer can do is
help.  As I understand the current definition, if I queried with Willow,
Anywher, PA and there was a Willow in Anywhere, then I would get valid, not
valid, valid.  How would you expect to display to the human "there is a
problem with Anywher as a city or Willow as a street" out of that?  However
the real problem is that if there was a Willow in Somewhere, PA but not in
Anywhere, PA, then the query today would be valid, not valid, valid, and you
really get confused.  Now, admittedly, that is an example of two errors, and
most systems that try to do error diagnosis fail miserably with two errors. 

Small aside with relevance to this discussion: You should be allowed to
query with community name blank (just as you should be able to query with
county name blank).  If the fields you supply yield a SINGLE record, you
should get a successful return.  If it yields more than one, you have an
error

I propose that if you have a miss, you examine fields in a defined order. As
soon as you find an error, stop.  Two errors would return a more meaningful
error diagnosis with this algorithm, a small benefit.  

I admit that it would be nice if there was a single record that matched 123
Willow, Anywher, PA, US because Willow only occurred in Anywhere that it be
able to say that, but I don't think it's really necessary.  If you would
like to get that, you can complicate the algorithm by looking at the fields
in order until you get something not found.  Then you try to find a SINGLE
record with that field omitted.  If you find ONE, you can clarify the error.

In the example, if the input is: "123 Willow, Anywher, PA" and there is a
Willow St in both Somewhere and Anywhere, you can't say anything meaningful
about Willow.  It's incorrect to say it is wrong. It is incorrect to say
that it is right.  You just don't know.  Would it help to change the return
to be three state (good, bad, unknown)?

I recognize that you don't have a strict order in the addressing scheme.
For example, postal code is NOT realy ordered in the
coutry/state/county/city scheme.  All that matters is that there is a
defined order.  Actually, you could make the order country specific, not
publish it, and it would be okay, if we sent the "unknown" state back.  What
matters is that you say "there is no Anywher in PA, US"

Brian

________________________________________
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, November 02, 2006 7:56 PM
To: Brian Rosen
Cc: 'Desjardins, Pierre'; [email-masked]
Subject: Re: [Ecrit] Changes in LoST -02

Again, who is gonna be issuing a correction? A computer or a human? If a
human is doing address validation for 123 Willow Street, Anywhere PA and the
computer says, "You have something wrong with either Willow as a street or
Anywhere as a city." I would hope the human could figure it out.

The permutations of Anywhere is valid as a city for PA but not CA, MD,...
and Willow is valid as a street for Anywhere as a city in PA and Anywhere as
a city in NY.... can get complex fast.

All of this is a far cry from the originally stated requirement, which was a
boolean flag for the address being valid or invalid.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 2 Nov 2006 20:50:28 -0500

Me too.

  _____  

From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, November 02, 2006 8:40 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [Ecrit] Changes in LoST -02

-andy

---

From: Shida Schubert <[email-masked]>
Date: Sun, 05 Nov 2006 15:39:08 -0800

Hi;

General comments on the 02 version of the draft.
 BTW Overall I really like where the draft is going.
 
 1. Now that the protocol is allowed to carry more than 1 location 
information
     in the findservice query, it may be a good idea to indicate which 
location was
     used to find out the URIs.
     > Otherwise I don't see how a server(proxy etc.) would be able to 
cache a response and
         later correlate it to a new request.

 2. Last paragraph in section 1 talks about how LoST is able to provide 
list of services that
     are provided in the location requested. Does this always hold true? 
I can see that the server
     is able to provide a list of services that the server in question 
can provide but I don't see
     how server will be aware of all the services that is provided in 
the area.. (What if service
     X is provided at a state level but service Y is provided at a city 
level??)

 3. With many location possibly included in the findService is there any 
way to
      prioritize and indicate the location user wants  LoST server to 
use? (I might have read the
      draft wrong but section 6.3.1 reads as if you can have more than 
one location with the
      same location-profile..)

 4. There is no text explaining the ordering of <via> and its semantics. 
If there is no rule,
     there is no way for an endpoint to figure out which LoST server 
provided the final
     resolution.

 5. What happens when the LoST query is exhausted while it's being iterated?

 6. Can client put an asterisk to indicate it wants all the possible 
information LoST server
     can provide in "include" attribute.

 7. Figure 6 shows a response with the ServiceBoundry but it is not 
requested in the
     request. Is serviceBoundry a MUST in a response?

 8. Section 6.4.7. <serviceNumber> is the only thing that is declared 
optional in the
     draft? Is everything else mandatory??

 9. Section 6.4.4. Let's say the LoST server being queried is 
responsible for the city,
     and it only provides X and Y. But the server responsible for state 
may provide
     service X, Y and Z. Would it only return the alternative it is 
aware of or should
     it query the server responsible for the state and respond according 
to what it
     finds out..

 10. I don't understand why <getServiceBoundary> needs to be defined. Can't
      we just use the findService and have include

 11. <getServiceBoundary> does not have the serviceURN in question. I am 
assuming
      that with LoST server possibly providing different services, each 
services can also
      have different boundary. If so the request and response should 
have the relevant
      service.

 12. TTL should be absolute time. I don't see how servers can 
effectively cache the
       value otherwise. It also will promote replay attack if it's just 
indicated in seconds.

 13. It doesn't say what can be set in the "include" attribute. I think 
this should be
       specified.

  Regards
   Shida Schubert

Henning Schulzrinne wrote:
> - include mechanism, to allow clients to specify which information 
> they want the server to return;
>
> - <valid>, <invalid>, <unchecked> indicate which pieces of civic 
> address data have been checked, are invalid and have not been checked, 
> respectively;
>
> Open issues:
>

---

From: Andrew Newton <[email-masked]>
Date: Mon, 6 Nov 2006 13:49:59 -0500

Shida,

I'll try to answer these as best as possible.  Hopefully Henning,  
Ted, and Hannes can elaborate on the items I don't cover well.

On Nov 5, 2006, at 6:39 PM, Shida Schubert wrote:
>     in the findservice query, it may be a good idea to indicate  
> which location was
>     > Otherwise I don't see how a server(proxy etc.) would be able  
> to cache a response and

Though I cannot see it in the draft, I thought there was wording  
about the ordering of the <location> elements to indicate preference  
and likewise in the response.  That would resolve the issue above.   
But you are correct, we need to be able to indicate which location  
profile was used for the answer.

> 2. Last paragraph in section 1 talks about how LoST is able to  
> provide list of services that
>     are provided in the location requested. Does this always hold  
> true? I can see that the server
>     is able to provide a list of services that the server in  
> question can provide but I don't see
>     how server will be aware of all the services that is provided  
> in the area.. (What if service
>     X is provided at a state level but service Y is provided at a  
> city level??)

Good question.  I think that a <listServices> query would not reach  
an authoritative server.  It would always either be answered by a  
caching resolver via how it was configured to do resolution or from  
information from a forrest guide.

> 3. With many location possibly included in the findService is there  
> any way to
>      prioritize and indicate the location user wants  LoST server  
> to use? (I might have read the
>      draft wrong but section 6.3.1 reads as if you can have more  
> than one location with the
>      same location-profile..)

See #1.

> 4. There is no text explaining the ordering of <via> and its  
> semantics. If there is no rule,

We inadvertently removed that text during some wordsmithing to make  
section 6.4.1 read more clearly.  Thanks for pointing this out.

> 5. What happens when the LoST query is exhausted while it's being  

Either a <notFound> or a <redirect>.

>     can provide in "include" attribute.

I'll see if we can do this.  It shouldn't be too hard in the Relax NG.

>     request. Is serviceBoundry a MUST in a response?

That's a mistake in the example.  No, it is not a MUST.

> 8. Section 6.4.7. <serviceNumber> is the only thing that is  
> declared optional in the

No.  While we do have the mismatch with the Relax NG and some of the  
wording, every element in <findServiceResponse> is optional.

>     and it only provides X and Y. But the server responsible for  
> state may provide
>     it query the server responsible for the state and respond  
> according to what it
>     finds out..

See #2.

>      we just use the findService and have include

The include attribute in <findService> specifies either  
serviceBoundary or serviceBoundaryReference.  This allows a client to  
retrieve the service boundary in a separate message using the  
<getServiceBoundary> query.  This might be useful in networks with  
low bandwidth with service boundaries that might take a lot to express.

> 11. <getServiceBoundary> does not have the serviceURN in question.  
> I am assuming
>      that with LoST server possibly providing different services,  
> each services can also

The key should be good enough.  If a server wants to implement the  
creating of the key with the URN embedded in the key, then it is free  
to do so.  Though perhaps we should relax the regex to allow this.   
Thanks for pointing this out.

>       value otherwise. It also will promote replay attack if it's  
> just indicated in seconds.

Quite easily.  DNS, the largest distributed, caching, inter-domain,  
distributed database uses relative TTLs with no problems.  And there  
is nothing inherent in absolute times themselves that prevent replay  
attacks.

> 13. It doesn't say what can be set in the "include" attribute. I  
> think this should be
>       specified.

That is explicitly listed in the relax ng schema.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Nov 2006 18:58:24 -0800

> about the ordering of the <location> elements to indicate  
> preference and likewise in the response.  That would resolve the  
> issue above.  But you are correct, we need to be able to indicate  
> which location profile was used for the answer.

Given the previous discussion, it might be helpful to add that we  
clearly don't want to allow a LoST request to describe multiple  
points or even in different notations (civic and geo, say).

> information from a forrest guide.

I agree that this needs clarification. There are really two separate  
questions:

(1) What (top-level) services can a server handle? Each top-level  
service is likely to have its own forest guide, so asking my local  
emergency-only resolver for urn:service:restaurant isn't likely to be  
useful.

This would be <listServices> without a location.

(2) What specific services are available for a particular region?  
This would have to travel to the authoritative server, unless the  
resolver has cached the answer to the <listServices> query for that  
particular region.

This calls for more description, assuming we agree on these two  
functions.

>
>> 6. Can client put an asterisk to indicate it wants all the  
>> possible information LoST server

We need to define what omitting 'include' means. We could define that  
no include means "give me everything you got".

> serviceBoundary or serviceBoundaryReference.  This allows a client  
> to retrieve the service boundary in a separate message using the  

To amplify this: service boundaries can be 8000 bytes long, based on  
our county boundary examples. This is large enough that it might be  
an issue for mobile devices.

>>      have different boundary. If so the request and response  
>> should have the relevant
>>      service.
>
> creating of the key with the URN embedded in the key, then it is  
> free to do so.  Though perhaps we should relax the regex to allow  
> this.  Thanks for pointing this out.
>

The important properties are (probabilistically) global uniqueness  
and opaqueness, along with easy byte-by-byte comparison. For example,  
if somebody uses a URN, the recipient should not have to understand  
the URN scheme. In the interest of simplicity, I don't see great  
advantage of allowing more than just base-64 characters or even just  
the DNS ASCII character subset [A-Z0-9-], as opposed to, say, full  
UTF-8.

Henning

---

From: Ted Hardie <[email-masked]>
Date: Wed, 8 Nov 2006 09:39:17 -0800

At 6:58 PM -0800 11/7/06, Henning Schulzrinne wrote:
>>>6. Can client put an asterisk to indicate it wants all the possible information LoST server
>We need to define what omitting 'include' means. We could define that no include means "give me everything you got".

What would that mean to a proxy?  "Give me everything you currently know."
(which might be limited to things previous clients had <include>ed ) or
"Give me everything, doing whatever discovery would be required"?

					Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 8 Nov 2006 11:15:07 -0800

Thinking about this a bit more, I'm actually somewhat worried that  
such an option could be dangerous if future optional objects are  
large. Including things the receiver can't parse isn't too helpful  
and the semantics of "include at least this, but return more if you  
have it" already addresses the caching concerns.

Maybe we should step back and ask what this would be needed for.