At 4/29/00 08:29 PM (Saturday), Bill Karwin wrote:

>My opinion is motivated by prioritization of InterBase features. I admit
>that's out of place on this list. My apologies.

My apologies, also, and I think we should drop this for now. Let me wrap up
my perspective, though.

All this does tie in to architecture, at least a bit. My reason for
bringing it up was the previous discussion of plug-ins. I saw the
architectural addition of plug-ins as being a great opportunity for
Interbase to accommodate encryption without having to rearrange priorities
too much. In fact, if the plug-in API were just designed but no plug-in
actually implemented by ISC-IV then those who have a need for the
encryption could implement/deploy it independently. I see this as a
splendid solution for all.

My reason for getting into the scenarios was to document some rationale for
following through on this idea. Yes, I agree that most security conscious
sites will implement a more comprehensive, VPN-type solution. But there are
some situations where an Interbase-specific alternative fits the bill.

For example, we are now developing an application with Interbase as the
embedded database (about as appropriate a use of Interbase as there can
be). Our client will sell the software product to customers who are not
always technically astute. Our client recently asked us about whether the
client-server communication is protected in any way. We told them that it
was not and that we assumed the ultimate customer would implement as much
TCP/IP security as they needed to address this issue. (Our standard party
line, which is ISC's standard party line.) However, they still expect some
customers to have this on their sales requirement checklist. To hear that
we have not addressed it AT ALL will be a sales barrier we would rather not
confront. If we could just say that there is some level of protection we
would can eliminate the barrier.