Re: I-D ACTION:draft-morris-geopriv-core-00.txt

FYI:

In terms of "location objects" I would refer the list to:

1. The OpenGIS Consortium abstract models for geometry and features. These
are public documents. I would also look to GML 2.1.2 (XML encoding for OGC
geometry, features, and properties) which is becoming the standard for
interoperable transport of location/geographic data in the GIS industry. GML
is a public document. (www.opengis.org and then go to specifications).
2. The Location Interoperability Forum (now OMA) and their Mobile Location
API, which is an encoding/interface API for the location services industry.
The MLP also uses the OGC geometry and coordinate reference system models.

Finally, the LIF has a white paper on privacy and the use of location in the
mobile wireless industry. It might be worth reading.

Carl Reed, PhD
Executive Director, OGC Specification Program

----- Original Message -----
From: John Morris <jmorris@cdt.org>
To: <geopriv@mail.apps.ietf.org>
Sent: Thursday, October 31, 2002 9:59 AM
Subject: Re: I-D ACTION:draft-morris-geopriv-core-00.txt

> I wanted to ask for feedback and discussion on the referenced I-D
> (which is, as these things go, fairly short). In my personal view,
> the I-D frames one of the most important questions that we need to
> resolve either before or in Atlanta. I think it would be very
> helpful if we could start a conversation about the questions before
> we get to Atlanta.
>
> The real question is whether the Location Object will be able to
> contain some limited set of privacy rules. I've cut and pasted the
> "overview" section from the I-D into the end of this e-mail, just to
> give you a quick look at possible approaches to the issues.
> Obviously, the full draft goes into more detail.
>
> Any comments and questions would be welcome.
>
> John
>
> At 4:21 PM -0500 10/30/02, Internet-Drafts@ietf.org wrote:
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >
> >
> > Title : Core Privacy Protections for Geopriv Location Object
> > Author(s) : J. Morris et al.
> > Filename : draft-morris-geopriv-core-00.txt
> > Pages : 10
> > Date : 2002-10-30
> >
> >In designing the requirements for the Geopriv Location Object (LO), a
> >key question for the working group is whether to include privacy-
> >protecting rules inside the LO itself, and if so, how many and what
> >rules should be contained in the LO. The Internet-Draft first
> >suggests that the LO should contain at least a limited set of privacy
> >rule fields, and second proposes a set of rules for inclusion in the
> >Location Object.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-morris-geopriv-core-00.txt
> >
> <snip>
>
> Excerpt from the I-D:
>
> 1. Overview and Introduction
>
> A critical issue facing the Geopriv working group is whether the
> Location Object (LO) to be designed should include fields for
> particular privacy-protecting rules, or instead should simply refer
> to an external set of privacy rules.
>
> There are at least four plausible answers to this question, labeled
> somewhat arbitrarily as follows:
>
> * "Entirely External" -- the LO should only contain a URI reference
> to an external set of privacy rules that must be followed by any
> recipient of the LO
>
> * "Bare Bones Internal" -- the LO should contain one rule that
> specifies that the Location Information (LI) shall not be retained
> longer past xyz date (or longer than xyz duration), along with a URI
> reference to an external set of privacy rules that must be followed
> by any recipient of the LO
>
> * "Limited Internal" -- the LO should contain a very limited set of
> rules that cover the great bulk of likely privacy rules (as well as
> the ability to include a URI reference to an external set of privacy
> rules if more robust rules are needed)
>
> * "Full Internal" -- the LO should be defined to be able to contain a
> full, robust, and potentially complex set of privacy rules
>
> To our knowledge no one in the working group has advocated for the
> "Full Internal" option. That option would be the most complex to
> define, the most complex to implement, and would not be consistent
> with the goal of enabling the use of the Geopriv LO on constrained
> devices or with constrained bandwidth.
>
> Some WG participants have expressed their view that the "Entirely
> External" approach would be the quickest for the working group to
> accomplish, and that if fully implemented in the marketplace the
> approach could give end users a great deal of control and flexibility
> in the protection of Location Information.
>
> Other WG participants (including at least some of the authors here)
> have argued that most effective way to ensure that users have some
> privacy control is for the LO to be defined to carry a limited number
> of privacy rules.
>
> It is not the purpose of this Internet-Draft to attempt to reach a
> definitive answer to this critical question. Instead, this I-D
> articulates one approach to the "Limited Internal" set of privacy
> rules. By specifying one view of exactly how the Limited Internal
> set of rules might be expressed, the Internet-Draft hopes to aid the
> WG's decisions on this key issue.
>
> Five separate things follow below. First, there is a brief and broad
> brush statement of the core privacy elements that we think should be
> contained in a "Limited Internal" design of the Location Object.
> Second, there is a more precise proposal on exactly how to articulate
> and express these elements; significantly, this proposal combines
> three of the elements into one "permissions table." Third, there is
> an alternate proposal that adds a few additional elements to the
> proposed permissions table, and thereby significantly enhances the
> power of the LO privacy protections. Fourth, there are a few
> additional comments about the proposals. Fifth and last is language
> in the form of a Requirement that could be inserted into a
> requirements document if the WG chooses the "Limited Internal"
> approach.
>
Received on Thu Oct 31 13:23:55 2002