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

[Helge Timenes]

Missed this one due to a mis-behaving spamfilter...

Will add to spec and update the next few days.


- helge -


On Mar 21, 2009, at 2:39 AM, Helge Timenes wrote:

/ I agree that "mac" is more general-purpose.

/>/ Well "mac" is maybe also too general?
/
Agree.  Either "nic" or "ethernet" are fine with me.

/ Would "nic" be appropriate? In any case a bit of prose would be  

/>/ needed to explain its usage
/
That's fine.  How about:

The "nic" type is an indication to the location server of the link  
layer (Media Access Control) address of one of the Network Interface  
Controllers (NICs) associated with the client sending the request.   
Most commonly, this will take the form of a 48-bit ethernet address  
formatted in six colon-separated groups of two hexadecimal digits, in  
transmission order.   Some location servers may be able to use this  
information to query network elements through which the client is  
connected in order to deduce location data.


--
Joe Hildebrand

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

[Helge Timenes]

Joe Hildebrand wrote:


On Mar 20, 2009, at 12:25 AM, Helge Timenes wrote:

BTW, did we not add the "ethernet" type yet?
I added the IP type, but not yet ethernet. Would that indeed be the 
right type name? As I understood Joe  it would be the MAC address of 
a Network Interface Card (NIC), so maybe "ethernet" would be a bit 
vague?


I agree that "mac" is more general-purpose.  
Well "mac" is maybe also too general? The most important job of the 
"type" attribute is to give the server an indication of the localization 
characteristics of a reference. Wifi access points and bluetooth devices 
are also identified by their mac address, but have completely different 
location characteristics (range, typical degree of mobility etc) from 
both each other and a network interface card.


Would "nic" be appropriate? In any case a bit of prose would be needed 
to explain its usage
Do we then have to worry about EUI-64 addresses as well?  Would we 
expect this to include your Bluetooth or ZigBee address as well?


Bluetooth is already a specified reference type. Without knowing ZigBee 
particularly well I'd assume that there are enough differences from 
other wireless protocols that a location server would be interested in 
knowing it, and treat such a reference "accordingly" when processing a 
location query.


The important thing is that references that should be treated specially 
by the location server needs a dedicated "type".



Helge

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

[Helge Timenes]

Firstly, I appologise for sluggish response. I ran into another 
space-time continuum singularity...


Secondly, see inline.


Peter Saint-Andre wrote:

On 3/14/09 4:28 AM, Helge Timenes wrote:
  

Peter Saint-Andre wrote:


On 3/13/09 8:49 PM, XMPP Extensions Editor wrote:

  
  

URL: http://www.xmpp.org/extensions/xep-0255.html



I notice that the suggested / allowable values of the 'type' attribute
are "cell", "wifi", "bluetooth", "wimax", "rfid", "ip", "other". I see
three ways to handle these:

1. Restrictive: lock down these values in the schema

2. Permissive: allow applications to include any value they choose

3. Extensible: set up a registry so that we don't need to update the
spec every time we add a new value while still providing guidance to
implementors

I lean toward #3.
  
  

That seems sensible, though i suspect the reference types will change
frequently while the XEP is young, but at some point settle down as the
spec catches up with all the possibilities out there (sure new ones will
be invented, but not at a pace that is hard to keep up with I'd guess)



If we have a registry, we don't need to update the spec all the time.
Perhaps it's not a big deal.

  

How would such a registry work? Are there examples of such from other XEPs?



I've defined all the registries so far since I'm the XMPP Registrar. :)
It's easy enough for me to add this to the spec.

  

Register at will :-)

BTW, did we not add the "ethernet" type yet?

  
I added the IP type, but not yet ethernet. Would that indeed be the 
right type name? As I understood Joe  it would be the MAC address of a 
Network Interface Card (NIC), so maybe "ethernet" would be a bit vague?


Helge

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

[Helge Timenes]

Peter Saint-Andre wrote:

On 3/13/09 8:49 PM, XMPP Extensions Editor wrote:

  

URL: http://www.xmpp.org/extensions/xep-0255.html



I notice that the suggested / allowable values of the 'type' attribute
are "cell", "wifi", "bluetooth", "wimax", "rfid", "ip", "other". I see
three ways to handle these:

1. Restrictive: lock down these values in the schema

2. Permissive: allow applications to include any value they choose

3. Extensible: set up a registry so that we don't need to update the
spec every time we add a new value while still providing guidance to
implementors

I lean toward #3.
  
That seems sensible, though i suspect the reference types will change 
frequently while the XEP is young, but at some point settle down as the 
spec catches up with all the possibilities out there (sure new ones will 
be invented, but not at a pace that is hard to keep up with I'd guess)


How would such a registry work? Are there examples of such from other XEPs?

Peter

  

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?

[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

[Standards] XEP-0255: Location Query

[Helge Timenes]

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

[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

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

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

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

[Standards] XEP-0255 (Location Query)

[Helge Timenes]

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

Re: [Standards] [mobile] [Fwd: Proposed XMPP Extension: Location Query]

[Helge Timenes]

Peter Saint-Andre wrote:
>Simon Tennant wrote:
>> Stephen Pendleton wrote:
>>> Very cool.
>>> Question for the authors: Are you really using arc-minutes as units of the
>>> GPS error or is that carryover from the GEOLOC XEP?
>>
>> Props should go to Helge for the spec. I guess that writing
>> specifications for unmanned aerial vehicles is finally paying off.
>>
>> I presume you are referring to this post:
>> http://mail.jabber.org/pipermail/standards/2008-October/019920.html
>>
>> Arc-minutes are a carry over.  We wrote the spec with XEP-0080 in mind
>> and use that as the format for publishing the derived location to the
>> user's geoloc node too.
>>
>> We would prefer to use accuracy in meters. While arc minutes may make
>> sense in a GPS sense, accuracy often has to be implied when using other
>> location means.
>>
>> For example, if the server is receiving Cell-ID beacons and some of the
>> known beacons are identified as within a city an accuracy of 100m could
>> be implied due to a known higher tower density. Trying to apply
>> arc-minutes to this would probably end up just being clumsy and it would
>> be nice to use the same unit of measurement for accuracy.
>
>So use the new  element, which measures in meters:
>
>http://xmpp.org/extensions/xep-0080.html#format

Sorry for the slow response to this, got bogged down with some home improvement 
work (no worries, still have all my fingers :-)

I will update to use the  element, and the world will be a better 
place. 


Helge