Subject: new draft: draft-morris-geopriv-location-object-issues-00.txt

From: Cuellar Jorge <[email-masked]>
Date: Tue, 25 Jun 2002 10:34:24 +0200

We have submitted the following draft:
The use of Multiple Locations in the Location Object
draft-morris-geopriv-location-object-issues-00.txt

It is a discussion on the Location Object that, when consolidated,
will probably be part of draft-ietf-geopriv-reqs-00.txt

You may find the draft at:

http://www.ersue.de/geopriv/draft-morris-geopriv-location-object-issues-00.t
xt

Please let me know, if you have any comments.

Regards,

Jorge
-----------------------------------------------------
Internet Draft
	John B.  Morris, Jr.
	Center for Democracy and Technology

	J.  Cuellar
	Siemens AG

	A.  Gogic
	QUALCOMM, Inc.

	D.  Mulligan
	A.  Burstein
	Samuelson Law, Technology, and Public Policy Clinic

Expires: Dec. 2002	June 2002

The use of Multiple Locations in the Location Object

<draft-morris-geopriv-location-object-issues-00.txt>

Table of Contents

 1. Abstract	2
 2. Summary	2
 3. Conventions Used in This Document	3
 4. Underlying Assumptions	3
 4.1. Location Representation in the Location Object	4
 4.2. Location Representation Format	4
 4.3. Provisions for Precision and Confidence	4
 4.4. Multiple Representations of a Single Location	5
 5. User-controlled Precision of Location Representation	5
 6. Misstatement of Location Information	5
 7. Multiple Locations	6
 7.1. General Principles	6
 7.2. The Semantics of Multiple Locations within a Single Object	6
 8. Acknowledgements	7
 9. References	7
 10. Author's Addresses	7
 11. Full Copyright Statement	8

1. Abstract

This document discusses three major questions that were posed and discussed
at some length at the interim meeting in San Diego, June 2002:

(1) Should geopriv facilitate the misrepresentation of location information?

(2) Should the geopriv Location Object (LO) accommodate multiple locations
as part of a single positioning transaction?

(3) If so, should the Location Object hold multiple locations in a single
object, or should the multiple locations be contained in multiple objects?

In this paper we propose an answer to those questions.

2. Summary

In this paper we propose the following: 

(1) Geopriv should not facilitate the misrepresentation of location
information (but it should also not try to prohibit it).

(2) The protocol should allow multiple Locations within one Location Object,
meaning that the intended location is one of the Locations included in the
LO.

(3) Further each Location may contain different representations of the
location (for instance, the results of different measuring technologies).

(4) An application may use multiple locations contained in multiple objects
if desired.

The relationship between LO, Locations and Location Representations may be
seen schematically as follows: The Location Object MAY contain zero, one, or
several Locations (= Location Fields) L1, L2, etc:

LO =
+------+------+------+------+------+------+--------+------+
|  ID  | Cred |  ..  |  L1  |  ..  |  Li  |  ..    |  Ln  |
+------+------+------+------+------+------+--------+------+
                     \_______________  ___________________/
                                     \/
                             Location Information

The intended semantics of the Location Information is then that one of the
Li is

  Location Information = L1 or L2 or ... Ln

in the sense that the Location Information "holds" (for whatever purpose the
using protocol uses the location) exactly if one location Li "holds".

Further, a Location (field) Li is MAY contain different "Location
Representations"

Li (i=1,.., n)  =
+--------+--------+--------+--------+--------+
|  LRi1  |  LRi2  |   LRi3 |  ..    |   LRim |
+--------+--------+--------+--------+--------+

The intended semantics of a Location Li is

  Li = LRi1 and LRi2 and ... LRim

in the sense that location Li "holds" (for whatever purpose the using 
protocol uses the location) exactly if all location representations
LRij "hold".

--------------------------------------------
Dr. Jorge R Cuellar     T +49 89 636-47 585
Security                
CT IC 3                 
Siemens        [email-masked]
----------------------------------------------

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 26 Jun 2002 11:02:33 -0400

Cuellar,

It seems to me that at the end of the WG process, a draft goes to WG LC
with a section that reads something like:

N. IANA Considerations

   If the IESG approves this memo for publication, then the IANA registers
   (something, tbd), as specified in Section I.J.

   The IANA maintains a list of:

   o  standards-track spatial coordinate system identifiers, c.f., Section K.L;

   ... (zero or more things that aren't either standards-track, or aren't
	spatial coordinate system identifiers, or both).

   For each list, the IESG is responsible for assigning a designated expert
   to review the specification prior to the IANA making the assignment.

Specification of what the IANA maintains a list(s) of is an issue.

Eric