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.