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

Joe Hildebrand JHildebrand at jabber.com
Wed Apr 16 15:52:42 UTC 2003

(elided, answers inline)

> From: Ralph Meijer [mailto:jabber.org at ralphm.ik.nu]
> 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:

I'll move 3.1 to the end of the use cases, and put some deprecation language
in.  I think it is important to include it still, particularly until pub/sub
is more widely deployed.

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

Yes.  Client implementations need to do the right thing.  I'm also trying to


into to the IETF docs for this sort of thing, too.  This would mean that
this session is not eligible for default resource routing, so that if this
is the only resource present, the message could be offlined.  That would
mean that your non-IM device could participate in the presence cloud.

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

I think I talk about this in section 3.4.  I can add more.

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

No need for the client to send this to groupchat rooms, too...

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

Section 8 of draft-ietf-xmpp-im-08 allows this.

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

I should make it clear in the JEP that the node to publish to is totally
implementation-dependant.  I'll also remove the SHOULD about the item ID,
and make that impl-dependant as well.

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

Again, I think the IQ's are useful, so I don't want to remove them.  I
*will* add a note that basically says this, though, to push people towards

Joe Hildebrand

More information about the Standards mailing list