[Geopriv] Review of XEP-0255

["Thomson, Martin" <[e-mail]>]

Review of: XEP-0255 <http://xmpp.org/extensions/xep-0255.html>
By: Martin Thomson
Date: 2009-04-02

I've been asked to review this document by Joe and Peter.  These are my initial impressions, relating this document with the work being undertaken by GEOPRIV.  It's also a little essay that might serve as an introduction to the philosophy behind the design of HELD and its related specifications.  I would encourage you to read the referenced GEOPRIV documents.

These are my views, but I've shared this with GEOPRIV, mainly to save me the effort of finding and listing all the interested GEOPRIV attendees.

~~

The first thing that struck me about this document is its similarity to HELD [1].  In terms of the mechanics described, the document is largely identical to HELD with measurements [2].

From that perspective, my initial objection is over the duplication of work.  I see no point in duplicating effort on specifications that are fundamentally identical.

I'm was tempted to suggest that defining an XMPP transport for HELD might be appropriate, but then there are deeper issues to examine.

(Before continuing, I'd like to isolate one aspect from the discussion: (reverse-)geocoding.  I'll get back to this point later, but for now assume that the ensuing discussion addresses the primary function: retrieving location information.)

The architecture assumed in IETF (GEOPRIV, ECRIT, ...) work [5] relies on one of two things: the device is able to determine where it is, or the immediate access network is able to tell the device where it is.  Physical presence is considered an important, if not necessary, part of location determination.

A device might be able to autonomously determine its location - no need to specify protocols there, aside from conveyance, presence publish, etc...  Plenty of devices have GPS units, and while there are things that a network can do to assist (c.f. assisted GNSS) this isn't the interesting problem.

More interesting, and the focus of HELD and several related work items is the scenario where a device is unable to determine its own location.  The architecture developed in GEOPRIV identifies a server in the access network that performs this function.  This server is the Location Information Server (LIS).  There is an established means of discovering a LIS [3], and a protocol (HELD) for acquiring location information from it.

The tie between LIS and access network is a key aspect of this architecture.  A LIS is assumed to be able to have sufficient knowledge about the network topology and its relationship to the physical world.  It can use this information, plus information provided by devices in the access network such as routers and switches, to identify the location of a device.

In some cases, the device provides information to the LIS that aids it in more accurately determining location.  After all, being at the location of interest, the device is in a unique position to assist.  There is a well-matured individual submission that documents how this might be done in a number of cases [2]; cases that have a remarkable similarity to those documented in XEP-0255.

~~

XEP-0255 does not articulate the deployment architecture where the authors envisage it being deployed.  I can't properly evaluate whether this is a practical specification without additional context.  This might reflect my lack of familiarity with other work amoungst the 250+ XEPs, but there seem to be a number of unstated assumptions.

If we scratch the surface, there are a number of other issues that arise.  I wont go into these in detail, but a few leap out.

 - A device is able to request based on an arbitrary identifier, in particular IP address.  What mechanisms are put in place to either (a) authenticate the requester as owning the identifier, or (b) authorize the requester as being able to request location information for a third party?  These are non-trivial issues that we deal with in [4].

 - As above, what measures are taken to protect against falsified measurement data?  This one is an even more complex issue.

 - Cell identifiers don't state which type of RAN they apply to, but I might assume that you only support GSM.  Identifiers in UMTS, LTE and CDMA cellular networks are different.

While I've said that on the whole this duplicates IETF effort, it's possible that some functions are novel.  These might be XMPP specific, but I wonder whether you don't need something more generic.  For instance, the on-behalf-of publish is not something that is possible within GEOPRIV since this assumes a number of trust relationships that cannot be assumed in the GEOPRIV architecture.  We are working on something similar in the IETF, but from a different angle [6], [7].  This wouldn't be location specific, even if location information was the initial motivation for the work.

~~

On geocoding, that's an entirely separable function.  A LIS, or LIS-like, function is in essence a very simple service.  Leaving aside for the moment the fact that the process of managing the data might be arbitrarily complex, a LIS only has to trace the path a packet might travel in getting to a given device; map that path onto a physical topology and extract location information.

In many cases, operating a LIS only requires that the network operator know where the cables in a building terminate.  Not to trivialise the difficulty of managing that, it's fundamentally different to what is involved in geocoding.

Geocoding and reverse-geocoding requires a different sort of information.  That information relates to the human-constructed environment and it's mapping onto the physical world.  Such a database might be constrained to specific locations, or it might be global.

I'd suggest that if you are looking to define an interface to a geocoding database, that is something that you want to do separately.  (1) You cannot assume that the service that knows where you are is able to translate to/from civic address forms, and (2) you cannot assume that a geocoding database is able to tell you where you are.

~~

I think that one of these unstated assumptions I referred to earlier is the existence of a magical service, perhaps one like that offered by Google.  To Google's credit, by publishing a simple API, they've done a remarkable job in masking the underlying complexity of the task of location determination.  By combining this API with geocoding, they are able to seamlessly provide a service that is both moderately accurate and quite accessible to web applications.  

However, the Google API hides a great many assumptions and flaws, such as the brittleness of their wireless AP database.  Services like this (we call these World in a DataBase, or WiDB, services) are always subject to a range of problems.  Primarily, they are entirely subject to their self-healing algorithms; changes in network topology always lead to a period of adjustment.

~~

I know that I haven't covered everything that is involved in this specification.  It's a remarkably complex specification.  I don't know if this is what is expected, but it seems lightly specified given the complexity of the tasks described.  

It's quite possible that interoperating implementations of this specification could be developed, but I think as a whole, the specification attempts too much in the one piece.  More importantly, there are a lot of unstated assumptions that I would like to see made clear.  

Of course, in all of this I could just be demonstrating my ignorance of the XMPP process - these assumptions might already be well understood as background.  Feel free to enlighten me.

--Martin


[1] <http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery>
[2] <http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements>
[3] <http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery>
[4] <http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensions>
[5] <http://tools.ietf.org/html/draft-ietf-geopriv-l7-lcp-ps>
[6] <http://tools.ietf.org/html/draft-garcia-simple-indirect-presence-publish>
[7] <http://tools.ietf.org/html/draft-thomson-simple-cont-presence-val-req>


------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]