path: root/doc/narp.tm

<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,
    IRC, specfic web services, ...
  </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 a client/server protocol 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
    (possibly 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>, <verbatim|delete>, <verbatim|rename>,
    <verbatim|link> : requests the creation or modification of a ressource in
    the namespace
  </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 in specific situations
    where too many levels of recursion cause a performance issue.
  </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 possibility 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. Research is yet to be done on this specific subject.

  <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|Reliability concerns>

  The NARP protocol relies on the fact that when transmitting a message, the
  other end will recieve it. It is nevertheless recommended that NARP
  implementations support the repeating of messages if an expected
  acknowlegment has not arrived after a given delay.

  <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|...>|<cell|element type>>|<row|<cell|element
  description>|<cell|element description>|<cell|...>|<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 recursive send/recieve messages. Other
  messages usually imply some kind of action or getting of information,
  therefore an acknowlegment or an error is usually sent as a response.

  <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\>>>Response to the <strong|Stat> message.

  <\indent>
    <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\>>>Response to the <strong|List> message.

  <\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\>>>Response to the <strong|Attach>
  command.

  <\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>>>>>

    This message does not expect a response.
  </indent>

  <paragraph|Recieve<math|\<downarrow\>>>

  <\indent>
    Spontaneous server message indicating some data is sent by an attached
    ressource. This message does not expect a response.

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

    This message does not expect a response.
  </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\>>>Response to the <strong|Create>
  command.

  <\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\>>>Response to the <strong|ReadLink>
  message.

  <\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>|<cell|array(int32)>>|<row|<cell|header>|<cell|request
    ID>|<cell|path>|<cell|announced interfaces>>>>>

    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 <strong|Incoming> and
    <strong|Detach> 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.

    The <em|announced interfaces> serves to answer <strong|Stat> messages on
    the object while we are serving it.
  </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>

  <paragraph|Unbox<math|\<uparrow\>>>

  <\indent>
    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|int32>>|<row|<cell|header>|<cell|request
    ID>|<cell|outer handle>|<cell|inner handle>>>>>

    Consider the handle <em|outer handle> as a NARP protocol service, and
    associate a handle in the outer layer to the handle of the inner layer
    with handle <em|inner handle>.

    Example : in connection A we have a connection open on handle 5 which
    contains NARP data that we will call B, and in connection B we have
    another connection open on handle 7. Issuing a Unbox(id, 5, 7) request on
    A will lead to the server creating a handle (say 12) where sending
    corresponds to sending a message to handle 7 on connection B, and such
    that all messages recieved on handle 5 (ie on connection B) are filtered
    and messages whose destination is handle 7 on connection B are removed
    from the stream and issued on handle 12 of connection A instead.

    The answer to such a request is an <strong|Attached> response giving a
    handle to the unboxed connection.

    Systematically unboxing open connections may lead in some cases to the
    network infrastructure being able to do simplifications in the
    interconnections. In other cases it may result to useless overhead on the
    server side : in such a case the server may refuse an unbox request.
  </indent>

  <paragraph|Plug<math|\<uparrow\>>>

  <\indent>
    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|int32>>|<row|<cell|header>|<cell|request
    ID>|<cell|handle A>|<cell|handle B>>>>>

    Ask the server to redirect all messages recieved on handle A to handle B
    and all mesages recieved on handle B to handle A. The messages recieved
    on either handle are not sent to the client anymore.

    The answer messages are standard <strong|Ack>/<strong|Error> messages.
  </indent>

  <paragraph|Unplug<math|\<uparrow\>>>

  <\indent>
    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|int32>>|<row|<cell|header>|<cell|request
    ID>|<cell|handle A>|<cell|handle B>>>>>

    Undoes a plugging.
  </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\>>>Response to the <strong|NewToken>
  message.

  <\indent>
    <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|message
    ID>|<cell|token>>>>>
  </indent>

  TODO : request account creation, manage user groups and ACLs, ...

  <subsection|File protocol>

  Client messages [50,100) ; server messages [10050,10100). TODO

  <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|<strong|Unbox>>|<cell|20>|<cell|>>|<row|<cell|<strong|Accept>>|<cell|9>|<cell|>|<cell|>|<cell|<strong|Plug>>|<cell|21>|<cell|>>|<row|<cell|>|<cell|>|<cell|>|<cell|>|<cell|<strong|Unplug>>|<cell|22>|<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|enumerable>|<cell|<strong|List>,
    <strong|ListR>>>|<row|<cell|2>|<cell|is symlink>|<cell|<strong|ReadLink>,
    <strong|ReadLinkR>>>|<row|<cell|>|<cell|>|<cell|>>|<row|<cell|9>|<cell|non-NARP
    inside>|<cell|once attached, inside data is
    arbitrary>>|<row|<cell|10>|<cell|NARP service>|<cell|once attached,
    inside data is a NARP service (ie has objects,
    ...)>>|<row|<cell|11>|<cell|NARP unbox>|<cell|once attached,
    <strong|Unbox> command supported>>|<row|<cell|12>|<cell|NARP
    plug>|<cell|once attached, <strong|Plug> and <strong|Unplug> commands
    supported>>|<row|<cell|>|<cell|>|<cell|>>|<row|<cell|20>|<cell|file>|<cell|once
    attached, file semantics>>|<row|<cell|21>|<cell|terminal>|<cell|once
    attached, terminal semantics>>|<row|<cell|22>|<cell|graphics
    window>|<cell|once attached, GUI semantics>>>>> \ 
  </indent>

  <paragraph|Servable>This interface specifies that the object is currently
  an empty object waiting for someone to issue a <strong|Serve> command on
  it, providing it with an implementation of some interfaces.

  <paragraph|non-NARP inside>This interfaces indicates that once attached to
  the object, the messages sent/recieved to it are not supposed to be NARP
  format but any arbitrary format. If this interface is not specified, then
  it is expected that the messages transmitted will follow the general NARP
  protocol (message format, standard hello/ack/error messages).

  <paragraph|NARP service>This interface indicates that once attached to the
  object, one can have access to a new NARP namespace where at least the
  following operations are supported : <strong|Stat>, <strong|Attach>,
  <strong|Send>, <strong|Recieve>, <strong|Detach>. Additionnal messages may
  or may not be supported.

  <section|Architecture of a NARP implementation in OCaml or Haskell>

  An asynchronous implementation can be easily programmed in functionnal
  languages such as OCaml or Haskell, using closures as continuations for
  <em|what to do when a (response) message arrives>.

  TODO

  <section|Using NARP to design an Operating System>

  When designing the NARP protocol, we had in mind that it would be possible
  to use it in a new operating system design at many levels : access to
  devices, process management, memory management, filesystems, IPC, GUI, ...

  Kernel helpers could be developped so that a part of the NARP multiplexing
  and demultiplexing takes place in kernel land, before messages are passed
  to userspace. For instance, this would allow the simplification of useless
  mux-demux chains taking place on the same machine. The mux-demux helper can
  be implemented via the <strong|Unbox> protocol message, handled at the
  level of the root stream of NARP communication with the kernel. Another
  possible helper would be to map a virtual memory region to a NARP ressource
  implementing a standard filing protocol, much like memory mapped files in
  standard OSes (only this would work with arbitrary ressources).

  TODO
</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|3>>
    <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.9|4>>
    <associate|auto-16|<tuple|2.9.1|4>>
    <associate|auto-17|<tuple|2.9.2|4>>
    <associate|auto-18|<tuple|2.9.3|4>>
    <associate|auto-19|<tuple|2.9.4|5>>
    <associate|auto-2|<tuple|2|1>>
    <associate|auto-20|<tuple|2.9.5|5>>
    <associate|auto-21|<tuple|2.9.6|5>>
    <associate|auto-22|<tuple|3|5>>
    <associate|auto-23|<tuple|3.1|5>>
    <associate|auto-24|<tuple|3.2|5>>
    <associate|auto-25|<tuple|3.3|6>>
    <associate|auto-26|<tuple|3.3.0.1|6>>
    <associate|auto-27|<tuple|3.3.0.2|6>>
    <associate|auto-28|<tuple|3.3.0.3|6>>
    <associate|auto-29|<tuple|3.3.0.4|6>>
    <associate|auto-3|<tuple|2.1|1>>
    <associate|auto-30|<tuple|3.3.0.5|6>>
    <associate|auto-31|<tuple|3.3.0.6|7>>
    <associate|auto-32|<tuple|3.3.0.7|7>>
    <associate|auto-33|<tuple|3.3.0.8|7>>
    <associate|auto-34|<tuple|3.3.0.9|7>>
    <associate|auto-35|<tuple|3.3.0.10|7>>
    <associate|auto-36|<tuple|3.3.0.11|7>>
    <associate|auto-37|<tuple|3.3.0.12|7>>
    <associate|auto-38|<tuple|3.3.0.13|8>>
    <associate|auto-39|<tuple|3.3.0.14|8>>
    <associate|auto-4|<tuple|2.2|2>>
    <associate|auto-40|<tuple|3.3.0.15|8>>
    <associate|auto-41|<tuple|3.3.0.16|8>>
    <associate|auto-42|<tuple|3.3.0.17|8>>
    <associate|auto-43|<tuple|3.3.0.18|8>>
    <associate|auto-44|<tuple|3.3.0.19|8>>
    <associate|auto-45|<tuple|3.3.0.20|9>>
    <associate|auto-46|<tuple|3.3.0.21|9>>
    <associate|auto-47|<tuple|3.3.0.22|9>>
    <associate|auto-48|<tuple|3.3.0.23|9>>
    <associate|auto-49|<tuple|3.3.0.24|9>>
    <associate|auto-5|<tuple|2.3|2>>
    <associate|auto-50|<tuple|3.3.0.25|9>>
    <associate|auto-51|<tuple|3.3.0.26|9>>
    <associate|auto-52|<tuple|3.4|10>>
    <associate|auto-53|<tuple|3.5|10>>
    <associate|auto-54|<tuple|3.5.0.27|10>>
    <associate|auto-55|<tuple|3.5.0.28|10>>
    <associate|auto-56|<tuple|3.5.0.29|10>>
    <associate|auto-57|<tuple|3.6|10>>
    <associate|auto-58|<tuple|3.7|10>>
    <associate|auto-59|<tuple|3.7.1|10>>
    <associate|auto-6|<tuple|2.4|2>>
    <associate|auto-60|<tuple|3.7.2|10>>
    <associate|auto-61|<tuple|3.8|10>>
    <associate|auto-62|<tuple|3.8.1|10>>
    <associate|auto-63|<tuple|3.8.2|11>>
    <associate|auto-64|<tuple|3.9|11>>
    <associate|auto-65|<tuple|3.10|11>>
    <associate|auto-66|<tuple|3.10.1|11>>
    <associate|auto-67|<tuple|3.10.1.1|11>>
    <associate|auto-68|<tuple|3.10.1.2|11>>
    <associate|auto-69|<tuple|3.10.2|11>>
    <associate|auto-7|<tuple|2.5|3>>
    <associate|auto-70|<tuple|3.10.3|12>>
    <associate|auto-71|<tuple|3.10.3.1|12>>
    <associate|auto-72|<tuple|3.10.3.2|12>>
    <associate|auto-73|<tuple|3.10.3.3|?>>
    <associate|auto-74|<tuple|4|?>>
    <associate|auto-75|<tuple|5|?>>
    <associate|auto-8|<tuple|2.5.1|3>>
    <associate|auto-9|<tuple|2.5.2|3>>
    <associate|error-nums|<tuple|3.10.2|11>>
    <associate|footnote-1|<tuple|1|2>>
    <associate|footnote-2|<tuple|2|?>>
    <associate|footnr-1|<tuple|1|2>>
    <associate|footnr-2|<tuple|2|?>>
    <associate|interface-nums|<tuple|3.10.3|11>>
    <associate|rev-sock|<tuple|2.4|2>>
    <associate|type-nums|<tuple|3.10.1|11>>
  </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>Reliability concerns
      <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|1tab>|2.9<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-15>>

      <with|par-left|<quote|2tab>|2.9.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-16>>

      <with|par-left|<quote|2tab>|2.9.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-17>>

      <with|par-left|<quote|2tab>|2.9.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-18>>

      <with|par-left|<quote|2tab>|2.9.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-19>>

      <with|par-left|<quote|2tab>|2.9.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-20>>

      <with|par-left|<quote|2tab>|2.9.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-21>>

      <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-22><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-23>>

      <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-24>>

      <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-25>>

      <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-26><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-27><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-28><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-29><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-30><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-31><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-32><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-33><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-34><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-35><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-36><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-37><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-38><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-39><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-40><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-41><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-42><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-43><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-44><vspace|0.15fn>>

      <with|par-left|<quote|4tab>|Rename<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-45><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-46><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-47><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-48><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-49>>

      <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-50>>

      <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-51><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-52><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-53><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-54>>

      <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-55>>

      <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-56>>

      <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-57>>

      <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-58>>

      <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-59>>

      <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-60>>

      <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-61>>

      <with|par-left|<quote|1tab>|3.10<space|2spc>Table of IDs
      <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-62>>

      <with|par-left|<quote|2tab>|3.10.1<space|2spc>Message types
      <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-63>>

      <with|par-left|<quote|4tab>|Base 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-64><vspace|0.15fn>>

      <with|par-left|<quote|4tab>|Authentication & privileges
      <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-65><vspace|0.15fn>>

      <with|par-left|<quote|2tab>|3.10.2<space|2spc>Error 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-66>>

      <with|par-left|<quote|2tab>|3.10.3<space|2spc>Object interfaces
      <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-67>>

      <with|par-left|<quote|4tab>|Servable
      <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-68><vspace|0.15fn>>

      <with|par-left|<quote|4tab>|non-NARP inside
      <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-69><vspace|0.15fn>>

      <with|par-left|<quote|4tab>|NARP service
      <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-70><vspace|0.15fn>>

      <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-71><vspace|0.5fn>

      <vspace*|1fn><with|font-series|<quote|bold>|math-font-series|<quote|bold>|5<space|2spc>Using
      NARP to design an Operating System>
      <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-72><vspace|0.5fn>
    </associate>
  </collection>
</auxiliary>