[Standards] LAST CALL: XEP-0255 (Location Query)

Bernard Aboba bernard.aboba at gmail.com
Fri May 14 04:15:13 UTC 2010


Having gone through the (somewhat painful) process of editing RFC 3825bis
(see http://tools.ietf.org/html/draft-ietf-geopriv-rfc3825bis) and having to
carefully delineate between the meaning of the terms "uncertainty" and
"resolution", I would recommend that the authors think very carefully about
the meaning of the term "accuracy" in this document.

The other thing that strikes me about this document is that doesn't talk
much about distinguishing between third party queries and a host querying
for its own location.  This distinction has a  number of privacy
implications and has led to quite a bit of angst within the GEOPRIV WG, as
reflected in documents such as the HELD identity extensions document (see
http://tools.ietf.org/htmldraft-ietf-geopriv-held-identity-extensions ).

I'd also recommend the authors of the HELD extensions document as excellent
sources of information about the ins and outs of location configuration,
privacy issues, etc.  Though after talking to them, you'll know doubt learn
things that you might wish you had learned earlier.



On Tue, May 4, 2010 at 8:16 AM, Dave Cridland <dave at cridland.net> wrote:

> On Tue May  4 15:18:23 2010, XMPP Extensions Editor wrote:
>
>> 1. Is this specification needed to fill gaps in the XMPP protocol stack or
>> to clarify an existing protocol?
>>
>
> My impression is that it fills gaps, and provides a XMPP-based network
> service which provides a valuable task, in support of clients wishing to
> perform XEP-0080 for example.
>
> In particular, I suspect this represents a key component in making XEP-0080
> usable for the majority of systems.
>
>
>
>  2. Does the specification solve the problem stated in the introduction and
>> requirements?
>>
>
> Partially - in particular, it's not entirely clear what the latter portion
> of the second paragraph of §1 actually means in practise. It does imply a
> substantial data retention and analysis capability on the location server,
> which in turn has ramifications for security/privacy.
>
>
>
>  3. Do you plan to implement this specification in your code? If not, why
>> not?
>>
>
> I have often been tempted to implement it in a number of cases, but haven't
> yet - it certainly strikes me that it would make a valuable addition on a
> number of clients, assuming the existence of a suitable server.
>
>
>
>  4. Do you have any security concerns related to this specification?
>>
>
> The existing §8 covers the most obvious cases of privacy. It might need to
> be expanded somewhat to highlight that this should cover data in flight in
> both directions, as well as any data retained by the location service.
>
> It's not clear to me how the "publish" option might work in practise,
> however, so this may result in further security considerations.
>
>
>
>  5. Is the specification accurate and clearly written?
>>
>>
>>  The "publish" option appears somewhat underspecified.
>
> It implies that the location server has proxy-authorization capability,
> which is alarming - I see no direct need for this, but instead one assumes
> that the location server could be granted a Publisher affiliation on the PEP
> node, and hence be capable of simple publication.
>
> It's not clear to me if this should be a distinct, optional, feature or not
> - which brings me onto a second point.
>
> There is no XEP-0030 category or type specified for a location service,
> which means that a client wishing to discover a location server recommended
> by the server operator is  somewhat out of luck. I'd have thought that this
> would be generally useful, even if current implementations can have this
> server hardcoded.
>
>
> Dave.
> --
> Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net<xmpp%3Adwd at dave.cridland.net>
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100513/57814660/attachment.html>


More information about the Standards mailing list