[Standards] XEP-0255 (Location Query)

Helge Timenes helge at buddycloud.com
Fri Dec 12 15:52:56 UTC 2008

On Thu, 11 Dec 2008 16:15:30 -0500, Stephen Pendleton <stephenpendleton at hotmail.com> wrote:
> Some comments I have on 0255 during implementation:
> - XEP-0080 uses <lat>, <lon>, <alt> instead of <latitude>, <longitude>...
> so the examples need to be changed. The schema looks right though. 

Have updated the examples. Thanks for reporting. Also I have added the optional element <signalstrength> to the <beacon> element, which is something I just plain forgot about in the earlier versions (@Peter: will send you updated xml file)

> - Is Example 7 allowed in XMPP/pubsub? It looks like the component is
> publishing to the entities node. I suppose there is nothing wrong with
> that, I just haven't seen it before.

I was wondering the same thing when i wrote the draft. It is probably not the intended use of pubsub, but it does save a round trip of the location results. In buddycloud we have configured our location component such that our server (ejabberd) allows it to post on behalf of users (@Simon: correct me if I'm wrong or unclear on this)


>> To: standards at xmpp.org> Date: Wed, 26 Nov 2008 22:43:45 +0100> From:
> helge at buddycloud.com> Subject: [Standards] XEP-0255 (Location Query)> > >
> Some comments to the XEP-0255 / "Location Query" draft
> (http://xmpp.org/extensions/xep-0255.html):> > 1) Beacon signal strength
> seems to have been forgotten in the draft specification. This is a mistake
> and I will correct it. > > 2) In the development project from which
> XEP-0255 was born (Buddycloud), we never considered using Timing Advance
> (http://en.wikipedia.org/wiki/Timing_advance) for triangulation between
> cell towers, simply because it was too troublesome getting the deep API
> access required on Symbian, our main client platform.> > However I assume
> this is something other implementers may want to use, so i think it should
> be covered by the XEP.> > The specification currently uses a generic data
> type for all radio beacons (cell towers, wifi access points, bluetooth
> devices). However timing advance would only apply to cell towers. In order
> to keep this symmetry, and as timing advance translate directly to distance
> (scaled by a factor of 550m per unit), i am pondering whether to add the
> somewhat more generic field 'distance' rather than 'timing advance'. I am
> not sure how a client would derive distance to, say a wifi access point,
> but I think that is more likely than a timing advance value...> > Any
> thoughts?> > > Helge> 
> _________________________________________________________________
> Send e-mail faster without improving your typing skills.
> http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_122008

More information about the Standards mailing list