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

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

I admit that this theme is somewhat of a tangent to the subject, but can
the authors of LoST help me understand the reasons for not using the
PIDF-LO.

Is it the overhead?  Is the PIDF-LO not adequate to convey location some
how?

As an example, if the PIDF-LO format is changed significantly in some
way, it will mandate a s/w change to ~10^8 clients vs. only ~10^2 - 10^4
server instances.
 
It seems to me that as the PIDF-LO undergoes changes over time, that the
choice between having to modify client software vs. server software
instances represents a huge difference in effort.

Roger Marshall

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 5 Jun 2006 20:18:30 -0400

Extracting civic and/or geo element from PIDF-LO seems rather trivial  
for the client and the basic division of PIDF-LO would need more than  
just a minor change in the spec. (In any event, in many cases, the  
client will need to construct the location information from local non- 
XML data, be it GPS, LLDP-MED or DHCP, and can't just blindly copy  
some XML blob it's been handed.)

No, I'm not worried about the few extra elements, although they are  
not particularly helpful (and, in the case of the entity URL, may  
need scrubbing to avoid revealing unnecessary privacy-sensitive  
personal information downstream).

---

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

Roger,

The location information in PIDF-LO for geo is GML and the civic has  
its own namespace, making it really easy to pluck that information  
out of it.  The other elements didn't seem necessary.  The parts that  
LoST uses are an exact fragment of the PIDF-LO would be constructed  
and passed in the SIP message.

-andy

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 07 Jun 2006 15:23:04 -0400

You seem to be assuming that the LoST client is the user terminal, and 
at the same time assuming that it has to parse PIDF-LO. This doesn't 
make sense to me -- won't it be the originator of the PIDF-LO and have 
the raw data in hand?