"Whoson" protocol document

[Eugene Crosser <crosser@online.ru>]

Hello,

while Matti is not here ;-)  I'd ask you to look at the document below.
Comments/suggestions/criticism solicited.  I would be especially thankful
if some kind soul with good English correct my style and syntax...

Eugene

# This is a draft proposal for the "Who's On" protocol.
# Eugene G. Crosser <crosser@average.org>
# Original version: 28 Apr 1998

# $Id: protocol.txt,v 1.2 1998/07/12 23:01:24 crosser Exp crosser $

# $Log: protocol.txt,v $
# Revision 1.2  1998/07/12 23:01:24  crosser
# make protocol "symmetric"
# Write introduction etc.
#

Status of this memo
===================

This memo suggests a simple method for Internet server programs to know
if a particular (dynamically allocated) IP address is currently
allocated to a known (trusted) user and, optionally, the identity of the
said user.  This RFC specifies a proposed protocol for the Internet
community, and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.

This memo is not based on any previous work, although it tries to follow
the spirit of other Internet protocols.

Introduction
============

Over the recent years, a commonly adopted policy has evolved to protect
SMTP Mail Transfer System (MTS) servers form being unwillingly used for
relaying third party email (Spam-relaying protection policy).  This
policy requests that email submitted from "foreign" networks should only
be accepted for delivery if destined to a limited set of addresses
served by this MTS.

This approach has unwanted implication on the "travelling customers",
i.e. the people who are using their portable systems to send email while
being connected to the Internet over a different Internet provider than
their "main" provider whose MTS they are using.

Being connected from IP addresses "foreign" to the MTS, such users
will have their email rejected by the MTS.

To avoid this problem, the following approach was suggested: keep a
database of "temporarily trusted" IP addresses, e.g. addresses from
which a successfull POP3 or IMAP session was recently originated, or
addresses that have been allocated to a trusted user by a server that
provides authentication for Internet roaming.

The suggested "Who Is Online" ("whoson") protocol can be used to
implement this feature in a uniform way.  In addition, it may be used in
the same way as the "ident" (RFC931/1413) protocol to identify the users
connected to the Internet via dialup.

Rationale
=========

The design goal of the protocol is to allow the Application Program
Interface (API) be simple and fast, and move maintenance of the database
of addresses and things like "Time to Live" (TTL) housekeeping to a
dedicated server process.  On the other hand, the server process is not
supposed to ever perform "slow" operations like DNS lookups, to make
possible a "single process" implementation.

The server process shall listen for incoming stream (such as UNIX domain
or TCP) and/or datagram (such as UDP) connections. Stream type
connections may be encrypted.  Access may be restricted to only some
addresses and some protocols by local policy.

Protocol Description
====================

The client request and the server responce are sets of one or more lines
of ascii characters.  Each line is terminated with a <CR> <LF> sequence,
and the whole request or responce is terminated by an empty line, i.e.
the <CR> <LF> <CR> <LF> sequence.  Only the first line is mandatory,
other lines are reserved for future extentions of the protocol.  The
server and the client shall ignore those extention lines that they
cannot interpret.  For connectionless transports, the size of the
request and the responce is limited to a single network send/receive
operation; implementation may impose further restrictions on the maximum
size.

The first line of the request that the client sends to the server shall
have the following format:

	<verb> <SP> <addr-spec> [ <SP> <user-identity> ] <CR> <LF>

Here the <verb> is one of the strings "LOGIN", "LOGOUT" and "QUERY",
<SP> is one or more space or tab characters, <addr-spec> is standard
printable ascii representation of the address (dotted quad notation for
IPv4 addresses), <user-identity> is the user I.D. or whatever is used to
identify the user on the local system.  The "<SP> <user-identity>"
sequence is only allowed if the verb is "LOGIN".  The <addr-spec> may
not contain whitespace (space or tab) characters.  Other verbs may be
defined as extentions of this protocol; if the server cannot recognize
the verb, it shall send a "request cound not be processed" responce (see
below).

The first line of the server responce shall have the following format:

	<indicator-character> [ <data> ] <CR> <LF>

Here <indicator-character> is a single ascii character; the following
values of <indicator-character> are defined:

	'+':	request processed, result is positive ("found")
	'-':	request processed, result is negative ("not found")
	'*':	request cound not be processed

Other characters may be specified as extentions of this protocol; if the
client cannot recognize the indicator character, it shall interpret it
in the same away as '*' (request cound not be processed).

<data> part of the responce is optional; if the indicator character is
'+', it shall, if present, contain the <user-identity> data associated
with the specified <addr-spec>.  If the <indicator-character> is other
than '+', <data> may contain plain text explanation of the failure
reason.

Notes On Semantics
==================

"LOGIN" and "LOGOUT" requests tell the server that a particlular IP
address is in use by a trusted user, and that the address is no longer
in use by a trusted user, respectively.  "QUERY" request asks the server
which user, if any, currently uses the particular IP address.

"LOGOUT" request for an address that was previously specified in a
"LOGIN" request is optional; the server shall get rid of old entries
based on locally defined policy.

References
==========

    [Not ready, to be filled]

Author's Address
================

Eugene G. Crosser
Sovam Teleport
Verhniaya Maslovka 5-16
Moscow 125083, Russia

Phone: +7 095 258 4170
Fax: +7 095 258 4133
Email: crosser@average.org