On 11/12/2010 1:45 PM, Alex Peshkoff wrote:

>
>> In theory, yes. But he's going to have to get a fixed IP out of his ISP
>> to make that work. If he figures out how to do that, ask him to explain
>> how he did it...
> I have not tried it myself, but on site of my ISP I see 100 rubles (~
> $3) for getting fixed IP and same payment ($3) per month for it.
> But even if not - ISPs typically provide dynamic IP from known range. We
> may specify that range.

You are dealing with a capitalist ISP. Here, we have Verizon.

Which reminds me of joke about the old Soviet Union about little Natasha
asked by her teacher to explain to her foreign visitors the difference
between capitalism. "Under capitalism," little Natasha explained, "man
suffered from man's inhumanity to man. Under socialism, it's the other
way around."

So if you'd be so kind to explain to Verizon, one of our gigantic phone
companies, why it makes sense to offer service that their customers
want, I'd be very happy.

>>> I.e. before connecting to server client (like isql) must know that it is
>>> going to perform administrative tasks?
>>>
>>>
>> I've been worrying about that. One solution is allow the encryption
>> level to be changed in mid-session and invent a DML extension to invoke
>> it. It could be done on the client side at the expense of limited
>> client side command parsing. A better solution is to let the server
>> initiate the change in encryption. This, in turn, would require yet
>> another protocol extension.
> This has one issue except protocol extension. When server asks client to
> enhance encryption level, client does it and suggests user to repeat
> last operation. Very good, but 99% of users will use same password value
> like it was before. And that value already used to travel unencrypted
> over network, and if caught - can be reasonably attempted a few minutes
> after failed attempt. What to do? Keep blacklist of passwords
> transferred insecure?

That's a tough and serious problem. I'm going to have to think about.

>> A secure architecture is going to require a modest number of protocol
>> extensions, which is why I am arguing to put the architecture and
>> infrastructure in place first, then implement the specifics as needed.
> Our trunk is in a very good phase for protocol extensions - it is
> unstable 3.0. Even if someone gets a build with half-done protocol, this
> is not big problem :)
> But certainly understanding architecture first is very good idea.
>

--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376