Subject: [Geopriv] Review of XEP-0255

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 1 Apr 2009 22:40:41 -0500

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]

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 5 Apr 2009 19:36:40 -0500

Hi Helge,

I think that you have missed my central point about the architecture assumed by the protocol.  It's OK for you to decide to rely on an omniscient service*, but that's an assumption that needs to be made clear.

My point about geocoding being a separable and separate function also appears to have been lost.  Of course, it's natural to see the two functions (location determination and geocoding) in the one box after making the first set of assumptions.  However, from an aesthetics and protocol design perspective, I'd prefer to see the two initially separate with a bridging piece defined later.

Cheers,
Martin

* As I pointed out, this is an attractive concept, but that doesn't mean it's going to work.

> -----Original Message-----
> From: Helge Timenes [mailto:[email-masked]]
> Sent: Sunday, 5 April 2009 9:39 PM
> To: Thomson, Martin
> Cc: Peter Saint-Andre; Joe Hildebrand; [email-masked];
> [email-masked]; GEOPRIV
> Subject: Re: Review of XEP-0255
> 
> Thomson, Martin wrote:
> > 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].
> >
> This may very well be. Personally I was not aware of the HELD
> specification, but if it provides a solution to a similar problem, it
> makes sense that it looks similar.
> > 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.
> >
> Firstly I must admit that I have not yet read the HELD spec in detail,
> but based on the examples supplied, I see the following differences:
> 
> Transport: HTTP vs XMPP
> 
> Response: XEP-0255 was designed to supply results in the form dictated
> by XEP-0080 (http://xmpp.org/extensions/xep-0080.html). This
> specification predates XEP-0255 by several years, and is been widely
> used by XMPP clients. Predominantly this use has been to let users
> enter
> their location manually, and distribute as a XEP-0080 conform node on
> PubSub (http://xmpp.org/extensions/xep-0060.html) or PEP
> (http://xmpp.org/extensions/xep-0163.html). XEP-0255 was designed to
> enable an automated use of XEP-0080
> > I'm was tempted to suggest that defining an XMPP transport for HELD
> might be appropriate, but then there are deeper issues to examine.
> >
> 
> See my comments at the bottom
> > (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.
> >
> Publish is an aspect addressed in XEP-0255
> > 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.
> >
> 
> Again, this should come as no surprise. Convergent evolution
> (http://en.wikipedia.org/wiki/Convergent_evolution) happens in nature
> all the time. Why should it not in engineering? ;-) The surprising
> thing
> is rather that I and my co-authors were not aware of the HELD
> specification. Poor research that can only be explained by lack of time
> (I'm doing this in my spare time)
> > ~~
> >
> > 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.
> >
> XEP-0255 does currently not include any service discovery
> (http://xmpp.org/extensions/xep-0030.html) aspects, which would give
> clients the opportunity to query servers for their location
> capabilities. This should be added in later revisions.
> 
> For an example of an existing deployment, I can recommend
> http://buddycloud.com, which is the project from which XEP-0255 was
> spawned.
> > 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.
> >
> You are right that XEP-0255 does not address this. As it stands now it
> describes the form of the protocol, with only a few "best practises"
> notes on how it should be implemented. In the end, implementers have
> the
> say in how they want to deal with privacy. That's not to say that the
> specification should not address it. See my comments at the bottom for
> more.
> >  - 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.
> >
> Right, derivation of reference ID from other network types needs to be
> stated. Added to TODO list
> > 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.
> >
> >
> How a XEP-0255 compliant server does it's (reverse) geocoding is left
> up
> to the server implementers.
> > ~~
> >
> > 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.
> >
> How the server is processing the location query is left to implementers
> to decide. If it decide on leveraging third party services (e.g.
> google,
> yahoo geonames.org, open street map or others) than that's ok form a
> protocol specification point of view. For a client perspective it
> happens automagically ;-)
> > ~~
> >
> > 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.
> >
> As mentioned, the spec was born out of an project in development
> (buddycloud.com) and is certainly lightweight in some areas. The
> focuses
> has so far been on form, rather than policies.
> > 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.
> >
> 
> To come back to your earlier comment on this being largely redundant
> with HELD. It does indeed seem so, and maybe the way ahead could be to
> keep XEP-0255 as a XMPP specific alternative to HELD. And as you
> clearly
> have given some aspects (privacy, authentication etc) much more thought
> than we have, it would perhaps be practical to refer to HELD for
> details
> on these.
> 
> I would also like to take this opportunity to invite you to help out
> with future work on XEP-0255.
> 
> 
> Best regards,
> 
> Helge Timenes
>