At 3:48 PM 1/22/95, Simon E Spero wrote:
>Having support for this kind of negotiation in the protocol seems useful to
>me - it doesn't add much to the implementation, and does address some privacy
>concerns.
How does this sort of negotiating in real-time work:
a. when the user is interacting with a caching server and not the 'owner'
of the data?
b. when the net is congested and each protocol-exchange suffers serious
latencies, thereby adding considerably to overall session "effort" and
time?
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?
(Speech) Any particular change to any particular protocol may well
be cheap to write in the spec and even cheap to write in the code. But
what is the cost of supporting it, operationally, throughout the vagaries
of the Internet?
(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.
d/
--------------------
Dave Crocker
Brandenburg Consulting +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 dcrocker@mordor.stanford.edu