An RSF-rendered view may be allocated one or more (globally) unique view tokens - currently a 24-character string of printable characters generated by the EighteenIDGenerator.

At the moment, there are two (independent) tokens, the flowtoken, being a unique key for any particular 'flow instance' that this view is participating in, and the errortoken, which is a key for any error state (messages and rejected user values).

Reliance on "sessions" as defining a scope for storage, whether HttpSessions or otherwise, which is upsettingly almost ubiquitous in webapps, simply does not match the model defined by the web browser tool on everyone's desktop. This browser has all sorts of affordances which it is unreasonable (although often surprisingly effective) to tell users "not to use" for certain pages, including navigating using the "back" button, bookmarking arbitrary pages indefinitely, or "forking" multiple browser windows from the same links.

Whilst many users are quite accustomed (with experience) to the sorts of disasters that can result from "misusing" their browsers, there's not really any excuse for not designing apps that are as foolproof and free of fragility as possible - RSF tries to impose the minimum burden on the programmer in helping with this task.

The view token, a string stored in the base ViewParameters object, is used as an index into a pool of state maintained by RSF, indexing a TokenRequestState object. The content and strategy behind this storage is discussed on a separate page on State in RSF.

During the rendering of each page, renderer and component producer are aware of both the incoming token (that which appears in the request URL) and the outgoing token which will be rendered in outgoing links from the rendering page, and may enter state under the (some transferred from the old taken) to "get ready" for the next request arriving from the client.