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