> Oh-oh.  What exactly are you uncomfortable with? (Roy, please answer
> this too)
> - representation resources being first class objects with their own
>   URIs?

Okay -- representation resources are resources too.

> - a response from the representation resource with URI
>   TheProject.en.html being included in a response to a request on
>   the resource with URI TheProject?

Okay -- necessary for older clients and saves second request in common case.

> - the fact that reactive negotiation, which is done with a request
>   on the representation resource URI TheProject.en.html, necessitates,
>   for efficiency reasons, the sharing of cache slots?

Ummm, depends on what you mean by cache slots.  The cache key is the
Method+Request-URI (regardless of what was returned in URI) for
security reasons.  The cache slot pointed to by the key should contain
the request modifiers/vary information and metainfo necessary for
cache updates, and point to each of the cached responses.  Right?

> - having two blocks of headers in the preemptive response?

Makes me a bit queezy.  Keep in mind that a 1xx response can't be
sent to 1.0 clients, so it is difficult to transition this as an

> - the information in the URI header being cachable separately?

I'd prefer just making the URI header information correspond
to the Method+Request-URI cache key and not allow it to change per
representation returned.  That way, it can be in the single response.

> - something else?
> I wonder if it would make you less uncomfortable if I go back to my
> old scheme in which the Representations: (used to be URI:) header has
> its own fields to control caching.  As I explained before, I feel that
> it is necessary to allow service authors to control caching of the
> Representations: headers independent of the caching of the
> representation resource responses.

Any chance we can make that "Reps:"?  Hmmm, how about "More:"?
Or "Variants" or "Alternates".  It is really hard to say 5 syllable
words while giving a presentation.