[Standards] LAST CALL: XEP-0255 (Location Query)

Simon Tennant (buddycloud) simon at buddycloud.com
Wed May 19 10:48:37 UTC 2010


On 14/05/2010 06:15, Bernard Aboba wrote:
> Having gone through the (somewhat painful) process of editing RFC 
> 3825bis (see http://tools.ietf.org/html/draft-ietf-geopriv-rfc3825bis) 
> and having to carefully delineate between the meaning of the terms 
> "uncertainty" and "resolution", I would recommend that the authors 
> think very carefully about the meaning of the term "accuracy" in this 
> document.
It's quite common for location-based systems to return the level of 
accuracy that they are able to calculate the position to.  Could you be 
more specific about your accuracy concern?
> The other thing that strikes me about this document is that doesn't 
> talk much about distinguishing between third party queries and a host 
> querying for its own location.  This distinction has a  number of 
> privacy implications and has led to quite a bit of angst within the 
> GEOPRIV WG, as reflected in documents such as the HELD identity 
> extensions document (see 
> http://tools.ietf.org/htmldraft-ietf-geopriv-held-identity-extensions ).

XEP-0255 is a method for a component or JID to send measurements to a 
server and receive back a calculated location. Just that.

I have been following the HELD process closely and after reading it, I'm 
pleased to be working on XMPP instead. They have had to create privacy, 
distribution, authentication and trust mechanisms from scratch.  XMPP 
provides privacy, distruibtion, authentication and trust for free 
(XEP-0060, XEP-0080 amongst others).

If there is a reason to duplicate these functions then they should be 
included in XEP-0255.  In my opinion, the XEP specification's great 
benefit is the ability to combine them together. XEP-0255 doesn't try to 
define how location must be shared.  Some implementers may use PEP, 
others may prefer Pubsub or even <message> stanzas.  This really depends 
on the specifics of the application and in my opinion is not spec dependent.

S.



More information about the Standards mailing list