Re: [Standards] XEP-0255 (Location Query): ethernet reference type?
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?
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: iq from='ham...@shakespeare.lit/phone' id='q02' to='location.shakespear.lit' type='get' xml:lang='en-US' locationquery xmlns='urn:xmpp:locationquery:0' reference id00.31.55.f9.1d.de/id typeethernet/type /reference /locationquery iq 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?
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?
Fabio Forno wrote: On Mon, Mar 2, 2009 at 11:15 PM, Peter Saint-Andre stpe...@stpeter.im 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: typerfid/type ididscheme:id/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 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
Re: [Standards] XEP-0255 (Location Query): ethernet reference type?
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: iq from='location.shakespeare.lit' 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) 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.
[Standards] XEP-0255 (Location Query): ethernet reference type?
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: iq from='ham...@shakespeare.lit/phone' id='q02' to='location.shakespear.lit' type='get' xml:lang='en-US' locationquery xmlns='urn:xmpp:locationquery:0' reference id00.31.55.f9.1d.de/id typeethernet/type /reference /locationquery iq 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). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0255 (Location Query): ethernet reference type?
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): ethernet reference type?
On Mon, Mar 2, 2009 at 8:23 PM, Peter Saint-Andre stpe...@stpeter.im 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?
On Mon, Mar 2, 2009 at 11:15 PM, Peter Saint-Andre stpe...@stpeter.im 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: typerfid/type ididscheme:id/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
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
-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
[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
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 dan...@totalueberwachung.de 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 signature.asc
Re: [Standards] XEP-0255: Location Query
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 beacon into cell,wifi, bluetooth, ip ? 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 pendl...@movsoftware.com 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 dan...@totalueberwachung.de 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 signature.asc
Re: [Standards] XEP-0255: Location Query
Thanks. Will fix ;-) Regards, Helge Timenes -original message- Subject: [Standards] XEP-0255: Location Query From: Daniel Willmann dan...@totalueberwachung.de 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 signature.asc
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 beacon element into explicit cell, wifi, bluetooth, and as suggested, ip 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)
I'm on board with that too. So IP would be: iq from='ham...@shakespeare.lit/phone' id='q02' to='location.shakespear.lit' type='get' xml:lang='en-US' locationquery xmlns='urn:xmpp:locationquery:0' beacon id208.99.11.22/id typeip/type /beacon /locationquery iq -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 beacon element into explicit cell, wifi, bluetooth, and as suggested, ip 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)
What about adding another optional element to the query to allow the lookup of location information based on IP address?: iq from='ham...@shakespeare.lit/phone' id='q02' to='location.shakespear.lit' type='get' xml:lang='en-US' locationquery xmlns='urn:xmpp:locationquery:0' ip127.88.22.22/ip /locationquery iq Sometimes IP address is good enough for applications. Thanks
Re: [Standards] XEP-0255 (Location Query)
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 locationquery xmlns='urn:xmpp:locationquery:0' element for queries, but doesn't for replies. Shouldn't the locationquery/ 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 publish/ element. But I'm not sure the publish/ element is correctly located. It is not very elegant and perhaps that : - the location query could contain the geoloc namespace ; - the publish/ element value could be part of the Pubsub publish-options/ with for example a (better named) 'pubsub#on_behalf' attribute value : iq from='ham...@shakespeare.lit/phone' locationquery xmlns='urn:xmpp:locationquery:0' geoloc xmlns='http://jabber.org/protocol/geoloc' timestamp1599-10-23T01:55:21Z/timestamp latitude57.0501862/latitude longitude9.918874/longitude accuracy33.56/accuracy /geoloc publish-options x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' type='hidden' valuehttp://jabber.org/protocol/pubsub#publish-options/value /field field var='pubsub#on_behalf' valuetrue/value /field field var='pubsub#access_model' valuewhitelist/value /field /x /publish-options /locationquery iq 3. The XEP allows to query the location server to resolve cellID, and WiFi, WiMax and Bluetooth SSIDs. It uses a beacon/ 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 : iq from='ham...@shakespeare.lit/phone' locationquery xmlns='urn:xmpp:locationquery:0' geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en' timestamp1599-10-23T01:55:21Z/timestamp latitude57.0501862/latitude longitude9.918874/longitude accuracy33.56/accuracy /geoloc cell xmlns='urn:3gpp:cell' cgi238:02:34775:50880/cgi signalstrength1/signalstrength /cell !-- or xmlns='http://jabber.org/protocol/cell', etc. -- wifi xmlns='urn:ieee:802.11' ssid00:19:CB:45:50:4A/ssid /wifi bluetooth xmlns='urn:ieee:802.15' ssid00:19:CB:45:50:4A/ssid /bluetooth wimax xmlns='urn:ieee:802.16' ssid00:19:CB:45:50:4A/ssid /wimax publish-options x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' type='hidden' valuehttp://jabber.org/protocol/pubsub#publish-options/value /field field var='pubsub#on_behalf' valuetrue/value /field field var='pubsub#access_model' valuewhitelist/value /field /x /publish-options /locationquery iq It looks more cohesive with new namespaces than with the beacon/ 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 http://jabber.org/protocol/cell+notify 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 http://www.3gpp.org/ftp/Specs/html-info/0303.htm 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 wrote, On 12/12/2008 04:52 PM: On Thu, 11 Dec 2008 16:15:30 -0500, Stephen Pendleton stephenpendle...@hotmail.com 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 : iq type='set'to='pubsub.shakespeare.lit' pubsub xmlns='http://jabber.org/protocol/pubsub' create node='princely_musings'/ configure x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' type='hidden' valuehttp://jabber.org/protocol/pubsub#node_config/value /field field var='pubsub#access_model'valuewhitelist/value/field field var='pubsub#publisher' type='jid-multi' label='The JIDs of those with an affiliation of publisher' valuegeo.jabber.org/value /field /x /configure /pubsub /iq and/or (I don't remember exactly) by settings the affiliations for a node : iq type='set'to='pubsub.shakespeare.lit' pubsub xmlns='http://jabber.org/protocol/pubsub#owner' affiliations node='princely_musings' affiliation jid='geo.jabber.org' affiliation='publisher'/ /affiliations /pubsub /iq 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 http://xmpp.org/extensions/xep-0163.html#approach-publisher 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)
On Thu, 11 Dec 2008 16:15:30 -0500, Stephen Pendleton stephenpendle...@hotmail.com wrote: Some comments I have on 0255 during implementation: - XEP-0080 uses lat, lon, alt instead of latitude, longitude... 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 signalstrength to the beacon 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)
Some comments I have on 0255 during implementation: - XEP-0080 uses lat, lon, alt instead of latitude, longitude... 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
