Subject: Re: [Ecrit] Review of draft-ietf-ecrit-similar-location-01

From: Brooks Shannon <[email-masked]>
Date: Fri, 5 Feb 2016 20:58:29 +0000

Jason,

I agree with you and Brian - it definitely makes sense for a LoST server to limit the number of suggested/complete addresses that it returns.  Even a few dozen will become difficult for a human to process.  Any more than a handful would indicate to me that the address I am validating has some definite issues, which would cause me to investigate its accuracy and probably try validating a few different variations of it as I investigate the problem.  (That's basically what I do when using GIS data editing applications to determine why an address won't geocode; I 'play around' with the values until I learn what's wrong with my address or I dive deeper and start looking for GIS data errors.)

I'm not sure that there is a lot of value in allowing a client to specify the max number of results to return.  Rather I see much more value in simply allowing the LVF to return some indication that it found too many possible candidates and the returned set is truncated due to that.

Thanks!
Brooks

Brooks T. Shannon | Senior Product Manager
Geo-Comm, Inc. | www.geo-comm.com
601 W. Saint Germain St., St. Cloud, MN 56301
Office: 320.240.0040 or 888.436.2666 Fax: 320.240.2389 

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, February 5, 2016 2:28 PM
To: [email-masked]
Subject: Ecrit Digest, Vol 133, Issue 7

Send Ecrit mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/ecrit
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Ecrit digest..."

Today's Topics:

   1. Re: Review of draft-ietf-ecrit-similar-location-01 (Jason Horning)

----------------------------------------------------------------------

Message: 1
Date: Fri, 5 Feb 2016 20:28:03 +0000
From: Jason Horning <[email-masked]>
To: "Rosen, Brian" <[email-masked]>, Roger Marshall
	<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Ecrit] Review of draft-ietf-ecrit-similar-location-01
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="utf-8"

If a client provides a physical address for an apartment building but no sub-address for the individual unit, a server may be inclined to send back complete locations for all 36 units in the apartment building.  That would probably be helpful as long as the list doesn?t get too unwieldy.  For example, it probably wouldn?t be helpful in the case of ?One World Trade Center? where thousands of complete locations may exist.

The thing I?m trying to determine is what the value of the extension would be in examples that are more difficult than a single family home scenario.  In those complex cases is it any more helpful than the LoST protocol as it currently exists?

Maybe it?s worth sending a message to the client that too many similar/complete results were found?

From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, February 5, 2016 1:54 PM
To: Jason Horning; Roger Marshall
Cc: [email-masked]
Subject: Re: Review of draft-ietf-ecrit-similar-location-01

Thanks for the review.

I think the server ought to limit how many options it sends to a couple.  I think we could add words to that effect.  It might be possible to provide a way for the client to specify the max number of valid possibilities it gets, but I think that isn?t worth the complexity.

Brian

From: Jason Horning <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 5, 2016 at 11:53 AM
To: Roger Marshall <[email-masked]<mailto:[email-masked]>>, Brian Rosen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Review of draft-ietf-ecrit-similar-location-01

I think it is important that this draft move forward.  As it stands, LoST is not particularly helpful when it comes to validating addresses.

One question that I do have is what happens when dozens (i.e. an apartment) or hundreds (office complex) of potential complete or similar location candidates are found by the LoST server.  Is there an expectation that all complete or similar locations with the same level of completeness or similarity are returned?

Jason

From: Ecrit [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: Wednesday, February 3, 2016 9:40 AM
To: 'Theresa Reese'; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] Review of draft-ietf-ecrit-similar-location-01

Terry:
Thanks for your careful review of draft-ietf-ecrit-similar-location-01.  We will soon update the draft to take into account these editorial changes.

-roger.

From: Theresa Reese [mailto:[email-masked]]
Sent: Wednesday, February 03, 2016 7:29 AM
To: Roger Marshall; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Review of draft-ietf-ecrit-similar-location-01

I have reviewed draft-ietf-ecrit-similar-location-01 and consider this document to describe a useful capability.

During my review, I identified the following NITS:

1.       The word ?a? is missing from the last sentence of the abstract.

Proposed change:
From: ?These two types of civic addresses are referred to as either  "complete location" or "similar location", and are included as compilation of ca type xml elements within the existing LoST findServiceResponse message structure.?

To:  ?These two types of civic addresses are referred to as either  "complete location" or "similar location", and are included as a compilation of ca type xml elements within the existing LoST findServiceResponse message structure.?

2.       There is an inconsistency in the way the term CAtype is presented throughout the document (i.e., the Abstract uses ?ca type?; Section 2 uses ?CAtype?; Section 3 uses ?caType? and ?CAtype?; Section 8 usese ?CAtype).  The term should be presented consistently throughout the document.

3.       Fix the punctuation in the definition for Civic Location in Section 2

Proposed change:
From: ?. . . to designates a place within a defined grid or basemap, The example used within . .  .?

To:  ?. . . to designates a place within a defined grid or basemap,. The example used within . .  .?

4.       Need to add periods at the end of the definitions for:  Civic Location, Civic Address Element, Invalid, and Valid in Section 2, for consistency with the other definitions.

5.       The word ?of? is missing from Section 3, paragraph 2, third sentence:

Proposed change:
From:   ?As an example, there are LoST civic  address elements that could be used to define a postal location, suitable for delivery mail as well as a municipal location suitable for responding to an emergency call.?

To:  ?As an example, there are LoST civic  address elements that could be used to define a postal location, suitable for delivery of mail as well as a municipal location suitable for responding to an emergency call.?

6.       Fix the punctuation in Section 3, paragraph 6, third sentence

Proposed change:
From: ?In a valid location response, a LoST server returns a response to a findService request that contains a set of civic address elements marked valid, the location information in the findServiceResponse message MAY be extended to include additional location information specific for that location.?

To:  ?In a valid location response, a LoST server returns a response to a findService request that contains a set of civic address elements marked valid,.  tThe location information in the findServiceResponse message MAY be extended to include additional location information specific for that location.?

7.       Replace the colon with a period at the end of the last sentence in Section 3.

8.       Consider making Sections 5 and 6 subsections of Section 4 (i.e., change Section 5 to Section 4.1; change Section 6 to Section 4.2).

Regards,
Terry Reese

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/ecrit/attachments/20160205/f29905e7/attachment.html>

---

From: James Winterbottom <[email-masked]>
Date: Sat, 6 Feb 2016 08:27:04 +1100

Hi All,

It feels like some kind of limit on the returned number of entities is a good plan (I still don’t like the concept of the draft at all).
When we are down to which of 300 apartments to identify, I think we are talking dispatch, when our charter is routing. Given that, perhaps street number is actually as fine a grain as we need to go?

Cheers
James

> On 6 Feb 2016, at 7:58 am, Brooks Shannon <[email-masked]> wrote:
> 
> Jason,
> 
> Geo-Comm, Inc. | www.geo-comm.com <http://www.geo-comm.com/>

---

From: Jason Horning <[email-masked]>
Date: Fri, 5 Feb 2016 21:40:55 +0000

not familiar with the charter so my apologies there, but when pre-validating addresses for 911 I don't believe that the hn is enough resolution. no guarantee you'll get more detail from the caller.  where else would the dispatch level resolution come from?

Sent from my iPhone

On Feb 5, 2016, at 3:25 PM, James Winterbottom <[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

Cheers
James

On 6 Feb 2016, at 7:58 am, Brooks Shannon <[email-masked]<mailto:[email-masked]>> wrote:

Jason,

Thanks!
Brooks

Brooks T. Shannon | Senior Product Manager
Geo-Comm, Inc. | www.geo-comm.com<http://www.geo-comm.com/>
601 W. Saint Germain St., St. Cloud, MN 56301
Office: 320.240.0040 or 888.436.2666 Fax: 320.240.2389

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, February 5, 2016 2:28 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Ecrit Digest, Vol 133, Issue 7

Send Ecrit mailing list submissions to
[email-masked]<mailto:[email-masked]>

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/ecrit
or, via email, send a message with subject or body 'help' to
[email-masked]<mailto:[email-masked]>

You can reach the person managing the list at
[email-masked]<mailto:[email-masked]>

Today's Topics:

Message: 1
Date: Fri, 5 Feb 2016 20:28:03 +0000
From: Jason Horning <[email-masked]<mailto:[email-masked]>>
To: "Rosen, Brian" <[email-masked]<mailto:[email-masked]>>, Roger Marshall
<[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ecrit] Review of draft-ietf-ecrit-similar-location-01
Message-ID:
<[email-masked]<mailto:[email-masked]>>
Content-Type: text/plain; charset="utf-8"

Thanks for the review.

Brian

From: Jason Horning <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Date: Friday, February 5, 2016 at 11:53 AM
To: Roger Marshall <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>, Brian Rosen <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Subject: RE: Review of draft-ietf-ecrit-similar-location-01

Jason

From: Ecrit [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: Wednesday, February 3, 2016 9:40 AM
To: 'Theresa Reese'; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Subject: Re: [Ecrit] Review of draft-ietf-ecrit-similar-location-01

Terry:

-roger.

From: Theresa Reese [mailto:[email-masked]]
Sent: Wednesday, February 03, 2016 7:29 AM
To: Roger Marshall; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Subject: Review of draft-ietf-ecrit-similar-location-01

Proposed change:

Proposed change:

Proposed change:

Proposed change:

Regards,
Terry Reese

-------------- next part --------------

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit

---

From: James Winterbottom <[email-masked]>
Date: Sat, 6 Feb 2016 08:55:29 +1100

Hi Jason,

https://datatracker.ietf.org/wg/ecrit/charter/ <https://datatracker.ietf.org/wg/ecrit/charter/>

I agree dispatch is important, but not currently in scope.. *8(

> On 6 Feb 2016, at 8:40 am, Jason Horning <[email-masked]> wrote:
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Feb 2016 22:00:54 +0000

I’ll make things easy for you:

There are buildings where some suites house very high security departments.  Emergency calls from those suites has to be special, so routing of the calls is different.  I personally am not aware of a routing different for one room (such as a SCIF), but that may also be necessary.

So, not limited to dispatch issues.

Brian

On Feb 5, 2016, at 4:55 PM, James Winterbottom <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jason,

https://datatracker.ietf.org/wg/ecrit/charter/

On 6 Feb 2016, at 8:40 am, Jason Horning <[email-masked]<mailto:[email-masked]>> wrote:

Sent from my iPhone

On Feb 5, 2016, at 3:25 PM, James Winterbottom <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

Hi All,

Cheers
James

---

From: James Winterbottom <[email-masked]>
Date: Sat, 6 Feb 2016 09:23:46 +1100

In such a case it is more than likely that calls are routed inside a private network. Therefore I think that this is beyond a fringe case.

Sent from my iPhone

> On 6 Feb 2016, at 9:00 am, "Rosen, Brian" <[email-masked]> wrote:
> 
>> On Feb 5, 2016, at 4:55 PM, James Winterbottom <[email-masked]> wrote:
>> 
>> Hi Jason,
>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Feb 2016 22:29:44 +0000

Why would it matter if it’s a private network?  Still is a route.

None of this actually matters, I’m humoring you.  Since the same circumstance we’re discussing happens on a street number, solving it for that case solves it for apartment numbers, or even rooms.  The location information LoST uses includes all the subaddress components.  It’s possible to route on any of them.  The problems we’re solving can occur on just about any field.  For example if there is an error on A1 (State/Province), but there is only a few possible addresses that match all of the rest of the fields provided, all the discussions we are having on this thread apply.

Brian

On Feb 5, 2016, at 5:23 PM, James Winterbottom <[email-masked]<mailto:[email-masked]>> wrote:

Sent from my iPhone

On 6 Feb 2016, at 9:00 am, "Rosen, Brian" <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Hi Jason,

Sent from my iPhone

Hi All,

Cheers
James

---

From: James Winterbottom <[email-masked]>
Date: Sat, 6 Feb 2016 10:24:38 +1100

Except that the first “P” in PSAP standards for Public, not Private. So in a private network you can do whatever you want and it is not applicable here…. *8P

I don’t believe that we should conflate routing and dispatch locations by forcing them to be the same, I know that NENA took this approach, I queried it then too.

I disagree with the assertion "The location information LoST uses includes all the subaddress components”, the LoST server in ECRIT only requires the components necessary to identify the correct PSAP to route to. If you decouple the routing and dispatch from having to be the same, then I think we can define the minimum sub-element quite easily. There is also a very big difference between providing alternatives for information that has been proffered, and adding whole sub-elements that were not.

Cheers
James

> On 6 Feb 2016, at 9:29 am, Rosen, Brian <[email-masked]> wrote:
> 
>> On Feb 5, 2016, at 5:23 PM, James Winterbottom <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On 6 Feb 2016, at 9:00 am, "Rosen, Brian" <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>> On Feb 5, 2016, at 4:55 PM, James Winterbottom <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> Hi Jason,
>>>> 
>>>>> On 6 Feb 2016, at 8:40 am, Jason Horning <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> On Feb 5, 2016, at 3:25 PM, James Winterbottom <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>> 
>>>>> Hi All,
>>>>> 
>> [email-masked] <mailto:[email-masked]>

---

From: "Rosen, Brian" <[email-masked]>
Date: Sat, 6 Feb 2016 17:31:11 +0000

“Public Safety” applies to a limited access/limited service area response system, especially when operated by government agencies, which are the examples I’ve cited.

You often “conflate” routing and dispatch because you always send one location with the call.  That has to be good enough for both functions when using location by value.  We are discussing street addresses, which are very often sent by value.

LoST is capable of routing based on any component of the Location Information, including the subaddress components.  Whether they are actually used or not depends on the circumstances, and there are circumstances where they are used.  That’s really all there is.  We don’t have any text in any document that limits what LoST can route on, and all the components can be in the proffered address, and thus CAN be routed on.

I’m not sure I understand "There is also a very big difference between providing alternatives for information that has been proffered, and adding whole sub-elements that were not”.  If you send a location that is missing some element, but by the elements you send, we can in fact identify a unique location, that doesn’t necessarily mean the location is correct.  Suppose there is no 200 Main Street, but there is a 200 North Main Street.  “North” may be missing.  Is that “adding a while sub-element” if that location is returned as an alternate valid location?

Brian

On Feb 5, 2016, at 6:24 PM, James Winterbottom <[email-masked]<mailto:[email-masked]>> wrote:

Cheers
James

On 6 Feb 2016, at 9:29 am, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Sent from my iPhone

Brian

Hi Jason,

Sent from my iPhone

Hi All,

Cheers
James

---

From: James Winterbottom <[email-masked]>
Date: Sun, 7 Feb 2016 06:16:00 +1100

Sub-element was a bad choice of terms, leaf might be a better one.

The problem that is currently being described isn’t really the example you give below. The problem is that you haven’t found “a” unique address, the issue being described is lots of “unique” addresses, and that is not the same problem. It may be a related problem, but it is not the problem you describe below. The problem that is being described, as I understand it, is you provide "200 North Main Street” and this street goes for 20 blocks, so you are given all 20 blocks worth of options on both sides of the road + all floors and suites that may exist in any of the buildings. No allowing multiples to be returned where it is “only” the leaf element that is being substituted (leaf if from the proffered location), would address this and most of the other vast-multi-return cases. For example, if you just put US, you would not get a response because there are 50 states that could be returned.

Cheers
James

> On 7 Feb 2016, at 4:31 am, Rosen, Brian <[email-masked]> wrote:
> 
>> On Feb 5, 2016, at 6:24 PM, James Winterbottom <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On 6 Feb 2016, at 9:29 am, Rosen, Brian <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
>>> 
>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Sun, 7 Feb 2016 21:53:59 +0000

I really think it’s just how many valid locations would be returned.  If it’s small, return them.  If it’s not, either don’t return any option, or return the few most likely.  I don’t think you can suggest that if it’s not the leaf element than don’t return:  there are lots of cases where, for example, common use is no house number on some very short streets that have only one or a very small number of houses, but in fact there is one.  House number is leaf.  All the “options” on street name  (directionals, prefix/suffix, thoroughfare type,..) could be considered “leaf” of street name, and many of the cases we’re discussing could have only a couple of likely options.  I just don’t think that differentiation is useful for us.

Brian

On Feb 6, 2016, at 2:16 PM, James Winterbottom <[email-masked]<mailto:[email-masked]>> wrote:

Cheers
James

On 7 Feb 2016, at 4:31 am, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Cheers
James

Brian

Sent from my iPhone

Brian

Hi Jason,

Sent from my iPhone

Hi All,

Cheers
James

---

From: James Winterbottom <[email-masked]>
Date: Mon, 8 Feb 2016 09:34:25 +1100

House number is exactly as use case where not permitting leaf should be applied. But are strangers to disagreement...*8)

Sent from my iPhone

> On 8 Feb 2016, at 8:53 am, "Rosen, Brian" <[email-masked]> wrote:
> 
>> On Feb 6, 2016, at 2:16 PM, James Winterbottom <[email-masked]> wrote:
>> 
>> 
>>>> On Feb 5, 2016, at 6:24 PM, James Winterbottom <[email-masked]> wrote:
>>>> 
>>>>>> On Feb 5, 2016, at 5:23 PM, James Winterbottom <[email-masked]> wrote:
>>>>>> 
>>>>>> [email-masked]
>>>> [email-masked]

---

From: Jason Horning <[email-masked]>
Date: Mon, 8 Feb 2016 20:23:28 +0000

Can we agree that if a server finds 30 matches of complete or similar locations with equal match quality, odds are that the interesting ones are not offered in the response if the response is limited to a few?

If you truncate the response at all, it seems like something else is necessary to give the requestor another clue. (e.g. too many matches returned, be more specific, try again with a UNIT value, etc)

Jason

From: Ecrit [mailto:[email-masked]] On Behalf Of James Winterbottom
Sent: Sunday, February 7, 2016 4:34 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [Ecrit] Review of draft-ietf-ecrit-similar-location-01

Sent from my iPhone

On 8 Feb 2016, at 8:53 am, "Rosen, Brian" <[email-masked]<mailto:[email-masked]>> wrote:
I really think it’s just how many valid locations would be returned.  If it’s small, return them.  If it’s not, either don’t return any option, or return the few most likely.  I don’t think you can suggest that if it’s not the leaf element than don’t return:  there are lots of cases where, for example, common use is no house number on some very short streets that have only one or a very small number of houses, but in fact there is one.  House number is leaf.  All the “options” on street name  (directionals, prefix/suffix, thoroughfare type,..) could be considered “leaf” of street name, and many of the cases we’re discussing could have only a couple of likely options.  I just don’t think that differentiation is useful for us.

Brian

Cheers
James

Brian

Cheers
James

Brian

Sent from my iPhone

Brian

Hi Jason,

Sent from my iPhone

Hi All,

Cheers
James

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 8 Feb 2016 20:32:43 +0000

Yeah, I think so.  We would need a new error code to supply “too many matches”.  I wouldn’t try to suggest what to do: “try again with a unit”.  In the case where a unit is required to get a match, you would return unit in the invalid list if it was missing.  Same with A1.

Brian

On Feb 8, 2016, at 3:23 PM, Jason Horning <[email-masked]<mailto:[email-masked]>> wrote:

Jason

Sent from my iPhone

Brian

Cheers
James

Brian

Cheers
James

Brian

Sent from my iPhone

Brian

Hi Jason,

Sent from my iPhone

Hi All,

Cheers
James

---

From: James Winterbottom <[email-masked]>
Date: Tue, 9 Feb 2016 18:48:59 +1100

I think your position is fair Jason.

The problem is that anything more than a very small number is going to be difficult to hand process, and I must be honest and say that I don’t think this mechanism is likely to be used for mass or batch processing. So what is the recommended limit for the number of responses?

Cheers
James

> On 9 Feb 2016, at 7:32 am, Rosen, Brian <[email-masked]> wrote:
> 
>> On Feb 8, 2016, at 3:23 PM, Jason Horning <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>   <>
>> From: Ecrit [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of James Winterbottom
>> Cc: [email-masked] <mailto:[email-masked]>
>> On 8 Feb 2016, at 8:53 am, "Rosen, Brian" <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Feb 6, 2016, at 2:16 PM, James Winterbottom <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>>  
>> On 7 Feb 2016, at 4:31 am, Rosen, Brian <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Dan Banks <[email-masked]>
Date: Tue, 16 Feb 2016 17:25:38 +0000

I tend to agree with Brian’s position here.  Sub-address elements are defined in the civic address structure, and a LoST server can be capable of using them to determine a response.  Which of those elements will actually be used or required in any given circumstance depends on the data available to the server, but that is unimportant from the perspective of the protocol.

For similar location, I agree it makes sense for a server to limit the maximum number of responses, and that limit should be determined by local policy.  And yes, I would like a warning to be defined that should be added to the response if a limit is imposed.  I also agree that there are circumstances in which it may make sense to not return any suggestions.  The first example that comes to mind is if a submitted address is missing the HNO:  I do not see a huge benefit to enumerating all (or perhaps any) of the valid HNOs on Main Street, especially if the LoST server is making that determination based on address-ranged road centerlines rather than discrete address features.

I think that it would be dangerous to choose from multiple similar locations in an automated fashion, so I agree that the similar location aspect is not likely to be used for mass/batch processing.  However, I think the complete location portion may be able to be used within reason for automated processing (and I intend to try it).

Dan Banks

From: Ecrit [mailto:[email-masked]] On Behalf Of James Winterbottom
Sent: Tuesday, February 09, 2016 2:49 AM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [Ecrit] Review of draft-ietf-ecrit-similar-location-01

Cheers
James

On 9 Feb 2016, at 7:32 am, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Jason

Sent from my iPhone

Brian

Cheers
James

Brian

Cheers
James

Brian

Sent from my iPhone

Brian

Hi Jason,

Sent from my iPhone

Hi All,

Cheers
James