[standards-jig] NEW: Geographic Location Information (JEP-0080)

Ralph Meijer jabber.org at ralphm.ik.nu
Wed Apr 16 08:00:44 UTC 2003

On Tue, Apr 15, 2003 at 05:41:25PM -0500, Peter Saint-Andre wrote:
> Joe Hildebrand has submitted a proposal for encapsulating information
> about geographical location in Jabber/XMPP. The URL is:

(warning: long response)


First of all: Joe, thanks for this JEP.

Since Temas gave me the idea of making the Jabber World Map [1], I've been
interested in maps and location linked/based information. This JEP should be
very usefull for getting effords off the ground.

I've been wanting to implement a pub/sub system for the Map as well, so you
can send your location from anywhere and have your 'bulb' move along the map
as you go. I have done a lot of thinking about this, and have been tempted to
use the presence stanza to include this information, but I really think that
should be avoided and even discouraged. Although you do hint that it might
not be the best way to implement that, I want to make it more evident and
I'll try to motivate that here, for others to think about, too:

Presence and location are two separate axes in my view. Although in practice
you need to exist (!) to have a location, being able to send your location
doesn't need to involve sending presence and visa versa.

When I am in a certain location with a mobile device, my presence can change
(from online to dnd) while I stay in the same spot. In this case I would send
no location in the presence stanza (I guess).

Then again, moving with the mobile device shouldn't also update the presence
information. However, the way presence works, sending a presence stanza with
only the location information as in the example in the JEP, sets your presence
to 'online', forgetting the presence you might have set earlier. The client
should remember and resend the correct presence information to 'fix' this.

And this takes me to the next problem. Say clients were to implement this into
the presence stanza, everyone on the roster of a user will get his location
information. I can imagine mobile clients (on a cell phone or PDA) that update
their location information every minute.

Stpeter has more than 1000 people on his roster...

We saw this problem earlier with the gabber hack for including the current song
in XMMS in the presence stanza. People who used a certain client and were in a
groupchat kept asking why presence was updated so much, although it didn't
change. The client just displayed 'ralphm is online' on every song change.

In both examples, most people don't NEED the location information of somebody
else. Certainly in mobile clients were you have to pay for every byte
(GPRS anyone), this is totally undesirable, and there is no way to avoid others
of sending extended presence packets short of removing them from your roster or
being invisable.

As I said before, I really want to avoid clients implementing this in the
presence stanza. Please use directed messages (example 4) or better yet pub/sub
(example 5/6).

Now some other part of the JEP. Examples 5/6 are about how you could send
location information via pub/sub. The way it is done currently makes it
possible for all that can publish to the node 'location' to send to the item
with id 'portia at merchants'. Also if they are not representing
'portia at merchants', which is suggested to be the JID of the person to whom the
location information belongs.

A better example would be to have the node id be something like
'generic/location/portia at merchants' and the item id 'current'. That way,
people can subscribe to the location data of one person, and the node
can be configured so that only 'portia at merchants' can publish to that node.

Note that implementing it via pubsub also makes it possible to do away
with example 2/3. Someone could subscribe to the pub/sub node, and configure
his subscription to not send updates. It could still query the node however,
and your authorization would already be taken care of by the pub/sub system.

That's it (for now),


More information about the Standards mailing list