mznet.tex

早期freebsd实现

\begin{flushleft}
\hspace{.5in} {\tt CURRENT: 3}
\end{flushleft}

This indicates that the file {\tt DRAFT.003} would be operated upon
when default conditions apply (i.e. when no message number is
explicitly given to a CP/MH command).

Possible future uses for the info file include named message sequences
(a set of messages to which commands may be applied as a whole) and
user profile information for application to particular folders (there
is presently a single user profile, described shortly).

A floppy diskette may contain more than one folder, but folders
do not extend over more than one floppy diskette; therefore two
different diskettes may contain folders with the same name.

\subsection*	{CP/MH Commands}
Commands operating on messages can be divided into several general categories:
\medskip
\begin{description}
\item[Transporting:]	sending, receiving
\item[Viewing:]		selecting for display, showing header summaries
\item[Creating:]	composing, replying, forwarding
\item[Archiving:]	categorizing, refiling, deleting, sorting
\end{description}

\medskip
The architecture of CP/MH permits the simulation of some of these
categories using standard CP/M commands when CP/MH, in its present
primitive state, does not cover them.

A minimal functionality is presently provided by the following four commands:
\medskip
\begin{description}
\item[COMP]
composes mail items:
creates a file containing header information taken 
from a standard or user-specified template.  
This newly-created file may be edited to fill in
the header fields and body.
\item[REPL]
replies to mail items:
creates a file containing header
information appropriate for answering a given mail item.
This newly-created file may be edited to
change header fields and fill in the body.
\item[SEND]
sends mail items:
posts selected items through the split-slot from a draft folder.
\item[INC]
receives mail items:
takes delivery of selected items
across the split-slot, incorporating
them into a mailbox folder.
\end{description}
\medskip
These commands, with a few enhancements and modifications
appropriate to the CP/M environment, are functionally almost
identical to their Unix MH counterparts.

CP/MH commands are invoked like any other 
CP/M commands such as ED, PIP, or DIR.  
Command line options are generally preceded by a dash 
(e.g. {\tt -editor A:ED}), and may be abbreviated.  
Folder names are preceded by a plus (e.g. {\tt +B:DRAFT}).
Messages are identified by numbers or by the special names {\tt first},
{\tt last}, {\tt current}, {\tt next}, and {\tt previous}.

An example of use of a CP/MH command is:  

\begin{flushleft}
\hspace{1in} {\tt comp -edit a:ed -use last +b:draft -log}
\end{flushleft}

This particular example will edit the last-composed message (the
{\tt -use last} option) in the folder {\tt DRAFT} on disk drive {\tt B:}
(the {\tt +b:draft} option), using the standard CP/M editor ED on disk
drive {\tt A:} (the {\tt -edit a:ed} option), and prompting the user when
it is appropriate to change disks (the {\tt -log} option).

All CP/MH commands have a {\tt -help} option which displays all
available options for the particular command invoked.
Another common option is {\tt -log} which permits the user to change
({\it relog}) diskettes after invoking a command, for purposes of
selecting diskettes with message folders or with editor programs.
This is particularly useful on single-drive systems or on systems
with diskettes of low storage capacity.

\subsection*	{The Profile}
If there are options commonly used with a particular CP/MH command, 
they may be entered in the user profile contained in the file called 
(naturally enough) {\tt PROFILE}, which must exist on the same diskette on 
which CP/MH commands reside and from which the commands are invoked.  
A profile entry consists of a program name followed by a colon and 
the options to be used with that program, for example:

{\tt
\begin{flushleft}
\hspace{1in} comp: -editor A:VEDIT +B:outbox -log \\
\hspace{1in} repl: -editor A:VEDIT -log \\
\hspace{1in} send: +B:outbox \\
\hspace{1in} inc: +B:inbox -log
\end{flushleft}
}

Individual profile components are overridden by options given at
the time of invocation (e.g. {\tt -noedit} given on the command line
will override the {\tt -editor} profile component for a particular command).

\section*	{The MZnet Split-Slot Mail Transfer System}
The MZnet split-slot software implements a peer-to-peer
communication protocol between a time-sharing host's MTA and a personal 
micro-computer (PC) UA.
This MZnet protocol extends the UA/MTA/UA model of
computer-based message systems (CBMS) to provide a
split gateway function between individual PCs and the ZOTnet
similar to the UCI ICS split Internet gateway described previously
(see Figure~\ref{splitslot}).
\tagfigure{figure2}{The Split-Slot Model}{splitslot}

\subsection*	{The Structure of the Split-Slot}
The MZnet Split Gateway consists of three distributed processing components: 
\medskip
\begin{itemize}
\item A PC running a UA (in MZnet, CP/MH) acting as the mail server.
\item A mini/mainframe host running a full MTA (MMDF in MZnet)
providing mail relay services.
\item A communication protocol (a modified version of MMDF PhoneNet) to
connect the two ends of the split-slot.
\end{itemize}
\medskip
Although this combination may not be unique, the method by which the MZnet 
split-slot bonds these parts together uniquely deals with the 
problems of remote user agents.
In addition to overcoming limited storage and processing capacities,  
remote user agents must deal with noisy modem lines, 
mail software certification, and mail system security problems.  
The MZnet architecture appears to solve these problems with
a clean mail interface for PCs.

\subsection*	{The MZnet Mail Server}
The split-slot mail server consists of a set of {\it command packet}
programs run from the PC.
These programs simply present commands
through the PhoneNet communication protocol to the mail relay slave program
on the host.
Some basic commands are:

\medskip
\begin{description}
\item[PostMail]		posts mail drafts to MTA
\item[GetMail]		accepts mail from MTA
\item[RemoteScan]	displays information about waiting mail
\item[Quit]		drops connection between PC and Host
\end{description}

\medskip
Each command has the form:

\begin{flushleft}
\hspace{.5in} Command Request \\
\hspace{.5in} Data Transmission \\
\hspace{.5in} Command Termination
\end{flushleft}

For example, the PostMail command is a small program that:
\medskip
\begin{itemize}
\item initiates a command with the Mail Slave by sending the command
name (PostMail) encoded within a PhoneNet packet;
\item sends a series of PhoneNet packets that contain pieces of
the mail item to be posted; 
\item finally sends a command termination signal to end
the transaction without
terminating the connection between host and PC.
\end{itemize}

\subsection*	{The MZnet Channel To MMDF}
The MZnet Channel runs on the MTA host under the University of Delaware's
MMDF (Version 1) and is responsible for both delivery of received mail
to MZnet users, and posting of MZnet user-originated mail.
The MMDF MZnet channel maintains a unique message queue for each
registered MZnet user.
As new mail items arrive,
they are posted to the appropriate queues,
where MZnet holds the mail items for pickup by their registered
recipients.

To send or receive mail,
the MZnet user must attach to the host,
log into the public MZnet account,
and identify (authenticate) himself.
During the MZnet session with the host,
the user has access only to that restricted set of functions
provided by the MZnet split gateway protocol:
he may request delivery of queued mail with GetMail,
or post new mail with PostMail.
Prior to taking delivery of queued mail,
a survey of waiting mail also may be requested with RemoteScan to obtain
message size information (among other data)
to allow intelligent disposition 
of mail in the queue.

Hidden within these activities are issues of security and certification.
To certify and establish the identity of the user,
a second password is requested after logging into the 
public MZnet account.
This certification procedure allows MZnet to certify the source
of originated mail.
A relatively secure environment is provided by MZnet,
as it is the only interface to the host permitted to MZnet users
(once beyond the public login procedure),
and it offers only the severely restricted set of
PhoneNet-encoded commands.
Aside from security issues,
using a single account to handle all MZnet users
reduces demands on system resources.

\subsection*	{The MZnet-PhoneNet Protocol}
A unique facet of the MZnet system derives from the PhoneNet File 
Transfer Protocol (FTP).
PhoneNet FTP is a simple error-checked packet protocol which transfers
ASCII plaintext.
PhoneNet encodes any non-plaintext character (or any other character
``forbidden'' by the idiosyncrasies of the communicating systems) by
mapping it onto an ``accepted'' character set.
The accepted character set mapping is determined by
a ``negotiating'' session between the two systems at the start of
the PhoneNet session.

MZnet transfers all information (both commands and data) in PhoneNet
packets to obtain error control.
The MZnet-PhoneNet command FTP tolerates noise with a high degree
of success, and in effect, connects both ends of the Split Slot
together with a reliable set of virtual wires.

\subsection*	{MZnet Session Example}
Here, a typical MZnet session is presented, with the UA commands
issued from the PC side of the connection printed
in a {\tt typewriter} typeface, and the responses
from the host side printed
in an {\it italic} typeface.
PhoneNet interactions are indented.
The initial connection to the host is accomplished with the
{\tt term} program, which provides a simple terminal emulation
function.
The prompt of the PC for a UA command is ``A$\rangle$''.
Note that passwords are never echoed by the host system.

\begin{tabbing}
xxxxxxxx \= xxxxxxx \= \kill
\> A$\rangle$ {\tt term} \\
\> {\it login:} {\tt mznet} \\
\> {\it password:} \\
\> {\it MZ-Password:} \\
\> \> PhoneNet packet negotiation \\
\> {\it Connected.} \\
\> \> exit terminal mode \\
\> A$\rangle$ {\tt send cur} \\
\> \> PostMail command \\
\> \> message text packet transmission \\
\> \> command terminator \\
\> A$\rangle$ {\tt quit} \\
\> \> Quit command \\
\> {\it Disconnecting.}
\end{tabbing}

\section*	{Conclusions}
The main conclusions of this paper are that 
small personal computer systems 
with dial-up phone connections constrain User Agent systems design
in ways that require use of a {\it split-slot} interface between
the UA and its supporting Mail Transfer Agent (MTA), and that
this interface will best provide the required services if it
has error controlled command and data transfer facilities, with 
interactive behavior.

It is also believed that a good design for the small PC UA
is based on a very modular architecture, such as the Rand MH
system, which has been used as a pattern for the MZnet UA.

By bringing these concepts together,
we expect MZnet to provide reliable UA/MTA
service to a distributed set of small personal computers, to match
the quality of service that is normally only available from larger
mainframe host systems with co-resident UA/MTA pairs.

\bibliography{mznet}

\end{document}