Joe Hildebrand wrote:
On Mar 2, 2009, at 3:15 PM, Peter Saint-Andre wrote:
Uhm.. is that meaningful? Usually for location queries external
references are more useful than your address (e.g. your MAC moves with
your notebook, so what is the purpose of doing a query with it?)
I meant your locally-assigned IPv4 or IPv6 address, not your MAC
address. My bad.
Actually, I meant the local ethernet (MAC) address of your active
network connection(s). There are network elements that keep track of
the ethernet addresses they have seen, and can glean location
information from that connectivity information. Imagine that your
switch's ARP map was query-able, and you knew where each switch port
was punched down in a given office. Also imagine a network of
wireless access points that can triangulate on you, given your
ethernet address.
I will come back to you on that one when i have fully understood what
you meant (can't really think in the bus I'm sitting in ATM ;-)
I had a couple of other suggestions for -255, as well:
1) Need a "discovering support" section. I might want to find a
location service using disco#items/disco#info, as implied by "run as a
component on the same or a different machine from the XMPP server itself".
Yes that makes sense. Will add to TODO list.
2) For components outside your core XMPP service, it would be nice to
direct a presence to them first, so that they get notified when you go
offline.
If a location server provide location upon request, I'm not sure if
online/offline presence adds much...?
3) Some location services may be able to publish your XEP-80 location
to PEP on your behalf. If so, they should return an empty result:
<iq from='location.shakespeare.lit'
id='q01'
to='ham...@shakespeare.lit <mailto:to=%27ham...@shakespeare.lit>/phone'
type='result'
xml:lang='en-US'/>
If I understand you correctly, that is indeed what is specified (see
Example 6)
Helge
