About this blog…

I am employed by Netnod as head of engineering, research and development and am among other things chair of the Security and Stability Advisory Committee at ICANN. You can find CV and photos of me at this page.

As I wear so many hats, I find it being necessary to somewhere express my personal view on things. This is the location where that happens. Postings on this blog, or at Facebook, Twitter etc, falls under this policy.

The views expressed on this post are mine and do not necessarily reflect the views of Netnod or any other of the organisations I have connections to.

People Location Protocol – PLOP

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

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


   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

   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

   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:

        TAG       = "Tag: " DIGIT
        LAT       = "Lat: " DEGREES
        LONG      = "Long: " DEGREES
        TIME      = "Time: " TIMESPEC
        INFO      = "Text: " TEXT
        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

   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
      GETKEY     = "GetKey"
      SETKEY     = "SetKey" SPACE KEY
      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