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

From: [email-masked]
Date: Wed, 30 Oct 2002 16:21:22 -0500

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-morris-geopriv-core-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-morris-geopriv-core-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: John Morris <[email-masked]>
Date: Thu, 31 Oct 2002 11:59:42 -0500

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

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

---

From: Carl Reed <[email-masked]>
Date: Thu, 31 Oct 2002 11:04:41 -0700

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