Subject: [Geopriv] [Fwd: Re: Review of XEP-0255]

From: Richard Barnes <[email-masked]>
Date: Tue, 07 Apr 2009 18:55:21 +0200

Forwarding this to the list because I'm locked out of the moderation 
system at the moment.
--Richard

-------- Original Message --------
Subject: Re: Review of XEP-0255
Date: Mon, 06 Apr 2009 23:45:50 +0200
From: Simon Tennant <[email-masked]>
Organization: Buddycloud
To: Joe Hildebrand <[email-masked]>,  "Thomson, Martin" 
<[email-masked]>, Peter Saint-Andre <[email-masked]>, 
Helge Timenes <[email-masked]>, [email-masked], Ross Savage 
<[email-masked]>,  Jonathan Schleifer <[email-masked]>
CC: [email-masked]
References: <[email-masked]>

Martin,

I made it to the end of your analysis in one piece and have some
feedback that will hopefully help you to see how the standard is
positioned in the XMPP world and the similarities and differences with
HELD.

It looks like you spent a lot of time looking at the spec and, judging
by your comments, you have spent considerable time thinking about
positioning systems.

We have been working on the background to this XEP for the last 3 years
and have gone through a number of iterations of how best to get
reasonable remote positioning working in a real-world implementation.

Where we are coming from:

XEP-0255 tries to work within the existing XMPP framework. The XMPP
framework of specifications gives the implementer some nice advantage of
letting us leverage predefined sub-systems like a "Target" (roster
user), "Rule Holder" and "Rule Maker" publish/subscribe(XEP-0060).  XMPP
also includes a server and service discovery protocol which looks like
it corresponds to your "Location Configuration Server" role.

Privacy is also inherent in XMPP and enhanced by the affiliation
permissions on the publish-subscribe system in XMPP. Peter and Jo have
done a good job of crafting these to be open enough to work well and
while not too open to be useless for specific use cases. When we looked
at the existing suite of specifications it was not necessary to design
more than a way to report beacons into a location server and handle the
results. Publishing, permissioning and privacy is already taken care of
by other specs.

XEP-0255 model is very much client-server with the client being as dumb
as possible and the server having a good understanding of known beacons
and implying other data. The server then builds up a picture over time
about where the client is and does some cross checking. For example,
one can imply that two devices are nearby enough if they see each
other's bluetooth MACs and then leverage the better positioning
mechanism on the one terminal for the benefit of the terminal that
perhaps only has Cell-id positioning. Again this requires no client-side
processing other than reporting beacons. Indeed many implementations may
not even bother with bluetooth.

The XEP-0255 specification is the result of getting something working
really well while still leaving open the possibility that there may be
new beacon types in the future.  We don't know what they will be.
Nobody knows what will come after LTE or if there will be a new type of
Wifi router, but the current spec is flexible enough to handle these new
beacons identifiers once they get invented. I'd be curious to know how
you plan on handling these in HELD?

To give you some context: This as the first step. Simply reporting
beacons is somewhat easy and needs minimal clarification. Implementers
are expected to be familiar with XMPP and have an understanding of the
suite of XEPs that work as building blocks for a complete solution.

The second step is building on this spec with a way to manage location.
  Assigning meaningful names to locations for example seeing three
particular MAC addresses means that I am at "Home" (defining place based
on location).  We have a good working implementation and are now working
on a standardised spec that others can leverage.  But I believe XEP-0255
should stand on it's own so we can ignore this for now. Following on,
and building on the strength of XMPP's server to server infrastructure,
we want to standardise how you share location across domains.

For the rest of this response, I have gone through and commented on
particular points that stood out in your email.

> (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.)

This spec doesn't cover the implementation of reverse geocoding.  It's
simply a way to report beacons.  Everyone has their own methods on how
to implement this server side. Even best practices will vary depending
on the service being offered and the type of industry.

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

We make no assumptions about where it's deployed. Neither do I think one
should. It's a way to stream positioning beacons and get a response back
which can additionally be published elsewhere using existing XMPP
mechanisms.

We are currently seeing it deployed by developers on mobile platforms
including iPhone and Android.  We have also have an example where it's
location reporting functions are being built into an existing desktop
XMPP client. This is happening without clarification although the
developers are familiar with XMPP.

> - 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].

Authorising third parties to access or update your location results is
best done with existing pieces of the XMPP stack like pub-sub which
contains a mechanism to permit processes to update your location on your
behalf and includes a privacy model.  I believe, although have not
worked with it yet, there is an O-Auth implementation also which you can
delegate permissions to.

Authentication happens at the XMPP session layer. Peter and co. have
done a good job with the design of XMPP and we leverage this with how
location is shared. So authorisation of access to a user's location is
not addressed and and also not relevant to this spec. That's already
defined in the pub-sub XEP and in the PEP XEP.

I am not sure what you mean about needing to *own* an identifier to see
it and position off it. (I had a look through the HELD docs and could
not find anything that clarifies this ownership of a beacon.) Could you
clarify?

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

Unless one controls the measurement beacons and you have measurement
beacons that sign their data, this is not possible.  Short of running
our own GPS network and a PKI to sign GPS signals, this is not a
reality. So building a field based system that tries to thwart beacon
data hacking without controlling the entire chain is bound to fail.
That's why we don't address it XEP-0255.

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

We cannot predict all future cell identifier types. We have currently
tested with GSM and UMTS types. We can however know that CellID based
positioning is going to behave in a certain way and therefore include it
in a generic CellID tag. WiFi behaves in another.

The numbering of these beacons varies between technology types. I
believe the spec is  open enough to handle new beacon types. I am
curious to know how you plan on implementing future compatibility?

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

Neither does it try to.  How a location server chooses to fill out
XEP-0080 based data is left up to implementations.  Good ones will
include what you call "civic data".  Less impressive implementations
will just publish a lat/long. How they establish this lat/long is also
left up to implementers.  I am all for letting implementers determine
their own location quality levels and letting the market decide on
what's best.

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

Could you explain this? In your opinion what should the spec *not* be doing?

In summary, I think there is some overlap between beacon types, however
thing like privacy and authorisation are already very nicely handled
within the XMPP suite of XEPs and so not worth re-speccing.

I think it's worth us looking at how we can perhaps use the same
namespace for beacon types.

I am also against overlapping specifications so looked long and hard at
what you are doing. But, IMHO, we are working in different architectures
and adopting the entire HELD spec for XMPP would lead to massive and
confusing overlaps with the existing XMPP assumptions and specs
(XEP-0080, XEP-0060 immediately spring to mind).

So, as a next step, do you have a link to a definitive list of beacon
types and their XML schema?  We'll take a look here and see how much
overlap there is and see if we can make things nice for developers by
using the same naming.

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: [email-masked]
http://buddycloud.com