> Part of the charter of this working group proposes
> to document current practice and current practice is that there are many,
> often non-interoperable, caching solutions out there which would benefit
> both from documentation and standardization work.
hmmm... one sure-fire way for a working group to get into trouble is
for it to try to document current practice at the same time it's trying
to define what should be the practice. people in the group tend to
get the two confused and the result is usually neither an improvement
over the current practice, nor an accurate description of current practice,
I have no problem with documenting current practice, as long as the
document and the authors are clear that they are describing current
practice and not a representation of how things *should* work.
But documenting current practice isn't interesting to most WG members -
they tend to want to do new work.
> So, if you can accept
> that we are talking about intermediaries as referring to *all* entities
> holding replicated copies of an original, then this fits well into your
> above scenario.
"intermediary" seems like an odd term for what could be called an
"origin server" in HTTP jargon. I think it would be clearer to
use the term to describe something that appears in the signal
path between client and origin server.
One reason why the term can be confusing is that with URI resolution
there doesn't have to be a single origin server for a URI - an update
can be simultaneously posted from the source to several origin
servers, or to a different origin server for each update. In this
scenario, which servers are the intermediaries?
Keith
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:25 MST