Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand geospatialinfointo the query?

From: "Roger Marshall" <[email-masked]>
Date: Mon, 5 Jun 2006 15:42:12 -0700

Marc:
What is the scale of "accuracy" for a civic street address?  0%,100%?

Just because both civic and geo are included, doesn't mean one is
better.  For example, it is  obvious that lat/lon's have measurement
criteria whereas civic addresses don't, since they're either "stated" or
"derived".

Parcel-based GIS mapping systems exist today which describe a location
in terms of both.  As a simple example, Google Earth does this for you.
You specify 123 Main Street, Anytown, USA and once it finds it, it also
provides a lat/lon.  I admit that the there are challenges with using
both, but I expect that those issues will become fewer over time.

Does there have to be a line in the sand as to whether a particular
location is known in terms of civic vs. geo and not both?  I don't think
so. 

Roger Marshall

>-----Original Message-----
>From: Marc Linsner [mailto:[email-masked]] 
>Sent: Monday, June 05, 2006 3:23 PM
>To: 'Andrew Newton'
>Cc: [email-masked]
>Subject: RE: [Ecrit] [issue2] Is it allowed to specifycivicand 
>geospatialinfointo the query?
>
>Andy,
>
>The problem is that the 'preferred' location is the accurate 
>one.  No LoST server/service will be able to determine which 
>one is most accurate.  You may equate the same problem to the 
>client, but IMO, it's better that the client make the decision 
>since it's closer to the human that 'should' know.
>
>-Marc-
>
>
>
>> -----Original Message-----
>> From: Andrew Newton [mailto:[email-masked]]
>> Sent: Monday, June 05, 2006 5:58 PM
>> To: Marc Linsner
>> Cc: 'Hannes Tschofenig'; [email-masked]
>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand 
>> geospatialinfointo the query?
>> 
>> I think we'd have a protocol more capable of adapting to unforeseen, 
>> real world issues if both were sent and the server had the 
>opportunity 
>> to determine which type of location it preferred.  I must admit that 
>> it seems a bit of a stretch, but I think it is just as possible as 
>> Henning's idea that the client will have the same type of 
>notion.  It 
>> almost always seems to me that if ever there is a question about 
>> preference, it should fall to the LoST service operators and their 
>> jurisdictional considerations.
>> 
>> It also seems to me that if a client or seeker does, in some 
>odd way, 
>> have a notion of a preferred type of location when it 
>possesses both, 
>> that it can always just send the query with only the type of 
>location 
>> it prefers.  For clients that don't have this strong notion, 
>send both 
>> and see if the server has a preference.
>> 
>> -andy
>> 
>> 
>> On Jun 5, 2006, at 5:39 PM, Marc Linsner wrote:
>> 
>> > I agree, the LoST client submits one location at a time.  
>> No decisions
>> > made by LoST server/service.
>> >
>> > -Marc-
>> >
>> >> -----Original Message-----
>> >> From: Hannes Tschofenig [mailto:[email-masked]]
>> >> Sent: Monday, June 05, 2006 5:24 PM
>> >> To: Roger Marshall
>> >> Cc: [email-masked]
>> >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand 
>> >> geospatialinfointo the query?
>> >>
>> >> Hi Roger,
>> >>
>> >> Roger Marshall wrote:
>> >>> Hannes: Thanks for clarifying.
>> >>>
>> >>> I think it's a bad idea to withold location information
>> >> from the LoST
>> >>> server.
>> >>>
>> >>> To suggest that we restrict the client, allowing only one
>> >> to be sent,
>> >>> sounds to me like we're placing a constraint on the
>> >> PIDF-LO, saying it
>> >>> can't have both (assuming LoST reuses the PIDF-LO).  I
>> >> don't think we
>> >>> can get away with that.   If the PIDF-LO has both, how is
>> >> it that we can
>> >>> glibly strip one out?  To do so would be unreasonable.
>> >>
>> >> To clarify:
>> >>
>> >> * You can send as many queries as you want but not with the same 
>> >> message. Different location information => different query
>> >>
>> >> * We don't use a PIDF-LO in LoST. We use the raw location info.
>> >>
>> >>>
>> >>> Since the client can have both civic and geo in the
>> PIDF-LO, it can
>> >>> also send both to the server.  What am I missing?
>> >>
>> >> None of the proposals ever used a PIDF-LO as input; just location 
>> >> info.
>> >>
>> >>>
>> >>> It's the LoST server's job to pick one, not the client's.
>> >>
>> >> At the PSAP and the emergency routing proxy I agree with you.
>> >>
>> >>>
>> >>> So, the requirement I would support is as follows:
>> >>>
>> >>> Rx' LoST client SHALL query with either civic or geo.
>> >>
>> >> That's fine.
>> >>
>> >>
>> >>> Ry' LoST client SHOULD query with *both* civic and geo.  
>> When LoST
>> >>> server receives both civic and geo, the server SHOULD try
>> >> to use the
>> >>> geo first.  The LoST server response SHALL indicate which
>> data was
>> >>> used (either geo or civic).
>> >>
>> >> I guess you will not support for this one based on the
>> response I saw
>> >> on the list so far.
>> >>
>> >> Ciao
>> >> Hannes
>> >>
>> >>>
>> >>> -roger.
>> >>>
>> >>>
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: Hannes Tschofenig [mailto:[email-masked]]
>> >>>> Sent: Monday, June 05, 2006 1:50 PM
>> >>>> To: Roger Marshall
>> >>>> Cc: Brian Rosen; [email-masked]
>> >>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify 
>civic and 
>> >>>> geospatialinfointo the query?
>> >>>>
>> >>>> Hi Roger,
>> >>>>
>> >>>> I think the current suggestion is that the LoST client
>> just picks
>> >>>> whatever he wants and then uses the mapping protocol to
>> trigger the
>> >>>> resolution.
>> >>>>
>> >>>> Using geo and civic might be, from a certain point of view,
>> >> just be an
>> >>>> optimization. The LoST client can always trigger separate
>> >> queries with
>> >>>> all the location info it has.
>> >>>>
>> >>>> Ciao
>> >>>> Hannes
>> >>>>
>> >>>> Roger Marshall wrote:
>> >>>>
>> >>>>> I don't disagree that we ask the LoST server to pick one and
>> >>>>
>> >>>> use it.
>> >>>>
>> >>>>> We need to be consistent though, and so therefore, I propose
>> >>>>
>> >>>> that the
>> >>>>
>> >>>>> LoST server always picks the geo over the civic and returns
>> >>>>
>> >>>> a flag in
>> >>>>
>> >>>>> the response stating that the geo was used to perform mapping.
>> >>>>>
>> >>>>> Roger.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: Hannes Tschofenig [mailto:[email-masked]]
>> >>>>>> Sent: Monday, June 05, 2006 1:39 PM
>> >>>>>> To: Brian Rosen
>> >>>>>> Cc: [email-masked]
>> >>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to specify
>> civic and
>> >>>>>> geospatialinfointo the query?
>> >>>>>>
>> >>>>>> It seems that we closed this issue.
>> >>>>>>
>> >>>>>> Everyone seems to be in favor for a civic OR geospatial.
>> >>>>>> Extensions possible for future applications.
>> >>>>>>
>> >>>>>> Ciao
>> >>>>>> Hannes
>> >>>>>>
>> >>>>>> Brian Rosen wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>> I think this is the issue.  There is no guidance we
>> can give the
>> >>>>>>> server to tell it how to resolve what to do when  both
>> >>>>
>> >>>> locations are
>> >>>>
>> >>>>>>> valid but the URI for the geo does match the URI for
>> the civic.
>> >>>>>>>
>> >>>>>>> This happens a lot when you are near boundaries because the
>> >>>>>>
>> >>>>>> precision
>> >>>>>>
>> >>>>>>
>> >>>>>>> and accuracy of the two methods differ.
>> >>>>>>>
>> >>>>>>> I think you pick ONE and use it.
>> >>>>>>>
>> >>>>>>> Even if you send more than one along, the PSAP has to know
>> >>>>
>> >>>> which one
>> >>>>
>> >>>>>>> you used to route.  It's going to continue to use that
>> >>>>
>> >>>> until a human
>> >>>>
>> >>>>>>> says otherwise.
>> >>>>>>>
>> >>>>>>> Brian
>> >>>>>>>
>> >>>>>>> -----Original Message-----
>> >>>>>>> From: Henning Schulzrinne [mailto:[email-masked]]
>> >>>>>>> Sent: Monday, June 05, 2006 3:55 PM
>> >>>>>>> To: Andrew Newton
>> >>>>>>> Cc: [email-masked]
>> >>>>>>> Subject: Re: [Ecrit] [issue2] Is it allowed to
>> specify civic and
>> >>>>>>> geospatialinfo into the query?
>> >>>>>>>
>> >>>>>>> At the PSAP, we have a human that can look at this
>> >> information and
>> >>>>>>> make decisions (and maybe even ask if there's a
>> >> discrepancy). That
>> >>>>>>> seems a stretch for the LoST server.
>> >>>>>>>
>> >>>>>>> Andrew Newton wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning Schulzrinne wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>> In all of these dual-information cases, I don't see
>> >> how anybody
>> >>>>>>>>> except the seeker can make any determination which type of 
>> >>>>>>>>> information is better, more accurate, more recent, etc.
>> >>>>>>>>
>> >>>>>>>> Would we want the seeker to determine which information it
>> >>>>
>> >>>> feels is
>> >>>>
>> >>>>>>>> best to provide to the PSAP?  I've always heard that the
>> >>>>>>
>> >>>>>> answer would be no:
>> >>>>>>
>> >>>>>>
>> >>>>>>>> provide both to the PSAP.  So why then would we not
>> >>>>
>> >>>> provide the same
>> >>>>
>> >>>>>>>> information when determining which PSAP to contact?
>> >>>>>>>>
>> >>>>>>>> -andy
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> Ecrit mailing list
>> >>>>>>> [email-masked]
>> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> Ecrit mailing list
>> >>>>>>> [email-masked]
>> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> Ecrit mailing list
>> >>>>>> [email-masked]
>> >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> Ecrit mailing list
>> >> [email-masked]
>> >> https://www1.ietf.org/mailman/listinfo/ecrit
>> >
>> > _______________________________________________
>> > Ecrit mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>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: "Marc Linsner" <[email-masked]>
Date: Mon, 5 Jun 2006 19:44:15 -0400

Roger,

I'm not arguing geo vs. civil.  All I am trying to state is when multiple
location representations are known for a LoST client, the LoST
server/service should not be the one to determine which representation is
best.

Setup for failure example #1: A single LoST query contains both a civic (123
Main St.) and a geo representation.  All geocode databases return 456 Second
St. for the geo.  Which one should LoST prefer?

Setup for failure example #2: A single LoST query contains two civic
representations.  One is in New York City and the other in Seattle.  Which
one should LoST prefer?

IMO, each example should be (2) unique queries, one for each representation,
and let the client deal with it.  This decision needs to be made as close to
a human as possible, I don't foresee any programmatic solution.  If the
client holds (2) location representations, the problem is theirs and needs
to be resolved there.  Once a PSAP call taker (a second human) is involved,
then the two humans can negotiate the issue.

Too many variables to standardize a solution.

-Marc-

> Just because both civic and geo are included, doesn't mean 
> one is better.  For example, it is  obvious that lat/lon's 
> have measurement criteria whereas civic addresses don't, 
> since they're either "stated" or "derived".
> 
> Parcel-based GIS mapping systems exist today which describe a 
> location in terms of both.  As a simple example, Google Earth 
> does this for you.
> You specify 123 Main Street, Anytown, USA and once it finds 
> it, it also provides a lat/lon.  I admit that the there are 
> challenges with using both, but I expect that those issues 
> will become fewer over time.
> 
> Does there have to be a line in the sand as to whether a 
> particular location is known in terms of civic vs. geo and 
> not both?  I don't think so. 
> 
> 
> Roger Marshall
>  
> 
> one.  No 
> >LoST server/service will be able to determine which one is most 
> >accurate.  You may equate the same problem to the client, 
> but IMO, it's 
> >better that the client make the decision since it's closer 
> to the human 
> >that 'should' know.
> >
> >-Marc-
> >
> >
> >

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 5 Jun 2006 19:04:05 -0500

Why wouldn't the LoSt server simply treat each representation on its own
merits? You give me two locations you get back 2 URIs, even if they are
the same.

> Sent: Tuesday, 6 June 2006 9:44 AM
> To: 'Roger Marshall'; 'Andrew Newton'
> Cc: [email-masked]
> Subject: RE: [Ecrit] [issue2] Is it allowed tospecifycivicand
> Setup for failure example #1: A single LoST query contains both a
civic
> (123
> and let the client deal with it.  This decision needs to be made as
close
> to
civicand
> > >> >>>>>>>> information when determining which PSAP to contact?

------------------------------------------------------------------------------------------------
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: Henning Schulzrinne <[email-masked]>
Date: Mon, 5 Jun 2006 20:11:14 -0400

Yes, you could do that, but you now have to carry possibly two error  
indications, have to worry about carrying two boundaries, etc. Just  
made the protocol much messier, for both client and server. It gets  
worse: in all likelihood, the server has to recurse or iterate  
differently for civic and geo coordinates, so the server has to wait  
until both results are in from upstream servers (or return just one  
result after a timeout). This all just seems pointlessly complex,  
given that the same result can be trivially achieved by splitting the  
query.

On Jun 5, 2006, at 8:04 PM, Winterbottom, James wrote:

>> server/service should not be the one to determine which  
>> representation
> is
>> best.
>>

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 5 Jun 2006 20:31:50 -0400

James,

What happens if the answer is in 2 different admin domains (not cached)?
Does the client resolver have to wait for both responses and assemble them?

One at a time is very clean and quick.

-Marc-

> 
> Why wouldn't the LoSt server simply treat each representation 
> on its own merits? You give me two locations you get back 2 
> URIs, even if they are the same.
> 
> 
> > Main St.) and a geo representation.  All geocode databases 
> return 456 
> > Second St. for the geo.  Which one should LoST prefer?
> > 
> > IMO, each example should be (2) unique queries, one for each 
> > representation, and let the client deal with it.  This 
> decision needs 
> > to be made as
> close
> > to
> > to be resolved there.  Once a PSAP call taker (a second human) is 
> > involved, then the two humans can negotiate the issue.
> > 
> > > criteria whereas civic addresses don't, since they're either 
> > > "stated" or "derived".
> > >
> > > location in terms of both.  As a simple example, Google 
> Earth does 
> > > this for you.
> > > You specify 123 Main Street, Anytown, USA and once it 
> finds it, it 
> > > also provides a lat/lon.  I admit that the there are 
> challenges with 
> > > using both, but I expect that those issues will become fewer over 
> > > time.
> > >
> particular 
> > > location is known in terms of civic vs. geo and not both? 
>  I don't 
> > > think so.
> > >
> > >
> > > Roger Marshall
> > >
> > >
> > > >> >>>>>>>> Would we want the seeker to determine which 
> information
> it
> > > >> >>>>
> > > >> >>>> feels is
> > > >> >>>>

---

From: Andrew Newton <[email-masked]>
Date: Mon, 5 Jun 2006 20:38:53 -0400

It's an extra outer loop, and only more complex if you have somebody  
trying to make it that way.  Otherwise, it is exactly the same amount  
of work.

As to the point that a human, in an emergency situation, at the  
seeker is in a better position to make the correct judgement, I  
dispute that.  Most people will look at lat/long coordinates and not  
have the faintest clue how accurate they are.  If you plunk me down  
in the middle of Tokyo, I'd have to do a coin toss to tell you which  
is more accurate, civic or geo.  And what about cases were the seeker  
is a gateway?

To be honest, whether the server would know better or the client  
would know better is something I think none of us can answer with  
certainty at the moment.  I would just rather not create a protocol  
that precludes one or the other.

-andy

On Jun 5, 2006, at 8:11 PM, Henning Schulzrinne wrote:

> Yes, you could do that, but you now have to carry possibly two  
> error indications, have to worry about carrying two boundaries,  
> etc. Just made the protocol much messier, for both client and  
> server. It gets worse: in all likelihood, the server has to recurse  
> or iterate differently for civic and geo coordinates, so the server  
> has to wait until both results are in from upstream servers (or  
> return just one result after a timeout). This all just seems  
> pointlessly complex, given that the same result can be trivially  
> achieved by splitting the query.
>
>>> Main St.) and a geo representation.  All geocode databases return  
>>> 456
>>> Second
>>> representation,
>>> involved,

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 5 Jun 2006 19:48:33 -0500

Sounds like good reasoning to me.

Do we still have a way for the LoST server to indicate what location information it used in its decision?  That is certainly useful in this case.  The LoST server can just throw out the pieces it doesn't want.

Although, I expect that we are relying on client implementations to make the decision, not people.  I'd rather have the LoST server make that determination, with all the information available, rather than risk missing out vital information.

Even where the client is able to make a determination, this might still fail due to limitations on either side.  For instance, the LoST server might use geodetic information only, and uses a geocoder to get geodetic information.  However, it may be unable to geocode a civic address down to the most precise fields -- it can only geocode down to a street.  If the client threw out geodetic because civic was down to room and geodetic was +/- 200m, then you have lost information that might have been more useful to the LoST server.

> Sent: Tuesday, 6 June 2006 10:39 AM
> To: Henning Schulzrinne
> Cc: [email-masked]
> Subject: Re: [Ecrit] [issue2] Is it allowedtospecifycivicand

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 5 Jun 2006 20:57:00 -0400

> 
> As to the point that a human, in an emergency situation, at 
> the seeker is in a better position to make the correct 
> judgement, I dispute that.

And it's by magic that the LoST server can make this decision?  'Hmm, your
query has an east coast accent so it probably came from New York, so that's
the location I'll respond to and disregard the Seattle location.'

  Most people will look at lat/long 
> coordinates and not have the faintest clue how accurate they 
> are.

Most people utilize mapping software to assist interpreting geo information.

-Marc-

  If you plunk me down in the middle of Tokyo, I'd have 
> to do a coin toss to tell you which is more accurate, civic 
> or geo.  And what about cases were the seeker is a gateway?
> 
> To be honest, whether the server would know better or the 
> client would know better is something I think none of us can 
> answer with certainty at the moment.  I would just rather not 
> create a protocol that precludes one or the other.
> 
> -andy
> 
> >>> representations.  One is in New York City and the other 
> in Seattle.
> >> Which
> >>> one should LoST prefer?
> >>>
> >>> a human as possible, I don't foresee any programmatic 
> solution.  If
> >> the
> >>> client holds (2) location representations, the problem is 
> theirs and
> >> needs

---

From: Shida Schubert <[email-masked]>
Date: Tue, 06 Jun 2006 00:40:11 -0700

I thought we wanted to eliminate as much user's involvement
as possible when making an emergency call, so I object returning
multiple URIs based on multiple location type if we anticipate any
user's interaction as a result of supporting this feature.

Now, on the other hand if the LOST server complies to requirement
Ma8 and returns only one primary URI with multiple alternate URIs
(possibly 2 from Geo resolution and 1 from Civic resolution if one of the
URI from Civic resolution was picked as the primary URI),
I don't really see a problem with LOST server returning URIs based
on two different location types(civic & geo).

BTW did I see any post on this thread stating LOST server might
return an error when it does not support the location type?
I hope I am hallucinating because if that is the behavior
considered for LOST server, it should at least redirect to another
LOST server that can resolve the location type provided(Considering
UA can't provide any other location type it will not be able to make
an emergency call..).

Regards
Shida

Marc Linsner wrote:
>>> server. It gets worse: in all likelihood, the server has to 
>>>       
>> recurse  
>>     
>>> or iterate differently for civic and geo coordinates, so 
>>>       
>> the server  
>>     
>>>>> I'm not arguing geo vs. civil.  All I am trying to state is when
>>>>>           
>>>> multiple
>>>>         
>>>>> Main St.) and a geo representation.  All geocode 
>>>>>           
>> databases return  
>>     
>>>>> 456
>>>>> Second
>>>>> Setup for failure example #2: A single LoST query 
>>>>>           
>> contains two civic
>>     
>>>>> and let the client deal with it.  This decision needs to 
>>>>>           
>> be made as
>>     
>>>> close
>>>>         
>>>>> to
>>>>>> What is the scale of "accuracy" for a civic street address?
>>>>>>             
>>>> 0%,100%?
>>>>         
>>>>>>>> I think we'd have a protocol more capable of adapting to
>>>>>>>>                 
>>>>>> unforeseen,
>>>>>>             
>>>>>>>> to determine which type of location it preferred.  I must
>>>>>>>>                 
>>>>>> admit that
>>>>>>             
>>>>>>>> it seems a bit of a stretch, but I think it is just as possible
>>>>>>>>                 
>>>> as
>>>>         
>>>>>>>> almost always seems to me that if ever there is a 
>>>>>>>>                 
>> question about
>>     
>>>>>>>> preference, it should fall to the LoST service operators and
>>>>>>>>                 
>>>> their
>>>>         
>>>>>>>>>> * You can send as many queries as you want but not with
>>>>>>>>>>                     
>>>>>> the same
>>>>>>             
>>>>>>>>>> * We don't use a PIDF-LO in LoST. We use the raw location
>>>>>>>>>>                     
>>>> info.
>>>>         
>>>>>>>>>> None of the proposals ever used a PIDF-LO as input;
>>>>>>>>>>                     
>>>>>> just location
>>>>>>             
>>>>>>>>>> info.
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>>>> I don't disagree that we ask the LoST server to pick one
>>>>>>>>>>>>>                           
>>>> and
>>>>         
>>>>>>>>>>>> use it.
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>> We need to be consistent though, and so therefore, I
>>>>>>>>>>>>>                           
>>>> propose
>>>>         
>>>>>>>>>>>> that the
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>> LoST server always picks the geo over the civic 
>>>>>>>>>>>>>                           
>> and returns
>>     
>>>>>>>>>>>> a flag in
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>> the response stating that the geo was used to
>>>>>>>>>>>>>                           
>>>>>> perform mapping.
>>>>>>             
>>>>>>>>>>>>> Roger.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> From: Hannes Tschofenig 
>> [mailto:[email-masked]]
>>     
>>>>>>>>>>>>>>> This happens a lot when you are near boundaries because
>>>>>>>>>>>>>>>                               
>>>> the
>>>>         
>>>>>>>>>>>>>> precision
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>>> Even if you send more than one along, the PSAP has to
>>>>>>>>>>>>>>>                               
>>>> know
>>>>         
>>>>>>>>>>>> which one
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>>>>>> except the seeker can make any determination
>>>>>>>>>>>>>>>>>                                   
>>>>>> which type of
>>>>>>             
>>>>>>>>>>>>>>>>> information is better, more accurate, more 
>>>>>>>>>>>>>>>>>                                   
>> recent, etc.
>>     
>>>>>>>>>>>>>>>> Would we want the seeker to determine which information
>>>>>>>>>>>>>>>>                                 
>>>> it
>>>>         
>>>>>>>>>>>> feels is
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>>>>> best to provide to the PSAP?  I've always 
>>>>>>>>>>>>>>>>                                 
>> heard that the
>>     
>>>>>>>>>>>>>> answer would be no:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>> --------------------------------------------------------------------- 
>>     
>>>> ---------------------------
>> --------------------------------------------------------------------- 
>>     
>>>> ---------------------------
>>>> [mf2]
>>>>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 6 Jun 2006 09:40:13 -0400

> user's interaction as a result of supporting this feature.

That sounds ideal, though with all the talk about listing services,  
etc... I'm not sure that is a goal.

Also, the two separate query solution proposed by Henning doesn't  
seem to solve the problem.  The user could still get back two  
different PSAP URIs based on both geo and civic.

> on two different location types(civic & geo).

This sounds more reasonable, and only possible with the single query  
solution.  Well, it could be done with multiple queries, but that  
would mean matching transactions via IP addresses, which has the  
obvious NAT problem.

> UA can't provide any other location type it will not be able to make

Some of the threads are hard for me to follow.  But I would assume  
that any authoritative server that has to say "I don't know." would  
atleast return a default URI.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 6 Jun 2006 12:01:48 -0400

The LoST administration authorities are NOT responsible for location
determination.  The parallel in the legacy environment never has been
responsible for caller location, and I don't understand how they ever
should/will be.  To create a system that puts any amount of liability on the
LoST administration wrt LoST client location determination seems like a bad
design.  If you expect the LoST service to choose a 'preferred' location,
you are placing them in the location determination task.  If a LoST client
(seeker) submits two location representations and it is expected that the
LoST service will determine which representation is preferred, this function
puts liability on the LoST admin authorities.  This cannot be allowed.  It
doesn't matter whether the two submitted locations describe the exact same
square millimeter on the planet, it must be the seeker who determines which
resolved URI to use for follow-on session initiation.  It would be expected
that the two resolutions in this ridiculous example are the same, hence an
easy choice for the seeker to make.  But, since it is completely possible in
a 'I'm LoST, tell where I'm at' scenario to have two jurisdictionally unique
locations (New York City & Seattle), requiring the LoST admin to figure out
the 'preferred' location cannot be expected.

IMO, the basis for this thread is the long standing debate on geo vs. civic.
We (IETF) have support for both representations in all protocols to date and
this is NOT an IETF decision, this is an end-user (caller and/or PSAP)
decision, and this debate needs to happen elsewhere.

Can we now conclude this topic with a resolution that a seeker submits a
single location representation with each query?

-Marc-

> From: Shida Schubert [mailto:[email-masked]] 
> Sent: Tuesday, June 06, 2006 3:40 AM
> To: Marc Linsner
> Cc: 'Andrew Newton'; [email-masked]
> Subject: Re: [Ecrit] [issue2] Is it allowed tospecifycivicand 
> as possible when making an emergency call, so I object 
> returning multiple URIs based on multiple location type if we 
> anticipate any user's interaction as a result of supporting 
> this feature.
> 
> Ma8 and returns only one primary URI with multiple alternate 
> URIs (possibly 2 from Geo resolution and 1 from Civic 
> resolution if one of the URI from Civic resolution was picked 
> as the primary URI), I don't really see a problem with LOST 
> server returning URIs based on two different location 
> types(civic & geo).
> 
> BTW did I see any post on this thread stating LOST server 
> might return an error when it does not support the location type?
> considered for LOST server, it should at least redirect to 
> another LOST server that can resolve the location type 
> provided(Considering UA can't provide any other location type 
> it will not be able to make an emergency call..).
> 
> Regards
> Shida
> 
> Marc Linsner wrote:
> >  
> >   
> >> dispute that.
> > And it's by magic that the LoST server can make this 
> decision?  'Hmm, 
> > your query has an east coast accent so it probably came 
> from New York, 
> > so that's the location I'll respond to and disregard the 
> Seattle location.'
> >
> >> coordinates and not have the faintest clue how accurate they are.
> >>     
> >
> >> to do a coin toss to tell you which is more accurate, 
> civic or geo.  
> >> And what about cases were the seeker is a gateway?
> >>
> >>> worse: in all likelihood, the server has to
> >>>       
> >> recurse
> >>     
> >>>> Why wouldn't the LoSt server simply treat each representation on 
> >>>> its own merits? You give me two locations you get back 2 
> URIs, even 
> >>>> if they are the same.
> >>>>
> >>>>
> >>>>         
> >>>>> representation, and let the client deal with it.  This decision 
> >>>>> needs to
> >>>>>           
> >> be made as
> >>     
> >>>> close
> >>>>         
> >>>>> to
> >>>>>> better.  For example, it is  obvious that lat/lon's have 
> >>>>>> measurement criteria whereas civic addresses don't, 
> since they're 
> finds it, 
> >>>>>> it also provides a lat/lon.  I admit that the there are 
> >>>>>> challenges with using both, but I expect that those 
> issues will 
> >>>>>> become fewer over time.
> >>>>>>
> >>>>>> particular location is known in terms of civic vs. geo and not 
> >>>>>> both?  I don't think so.
> >>>>>>
> >>>>>>
> >>>>>> Roger Marshall
> >>>>>>
> >>>>>>
> >>>>>>             
> specify civicand 
> >>>> This message is for the designated recipient only and 
> may contain 
> >>>> privileged, proprietary, or otherwise private information.
> >>>> immediately and delete the original.  Any unauthorized 
> use of this 
> >>>> email is prohibited.
> >>>>
> >>>>         
> >>

---

From: Shida Schubert <[email-masked]>
Date: Tue, 06 Jun 2006 12:53:28 -0700

I personally don't have any objection to Marc's resolution.

Regards
Shida

Marc Linsner wrote:
>>> Most people utilize mapping software to assist interpreting 
>>>       
>> geo information.
>>     
>>> -Marc-
>>>
>>>> certainty at the moment.  I would just rather not create a 
>>>>         
>> protocol 
>>     
>>>>> Yes, you could do that, but you now have to carry 
>>>>>           
>> possibly two error 
>>     
>>>>> indications, have to worry about carrying two boundaries, 
>>>>>           
>> etc. Just 
>>     
>>>>> made the protocol much messier, for both client and 
>>>>>           
>> server. It gets 
>>     
>> URIs, even 
>>>>>> if they are the same.
>>>>>>> Setup for failure example #1: A single LoST query 
>>>>>>>               
>> contains both a
>>     
>>>>>>>           
>>>>>>>               
>>>>>> civic
>>>>>>         
>>>>>>             
>>>>>>> (123
>>>>>>> to be resolved there.  Once a PSAP call taker (a second 
>>>>>>>               
>> human) is 
>>     
>>>>>>>> Just because both civic and geo are included, doesn't 
>>>>>>>>                 
>> mean one is 
>>     
>> since they're 
>>>>>>>> either "stated" or "derived".
>>>>>>>>
>>>>>>>>> Subject: RE: [Ecrit] [issue2] Is it allowed to 
>>>>>>>>>                   
>> specifycivicand 
>>     
>>>>>>>>> LoST server/service will be able to determine which 
>>>>>>>>>                   
>> one is most 
>>     
>>>>>>>>>> it seems a bit of a stretch, but I think it is just 
>>>>>>>>>>                     
>> as possible
>>     
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>> as
>>>>>>         
>>>>>>             
>>>>>>>>>>>> At the PSAP and the emergency routing proxy I 
>>>>>>>>>>>>                         
>> agree with you.
>>     
>>>>>>>>>>>>                     
>>>>>>>>>>>>                         
>>>>>>>>>>>>>> Using geo and civic might be, from a certain 
>>>>>>>>>>>>>>                             
>> point of view,
>>     
>>>>>>>>>>>>>>                         
>>>>>>>>>>>>>>                             
>>>>>>>>>>>> just be an
>>>>>>>>>>>>                     
>>>>>>>>>>>>                         
>>>>>>>>>>>>>>>> Everyone seems to be in favor for a civic OR 
>>>>>>>>>>>>>>>>                                 
>> geospatial.
>>     
>>>>>>>>>>>>>>>>> This happens a lot when you are near 
>>>>>>>>>>>>>>>>>                                   
>> boundaries because
>>     
>>>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>>>                                   
>>>>>> the
>>>>>>         
>>>>>>             
>>>>>>>>>>>>>>>> precision
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>>>>                                 
>>>>>>>>>>>>>>>>>> On Jun 5, 2006, at 2:53 PM, Henning 
>>>>>>>>>>>>>>>>>>                                     
>> Schulzrinne wrote:
>>     
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>                                 
>>>>>>>>>>>>>>>>>>

---

From: Shida Schubert <[email-masked]>
Date: Tue, 06 Jun 2006 13:07:27 -0700

Hi Andrew;

comments inline.

> etc... I'm not sure that is a goal.
I thought getting a list would be a completely different query distinct
from "get me a URI for this
service X for this location Y".
> Also, the two separate query solution proposed by Henning doesn't seem
> to solve the problem. The user could still get back two different PSAP
> URIs based on both geo and civic.
Agree.
> solution. Well, it could be done with multiple queries, but that would
> mean matching transactions via IP addresses, which has the obvious NAT
> problem.
Agree.
> Some of the threads are hard for me to follow. But I would assume that
> any authoritative server that has to say "I don't know." would atleast
> return a default URI.
That's good to hear, especially when it's coming from one of the
co-author of the draft.

Thanks
Shida

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 6 Jun 2006 16:18:26 -0400

snip.....................................
> >> (possibly 2 from Geo resolution and 1 from Civic 
> resolution if one of 
> >> the URI from Civic resolution was picked as the primary 
> URI), I don't 
> >> really see a problem with LOST server returning URIs based on two 
> >> different location types(civic & geo).
> >
snip.............................

Requirement Ma8 talks about returning multiple uri types (sip, im, email,
etc.) all for the SAME location representation.  Ma8 does NOT deal with
resolving multiple location representations that are sent within the same
query.

-Marc-

---

From: Shida Schubert <[email-masked]>
Date: Tue, 06 Jun 2006 15:00:26 -0700

My mistake I meant Ma9 not Ma8.

Regards
Shida

Marc Linsner wrote:
>>> This sounds more reasonable, and only possible with the 
>>>       
>> single query 
>>     
>>> solution. Well, it could be done with multiple queries, but 
>>>       
>> that would 
>>     
>>> mean matching transactions via IP addresses, which has the 
>>>       
>> obvious NAT 
>>     
>>> problem.
>>>       
>> Agree.
>>

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 7 Jun 2006 09:28:39 +0100

> St. for the geo.  Which one should LoST prefer?

By coincidence, I had an email from a friend in Switzerland yesterday that
expresses a similar situation.

His house is labelled 38 and the house next door is 40 - all the signs on
the houses say this and his post is addressed to number 38. He has just had
a letter from the local authority telling him that a mistake was made N
(where N>20) years ago and actually his house is 40 and the other one is
38. However, he and his neighbour intend to keep the existing numbers
rather than try to deal with redirecting vast amounts of post.

So, assuming the official databases are updated, the lat-long of the house
with "38" written on it will return number 40, while that of the house with
"40" written on it will return number 38. Which one should be used?

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