Clarification on cacheability

Heya,

Background:
I'm working with the WAP folk on their end to end security proposal.
One of the pieces of this is the concept of a navigation document.
This navdoc aims to provide functionality like the 305/306 were
intended to( but ended up not).  In short, the navdoc is to be
returned when accessing a resource that requires an alternate
proxy or path which may include various, lets say, other infrastructure.

So, the question we have come to is what HTTP response code should
be returned by a server when the navdoc is returned (instead of
the resource itself)?

When the client receives a navigation document, instead of the content
resource it actually asked for, it is supposed to interpret the navdoc
and perform the necessary steps such as connect to X proxy, hang up
and dial a different PPP serve, etc..  Then it essentially retries the
request through that new chain.

The current plan is to use 200 OK as the response code for simplicity
and cacheability.

I don't necessarily think this is the best way to go, so I have 
been advocating using either an existing 3xx code or a new 3xx code.
The only problem using a 3xx code is cacheability.   There are
two sections of the HTTP draft which seem conflicting on this.

Section 6.1 says that any unknown 3xx header must be treated
as 300, but NOT cached.
Section 13.4 seems to impy that if you have a cache-control: 
header then you may cache it.
These sections are quoted at the bottom of this message.

Question:
So, my question essentially comes down to this:
If I invent a new 3xx status code, or overload an existing 3xx
code but I include a cache-control: header to explicitly
allow caching, can a cache cache the results?

Section 6.1
HTTP status codes are extensible. HTTP applications are not required to
understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understand
the class of any status code, as indicated by the first digit, and treat any
unrecognized response as being equivalent to the x00 status code of that
class, with the exception that an unrecognized response MUST NOT be cached.
For example, if an unrecognized status code of 431 is received by the
client, it can safely assume that there was something wrong with its request
and treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned with the
response, since that entity is likely to include human- readable information
which will explain the unusual status. 

section 13.4
A response received with any other status code (e.g. status codes 302 
   and 307) MUST NOT be returned in a reply to a subsequent request 
   unless there are cache-control directives or another header(s) that 
   explicitly allow it. For example, these include the following: an 
   Expires header (section 14.21); a "max-age", "s-maxage",  "must- 
   revalidate", "proxy-revalidate", "public" or "private" cache-control 
   directive (section 14.9). 

---
Josh Cohen