diff --git a/README.md b/README.md
index 000e9895a..ae69ea991 100644
--- a/README.md
+++ b/README.md
@@ -200,42 +200,28 @@ routeWithAuth := NewAuthRoute("/index", "GET" ProcessorFunc, true, Authendicator
 The caching layer for HTTP routes is specified per Route.
 
 ```go
+// routeCache is the builder needed to build a cache for the corresponding route
 type routeCache struct {
-	// cache is the cache implementation to be used
-	cache cache.Cache
-	// ttl is the time to live for all cached objects in seconds
-	ttl int64
-	// instant is the timing function for the cache expiry calculations
-	instant TimeInstant
-	// minAge specifies the minimum amount of max-age header value for client cache-control requests in seconds
-	minAge int64
-	// max-fresh specifies the maximum amount of min-fresh header value for client cache-control requests in seconds
-	maxFresh int64
-	// staleResponse specifies if the server is willing to send stale responses
-	// if a new response could not be generated for any reason
-	staleResponse bool
+	// cache is the ttl cache implementation to be used
+	cache cache.TTLCache
+	// age specifies the minimum and maximum amount for max-age and min-fresh header values respectively
+	// regarding the client cache-control requests in seconds
+	age age
 }
 ```
 
 #### server cache
 - The **cache key** is based on the route path and the url request parameters.
 - The server caches only **GET requests**.
-- The server implementation must specify a **Time to Live policy** upon construction.
+- The server implementation must specify **Age** parameters upon construction.
+- Age with **Min=0** and **Max=0** effectively disables caching
 - The route should return always the most fresh object instance.
 - An **ETag header** must be always in responses that are part of the cache, representing the hash of the response.
 - Requests within the time-to-live threshold, will be served from the cache. 
 Otherwise the request will be handled as usual by the route processor function. 
 The resulting response will be cached for future requests.
-- Requests that cannot be processed due to any kind of error, but are found in the cache,
+- Requests where the client control header requirements cannot be met i.e. **very low max-age** or **very high min-fresh** parameters,
 will be returned to the client with a `Warning` header present in the response. 
-ONLY IF : this option is specified in the server with the `staleResponse` parameter set to `true`
-
-```
-Note : The server is unaware of the cache time-to-live policy itself. 
-The cache might evict entries based on it's internal configuration.
-This is transparent to the server. As long as a key cannot be found in the cache, 
-the server will execute the route processor function and fill the corresponding cache entry
-```
 
 ```
 Note : When a cache is used, the handler execution might be skipped.
@@ -255,10 +241,7 @@ This is to avoid chatty clients with no cache control policy (or very aggressive
 returns the cached instance if the time left for expiration is lower than the provided parameter.
 This parameter is bounded from above by the server option `maxFresh`.
 This is to avoid chatty clients with no cache control policy (or very aggressive min-fresh policy) to effectively disable the cache
-- `max-stale=?`
- 
-returns the cached instance, even if it has expired within the provided bound by the client.
-This response should always be accompanied by a `must-revalidate` response header.
+
 - `no-cache` / `no-store`
 
 returns a new response to the client by executing the route processing function.