Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Joe Hildebrand]

On Mar 5, 2009, at 5:49 AM, Pedro Melo wrote:

I don't see the usefulness of sending my own mac address. But  
sending the mac address of my default gateway, then yes, I find that  
very useful. That's how a lot of "location aware"-tools for the Mac  
work for example.


It's just another source of information, if the network is "smart".
In some environments, there are services that can take an ethernet  
address, and return location.  I want to deploy into one of those  
environments, and do it in a standard manner.


--
Joe Hildebrand

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Pedro Melo]

On Mar 2, 2009, at 7:23 PM, Peter Saint-Andre wrote:

I was chatting with Joe Hildebrand about XEP-0255 and he mentioned  
that
it would be good to add a reference type for an Ethernet address,  
such as:



 
   
 00.31.55.f9.1d.de
 ethernet
   
 


It seems that we'd need this because your ethernet address might be
different from your wifi address even in the same location (e.g.,  
where
I am right now my ethernet address is 00:23:32:d4:28:ea whereas my  
wifi

address is 00:23:6c:88:d4:1d).


I don't see the usefulness of sending my own mac address. But sending  
the mac address of my default gateway, then yes, I find that very  
useful. That's how a lot of "location aware"-tools for the Mac work  
for example.


Other scenario: bounjour printers, for example. I would send the mac  
address of the printer and get the coordinates. They usually have a  
"location" field in the bonjour advertisement, though.


Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: m...@simplicidade.org
Use XMPP!

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Fabio Forno]

On Tue, Mar 3, 2009 at 6:08 PM, Helge Timenes  wrote:

> The reference type "rfid" has been actually been foreseen since v0.1. This
> is also not covered by any examples and I have made no assumptions as to how
> the ID of a RFID reference should be composed as I don't really know much
> about it :-) Fabio: Perhaps you could help me with a short example?

I think that very few know, since they are making things overcomplicated ;)

Afaik (which is not a lot)  here you can find the most general way for
encoding rfid data:

http://www.epcglobalinc.org/standards/tds/

To make the story short the urn scheme is something like this:

urn:epc:id:gid:1.1.100

where
 - epc tells that you are encoding things according to those specs
 - id means that the urn refers to a pure tag id (there more complex
schemes for application dependent data, filters...)
 - gid: the identity type, says that is a general id, indicating that
the following id must not be interpreted for a specific purpose such
as a shipping number or a product code
 - and finally finally the numeric id

Therefore in the  element I'd put the EPC urn, and than let the
application give it a meaning according to the used encoding

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Joe Hildebrand]

On Mar 3, 2009, at 11:17 PM, Helge Timenes wrote:


Joe Hildebrand wrote:


On Mar 3, 2009, at 10:21 AM, Helge Timenes wrote:

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 ;-)


To be clear, what I'm asking for is the addition of an "ethernet"  
reference type, which is the ethernet address of a NIC on the  
user's machine.
Let me try to recapture this scenario, just to see if i understood  
it right: Someone attaches his notebook to, say, an ethernet wall  
socket in an office building. The local network switch, or some  
service with access to it, knows where each ethernet wall socket is  
located (room number, lat/lon or what have you) and thus would know  
where each connected device is. So if the device itself wants to  
know, it would send a location query with the NIC MAC to this  
service and get its location served on a plate. Is that about right?


That is exactly correct.

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


The use case I've got is that the location server wants to know  
when your device is no longer a source of location.  Unavailable  
presence is a great indicator for that.  If you direct a presence  
to the location server, then it will always get notified when you  
go offline, in much the same way that a XEP-45 chat room does.
What would the server do with the offline presence info? Clear this  
users geoloc Pub-Sub node?


Yes, or prefer a lower-priority resource's location information.

As a corollary, re-publishing a different ethernet address from the  
same resource should replace the previous information, and publishing  
an empty set retracts the previous information.

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Helge Timenes]

Joe Hildebrand wrote:

On Mar 3, 2009, at 10:21 AM, Helge Timenes wrote:

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 ;-)


To be clear, what I'm asking for is the addition of an "ethernet" 
reference type, which is the ethernet address of a NIC on the user's 
machine.
Let me try to recapture this scenario, just to see if i understood it 
right: Someone attaches his notebook to, say, an ethernet wall socket in 
an office building. The local network switch, or some service with 
access to it, knows where each ethernet wall socket is located (room 
number, lat/lon or what have you) and thus would know where each 
connected device is. So if the device itself wants to know, it would 
send a location query with the NIC MAC to this service and get its 
location served on a plate. Is that about right?


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.


Thanks.

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


The use case I've got is that the location server wants to know when 
your device is no longer a source of location.  Unavailable presence 
is a great indicator for that.  If you direct a presence to the 
location server, then it will always get notified when you go offline, 
in much the same way that a XEP-45 chat room does.
What would the server do with the offline presence info? Clear this 
users geoloc Pub-Sub node?

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Joe Hildebrand]

On Mar 3, 2009, at 10:21 AM, Helge Timenes wrote:

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 ;-)


To be clear, what I'm asking for is the addition of an "ethernet"  
reference type, which is the ethernet address of a NIC on the user's  
machine.


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.


Thanks.

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


The use case I've got is that the location server wants to know when  
your device is no longer a source of location.  Unavailable presence  
is a great indicator for that.  If you direct a presence to the  
location server, then it will always get notified when you go offline,  
in much the same way that a XEP-45 chat room does.


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:


 
If I understand you correctly, that is indeed what is specified (see  
Example 6)


Whoops, sorry.  Missed that, perhaps because it wasn't clear to me  
that Example 7 was coming from the location service.  Perhaps there  
needs to be a little more expository text between the examples.

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Helge Timenes]

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:


id='q01' 
to='ham...@shakespeare.lit /phone' 
type='result' 
xml:lang='en-US'/>
If I understand you correctly, that is indeed what is specified (see 
Example 6)



Helge

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Helge Timenes]

Fabio Forno wrote:

On Mon, Mar 2, 2009 at 11:15 PM, Peter Saint-Andre  wrote:
  

I meant your locally-assigned IPv4 or IPv6 address, not your MAC
address. My bad.



Penitenziagite! :D Yep, now I get the point and it makes sense

  
Sorry for being a bit late responding to this. The reference type "ip" 
was added on last revision (v04 2009-02-17). Granted it does not show up 
in the examples... Will add one.




Besides that there is one more reference we are starting using: RFID
addresses, which allow to pinpoint the exact position of the device.
  


The only problem is that there are few different id schemes (e.g EPC,
96bits; iso 15693, 64 bits and other proprietary). Somewhere there urn
schemes allowing the mapping between the different standards, but a
solution like this should be general enough:
rfid
idscheme:id

(need to do some more research for confirming)

  
The reference type "rfid" has been actually been foreseen since v0.1. 
This is also not covered by any examples and I have made no assumptions 
as to how the ID of a RFID reference should be composed as I don't 
really know much about it :-) Fabio: Perhaps you could help me with a 
short example?



Helge

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Joe Hildebrand]

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

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Seth Fitzsimmons]

>>> It seems that we'd need this because your ethernet address might be
>>> different from your wifi address even in the same location (e.g., where
>>> I am right now my ethernet address is 00:23:32:d4:28:ea whereas my wifi
>>> address is 00:23:6c:88:d4:1d).
>>>
>>
>> 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.

I think the intent was to pass in WiFi beacons (or MAC addresses of
visible access points) rather than the assigned IP.

That said, HELD (part of the IETF GeoPriv effort) attempts to provide
mechanisms to determine location from IP:
http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-12

seth

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Fabio Forno]

On Mon, Mar 2, 2009 at 11:15 PM, Peter Saint-Andre  wrote:
>
> I meant your locally-assigned IPv4 or IPv6 address, not your MAC
> address. My bad.

Penitenziagite! :D Yep, now I get the point and it makes sense

>> Besides that there is one more reference we are starting using: RFID
>> addresses, which allow to pinpoint the exact position of the device.

The only problem is that there are few different id schemes (e.g EPC,
96bits; iso 15693, 64 bits and other proprietary). Somewhere there urn
schemes allowing the mapping between the different standards, but a
solution like this should be general enough:
rfid
idscheme:id

(need to do some more research for confirming)

-- 
Fabio Forno, Ph.D.
Ooros srl
jabber id: f...@jabber.bluendo.com

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Peter Saint-Andre]

Fabio Forno wrote:
> On Mon, Mar 2, 2009 at 8:23 PM, Peter Saint-Andre  wrote:
>> I was chatting with Joe Hildebrand about XEP-0255 and he mentioned that
> 
> [...]
>> It seems that we'd need this because your ethernet address might be
>> different from your wifi address even in the same location (e.g., where
>> I am right now my ethernet address is 00:23:32:d4:28:ea whereas my wifi
>> address is 00:23:6c:88:d4:1d).
>>
> 
> 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.

> Besides that there is one more reference we are starting using: RFID
> addresses, which allow to pinpoint the exact position of the device.

Yes, that too would be useful.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Fabio Forno]

On Mon, Mar 2, 2009 at 8:23 PM, Peter Saint-Andre  wrote:
> I was chatting with Joe Hildebrand about XEP-0255 and he mentioned that

[...]
> It seems that we'd need this because your ethernet address might be
> different from your wifi address even in the same location (e.g., where
> I am right now my ethernet address is 00:23:32:d4:28:ea whereas my wifi
> address is 00:23:6c:88:d4:1d).
>

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?)

Besides that there is one more reference we are starting using: RFID
addresses, which allow to pinpoint the exact position of the device.

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com

Re: [Standards] XEP-0255 (Location Query): ethernet reference type?

[Andreas Monitzer]

On Mar 02, 2009, at 20:23, Peter Saint-Andre wrote:

I was chatting with Joe Hildebrand about XEP-0255 and he mentioned  
that
it would be good to add a reference type for an Ethernet address,  
such as:


It seems that we'd need this because your ethernet address might be
different from your wifi address even in the same location (e.g.,  
where
I am right now my ethernet address is 00:23:32:d4:28:ea whereas my  
wifi

address is 00:23:6c:88:d4:1d).


My MacPro has two Ethernet ports built-in, bringing the total number  
of MAC addresses to 3. Some servers might have even more.


andy

Re: [Standards] XEP-0255: Location Query

[Stephen Pendleton]

Whoops sorry, I misread your comment about pulling out the IP address so
disregard my previous comment on this. 

Yes, in a component you wouldn't have access to the users IP. 

However, in a more generic implementation you might not be requesting "my"
location information. You may want to use this XEP to query location info of
other reference points (maybe another users IP or the last few IP addresses
that were encountered?)

THanks

-Original Message-
From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On
Behalf Of Stephen Pendleton
Sent: 02/13/2009 12:29 PM
To: 'XMPP Standards'
Subject: Re: [Standards] XEP-0255: Location Query




-Original Message-
From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On
Behalf Of Helge Timenes
Sent: 02/13/2009 1:24 AM
To: XMPP Standards
Subject: [Standards] XEP-0255: Location Query


Just a heads up notice:

As suggested by Stephen Pendleton I plan to add ip-address to the type 
of "beacons" that can be submitted in a location query. The 
justification being that in most cases an IP address can be associated 
with a particular country, region and city. Some items of concern in 
this matter:

A server implementing this XEP directly might be able to pull out a 
connected user's IP address without this tag. I assume a component style 
implementation does not have this option, or there would be little use 
in re-stating it explicitly in the stanza.

This XEP is of particular interest for mobile applications. Does anyone 
know if the IP-to-location mapping holds true for mobile connections? 
Are handsets assigned an IP by the local carrier where you happen to be 
roaming, or by your home-network? Do mobile operators even use 
location-mappable IP addresses?

As  opposed to cell towers, wifi access points and bluetooth devices, an 
ip address can hardly be construed as a beacon in any sense of the word, 
i plan to change the nomenclature to simply "reference" from now on.

Any injections/suggestions/comments? If no suggestions to the contrary, 
i will add type "ip" and rename "beacon" to "reference".


IP address is worthless for mobile radio (data/gprs/etc) devices. However it
would be helpful for other IP devices (laptops, desktops, etc). Also, the
server already has the connected users IP address anyway, so maybe I am
missing something?

Thanks

Re: [Standards] XEP-0255: Location Query

[Stephen Pendleton]

-Original Message-
From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On
Behalf Of Helge Timenes
Sent: 02/13/2009 1:24 AM
To: XMPP Standards
Subject: [Standards] XEP-0255: Location Query


Just a heads up notice:

As suggested by Stephen Pendleton I plan to add ip-address to the type 
of "beacons" that can be submitted in a location query. The 
justification being that in most cases an IP address can be associated 
with a particular country, region and city. Some items of concern in 
this matter:

A server implementing this XEP directly might be able to pull out a 
connected user's IP address without this tag. I assume a component style 
implementation does not have this option, or there would be little use 
in re-stating it explicitly in the stanza.

This XEP is of particular interest for mobile applications. Does anyone 
know if the IP-to-location mapping holds true for mobile connections? 
Are handsets assigned an IP by the local carrier where you happen to be 
roaming, or by your home-network? Do mobile operators even use 
location-mappable IP addresses?

As  opposed to cell towers, wifi access points and bluetooth devices, an 
ip address can hardly be construed as a beacon in any sense of the word, 
i plan to change the nomenclature to simply "reference" from now on.

Any injections/suggestions/comments? If no suggestions to the contrary, 
i will add type "ip" and rename "beacon" to "reference".


IP address is worthless for mobile radio (data/gprs/etc) devices. However it
would be helpful for other IP devices (laptops, desktops, etc). Also, the
server already has the connected users IP address anyway, so maybe I am
missing something?

Thanks

Re: [Standards] XEP-0255: Location Query

[Dean Collins]

Hi Helge,

Having worked for www.Amethon.com last year I can tell you categorically
that mobile handset ip addresses have very little location based
information.

You need a cell tower mapping system which isn't readily accessible by
the applications etc.

Ignore this problem for a few years and it will sort itself out, in the
mean time I think your idea for mapping landline ip addresses etc is a
great one.


Cheers,
Dean



-Original Message-
From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On
Behalf Of Helge Timenes
Sent: Friday, February 13, 2009 1:24 AM
To: XMPP Standards
Subject: [Standards] XEP-0255: Location Query

Just a heads up notice:

As suggested by Stephen Pendleton I plan to add ip-address to the type 
of "beacons" that can be submitted in a location query. The 
justification being that in most cases an IP address can be associated 
with a particular country, region and city. Some items of concern in 
this matter:

A server implementing this XEP directly might be able to pull out a 
connected user's IP address without this tag. I assume a component style

implementation does not have this option, or there would be little use 
in re-stating it explicitly in the stanza.

This XEP is of particular interest for mobile applications. Does anyone 
know if the IP-to-location mapping holds true for mobile connections? 
Are handsets assigned an IP by the local carrier where you happen to be 
roaming, or by your home-network? Do mobile operators even use 
location-mappable IP addresses?

As  opposed to cell towers, wifi access points and bluetooth devices, an

ip address can hardly be construed as a beacon in any sense of the word,

i plan to change the nomenclature to simply "reference" from now on.

Any injections/suggestions/comments? If no suggestions to the contrary, 
i will add type "ip" and rename "beacon" to "reference".

As already mentioned i feel more and more that breaking up the generic 
notation and using dedicated tags for each beacon/reference would make 
sense, but as there has not been much opinions in either direction on 
this I'll leave it as mentioned above under the motto "if it ain't 
completely broken, don't fix it more than necessary..."


Helge

Re: [Standards] XEP-0255: Location Query

[Stephen Pendleton]

I think a better name for beacon would be "reference point", which is common
when talking about reference based location systems. IP is just another
reference point type.

-Original Message-
From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On
Behalf Of Helge Timenes
Sent: 02/04/2009 11:25 AM
To: XMPP Standards
Subject: Re: [Standards] XEP-0255: Location Query


I'm still thinking about this one. Granted ip address is useful in
determining location, and adding a new beacon type is a painless update. But
i feel it is a bit silly to call it a 'beacon'. Cell towers, wifi access
points and bluetooth devices are all radio transmitters, so in a very true
sense radio frequency beacons. IP address? Not so much...

Add a new beacon type, or de-generalize  into ,,
,  ? The latter seems more correct, but is of course a
backwards compatibility breaking change. Do any one have an opinion or
preference?

-original message-
Subject: Re: [Standards] XEP-0255: Location Query
From: "Stephen Pendleton" 
Date: 04/02/2009 16:49

Also, can you add "ip" as one of the beacon types in Table 2? That would
cover one of the use cases.

Thanks

-Original Message-
From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On
Behalf Of Helge Timenes
Sent: 02/03/2009 6:55 AM
To: XMPP Standards
Subject: Re: [Standards] XEP-0255: Location Query


Thanks. Will fix ;-)

Regards,
Helge Timenes

-original message-
Subject: [Standards] XEP-0255: Location Query
From: Daniel Willmann 
Date: 03/02/2009 11:24

Hi,

I just noticed an inconsistency between the query tags at
http://xmpp.org/extensions/xep-0255.html#examples and the format
specification at http://xmpp.org/extensions/xep-0255.html#format.

Example 1 uses tags named latitude and longitude, but the format specifies
them as lat and lon. Since XEP-80 also uses lat and lon I'm guessing that
the example is wrong, but still better not to confuse people. :-)

Regards,
Daniel Willmann

<>

Re: [Standards] XEP-0255: Location Query

[Helge Timenes]

I'm still thinking about this one. Granted ip address is useful in determining 
location, and adding a new beacon type is a painless update. But i feel it is a 
bit silly to call it a 'beacon'. Cell towers, wifi access points and bluetooth 
devices are all radio transmitters, so in a very true sense radio frequency 
beacons. IP address? Not so much...

Add a new beacon type, or de-generalize  into ,, 
,  ? The latter seems more correct, but is of course a backwards 
compatibility breaking change. Do any one have an opinion or preference?

-original message-
Subject: Re: [Standards] XEP-0255: Location Query
From: "Stephen Pendleton" 
Date: 04/02/2009 16:49

Also, can you add "ip" as one of the beacon types in Table 2? That would
cover one of the use cases.

Thanks

-Original Message-
From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On
Behalf Of Helge Timenes
Sent: 02/03/2009 6:55 AM
To: XMPP Standards
Subject: Re: [Standards] XEP-0255: Location Query


Thanks. Will fix ;-)

Regards,
Helge Timenes

-original message-
Subject: [Standards] XEP-0255: Location Query
From: Daniel Willmann 
Date: 03/02/2009 11:24

Hi,

I just noticed an inconsistency between the query tags at
http://xmpp.org/extensions/xep-0255.html#examples and the format
specification at http://xmpp.org/extensions/xep-0255.html#format.

Example 1 uses tags named latitude and longitude, but the format specifies
them as lat and lon. Since XEP-80 also uses lat and lon I'm guessing that
the example is wrong, but still better not to confuse people. :-)

Regards,
Daniel Willmann

<>

Re: [Standards] XEP-0255: Location Query

[Stephen Pendleton]

Also, can you add "ip" as one of the beacon types in Table 2? That would
cover one of the use cases.

Thanks

-Original Message-
From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On
Behalf Of Helge Timenes
Sent: 02/03/2009 6:55 AM
To: XMPP Standards
Subject: Re: [Standards] XEP-0255: Location Query


Thanks. Will fix ;-)

Regards,
Helge Timenes

-original message-
Subject: [Standards] XEP-0255: Location Query
From: Daniel Willmann 
Date: 03/02/2009 11:24

Hi,

I just noticed an inconsistency between the query tags at
http://xmpp.org/extensions/xep-0255.html#examples and the format
specification at http://xmpp.org/extensions/xep-0255.html#format.

Example 1 uses tags named latitude and longitude, but the format specifies
them as lat and lon. Since XEP-80 also uses lat and lon I'm guessing that
the example is wrong, but still better not to confuse people. :-)

Regards,
Daniel Willmann

<>

Re: [Standards] XEP-0255: Location Query

[Helge Timenes]

Thanks. Will fix ;-)

Regards,
Helge Timenes

-original message-
Subject: [Standards] XEP-0255: Location Query
From: Daniel Willmann 
Date: 03/02/2009 11:24

Hi,

I just noticed an inconsistency between the query tags at
http://xmpp.org/extensions/xep-0255.html#examples and the format
specification at http://xmpp.org/extensions/xep-0255.html#format.

Example 1 uses tags named latitude and longitude, but the format
specifies them as lat and lon. Since XEP-80 also uses lat and lon I'm
guessing that the example is wrong, but still better not to confuse
people. :-)

Regards,
Daniel Willmann

<>

Re: [Standards] XEP-0255 (Location Query)

[Stephen Pendleton]

I'm on board with that too. So IP would be:


  

  208.99.11.22
  ip

  


-Original Message-
From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On
Behalf Of Simon Tennant
Sent: 01/27/2009 9:20 AM
To: XMPP Standards
Subject: Re: [Standards] XEP-0255 (Location Query)


Helge Timenes wrote:
> That is a good idea. And also  brings up an already asked question. 
> Would it be better to de-generalize the  element into explicit 
> , , , and as suggested,  elements?
> 
> Pros/cons anyone?

We will soon have WiMAX and then LTE-type cell-ids and... So let's not paint
ourselves into a corner by presuming that all beacon types are accounted
for.

Please don't de-generalise.  "type=" works well for this.  IP is just
another type of beacon.

S.


-- 
Simon Tennant
Buddycloud
uk: +44 20 7043 6756   de: +49 89 420 955 854
uk: +44 78 5335 6047   de: +49 17 8545 0880
email and xmpp: si...@buddycloud.com

Re: [Standards] XEP-0255 (Location Query)

[Simon Tennant]

Helge Timenes wrote:
> That is a good idea. And also  brings up an already asked question. Would it 
> be better to de-generalize the  element into explicit , , 
> , and as suggested,  elements?
> 
> Pros/cons anyone?

We will soon have WiMAX and then LTE-type cell-ids and... So let's not
paint ourselves into a corner by presuming that all beacon types are
accounted for.

Please don't de-generalise.  "type=" works well for this.  IP is just
another type of beacon.

S.


-- 
Simon Tennant
Buddycloud
uk: +44 20 7043 6756   de: +49 89 420 955 854
uk: +44 78 5335 6047   de: +49 17 8545 0880
email and xmpp: si...@buddycloud.com

Re: [Standards] XEP-0255 (Location Query)

[Helge Timenes]

That is a good idea. And also  brings up an already asked question. Would it be 
better to de-generalize the  element into explicit , , 
, and as suggested,  elements?

Pros/cons anyone?

-original message-
Subject: Re: [Standards] XEP-0255 (Location Query)
From: "Stephen Pendleton" 
Date: 26/01/2009 23:12

What about adding another optional element to the query to allow the lookup
of location information based on IP address?:


  
127.88.22.22
  


Sometimes IP address is "good enough" for applications.

Thanks

Re: [Standards] XEP-0255 (Location Query)

[Stephen Pendleton]

What about adding another optional element to the query to allow the lookup
of location information based on IP address?:


  
127.88.22.22
  


Sometimes IP address is "good enough" for applications.

Thanks

Re: [Standards] XEP-0255 (Location Query)

[kael]

Helge Timenes wrote, On 12/12/2008 04:52 PM:

On Thu, 11 Dec 2008 16:15:30 -0500, Stephen Pendleton 
 wrote:

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


It is possible to allow delegated Pubsub publication by a third-party 
JID by using the 'pubsub#publisher' attribute value when creating a node :




  


  
   
 http://jabber.org/protocol/pubsub#node_config
   
   whitelist
   
geo.jabber.org
   
  

  



and/or (I don't remember exactly) by settings the affiliations for a node :


  

  

  




But apparently, delegated publication isn't allowed with PEP. At least, 
this is what I've been told by an Ejabberd developer who pointed 
XEP-0163  
which states in section 2.2 :


"There is no need for multiple publishers to a PEP service, since by 
definition the service generates information associated with only one 
entity. The owner-publisher for every node is the bare JID of the 
account owner."


However, Openfire allows delegated PEP publication.

Could some Pubsub/PEP experts clarify on this point, please ?

--
kael

Re: [Standards] XEP-0255 (Location Query)

[kael]

Helge Timenes wrote, On 11/26/2008 10:43 PM:

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?


This specification looks nice. I'd have some comments and suggestions.


1. The XEP uses an  
element for queries, but doesn't for replies.


Shouldn't the  element be part of replies ?


2. The XEP allows to decide if the query result should be published by
the location server on behalf of the user with a  element. But 
I'm not sure the  element is correctly located. It is not

very elegant and perhaps that :

- the location query could contain the geoloc namespace ;

- the  element value could be part of the Pubsub 
 with for example a (better named) 'pubsub#on_behalf' 
attribute value :



  

  1599-10-23T01:55:21Z
  57.0501862
  9.918874
  33.56


  

http://jabber.org/protocol/pubsub#publish-options


  true


  whitelist

  

  



3. The XEP allows to query the location server to resolve cellID, and 
WiFi, WiMax and Bluetooth SSIDs. It uses a  element which 
doesn't look very cohesive compared to the geolocation ones.


So perhaps it would be possible to extend XEP-0080 to include two or
three new namespaces for cellID, Bluetooth, WiFi, and WiMax SSID (I
don't know the terminology for Bluetooth and WiMax) or perhaps to add 
the following new namespaces to this XEP :



  

  1599-10-23T01:55:21Z
  57.0501862
  9.918874
  33.56


  238:02:34775:50880
  1



  00:19:CB:45:50:4A


  00:19:CB:45:50:4A


  00:19:CB:45:50:4A


  

http://jabber.org/protocol/pubsub#publish-options


  true


  whitelist

  

  



It looks more cohesive with new namespaces than with the 
element and perhaps slightly easier for parsing, although a bit more 
verbose.


But if XEP-0080 was extended, then will there be any PEP CellID with for 
example clients advertising  in 
their capabilities ?


I'd suggest also to add some references for the definitions of Cell 
Global Identity (CGI), SSID, etc, like the "3GPP TS 03.03 - Numbering, 
Addressing and Identification" specification 
 which defines CGI for 
2G mobile networks in Section 4.3.1.


And in example 7 of the XEP, the from attribute should be the JID of the 
location server, I think.


--
kael

Re: [Standards] XEP-0255 (Location Query)

[Helge Timenes]

On Thu, 11 Dec 2008 16:15:30 -0500, Stephen Pendleton 
 wrote:
> 
> Some comments I have on 0255 during implementation:
>  
>  
> - XEP-0080 uses , ,  instead of , ...
> 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  to the  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)



Helge

>> To: standards@xmpp.org> Date: Wed, 26 Nov 2008 22:43:45 +0100> From:
> he...@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
> 

Re: [Standards] XEP-0255 (Location Query)

[Stephen Pendleton]

Some comments I have on 0255 during implementation:
 
 
- XEP-0080 uses , ,  instead of , ... so 
the examples need to be changed. The schema looks right though. 
- 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.
> To: standards@xmpp.org> Date: Wed, 26 Nov 2008 22:43:45 +0100> From: 
> he...@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