Text 2223, 175 rader
Skriven 2004-07-31 18:08:00 av Alex Shakhaylo (2:461/701)
   Kommentar till text 2216 av Michiel van der Vlist (2:280/5555)
Ärende: http compatability flag
===============================
*** Answering a msg seen in area CC (CC).

Hi, Michiel!

30 Jul 04 12:10, Michiel van der Vlist said to Alex Shakhaylo:

 >> MV> Actually, mmy personal opinion is that allowing EONs was a
 >> MV> mistake. Mail delivery depends on them polling their ISP to
 >> MV> pick up the mail and so they heve the reachability of a point.
 >> MV> They should be treated as such.

 >> I come out of the "status quo", not of what "should be". My
 >> mailer has to support as many connectivity, as it is possible.

 MV> Why? Why does it have to support as many protocols as possible? You
 MV> want to be in Guinnes book of records?

No, I don't want to feel myself limited in my abilities.

 MV> The more protocols you add, the more room there is for bugs and
 MV> errors. I prefer things that do one or two things well instead of
 MV> trying to do everything and doing it poorly.

This is just _your_ prefference, but I'm working for mine ;)

I always install the lates copies of software (alphas, betas)
with maximum number of new features. Bugs don't fright me,
because they usually are temporary thing. This is my _preffe-
rence_, and it is natural that my mailer goes this way ..

I have to be "at the edge", I'm not satisfied with just stable
but featureless tools.

And beside of all this is interesting -- to experiment, to look
for new ways, to find solutions.

 >>  >> there are e-mail only points, which still are fidonet points).

 >> MV> Points exchnge mail with their boss node by private
 >> MV> arrangement. No need to contaminate the nodelist with that.

 >> Why not?

 MV> Because there are infinite ways to echange mail by private
 MV> arrangement. We do not want to saddle ourselves with the task of
 MV> documenting an infinite number of protocols.

No, we don't. But we have to saddle with implemented protocols,
and they are pretty countable. This is for technical convinience,
that mailers could do as much authomated work as it is possible.

 >> This information can be useful for mailer. Just another
 >> automation option.

 MV> "Just another" says it all. No added value.

Added values are saved sysops' time and backup protocol.
Email transport appeared to be useful when fidonet.net
zone went down. Mail still passed its way.

 MV> What the nodelist must provide is the means to make a basic connect.
 MV> There is no need to list ALL the potential means of connect. When
 MV> parties wish to tune the connection and use an exotic protocol they
 MV> can do so by private arrangement after the initial conact is made.

Sorry, but my point of view is completely opposite. Nodelist must
provide all the ways node can be contacted. Then people may choose
which way is better for them.

 >> My mailer is free of politic, because it is FTN
 >> mailer, not only Fidonet one ;)

 MV> Think again. "My mailer has to support as many protocols as possible"
 MV> is a strong political statement in itself.

This is not politic, because I have not prefferences which way is
better. All the ways are equally good for me. Politic begins with
limitations and prefferences, they make people feel uncomfortable.

 >> You talk all the time of Fidonet. But Fidonet Policy
 >> doesn't regulate all the FTN networks, so FTSC docs should
 >> not be technologically bound by it, I think. It should document
 >> existing practise.

 MV> The "F" in "FTSC" stands for FidoNet. We (the FTSC) have no obligation
 MV> towards other networks, we document for FidoNet. Period.

FTN also begins with Fidonet, but it is not bound by Fidonet politic.

FTS-1 is just another protocol, but according to politic it is mi-
nimal requiered Fidonet protocol. Where in FTS-1 have you seen words
'minimal' and 'requiered' ? They are not there. And which is more,
todays situation is not eternal situation. Tomorrow everything can
change in politic.

 MV> If other
 MV> networks wish to use our technology, that's fine. If ChickenNet does
 MV> not wish to use our technology, but wishes to use alternatives, they
 MV> are free to create a CTSC (ChickenNet Techical Standard Comittee) to
 MV> document those alternatives.

 MV> If you wish to implement those alternatives in your mailer, that is
 MV> your choice. But then don't tell us

I'm sure you did mean "don't tell _me_".

 MV> we should document it because it
 MV> is existing practise. Go to the CTSC for that.

Why not ? My opinin differs from yours, but nobody prooved that
yours is more correct. I'll try to tell. May I ? ;)

 >> MV> Sorry, I don't. More protocols no more make life easier than
 >> MV> having both metric and witworth nuts and bolts. They compell
 >> MV> you to have two sets of spanners. It just makes the toolbox
 >> MV> twice as heavy.

 >> I'm talking not of a server benefits, but of remote. I use
 >> http and smtp and pop3 in mail exchange between my 700 and
 >> 701 nodes.

 MV> Until not so long ago I used a couple of home made programs and a
 MV> batch script to exchange mail between my main system and my laptop
 MV> point over mt Novell LAN. If I were still using that should we
 MV> document that method and introduce the IPX flag?

But of course.

 MV> Ow, c'mon...

 >> When in the midday I call ISP to send my mail to 700 and
 >> 700 machine is down or rebooting or there are some tcp/ip
 >> routing problems my mail goes via smtp. Then I hangup and save my
 >> money not waiting until 700 comes online. When 700 is online it
 >> picks up mail over pop3. Isn't it still convincing ? Have you
 >> another way to send mail without delay and save money in a
 >> described  situation ?

 MV> Yes. Put the mail on a floppy disk, put it in your pocket and take it
 MV> home with you. When you arrive at the other machine stick it in the
 MV> slot and transfer the mail.

Michiel. Don't you want to go by foot instead of driving car ?
And yes, you may want it. But I want to drive car when distance
is long and time does matter, sorry.

 >> For example no one FTN protocol may be as 'cachable' as
 >> smtp/pop3.

 MV> What is the advantage of "cachable"? if I send mail direct, I don't
 MV> want it to be "cached". I want it to get there right away. If I want
 MV> it "cached" I can route it.

This is your personal choice. Why should I choose the same ?

 >> to send an urgent message to sysop whos mailer suport http
 >> receiption.

 MV> Shrug. How many will support it? Send an e-mail. /Everyone/ that has
 MV> access to the InterNet supports that.

I don't know email of all the fidonet nodes. If it shows IEM flag
I will send email, but in case it shows IHT flag I'll login and
send him mail using HTTP. What does disturb you ?

 MV> Anyway, if I have something urgent to tell another sysop and I can't
 MV> reach him by mail, I just call him on the telephone. That way I am
 MV> sure he gets the message.

IONs and EONs don't have listed phones.

Bye, Sinc, Alex

--- GoldED/W32 3.0.1
 * Origin: , (2:461/701)