Implementation Guidelines
Some general rules have been
followed in the implementation. They are not strict, but should
be respected:
No Sessions
There are no sessions between client and
server. The client may retain state, (i.e. it knows which path it
has followed) but the server may not. Each time a link is
followed, a connection with the server is established, the
request made, the server's response sent back and the connection
closed. Therefore there is no way that the server should know
what it did with a client before the current request.
There is an exception to this in the access protection area,
which is an optimisation and not a breach of the rule: normally,
for protected data, the client should send its access validation
for each request. This may be lengthy if several documents are
retrieved in a row from the same protected server. Thus the
server may choose to transmit an access key to the client on the
first contact, and keep the access validation and key locally.
The client uses the access key in its next request. Such keys
should expire in reasonable time.
Another problem with having no sessions is when very long
documents need to be transmitted: the client will normally not
display anything before having received the entire document. This
is disconcerting to the user. The server, knowing how long the
document is, may decide to synthesise local nodes with parts,
each part containing a link to the next part, and transmit only
the first part (this may go on in parallel). The client may not
be able to handle a very long document anyway.
Short UDIs
UDIs should be kept short and devoid of
information that indicates the mechanism by which the document is
retrieved. (in the theoretically clean implementation, the
protocol information should not be present).
The motivation is that when a document changes implementation
(e.g. from being a file to being part of a data base, or by
moving to a different location, the anchors pointing to it should
not have to change.
UDIs should only specify the contents.
The document itself decides what it is and how to produce its
contents. Normal documents contain their own text. Indexes
contain a cover page.
Indirect documents contain the mechanism for finding the real
thing.
See data model
Ignore silently
Any information a client or server does
not understand it should ignore without complaints. The
motivation is forward compatibility. Commands sent by new
browsers to old servers should be ignored by those servers. In
any case, from the next version, client and server always send
the version number of the HTTP protocol they use, so the more
recent of the two can choose to downgrade to the older version.
See from version
to version
Protect investment in old links
Links made to documents
should not have to be changed when the location or the
implementation of the document changes. This ideal situation
cannot be implemented, but one can come close, by ensuring that
as little as possible information about implementation is
recorded in the UDI. Relocation can be handled by an indirect
node of the forwarding type, change of implementation by one of
the query type.