Re: [Standards] LAST CALL: XEP-0255 (Location Query)
On 05/04/2010 04:18 PM, XMPP Extensions Editor wrote: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Having a standard way to query geolocation servers is relevant and useful, and this XEP appears to be to XMPP what this draft <http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery> is to HTTP. 2. Does the specification solve the problem stated in the introduction and requirements? Seems so. 3. Do you plan to implement this specification in your code? If not, why not? I've started to write a component for this XEP and have some comments (some redundant with Dave's) : - I'd suggest adding additional capability namespaces so that a client can determine the type of geolocation resolver a service provides, with for example services announcing : 'urn:xmpp:locationquery:0#bluetooth' 'urn:xmpp:locationquery:0#cell' 'urn:xmpp:locationquery:0#wifi' etc. And a namespace for reverse geocoding (when a client requests an address based on geocoordinates) with for example 'urn:xmpp:locationquery:0#geo' Also, having a category or type for service discovery could be useful ; - I for one don't like the fact that the query namespace is not the same than the response one. This breaks namespace parallelism but it's not that much important ; - The element is more or less lost in the geo data. It also doesn't take into account the possibility of publishing geolocation to certain roster groups only. So I'd suggest moving the element (but where ?), or at least using a element so that clients can specify roster groups for example. And the element would be replaced with a new field attribute like 'pubsub#on_behalf'. 4. Do you have any security concerns related to this specification? There's one regarding geolocation data privacy but it seems to be out of the scope of the XEP. However, there be could a simple mention of privacy best practices for such data. 5. Is the specification accurate and clearly written? Perhaps it could be enhanced regarding PEP geolocation delegated publication which requires to manage the node affiliations. -- kael
Re: [Standards] Could anyone using XMPP-0277 or PEP help us test our Onesocialweb implementation ?
On 03/29/2010 11:10 AM, Laurent Eschenauer wrote: Hi everyone, Hello, Sorry to be late on the reply. Just wanted to tell you guys that we changed the notification engine of Onesocialweb from our crappy custom stuff to.. XEP-0277 ! We made quite a few custom changes to support activitystreams, per item privacy etc.. but still remain compatible with the overall PEP/XEP-0277 protocols. I'll ping an email later with suggestions on evolving PEP and XEP-0277 based on our work. I think the XEP-0277 is not complete and may be buggy. Consider the situation with users A, B and C. A and B are subscribed to each others node, as well as B and C, but not A and C. A publishes a message. B replies to A by publishing a message which is also received by C. C wants to reply to A and publishes a message, but A won't receive it because A is not subscribed to C. So it looks like something's missing, perhaps a Cc-like mechanism. Also, the use of the element can create privacy issues since it theoretically contains the JID of the previous poster which is sent to the replier's contacts. I think this case should be addressed, specially in the light of the Google Buzz privacy issues. Similarly, I'm wondering if there shouldn't be a public and a private roster, but it makes things much more complicated. In the meanwhile, I need help on the following: 1) Is there any pubsub client out there ??? I wanted to check our implementation against a generic client supporting PEP (and ideally support rendering of Atom content and even XSLT) but did not find any ! There's OneChannel <http://xmpp-sandbox.org/onechannel> which supports ATOM payloads but it doesn't support Pubsub-On-JID. Synapse <http://synapse.im> has support for XEP-0277. Regarding XSLT, are you referring to the 'pubsub#body_xslt' option ? 3) Can anyone try to 'follow' me and give me feedback ? (xmpp:esch...@vodafonernd.com?;node=urn%3Axmpp%3Amicroblog%3A0) I have subscribed to your node and retrieved the items. Some contain two elements, and I think it's not correct. Also, the Pubsub items contain the ACL elements. I'm to write an OSW component for ejabberd and have looked at the updated specs, but they seem to miss some informations on ACL. Is there any schema for ACL ? Cheers. -- kael ProcessOne - <http://process-one.net>
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 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 <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)
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 <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
