summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--.gitignore4
-rw-r--r--doc/narp.pdfbin0 -> 123463 bytes
-rw-r--r--doc/narp.tm1127
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
Binary files differ
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