Re: [Ecrit] LoST

Hi Martin,

Dawson, Martin wrote:
> Thanks Hannes,
>
> Yes, I'm suggesting that since the profile spec is about to go RFC, that
> the LoST spec might just as well reference it so we have a consistent
> ecology of specs. I think that having a subsequent spec make the profile
> mandatory would only be an issue if it came after LoST was implemented.
> On the other hand, if we assume it will happen before LoST is
> implemented, then why not just include the requirement now.
>   
I would like to let the group decide.

> With respect to GPS - a LIS (LCS, whatever) could utilize any suitable
> protocol, including SUPL, to do GPS interactions with the client - it
> still casts the result as a PIDF-LO in the response. I'm not really
> thinking of the situation where the device does a GPS fix or gets it
> from some other non-PIDF-LO source. In that case, I'd certainly agree
> that the device may as well transcode it into the basic form. I'm not
> really concerned about that situation.
>
>   
I know about this feature in SUPL.
Still, do most GPS devices today use SUPL?

Ciao
Hannes

> Cheers,
> Martin
>
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> Sent: Wednesday, 11 July 2007 7:33 PM
> To: Dawson, Martin
> Cc: Winterbottom, James; ECRIT
> Subject: Re: [Ecrit] LoST
>
> Hi Martin,
>
> Dawson, Martin wrote:
>   
>> Hi Hannes,
>>
>> This seems a bit bogged down in the here and now... A LIS for almost
>>     
> any
>   
>> access technology, with or without GPS, could produce a geo-shape as a
>> consequence of the location-determination technique it employs. What
>> 3GPP may be thinking now doesn't seem particularly pertinent.
>>   
>>     
> True. A LCS (this is the correct terminology now) can indeed produce a 
> PIDF-LO with the Geo-Shapes format.
>
> When you use a GPS receiver today (and probably for a long time) then it
>
> does not produce a format in XML format since there is just no LCP 
> involved.
>
>   
>> There's already a pdif-lo-profile draft ([sic] is the spelling ever
>> going to get corrected btw or is a title immutable?) that states what
>> shapes should be used and defines what the LIS clients can expect to
>> receive.
>>   
>>     
> We decided not to change the file name. When the document gets published
>
> as RFC then the filename does not matter anway.
> Btw, we recognized the wrong spelling with version -04 or so.
>
>   
>> While I accept that a LoST implementor could add support for that
>> profile, as long as it is optional to do so, the client cannot be sure
>> that anything other than a point will be supported.
>>     
> A new document can also say that the new location profile is mandatory 
> to implement. Do you think that will be a problem?
>
>   
>>  This adds the dual
>> issue of making the client always convert to a point form and/or
>> eliminating the prospect of LoST servers being able to do more
>> sophisticated routing based on weighted coverage by uncertainty.
>>
>> Rather than invite the compatibility issue at a later date, wouldn't
>>     
> it
>   
>> be more prudent just to add the requirement now?
>>   
>>     
> No doubt that we could add an additional location profile right now.
>
> I am just repeating what we agreed earlier in the working group on this 
> particular issue. If the working group now thinks that this is a problem
>
> then we should re-consider it. I just want to open-up previously closed 
> or postponed issues too quickly.
>
>
> Ciao
> Hannes
>
>   
>> Cheers,
>> Martin
>>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
>> Sent: Wednesday, 11 July 2007 6:55 PM
>> To: Winterbottom, James
>> Cc: ECRIT
>> Subject: Re: [Ecrit] LoST
>>
>> Hi James,
>>
>> Winterbottom, James wrote:
>>   
>>     
>>> Hi Hannes,
>>>
>>> That makes perfect sense.
>>>
>>> The issue that I am most concerned about is the limitation in the
>>>     
>>>       
>> shape
>>   
>>     
>>> representation in the basic location profile. As it currently stands
>>>       
> I
>   
>>> cannot use standard GPS related shapes, my end-point has to interpret
>>> location and put into a profile. This is incompatible with a large
>>> number of solutions deployed today on which many deployments will be
>>> based, at least initially. I strongly urge this WG to reconsider this
>>> restriction and include circle, and ellipse at a minimum.
>>>   
>>>     
>>>       
>> Some time back we also discussed this issue and the conclusion was the
>>     
>
>   
>> following:
>> * Let us build a mechanism in there to have a mechanism to extend the 
>> location shapes.
>> * Let us specify simple location shapes first.
>>
>> I know that there is this limitation with geodetic shapes and a
>>     
> separate
>   
>> location profile would be needed to address GPS and the cellular
>>     
> world.
>   
>> On the cellular aspect we also had a discussion with the 3GPP. There 
>> they are currently not using LoST at the end point since they are 
>> focusing on a different architecture (see 
>>
>>     
> http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview-
>   
>> 00). 
>> Even if they would use LoST at the end point they most likely want to 
>> hide the location information of the end point or to make use of 
>> information like cell ids (as recorded in the issue tracker a while
>>     
> ago:
>   
>> http://www.tschofenig.priv.at:8080/lost/issue16).
>>
>> Now, everything boils down to the question of GPS. Since GPS produces 
>> data in a format that is not PIDF-LO alike we can already assume that 
>> the end host has to understand the format. It can now encode it in 
>> different ways. In previous discussions a couple of us wanted to add a
>>     
>
>   
>> polygon as a location profile to the LoST document since it would also
>>     
>
>   
>> address the location hiding requirement. Since this issue came also up
>>     
>
>   
>> in the location hiding context we postpone this topic entirely.
>>
>> Hence, it is up to us to come up with a location profile that supports
>> * a circle
>> * an ellipse
>> * a polygon,
>> * a combination of the above
>> * cell-ids
>> if we think there is a need todo so.
>>
>> Ciao
>> Hannes
>>
>>   
>>     
>>> Cheers
>>> James
>>>
>>>   
>>>     
>>>       
>>>> -----Original Message-----
>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>>>> Sent: Wednesday, 11 July 2007 4:58 PM
>>>> To: Winterbottom, James
>>>> Cc: ECRIT
>>>> Subject: Re: [Ecrit] LoST
>>>>
>>>> Hi James,
>>>>
>>>> let me pick a concrete example: LoST server discovery.
>>>> Currently, we have specified the usage of DHCP and DNS. Only the
>>>>     
>>>>       
>>>>         
>>> former
>>>   
>>>     
>>>       
>>>> allows to discover the LoST server in the access network. I am,
>>>>     
>>>>       
>>>>         
>>> however,
>>>   
>>>     
>>>       
>>>> aware of the work on HELD discovery, see
>>>>
>>>>         
> http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery-
>   
>>>> 01.txt,
>>>> that aims to discover a HELD server in the access network using DNS
>>>> mechanisms.
>>>>
>>>> Now, even though the current LoST draft does not describe how to
>>>> discover a LoST server using DNS in the access network that can be
>>>> extended later when the above document is generalized (which I think
>>>> would be a good idea).
>>>>
>>>> Does that make sense to you?
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> Winterbottom, James wrote:
>>>>     
>>>>       
>>>>         
>>>>> Hi Hannes,
>>>>>
>>>>> What exactly do you mean by postponed?
>>>>>
>>>>> Cheers
>>>>> James
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>>         
>>>>>           
>>>>>> -----Original Message-----
>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>>>>>> Sent: Wednesday, 11 July 2007 5:58 AM
>>>>>> To: ECRIT
>>>>>> Subject: [Ecrit] LoST
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> during the WGLC we have received a number of comments. Then, we
>>>>>>
>>>>>>         
>>>>>>           
>>>>>>             
>>>>> delayed
>>>>>
>>>>>       
>>>>>         
>>>>>           
>>>>>> the completion of the work because of the location hiding
>>>>>>         
>>>>>>           
>>>>>>             
>>> discussions.
>>>   
>>>     
>>>       
>>>>>> Now, you can find the latest version of the document at:
>>>>>>
>>>>>>
>>>>>>         
>>>>>>           
>>>>>>             
> http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-los
>   
>>   
>>     
>>>   
>>>     
>>>       
>>>>> t-
>>>>>
>>>>>       
>>>>>         
>>>>>           
>>>>>> 06.txt
>>>>>>
>>>>>> We have also updated the DHCP-based LoST discovery draft (based on
>>>>>>         
>>>>>>           
>>>>>>             
>>> the
>>>   
>>>     
>>>       
>>>>>> comments we received from the DHC working group). The document can
>>>>>>         
>>>>>>           
>>>>>>             
>>> be
>>>   
>>>     
>>>       
>>>>>> found here:
>>>>>>
>>>>>>
>>>>>>         
>>>>>>           
>>>>>>             
> http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft-
>   
>>   
>>     
>>>   
>>>     
>>>       
>>>>>> ietf-ecrit-dhc-lost-discovery-02.txt
>>>>>>
>>>>>> Now, here is the unfortunate news: It seems that we did not submit
>>>>>>         
>>>>>>           
>>>>>>             
>>> the
>>>   
>>>     
>>>       
>>>>>> LoST draft :-(
>>>>>> Everyone was assuming that someone else is going to submit it.
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>> PS: James has recently sent a number of comments. Some of them got
>>>>>> reflected in the document (namely the editorial onces). Others got
>>>>>> intentionally postponed since we discussed them already in the
>>>>>>         
>>>>>>           
>>>>>>             
>>> past.
>>>   
>>>     
>>>       
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> Ecrit@ietf.org
>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>>>         
>>>>>>           
>>>>>>             
>>>>>       
>>>>>         
>>>>>           
> ------------------------------------------------------------------------
>   
>>   
>>     
>>>   
>>>     
>>>       
>>>> ------------------------
>>>>     
>>>>       
>>>>         
>>>>> 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]
>>>>>
>>>>>
>>>>>       
>>>>>         
>>>>>           
>>>     
>>>       
> ------------------------------------------------------------------------
>   
>> ------------------------
>>   
>>     
>>> 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]
>>>
>>>   
>>>     
>>>       
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ecrit
>>
>>
>>     
> ------------------------------------------------------------------------
> ------------------------
>   
>> 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]
>>
>>   
>>     
>
>
> ------------------------------------------------------------------------------------------------
> 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]
>
>   

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit