[1884] in WWW Security List Archive
Re: Interoperability question (s)...
daemon@ATHENA.MIT.EDU (Charlie Kaufman/Iris)
Tue Apr 23 18:14:08 1996
To: Viveca Noble <vnoble@noble.tamu.edu>
Cc: Web Transaction Security <Www-Security@ns2.rutgers.edu>
From: Charlie Kaufman/Iris <Charlie_Kaufman/Iris.IRIS@iris.com>
Date: 22 Apr 96 16:23:15 EDT
Errors-To: owner-www-security@ns2.rutgers.edu
>What is the difference, if any, between the terms
>interoperability and compatibility?
Compatibility is a weasle word that can mean almost anything - or nothing at
all - unless constrained with more information. Two species are often called
compatible if they can coexist in the same geographical area without one wiping
out the other. Two protocols can be called compatible if they can both run on
the same wire without tripping over one another. Nothing is implied about any
interaction between the two. Some people mean a stronger relationship when they
say compatible, but you can't count on it unless the term is qualified.
Interoperable is a stronger term: in a networking context, it means that the
two entities can usefully exchange data. The term can be weak because they may
only interoperate in the presence of a gateway or they might only interoperate
with a minimal subset of the functionality of either, but interoperability does
say something.
>I am asking because in a number of the papers that I have
>read about WWW security, interoperability has been identified
>as an unresolved issue. I have taken this to mean that there
>is a problem communicating between different security
>protocols, schemes, etc. e.g. SSL secured transactions
>present a problem when received by SHTTP secured servers.
Unresolved would imply that there remains work to be done. This is perhaps
overoptimistic. I'd say the problem has been resolved negatively. The two
protocols do not interoperate. If this is a problem, there are several possible
approaches. The world could settle on one scheme and abandon the other. This
may be desireable, but it is unlikely. A client could speak both protocols and
thus communicate with either flavor of server; a server could speak both
protocols and thus communicate with either flavor of client. It is conceivable
that one could build a gateway that did protocol translation between the two
protocols, though the security gained thereby would be questionable. I suspect
people are working on all of the above. The world will continue to be an in
teresting place.
>One of my professors seems to believe that this is not a problem
>because CGIs or APIs can be used to overcome any potential
>problems that may arise from the previously decscribed scenario.
Not be a problem for whom? This is a recipe for implementing both protocols
under a layer that hides the details from the calling application and from the
user. This can be a reasonable thing to do when the functionality difference
between the two protocols is small and/or irrelevant to the application. It
solves the problem for the user and perhaps the application designer, but not
for the person implementing the API. That person still has to implement both
protocols or give up interoperability.
Does this help?
--Charlie Kaufman
(charlie_kaufman@iris.com)
