Created:
Once upon a time, I wrote this together with my friend Dirk…
Updated: I also found a presentation from 1999 about it: plop.pdf
INTERNET-DRAFT Patrik Faltstrom
<draft-faltstrom-plop-01.txt> Dirk-Willem van Gulik
April 8, 1997
expires July 8, 1997
The People Location Protocol
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as ``work in
progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
The People Location Protocol (PLOP) gives the ability to subscribe
to a feed of geographical locations of specific objects. The protocol
describes both a TCP-based control channel, aswell as a lightweight
UDP-based location stream channel between both the object announcing
its position and the a PLOP service provider, and the PLOP service
provider and the subscriber.
1. Introduction
One problem today is to find the geographical location of objects, such
as friends, sattelites and airplanes. People have the need for finding
each other; and current methods such as the rwho, and finger protocols
generally reveal information in a crude and privacy invasing way. Furthermore
the introduction of nomad technology, such as DHCP, W-LANs, mobile IP and
roaming accounts has wired people and mobile objects.
In PLOP, three concepts are central; the Announcer, the Provider and the
Subscriber. Announcers somehow know and are able to provide the location
of an object. Providers can provide this information to third parties,
such as other providers or to Subscribers. The Subscriber is the final
client; which has a (legitimate) need to know the location of an object.
How the announcer knows the location is outside the scope of this protocol,
it could well have a NMEA serial interface to a GPS and be on the move; but
it might well proxy for a whole range of objects, based on information it
retrieves from its database.
Consider an email tool or personal address book; which warns
the user that the person to be called or emailed is in a different timezone,
or which suggest which phonenumber to use.
A user might simply ferry between his house, his work; and does want
to publish both places so that he can be reached easily, but at other times
might not want to be visible to others (except perhaps his mistress, girlfriend,
wife..) Such might be accomplished with a simple three state 'switch', home,
at work and 'not-there'; with some fixed locations and simple access controls
A duty doctor might want to publish his information during on-duty
hours; to, and insofar as needed by, the hospitals and medical-alarm centers,
but at the same time has to consider the privacy of his patients. Even though
a full blown GPS/GSM combination might be cool; the above can easily be accomplished
today by using the information already avaible at the medical alarm centers
in most countries which, during the night, links the postal-code or zip to
a specific doctor 'state'; such as 'on-call', 'in-transit', 'confirmed',
'signed-off' and 'off-call'.
A container fright company might want to keep track of its containers,
while they are at sea, on the road as well as at their customers. During some
parts of the transit; the locations are generally linked, and a simple ship
location announcement suffices for the container provider to publish the location
or estimated times of arrival of all containers known to be on the ship. But
during land transit by train or by car; other announcers might have to take
over; and during the last leg of the journey some dedicated hardware on
the container might be responsible of updating the information the location
announcer has avaible. The container company might have a desire to share
specific parts of the information with some of its customers.
Sometimes the location of the object, as a space craft, is to be
published and made known to a large number of users. A space organization
could for example provide some icons and a nice backdrop or screen safer
which displays latest mission happening live. Generally Mission Control
will be quite able to supply the location of its spacecraft; there is
little reason to actually add an Announcers, a GPS and an extra downlink
to the spacescraft misson !
The above examples illustrate several different extremes; some are essential
one-to-one exchanges with tight access controls; the other extreme is a many
to many exchange with little or no access and/or privacy controls. It should
be noted that the security and privacy concerns are generally inversely related
to the number of subscribers and the number of announcers.
2. Basic definitions
2.1 The PLOP Location Announcer (PLA)
The PLOP location announcer (PLA) is a PLOP client that want to publish its
geographical position. It must have a PGP key, where the public key is
stored on a public server. It must also have the public key of the PSP
(see 2.2) to be able to encrypt and sign the messages in PLP.
The PLA tells via the PLOP-control protocol (PCP) the PSP
that a certain other client can subscribe to the location, and with
what accuracy.
The PLA updates via the PLOP location protocol (PLP) the PSP the new
location.
Updates are send at the PLA's discretion for the duration of the
subcribtion lease.
2.2 PLOP Service Provider (PSP)
The PLOP service provider (PSP) is a server that receives the locations
sent from the PLA, checks if the message should be forwarded to some
other PSP (the authorative one), or takes care of registering the new
location of the PLA after checking the integrity of the location
announcement.
The PSP is for each changed location checking what PLS (see 2.3 below)
is subscribing to the location information for a given PLA, and sends
the updated location using PLP to the PLS with the given accuracy.
The PSP has announced its public key to the public as this key is needed
for the PCP protocol.
2.3 PLOP Location Subscriber (PLS)
The PLOP Location Subscriber is after subscribing for the location
using PCP for a given object at a PLA, given a stream of locations
from the PSP using PLP.
3 The protocols used
3.1 PLP
The PLOP Location Protocol is a UDP based protocol where the messages
are protected with a live key. The live key is exchanged between the
client and the server via the PCP protocol.
The format of the message in PLP is the following:
PLP = TAG CRLF LAT CRLF LONG CRLF TIME CRLF INFO CRLF
TAG = "Tag: " DIGIT
LAT = "Lat: " DEGREES
LONG = "Long: " DEGREES
TIME = "Time: " TIMESPEC
INFO = "Text: " TEXT
DEGREES = *PLUSMINUS DIGITS '.' DIGITS
TIMESPEC = *PLUSMINUS DIGITS '.' DIGITS
TEXT = *CHAR
PLUSMINUS = + | -
DIGITS = DIGIT *DIGIT
DIGIT = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
CHAR = < Any UTF-8 encoded UNICODE character except S-CHAR >
S-CHAR = < Any UNICODE character in the range U+0000 to U+001F >
The PLP message is encrypted using <A REAL ZIPHER ALGORITHM> with the
live key that is earlier exchanged between sender and receiver using
PCP. The receiver of a message is responsible for detecting if the
live key has changed, and
3.1.1 Lattitude / Longitude (DEGREES)
Values for latitude and longitude shall be expressed as decimal
fractions of degrees. Whole degrees of latitude shall be represented
by a two-digit decimal number ranging from 0 through 90. Whole degrees
of longitude shall be represented by a decimal number ranging from
0 through 180. When a decimal fraction of a degree is specified,
it shall be separated from the whole number of degrees by a
decimal point. Decimal fractions of a degree may be expressed to the
precision desired.
Latitudes north of the equator shall be specified by a plus sign (+),
or by the absence of a minus sign (-), preceding the
designating degrees. Latitudes south of the Equator shall be
designated by a minus sign (-) preceding the two digits designating
degrees. A point on the Equator shall be assigned to the Northern
Hemisphere.
Longitudes east of the prime meridian shall be specified by a plus sign
(+), or by the Longitudes west of the meridian shall be designated by
minus sign (-) preceding the digits designating degrees. A point
on the prime meridian shall be assigned to the Eastern Hemisphere. A
point on the 180th meridian shall be assigned to the Western
Hemisphere. One exception to this last convention is permitted. For
the special condition of describing a band of latitude around the
earth, the East Bounding Coordinate data element shall be assigned the
value +180 (180) degrees.
Any spatial address with a latitude of +90 (90) or -90 degrees will
specify the position at the North or South Pole, respectively. The
component for longitude may have any legal value.
With the exception of the special condition described above, this form
is specified in Department of Commerce, 1986, Representation of
geographic point locations for information interchange (Federal
Information Processing Standard 70-1): Washington, Department of
Commerce, National Institute of Standards and Technology.
3.1.2 Time (TIMESPEC)
A time is expressed as a Julian date, a Floating point number
of arbitrary accuracy denoting the number of days before (negative),
or after (positive) the 14th of September 1752.
3.2 PCP
The PLOP Control Protocol is a TCP based protocol where the messages
are transported using HTTP. Most messages are signed by the sender and
encrypted for the receiver using PGP.
The PCP protocol is used by either a PLS or a PLA when communicating
with the PSP.
The commands available are:
PCP = PCPCOMMAND CRLF
PCPCOMMAND = PLACOMMAND | PLSCOMMAND
PLACOMMAND = GETKEY | SETACL
PLSCOMMAND = GETKEY | SUBSCRIBE
GETKEY = "GetKey"
SETKEY = "SetKey" SPACE KEY
SETACL = "SetACL" SPACE TOKEN SPACE TAG
KEY = DIGITS
TOKEN = DIGITS
SPACE = <U+0020>
These commands are always encrypted with the public key of the PSP
and signed by the PLS or PLA so the PSP can verify the sender. The
resulting message, signed and encrypted, is sent via a POST command
via HTTP.
4. Security considerations
The PCP is encrypted with the public key of the PSP, and signed by
PLA or PLS. This ensures that both sender and receiver of the commands
verify each other to each other. Also, because of the encryption,
it is not possible to steal the connection.
PLP is secured via a symmetric encryption using a live key which is
exchanged via PCP. The sender of locations using PLP can choose to
change the live key whenever he wants. He is because of that also
responsible for changing the live key.
5. References
6. Author's Addresses