If the data is cached, and was provided by the originating server under
the condition that logging information be provided to that originating
server, then the caching server must request and require such logging
privileges as required by that agreement.
>b. when the net is congested and each protocol-exchange suffers serious
>latencies, thereby adding considerably to overall session "effort" and
>time?
[hey - real time networks don't get congested - otherwise ATM would have
a way of dealing with it :)]
Negotiations like this only cause extra-latency in the event of negotiation
failure- for example, if a server requires full third-party log communication
rights, and the client refuses to grant such rights. In all other cases,
pipe-lining prevents the latency problem.
>c. getting at the data through non-interactive, non-web means? Do we get
>to re-invent security mechanisms for each method of conveying the same
>data?
I'm not quite sure I understand this (or at least I'm missing the subtext).
If options relating to the disposition of logging requests and licence display
don't belong in the application layer, and given your advocacy of the
traditional ARPA 5 layer model of networking (Physical-Link-Network-Transport-
Application), the only place to put such options would be in either TCP-NG or
IP-NG. I know that IP-NG has lots of wasted bits in the address space, but it's
a bit early to start overloading them for application semantics.
>
> (more speeh) Stating this differently: I strongly advise against
>the tendency to "put security into the protocol" namely http, and think
>much harder about puting security around the data. http-level mechanisms
>can be VERY useful to determining the security required by the object, but
>that is different from acturally having the security mechanism, itself, in
>the protocol.
I'm not sure I understand this paragraph (and I'm sure that this time it's my
fault). Could you explain a bit more about what you mean by 'security around
the data'.
Simon