Beginning of documentation.

3 files changed, 1131 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..c158862
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,4 @@
+# Temporary files
+*~
+*.swp
+
diff --git a/doc/narp.pdf b/doc/narp.pdf
new file mode 100644
index 0000000..1804485
--- /dev/null
+++ b/doc/narp.pdf
diff --git a/doc/narp.tm b/doc/narp.tm
new file mode 100644
index 0000000..a992ffe
--- /dev/null
+++ b/doc/narp.tm
@@ -0,0 +1,1127 @@
+<TeXmacs|1.99.2>
+
+<style|generic>
+
+<\body>
+  <doc-data|<doc-title|The NARP protocol specification >|<doc-subtitle|A
+  Generic Recursive Communication Protocol for Networked Applications>>
+
+  In this document we explain the purpose and provide a draft specification
+  for the NARP protocol, a general-purpose networking protocol destined to be
+  used in many layers of a new operating system and networking system.
+
+  <section|Introduction>
+
+  We begin by remarking that a basic operation in all computer operation
+  processes consists in naming objects and providing acces to these named
+  objects. Here are a few examples of naming in real use cases:
+
+  <\itemize>
+    <item>Naming of files on a local or distant file system
+
+    <item>Naming of devices in the <verbatim|/dev> virtual filesystem on Unix
+    machines
+
+    <item>Naming of networked machines (with IP adresses and DNS records)
+
+    <item>Naming of internet ressources over protocols such as HTTP, IMAP,
+    ...
+  </itemize>
+
+  We propose here a novel architecture with the purpose of unifying all the
+  naming happening at all levels of the system, with two base concepts :
+  <em|objects> and <em|service>.
+
+  <\itemize>
+    <item><em|objects> are ressources that may implement different semantics
+    : bidirectionnal communication (such as sockets) ; unidirectionnal
+    communication (FIFO-like) ; file semantics ; etc.
+
+    <item><em|services> are a way of naming objects, querying the interfaces
+    they implement, and multiplexing communications with them
+  </itemize>
+
+  We suggest that a NARP service may be provided on any bidirectionnal
+  channel of communication supporting the (reliable) sending and recieving of
+  messages. In addition, NARP objects may implement such a send/recieve
+  interface ; therefore a NARP service can be channeled into an object. Such
+  a construction of using a NARP object to access a NARP service is a
+  fundamental operation that we call <em|recursive multiplexing>, or just
+  <em|multiplexing>.
+
+  The NARP protocol is meant to include a variety of different operations
+  that may or may not be implemented by a specific NARP server.
+
+  <section|High-level overview>
+
+  <subsection|The basic operations on services and objects>
+
+  A NARP service is basically any object that implements the following
+  operations:
+
+  <\itemize>
+    <item><em|query> : get information on a ressource identified by name
+
+    <item><em|list> : know the names of ressources presented by the service
+    (eventually in a specific sub-path)
+
+    <item><em|attach> : get an object interface for accessing a ressource,
+    identified by name
+  </itemize>
+
+  A NARP object is basically any object that implements the following
+  operations :
+
+  <\itemize>
+    <item><em|send> : send a message (an arbitrary byte string) to the object
+
+    <item><em|recieve> : recieve a message from the object (this may be done
+    asynchronously with handler functions)
+
+    <item><em|detach> : delete object connection
+  </itemize>
+
+  <subsection|The basics of the NARP protocol>
+
+  Given any interface with send/recieve capabilities considered as an
+  assymetric (client/server) configuration, the following client messages
+  consitute the basics of the NARP protocol for providing a NARP service on
+  the interface:
+
+  <\itemize>
+    <item><verbatim|hello> : initialize a connection, check version
+    information, ...
+
+    <item><verbatim|authenticate> and appropriate response messages : use
+    credentials (user/password or access token) to gain acces to some
+    ressources provided by the server (the protocol is thus statefull)
+
+    <item><verbatim|walk>, <verbatim|list> and appropriate response messages
+    : get information about the available ressources
+
+    <item><verbatim|attach> and appropriate response messages : give an
+    identifier (a descriptor) to a ressource in order to communicate with it
+
+    <item><verbatim|send> and appropriate response messages : send a message
+    to an attached ressource, identified by its descriptor
+
+    <item><verbatim|detach> : close a descriptor and detach from a ressource
+
+    <item><verbatim|create> : requests the creation of a ressource in the
+    namespace
+
+    <item><verbatim|delete> : requests the deletion of a ressource in the
+    namespace
+
+    <item><verbatim|link> : create a link for an object under another name
+    (these are always symbolic links, and are independent of the pointed
+    ressource)
+  </itemize>
+
+  The server may also at any moment send a message, including:
+
+  <\itemize>
+    <item>a response to a query
+
+    <item><verbatim|recieve> : a notification of a message sent from the
+    object to the client
+
+    <item><verbatim|detached> : the connection to the object has been
+    terminated by the object server
+  </itemize>
+
+  <subsection|Recursion>
+
+  If an object is a NARP server, the messages sent to it and recieved from it
+  are messages of the NARP protocol. Otherwise, they are arbitrary.
+
+  <subsection|Reverse object><label|rev-sock>
+
+  Some NARP servers may support reverse object serving: the client creates an
+  object on the server and handles all the requests arriving to this object
+  (therefore the initial NARP server only serves as a relay between the new
+  server and its clients<\footnote>
+    Research is to be done on shortcutting mechanisms
+  </footnote>). A client wishing to act as a reverse object server may use
+  the following commands:
+
+  <\itemize>
+    <item><verbatim|serve> : listen for attach requests on a servable (empty)
+    object created in the server namespace (if authorized)
+
+    <item><verbatim|accept> and <verbatim|reject> : accept (or reject) an
+    attach request to the object
+
+    <item><verbatim|detach> : close connection between object and client
+    (this is the same detach message as in standard communications)
+
+    <item><verbatim|unserve> : stop serving for the object. Attached clients
+    continue to be attached.
+  </itemize>
+
+  The server may in turn send the following messages concerning the server
+  object:
+
+  <\itemize>
+    <item><verbatim|attach_request> : a client is willing to attach to the
+    object. A descriptor is already associated to the connection to be
+    established, but the server may reject it.
+  </itemize>
+
+  Once a client is attached to the object, a classical send/recieved
+  interface is provided.
+
+  Typically, the protocol exchanged over the object is NARP protocol,
+  therefore enabling the reverse server to provide its own namespace and
+  other functionnality.
+
+  <subsection|Specific object types and associated messages>
+
+  <subsubsection|Objects are sockets>
+
+  Sockets are the basis of the NARP protocol : attaching to an objects opens
+  a socket connection to the process serving the object, and when the
+  connection is accepted, basic send/recieve functionnality is provided. See
+  also the reverse object protocol described in section <reference|rev-sock>.
+
+  <subsubsection|File objects>
+
+  Small files may implement the following interface:
+
+  <\itemize>
+    <item><verbatim|put> : erase the whole file and put the transmitted
+    content
+
+    <item><verbatim|get> : retrieve the whole file content
+  </itemize>
+
+  Big files may implement the following interface:
+
+  <\itemize>
+    <item><verbatim|write> : write a portion of the file at a given offset
+
+    <item><verbatim|read> : read a portion of the file at a given offset
+  </itemize>
+
+  <subsubsection|User IO (terminals...)>
+
+  Virtual terminals can be seen as objects implementing a simple send/recieve
+  semantic, where the data transmitted is unstructured (or structured given a
+  specific terminal data structure). More specific interfaces can be defined
+  for advanced terminals and GUIs.
+
+  <subsubsection|Specific applications>
+
+  Specific applications may define custom messages. Examples include:
+
+  <\itemize>
+    <item>e-mail
+
+    <item>instant messaging
+
+    <item>collaborative editing of text-based documents
+  </itemize>
+
+  and many other applications yet to be invented.
+
+  <subsection|Big messages>
+
+  The message size in the NARP protocol is limited to 64kb, and recommended
+  not to exceed 4kb+header (4kb is the size of a memory page on many
+  machines). Therefore a possibilith would be for the NARP protocol to
+  include a way to transmit big messages by fragmenting them into small
+  messages. Optionnal error correction may be included. This can be useful
+  for example when using <verbatim|put> or <verbatim|get> on large files, or
+  <verbatim|read>s and <verbatim|write>s of big file portions. The recieving
+  of a large fragmented message may have a specific implementation allowing
+  the reciever to work with the partial data as soon as it starts arriving
+  and not having to wait for the whole message to be transmitted and
+  buffered.
+
+  <subsection|Permissions>
+
+  For each attached client the server may keep track of associated
+  permissions, and accept or reject requests according to those permissions.
+  The client may use an authentication command to gain supplementary
+  privileges on the server's ressources. The client may request a token to
+  delegate it's privileges on a given object to another client. Advanced
+  right management functionnalities are to be discussed.
+
+  <subsection|Example NARP servers>
+
+  <subsubsection|Virtual NARP server (i.e. NARP router)>
+
+  This server implements a namespace where any client may create an empty
+  object and serve connections to it. Additionnaly, the server may implement
+  the possibility to create virtual files, virtual directories, FIFO queues,
+  etc.
+
+  This server may be connected to other virtual NARP servers in order to
+  provide a global namespace accessible to all. Each virtual NARP server acts
+  as an endpoint into the network and may have functionnality for routing the
+  communications to objects to the clients that serve them.
+
+  <subsubsection|NARP file server>
+
+  This server simply implements access to a filesystem : listed ressources
+  are the same as the files present in a served directory, each of these
+  implements the filing protocol (served directly by the file server), and
+  the creation of files/directories may also be implemented.
+
+  <subsubsection|NARP terminal/GUI server>
+
+  Clients may create objects on the server ; each of these objects correspond
+  to a GUI window. Two interfaces may be implemented : text IO (terminal) and
+  graphical interaction. Advanced terminal interaction features may be
+  implemented at the protocol level, such as auto-completion of commands or
+  of text being edited...
+
+  Suggestion for a third kind of window : the data sent by the client
+  corresponds to a description of the scene in a given markup language and
+  the server does the rendering. The client can also subscribed to events
+  such as clicking on an item or entering text. This possibility is to be
+  explored.
+
+  <subsubsection|NARP e-mail and newsgroup server>
+
+  Several features to be implemented:
+
+  <\itemize>
+    <item>user login and private user mailboxes
+
+    <item>bridge to standard SMTP/POP3/IMAP services
+
+    <item>private threads of conversation with access rights (the users don't
+    each have a copy of the thread)
+
+    <item>synchronization between many servers
+
+    <item>public discussion forums
+  </itemize>
+
+  <subsubsection|NARP chat server>
+
+  <\itemize>
+    <item>user login and status notification
+
+    <item>online and offline private messaging
+
+    <item>public chat rooms, chat room logging independently of user being
+    online or offline
+
+    <item>bridging and synchronization between many servers
+  </itemize>
+
+  <subsubsection|NARP applicative server>
+
+  TODO...
+
+  <section|Specifics of the NARP protocol>
+
+  <subsection|Protocol description format>
+
+  A protocol message is given in the following form:
+
+  <block*|<tformat|<table|<row|<cell|element type>|<cell|element
+  type>|<cell|<math|\<ldots\>>>|<cell|element type>>|<row|<cell|element
+  description>|<cell|element description>|<cell|<math|\<ldots\>.>>|<cell|element
+  description>>>>>
+
+  The following element types apply:
+
+  <\itemize>
+    <item><math|int16>, <math|int32>, <math|int64> : 16-bit, 32-bit or 64-bit
+    little-endian integers
+
+    <item><math|str> : a string, prefixed by a 16-bit length header
+
+    <item><math|arr<around*|(|T|)>> : an array of <math|T>'s (where <math|T>
+    is another element type), prefixed by a 16-bit length header
+
+    <item>* (for the last element) : consider all the rest of the message as
+    a byte string
+  </itemize>
+
+  <subsection|Basic message format>
+
+  The basic format of a message is :
+
+  <block*|<tformat|<table|<row|<cell|int16>|<cell|int16>|<cell|*>>|<row|<cell|message
+  size>|<cell|message type>|<cell|payload>>>>>
+
+  We will abbreviate by ``header'' the first 32 bits (4 bytes) of the
+  message. The list of message types is given in section
+  <reference|type-nums>.
+
+  Messages for communication with an attached ressource will have the
+  following format :
+
+  <block*|<tformat|<table|<row|<cell|int16>|<cell|int16>|<cell|int32>|<cell|*>>|<row|<cell|message
+  size>|<cell|message type>|<cell|ressource descriptor
+  (handle)>|<cell|payload>>>>>
+
+  Many client messages awating a response will have a message ID included ;
+  this message ID is an arbitrary number generated by the client and used by
+  the server when giving its response. The header then looks like this:
+
+  <block*|<tformat|<table|<row|<cell|int16>|<cell|int16>|<cell|int32>|<cell|*>>|<row|<cell|message
+  size>|<cell|message type>|<cell|message ID>|<cell|payload>>>>>
+
+  <subsection|Message list for core NARP protocol>
+
+  Client messages have an up arrow (<math|\<uparrow\>>) next to their name,
+  while server messages have a down arrow <math|<around*|(|\<downarrow\>|)>>.
+
+  The core NARP protocol is meant for small size and rapidity (so that many
+  layers can be encapsulated with minimal overhead), therefore no
+  acknowlegment is to be sent for most messages. Specific interfaces for
+  objects are responsible for making sure messages have been transmitted
+  correctly.
+
+  <paragraph|Hello<math|\<uparrow\>\<downarrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|arr(int32)>>|<row|<cell|header>|<cell|version>|<cell|list
+    of needed/provided interfaces>>>>> \ \ 
+
+    When a NARP connection is established, the client is always the first to
+    send a <strong|Hello> message. The object may then respond either with a
+    <strong|Hello> message indicating that the requested interfaces can be
+    provided, or with an <strong|Error> message. The two common error causes
+    are <em|interface not implemented> and <em|incompatible versions>.
+
+    For interface numbers : see table in section <reference|interface-nums>.
+  </indent>
+
+  <paragraph|Error<math|\<downarrow\>>>
+
+  <\indent>
+    Generic error response message for any operation.
+
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
+    ID>|<cell|error ID>|<cell|error string>>>>>
+
+    Common error IDs are specified in section <reference|error-nums>.
+  </indent>
+
+  <paragraph|Ack<math|\<downarrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>>|<row|<cell|header>|<cell|request
+    ID>>>>>
+
+    Generic acknowlegment message for commands that require it. An acknowlege
+    implies the command has been sucessfully executed (otherwise an error
+    message is sent).
+  </indent>
+
+  <paragraph|Stat<math|\<uparrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
+    ID>|<cell|filename>>>>>
+
+    The request ID is an ID decided by the client so that it can identify the
+    answer.
+  </indent>
+
+  <paragraph|StatR<math|\<downarrow\>>>
+
+  <\indent>
+    Response to the <strong|Stat> message.
+
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|arr(int32)>>|<row|<cell|header>|<cell|request
+    ID>|<cell|implemented interface>>>>>
+
+    Common interface numbers are to be found in section
+    <math|<reference|interface-nums>>.
+
+    If a <strong|Stat> query on an object gives a certain list of interfaces,
+    then when connecting to the object at least all these interfaces must be
+    included in the server's <strong|Hello> message as supported interfaces.
+
+    Note that some interface numbers correspond to actions that can be done
+    on the object from the connection where the object exists (e.g. :
+    symbolic link, directory), and others correspond to actions that can be
+    performed after attaching to the object (e.g. file, terminal, ...)
+  </indent>
+
+  <paragraph|List<math|\<uparrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
+    ID>|<cell|first entry number>|<cell|number of entries
+    requested>|<cell|base path string>>>>>
+  </indent>
+
+  <paragraph|ListR<math|\<downarrow\>>>
+
+  <\indent>
+    One message is passed for each entry in the requested range:
+
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
+    ID>|<cell|entry number>|<cell|entry name>>>>>
+
+    After the directory has finished being enumerated, a supplementary entry
+    is given with entry number the last valid entry number plus one and an
+    empty entry name. This supplementary entry is only given if its (ficious)
+    entry number is included in the range requested by the client.
+  </indent>
+
+  Possible extension : combine List and Stat so that when the answer to List
+  is given, information is also given on the object's implemented interfaces.
+
+  <paragraph|Attach<math|\<uparrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
+    ID>|<cell|filename>>>>>
+  </indent>
+
+  <paragraph|Attached<math|\<downarrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>>|<row|<cell|header>|<cell|request
+    ID>|<cell|handle>>>>>
+
+    (the handle, ie the ressource descriptor, is attributed by the server)
+  </indent>
+
+  <paragraph|Send<math|\<uparrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|*>>|<row|<cell|header>|<cell|handle>|<cell|payload>>>>>
+  </indent>
+
+  <paragraph|Recieve<math|\<downarrow\>>>
+
+  <\indent>
+    Spontaneous server message indicating some data is sent by object.
+
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|*>>|<row|<cell|header>|<cell|handle>|<cell|payload>>>>>
+  </indent>
+
+  <paragraph|Detach<math|\<uparrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>>|<row|<cell|header>|<cell|handle>>>>>
+  </indent>
+
+  <paragraph|Detached<math|\<downarrow\>>>
+
+  <\indent>
+    Spontaneous server message indicating the object has been detached.
+
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>>|<row|<cell|header>|<cell|handle>>>>>
+  </indent>
+
+  <paragraph|<strong|Create<math|\<uparrow\>>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|arr(int32)>|<cell|str>>|<row|<cell|header>|<cell|request
+    ID>|<cell|needed interfaces>|<cell|path>>>>>
+
+    A create request is accompanied with a list of needed interfaces that
+    direct the server into creating the corresponding type of object (e.g. an
+    empty object to be served, a directory, a file, ...)
+  </indent>
+
+  <paragraph|Created<math|\<downarrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|arr(int32)>>|<row|<cell|header>|<cell|request
+    ID>|<cell|implemented interfaces>>>>>
+
+    Signals that the object has been created, and has corresponding
+    interfaces associated to it.
+  </indent>
+
+  <paragraph|Delete<math|\<uparrow\>><verbatim|>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
+    ID>|<cell|path>>>>>
+
+    This message expects a standard <strong|Ack> response message.
+  </indent>
+
+  <paragraph|Link<math|\<uparrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>|<cell|str>>|<row|<cell|header>|<cell|request
+    ID>|<cell|destination path>|<cell|link path>>>>>
+
+    This message expects a standard <strong|Ack> response message.
+
+    Semantics of the link object:
+
+    <\itemize>
+      <item>attaching or serving on this objects corresponds to resolving the
+      linked path and attaching/serving on the linked object
+
+      <item>stating the link will stat the linked object and add as an
+      implemented interface the ``this is a symlink'' information
+
+      <item>directory listings follow links
+
+      <item>deleting the link will not delete the original file but only the
+      link
+    </itemize>
+  </indent>
+
+  <paragraph|ReadLink<math|\<uparrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
+    ID>|<cell|path>>>>>
+  </indent>
+
+  <paragraph|ReadLinkR<math|\<downarrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
+    ID>|<cell|link description>>>>>
+
+    This will only return the first level of linking, ie the link data
+    directly associated to the link object.
+  </indent>
+
+  <paragraph|Rename<math|\<uparrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>|<cell|str>>|<row|<cell|header>|<cell|request
+    ID>|<cell|original path>|<cell|new path>>>>>
+
+    This message expects a standard <strong|Ack> response message.
+  </indent>
+
+  <paragraph|Serve<math|\<uparrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
+    ID>|<cell|path>>>>>
+
+    This message is a request for the client to be a reverse server to an
+    object. The response message to this message is an <strong|Attached>
+    message. The handle attributed to the served object is known as the
+    <em|server handle> and is used in the following few messages.
+
+    To stop serving an object, the client simply sends a <strong|Detach>
+    command on the server handle. The semantics is that all connections that
+    have been openned through the reverse-served object are preserved when
+    the object stops being served, and an individual <strong|Detach> message
+    must be sent to all of them if we want to close them.
+  </indent>
+
+  <paragraph|Incoming<math|\<downarrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>>|<row|<cell|header>|<cell|server
+    handle>|<cell|client hande>>>>>
+
+    This message is sent by the server when another client wishes to attach
+    to an object reverse-served by this client. The server handle is the one
+    given as a response to the <strong|Serve> message. The client handle is a
+    handle associated to the connection. The reverse server may reject the
+    connection by issuing a <strong|Detach> command on the client handle, or
+    may accept it using the <strong|Accept> message given below.
+  </indent>
+
+  <paragraph|Accept<math|\<uparrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>>|<row|<cell|header>|<cell|client
+    handle>>>>>
+
+    Once a connection has been accepted, the reverse server may at any moment
+    close it by sending a <strong|Detach> command on the corresponding client
+    handle.
+  </indent>
+
+  <subsection|Big message protocol>
+
+  To be defined. Is it really usefull? What role exactly does it have? Can it
+  implement repetition in the case where the message hasn't been acknowledge?
+  ...
+
+  Reserved message IDs : <math|<around*|[|20,30|)>> and
+  <math|<around*|[|10020,10030|)>>.
+
+  <subsection|Authentification and rights managment commands>
+
+  <paragraph|Authenticate<math|\<uparrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|*>>|<row|<cell|header>|<cell|message
+    ID>|<cell|authentification method>|<cell|authentification data>>>>>
+
+    Used to gain access using credentials (user/password, token, ...).
+    Response messages are standard <strong|Ack> on success or <strong|Error>
+    on failure. Autentification methods include :
+
+    <\itemize>
+      <item>1 : user + password
+
+      <item>2 : token
+    </itemize>
+  </indent>
+
+  <paragraph|NewToken<math|\<uparrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|message
+    ID>|<cell|path>>>>>
+
+    Requests the server to create an authentication token for accessing a
+    given object with the privileges of the connected client. Once the token
+    has been returned, it may be transmitted to another client so that that
+    client will use it to gain same access to the object.
+  </indent>
+
+  <paragraph|NewTokenR<math|\<downarrow\>>>
+
+  <\indent>
+    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|message
+    ID>|<cell|token>>>>>
+  </indent>
+
+  More TODO : request account creation, manage user groups and ACLs, ...
+
+  <subsection|File protocol>
+
+  Client messages [50,100) ; server messages [10050,10100).
+
+  <subsection|UI protocols>
+
+  Client messages <math|<around*|[|100,200|)>> and server messages
+  <math|<around*|[|10100,10200|)>>.
+
+  <subsubsection|Terminal protocol>
+
+  TODO
+
+  <subsubsection|Graphical user interface protocol>
+
+  TODO
+
+  <subsection|Communication protocols>
+
+  Client messages <math|<around*|[|200,300|)>> and server messages
+  <math|<around*|[|10200,10300|)>>.
+
+  <subsubsection|Email and newsgroups protocol>
+
+  Client messages <math|<around*|[|200,220|)>>, server messages
+  <math|<around*|[|10200\<nocomma\>,10220|)>>.
+
+  <subsubsection|Instant messaging protocol>
+
+  Client messages <math|<around*|[|220,250|)>>, server messages
+  <math|<around*|[|10220\<nocomma\>,10250|)>>.
+
+  <subsection|Other protocols>
+
+  Protocols not discussed in this specification may use client messages with
+  type IDs <math|<around*|[|1000,10000|)>> and server messages
+  <math|<around*|[|11000,20000|)>>. Overlaps between several protocols are
+  allowed : the information about implemented interfaces for an object is
+  meant to disambiguate such situations.
+
+  <subsection|Table of IDs>
+
+  The tables presented in this section give the number associated to the
+  message types. These tables are the reference on the subject ; any
+  information found somewhere else is wrong if it is not the same as found
+  here. This is for protocol version 1.
+
+  <subsubsection|Message types><label|type-nums>
+
+  <paragraph|Base protocol>
+
+  <\indent>
+    <block|<tformat|<cwith|1|-1|4|4|cell-tborder|0px>|<cwith|1|-1|4|4|cell-bborder|0px>|<table|<row|<cell|message>|<cell|<math|\<uparrow\>>
+    id>|<cell|<math|\<downarrow\>> id>|<cell|>|<cell|message>|<cell|<math|\<uparrow\>>
+    id>|<cell|<math|\<downarrow\>> id>>|<row|<cell|<strong|Hello>>|<cell|0>|<cell|10000>|<cell|>|<cell|<strong|Stat>
+    / <strong|StatR>>|<cell|10>|<cell|10010>>|<row|<cell|<strong|Error>>|<cell|>|<cell|10001>|<cell|>|<cell|<strong|List>
+    / <strong|ListR>>|<cell|11>|<cell|10011>>|<row|<cell|<strong|Ack>>|<cell|>|<cell|10002>|<cell|>|<cell|<strong|Create>
+    / <strong|Created>>|<cell|12>|<cell|10012>>|<row|<cell|>|<cell|>|<cell|>|<cell|>|<cell|<strong|Delete>>|<cell|13>|<cell|>>|<row|<cell|<strong|Attach>
+    / <strong|Attached>>|<cell|5>|<cell|10005>|<cell|>|<cell|<strong|Rename>>|<cell|14>|<cell|>>|<row|<cell|<strong|Send>
+    / <strong|Recieve>>|<cell|6>|<cell|10006>|<cell|>|<cell|<strong|Link>>|<cell|15>|<cell|>>|<row|<cell|<strong|Detach>
+    / <strong|Detached>>|<cell|7>|<cell|10007>|<cell|>|<cell|<strong|ReadLink>
+    / <strong|ReadLinkR>>|<cell|16>|<cell|10016>>|<row|<cell|<strong|Serve>>|<cell|8>|<cell|>|<cell|>|<cell|>|<cell|>|<cell|>>|<row|<cell|<strong|Incoming>>|<cell|>|<cell|10008>|<cell|>|<cell|>|<cell|>|<cell|>>|<row|<cell|<strong|Accept>>|<cell|9>|<cell|>|<cell|>|<cell|>|<cell|>|<cell|>>>>>
+  </indent>
+
+  <paragraph|Authentication & privileges>
+
+  <\indent>
+    <block|<tformat|<table|<row|<cell|message>|<cell|<math|\<uparrow\>>
+    id>|<cell|<math|\<downarrow\>> id>>|<row|<cell|<strong|Authenticate>>|<cell|30>|<cell|>>|<row|<cell|<strong|NewToken>
+    / <strong|NewTokenR>>|<cell|31>|<cell|10031>>>>>
+  </indent>
+
+  <subsubsection|Error messages><label|error-nums>
+
+  <\indent>
+    <block|<tformat|<table|<row|<cell|id>|<cell|cause>>|<row|<cell|1>|<cell|Incompatible
+    versions>>|<row|<cell|2>|<cell|Command/interface not
+    implemented>>|<row|<cell|3>|<cell|Invalid request (e.g. : out of
+    bounds)>>|<row|<cell|4>|<cell|Invalid handle>>|<row|<cell|5>|<cell|Attach
+    request rejected>>|<row|<cell|6>|<cell|Action impossible because object
+    is in use (cannot delete, ...)>>|<row|<cell|7>|<cell|No such object
+    (invalid path)>>|<row|<cell|8>|<cell|Could not resolve
+    link>>|<row|<cell|9>|<cell|Incorrect credentials>>|<row|<cell|10>|<cell|Unauthorized>>>>>
+  </indent>
+
+  <subsubsection|Object interfaces<label|interface-nums>>
+
+  <\indent>
+    <block|<tformat|<table|<row|<cell|id>|<cell|name>|<cell|must implement
+    messages>>|<row|<cell|0>|<cell|servable>|<cell|<strong|Serve>,
+    <strong|Accept>, <strong|Incoming>>>|<row|<cell|1>|<cell|NARP
+    service>|<cell|once attached, inside data is also NARP
+    protocol>>|<row|<cell|2>|<cell|non-NARP socket>|<cell|once attached,
+    inside data is arbitrary>>|<row|<cell|3>|<cell|enumerable>|<cell|<strong|List>,
+    <strong|ListR>>>|<row|<cell|4>|<cell|is symlink>|<cell|<strong|ReadLink>,
+    <strong|ReadLinkR>>>|<row|<cell|10>|<cell|file>|<cell|once attached, file
+    semantics>>|<row|<cell|11>|<cell|terminal>|<cell|once attached, terminal
+    semantics>>|<row|<cell|12>|<cell|graphics window>|<cell|once attached,
+    graphics semantics>>>>>
+  </indent>
+
+  <section|Architecture of a NARP implementation in OCaml or Haskell>
+
+  \;
+</body>
+
+<\initial>
+  <\collection>
+    <associate|page-medium|paper>
+  </collection>
+</initial>
+
+<\references>
+  <\collection>
+    <associate|auto-1|<tuple|1|1>>
+    <associate|auto-10|<tuple|2.5.3|3>>
+    <associate|auto-11|<tuple|2.5.4|4>>
+    <associate|auto-12|<tuple|2.6|4>>
+    <associate|auto-13|<tuple|2.7|4>>
+    <associate|auto-14|<tuple|2.8|4>>
+    <associate|auto-15|<tuple|2.8.1|4>>
+    <associate|auto-16|<tuple|2.8.2|4>>
+    <associate|auto-17|<tuple|2.8.3|4>>
+    <associate|auto-18|<tuple|2.8.4|5>>
+    <associate|auto-19|<tuple|2.8.5|5>>
+    <associate|auto-2|<tuple|2|1>>
+    <associate|auto-20|<tuple|2.8.6|5>>
+    <associate|auto-21|<tuple|3|5>>
+    <associate|auto-22|<tuple|3.1|5>>
+    <associate|auto-23|<tuple|3.2|5>>
+    <associate|auto-24|<tuple|3.3|6>>
+    <associate|auto-25|<tuple|3.3.0.1|6>>
+    <associate|auto-26|<tuple|3.3.0.2|6>>
+    <associate|auto-27|<tuple|3.3.0.3|7>>
+    <associate|auto-28|<tuple|3.3.0.4|7>>
+    <associate|auto-29|<tuple|3.3.0.5|7>>
+    <associate|auto-3|<tuple|2.1|1>>
+    <associate|auto-30|<tuple|3.3.0.6|7>>
+    <associate|auto-31|<tuple|3.3.0.7|7>>
+    <associate|auto-32|<tuple|3.3.0.8|8>>
+    <associate|auto-33|<tuple|3.3.0.9|8>>
+    <associate|auto-34|<tuple|3.3.0.10|8>>
+    <associate|auto-35|<tuple|3.3.0.11|8>>
+    <associate|auto-36|<tuple|3.3.0.12|8>>
+    <associate|auto-37|<tuple|3.3.0.13|8>>
+    <associate|auto-38|<tuple|3.3.0.14|8>>
+    <associate|auto-39|<tuple|3.3.0.15|8>>
+    <associate|auto-4|<tuple|2.2|2>>
+    <associate|auto-40|<tuple|3.3.0.16|8>>
+    <associate|auto-41|<tuple|3.3.0.17|9>>
+    <associate|auto-42|<tuple|3.3.0.18|9>>
+    <associate|auto-43|<tuple|3.3.0.19|9>>
+    <associate|auto-44|<tuple|3.3.0.20|9>>
+    <associate|auto-45|<tuple|3.3.0.21|9>>
+    <associate|auto-46|<tuple|3.3.0.22|9>>
+    <associate|auto-47|<tuple|3.3.0.23|10>>
+    <associate|auto-48|<tuple|3.4|10>>
+    <associate|auto-49|<tuple|3.5|10>>
+    <associate|auto-5|<tuple|2.3|2>>
+    <associate|auto-50|<tuple|3.5.0.24|10>>
+    <associate|auto-51|<tuple|3.5.0.25|10>>
+    <associate|auto-52|<tuple|3.5.0.26|10>>
+    <associate|auto-53|<tuple|3.6|10>>
+    <associate|auto-54|<tuple|3.7|10>>
+    <associate|auto-55|<tuple|3.7.1|10>>
+    <associate|auto-56|<tuple|3.7.2|10>>
+    <associate|auto-57|<tuple|3.8|11>>
+    <associate|auto-58|<tuple|3.8.1|11>>
+    <associate|auto-59|<tuple|3.8.2|11>>
+    <associate|auto-6|<tuple|2.4|3>>
+    <associate|auto-60|<tuple|3.9|11>>
+    <associate|auto-61|<tuple|3.10|?>>
+    <associate|auto-62|<tuple|3.10.1|?>>
+    <associate|auto-63|<tuple|3.10.1.1|?>>
+    <associate|auto-64|<tuple|3.10.1.2|?>>
+    <associate|auto-65|<tuple|3.10.2|?>>
+    <associate|auto-66|<tuple|3.10.3|?>>
+    <associate|auto-67|<tuple|4|?>>
+    <associate|auto-7|<tuple|2.5|3>>
+    <associate|auto-8|<tuple|2.5.1|3>>
+    <associate|auto-9|<tuple|2.5.2|3>>
+    <associate|error-nums|<tuple|3.10.2|?>>
+    <associate|footnote-1|<tuple|1|3>>
+    <associate|footnote-2|<tuple|2|?>>
+    <associate|footnr-1|<tuple|1|3>>
+    <associate|footnr-2|<tuple|2|?>>
+    <associate|interface-nums|<tuple|3.10.3|?>>
+    <associate|rev-sock|<tuple|2.4|3>>
+    <associate|type-nums|<tuple|3.10.1|?>>
+  </collection>
+</references>
+
+<\auxiliary>
+  <\collection>
+    <\associate|toc>
+      <vspace*|1fn><with|font-series|<quote|bold>|math-font-series|<quote|bold>|1<space|2spc>Introduction>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-1><vspace|0.5fn>
+
+      <vspace*|1fn><with|font-series|<quote|bold>|math-font-series|<quote|bold>|2<space|2spc>High-level
+      overview> <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-2><vspace|0.5fn>
+
+      <with|par-left|<quote|1tab>|2.1<space|2spc>The basic operations on
+      services and objects <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-3>>
+
+      <with|par-left|<quote|1tab>|2.2<space|2spc>The basics of the NARP
+      protocol <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-4>>
+
+      <with|par-left|<quote|1tab>|2.3<space|2spc>Recursion
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-5>>
+
+      <with|par-left|<quote|1tab>|2.4<space|2spc>Reverse object
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-6>>
+
+      <with|par-left|<quote|1tab>|2.5<space|2spc>Specific object types and
+      associated messages <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-7>>
+
+      <with|par-left|<quote|2tab>|2.5.1<space|2spc>Objects are sockets
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-8>>
+
+      <with|par-left|<quote|2tab>|2.5.2<space|2spc>File objects
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-9>>
+
+      <with|par-left|<quote|2tab>|2.5.3<space|2spc>User IO (terminals...)
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-10>>
+
+      <with|par-left|<quote|2tab>|2.5.4<space|2spc>Specific applications
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-11>>
+
+      <with|par-left|<quote|1tab>|2.6<space|2spc>Big messages
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-12>>
+
+      <with|par-left|<quote|1tab>|2.7<space|2spc>Permissions
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-13>>
+
+      <with|par-left|<quote|1tab>|2.8<space|2spc>Example NARP servers
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-14>>
+
+      <with|par-left|<quote|2tab>|2.8.1<space|2spc>Virtual NARP server (i.e.
+      NARP router) <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-15>>
+
+      <with|par-left|<quote|2tab>|2.8.2<space|2spc>NARP file server
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-16>>
+
+      <with|par-left|<quote|2tab>|2.8.3<space|2spc>NARP terminal/GUI server
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-17>>
+
+      <with|par-left|<quote|2tab>|2.8.4<space|2spc>NARP e-mail and newsgroup
+      server <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-18>>
+
+      <with|par-left|<quote|2tab>|2.8.5<space|2spc>NARP chat server
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-19>>
+
+      <with|par-left|<quote|2tab>|2.8.6<space|2spc>NARP applicative server
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-20>>
+
+      <vspace*|1fn><with|font-series|<quote|bold>|math-font-series|<quote|bold>|3<space|2spc>Specifics
+      of the NARP protocol> <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-21><vspace|0.5fn>
+
+      <with|par-left|<quote|1tab>|3.1<space|2spc>Protocol description format
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-22>>
+
+      <with|par-left|<quote|1tab>|3.2<space|2spc>Basic message format
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-23>>
+
+      <with|par-left|<quote|1tab>|3.3<space|2spc>Message list for core NARP
+      protocol <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-24>>
+
+      <with|par-left|<quote|4tab>|Hello<with|mode|<quote|math>|\<uparrow\>\<downarrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-25><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Error<with|mode|<quote|math>|\<downarrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-26><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Ack<with|mode|<quote|math>|\<downarrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-27><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Stat<with|mode|<quote|math>|\<uparrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-28><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|StatR<with|mode|<quote|math>|\<downarrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-29><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|List<with|mode|<quote|math>|\<uparrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-30><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|ListR<with|mode|<quote|math>|\<downarrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-31><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Attach<with|mode|<quote|math>|\<uparrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-32><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Attached<with|mode|<quote|math>|\<downarrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-33><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Send<with|mode|<quote|math>|\<uparrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-34><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Recieve<with|mode|<quote|math>|\<downarrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-35><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Detach<with|mode|<quote|math>|\<uparrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-36><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Detached<with|mode|<quote|math>|\<downarrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-37><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|<with|font-series|<quote|bold>|math-font-series|<quote|bold>|Create<with|mode|<quote|math>|\<uparrow\>>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-38><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Created<with|mode|<quote|math>|\<downarrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-39><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Delete<with|mode|<quote|math>|\<uparrow\>><with|font-family|<quote|tt>|language|<quote|verbatim>|>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-40><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Link<with|mode|<quote|math>|\<uparrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-41><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|ReadLink<with|mode|<quote|math>|\<uparrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-42><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|ReadLinkR<with|mode|<quote|math>|\<downarrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-43><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Serve<with|mode|<quote|math>|\<uparrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-44><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Incoming<with|mode|<quote|math>|\<downarrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-45><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|Accept<with|mode|<quote|math>|\<uparrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-46><vspace|0.15fn>>
+
+      <with|par-left|<quote|1tab>|3.4<space|2spc>Big message protocol
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-47>>
+
+      <with|par-left|<quote|1tab>|3.5<space|2spc>Authentification and rights
+      managment commands <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-48>>
+
+      <with|par-left|<quote|4tab>|Authenticate<with|mode|<quote|math>|\<uparrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-49><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|NewToken<with|mode|<quote|math>|\<uparrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-50><vspace|0.15fn>>
+
+      <with|par-left|<quote|4tab>|NewTokenR<with|mode|<quote|math>|\<downarrow\>>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-51><vspace|0.15fn>>
+
+      <with|par-left|<quote|1tab>|3.6<space|2spc>File protocol
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-52>>
+
+      <with|par-left|<quote|1tab>|3.7<space|2spc>UI protocols
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-53>>
+
+      <with|par-left|<quote|2tab>|3.7.1<space|2spc>Terminal protocol
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-54>>
+
+      <with|par-left|<quote|2tab>|3.7.2<space|2spc>Graphical user interface
+      protocol <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-55>>
+
+      <with|par-left|<quote|1tab>|3.8<space|2spc>Communication protocols
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-56>>
+
+      <with|par-left|<quote|2tab>|3.8.1<space|2spc>Email and newsgroups
+      protocol <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-57>>
+
+      <with|par-left|<quote|2tab>|3.8.2<space|2spc>Instant messaging protocol
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-58>>
+
+      <with|par-left|<quote|1tab>|3.9<space|2spc>Other protocols
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-59>>
+
+      <vspace*|1fn><with|font-series|<quote|bold>|math-font-series|<quote|bold>|4<space|2spc>Architecture
+      of a NARP implementation in OCaml or Haskell>
+      <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
+      <no-break><pageref|auto-60><vspace|0.5fn>
+    </associate>
+  </collection>
+</auxiliary>
\ No newline at end of file