Subject: RE: [Ecrit] [issue2] Is it allowed to specify civic and geospatialinfointo the query?

From: "Roger Marshall" <[email-masked]>
Date: Mon, 5 Jun 2006 14:35:28 -0700

Seems like a lot of programmatic overhead being built in to the LoST
client... how to parse the original PIDF-LO, how to pick between
multiple tuples, etc.  How many LoST clients are there go to be?
Millions?

>-----Original Message-----
>From: Hannes Tschofenig [mailto:[email-masked]] 
>Sent: Monday, June 05, 2006 2:24 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,
>
>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