- Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #189 [1995] Scn From : Rune Johansen 2:210/20 01 Oct 97 09:33:30 To : maciej grzeszczuk 01 Oct 97 07:03:46 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > but, we have to think about the standard of connetion that every ip node > allows. my proposal is to set VMODEM as a standard protocol, which must be > handled by every ip node (some kind of fts-0001 for ip nodes). vmodem exist > on every hardware or software platform (seen working with amiga, pc running > os/2, win95, win3.1, linux, freebsd, openbsd, and all unices running on the > 'big' computers). also ifcico from ifmail packet also can easily handle both > incoming and outgoing connections. all tcp fossils are vmodem aware. I would refuse setting VModem as a minimal requirement for a IP node. That's because I use a system that integrates with the IP stack itself, and does not use any fossil imitator to use a "normal" mailer. My mailer support telnet sessions in and out, plus outbound ftp sessions. I have not read the copyright on the VModem protocol, but I doubt that my author will implement it, if it is not completely free. That goes for the encryption part of it too. But, a VModem node can call a telnet node, and a telnet node can call a Vmodem node when it is configured to do telnet in addition to VModem protocol. Ifcico can also do telnet in/out. If a minimum protocol is to be used, I would vote for telnet. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) -------------------------- IP_CONNECT (IP_CONNECT) - Msg : #204 [1995] Scn From : Eckhard Mueller 2:2449/225 01 Oct 97 09:00:02 To : maciej grzeszczuk 01 Oct 97 19:11:00 Subj : 000 = emergency-number in Australia ------------------------------------------------------------------------------- Hallo maciej! >> > Yes, 000 is the Australian emergency number. this is relevant only if the dial prefix used in australia is 00 as here in germany and lots of other countries (or 0, theoretically). if the international dial prefix used in australia is something else, for example 011 like in USA, then this doesn't matter, since a mailer would call 011-000-something. I don't believe that australia is using 00: I'm dialing 000 very often (every international call, one 0 for getting out of my house, two more 0s for an international call), its likely that I'll dial 000 also, when I'm somewhere else where I don't need the first 0. But ok, maybe australiens don't make so many international calls... I don't know. mg> 999 is an emergency number in poland... this is relevant only, if 9 or 99 is your international access code. but if you use 00 in poland, we could use 999- for IP numbers, since your mailer would dial 00-999-something, not 999. Tschuess Eckhard --- GoldED/2 2.50.Beta6+ * Origin: AEH (2:2449/225) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #205 [1995] Scn From : maciej grzeszczuk 2:480/70 01 Oct 97 07:22:28 To : Rune Johansen 02 Oct 97 07:03:28 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Wed, 01 Oct 97 08:33:30 +0200 Rune Johansen napisal byl w fido.ip_connect: > But, a VModem node can call a telnet node, and a telnet node can call a > Vmodem node when it is configured to do telnet in addition to VModem > protocol. Ifcico can also do telnet in/out. If a minimum protocol is to be > used, I would vote for telnet. i agree. both telnet and ifcico protocols are compatible with vmodem. we can set up minimal standard for telnet, and that will be ok, as all the systems using emsi via tcp would easily connect then. 369 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: o, ziemniaki puree, jestem zbudowany... (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #206 [1995] Scn From : Steve Woodmore 2:254/410.1 01 Oct 97 08:20:16 To : Lech Szychowski 02 Oct 97 07:03:28 Subj : IP-connectivity ------------------------------------------------------------------------------- * Replying to a message in : SAVEAREA Hi Lech Szychowski, hope you are having a nice day 30-Sep-97 01:37:00, Lech Szychowski wrote to Steve Woodmore Subject: IP-connectivity LS> Hmm... The Internet seems to be an IP based network - and using LS> the IP protocol (most likely plus the TCP layer) is the only way LS> of sending data thru this network. I can't see your point here. LS> Well, to be honest, I think I see a possible point here: are you LS> trying to say that we should also provide enough flexibility to be LS> able to accommodate also addresses like X.25, X.400 etc? No I am talking about SMTP mail transfers, yes they are IP based, but the nodes that transfer are not on the internet full time. -=> Steve Woodmore <=- --- Terminate 5.00/Pro * Origin: At last, a quality Node in NET254 (2:254/410.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #207 [1995] Scn From : Pedro Lima 2:362/21 01 Oct 97 01:12:58 To : Ger Vloothuis 02 Oct 97 07:03:28 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hi, GV> The prefix is +61-. You probably misunderstood me. What I was asking was the prefix to make an international call in Australia, not the australian international prefix. :-) GV> If there is no translation specified in the nodelist compiler, GV> then the mailer would dial the number as listed, wouldn't it? True. However, I believe most people will have 3 translations configured, one to eliminate the local prefix, another to replace the country prefix, and a third for all other cases, which appends the international prefix. A nodelisted number initiated with '000-' would fall in the last category, so the translator would append the international prefix. This makes the number an impossible number in Australia unless the international prefix there is '0' or '00'. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #208 [1995] Scn From : Mats Wallin 2:201/329.11 01 Oct 97 10:49:52 To : Ward Dossche 02 Oct 97 07:03:28 Subj : 000 = emergency-number in Australia ------------------------------------------------------------------------------- WD> I checked with Alwyn Smith, the new ZC/3, and he confirmed WD> ... >> Yes, 000 is the Australian emergency number. I was thinking of >> 999 as a prefix code to use ... WD> Comments anyone? What is the prefix for dialing an international phone call in Australia then? Because it doesn't matter if 000 is the emergency number if the international prefix is something different than a number of zeroes. Any mailer would automatically add the international prefix before dialing an unknown country code. Mats mw@defsol.se --- * Origin: Stockholm, Sweden (2:201/329.11) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #209 [1995] Rcv Scn From : Lech Szychowski 2:480/33.7 01 Oct 97 01:15:00 To : Lothar Behet 02 Oct 97 07:03:28 Subj : IP-access ------------------------------------------------------------------------------- > LS> Ooops! Here we hit another problem: multiple-homed IP nodes. [...] > I think, if you are not regularly visiting your several sites, you will > install a forward schedule to the (temporary) main site. What you seem to talk about is a mobile system. When I wrote "multiple-homed" I meant one system that has three network interfaces (all of them permanently/simultanously active). > This is not a problem of ip, but a problem of your system setup > independant of the used connection technology. Right. This is a problem of (a) nodelist carrying enough info to make it possible for a mailer to realize that several addresses denote the same system and therefore all/any of them can be used to contact this system, (b) mailer being capable of detecting the aforementioned situation and and using the info it got from the nodelist. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #210 [1995] Scn From : Lech Szychowski 2:480/33.7 01 Oct 97 01:21:00 To : Pedro Lima 02 Oct 97 07:03:28 Subj : IP-access ------------------------------------------------------------------------------- > in the nodelist with the maximum of versatility and simplicity and > minimally upsetting the existant standards, namely by making it > compatible with the existant mailers and their nodelist compilers. If we are that much concerned about compatibility issues, we have almost no room to manouver in. I'm afraid the only option I can think about right now is using Pvt entries to list non-PSTN nodes, specifying just one non-PSTN address and capability per entry. It will work, but at the expense of wasting a huge amount of the Fido addressing space... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #211 [1995] Rcv Scn From : Lech Szychowski 2:480/33.7 01 Oct 97 01:26:00 To : Lothar Behet 02 Oct 97 07:03:28 Subj : 000 = emergency-number in Australia ------------------------------------------------------------------------------- > IMHO any prefix we select at this moment may be used later as an > official code or already be in use in at least one country. Unfortunately you are right. The only part od the nodelist entry that has a fixed range of possible values is the flags field. Any other field can have almost arbitrary value; of course within some limits, but we cannot go outside this limits without losing compatibility with existing nodelist processing software. This leaves us a very limited choice, ain't it? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #212 [1995] Scn From : Mats Wallin 2:201/329.11 01 Oct 97 10:46:20 To : rafal wiosna 02 Oct 97 07:03:28 Subj : IP-connectivity ------------------------------------------------------------------------------- rw> Because they cannot be reached from the PSTN Fido and rw> that's against P4. There is no requirement that everyone should be able to connect to everyone else using any type of analogue modem they want to. They need to use the correct equipment if they want to be able to connect. For instance, if I were to install a 300 bps modem here (which definitely is something that I'm allowed to do, since 300 bps modems were the modem type used when FidoNet started), I would be unable to connect to many systems. There are a lot of high speed modems that no longer supports 300 bps connects. So the requirement in P4 can't be anything else than that everyone should be able to connect to everyone else, if the caller uses the correct type of equipment when calling the other system. For an IP node, he will have to use IP when calling, for an ISDN node he will have to use ISDN and for a 300 bps node he will have to use a modem that supports 300 bps (and btw, it ahs to be the same 300 bps standard). Mats mw@defsol.se --- * Origin: Definite APXw (2:201/329.11) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #213 [1995] Scn From : Lech Szychowski 2:480/33.7 01 Oct 97 01:29:00 To : Rune Johansen 02 Oct 97 07:03:28 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > If a minimum protocol is to be used, I would vote for telnet. Why not a "raw socket"? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #214 [1995] Scn From : Ask Bjoern Hansen 2:235/224 01 Oct 97 03:20:42 To : Denis McMahon 02 Oct 97 07:03:38 Subj : IP-access ------------------------------------------------------------------------------- XP: IP_CONNECT Hello Denis! Thursday September 25 1997 01:22, Denis McMahon wrote to Pablo Saratxaga: DM>> OK, so with your proposal all that is needed is a flag for each DM>> type of ip connect a system can accept, and the system should be DM>> identified using a dns lookup on the f*.n*.z*.fidonet.org DM>> address, yes? PS>> Yes. DM> OK, so whoever maintains the fidonet.org dns table has to keep it DM> updated for all ip capable nodes in fidonet. Even if this is delegated DM> to the zx.fidonet.org level the administration will be excessive for a DM> single person. It would be easy to redelegte the administration further down to the RC, NC or whoever.. Kind Regards, Ask --- GoldED/2 3.00.Alpha4+ * Origin: An expert is still a novice, but on a higher level (2:235/224) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #215 [1995] Scn From : Ask Bjoern Hansen 2:235/224 01 Oct 97 03:24:42 To : All 02 Oct 97 07:03:38 Subj : Re: IP-access ------------------------------------------------------------------------------- ============================================================================= * Forwarded by Ask Bjoern Hansen (2:235/224) * Area : ENET.SYSOP (European sysop echo) * From : Pablo Saratxaga, 2:293/2219 (Wednesday September 10 1997 03:13) * To : Alto Speckhardt * Subj : Re: IP-access ============================================================================= From: Pablo Saratxaga Kaixo! on Sat, 06 Sep 97 18:42:36 +0200, Alto Speckhardt said: PS>> In zone 2 we have even the chance not to need to tell the IP numbers. PS>> Just use the DNS ! As it allows individual A entries. AS> Did I get that right: You'd suggested using a special nameserver to get AS> the ip-adresses from by specifying the fido-aka as the search kriterium. Not a special one, the existing one, that already works. For exemple lets say you have had a full 24h/24 IP connection at your birthday gift (lucy you ! :) ). Then you decide to put a TCP/IP-able mailer to listen on your wired machine. And you ask to mantainer of z2 DNS to add an A record (=IP address) for your fidonet address (f4000.n2487.z2.fidonet.org). For exemple if your IP address is 123.45.67.89, the you ask the DNS maintainer to put a line : f4000.n2487.z2.fidonet.org. A 123.45.67.89 f4000.n2487.z2.fidonet.org. MX 10 some.mx.host. f4000.n2487.z2.fidonet.org. MX 20 other.mx.host. *.f4000.n2487.z2.fidonet.org. MX 15 some.mx.host. *.f4000.n2487.z2.fidonet.org. MX 25 other.mx.host. (the MX lines is to tell where to send gated email, if you set up a gateway on your machine you can ask to be your own MX (list yourself in the first MX, "some.mx.host" in the exemple), or you can leave the default ones also, but that is not relevant to what I told about nodelist and DNS... So, now if someone on internet does for exemple a "ping f4000.n2487.z2.fidonet.org" he will be able to ping your wired machine. fine. That means that there is no need to put the IP address in the nodelist, in the nodelist you are: Hub,4000,Hub_Weissenhorn,Weissenhorn,Alto_Speckhardt,49-7309-7270,9600,CM, \ XA,VFC,V34,V42B,U,V110L,V110H,V120L,V120H,X75 if the IP flags are adopted that could become something like : Hub,4000,Hub_Weissenhorn,Weissenhorn,Alto_Speckhardt,49-7309-7270,9600,CM, \ XA,VFC,V34,V42B,U,V110L,V110H,V120L,V120H,X75,IFC telling you accept IFC calls (default port 60179). There is no IP address told, but as you are 2:2487/4000 --> f4000.n2487.z2.fidonet.org then search it on DNS. One of the reason some people are against listing TCP/IP-able nodes is that "that will increase nodelist size whith lots of uselless information and non dialable nodes". In Z2 we have the chance that we can list the TCP/IP-able nodes whithout "increasig nodelist size whith lots of uselless information and non dialable nodes", as you see in my exemple there is no need for supplementary lines, and the supplementary bytes are very fex (between 3 and 10 I suppose in 90% of the cases). That is possible thanks to the fact that the IP address can be retrieved otherwise than from the nodelist. AS> I understood you said there would already be such a nameserver for zone AS> two, is that right? If so, what would that server be linux:~# nslookup -query=SOA z2.fidonet.org. Server: chanae.stben.be Address: 194.149.85.130 z2.fidonet.org origin = ns.z2.fidonet.org mail addr = postmaster.z2.fidonet.org serial = 105 refresh = 345600 (4 days) retry = 7200 (2 hours) expire = 2592000 (30 days) minimum ttl = 86400 (1 day) z2.fidonet.org nameserver = ns0.fido.net z2.fidonet.org nameserver = fidonet.fidonet.org z2.fidonet.org nameserver = ns.z2.fidonet.org ns0.fido.net internet address = 194.159.102.1 fidonet.fidonet.org internet address = 198.69.90.5 ns.z2.fidonet.org internet address = 143.169.17.1 If you don't understand nslookup output, I asked for SOA entries (-query=SOA) for the z2.fidonet.org. domain, it replied me that those name servers are: z2.fidonet.org nameserver = ns0.fido.net z2.fidonet.org nameserver = fidonet.fidonet.org z2.fidonet.org nameserver = ns.z2.fidonet.org the main DNS being (origin) ns.z2.fidonet.org and the mantainer being (mail addr) postmaster@z2.fidonet.org AS> and isn't one single nameserver a AS> bit overtaxed if the whole region asks him for DNS-entries? The whole region won't do that, full 24h/24 TCP-IP access is still not very common, and anyway if that happens it won't be more complicated than mantaining the z2 nodelist. But on the other side nodes so listed can be reached directly, that will end in a better (fast and cheaper) routing, including for mail from outside z2, that will also decrease the charge of some fidonet nodes that currently do most of the traffic. That will also ensure more independence in the routing, if some central routing point crashes you can still receive mail directly from any TCP/IP-able node. I think after some time the modem routing will be only between TCP/IP-able nodes and local nodes, then most inter-region and inter-zone routing will be done by direct mailer connections trough TCP/IP. The reason I propose to use the DNS is that it will decreas *a lot* the required size in nodelist, that is it will have much less opposition than a proposal needing an extra line in the nodelist for each TCP/IP node (in fact I really doubt that this proposal could be approved, however by showing that TCP/IP-able nodes can be lsited whithout much trouble in nodelist I hope that the opposition to the project won't be too big and it could concretize). -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 -+- ifmail v.2.11-tx8.6 + Origin: Unknown (2:293/2219@fidonet) ============================================================================= --- GoldED/2 3.00.Alpha4+ * Origin: An expert is still a novice, but on a higher level (2:235/224) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #216 [1995] Scn From : Pedro Lima 2:362/21 01 Oct 97 18:39:26 To : Lech Szychowski 03 Oct 97 07:03:36 Subj : IP-access ------------------------------------------------------------------------------- LS> Yes. But at the expense of generating much additional netork traffic LS> and increasing server load - and therefore should be avoided whenever LS> possible. If I understand correctly, the traffic increase occurs mainly between the primary and secondary servers. Caches are almost inexistant since they have a short lifetime. Server load may be a significant factor if many people are "registering" at the same time, but I agree we should try to avoid the situation. LS> I'm not trying to say it's good or bad - I just want us to be aware LS> of as many implications as possible. Understood. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #217 [1995] Scn From : Pedro Lima 2:362/21 01 Oct 97 18:26:42 To : Rune Johansen 03 Oct 97 07:03:36 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hi, RJ> That's why a IP flag should be there too. Yes, I noticed it the day after, sometimes I'd better go to bed instead of answering mail... :-) How about IP4 and IP6 as flags? Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #218 [1995] Scn From : Pedro Lima 2:362/21 01 Oct 97 18:38:14 To : Lech Szychowski 03 Oct 97 07:03:36 Subj : IP-connectivity ------------------------------------------------------------------------------- Hello, LS> If we choose to LS> follow standard (PSTN) rules as close as possible (which seems LS> a logical and natural choice), then IP-node would have to be LS> accesible (ie accept incoming sessions) during the equivalent LS> of ZMH and support some minimal set of protocols (and we have LS> to define this set). ZMH had very good reasons to exist, but these reasons are at least partially obsolete nowadays. For example, forbidding echomail traffic during ZMH is usually unneccessary to accomplish the objective of having a time where the node's availability is almost certain. Naturally, systems which carry a big amount of echomail traffic and operate on a slow modem may have problems, but I guess a slow modem node wouldn't usually have that much echomail traffic. I see no particularly important reason to have a ZMH for IP nodes if the online time is specified (via Txx flags?) apart from compliance with P4. I'd agree however that a minimum online time should be considered. About protocols, the idea of retaining compatibility throughout all nodes justifies the existance of a minimal standard, even if other factors (such as modem protocols or more recently, ISDN nodes) make this an impossible objective. The objective would then be to *try* to be as compatible as possible. I agree it would be nice to have the same principle applied to IP nodes, but which of the existant protocols can be considered as a minimal standard is not an obvious choice, although BinkD seems to be supported in most of the platforms... Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #219 [1995] Scn From : Pedro Lima 2:362/21 01 Oct 97 08:10:18 To : Lech Szychowski 03 Oct 97 07:03:36 Subj : IP-connectivity ------------------------------------------------------------------------------- LS> Nope. If MTA decides this mail will go via SMTP protocol, it tries to LS> connect to port 25 at the IP address specified in square brackets. Ok, thanks for the clarification. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #220 [1995] Scn From : Pedro Lima 2:362/21 01 Oct 97 18:29:30 To : Steve Woodmore 03 Oct 97 07:03:36 Subj : IP-connectivity ------------------------------------------------------------------------------- SW> yes it is as simple as that or it isn't, any emails for me get held at SW> mail.demon.co.uk until I log on and collect them. SW> Like I say you can email me 24hrs, but only connect to me if I am SW> online. Thing is, if I send you an e-mail directly to your IP address (i.e using the form user@[aaa.bbb.ccc.ddd]), unless your ISP's mail machine aliases for itself the IP address when you're not connected, then I won't be able to do it unless you're online. This is only a detail, but one we must consider if we're going to assume that a nodelist entry with the sysop's name, his IP address and some kind of flag to declare e-mail capability (without specifying an e-mail address) is enough to send e-mail to that sysop. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #221 [1995] Rcv Scn From : Ger Vloothuis 3:633/284 02 Oct 97 23:08:14 To : Lothar Behet 03 Oct 97 19:06:20 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hi Lothar, Lothar Behet wrote in a message to Ger Vloothuis: GV> Triple 0 is the emergency phone number in Australia. Something like GV> 911 in the USA and 112 in GMS networks. Don't know if this would be a GV> problem but the emergency line operators would sure be hindered by a GV> lot of unintended modem calls. So that should be avoided. LB> Do you use the raw nodelist data for dialing or is there any kind LB> of dial translation in your nodelist compiler? LB> I hope, that most (node-)setups will respect even the flags in the LB> appropriate nodelist fields :) The dial translation will put the international access code in front of the listed phone number. With the ITU recommended international access code of 00 the dialer would translate a listed number starting with 0 into triple 0. The international access code 00 is already in use in most EEG countries and it is only a matter of time before other countries will follow. Australia just went through an entire new number implementation plan. One of the reasons (not the only one) was to clear the way to use 00 as a future international access code instead of the current 0011. Some other note: I am not so sure why it would be necessary to list IP numbers at all in a nodelist. The fido node number can readily be translated into a domain name, from which the IP can be resolved through the fidonet.org nameservers. If the fidonet community agrees on a 'well known port' to probe the remote IP on fido style connection capabilities, then no further information needs to be carried in the nodelist. An IP node without a registered domain name could be catered for with a local lookup file, very much in the same way as you can now handle unlisted, or changed phone numbers in Binkley. Don't know why there is so much hesitance to use DNS as a lookup mechanism. The previous ZC3 even made some automatic thinglybob to produce a DNS for zone 3. The fidonet.org domain servers should be put to good use and serve the IP connection methods for those who can. An IP compatible mailer could be made to probe first via dns, and if the return is 'no entry found' or 'no compatible file transfer method available', then automatic fall back to PSTN. Most IP nodes would have a PSTN modem online as well anyway and would have either connection method available to accept mail. No need to fiddle with nodelists. Only one entry needed per node. But very much need to further develop and refine IP compatible mailer systems and revive the fidonet.org dns as our dynamic always up-to-date on-line address book. In the spirit of enabling communications and not making things more difficult than they should be, the fidonet.org dns should even allow MX records for our many friends in remote countries where UUCP and PSTN is about the only way to get mail in and out and IP connectivity is still a dream. Regards Ger --- WtrGate v0.93.p1 Unreg * Origin: Teletechnique Melbourne (3:633/284) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #222 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 04 Oct 97 01:50:30 To : Ger Vloothuis Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hello Ger! On 02 Oct 97 wrote Ger Vloothuis to Lothar Behet: GV> The dial translation will put the international access code in front GV> of the listed phone number. With the ITU recommended international GV> access code of 00 the dialer would translate a listed number starting GV> with 0 into triple 0. Please tell this to those people, who mourne about dial translations :) GV> I am not so sure why it would be necessary to list IP numbers at all GV> in a nodelist. The fido node number can readily be translated into a GV> domain name, from which the IP can be resolved through the fidonet.org GV> nameservers. GV> If the fidonet community agrees on a 'well known port' to GV> probe the remote IP on fido style connection capabilities, then no GV> further information needs to be carried in the nodelist. At this moment the application form at z2.fidonet.org is only specified for gateways, but not for directly accessible ip-nodes, independant of the protocol they use. GV> An IP node without a registered domain name could be catered for with GV> a local lookup file, very much in the same way as you can now handle GV> unlisted, or changed phone numbers in Binkley. ... or privately "known" ip-nodes for my ip-mailers (Binkley/Vmodem is only of them :) GV> Don't know why there is so much hesitance to use DNS as a lookup GV> mechanism. The previous ZC3 even made some automatic thinglybob to GV> produce a DNS for zone 3. Without knowing his schedule, this implies a certain routing structure in Z3, otherwise this would be useless. GV> The fidonet.org domain servers should be put to good use and serve GV> the IP connection methods for those who can. An IP compatible mailer GV> could be made to probe first via dns, and if the return is 'no entry GV> found' or 'no compatible file transfer method available', then GV> automatic fall back to PSTN. Most IP nodes would have GV> a PSTN modem online as well anyway and would have either connection GV> method available to accept mail. That is one possibility for "direct" routing, but does really anybody need this in that way? It requires a special outbound task handling on the node, who is capable for different connection technologies, so there is no need for an epic discussion at this moment in this area. It is a task for system configuration and maybe some programmers, but not for defining a direct connection standard via ip-connectivity. GV> No need to fiddle with nodelists. Only one entry needed per node. But GV> very much need to further develop and refine IP compatible mailer GV> systems and revive the fidonet.org dns as our dynamic always GV> up-to-date on-line address book. Up to this point it is true: this address book exists, but ... GV> In the spirit of enabling communications and not making things more GV> difficult than they should be, the fidonet.org dns should even allow GV> MX records for our many friends in remote countries where UUCP and GV> PSTN is about the only way to get mail in and out and IP connectivity GV> is still a dream. ... you seem to be focused on mail exchange via gateways, but not on direct connections between nodes with ip connectivity. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #223 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 04 Oct 97 03:11:24 To : Ward Dossche Subj : IP-Test 2:2/3000 ------------------------------------------------------------------------------- Hello Ward! The nodelist entry for 2:2/3000 should read completely as follows: ,3000,fido.nrh.de,Uedem_Germany,Lothar_Behet,000-194-231-142-17,300,CM,U,VM,BND ,TELN Files request is at this moment only possible via Vmodem Protocol, but not on BinkD on my system! Now back to Business again :) What is the cause for the IP-flag on some of the test nodes? As far as the discussion is still in progress, shouldn't we try to explain the flags and default ports in the nodelist footer for interested nodes? ;S ;S Temporary user flags (for members of ip test only!) ;S These maybe changed in the future! ;S ;S VM Vmodem (default port 3141) ;S BND BinkD (default port 24554) ;S IFC ifcico (default port 60179) ;S IP ??? ;S ;S The system name field may be used for a fully qualified domain name. ;S Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #224 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 04 Oct 97 03:15:50 To : Ward Dossche Subj : IP-Test 2:2/3004 ------------------------------------------------------------------------------- Hello Ward! Only CM-Systems should be used at this moment for the IP-Test or at least appropiate Txy flags must be published. Furthermore the IP-Test-nodes should enable the address as soon as possible. Regards Lothar PS: Just mentioning it :) --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #225 [1995] Scn From : Jesper Maartenson 2:201/293.2 02 Oct 97 12:00:04 To : Lech Szychowski 04 Oct 97 07:03:38 Subj : Proposal? ------------------------------------------------------------------------------- LS> Is ICQ worth thinking about? Is it at least available on more LS> than one platform - or will it be soon? I doubt. Now available as JAVA-version and as MAC-version. (Earlier available as Win95/NT, Win31-version). * Origin: http://www.solberga.stockholm.se/ (2:201/293.2) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #226 [1995] Scn From : Denis McMahon 2:251/20 02 Oct 97 15:01:28 To : Steve Woodmore 04 Oct 97 07:03:38 Subj : IP-connectivity ------------------------------------------------------------------------------- Steve Woodmore wrote to Lech Szychowski: LS> Hmm... The Internet seems to be an IP based network - and using LS> the IP protocol (most likely plus the TCP layer) is the only way LS> of sending data thru this network. I can't see your point here. LS> Well, to be honest, I think I see a possible point here: are you LS> trying to say that we should also provide enough flexibility to be LS> able to accommodate also addresses like X.25, X.400 etc? SW> No I am talking about SMTP mail transfers, yes they are IP based, SW> but the nodes that transfer are not on the internet full time. SMTP is too abstract - it doesn't involve either ftn protocols or ftn data packets, and is wholly a tcp/ip transport. Note that I accept that smtp can be used to encapsulate a ftn packet file, compressed or otherwise, as a tunneling technique, however this is at the same level of abstraction from the ftn level as copying the files to a flop[py and sending it by snail mail. FTP is different - ftp can be used to transfer ftn data packets (compressed or otherwise) over an ip network, using anon login or passworded login and different levels of security for each. UUCP (of which I know little) is I believe like FTP. Perhaps someone can correct me? VModem transfers use FTN protocols over an ip connection as opposed to an analogue one. Telnet connections are IMHO BBS level, and whilst it might be of human interest that a BBS is telnettable, it has no strict nodelist impact as machines do not telnet to each other, rather people telnet to remote machines. Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #227 [1995] Scn From : Trevor Bates 2:250/607 01 Oct 97 18:39:00 To : Ward Dossche 04 Oct 97 07:03:38 Subj : 000 = emergency-number in Australia ------------------------------------------------------------------------------- Hia..... 28 Sep 97 09:39, Ward Dossche wrote to All: WD> I checked with Alwyn Smith, the new ZC/3, and he confirmed ... >> Yes, 000 is the Australian emergency number. I was thinking of 999 >> as a prefix code to use ... WD> Comments anyone? Uk Emergency Number :( Regards Trev.. --- FMail/2 1.22 * Origin: > Crock's Corner BBS Tel+44(0)1253-305040 24hrs< (2:250/607) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #228 [1995] Scn From : Lech Szychowski 2:480/33.7 02 Oct 97 02:51:00 To : Steve Woodmore 04 Oct 97 07:03:40 Subj : IP-connectivity ------------------------------------------------------------------------------- > No I am talking about SMTP mail transfers, yes they are IP based, but > the nodes that transfer are not on the internet full time. Are you trying to say that you seriously think about allowing IP-only SMTP-only non-permanently connected Fido nodes? :-O Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #229 [1995] Scn From : Lech Szychowski 2:480/33.7 03 Oct 97 10:30:00 To : maciej grzeszczuk 04 Oct 97 07:03:40 Subj : IP-connectivity ------------------------------------------------------------------------------- > if the email was really addressed to your ip number, it will be bounced > to the originator. Yep. There are no MXes for in-addr.arpa pseudodomains... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #230 [1995] Scn From : maciej grzeszczuk 2:480/70 01 Oct 97 23:08:14 To : Lech Szychowski 04 Oct 97 07:03:40 Subj : Re: IP-access ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 30 Sep 97 01:05:00 +0200 Lech Szychowski napisal byl w fido.ip_connect: > > emsi (vmodem) would be standard for ip-nodes. as the base protocol. > > that would simplify many things... > Sure, we might decide to make it so. But for sake of not introducing > any possible misunderstanding I'd rather not use the name "EMSI" here > - at least until we decide/agree EMSI should be the standard. my mistake. let telnet (vmodem) be the standard of protocol all ip nodes have to support. we can use emsi, or whatever we want to over this connection. 378 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: parasol (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #231 [1995] Scn From : maciej grzeszczuk 2:480/70 01 Oct 97 23:11:32 To : Lech Szychowski 04 Oct 97 07:03:40 Subj : Re: IP-access ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 30 Sep 97 01:11:00 +0200 Lech Szychowski napisal byl w fido.ip_connect: > I believe the solution we'll come to might work for both problems. sure, but that's not the main point. we should concentrate here on setting the protocol, and the nodelist entry format... 379 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: czy mierzyles jej fi dupy? (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #232 [1995] Scn From : Anders Thoresson 2:204/254.27 02 Oct 97 22:41:58 To : All 04 Oct 97 07:03:40 Subj : Add on for DOS ------------------------------------------------------------------------------- First of all, I better say hi. Hi! Second, I have been connected to this conference for a while without seeing any rules being posted. I would therefore like to express my hopes that this letter doesn't break this rules. If it is, let me know by netmail. The reason I write this letter is that I'm looking for some software which will make it possible for FrontDoor to make EMSI-connections over TCP/IP. I have looked at both rlfossil and ndis3pkt without any luck. If here is someone who have managed to setup and use any of these to packages I would gladly recieve some help. I'm also open for other solutions, but they have to work with FrontDoor running in a dos-box under Windows 95. The existing add-ons for Win95, like Com/IP, only lets windowsprograms to access their emulated comports (which btw works very good - at the moment I'm using FrontDoor APX/w and Com/IP without any problem). Therefore I guess I'm looking for a solution designed for DOS? Thank's in advance. * Origin: thore@fidonet.pp.se - fido | thore@biosys.net - other (2:204/254.27) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #233 [1995] Scn From : Lech Szychowski 2:480/33.7 02 Oct 97 02:59:00 To : maciej grzeszczuk 04 Oct 97 07:03:40 Subj : IP-access ------------------------------------------------------------------------------- > my mistake. let telnet (vmodem) be the standard of protocol all ip nodes Why telnet and not the raw connection? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #234 [1995] Scn From : maciej grzeszczuk 2:480/70 03 Oct 97 01:17:40 To : Steve Woodmore 04 Oct 97 07:03:40 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 30 Sep 97 09:20:20 +0200 Steve Woodmore napisal byl w fido.ip_connect: > PL> I thought an e-mail in the form user@[aaa.bbb.ccc.ddd] would be > PL> directed to port 25 of the machine at aaa.bbb.ccc.ddd, but maybe > PL> it isn't as simple as that. > yes it is as simple as that or it isn't, any emails for me get held at > mail.demon.co.uk until I log on and collect them. if the email was really addressed to your ip number, it will be bounced to the originator. > Like I say you can email me 24hrs, but only connect to me if I am online. i can mail you using your fqdn, not your ip. 410 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: agnieszka do kurwy nedzy! gdziezes polazla do chu (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #235 [1995] Scn From : maciej grzeszczuk 2:480/70 03 Oct 97 01:20:40 To : Eckhard Mueller 04 Oct 97 07:03:40 Subj : Re: 000 = emergency-number in Australia ------------------------------------------------------------------------------- From: maciej grzeszczuk Wed, 01 Oct 97 08:00:02 +0200 Eckhard Mueller napisal byl w fido.ip_connect: > this is relevant only, if 9 or 99 is your international access code. but if > you use 00 in poland, we could use 999- for IP numbers, since your mailer > would dial 00-999-something, not 999. all i want to say is that we'll never be sure that the prefix we've chosen will never be used in any country... 411 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: ...tak, tak, lubie tak, lubie kiedy robisz tak... (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #236 [1995] Scn From : maciej grzeszczuk 2:480/70 03 Oct 97 01:23:08 To : Sean Rima 04 Oct 97 07:03:40 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 30 Sep 97 10:05:24 +0200 Sean Rima napisal byl w fido.ip_connect: > Sorry you are wrong there. IFcico also uses BinkD, as does Argus and 2 other > mailers in the pipleline. Also Binkd is available for OS2, Windows95 , NT and > all versions of Unix. I also believe it is ported Amiga and the ST. ifcico is incompatible with binkd. binkd is incompatible with any mailer, except itself. sure, binkd exist on many platforms, but it's only one mailer, not a standard of virtual modem. with vmodem i can use any mailer. at any system. > Why should I and around 180 established Ipmailers have a forced change > because BinkD doesn't meet VModem. I think you would find that this would end > as 2 standards and not one. not change, but also allow vmodem connections. the standard that all ip nodes would accept shoudl be one. 412 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: obmierzly wale! (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #237 [1995] Scn From : maciej grzeszczuk 2:480/70 01 Oct 97 23:05:06 To : Pedro Lima 04 Oct 97 07:03:40 Subj : Re: IP-access ------------------------------------------------------------------------------- From: maciej grzeszczuk Mon, 29 Sep 97 05:48:39 +0200 Pedro Lima napisal byl w fido.ip_connect: > mg> what is the more importand, the node number differs as well. what for? > We're aiming at accomodating IP (and other network technologies) nodes > in the nodelist with the maximum of versatility and simplicity and > minimally upsetting the existant standards, namely by making it all the existing mailers need conversion in both cases - my flag-idea, and yours use-phone-number-field. so we can create something incompatible, and let authors of software modify their mailers to support our solution. my idea has one advantage - it allows both pstn and ip nodes within one entry, with one node number. no problem with mail addressing, packing, and so on... and it reduces the lenght of the nodelist, as we don't have to duplicate sysop's name, site, system's name, etc... 377 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: to, co pan mysli, ze weszlo to jeszcze nie wyszlo (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #238 [1995] Scn From : maciej grzeszczuk 2:480/70 03 Oct 97 11:13:02 To : Lech Szychowski 04 Oct 97 07:03:46 Subj : Re: IP-access ------------------------------------------------------------------------------- From: maciej grzeszczuk Thu, 02 Oct 97 01:59:00 +0200 Lech Szychowski napisal byl w fido.ip_connect: > > my mistake. let telnet (vmodem) be the standard of protocol all ip nodes > Why telnet and not the raw connection? that's quite simple: because people using mailers that supports raw connections are able to use vmodem connections too. vmodemers not nessesarilly can support raw ones. 415 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: rysiek! wynocha! sara, za ryskiem! (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #239 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 04 Oct 97 17:47:44 To : maciej grzeszczuk Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello maciej! On 03 Oct 97 wrote maciej grzeszczuk to Sean Rima: mg> sure, binkd exist on many platforms, but it's only one mailer, Furthermore the protocol specification is available and therefore will be supported by other programs in near future :) mg> not a standard of virtual modem. with vmodem i can use any mailer. at mg> any system. As far as i know, Vmodem is only supported for OS/2 and the protocol specification is not available. I would be happy to be corrected on this matter :) >> Why should I and around 180 established Ipmailers have a forced >> change because BinkD doesn't meet VModem. I think you would find >> that this would end as 2 standards and not one. I think, that at this moment FTP is the most important exchange protocol for FTN-data and mail via internet, as this is used between different zones for filebone and echobone transfers :) Personally I would prefer direct sessions, but as long as others are in use, i will not ignore them. mg> not change, but also allow vmodem connections. the standard that all mg> ip nodes would accept shoudl be one. This standard must allow permanent access and dialup-connections via internet. Furthermore you should not suppress mail based protocols completely, as they still make sense and they are in use, too. They are buffered at the specific mx and are of legal interest for non-CM ip-nodes. ( Hint: I am not talking about ip-only non-CM nodes! :) The nodelist flags should show the capability of a node to exchange mail and files even with different protocols and this may not only be with a direct mailerconnection for the near future. But the listed nodes must support ip-connectivity either CM or at least at clearly specified online times, otherwise they should not be listed with ip-flags on seperate or regular (PSTN) lines. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #240 [1995] Scn From : Pedro Lima 2:362/21 02 Oct 97 05:18:14 To : Lech Szychowski 04 Oct 97 19:09:36 Subj : IP-access ------------------------------------------------------------------------------- LS> If we are that much concerned about compatibility issues, we have LS> almost no room to manouver in. That is true. LS> I'm afraid the only option I can LS> think about right now is using Pvt entries to list non-PSTN nodes, LS> specifying just one non-PSTN address and capability per entry. That would be the most compatible solution, yes. But the incompatibility of placing an IP address into the phone field and not declaring the node as Pvt isn't technical, only procedural. LS> It will work, but at the expense of wasting a huge amount of the LS> Fido addressing space... Even if IP-nodes were admitted into the nodelist as Pvt nodes, if their entries somehow allow two IP mailers to get a connection, I hardly see it as a waste. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #241 [1995] Scn From : Sean Rima 2:252/356 02 Oct 97 23:32:42 To : All 04 Oct 97 19:09:36 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Due to comments about BinkD not being allowed into the proposed Nodelist, here are the specs for the next release of BinkD. Sean BINKP/1.0 _________________________________________________________________ Protocol description Binkp is a protocol intended for use over bidirectional channels with reliable transmission. Data sent by both of the parties should be split into frames that have the following general format: binkp's frames: +---------------------- 0=data block, 1=message(command) | +---- data block size / msg's argument size | | 7 6543210 76543210 +-+-------+--------+--- ..... ---+ | | HI LO | | -- data block / msg's argument +-+-------+--------+--- ..... ---+ |<- 2 bytes ->|<- 32K max ->| (frame header) (frame data) Frame header is 2 bytes long and defines type and length of data following the header. If the highest bit of the header is set to 0, then all the frame data shall be appended to the current file being received. If such file is not open, frame data can be discarded. Otherwise (if the highest bit is set to 1), frame data shall be parsed as a command changing protocol state. First byte of a command frame data is the command ID. The rest of the bytes carry command arguments. Command arguments are an arbitrary symbol string not necessarily limited by an '\0'. A command without arguments (e.g. M_OK) may look like this: 7 6543210 76543210 76543210 +-+-------+--------+--------+ |1| 0 1| 4| +-+-------+--------+--------+ | | +----- command ID (no arguments) | +-------- frame length (excluding header) +- command frame flag _________________________________________________________________ Binkp/1.0 commands and their arguments Format: symbolic_command_name command_ID * M_NUL 0 Command arguments are ignored and (optionally) logged. This is the way how binkd transmits nodelist info, sysop name, etc... e.g. "ZYZ Dima Maloff" * M_ADR 1 List of 5D addresses (space separated). e.g. "2:5047/13@fidonet 2:5047/0@fidonet" * M_PWD 2 Password. After successful password identification of the remote, binkd server rereads *.?lo files for the addresses presented by remote. e.g. "pAsSwOrD" * M_OK 4 Acknowledgement for a correct password. Upon receiving of this command, binkd client rereads *.?lo files for the addresses presented by remote. Arguments are ignored. e.g. "" * M_FILE 3 Space separated list of next file parameters: filename size in bytes; unix time; file transmission offset. [Warning!] Filenames can not include symbols with ASCII value less than 0x20. All parameters are decimal. Until the next M_FILE command is received, all data frames shall carry data from this file. There is no end of file identifier as the file size is known beforehand. If there are "extra" data frames, binkd will append this data to the file. Transmission of each file shall be started from offset 0. M_GET command sent by the remote party shall force us to make seek(). e.g. "config.sys 125 2476327846 0" or, answering to M_GET with offset 100: "config.sys 125 2476327846 100" * M_EOB 5 End-of-Batch. M_EOB command shall be transmitted after all the files have been sent. If all of the following applies: + we are in the EOB state (all the files have been sent), + we have received M_EOB from the remote party (there are no more files for us), + we have received acknowledgements for all the files sent, + we have received all the files re-requested by M_GET, then the session shall be deemed successfully ended. e.g. "" * M_GOT 6 File acknowledgement, that shall be transmitted upon receiving of the last data frame for this file. Arguments for this command shall be the same as for the M_FILE sent by remote, excluding the last argument, file offset, which is not transmitted back to the system which have sent M_FILE. M_GOT can also be transmitted while receiving a file, in which case transmitting party may interpret it as a destructive skip. e.g. "config.sys 125 2476327846" * M_ERR 7 This command indicates a fatal error. Party, sending M_ERR, may abort the session. Argument shall contain error explanation and may be logged. Binkd sends M_ERR in response for an incorrect password. e.g. "Incorrect password" * M_BSY 8 M_BSY command is transmitted if our system is busy. The argument may contain an explanation of the situation and may be logged by remote. e.g. "Too many servers are running already" * M_GET 9 M_GET command allows to resend files. Arguments of the command are the same as for the M_FILE command which we'd like to receive from remote. Binkd sends M_GET when it doesn't like transmission file offset. e.g. "config.sys 125 2476327846 100" As of nowadays, binkd processes this command as follows: according to the first three arguments (filename/size/unixtime), it determines whether the M_GET argument is the current file being transmitted to the remote (or a file that have been transmitted, but we are still waiting an M_GOT ack for it). If this is the case, binkd performs seek() to the specified offset and sends an M_FILE. For the example above, corresponding M_FILE will have the following arguments: e.g. "config.sys 125 2476327846 100" * M_SKIP 10 Non destructive skip. Parameter is a space separated list of filename, size and unixtime. e.g. "config.sys 125 2476327846" _________________________________________________________________ An example of a typical session between two binkds calling part sends called party sends M_NUL "SYS ..." M_NUL "SYS ..." M_NUL "ZYZ ..." M_NUL "ZYZ ..." M_NUL "LOC ..." M_NUL "LOC ..." M_NUL "VER ..." M_NUL "VER ..." M_ADR "2:2/2.2@fidonet" M_ADR "3:3/3.3@fidonet" M_PWD "password" (waiting for a password from remote) M_OK "" or M_ERR "Bad password" (waiting for M_OK) M_FILE "file2 200 42342434 0" M_FILE "file1 100 423424244 0" data data data data data M_EOB (got file1, acknowledging it) (got file2, acknowledging it) M_GOT "file1 100 423424244" M_GOT "file2 200 42342434" data M_EOB _________________________________________________________________ See also: http://www.doe.carleton.ca/~nsoveiko/fido/binkd/man/ Binkd User Guide for discussion on a particular implementation of binkp protocol. Original of this document in Russian, http://www.magadan.ru/~maloff/binkd/binkp.html. _________________________________________________________________ (c) Copyright 1996-97 by Dima Maloff (c) Copyright 1997 translated into English by Nick Soveiko --- Msged/NT 4.10 * Origin: DSP BBS, Reading, Berks (2:252/356@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #242 [1995] Scn From : Steve Woodmore 2:254/410.1 03 Oct 97 10:44:28 To : Pedro Lima 04 Oct 97 19:09:36 Subj : IP-connectivity ------------------------------------------------------------------------------- Hi Pedro Lima, hope you are having a nice day 01-Oct-97 18:29:30, Pedro Lima wrote to Steve Woodmore Subject: IP-connectivity PL> Thing is, if I send you an e-mail directly to your IP address (i.e PL> using the form user@[aaa.bbb.ccc.ddd]), unless your ISP's mail PL> machine aliases for itself the IP address when you're not This is becoming very circular. I do not want to see IP nodes only listed in the nodelist, that IGNORES the vast majority of people who use the internet as a telco carrier. I want to see a domain in the nodelist IE user@proteus.demon.co.uk for me, along with flags indicating my capabilities IE SMTP mail transfers. I want people to look in the nodelist (or automated software to this) and know that they can reach my fido node by SMTP or Email. There are thousands of nodes that have an internet account, this information should be incorporated into the nodelist, not ignored. Plain IP nodes are few and far between. -=> Steve Woodmore <=- --- Terminate 5.00/Pro * Origin: Descended from Apes (2:254/410.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #243 [1995] Scn From : Pedro Lima 2:362/21 02 Oct 97 05:38:44 To : Mats Wallin 04 Oct 97 19:09:36 Subj : 000 = emergency-number in Australia ------------------------------------------------------------------------------- MW> Any mailer would automatically add the international prefix before MW> dialing an unknown country code. Not really, it needs to be configured to do it, otherwise it'll dial the plain number. However, the purpose of having a special prefix is to avoid dialing by distraction an IP number with a current configuration, which will probably include adding the international prefix to all numbers not beginning with one's own country code. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #244 [1995] Scn From : Ward Dossche 2:292/854 04 Oct 97 13:32:26 To : David Moufarrege 05 Oct 97 07:07:48 Subj : Re: IP-nodes ... ------------------------------------------------------------------------------- David, > WD> At midnight the following will be added to the nodelist ... > Which nodelist? Testing in zone-2 ... to not disturb the other zones a portion of our nodelist is not exchanged with them, i.e. the section which deals with IP. There are now several IP-nodes in the zone2-nodelist for testing and experimenting purposes (and to help overcome the psychological treshold this represents for some) which operate in a realm not covered by policy. Therefor it's my responsibility to do this and I wouldn't want to bother the other zones with it. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #245 [1995] Scn From : Ward Dossche 2:292/854 04 Oct 97 12:53:40 To : Lech Szychowski 05 Oct 97 07:07:48 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Lech, > Nuke? Well, I'd rather call it "extend so that it would not ignore > the existence of IP network (namely one, the Internet) as a carrier > media", "carrier" being a keyword. Don't underestimate the psychological freeze that some of the old-core old-guys will experience if someone talks about FTS-0001, it needs a major-rewrite/rewrite though I like the ideas expressed in it. I would like to expand your words of "IP network" to "any carrier technology allowing a Fido-session". \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #246 [1995] Scn From : Ward Dossche 2:292/854 04 Oct 97 13:31:38 To : Steve Woodmore 05 Oct 97 07:07:48 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- > In fact why even Bother with regions and Zones, why not just have one > large net. I mentioned this already months ago ... nothing new. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #247 [1995] Scn From : Ward Dossche 2:292/854 04 Oct 97 13:02:44 To : Pedro Lima 05 Oct 97 07:07:48 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- > WD> Changing FTS-0001 would be fine ... but someone has a copyright on > it > WD> and changing the text is forbidden via that same > copyright-statement. > Is the reference 'FTS-0001' copyrighted? Yes. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #248 [1995] Scn From : Ward Dossche 2:292/854 04 Oct 97 13:04:46 To : Ger Vloothuis 05 Oct 97 07:07:48 Subj : How to not get IP-implemented ------------------------------------------------------------------------------- Welcome zone-3 in this ... erhhh ... discussion. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #249 [1995] Scn From : Ward Dossche 2:292/854 04 Oct 97 12:50:12 To : Lech Szychowski 05 Oct 97 07:07:48 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lech, > Well, let me clarify one more thing: you are not trying to imply that > Z2 Fido IP-nodes should all be listed under z2.fidonet.org domain? > I hope not :) I am not implying it ... fact is I am stating it with a degree of clarity that leaves no room for interpretation. The matter must stay manageable hence I see only 2 acceptable ways: 1) The full-IP number in the nodelist; 2) The FQDN in the nodelist. Both in the namefield, no more no less. If as some imply you also want to push for working with another list which is managed outside the Fidonet structures, then I have nothing left but to wish you sweet dreams ... because ... over my dead body! The core of Fidonet is the nodelist, think twice about that. Please don't write too long messages, I usually don't read past a second screen. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #250 [1995] Scn From : Ward Dossche 2:292/854 04 Oct 97 13:08:28 To : David Moufarrege 05 Oct 97 07:07:48 Subj : Re: How to not get IP-implemented ------------------------------------------------------------------------------- Yow David, > Hello Ward! And zone-1 is also on-line here I see. Great! \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #251 [1995] Scn From : Ward Dossche 2:292/854 04 Oct 97 13:24:06 To : Trevor Bates 05 Oct 97 07:07:48 Subj : Re: 000 = emergency-number in Australia ------------------------------------------------------------------------------- > WD> I checked with Alwyn Smith, the new ZC/3, and he confirmed ... >>> Yes, 000 is the Australian emergency number. I was thinking of 999 >>> as a prefix code to use ... > WD> Comments anyone? > Uk Emergency Number :( That's going to change! \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #252 [1995] Scn From : Ward Dossche 2:292/854 04 Oct 97 13:28:34 To : Sean Rima 05 Oct 97 07:07:48 Subj : Re: BinkD (0.9.2) specification ------------------------------------------------------------------------------- > Due to comments about BinkD not being allowed into the proposed Nodelist, Who said that? \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #253 [1995] Scn From : Ward Dossche 2:292/854 04 Oct 97 12:59:10 To : maciej grzeszczuk 05 Oct 97 07:07:48 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Maciej, > a/ ,U,IP(ADR) flag, that would carry the address. (imho the best idea) This is not my opinion. You'd have a serious problem defining then IP-only nodes. > b/ create another entry in the nodelist (with separate nodenumber), that > would carry all the information that primary does, but have address > in the phone field (we're duplicating a lot of data then) There is a duplication-element, but that is unavoidable. Things must remain manageable. > c/ put address in the system name field (as it's incompatible with > existing mailers as well as a/ point, we should better use the a/ one - > mailers should be modified do use the ,U,IP(ADR) flags. old ones could use > some kind of subst.lst list - created locally by sysop, contained the > nodenumber and proper internet address) I dissagree as well. Putting the address in the phone-field and otherwise treat it as a regular entry is the most simple and easy. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #254 [1995] Scn From : Ward Dossche 2:292/854 04 Oct 97 13:07:42 To : Ger Vloothuis 05 Oct 97 07:07:48 Subj : Re: IP-access ------------------------------------------------------------------------------- > Coming to think of it, why not keep the existing V7 Nodelist unchanged, > and make the mailer try to resolve the IP number from the default Fido > domain address: > "p#.f#.n#.z#.fidonet.org" Because that would mean every IP-capable node should be listed in extenso in the internet-tables. That means we'd have nodelist-management governed by policy-documents which can be enforced while there'd be the management of internet-tables on which we have no grasp from inside Fidonet. It is a technical complication which in the end will be abused by someone. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #255 [1995] Scn From : Lech Szychowski 2:480/33.7 04 Oct 97 13:37:00 To : Pedro Lima 05 Oct 97 07:08:04 Subj : IP-access ------------------------------------------------------------------------------- > If I understand correctly, the traffic increase occurs mainly between > the primary and secondary servers. Yes. Also traffic between these servers and clients requesting DNS records, but I think it's not as big as between servers. This problem can be partially solved by creating more DDNS servers servicing a smaller number of nodes; regional/netional subdomains of Z2 seem to be a natural/obvious choice. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #256 [1995] Scn From : Lech Szychowski 2:480/33.7 04 Oct 97 13:29:00 To : Pedro Lima 05 Oct 97 07:08:04 Subj : IP-connectivity ------------------------------------------------------------------------------- > partially obsolete nowadays. For example, forbidding echomail traffic > during ZMH is usually unneccessary to accomplish the objective of having > a time where the node's availability is almost certain. Yes, I agree that defining ZMH as a netmail-only time is, given the modem speeds we have now, obsolete. > I see no particularly important reason to have a ZMH for IP nodes > if the online time is specified (via Txx flags?) apart from compliance > with P4. I'd agree however that a minimum online time should be considered. Exactly. My idea was not to blindly copy P4 regulations, but to develop new ones according to the specific features of the IP connectivity. Having an IP-ZMH would also make it possible for all those who have no permanent connection but are dying to be an IP-capable node to stay online via dialup during these hours, therefore satisfying the connectivity requirement. > principle applied to IP nodes, but which of the existant protocols can > be considered as a minimal standard is not an obvious choice, although > BinkD seems to be supported in most of the platforms... Let's make a list of software available, along with its capabilities (protocols, platforms etc). This should give us a better background for making such decisions. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #257 [1995] Scn From : Lech Szychowski 2:480/33.7 04 Oct 97 13:00:00 To : Ask Bjoern Hansen 05 Oct 97 07:08:04 Subj : IP-access ------------------------------------------------------------------------------- > telling you accept IFC calls (default port 60179). There is no IP > address told, but as you are 2:2487/4000 --> f4000.n2487.z2.fidonet.org > then search it on DNS. Very reasonable idea that could become even more reasonable if regions/nets could have their respective subdomains delegated to them. And if someone really wants to have IP-based sessions with a node that for some reason has no DNS entry he can put this node manually into hosts file. BTW: Do you happen to know why Pablo is not active here? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #258 [1995] Scn From : Lech Szychowski 2:480/33.7 04 Oct 97 13:41:00 To : Denis McMahon 05 Oct 97 07:08:04 Subj : IP-connectivity ------------------------------------------------------------------------------- > UUCP (of which I know little) is I believe like FTP. Perhaps someone can > correct me? Smarter (can transfer files both ways) and much more suitable for our purposes; as a matter of fact, UUCP was created just to achieve what we want now: moving files and mail between nodes. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #259 [1995] Scn From : Lech Szychowski 2:480/33.7 04 Oct 97 13:43:00 To : maciej grzeszczuk 05 Oct 97 07:08:04 Subj : IP-access ------------------------------------------------------------------------------- >> Why telnet and not the raw connection? > because people using mailers that supports raw connections are able to > use vmodem connections too. vmodemers not nessesarilly can support raw > ones. If above is true (I'm not implying it is not - I am just not sure) vmodem is a better choice. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #260 [1995] Scn From : Lech Szychowski 2:480/33.7 04 Oct 97 13:03:00 To : Pedro Lima 05 Oct 97 07:08:04 Subj : A bit of steering ... ------------------------------------------------------------------------------- > of answering mail... :-) How about IP4 and IP6 as flags? Point taken. Question: do we need separate flags or can it be self-evident (actual address length)? I opt for a separate flag, to make software more easily created and more robust; moreover, IPv6 is a different/separate protocol anyway. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #261 [1995] Rcv Scn From : Ward Dossche 2:292/854 04 Oct 97 22:11:20 To : Lothar Behet 05 Oct 97 19:12:00 Subj : Re: IP-Test 2:2/3000 ------------------------------------------------------------------------------- Lothar, > The nodelist entry for 2:2/3000 should read completely as follows: Your request to me is a command and I am your humble servant. > What is the cause for the IP-flag on some of the test nodes? They've asked to put it that way. As you know, I don't have the heart to say "no". ;-) > As far as the discussion is still in progress, shouldn't we try to > explain the flags and default ports in the nodelist footer for interested > nodes? I attempted to do that yesterday, but I goofed somewhere and the system locked-up, that's the reason why the diff was some hours later than usual, I got worried at some point when at a Fridaymorning the modem was so silent.. When it will be in next week you'll see how much it resembles what you are proposing now. ;-) \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #262 [1995] Scn From : Tobias Ernst 2:2476/418 04 Oct 97 21:01:52 To : Ask Bjoern Hansen 05 Oct 97 19:12:00 Subj : IP-access ------------------------------------------------------------------------------- Hallo Ask! ABH>Hub,4000,Hub_Weissenhorn,Weissenhorn,Alto_Speckhardt,49-7309-7270,9600, ABH> ,CM,XA,VFC,V34,V42B,U,V110L,V110H,V120L,V120H,X75,IFC ABH> telling you accept IFC calls (default port 60179). There is no ABH> IP address told, but as you are 2:2487/4000 --> ABH> f4000.n2487.z2.fidonet.org then search it on DNS. This would require every existing mailer to be rewritten in a way to support IP-flags and to calculate the FQDN out of the node number. Nevertheless, of all solutions I have been seeing since I read this echo, this is the most elegant one. It makes the most clever use of existing internet technology (DNS), it puts the least ballast on the nodelist, and it will not have any negative influence on PSTN nodes who do not have a specific IP setup (compare to the problems with fake country prefixes when listing IP phone numbers). Keep up your good idea! ABH> in the routing, if some central routing point crashes you can ABH> still receive mail directly from any TCP/IP-able node. Well, this just shifts to the point that a crash of the DNS computer will stop any traffic in the whole Z2. ;-). We should maintain more than one DNS computer, on the one hand for backup purposes, on the other hand to reduce traffic for each individual one. Besides rewriting the mailers, we probably will have to write a software which allows end nodes to automatically register their IP numbers and which distributes the configuration to all Z2 DNS systems. Viele Gruesse, Tobias. --- * Origin: Ring a dong! hop along! fal lal the willow! (2:2476/418) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #263 [1995] Scn From : David Moufarrege 1:2613/404 04 Oct 97 22:39:50 To : Ward Dossche 05 Oct 97 19:13:04 Subj : How to not get IP-implemented ------------------------------------------------------------------------------- Hello Ward! In a message Ward Dossche wrote to David Moufarrege: WD> And zone-1 is also on-line here I see. Great! Can't let you do this alone now, can we? -=David=- _____________________________ | e-mail : david@kraut.xg.com | | FidoNet: 1:2613/404 | | 1:13/0 | ----------------------------- ... Computers don't make mistakes, but foolish people do. --- * Origin: Kraut Haus * Rochester, NY * 716-359-0871 (1:2613/404) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #264 [1995] Scn From : David Moufarrege 1:2613/404 04 Oct 97 22:38:12 To : Ward Dossche 05 Oct 97 19:13:04 Subj : IP-nodes ... ------------------------------------------------------------------------------- Hello Ward! In a message Ward Dossche wrote to David Moufarrege: WD> Testing in zone-2 ... to not disturb the other zones a portion of our WD> nodelist is not exchanged with them, i.e. the section which deals with WD> IP. I'd be interested to see this. Anyway I can get you to e-mail attach me that segment for review here? -=David=- _____________________________ | e-mail : david@kraut.xg.com | | FidoNet: 1:2613/404 | | 1:13/0 | ----------------------------- ... In this world a man must either be anvil or hammer. --- * Origin: Kraut Haus * Rochester, NY * 716-359-0871 (1:2613/404) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #265 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 05 Oct 97 21:15:30 To : Ward Dossche Subj : IP-Test 2:2/3000 ------------------------------------------------------------------------------- Hello Ward! On 04 Oct 97 wrote Ward Dossche to Lothar Behet: >> The nodelist entry for 2:2/3000 should read completely as follows: WD> Your request to me is a command and I am your humble servant. Thank you very much :) >> What is the cause for the IP-flag on some of the test nodes? WD> They've asked to put it that way. As you know, I don't have the heart WD> to say "no". ;-) I was was just looking for a reason, why some entries had it while others did not :) >> As far as the discussion is still in progress, shouldn't we try to >> explain the flags and default ports in the nodelist footer for >> interested nodes? WD> I attempted to do that yesterday, but I goofed somewhere and the WD> system locked-up, that's the reason why the diff was some hours later WD> than usual, I got worried at some point when at a Fridaymorning the WD> modem was so silent.. The silence did disturb your rest? :) WD> When it will be in next week you'll see how much it resembles what WD> you are proposing now. ;-) After a long time i can wait for another week :) With kind regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #266 [1995] Scn From : Slava Filimonov 2:469/33 02 Oct 97 18:34:20 To : Lech Szychowski 06 Oct 97 07:07:46 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Lech! 01 Oct 97 01:29, Lech Szychowski wrote to Rune Johansen: >> If a minimum protocol is to be used, I would vote for telnet. LS> Why not a "raw socket"? Have u heared anything about binkd protocol for ip fido mailer? as simple as possible and fast enough extendable too... why a standart? we've already using it at least for half year and there are at least 200 nodes which supports it... binkd - multiplatform ip fido mailer can be downloaded at ftp.falcon.spb.su /pub/fido Argus - fido mailer win32 with ip binkd protocol / www.ritlabs.com bwt, this echo comes to me through binkd. // 2:469/33 aka fido.mrp.cz/binkd // C0PiRATE Cy.b33r.Net // slf@mrp.cz // www.geocities.com/SoHo/9669 --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #267 [1995] Scn From : Fyodor Ustinov 2:5020/79 04 Oct 97 07:21:54 To : maciej grzeszczuk 06 Oct 97 07:07:46 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hi, maciej! Friday October 03 1997, maciej grzeszczuk writes to Sean Rima: >> Why should I and around 180 established Ipmailers have a forced >> change because BinkD doesn't meet VModem. I think you would find >> that this would end as 2 standards and not one. mg> not change, but also allow vmodem connections. the standard that all mg> ip nodes would accept shoudl be one. Yes. And this standart should be binkp. With best regards, Fyodor --- GoldED/W32 3.00.Alpha5 UNREG * Origin: U.F.M Station [ufm@prospect.com.ru, 1086856#ICQ] (2:5020/79) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #268 [1995] Scn From : Lech Szychowski 2:480/33.7 05 Oct 97 04:15:00 To : Pedro Lima 06 Oct 97 07:07:46 Subj : IP-access ------------------------------------------------------------------------------- > That would be the most compatible solution, yes. But the incompatibility > of placing an IP address into the phone field and not declaring the node > as Pvt isn't technical, only procedural. I we can guarantee that no mailer will generate additional cost and/or trouble - dialing a "non-reachable number" being a trouble - you are IMHO right. Even better: if we assume that all mailers can differ its behavior according to the flags the node they would like to connect to has listed in its nodelist entry, we can define "IP" as a "don't dial" flag and... Too bad not all mailers support this. > Even if IP-nodes were admitted into the nodelist as Pvt nodes, if their > entries somehow allow two IP mailers to get a connection, I hardly see > it as a waste. Don't get me wrong. All I'm trying to say is we should not accept such a waste too easily. If we find no other way... well, then we'll have to. But we should try very hard to avoid it. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #269 [1995] Scn From : Slava Filimonov 2:469/33 04 Oct 97 11:54:28 To : Fyodor Ustinov 06 Oct 97 07:07:46 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Fyodor! 04 Oct 97 07:21, Fyodor Ustinov wrote to maciej grzeszczuk: >>> Why should I and around 180 established Ipmailers have a forced >>> change because BinkD doesn't meet VModem. I think you would find >>> that this would end as 2 standards and not one. mg>> not change, but also allow vmodem connections. the standard that mg>> all ip nodes would accept shoudl be one. FU> Yes. And this standart should be binkp. Agreed. Using binkp now for half year i fell myself better. I almost forgot about all that hell i had with vmodem on my poor ip link ;))) // C0PiRATE Cy.b33r.Net // slf@mrp.cz // www.geocities.com/SoHo/9669 --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #270 [1995] Scn From : Max Masyutin 2:469/84 04 Oct 97 15:26:12 To : maciej grzeszczuk 06 Oct 97 07:07:46 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello maciej! 03 Oct 97 01:23, maciej grzeszczuk wrote to Sean Rima: >> Why should I and around 180 established Ipmailers have a forced change >> because BinkD doesn't meet VModem. I think you would find that this would >> end as 2 standards and not one. mg> not change, but also allow vmodem connections. the standard that all ip mg> nodes would accept shoudl be one. Do you suggest FTS-0001 session via VModem as the standard? Max. [Argus Team] --- * Origin: max@ritlabs.com (2:469/84) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #271 [1995] Scn From : Denis McMahon 2:251/20 04 Oct 97 14:10:50 To : Ask Bjoern Hansen 06 Oct 97 07:07:46 Subj : IP-access ------------------------------------------------------------------------------- Ask Bjoern Hansen wrote to Denis McMahon: DM>> OK, so with your proposal all that is needed is a flag for each DM>> type of ip connect a system can accept, and the system should be DM>> identified using a dns lookup on the f*.n*.z*.fidonet.org DM>> address, yes? PS>> Yes. DM> OK, so whoever maintains the fidonet.org dns table has to keep it DM> updated for all ip capable nodes in fidonet. Even if this is delegated DM> to the zx.fidonet.org level the administration will be excessive for a DM> single person. ABH> It would be easy to redelegte the administration further down to ABH> the RC, NC or whoever.. No it would not, the administration would have to be done by whoever maintained the dns at the level concerned. Most NCs, RCs etc have no access to the DNS for z2.fidonet.org. Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #272 [1995] Scn From : Sean Rima 2:252/356 05 Oct 97 01:56:26 To : maciej grzeszczuk 06 Oct 97 07:07:46 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- 03 Oct 97 01:23, maciej grzeszczuk wrote to Sean Rima: >> Sorry you are wrong there. IFcico also uses BinkD, as does Argus and 2 >> other mailers in the pipleline. Also Binkd is available for OS2, >> Windows95 , NT and all versions of Unix. I also believe it is ported >> Amiga and the ST. > ifcico is incompatible with binkd. binkd is incompatible with any > mailer, > except itself. Strange, I connect to an IFCICO mailer evey day with no problems. There is an addon for Ifcico to allow it to use BinkP which is use by BinkD > sure, binkd exist on many platforms, but it's only one mailer, not a > standard > of virtual modem. with vmodem i can use any mailer. at any system. BinkP is the protocol that is used by BinkD. BinkP 1.0 and 1.1 is used by Argus and shortly Beemail. I have also heard that there is another OS2 based mailer that will use BinkP 1.1 >> Why should I and around 180 established Ipmailers have a forced change because >> BinkD doesn't meet VModem. I think you would find that this would end >> as 2 standards and not one. > not change, but also allow vmodem connections. the standard that all ip > nodes > would accept shoudl be one. Having used EMSI connections across the net, I would not like to go back to it. It is incredably slow handshaking and I found it prone to dropped calls. Another reason that TelNet should not be considered is that some IPmailers operate on a shell account and the only way to change any settings is to TelNet in. I also believe that there is a major update with BinkD itself shortly. But I do not know the exact details. Sean --- Msged/NT 4.10 * Origin: DSP BBS, Reading, Berks (2:252/356@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #273 [1995] Scn From : Steve Woodmore 2:254/410.1 04 Oct 97 10:43:36 To : Lech Szychowski 06 Oct 97 07:07:46 Subj : IP-connectivity ------------------------------------------------------------------------------- * Replying to a message in : SAVEAREA Hi Lech Szychowski, hope you are having a nice day 02-Oct-97 02:51:00, Lech Szychowski wrote to Steve Woodmore Subject: IP-connectivity LS> Are you trying to say that you seriously think about allowing LS> IP-only SMTP-only non-permanently connected Fido nodes? :-O NO!, I am trying to say we should allow any node that has any form of IP transfer available to them, be it IP FTP SMTP Tunneling or whatever, if they can transfer mail via the internet in some form or another, then they should be listed as such. -=> Steve Woodmore <=- --- Terminate 5.00/Pro * Origin: Leaving NET440 :( (2:254/410.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #274 [1995] Scn From : Lech Szychowski 2:480/33.7 05 Oct 97 04:41:00 To : Steve Woodmore 06 Oct 97 07:07:46 Subj : IP-connectivity ------------------------------------------------------------------------------- > I want to see a domain in the nodelist IE user@proteus.demon.co.uk for > me, along with flags indicating my capabilities IE SMTP mail transfers. Excuse me, but I fail to see the way (other than final hop delivery) SMTP capabilites are useful for Fidonet. > I want people to look in the nodelist (or automated software to this) > and know that they can reach my fido node by SMTP or Email. Fidonet is more than sending (e)mail messages. Yes, netmail is a very basic and the most important thing, but we cannot forget about all the other stuff we become used to - echomail, freqs etc. Forgive me if it sounds rude, but I consider your idea quite wrong. > There are thousands of nodes that have an internet account, this > information should be incorporated into the nodelist, not ignored. Nope. These are not nodes. These are sysops. And IMHO that's major difference. For example, I can hardly imagine a hub having an address of "user@domain". How do I route mail to another user via this hub? How do I route files? > Plain IP nodes are few and far between. If "far between" stands here for "physically a long way apart" I dare to say it's irrelevant. One very important question: do you agree we should look at the Internet only as a carrier media? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #275 [1995] Scn From : Slava Filimonov 2:469/33 04 Oct 97 11:41:12 To : maciej grzeszczuk 06 Oct 97 07:07:46 Subj : IP-access ------------------------------------------------------------------------------- Hello maciej! 01 Oct 97 23:08, maciej grzeszczuk wrote to Lech Szychowski: mg> my mistake. let telnet (vmodem) be the standard of protocol all ip mg> nodes have to support. we can use emsi, or whatever we want to over mg> this connection. Why vmodem ? why add functionality to fido-over-ip which already built-in tcp-ip ? Why just not to start use simple,fast,reliable protocol like binkp/d instead vmodem ? If u have 2mb ip link - it's not a big deal, but if you have poor ip u can have _big_ troubles with timeouts/resending/etc associated with vmodem/modem-style emsi + zmodem|*modem protocols ? You definitevly don't need all that stuff. Want to keep old-fasion functionality? Switch to new protocol and standart on fido-over-ip is not hard as it seems to be. By not giving up with old unnesessary stuff for fido-over-ip we'll pay at least twice in software complexity/reliability in future... // C0PiRATE Cy.b33r.Net // slf@mrp.cz // www.geocities.com/SoHo/9669 --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #276 [1995] Scn From : Lech Szychowski 2:480/33.7 05 Oct 97 05:20:00 To : Ward Dossche 06 Oct 97 07:07:48 Subj : IP-connectivity ------------------------------------------------------------------------------- > I would like to expand your words of "IP network" to "any carrier > technology allowing a Fido-session". Sure. I especially appreciate "Fido session" stated explicitly here. This might help us to get rid of the SMTP and FTP (and in general all server-client model protocols) beding considered as candidates for adoption as standards :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #277 [1995] Scn From : Lech Szychowski 2:480/33.7 05 Oct 97 05:15:00 To : Ward Dossche 06 Oct 97 07:07:48 Subj : A bit of steering ... ------------------------------------------------------------------------------- > If as some imply you also want to push for working with another list > which is managed outside the Fidonet structures, then I have nothing > left but to wish you sweet dreams ... because ... over my dead body! > The core of Fidonet is the nodelist, think twice about that. I know. And I agree. Then let's talk about the solution Bjoern Hansen suggested - no FQDNs nor IP addresses in nodelist, all Internet related/specific data kept in DNS records with the natural/obvious Fido address <-> FQDN translation scheme. Correct me if I'm wrong, but z2.fidonet.org. domain is actually managed by Fido members, right? Then I think we can safely consider this domain as being managed inside Fidonet structures. Furthermore, if we stick to the rule "delegate subdomains only when a Fidonet member is to be the person responsible for this subdomain" all management is still kept within Fidonet. DNS maintainers will be appointed by ?Cs and formally it would be the ?C's responsibility to keep the DNS up to date with nodelist. This solution IMHO has some very important advantages. First, it requires no changes in the nodelist format; yes, we need new flags to indicate new capabilities, but I doubt it will make the flags field too long - please remember we do not have to place any IP addresses or FQDNs there. Second, it uses an existing and working mechanism. Third, it isolates changes in IP-related part from the PSTN one; one can change the DNS records as often as one wants and the changes automatically become known everywhere immediately (well, actually modulo TTL, but it's also us who set the TTL, so...). Fourth, TXT records in DNS allow for accomodating any info (in textual format, but that's no problem) we might want to list additionally for any IP-node. Fifth, we can have several IP addresses listed for one Fidonet address; DNS allows for more than one A record for an entity. Anything with this idea that makes you uncomfortable? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #278 [1995] Scn From : Lech Szychowski 2:480/33.7 05 Oct 97 05:27:00 To : Ward Dossche 06 Oct 97 07:07:48 Subj : IP-access ------------------------------------------------------------------------------- > Because that would mean every IP-capable node should be listed in > extenso in the internet-tables. Yes. IMHO that's quite natural for an Internet host to be listed somewhere in DNS; if the host has an IP adddres (and it has to :), why shouldn't it have a name as well? > That means we'd have nodelist-management governed by policy-documents > which can be enforced while there'd be the management of internet-tables > on which we have no grasp from inside Fidonet. We can and we will have - ff the maintainers are Fidonet members. > It is a technical complication which in the end will be abused by > someone. Why are you so afraid that someone will abuse DNS? What's so different about nodelist that you are not afraid of letting regions manage their segments/parts while you are afraid of letting them manage their subdomains? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #279 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 06 Oct 97 14:30:40 To : Lech Szychowski Subj : Standards, was: IP-connectivity ------------------------------------------------------------------------------- Hello Lech! On 05 Oct 97 wrote Lech Szychowski to Ward Dossche: >> I would like to expand your words of "IP network" to "any carrier >> technology allowing a Fido-session". LS> Sure. I especially appreciate "Fido session" stated explicitly here. LS> This might help us to get rid of the SMTP and FTP (and in general all LS> server-client model protocols) beding considered as candidates for LS> adoption as standards :) It is not a question of creating a standard, but more a kind of capability announcement to all other nodes, who have access to the internet as an *additional* carrier. As long as fido is a hobby network of privateers, we should try to exchange mail (and files) as cheap as possible for each individual member and with as less management overhead as possible. At this point of view, any discussion of a standard mailer (or protocol) for ip-connectivity is completely without sense, too. Different protocols are in use since years and will be used further, but any node should be able to use the internet as an additional carrier, where he sees an advantage. The only discussion should be, which flags will be used to show certain capabilities to other nodes with a minimum of overhead in the nodelist. Additional entries in the nodelist or a new nodelist format are not required in short term, if i.e. the system name field would be used for the fqdn (or even an ip#, if the phonenumber problem could not be resolved definitely). This could be shown for nodelist compilers by the flag "IPF" (fqdn) or IPN (IP#), while other flags specify the protocol (VMP[:3142], BND, IFC, FTP, etc.). Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #280 [1995] Scn From : Steve Woodmore 2:254/410.1 06 Oct 97 01:19:46 To : Lech Szychowski 06 Oct 97 19:10:00 Subj : IP-connectivity ------------------------------------------------------------------------------- * Replying to a message in : SAVEAREA Hi Lech Szychowski, hope you are having a nice day 05-Oct-97 04:41:00, Lech Szychowski wrote to Steve Woodmore Subject: IP-connectivity LS> Fidonet is more than sending (e)mail messages. Yes, netmail is a LS> very basic and the most important thing, but we cannot forget LS> about all the other stuff we become used to - echomail, freqs etc. LS> Forgive me if it sounds rude, but I consider your idea quite LS> wrong. I am talking about echomail, using SMTP I shift on average 10mbs/day to my downlinks. I think its very very relevant. -=> Steve Woodmore <=- --- Terminate 5.00/Pro * Origin: Moving to NET 254 :) (2:254/410.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #281 [1995] Scn From : Pedro Lima 2:362/21 06 Oct 97 01:55:10 To : Lech Szychowski 06 Oct 97 19:10:00 Subj : IP-connectivity ------------------------------------------------------------------------------- LS> Having an IP-ZMH would also make it possible for all LS> those who have no permanent connection but are dying to be an LS> IP-capable node to stay online via dialup during these hours, therefore LS> satisfying the connectivity requirement. Yes. My idea was not to have an IP-ZMH, but define the online time via the U,Txx flags (I know its use is Z2-specific so far, but perhaps we can change that?), and require a minimum of say an hour of continuous online time. LS> Let's make a list of software available, along with its capabilities LS> (protocols, platforms etc). This should give us a better background LS> for making such decisions. Ok, I agree. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #282 [1995] Scn From : Pedro Lima 2:362/21 05 Oct 97 14:43:14 To : Ward Dossche 06 Oct 97 19:10:00 Subj : A bit of steering ... ------------------------------------------------------------------------------- WD> Both in the namefield, no more no less. I believe you meant the phone field? Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #283 [1995] Scn From : Pedro Lima 2:362/21 05 Oct 97 13:15:22 To : Ger Vloothuis 06 Oct 97 19:10:00 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hi, GV> One of the reasons (not the only one) was to GV> clear the way to use 00 as a future international access code instead GV> of the current 0011. It's quite likely that if Australia is moving to an '00' international access code it will change the emergency number, as it would be very easy to mistakenly dial '000' instead of '00'. This means that the invalid '000' prefix is likely to be a good choice for our purposes. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #284 [1995] Scn From : Pedro Lima 2:362/21 06 Oct 97 01:59:00 To : Ward Dossche 06 Oct 97 19:10:00 Subj : IP-connectivity ------------------------------------------------------------------------------- Hello, > Is the reference 'FTS-0001' copyrighted? WD> Yes. Ok, then we'll have to interpret what's said in P4 in a different way (as I believe it was intended in the first place anyway), or replace P4 altogether, if we want to do it 'by the book'. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #285 [1995] Scn From : Pedro Lima 2:362/21 05 Oct 97 14:35:18 To : Lech Szychowski 06 Oct 97 19:10:00 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hi, LS> I opt for a separate flag, to make software more easily created and LS> more robust; Yes, I agree. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #286 [1995] Scn From : Pedro Lima 2:362/21 04 Oct 97 21:44:40 To : maciej grzeszczuk 06 Oct 97 19:10:00 Subj : IP-access ------------------------------------------------------------------------------- mg> all the existing mailers need conversion in both cases - my flag-idea, mg> and yours use-phone-number-field. so we can create something mg> incompatible, and let authors of software modify their mailers to mg> support our solution. You're forgetting what's probably the commonest situation, i.e., FidoNet nodes who do *not* have IP access. There's no need for these nodes to change their software, as long as we don't mess up the standards too much. Placing lengthy flags would do precisely that, IMO. mg> my idea has one advantage - it allows both pstn and ip nodes within mg> one entry, with one node number. no problem with mail addressing, mg> packing, and so on... and it reduces the lenght of the nodelist, as we mg> don't have to duplicate sysop's name, site, system's name, etc... The ghost of nodelist size is dimmer and dimmer, as computing power and disk space becomes cheaper. The advantage of including both PSTN and IP nodes in one entry is misleading, IMHO, because it's inflexible given the current nodelist format. How should we deal then with the inclusion of other network technologies? The standard procedure should foresee this possibility, at least until we have a better nodelist format allowing for multiple declarations in one entry. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #287 [1995] Scn From : Pedro Lima 2:362/21 06 Oct 97 01:57:40 To : Lech Szychowski 06 Oct 97 19:10:00 Subj : IP-connectivity ------------------------------------------------------------------------------- LS> as a matter of fact, UUCP was created just to achieve what LS> we want now: moving files and mail between nodes. Plus the fact that it's a store and forward technology, much like FidoNet's. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #288 [1995] Scn From : Pedro Lima 2:362/21 05 Oct 97 13:08:04 To : Steve Woodmore 06 Oct 97 19:10:00 Subj : IP-connectivity ------------------------------------------------------------------------------- Hello, SW> This is becoming very circular. There were two issues in discussion, a main issue, which is whether e-mail can be used as a FidoNet session protocol or as a carrier for one, and another one which is to know if it would be possible to send e-mail to an IP address when that system (or to be more precise, that interface) is disconnected. I have now the answer to the latter which is what we were lately talking about (so it's over now, no circle), and regarding the former, I don't see e-mail as a possibility for supporting a FidoNet session protocol. This means that I'm against e-mail only FidoNet nodes, but I'm *not* against declaring e-mail capability in a nodelist entry and, as long as a previous arrangement is made, this may make possible for two nodes to exchange Fido mail via e-mail. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #289 [1995] Scn From : Pedro Lima 2:362/21 05 Oct 97 14:50:02 To : Lech Szychowski 06 Oct 97 19:10:00 Subj : IP-access ------------------------------------------------------------------------------- LS> This problem can be partially solved by creating more DDNS LS> servers servicing a smaller number of nodes; regional/netional LS> subdomains of Z2 seem to be a natural/obvious choice. Agreed, but we're only talking about the z2.fidonet.org domain. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #290 [1995] Rcv Scn From : Pedro Lima 2:362/21 06 Oct 97 02:01:26 To : Lothar Behet 06 Oct 97 19:10:02 Subj : IP-Test 2:2/3000 ------------------------------------------------------------------------------- Hello, LB> What is the cause for the IP-flag on some of the test nodes? IMHO, the IP flag (or IP4) should be placed in all these nodes. This would allow for easier filtering with non-IP mailers and for identifying the possibility with IP mailers as well. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #291 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 06 Oct 97 20:40:38 To : Pedro Lima Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Pedro! On 05 Oct 97 wrote Pedro Lima to Ward Dossche: WD>> Both in the namefield, no more no less. PL> I believe you meant the phone field? There are several advantages in using the system name field: 1. As it is impoosible to put a fqdn in the phone field (due to makenl primarily), the system name field accepts both (fqdn or ip#). As far as only one of both is needed, this one field offers maximum flexibility. 2. there is no dial translation problem in that case. 3. No seperate nodelist entry for the additional ip-capability is needed. As you can see, all vital information (ip and pstn) is handled within a single nodelist entry, as long as the flags are clearly defined. As a hint for nodelist-compilers a flag IPF (->fqdn) or IPN (->ip#) may be defined, but at moment i know no program, which handles these differently. (Or just IP for FQDN/IP# in the system name field). We can concentrate now on a complete list of capability flags. If this handled as fast as this, we can gain full ip-support even within this year, as nodelistcompilers can work with this spec. On long term we can specify an advanced nodelist format, which might contain all information (even for a multiline-system with different protocols) in a single entry. Regards Lothar PS: This may be a quick and dirty solution, but in fact we can work with it on a very short term without any interference to existing software and without any annoying side effects to not especially prepared sysops :) --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #292 [1995] Scn From : Marco d'Itri 2:335/680.666 06 Oct 97 14:20:06 To : maciej grzeszczuk 07 Oct 97 00:07:26 Subj : Re: IP-access ------------------------------------------------------------------------------- krap@zwieracz.psych.uw.edu.pl wrote: >because people using mailers that supports raw connections are able to use >vmodem connections too. vmodemers not nessesarilly can support raw ones. I agree, you correctly described the current software situation, even if it's really stupid to use the telnet protocol when it's not needed. But I think we should also support binkd (let's say it better: the binkp protocol, supported by binkd and argus) as an alternate standard because it's free software, we have the source, it runs on nearly all platforms and it's faster than ftn handshake over telnet (please don't call it "vmodem", the vmodem protocol is a different and proprietary thing). -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #293 [1995] Scn From : Marco d'Itri 2:335/680.666 06 Oct 97 14:41:08 To : Lech Szychowski 07 Oct 97 00:07:26 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >Point taken. Question: do we need separate flags or can it be >self-evident (actual address length)? I opt for a separate The mailer does not needs to know if the protocol is IPv4, IPv6, SLIP or PPP. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #294 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 06 Oct 97 14:13:52 To : Lothar Behet 07 Oct 97 00:07:26 Subj : Re: IP-Test 2:2/3000 ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: >What is the cause for the IP-flag on some of the test nodes? It's used to force non IP mailers to never call those nodes. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #295 [1995] Scn From : Marco d'Itri 2:335/680.666 06 Oct 97 14:33:52 To : maciej grzeszczuk 07 Oct 97 00:07:26 Subj : Re: IP-access ------------------------------------------------------------------------------- krap@zwieracz.psych.uw.edu.pl wrote: >my idea has one advantage - it allows both pstn and ip nodes within one >entry, with one node number. no problem with mail addressing, packing, and so >on... If we have to radically change the nodelist we could use the extended nodelist proposal, it address this problem even better. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #296 [1995] Scn From : Marco d'Itri 2:335/680.666 06 Oct 97 14:39:48 To : maciej grzeszczuk 07 Oct 97 00:07:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- krap@zwieracz.psych.uw.edu.pl wrote: >not change, but also allow vmodem connections. the standard that all ip nodes >would accept shoudl be one. If we must have just one standard, this standard should be binkp, not telnet. Using telnet, emsi and zmodem over an IP link is a very stupid decision, zmodem and EMSI (or FTS-1) are not intended to be used over a low latency link. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #297 [1995] Scn From : Marco d'Itri 2:335/680.666 06 Oct 97 14:31:12 To : Tobias Ernst 07 Oct 97 00:07:26 Subj : Re: IP-access ------------------------------------------------------------------------------- Tobias.Ernst@f418.n2476.z2.fidonet.org wrote: >any traffic in the whole Z2. ;-). We should maintain more than one DNS >computer, on the one hand for backup purposes, on the other hand to reduce >traffic for each individual one. The DNS system already supports multiple name servers for the same zone, there is no need to worry about that. >Besides rewriting the mailers, we probably will have to write a software >which allows end nodes to automatically register their IP numbers and >which distributes the configuration to all Z2 DNS systems. The "automatic" distribution of zone data is a feature of the DNS protocol, local (=net level) DNS operators will have to develope some protocol to update zone data, like the internic does. Anyway I think your solution is too difficult to implement. If we require that all mailers will have to be modified to support IP (instead of using a special communication driver) we could as well modify nodelist compilers and distribute an IP nodelist to be merged with the PSTN one. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #298 [1995] Scn From : Marco d'Itri 2:335/680.666 06 Oct 97 14:22:58 To : Lech Szychowski 07 Oct 97 00:07:26 Subj : Re: IP-access ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >listed in its nodelist entry, we can define "IP" as a "don't dial" >flag and... Too bad not all mailers support this. Those mailers does not supports ISDN only nodes and high speed only nodes too. I think sysops who use old software will have to disable automatic calls for crashmail or live with the problem. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #299 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 07 Oct 97 00:20:26 To : Marco d'Itri Subj : IP-Test 2:2/3000 ------------------------------------------------------------------------------- Hello Marco! On 06 Oct 97 wrote Marco d'Itri to Lothar Behet: >> What is the cause for the IP-flag on some of the test nodes? MI> It's used to force non IP mailers to never call those nodes. All or just some of them? :) How do you tell the uninformed (older) mailer, that it definitely must not call these lines? I would interprete "IP" as an readable flag, which helps simple grep-subset programs (like FIND) and humans for searching ip-capable nodes in the first instance. As Ward selected the system name field to be the relevant field for fqdn or ip-address, i see no further need for "normal" pstn line exclusions except the above mentioned. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #300 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Oct 97 00:40:00 To : Slava Filimonov 07 Oct 97 07:06:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Have u heared anything about binkd protocol for ip fido mailer? > as simple as possible and fast enough extendable too... why a standart? Yeah, I'm quite aware of that. But IMHO it has one big disadvantage when compared to vmodem etc - it's a completely new design; although I have to admit it might be advantageous from some point of view. > we've already using it at least for half year and there are at least > 200 nodes which supports it... I dare to say that vmodem has been around for much more than half a year. And I dare to say that this issue should not be raised when it comes to setting a new standard; we should rather concentrate on finding the best solution - and here "best" not necessarily means "convenient for a number of nodes". Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #301 [1995] Scn From : Rune Johansen 2:210/20 05 Oct 97 21:34:12 To : Lech Szychowski 07 Oct 97 07:06:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> If a minimum protocol is to be used, I would vote for telnet. > Why not a "raw socket"? Because of that we should consider a possibility that there is a BBS running behind the mailer. Telnet is a "universal" tool on most platforms, and can be used by endusers to connect to the BBS. If we use raw socket as minimum protocol (if it should be some minimum protocol), they have to use specific software to connect. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #302 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Oct 97 01:21:00 To : Sean Rima 07 Oct 97 07:06:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > calls. Another reason that TelNet should not be considered is that some > IPmailers operate on a shell account and the only way to change any > settings is to TelNet in. Telnet is a protocol. Nobody says telnet servers have to listen just on port 23. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #303 [1995] Scn From : Rune Johansen 2:210/20 05 Oct 97 21:39:30 To : Pedro Lima 07 Oct 97 07:06:42 Subj : A bit of steering ... ------------------------------------------------------------------------------- >> That's why a IP flag should be there too. > Yes, I noticed it the day after, sometimes I'd better go to bed instead > of answering mail... :-) How about IP4 and IP6 as flags? To my knowledge, a DNS lookup on a hostname will return the specific IP address, wether it is a v4 or v6 style address. It all boils down to the IP stack you have to your service at your local workstation. These two protocols are bound to be running side by side for many years to come, so the routing part of it would not be not be applicable ween from an application point of view that we are. IPv6 is already being used for trunk lines in the internet, encapsulating IPv4 packets in them. That will also be the situation several years from now. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #304 [1995] Rcv Scn From : Rune Johansen 2:210/20 06 Oct 97 09:44:54 To : Lothar Behet 07 Oct 97 07:06:42 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- >> The dial translation will put the international access code in front >> of the listed phone number. With the ITU recommended international >> access code of 00 the dialer would translate a listed number starting >> with 0 into triple 0. > Please tell this to those people, who mourne about dial translations :) Wich country have got 00 as international access code _and_ 000 as emergency number? I doubt that there is any country that has got that. Australia has got 000 as emergency number. What is their international access code? The same for england: If their emergency number is 999, then you can be sure that their international access code is _not_ 99. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #305 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Oct 97 00:53:00 To : Slava Filimonov 07 Oct 97 07:06:42 Subj : IP-access ------------------------------------------------------------------------------- > but if you have poor ip u can have _big_ troubles with timeouts/ > resending/etc associated with vmodem/modem-style emsi + zmodem|*modem Timeouts etc can be tweaked in any way you see necessary. You have full sources available and there is nothing to stop yoy from implementing things in a way that takes care of the IP-link specific stuff. > protocols ? You definitevly don't need all that stuff. Want to keep What about using UUCP in these cases? Its implementations have been around for many years and have already proven itself useful and reliable. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #306 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Oct 97 01:05:00 To : Denis McMahon 07 Oct 97 07:06:42 Subj : IP-access ------------------------------------------------------------------------------- > No it would not, the administration would have to be done by whoever > maintained the dns at the level concerned. Most NCs, RCs etc have no > access to the DNS for z2.fidonet.org. I'm pretty sure that if someone runs a leased line connected system he can either set up a DNS server himself or find another Fidonet IP node that will be happy to host his entry. I believe ?C's responsibility does not imply he has to do all the nodelist-related stuff himself; his job is to make sure all the updates are correct and passed up the structure. C'mon, let's be consistent. At one time we think about allowing in the nodelist things so loosely connected with Fido as Internet email addreses, then at another time we are reluctant to let anyone other than ?C to maintain things so loosely connected with Fido as DNS records. If some region/net sc*ews up its MX, then it's this region's/net's fault and it's just this region/net that will not get its mail. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #307 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Oct 97 01:17:00 To : Tobias Ernst 07 Oct 97 07:06:42 Subj : IP-access ------------------------------------------------------------------------------- > ABH> as you are 2:2487/4000 --> f4000.n2487.z2.fidonet.org then > ABH> search it on DNS. > This would require every existing mailer to be rewritten in a way to > support IP-flags and to calculate the FQDN out of the node number. True. But I think it's worth it. And all I can say is that I second your opinion on this solution as the most elegant and easy to introduce without breaking any existing software etc. > Well, this just shifts to the point that a crash of the DNS computer > will stop any traffic in the whole Z2. ;-). We should maintain more than > one DNS computer, on the one hand for backup purposes, on the other hand > to reduce traffic for each individual one. Common practice and recommendations (I'm not sure if it's a requirement, but I wouldn't be suprise if it is) say "there shall be at least two nameservers for each domain". > Besides rewriting the mailers, we probably will have to write a software > which allows end nodes to automatically register their IP numbers and > which distributes the configuration to all Z2 DNS systems. I don't think it is necessary. Putting the word "Fidonet" aside for a moment, all we are talking about here is a standard domain with delegated subdomains etc, and dealing with it differs in no aspect form dealing with any other Internet domain: you want a DNS record added/removed/changed, you contact the relevant domain administrator and he makes the changes. Secondary servers will then automatically update their databases when either refresh period elapses or (in case of new DNS servers) they get notified by the primary server. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #308 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Oct 97 00:47:00 To : Steve Woodmore 07 Oct 97 07:06:42 Subj : IP-connectivity ------------------------------------------------------------------------------- > NO!, I am trying to say we should allow any node that has any form of IP > transfer available to them, be it IP FTP SMTP Tunneling or whatever, if > they can transfer mail via the internet in some form or another, then > they should be listed as such. Then I have to disagree. My Internet mail address is lech7@pse.pl, but I don't think it should ever be listed in the Fidonet nodelist. Why? 'Cause it is an e-mail address that has nothing to do with Fido (other than it can be used for sending me messages). Even more important difference between 2:480/17 and lech7@pse.pl is that the first one denotes a Fidonet system/node whilst the other one is merely an email account, and a Fidonet node is much more then a message delivery channel for a certain person. Nodelist is a list of nodes, not just a list of people and their netmail addresses. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #309 [1995] Scn From : maciej grzeszczuk 2:480/70 06 Oct 97 20:18:36 To : Pedro Lima 07 Oct 97 07:06:42 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- From: maciej grzeszczuk Wed, 01 Oct 97 17:38:14 +0200 Pedro Lima napisal byl w fido.ip_connect: > be considered as a minimal standard is not an obvious choice, although > BinkD seems to be supported in most of the platforms... binkd cannot be treated as a standard, as it's compatible only with itself. 443 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: karolina wcale nie ma worka... (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #310 [1995] Scn From : maciej grzeszczuk 2:480/70 06 Oct 97 20:41:04 To : Sean Rima 07 Oct 97 07:06:44 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Sun, 05 Oct 97 00:56:26 +0200 Sean Rima napisal byl w fido.ip_connect: > Strange, I connect to an IFCICO mailer evey day with no problems. There is an > addon for Ifcico to allow it to use BinkP which is use by BinkD if so, please tell me the location i can find the patch to my ifcico mailer. and to other vmodem fossils, that are allowing use of all mailers that you can imagine. > Having used EMSI connections across the net, I would not like to go back to > it. using emsi over tcp about 30-40 times a day, and haven't noticed any problems with slow handshaking, nor dropped connections. > reason that TelNet should not be considered is that some IPmailers operate on > a as a telnet available mailer i assume a mailer that support direct telnets onto port 23 of specified machine. 449 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: halt! (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #311 [1995] Scn From : maciej grzeszczuk 2:480/70 06 Oct 97 20:24:32 To : Steve Woodmore 07 Oct 97 07:06:44 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- From: maciej grzeszczuk Sat, 04 Oct 97 09:43:37 +0200 Steve Woodmore napisal byl w fido.ip_connect: > NO!, I am trying to say we should allow any node that has any form of IP > transfer available to them, be it IP FTP SMTP Tunneling or whatever, if > they can transfer mail via the internet in some form or another, then they > should be listed as such. ftp or smtp is not a way to reach the system's mailer. vmodem/ifcico/telnet connections are. 445 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: rave (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #312 [1995] Scn From : maciej grzeszczuk 2:480/70 06 Oct 97 20:32:02 To : Slava Filimonov 07 Oct 97 07:06:44 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Thu, 02 Oct 97 17:34:20 +0200 Slava Filimonov napisal byl w fido.ip_connect: > LS> Why not a "raw socket"? > Have u heared anything about binkd protocol for ip fido mailer? as simple as > possible and fast enough extendable too... why a standart? we've already > using it at least for half year and there are at least 200 nodes which > supports it... using binkd of course. other mailers are not allowed. > binkd - multiplatform ip fido mailer and vmodem is a standard for all existing platformes. and it allowes you to use ANY MAILER you want to. systems that are connecting to my node are using t-mail, frontdoor, portal of power, i've already seen two amiga mailers (i don't remember the name of them), all unix mailers are also compatible. binkd isn't compatible with any of the stuff listed, and more - it isn't compatible with anything else. and it won't. > bwt, this echo comes to me through binkd. this echo comes to me through raw emsi via tcp. 446 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: lege mortis? to chyba jakis owad... (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #313 [1995] Rcv Scn From : maciej grzeszczuk 2:480/70 06 Oct 97 20:37:00 To : Lothar Behet 07 Oct 97 07:06:44 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Sat, 04 Oct 97 16:47:44 +0200 Lothar Behet napisal byl w fido.ip_connect: > mg> sure, binkd exist on many platforms, but it's only one mailer, > Furthermore the protocol specification is available and therefore will be > supported by other programs in near future :) binkd exist for about a year or two, and i don't see any mailers supporting that 'standard'. > mg> not a standard of virtual modem. with vmodem i can use any mailer. at > mg> any system. > As far as i know, Vmodem is only supported for OS/2 and the protocol > specification is not available. > I would be happy to be corrected on this matter :) vmodem is supported on all software / hardware platforms. all unix mailers easily allowes vmodem incoming/outgoing connections, as well as the amiga, or win95/winnt ones. i've tried it. it succeded. > But the listed nodes must support ip-connectivity either CM or at least at > clearly specified online times, otherwise they should not be listed with > ip-flags on seperate or regular (PSTN) lines. agree with that. 448 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: > a myslisz, ze skad sie wzielo krap? > z morski (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #314 [1995] Scn From : maciej grzeszczuk 2:480/70 06 Oct 97 20:22:42 To : Denis McMahon 07 Oct 97 07:06:44 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- From: maciej grzeszczuk Thu, 02 Oct 97 14:01:29 +0200 Denis McMahon napisal byl w fido.ip_connect: > VModem transfers use FTN protocols over an ip connection as opposed to an > analogue one. > Telnet connections are IMHO BBS level, and whilst it might be of human > interest that a BBS is telnettable, it has no strict nodelist impact as > machines do not telnet to each other, rather people telnet to remote > machines. wrong. telnet connection allows you to directly access mailer as well as vmodem connection. automatically. fe. i can use my mailer, ifcico, to access fidonet mailer (available via telnet) on port 23 of sample.host.domain: ./ifcico -t 1 -a sample.host.domain:23 f70.n480 i used it for about 3 months with 2:350/12. they used frontdoor 2.20 on port 23 of bol.bg. 444 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: ...tak, tak, lubie tak, lubie kiedy robisz tak... (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #315 [1995] Scn From : maciej grzeszczuk 2:480/70 06 Oct 97 20:42:24 To : Sean Rima 07 Oct 97 07:06:44 Subj : Re: BinkD (0.9.2) specification ------------------------------------------------------------------------------- From: maciej grzeszczuk Thu, 02 Oct 97 22:32:42 +0200 Sean Rima napisal byl w fido.ip_connect: > Due to comments about BinkD not being allowed into the proposed Nodelist, > here are the specs for the next release of BinkD. allowed, but not as only protocol that ip node supports. 450 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: rumun i cygan to ta sama osoba! (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #316 [1995] Rcv Scn From : maciej grzeszczuk 2:480/70 06 Oct 97 20:45:34 To : Lothar Behet 07 Oct 97 07:06:44 Subj : Re: IP-Test 2:2/3004 ------------------------------------------------------------------------------- From: maciej grzeszczuk Sat, 04 Oct 97 02:15:50 +0200 Lothar Behet napisal byl w fido.ip_connect: > Only CM-Systems should be used at this moment for the IP-Test or at least > appropiate Txy flags must be published. > Furthermore the IP-Test-nodes should enable the address as soon as possible. 2:480/70 aka 2:48/70 is CM ip/pstn node, allowing connections on ports 60177 (vmodem) and 60179 (raw socket). addresses (independant ones, choose the one is faster for you) are: zwieracz.psych.uw.edu.pl (148.81.141.17) and zwieracz-tp.psych.uw.edu.pl (195.117.131.17). you can easily use it for all testing purposes. 451 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: > a myslisz, ze skad sie wzielo krap? > z morski (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #317 [1995] Scn From : maciej grzeszczuk 2:480/70 06 Oct 97 21:07:20 To : Ward Dossche 07 Oct 97 07:06:44 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- From: maciej grzeszczuk Sat, 04 Oct 97 11:59:10 +0200 Ward Dossche napisal byl w fido.ip_connect: > > > a/ ,U,IP(ADR) flag, that would carry the address. (imho the best idea) > This is not my opinion. You'd have a serious problem defining then IP-only > nodes. -unpublished- in the phone field. > > b/ create another entry in the nodelist (with separate nodenumber), that > > would carry all the information that primary does, but have address > > in the phone field (we're duplicating a lot of data then) > There is a duplication-element, but that is unavoidable. Things must remain > manageable. avoidable when using IP flags. but ip flags project is absolutelly incompatible with all the existing software, and may cause some makenl problems. > Putting the address in the phone-field and otherwise treat it as a regular > entry is the most simple and easy. i agree, but: 'dot' should be allowed in phone field. as only in this way the existing mailers would use the nodelist properly. 453 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: ps. polewiak pewnie jest juz w lodzi... (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #318 [1995] Scn From : Lawrence Garvin 1:106/6018 05 Oct 97 18:20:08 To : Mats Wallin 07 Oct 97 07:06:44 Subj : IP-connectivity ------------------------------------------------------------------------------- Mats Wallin said in a message to rafal wiosna: MW> There is no requirement that everyone should be able to connect to MW> everyone else using any type of analogue modem they want to. They MW> need to use the correct equipment if they want to be able to MW> connect. I think it's worth noting that while Policy 4 specifies that a node must be able to negotiate an FTS-0001 session during ZMH to maintain eligibility for listing, there is nothing in Policy 4 which suggests, or mandates, what the minimum -MODEM- negotiation must be to maintain that connection. Ergo... if the NC chooses to use the aforementioned 300bps modem, or perhaps more practically, a 16.8HST modem, that NC has automatically isolated certain nodes in his/her net from being able to establish a session with that NC, even though the node may have a perfect FTS-0001-compliant mailer in operation. Because P4 does not mandate the -telecommunications- technology which must be used, but only the -computer software capability-, I would suggest that an IP-only node that is accessible during ZMH via IP-address is fully compliant with Policy 4. Now, I'll offer a caveat to all of the above that points out that I might have missed some subtle issue somewhere concerning this scenario -- perhaps FTS-0001 in all its complicated, convoluted, language actually specifies that the FTS-0001 session must be accomplished via the PSTN. But if not, then wouldn't any FTS-0001 session accomplished via VModem or BinkD be equally as compliant? --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #319 [1995] Scn From : maciej grzeszczuk 2:480/70 06 Oct 97 20:33:16 To : Max Masyutin 07 Oct 97 07:06:44 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Sat, 04 Oct 97 14:26:12 +0200 Max Masyutin napisal byl w fido.ip_connect: > mg> not change, but also allow vmodem connections. the standard that all ip > mg> nodes would accept shoudl be one. > Do you suggest FTS-0001 session via VModem as the standard? yes. it's simple on all software / hardware platforms. 447 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: > a myslisz, ze skad sie wzielo krap? > z morski (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #320 [1995] Scn From : Lawrence Garvin 1:106/6018 05 Oct 97 18:34:52 To : rafal wiosna 07 Oct 97 07:06:46 Subj : Test of an IP-number in the nodelist ------------------------------------------------------------------------------- rafal wiosna said in a message to Mats Wallin: rw> þ (IP_PUBLIC, Mon Sep 08 1997) Mats Wallin -> Ward Dossche: MW> As far as I can tell, MakeNL does not accept that as a phonenumber. (I MW> just tried it here, and it complained about it). rw> Maybe it's time to improve MAKENL or start using another program? Now, this I think is an excellent idea -- and there are plenty of nodelist software authors still in existence writing software to 'compile' the nodelist from source to binary/index form. How much of a challenge could it be for them to write a new MAKENL type utility, that has provisions for extended telecommunications capabilities. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #321 [1995] Scn From : Lawrence Garvin 1:106/6018 05 Oct 97 18:30:10 To : rafal wiosna 07 Oct 97 07:06:46 Subj : IP addressing ------------------------------------------------------------------------------- rafal wiosna said in a message to Alberto Pasquale: rw> þ (IP_PUBLIC, Sat Aug 23 1997) Alberto Pasquale -> Ward Dossche: AP> ;S ,bbs.os2net.net,300,IP,VM - AP> ;S ,bbs.os2net.net,300,VM AP> ;S ,bbs.os2net.net,300,IP - rw> Does MAKENL.EXE get upset when processing such entries? If rw> yer, what do they use? It did here, when I tried placing something like this in my source segment: IP:198*216*61*12 I got a message about "illegal characters" in the telephone field. Although I've not specifically verified this, I suspect there is a strictly defined set of characters that MAKENL will accept in this field. My alternative to this, which I asked for input in FN_SYSOP, but, alas, got none, was to identify an unallocated prefix code -- preferably a code combination that would never be allocated in international telco service -- and adopt that prefix code, by convention, to be an identifier for an IP address. I believe the asterisk, however, should be an acceptable character, though once again I've not verified this, since it is defined as one of the twelve keys on a DTMF keypad. I fully expect that in my situation, it was the "IP:" which MAKENL found objectionable. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #322 [1995] Scn From : Lawrence Garvin 1:106/6018 05 Oct 97 18:33:56 To : rafal wiosna 07 Oct 97 07:06:46 Subj : IP-connectivity ------------------------------------------------------------------------------- rafal wiosna said in a message to Mats Wallin: rw> þ (IP_PUBLIC, Mon Sep 08 1997) Mats Wallin -> Pedro Lima: MW> system. This means that there somewhere in the region has to be a MW> system with both IP and modem access. rw> Well... It's implied. What's the reason for a net that has rw> no gate to PSTN/ISDN world?... Perhaps a workable solution is to ask NC's to create a HUB entry for such systems that are "dual homed" (IP and PSTN), with the agreement that the HUB will assume responsibility for gating/routing mail between the PSTN and IP worlds. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #323 [1995] Scn From : Lawrence Garvin 1:106/6018 05 Oct 97 18:25:34 To : Lech Szychowski 07 Oct 97 07:06:46 Subj : IP-connectivity ------------------------------------------------------------------------------- Lech Szychowski said in a message to Mats Wallin: > Just because you're using Internet to connect to your hub/host doesn't > mean that you're not interested in being a member of FidoNet, which for > instance makes it possible to vote in elections. LS> True enough. But let's put it this way: a non-permanent IP/FQDN LS> assignment implies dialup connection which implies system equipped LS> with a modem and having access to PSTN line which in turn implies LS> if system operator really wants to be a node he can very well LS> become a traditional technology based one. A good point. :) Especially since we're only talking about one hour out of the day to be configured in answer-capable mode. LS> Lets face it: DNS in its present shape does not provide much room LS> for permanent assignment of FQDN to a dynamically changing IP. Furthermore, with the (some say abuse) of DHCP, it's possible that more and more IP-based systems will have dynamic addresses, even where they did have permanent addresses before. Note, I'm not necessarily a proponent of this scenario, but I am a realist. :) On the other hand, if Fidonet could establish a CNAME registry between the old style naming zone#.net#.node#.fidonet.org and an actual DNS registered name, then a mere modem flag (say, UIP) could be used to override the telephone field in the source nodelist, and construct a usable domain name of the aforementioned form: zone#.net#.node#.fidonet.org -- without having to even store the actual DNS naming information in the nodelist. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #324 [1995] Scn From : Lawrence Garvin 1:106/6018 05 Oct 97 18:52:00 To : Rune Johansen 07 Oct 97 07:06:46 Subj : IP-access ------------------------------------------------------------------------------- Rune Johansen said in a message to Mats Wallin: RJ> Been looking a little on different rfc's now.. No, you can't have RJ> two different protocols on the same port number. It would be up to RJ> the server to distinguish a telnet protocol from a VModem protocol, RJ> by having some kind of "I want VModem" in the negotiation after the RJ> TCP sessions has been established, and falling back to telnet RJ> protocol if that does not come in. RJ> I don't know the VModem _protocol_, so I cannot say wether it can RJ> or not. Actually, isn't it the responsibility of the -client- to choose which port to initiate the session against? If I "telnet 23" then the telnetd on port 23 answers. If I "telnet 3141" then the vmodemd on port 3141 answers. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #325 [1995] Scn From : Lawrence Garvin 1:106/6018 05 Oct 97 18:44:40 To : rafal wiosna 07 Oct 97 07:06:46 Subj : what about... ------------------------------------------------------------------------------- rafal wiosna said in a message to all: rw> Or even better. We could put CNAME/IP in the _NAME_ field rw> of nodelist entry. It'd shorten the nodelist a bit. This way only rw> "U,NET" flag would be required [or better yet, mailer could assume rw> that the node's net-able whenever either TCP or VMODEM flag is rw> present]. This way software would know that it should resolve the rw> systemname field to satisfy socket functions. I'd suggest using the _NODENAME_ field, as opposed to the _SYSOPNAME_ field (please excuse my probably inaccurate use of field names), since my Node Name is really irrelevant to the nodelist, but my Sysop Name is critical to many mail readers. Or, perhaps an even more appropriate field, the -CITY- field -- after all, who cares where the city is in cyberspace. Perhaps, though, that is what you meant above. :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #326 [1995] Scn From : Lawrence Garvin 1:106/6018 05 Oct 97 18:45:44 To : rafal wiosna 07 Oct 97 07:06:46 Subj : what about... ------------------------------------------------------------------------------- Following up a message from maciej grzeszczuk to rafal wiosna: > Proposals for nodelist entries: > ,99,Im_dialable,Somewhere,John_Doe,12-34-567890,9600,...,U,NET,host.domain, > VMODEM,TCP > ,99,Im_not_dialable,Somewhere,John_Doe,0,300,U,NET,host.domain,VMODEM,TCP > ,99,Im_not_dialable,Somewhere,John_Doe,0,300,U,NET,123.45.6.78,VMODEM,TCP > ,99,host.domain,Somewhere,John_Doe,12-34-567890,9600,...,U,NET,VMODEM,TCP > ,99,host.domain,Somewhere,John_Doe,0,300,U,NET,VMODEM,TCP > ,99,123.45.6.78:7666,Somewhere,John_Doe,0,300,U,NET,VMODEM,TCP > ,99,host.domain,Somewhere,John_Doe,0,300,U,TCP Or, perhaps, as alluded to in the previous message: ,6018,The_Enchanted_Forest,bbs.eforest.houston.tx.us,Lawrence_Garvin,etc. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #327 [1995] Scn From : Lawrence Garvin 1:106/6018 05 Oct 97 18:37:00 To : Ward Dossche 07 Oct 97 07:06:46 Subj : IP-connectivity ------------------------------------------------------------------------------- Ward Dossche said in a message to rafal wiosna: WD> Rafal, WD> > What is the reason for becoming yet one more of the > internet-based nodes? In my opinion, there should be 2-3 NODES in the > internet area per region acting as Fido<->net gates [and being DIALABLE] > and the rest should be just points. WD> What you are telling here is that there should be a government WD> telling the people what is good for them while denying them access WD> to the things what they think themselves are good for them. Sound WD> familiar? Perhaps I can temper this idea with a thought from the side of volunteerism. I think that those of us (like myself) that are fortunate enough to have both PSTN and IP capabilities, ought to take it upon ourselves to engender the development of IP-capable FTN nodes, by volunteering to act as the 'bridge' that rafal suggests. I saw rafal's comments more as a way to create a workable solution without -requiring- that all IP-capable nodes be obligated to maintain a PSTN connection, just to be nodelisted. WD> The technology is there and the people that want it are there, I WD> see no reason to deny anyone to choose the technology he/she wants. Agreed. And I think that you and rafal are headed the same way on this point. I took it that rafal was merely trying to offer a workable solution to allow each sysop to actually execute their choice of technology. Those of us that have -both- capabilities, and -choose- to have both capabilities, should also -choose- to act as a 'bridge' between the two. Kind of a quid-pro-quo to benefit our own agenda. :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #328 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 07 Oct 97 08:43:42 To : maciej grzeszczuk Subj : IP-connectivity ------------------------------------------------------------------------------- Hello maciej! On 06 Oct 97 wrote maciej grzeszczuk to Pedro Lima: mg> binkd cannot be treated as a standard, as it's compatible only with mg> itself. ... on different platforms (Unix, Linux, OS/2, Win 95 and Win NT). Furthermore the sourcecode is (widely) available and other programs support it or will support it in the near future: - Argus has it - FrontToss is under construction :) - Beemail will support it Maybe you are talking about a completly different software world down there in Poland :) Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #329 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 07 Oct 97 08:59:32 To : maciej grzeszczuk Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello maciej! On 06 Oct 97 wrote maciej grzeszczuk to Lothar Behet: mg> vmodem is supported on all software / hardware platforms. all unix mg> mailers easily allowes vmodem incoming/outgoing connections, as well mg> as the amiga, or win95/winnt ones. i've tried it. it succeded. Could you please tell me (and others:), which products support Vmodem for PC based operating systems (DOS, Windows, Win96, Win95, WinNT) and where they are available? A software or protocol standard must be usable by most of the nodes. The standard node uses a standard pc with a standard operating system in most cases, except less than 5% (just a high guess) who work with different os and other hardware. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #330 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 07 Oct 97 09:36:20 To : Lawrence Garvin Subj : what about... ------------------------------------------------------------------------------- Hello Lawrence! On 05 Oct 97 wrote Lawrence Garvin to rafal wiosna: LG> I'd suggest using the _NODENAME_ field, as opposed to the _SYSOPNAME_ LG> field (please excuse my probably inaccurate use of field names), since LG> my Node Name is really irrelevant to the nodelist, but my Sysop Name LG> is critical to many mail readers. LG> Or, perhaps an even more appropriate field, the -CITY- field -- after LG> all, who cares where the city is in cyberspace. If you are looking for a routing system, which supports a specific protocol, the geographical location gives a you hint for a mostly satisfactory routing. Therefore i prefer the system name field, as this contains the least necessary information in the nodelist and as a character field accepts any kind of information :) The flag space is limited (doesn't matter if it's 32 or 63 characters), but should remain readable for the necessary protocol information. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #331 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 07 Oct 97 09:47:12 To : Lech Szychowski Subj : IP-access ------------------------------------------------------------------------------- Hello Lech! On 06 Oct 97 wrote Lech Szychowski to Slava Filimonov: >> but if you have poor ip u can have _big_ troubles with timeouts/ >> resending/etc associated with vmodem/modem-style emsi + >> zmodem|*modem LS> Timeouts etc can be tweaked in any way you see necessary. You have LS> full sources available You are not talking about Vmodem from Ray Gwinn's SIO package for OS/2? Which other implementations of Vmodem are available for other operating systems and especially where is the source published? LS> What about using UUCP in these cases? Its implementations have been LS> around for many years and have already proven itself useful and LS> reliable. Mail based protocols are buffered, so in that case you never know, when a message reaches the destination. Further more stored packets can easily be messed up, which is not possible in a direct connection between mailers. These indirect capabilities (mail based and FTP) should be shown by a flag, but should focus for normal operations on direct connections. As there are at least 3 different protocols widely spread, all three should be used for the next future. Ifcico is mainly based on Unix systems, Vmodem (as far as I know) strictly bound to OS/2 and BinkP receives more and more implementations in other programs. BinkD (the mailer with BinkP) itself is available for OS/2, different Unix dialects, Win 95 and NT (Not to forget the publicly available source code). Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #332 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 07 Oct 97 11:03:22 To : Ward Dossche Subj : Standards, especially Vmodem ------------------------------------------------------------------------------- Hello All! Just a short notification about standards (from Vmodem.Txt, Author Ray Gwinn): >-8------------------------ byte here ------------------------8-< The Virtual Modem Protocol (VMP) that is implemented by Vmodem uses TCP/IP Sockets. The default port number used by Vmodem is 3141 (the first 4 digits of pi, un-rounded). However, this default port number can be overridden by using the SERVICES file in the TCP/IP ETC directory. If the user defines a "Well-Known Port" called "vmodem" (lower case) in the SERVICES file, then that port will be used instead of 3141. The port number 3141 has been assigned to the Virtual Modem Protocol (VMP) by the Internet Assigned Numbers Authority (IANA). The name associated with port 3141 is "vmodem" (without the quotes). Likewise, the Telnet Server in Vmodem can be directed to use any port number by adding a "Well-Known Port" called VMOTelnet to your SERVICES file. The Telnet Server defaults to port 23 (the standard Telnet port). >-8------------------------ byte here ------------------------8-< Therefore i would prefer "VMP" above just "VM", except that several Vmodem implementations exist, which ought to be treated distinctively. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #333 [1995] Scn From : Sean Rima 2:252/356 06 Oct 97 19:15:28 To : Fyodor Ustinov 07 Oct 97 19:07:28 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Fyodor 04 Oct 97 07:21, Fyodor Ustinov wrote to maciej grzeszczuk: > Friday October 03 1997, maciej grzeszczuk writes to Sean Rima: >>> Why should I and around 180 established Ipmailers have a forced >>> change because BinkD doesn't meet VModem. I think you would find >>> that this would end as 2 standards and not one. mg>> not change, but also allow vmodem connections. the standard that all mg>> ip nodes would accept shoudl be one. > Yes. And this standart should be binkp. In the new version of Argus (3.016) BinkP is available as a protocol for incoming Telephone line calls and I believe that one or 2 other mailers are looking at it. Sean BinkD Mailer: alice.pcug.co.uk SD®¯ --- Msged/NT 4.10 * Origin: DSP BBS, Reading, Berks (2:252/356@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #334 [1995] Scn From : Sean Rima 2:252/356 06 Oct 97 19:10:56 To : Ward Dossche 07 Oct 97 19:07:28 Subj : Re: BinkD (0.9.2) specification ------------------------------------------------------------------------------- Ward, 04 Oct 97 13:28, Ward Dossche wrote to Sean Rima: >> Due to comments about BinkD not being allowed into the proposed >> Nodelist, > Who said that? Maciej Grzeszczuk (Got it wrong???) did a couple of days ago. I think I should have pointed out that I was not talking about BinkD which is the program but Binkp/1.0 the protocol, which is now in Argus for normal Teleco calls and is around 50% faster handshaking tham EMSI. Sean SD®¯NY. --- Msged/NT 4.10 * Origin: DSP BBS, Reading, Berks (2:252/356@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #335 [1995] Scn From : Sean Rima 2:252/356 06 Oct 97 19:17:20 To : Slava Filimonov 07 Oct 97 19:07:28 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Slava, 02 Oct 97 18:34, Slava Filimonov wrote to Lech Szychowski: > Have u heared anything about binkd protocol for ip fido mailer? as > simple as possible and fast enough extendable too... why a standart? > we've already using it at least for half year and there are at least > 200 nodes which supports it... > binkd - multiplatform ip fido mailer > can be downloaded at ftp.falcon.spb.su /pub/fido > Argus - fido mailer win32 with ip binkd protocol / www.ritlabs.com It is also available in the gamma version of Beemail/32. http://beemail.com Sean BinkD IPmailer: alice.pcug.co.uk --- Msged/NT 4.10 * Origin: DSP BBS, Reading, Berks (2:252/356@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #336 [1995] Scn From : Victor Prylipko 2:4635/4 07 Oct 97 11:11:44 To : maciej grzeszczuk 08 Oct 97 07:04:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello maciej! 03 Oct 97 01:23, maciej grzeszczuk wrote to Sean Rima: mg> ifcico is incompatible with binkd. binkd is incompatible with any ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mg> mailer, except itself. At this point you are wrong. binkd is compartible with Argus. mg> 412 mg> -- mg> = wasza KrAp = krap@psych.uw.edu.pl = Victor, victor@nensi.cherkassy.ua vic.pryl@rocketmail.com --- (c) Old & Gray but Young * Origin: -> ChiBis Station - 380-472-540981 21:00-08:00 (2:4635/4) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #337 [1995] Scn From : Mario Mure' 2:335/533 06 Oct 97 20:51:34 To : Fyodor Ustinov 08 Oct 97 07:04:36 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- In a message dated < 04 Oct 97 07:21:55 >, addressed to maciej grzeszczuk about < IMPORTANT! standard of protocol for ip-nodes proposal. >, Fyodor Ustinov wrote: FU> Yes. And this standart should be binkp. My vote for binkp ;-) I'm testing BinkD on agnese.fidoitalia.net [195.120.19.166] and it works great !!! Ciao ! /mario/ mure@sistemia.it --- DMreply v2.0 * Origin: Stay cool if your hard disk say goodbye (2:335/533@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #338 [1995] Scn From : Mario Mure' 2:335/533 06 Oct 97 21:20:06 To : Sean Rima 08 Oct 97 07:04:36 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- In a message dated < 05 Oct 97 01:56:26 >, addressed to maciej grzeszczuk about < Re: IMPORTANT! standard of protocol for ip-nodes proposal. >, Sean Rima wrote: SR> is an addon for Ifcico to allow it to use BinkP which is use by BinkD May I know where to find such add-on ? For linux of course ;-) Ciao ! /mario/ mure@sistemia.it --- DMreply v2.0 * Origin: errecitrentatre (2:335/533@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #339 [1995] Scn From : Lawrence Garvin 1:106/6018 06 Oct 97 20:15:46 To : Rune Johansen 08 Oct 97 07:04:36 Subj : Flags in nodelist ------------------------------------------------------------------------------- Rune Johansen said in a message to Ask Bjoern Hansen: >My suggestion: Don't include IP numbers or hostnames in the nodelist. >Just the flags. You would be reached at f27.n210.z2.fidonet.org; no >need for any other addresses. RJ> No, no, no, no. We must not be tying this to Fidonet and the RJ> fidonet.org DNS hierarchy. And why not, Rune? RJ> For that, is several reasons: What if this technique is to be used RJ> in other fidonet technology networks? Then let THEM register their own *.net or *.org domain and maintain their own DNS servers. There's nothing wrong with an FTN standard (which, btw, really only applies to Fidonet anyway, technically) mandating that the NETWORK must provide their own DNS servers in order to implement the technology. RJ> What if fidonet.org disappears? What if it does? What if -ANY- domain that somebody relies upon for internet access disappears? The answer: Somebody reregisters it! Currently George Peace is managing fidonet.org -- I highly doubt it's going anywhere in the near future, but if that's the concern, I'm sure between at least zones 1, 2, and 3, where this issue is of most significance, somebody could make arrangements to generate fifty US bucks in perpetuity to insure the domain continues to be paid for. RJ> What if I don't have DNS resolver, but only a hosts-list? Lame, Rune. DNS resolvers are available for just about every operating system platform known to the internet. You don't even have to be a zone managing node, you can put a caching-only DNS, and resolve the whole world through your own personal server. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #340 [1995] Scn From : Slava Filimonov 2:469/33 06 Oct 97 10:15:26 To : Ward Dossche 08 Oct 97 07:04:36 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Ward! 04 Oct 97 12:50, Ward Dossche wrote to Lech Szychowski: WD> If as some imply you also want to push for working with another list WD> which is managed outside the Fidonet structures, then I have nothing WD> left but to wish you sweet dreams ... because ... over my dead body! WD> The core of Fidonet is the nodelist, think twice about that. The _real_ core of Fidonet still public phone line. Nodelist is just phone directory like yellow pages in each phonebox. Guess what is the core of internet , and then think twice about that. // C0PiRATE Cy.b33r.Net // slf@mrp.cz // www.geocities.com/SoHo/9669 --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #341 [1995] Scn From : Pedro Lima 2:362/21 06 Oct 97 23:38:04 To : Lech Szychowski 08 Oct 97 07:04:36 Subj : IP-access ------------------------------------------------------------------------------- > That would be the most compatible solution, yes. But the incompatibility > of placing an IP address into the phone field and not declaring the node > as Pvt isn't technical, only procedural. LS> I we can guarantee that no mailer will generate additional cost and/or LS> trouble - dialing a "non-reachable number" being a trouble - you are LS> IMHO right. One of the important things is that the mailer should be correctly configured. However, no-one can guarantee that some mailer won't create "trouble" if the sysop commands it to modem dial an IP-entry. If the mailer doesn't support some automatic way of preventing it, the sysop should verify beforehand if the node is reachable via the technology he has available, like avoiding modem dialing an ISDN-entry. Namely this will generate a cost in those countries where you pay beginning at the moment you pick up the handset. It's impossible to guarantee in full a "peaceful" behaviour. That's why having the test addresses 2:2/3xxx is useful, and it would be important to extend these tests to all other zones as well, so we may be aware of possible problems. LS> Even better: if we assume that all mailers can differ its behavior LS> according to the flags the node they would like to connect to has LS> listed in its nodelist entry, we can define "IP" as a "don't dial" LS> flag and... Too bad not all mailers support this. True, but if the mailer isn't able to do the differentiation automatically, then the sysop should be aware of what he's doing. I'm more concerned with incompatibilities such as rendering the nodelist not compilable. LS> Don't get me wrong. All I'm trying to say is we should not accept LS> such a waste too easily. If we find no other way... well, then LS> we'll have to. But we should try very hard to avoid it. As long as the solution isn't worse than the problem, I agree. :-) Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #342 [1995] Scn From : Pedro Lima 2:362/21 06 Oct 97 13:48:20 To : Lech Szychowski 08 Oct 97 07:04:36 Subj : IP-connectivity ------------------------------------------------------------------------------- LS> I especially appreciate "Fido session" stated explicitly here. Agreed! Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #343 [1995] Scn From : Fyodor Ustinov 2:5020/79 06 Oct 97 08:21:44 To : Lech Szychowski 08 Oct 97 07:04:36 Subj : IP-access ------------------------------------------------------------------------------- Hi, Lech! Saturday October 04 1997, Lech Szychowski writes to Ask Bjoern Hansen: >> telling you accept IFC calls (default port 60179). There is no IP >> address told, but as you are 2:2487/4000 --> >> f4000.n2487.z2.fidonet.org then search it on DNS. LS> Very reasonable idea that could become even more reasonable if LS> regions/nets could have their respective subdomains delegated LS> to them. And if someone really wants to have IP-based sessions LS> with a node that for some reason has no DNS entry he can put LS> this node manually into hosts file. BTW. Any node supported binkp protocol can be published in fidonet.net domain. With best regards, Fyodor --- GoldED/W32 3.00.Alpha5 UNREG * Origin: U.F.M Station [ufm@prospect.com.ru, 1086856#ICQ] (2:5020/79) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #344 [1995] Scn From : Lech Szychowski 2:480/33.7 07 Oct 97 00:29:00 To : Rune Johansen 08 Oct 97 07:04:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Why not a "raw socket"? > Because of that we should consider a possibility that there is a BBS > running behind the mailer. Telnet is a "universal" tool on most > platforms, and can be used by endusers to connect to the BBS. If we use Using telnet protocol does not imply using WKS on port 23. One can easily have "telnetable" BBS on port 23 and some other telnet-based service on some other port. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #345 [1995] Scn From : Rune Johansen 2:210/20 06 Oct 97 21:16:46 To : Lech Szychowski 08 Oct 97 07:04:42 Subj : A bit of steering ... ------------------------------------------------------------------------------- > I know. And I agree. Then let's talk about the solution Bjoern Hansen > suggested - no FQDNs nor IP addresses in nodelist, all Internet > related/specific data kept in DNS records with the natural/obvious > Fido address <-> FQDN translation scheme. I have said this before, and I will say this again. We should not be so narrowminded to rely on "fidonet.org" DNS for implementing a conformant way of including ip-capable nodes in a nodelist. For means that will grow beyond our current view of the world, this will be unacceptable. Please, think of "othernets" too, even if you are not a member of such yourself right now (I am not, and I am not considering it either). We should not be so egoistic and self-centered. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #346 [1995] Scn From : Lech Szychowski 2:480/33.7 07 Oct 97 00:27:00 To : Pedro Lima 08 Oct 97 07:04:42 Subj : IP-access ------------------------------------------------------------------------------- > LS> This problem can be partially solved by creating more DDNS > LS> servers servicing a smaller number of nodes; regional/netional > LS> subdomains of Z2 seem to be a natural/obvious choice. > Agreed, but we're only talking about the z2.fidonet.org domain. Do you mean "as opposed to the whole fidonet.org ie we don't care about other zones" or "there will be no delegations and we have to think in terms of a zone-wide DDNS server"? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #347 [1995] Scn From : Rune Johansen 2:210/20 06 Oct 97 21:11:32 To : Ward Dossche 08 Oct 97 07:04:42 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- >> WD> Changing FTS-0001 would be fine ... but someone has a copyright on >> it >> WD> and changing the text is forbidden via that same >> copyright-statement. >> Is the reference 'FTS-0001' copyrighted? > Yes. How can that be copyrighted? A "Fidonet Technical Standard number 1" is by no means copyrightable in my views. As Randy says himself in the current FTS-0001: technical standard for FidoNet. The author did not design or specify the data formats or protocols, only attempted to document them. So, the only copyright I can see, is the combination of phrases and wording that combined add up to this document that is being copyrighted. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #348 [1995] Scn From : maciej grzeszczuk 2:480/70 06 Oct 97 22:24:46 To : Lech Szychowski 08 Oct 97 07:04:42 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Mon, 06 Oct 97 00:21:00 +0200 Lech Szychowski napisal byl w fido.ip_connect: > Telnet is a protocol. Nobody says telnet servers have to listen > just on port 23. but we shouldn't allow log in procedure when connecting to ftn mailer via telnet. 461 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: i co, wkurwiona poszla? (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #349 [1995] Scn From : Lech Szychowski 2:480/33.7 07 Oct 97 01:01:00 To : Steve Woodmore 08 Oct 97 07:04:42 Subj : IP-connectivity ------------------------------------------------------------------------------- > I am talking about echomail, using SMTP I shift on average 10mbs/day to > my downlinks. I think its very very relevant. Well, it is. But I would hate to see RFC822 (plus all susequent changes and addition) as the encapsulation protocol for Fidonet traffic. As a last resort, yes. But only in very special cases. In other words. it is relevant but should stop being so ASAP, replaced with some reliable/controllable solution. SMTP has no "resend from" capability, no guaranteed allowable message size, no widely available software utils for dealing with files encoded into message bodies, no session passwords etc. SMTP is great for sending relatively small messages but certainly it is not a protocol of choice when it comes to mocing files around. I'm afraid if we follow your idea we are just a step away from stating that if I agree to do my best to carry packets on floppies to a friend of mine, he can be a Fidonet node :( Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #350 [1995] Scn From : Lech Szychowski 2:480/33.7 07 Oct 97 00:44:00 To : Pedro Lima 08 Oct 97 07:04:42 Subj : IP-connectivity ------------------------------------------------------------------------------- > Yes. My idea was not to have an IP-ZMH, but define the online time via > the U,Txx flags (I know its use is Z2-specific so far, but perhaps we > can change that?), and require a minimum of say an hour of continuous > online time. I think I got it. Let me rephase it: an IP-node has to be accessible for at least NNN minutes in one contiguos period each 24 hours, also start and end of this period have to be explicitly declared using "T" flags. Did I miss something? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #351 [1995] Scn From : Chris Maddock 3:640/302 07 Oct 97 22:27:10 To : Ward Dossche 08 Oct 97 07:05:10 Subj : Re: IP-nodes ... ------------------------------------------------------------------------------- On 04 Oct at 13:32, Ward Dossche of 2:292/854 wrote to David Moufarrege: [....] >> Which nodelist? WD> Testing in zone-2 ... to not disturb the other zones a portion of our WD> nodelist is not exchanged with them, i.e. the section which deals with IP. WD> There are now several IP-nodes in the zone2-nodelist for testing and WD> experimenting purposes (and to help overcome the psychological treshold WD> this represents for some) which operate in a realm not covered by policy. WD> Therefor it's my responsibility to do this and I wouldn't want to bother WD> the other zones with it. \x/ard, Alwyn (Z3C) may be interested in your "local" segment. You might want to check with him. Regards, Chris Maddock chrism@bbs.st.net.au --- Msged/386 4.20 beta 2 * Origin: Diagnostic CBBS - DownUnder - (3:640/302) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #352 [1995] Scn From : Fyodor Ustinov 2:5020/79 07 Oct 97 09:52:46 To : maciej grzeszczuk 08 Oct 97 09:45:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hi, maciej! Monday October 06 1997, maciej grzeszczuk writes to Lothar Behet: mg> binkd exist for about a year or two, and i don't see any mailers mg> supporting that 'standard'. 1. BinkD - mailer. BinkP - protocol. 2. BinkP & binkD exist less _one_ year. 3. BinkP supported by Argus (http://www.ritlabs.com). And not only via IP. With best regards, Fyodor --- GoldED/W32 3.00.Alpha5 UNREG * Origin: U.F.M Station [ufm@prospect.com.ru, 1086856#ICQ] (2:5020/79) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #353 [1995] Scn From : Pedro Lima 2:362/21 07 Oct 97 14:22:00 To : Rune Johansen 08 Oct 97 09:45:14 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hi, RJ> To my knowledge, a DNS lookup on a hostname will return the specific RJ> IP address, wether it is a v4 or v6 style address. Yes, I was thinking of the cases where the IP address is nodelisted instead of the FQDN. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #354 [1995] Scn From : Sean Rima 2:252/356 07 Oct 97 15:22:50 To : maciej grzeszczuk 08 Oct 97 09:45:14 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- 06 Oct 97 20:37, maciej grzeszczuk wrote to Lothar Behet: > Sat, 04 Oct 97 16:47:44 +0200 Lothar Behet napisal byl w > fido.ip_connect: >> mg> sure, binkd exist on many platforms, but it's only one mailer, >> Furthermore the protocol specification is available and therefore will >> be supported by other programs in near future :) > binkd exist for about a year or two, and i don't see any mailers > supporting > that 'standard'. BinkD is a program. The protocol is BinkP and BinkP as a protocol is supported by Argus and Beemail/TCP. And another one or two in the pipleine. >> mg> not a standard of virtual modem. with vmodem i can use any mailer. >> mg> at any system. >> As far as i know, Vmodem is only supported for OS/2 and the protocol >> specification is not available. >> I would be happy to be corrected on this matter :) > vmodem is supported on all software / hardware platforms. all unix > mailers > easily allowes vmodem incoming/outgoing connections, as well as the > amiga, > or win95/winnt ones. i've tried it. it succeded. >> But the listed nodes must support ip-connectivity either CM or at least >> at clearly specified online times, otherwise they should not be listed >> with ip-flags on seperate or regular (PSTN) lines. > agree with that. So do I. But ruling out a protocol that is in daily use by over 100 Ipmailers seems the wrong way to go. Sean BinkD Ipmailer: alice.pcug.co.uk SD®¯Æ». --- Msged/NT 4.10 * Origin: DSP BBS, Reading, Berks (2:252/356@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #355 [1995] Scn From : Sean Rima 2:252/356 07 Oct 97 15:28:08 To : maciej grzeszczuk 08 Oct 97 09:45:14 Subj : Re: BinkD (0.9.2) specification ------------------------------------------------------------------------------- 06 Oct 97 20:42, maciej grzeszczuk wrote to Sean Rima: > From: maciej grzeszczuk > Thu, 02 Oct 97 22:32:42 +0200 Sean Rima napisal byl w fido.ip_connect: >> Due to comments about BinkD not being allowed into the proposed >> Nodelist, here >> are the specs for the next release of BinkD. > allowed, but not as only protocol that ip node supports. Okay, but the protocol is BinkP (Hey, have I said this before) Sean BinkD Ipmailer: alice.pcug.co.uk --- Msged/NT 4.10 * Origin: DSP BBS, Reading, Berks (2:252/356@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #356 [1995] Scn From : Igor Bilyi 2:421/450 07 Oct 97 10:50:58 To : maciej grzeszczuk 08 Oct 97 09:45:14 Subj : binkd vs vmodem ------------------------------------------------------------------------------- Hi Maciej ! mg> vmodem is supported on all software / hardware platforms. floppynet is supported on all software / hardware platforms. vmodem is 2-3x slower than binkd, want to try? i'm ready -i- --- FMail/2 1.22 * Origin: * IP NODE * (2:421/450) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #357 [1995] Scn From : Sean Rima 2:252/356 07 Oct 97 22:59:00 To : Mario Mure' 08 Oct 97 09:45:14 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hi Mario, In a message to Fyodor Ustinov you wrote: MM> In a message dated < 04 Oct 97 07:21:55 >, addressed to maciej MM> grzeszczuk MM> about < IMPORTANT! standard of protocol for ip-nodes proposal. >, MM> Fyodor Ustinov wrote: FU>> Yes. And this standart should be binkp. MM> My vote for binkp ;-) I'm testing BinkD on agnese.fidoitalia.net MM> [195.120.19.166] and it works great !!! Is that a full time link? Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: What do you mean QWK? It took me hours to read! (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #358 [1995] Scn From : Sean Rima 2:252/356 07 Oct 97 23:00:00 To : Mario Mure' 08 Oct 97 09:45:14 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hi Mario, On Stardate <9710.06>, you wrote me: MM> In a message dated < 05 Oct 97 01:56:26 >, addressed to maciej MM> grzeszczuk MM> about < Re: IMPORTANT! standard of protocol for ip-nodes proposal. >>, Sean Rima wrote: SR>> is an addon for Ifcico to allow it to use BinkP which is use by SR>> BinkD MM> May I know where to find such add-on ? For linux of course ;-) I was going to search for it tonight but I got delayed with reconfiguring my local mail base from Squish to Jam Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: quote only what ties to your reply--stop QUOTAHOLISM (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #359 [1995] Scn From : Sean Rima 2:252/356 07 Oct 97 15:18:54 To : maciej grzeszczuk 08 Oct 97 09:45:14 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- 06 Oct 97 20:32, maciej grzeszczuk wrote to Slava Filimonov: > Thu, 02 Oct 97 17:34:20 +0200 Slava Filimonov napisal byl w > fido.ip_connect: >> LS> Why not a "raw socket"? >> Have u heared anything about binkd protocol for ip fido mailer? as >> simple as possible and fast enough extendable too... why a standart? >> we've already using >> it at least for half year and there are at least 200 nodes which >> supports it... > using binkd of course. other mailers are not allowed. Just a curious question. How many IFCICO mailers are there live on the Net. I am curious. >> binkd - multiplatform ip fido mailer > and vmodem is a standard for all existing platformes. and it allowes > you to use > ANY MAILER you want to. systems that are connecting to my node are > using > t-mail, frontdoor, portal of power, i've already seen two amiga mailers > (i don't remember the name of them), all unix mailers are also > compatible. I know a BBS use uses T-mail as his main mailer and for TCP/IP connectiuons uses BinkD. Here has no problems with this setup and uses it daily. > binkd isn't compatible with any of the stuff listed, and more - it > isn't > compatible with anything else. and it won't. BinkD as a program is *NOT* able to be used on a Telephone line. It is a small program to allow connects over the Net. It works along side T-Mail, Argus and any other Binkley type mailer. And it is free. >> bwt, this echo comes to me through binkd. > this echo comes to me through raw emsi via tcp. Sean BinkD Ipmailer: alice.pcug.co.uk SD®¯–µ. --- Msged/NT 4.10 * Origin: DSP BBS, Reading, Berks (2:252/356@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #360 [1995] Scn From : Slava Filimonov 2:469/33 07 Oct 97 10:29:12 To : Sean Rima 08 Oct 97 09:45:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Sean! 06 Oct 97 19:17, Sean Rima wrote to Slava Filimonov: >> are at least 200 nodes which supports it... binkd - multiplatform >> ip fido mailer can be downloaded at ftp.falcon.spb.su >> /pub/fido Argus - fido mailer win32 with ip binkd protocol / >> www.ritlabs.com SR> It is also available in the gamma version of Beemail/32. SR> http://beemail.com it's time to make faq for this echo ;) some faq's http://www.falcon.spb.su/fido-via-ip-FAQ.html, IP list - fido nodes supporting ip http://www.falcon.spb.su/iplist.html Binkd ftp://ftp.prospect.com.ru/fidonet/mailers/binkd ftp://ufm.prospect.com.ru Login:binkd Argus http://www.ritlabs.com/argus/index.html ftp://ftp.ritlabs.com/pub/argus Beemail/32 http://beemail.com Fidonet.net domain ( to enter in this domain you should work 24h and use any software with binkp protocol ) -+-+ Domain Name: FIDONET.NET Administrative Contact: Ustinov Fyodor (UF7-ORG) ufm@PROSPECT.COM.RU 7 095 564 8272 Fax- 7 095 564 8945 Technical Contact, Zone Contact: Valdov, Dmitry (DV15-RIPE) dv@KIS.RU +7 831 2342022 +7 831 2343420 Billing Contact: Ustinov Fyodor (UF7-ORG) ufm@PROSPECT.COM.RU 7 095 564 8272 Fax- 7 095 564 8945 Domain servers in listed order: NS.FIDONET.NET 195.98.32.193 NS1.FIDONET.NET 194.85.143.33 -+-+ // C0PiRATE Cy.b33r.Net // slf@mrp.cz // www.geocities.com/SoHo/9669 --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #361 [1995] Scn From : Sean Rima 2:252/356 07 Oct 97 15:25:34 To : maciej grzeszczuk 08 Oct 97 09:45:14 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- 06 Oct 97 20:41, maciej grzeszczuk wrote to Sean Rima: > Sun, 05 Oct 97 00:56:26 +0200 Sean Rima napisal byl w fido.ip_connect: >> Strange, I connect to an IFCICO mailer evey day with no problems. There >> is an addon for Ifcico to allow it to use BinkP which is use by BinkD > if so, please tell me the location i can find the patch to my ifcico > mailer. > and to other vmodem fossils, that are allowing use of all mailers that > you > can imagine. I will try and find out the url for you. But I mean't the protocol BinkP. >> Having used EMSI connections across the net, I would not like to go >> back to it. > using emsi over tcp about 30-40 times a day, and haven't noticed any > problems > with slow handshaking, nor dropped connections. Umm, I did but then maybe it was me. >> reason that TelNet should not be considered is that some IPmailers >> operate on a > as a telnet available mailer i assume a mailer that support direct > telnets > onto port 23 of specified machine. I could not have a Telnet mailer operating on port 23 as I have to telnet into my shell account to read some mail. Also to start and stop both the mailer and tosser from time to time. Sean BinkD Ipmailer: alice.pcug.co.uk SD®¯ --- Msged/NT 4.10 * Origin: DSP BBS, Reading, Berks (2:252/356@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #362 [1995] Scn From : Dima Maloff 2:5020/79.31 08 Oct 97 19:41:00 To : Tobias Ernst 08 Oct 97 09:45:16 Subj : IP-access ------------------------------------------------------------------------------- Saturday October 04 1997 21:01, Tobias Ernst wrote to Ask Bjoern Hansen: TE> Nevertheless, of all solutions I have been seeing since I read TE> this echo, this is the most elegant one. It makes the most clever use TE> of existing internet technology (DNS), it puts the least ballast on TE> the nodelist, and it will not have any negative influence on PSTN TE> nodes who do not have a specific IP setup (compare to the problems TE> with fake country prefixes when listing IP phone numbers). TE> Keep up your good idea! Yes. Many of us, here at R50, loved that idea too. This summer we even set up fidonet.net. zone to perform x:y/z.t -> FQDN translation. We use mostly Argus Mailer and Binkd Daemon for Fido-over-IP, and their next versions will perform this translation automagically fo sure. TE> Well, this just shifts to the point that a crash of the DNS computer will TE> stop any traffic in the whole Z2. ;-). We should maintain more than one TE> DNS computer, on the one hand for backup purposes, on the other hand to TE> reduce traffic for each individual one. Sorry, but having at least 2 DNS servers for every zone at each level is "MUST to do" per RFC ;-) --- GoldED/2 3.00.Alpha5 UNREG * Origin: Would you give me a root message? I'm kinda tarred (2:5020/79.31) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #363 [1995] Scn From : Slava Filimonov 2:469/33 07 Oct 97 10:58:52 To : maciej grzeszczuk 08 Oct 97 09:45:16 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello maciej! 06 Oct 97 20:32, maciej grzeszczuk wrote to Slava Filimonov: >> 200 nodes which supports it... mg> using binkd of course. other mailers are not allowed. >> binkd - multiplatform ip fido mailer binkd don't use vmodem. binkd itself like interface between your tosser and my tosser. All other unnesessary things excluded. Just imagine that - due binkp simplicity, software developers can implement binkp directly into echoprocessors! ( ... and this will be fido-sendmail ? ) mg> and vmodem is a standard for all existing platformes. and it allowes mg> you to use ANY MAILER you want to. systems that are connecting to my mg> node are using t-mail, frontdoor, portal of power, i've already seen mg> two amiga mailers (i don't remember the name of them), all unix mg> mailers are also compatible. At the end of the day you'll pay for this compatibility. As i said - keep your old mailer. Set it up to bink-style. Add binkd (it takes about 10min to install and configure it). Another issue - vmodem emulates modem for dos box. isn't it ? For each platform you have to use system-dependent vmodem to emulate win32 modem device, os/2 modem device etc... Do you have source for vmodem ? nope. Are you keen enough to stick with vmodem forever ? I'm not. And vmodem afaik isn't for free... mg> binkd isn't compatible with any of the stuff listed, and more - it mg> isn't compatible with anything else. and it won't. At the fido beginning there was only two nodes which had support for new mail exchange protocol... And this protocol was simple as possible and not compatible with anything else. and it won't ;) >> bwt, this echo comes to me through binkd. mg> this echo comes to me through raw emsi via tcp. Now tell me your link capacity and avg cps ? // C0PiRATE Cy.b33r.Net // slf@mrp.cz // www.geocities.com/SoHo/9669 --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #364 [1995] Scn From : Sean Rima 2:252/356 07 Oct 97 23:03:00 To : Victor Prylipko 08 Oct 97 09:45:16 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hi Victor, In a message to Maciej Grzeszczuk you wrote: VP> Hello maciej! VP> 03 Oct 97 01:23, maciej grzeszczuk wrote to Sean Rima: mg>> ifcico is incompatible with binkd. binkd is incompatible with mg>> any mg>> mailer, except itself. VP> At this point you are wrong. binkd is compartible with Argus. I think this may have been my fault. I mentioned BinkD when I should have started talking about the Protocol BinkP. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: I think you understand that you've got it (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #365 [1995] Scn From : Pedro Lima 2:362/21 08 Oct 97 00:34:12 To : maciej grzeszczuk 08 Oct 97 09:45:16 Subj : IP-connectivity ------------------------------------------------------------------------------- mg> binkd cannot be treated as a standard, as it's compatible only with mg> itself. The main question here is if most platforms are covered and if the software is freely available. VModem is, IMHO, too much proprietary to be considered as a "minimal" capability. A list of the several possibilities, together with the platforms supported and if it's freely available or not may help us in pinpointing the best "minimal capability" (if indeed we need one). Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #366 [1995] Scn From : Sean Rima 2:252/356 07 Oct 97 23:01:00 To : Fyodor Ustinov 08 Oct 97 09:45:16 Subj : IP-access ------------------------------------------------------------------------------- Hi Fyodor, In a message to Lech Szychowski you wrote: FU> Hi, Lech! FU> Saturday October 04 1997, Lech Szychowski writes to Ask Bjoern FU> Hansen: -------CUT---------- LS>> with a node that for some reason has no DNS entry he can put LS>> this node manually into hosts file. FU> BTW. Any node supported binkp protocol can be published in FU> fidonet.net domain. I tried to do an DNS on fidonet.net but it doesn't appear to have any of the BinkD mailers listed yet. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: This time everything is easy (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #367 [1995] Scn From : Slava Filimonov 2:469/33 07 Oct 97 10:37:02 To : Lech Szychowski 08 Oct 97 09:45:16 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Lech! 06 Oct 97 00:40, Lech Szychowski wrote to Slava Filimonov: >> least 200 nodes which supports it... LS> I dare to say that vmodem has been around for much more than half LS> a year. And I dare to say that this issue should not be raised LS> when it comes to setting a new standard; we should rather concentrate LS> on finding the best solution - and here "best" not necessarily LS> means "convenient for a number of nodes". We're talking about ip-connectivity isn't it ? As long as you use BINK-style outboud, you can keep your old phone mailer and add binkd mailer to exchange fido over ip. Is this a real solution for all or what ? Finally, if you want to stick with vmodem, than keep ip for your convenience. Just alter your outbound to bink-style and keep 'em all - old mailer, binkd, your old mailer with vmodem. // C0PiRATE Cy.b33r.Net // slf@mrp.cz // www.geocities.com/SoHo/9669 --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #368 [1995] Scn From : Slava Filimonov 2:469/33 07 Oct 97 10:44:38 To : Lech Szychowski 08 Oct 97 09:45:16 Subj : IP-access ------------------------------------------------------------------------------- Hello Lech! 06 Oct 97 00:53, Lech Szychowski wrote to Slava Filimonov: >> protocols ? You definitevly don't need all that stuff. Want to keep LS> What about using UUCP in these cases? Its implementations have been LS> around for many years and have already proven itself useful and LS> reliable. So let try binkp protocol to proove its simplicity and reliability. And don't forget, UnixUnixCopyProtocol was designed for Unix systems ;) we're want FFCP - fidofidoCopyProtocol - binkp ;)) btw, and why do they start to use HTTP protocol, if UUCP were so good ? // C0PiRATE Cy.b33r.Net // slf@mrp.cz // www.geocities.com/SoHo/9669 --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #369 [1995] Scn From : Denis McMahon 2:251/20 07 Oct 97 00:47:10 To : Lech Szychowski 08 Oct 97 09:45:16 Subj : IP-connectivity ------------------------------------------------------------------------------- Lech Szychowski wrote to Denis McMahon: > UUCP (of which I know little) is I believe like FTP. Perhaps someone can > correct me? LS> Smarter (can transfer files both ways) and much more suitable for LS> our purposes; as a matter of fact, UUCP was created just to achieve LS> what we want now: moving files and mail between nodes. OK, so both ftp and uucp are means of transferring pkt, arcmail, nodediffs, fidonews. In that case, surely both ftp and uucp are carrier protocols between ftn systems. Hmm, this means you can have a fidonet node with no mailer, just a mail processor and ftp / uucp. Is this valid? Messages are still transferred in fts-0001 packet / arcmail format, and FTS-0001 compatible mail processing is required ....... I could argue both sides of this, so I'll sit on the fence instead. :-) Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #370 [1995] Scn From : Fyodor Ustinov 2:5020/79 07 Oct 97 09:48:48 To : maciej grzeszczuk 08 Oct 97 09:45:16 Subj : IP-connectivity ------------------------------------------------------------------------------- Hi, maciej! Monday October 06 1997, maciej grzeszczuk writes to Pedro Lima: mg> Wed, 01 Oct 97 17:38:14 +0200 Pedro Lima napisal byl w mg> fido.ip_connect: >> be considered as a minimal standard is not an obvious choice, >> although BinkD seems to be supported in most of the platforms... mg> binkd cannot be treated as a standard, as it's compatible only with mg> itself. Heh. Vmodem compatible with all software? Where _free_ vmodem? Where _any_ vmodem for Win32? With best regards, Fyodor --- GoldED/W32 3.00.Alpha5 UNREG * Origin: U.F.M Station [ufm@prospect.com.ru, 1086856#ICQ] (2:5020/79) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #371 [1995] Scn From : Sean Rima 2:252/356 07 Oct 97 15:13:50 To : maciej grzeszczuk 08 Oct 97 09:45:16 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- 06 Oct 97 20:18, maciej grzeszczuk wrote to Pedro Lima: > Wed, 01 Oct 97 17:38:14 +0200 Pedro Lima napisal byl w fido.ip_connect: >> be considered as a minimal standard is not an obvious choice, although >> BinkD seems to be supported in most of the platforms... > binkd cannot be treated as a standard, as it's compatible only with > itself. BinkD is a program, BinkP is the protocol that BinkD uses. BinkP /1.0 or BinkP /1.1 is used by Argus, Beemail/TCP. Also Argus uses BinkP as a protocol for normal telephone calls. BinkD as a program, is freely available under the GNU licence and has been compiled under OS2, Windows 95 and NT, and various versions of *NIX. Also, I believe that other mailers are looking at BinkP as a protocol as it is around 50% faster than anything else. Sean BinkD Ipmailer: alice.pcug.co.uk SD®¯˜®. --- Msged/NT 4.10 * Origin: DSP BBS, Reading, Berks (2:252/356@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #372 [1995] Scn From : Nick Soveiko 2:5030/23.101 06 Oct 97 22:33:30 To : Lech Szychowski 08 Oct 97 09:45:16 Subj : IP-access ------------------------------------------------------------------------------- Mon, 06 Oct 1997, 00:53, Lech Szychowski (2:480/33.7) ==> Slava Filimonov: > but if you have poor ip u can have _big_ troubles with timeouts/ > resending/etc associated with vmodem/modem-style emsi + zmodem|*modem LS> Timeouts etc can be tweaked in any way you see necessary. how many existing mailers you can name that allow tweaking with the timeouts? LS> You have full sources available and there is nothing to stop yoy LS> from implementing things in a way that takes care of the IP-link LS> specific stuff. for how many of the mailers do you have sources readily available? (right of the top of my head) i can name only two: that's binkleyterm and binkd. > protocols ? You definitevly don't need all that stuff. Want to keep LS> What about using UUCP in these cases? Its implementations have been LS> around for many years and have already proven itself useful and LS> reliable. uucp is probably fine. now comes the next question: can you propose a technology for using any uucp flavour for the purpose of fidonet transport? right now. that is, an already working technology. i bet you not. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #373 [1995] Scn From : Marco d'Itri 2:335/680.666 08 Oct 97 14:24:26 To : Lech Szychowski 08 Oct 97 22:17:16 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >passwords etc. SMTP is great for sending relatively small messages >but certainly it is not a protocol of choice when it comes to mocing >files around. I wrote an arcmail-in-email incapsulation protocol that addresses some of your concerns, I hope to be able to publish it in NET_DEV in some weeks (I written it on paper, I have to refine it yet). Anyway, I agree that email incapsulation should be used only in special cases: - internet bbs to point communication - communication between a PSTN node and an internet hub - communication between PSTN nodes (when it's cheaper) ie: communications between a node that is not online 24h and another node. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #374 [1995] Scn From : Marco d'Itri 2:335/680.666 08 Oct 97 14:16:50 To : Nick Soveiko 08 Oct 97 22:17:16 Subj : Re: IP-access ------------------------------------------------------------------------------- Nick.Soveiko@p101.f23.n5030.z2.fidonet.org wrote: >uucp is probably fine. now comes the next question: can you propose a >technology for using any uucp flavour for the purpose of fidonet transport? >right now. that is, an already working technology. I get this area via an uuencoded tunnel via email via uucp. Some years ago in Italy some bbs had uucp points. uucico can do much more than a ftn mailer. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #375 [1995] Scn From : Marco d'Itri 2:335/680.666 08 Oct 97 14:29:52 To : Pedro Lima 08 Oct 97 22:17:16 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Pedro.Lima@f21.n362.z2.fidonet.org wrote: >Yes, I was thinking of the cases where the IP address is nodelisted >instead of the FQDN. IPng addresses are different enough to be machine recognisable. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #376 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 07 Oct 97 23:01:02 To : Lothar Behet 08 Oct 97 22:17:16 Subj : Re: IP-Test 2:2/3000 ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: >How do you tell the uninformed (older) mailer, that it definitely must not >call these lines? With their nodelist compiler. If the sysops can't do even that they will have to disable automatic calls. >As Ward selected the system name field to be the relevant field for fqdn or I think it was a typo. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #377 [1995] Scn From : Marco d'Itri 2:335/680.666 08 Oct 97 14:26:50 To : Slava Filimonov 08 Oct 97 22:17:16 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Slava.Filimonov@f33.n469.z2.fidonet.org wrote: >And vmodem afaik isn't for free... IMHO this is a very important point. We should not accept as standard any solution that is not 100% free. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #378 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 08 Oct 97 22:32:50 To : Marco d'Itri Subj : IP-Test 2:2/3000 ------------------------------------------------------------------------------- Hello Marco! On 07 Oct 97 wrote Marco d'Itri to Lothar Behet: >> As Ward selected the system name field to be the relevant field for >> fqdn or MI> I think it was a typo. IMHO a very practical one :) The system name can carry any string (fqdn or ip#) without any interference to "normal" mailers within the existing nodelistformat and dependant software. It is even fault-tolerant to uninformed nodes :) From all information in the nodelist, it is IMHO the least significant one :), as the geographical location might still indicate a useful hint for a special link and the flag field may fulfill this purpose (flags) as complete as possible. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #379 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 08 Oct 97 23:09:56 To : All Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello All! The following should be met for an ip-capable entry in the nodelist: >-8------------------------ byte here ------------------------8-< 1. IP may be listed only as additional media type to normal pstn connections 2. the online time must be clearly stated, CM is preferred 3. there must at least be one FTS-conformant protocol on this line 4. additional protocols may be listed on the same line >-8------------------------ byte here ------------------------8-< Explanation: 1. is self-explanatory: There are no IP-only nodes in the nodelist. 2. As reachability at ZMH is a basic condition for a node, this should be honored (and checked), before listing an ip entry in the nodelist. 3. As FTS-001 is another basic condition for listing as node, at least one protocol must be capable for a direct mailer to mailer session. I do not state any special protocol as required, because several are in use widely and many systems can even support different protocols listed on the same line. These may (and i hope, normally they will) perform the duty as relay between different protocols, if required. 4. As Fido is a synomyn for "information exchange", the indirect protocols (FTP, email-based) should additionally be made available to the public for (cost-) optimization purposes. Please correct me, if i have overseen something important, but i hope, that these basics will be honored, before ip-nodes will be listed beside the few test-nodes. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #380 [1995] Scn From : David Moufarrege 1:2613/404 07 Oct 97 21:47:30 To : Lawrence Garvin 09 Oct 97 05:58:26 Subj : IP-connectivity ------------------------------------------------------------------------------- Hello Lawrence! In a message Lawrence Garvin wrote to Lech Szychowski: LG> Furthermore, with the (some say abuse) of DHCP, it's possible that LG> more and more IP-based systems will have dynamic addresses, even LG> where LG> they did have permanent addresses before. Well, using a service like Monolith allows you to "register" the dynamic IP and "convert" it into a pre-assigned static IP address, therefore being able to have a 24hr presence on the net even though your ISP might use DHCP and not assign static addresses under any circumstances. -=David=- _____________________________ | e-mail : david@kraut.xg.com | | FidoNet: 1:2613/404 | | 1:13/0 | ----------------------------- ... To excel at what you do, you must love doing it. --- * Origin: Kraut Haus * Rochester, NY * 716-359-0871 (1:2613/404) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #381 [1995] Scn From : Denis McMahon 2:251/20 07 Oct 97 22:46:00 To : Steve Woodmore 09 Oct 97 07:02:16 Subj : IP-connectivity ------------------------------------------------------------------------------- following up a message from Denis McMahon to maciej grzeszczuk: DM> Steve is IMHO an opiniated twerp, but sometimes he's right. Sorry, I should have said opinionated Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #382 [1995] Scn From : Denis McMahon 2:251/20 07 Oct 97 07:54:00 To : Pedro Lima 09 Oct 97 07:02:16 Subj : IP-access ------------------------------------------------------------------------------- Pedro Lima wrote to Lech Szychowski: LS> This problem can be partially solved by creating more DDNS LS> servers servicing a smaller number of nodes; regional/netional LS> subdomains of Z2 seem to be a natural/obvious choice. PL> Agreed, but we're only talking about the z2.fidonet.org domain. IMHO it would be short sighted of us not to consider the fidonet.org domain. A solution that only works in one zone is hardly ideal. Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #383 [1995] Scn From : Denis McMahon 2:251/20 07 Oct 97 07:56:30 To : Rune Johansen 09 Oct 97 07:02:16 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Rune Johansen wrote to Lothar Behet: >> The dial translation will put the international access code in front >> of the listed phone number. With the ITU recommended international >> access code of 00 the dialer would translate a listed number starting >> with 0 into triple 0. > Please tell this to those people, who mourne about dial translations :) RJ> Wich country have got 00 as international access code _and_ 000 as RJ> emergency number? I doubt that there is any country that has got RJ> that. Australia has got 000 as emergency number. What is their RJ> international access code? The same for england: If their emergency RJ> number is 999, then you can be sure that their international access RJ> code is _not_ 99. It doesn't really matter - as whatever "invalid country code" is used will be prefixed with "international access code" before dialling, and for example in UK 00-999 does not call emergency services. Does 0011-000 (Telstra) or 10011-000 (Optus) call emergency services in Australia? Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #384 [1995] Scn From : Denis McMahon 2:251/20 07 Oct 97 08:26:18 To : maciej grzeszczuk 09 Oct 97 07:02:16 Subj : IP-connectivity ------------------------------------------------------------------------------- maciej grzeszczuk wrote to Steve Woodmore: > NO!, I am trying to say we should allow any node that has any form of > IP transfer available to them, be it IP FTP SMTP Tunneling or > whatever, if they can transfer mail via the internet in some form or > another, then they should be listed as such. mg> ftp or smtp is not a way to reach the system's mailer. mg> vmodem/ifcico/telnet connections are. Steve is IMHO an opiniated twerp, but sometimes he's right. If you can transfer FTS-0001 packets fully automated at both ends then the connection is a fidonet connection. This means you don't need mailer to be a fido node, an IP system is OK as long as you have a mail processor and message reader! Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #385 [1995] Scn From : Eugene Gladchenko 2:5061/15 08 Oct 97 09:12:20 To : maciej grzeszczuk 09 Oct 97 07:02:16 Subj : BinkD (Was: IP-connectivity) ------------------------------------------------------------------------------- Hello maciej! >> BinkD seems to be supported in most of the platforms... mg> binkd cannot be treated as a standard, as it's compatible only with mg> itself. Don't be so categorical. First, binkd is not the only one *fidonet* mailer supporting binkp protocol already. Second, even if it was, it just would be the first one. It happens to all new things, agree? Everyone is given all the sources of binkd/binkp and sometimes there will be plenty of alternatives. Argus is an example. Third, it is not really compatible only with itself. It uses the same binkley-style outbound as other *fidonet* mailers do. It does it simultaneously with them. Furthermore it uses his own port number. Hence everyone can use it without refusing usual old mailer. Did you ever see binkd? If not please take a look. You will sure like it. It's so simple to use and very powerful all the same time. --- * Origin: Try working in my shoes (FidoNet 2:5061/15) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #386 [1995] Scn From : Denis McMahon 2:251/20 07 Oct 97 08:19:32 To : Lech Szychowski 09 Oct 97 07:02:16 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski wrote to Denis McMahon: > No it would not, the administration would have to be done by whoever > maintained the dns at the level concerned. Most NCs, RCs etc have no > access to the DNS for z2.fidonet.org. LS> I'm pretty sure that if someone runs a leased line connected system LS> he can either set up a DNS server himself or find another Fidonet LS> IP node that will be happy to host his entry. Thing is, his entry *MUST* (my understanding anyway) be in the DNS at either z2.fidonet.org /or/ .n.z2.fidonet.org for it to be looked up. If the entry isn't in one of those two locations, then a dns query for fx.ny.z2.fidonet.org will not find the ip address for 2:y/x! LS> I believe ?C's responsibility does not imply he has to do all the LS> nodelist-related stuff himself; his job is to make sure all the LS> updates are correct and passed up the structure. Yes, but (again my understanding) is that dns entries within any hierarchy have to be manually maintained at the recognised DNS server(s) for that hierarchy. LS> C'mon, let's be consistent. More to the point, let's make sure what we're proposing can work, eh? Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #387 [1995] Scn From : Lawrence Garvin 1:106/6018 08 Oct 97 07:54:50 To : Lech Szychowski 09 Oct 97 07:02:16 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Pedro Lima: > If I understand correctly, the traffic increase occurs mainly between > the primary and secondary servers. LS> Yes. Also traffic between these servers and clients requesting DNS LS> records, but I think it's not as big as between servers. This LS> problem can be partially solved by creating more DDNS servers LS> servicing a smaller number of nodes; Definitely! Although I suspect you meant more DNS servers, not more DDNS servers. No? LS> regional/netional subdomains of Z2 seem to be a natural/obvious LS> choice. Or any other zone as well. :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #388 [1995] Scn From : Dima Maloff 2:5020/79.31 09 Oct 97 13:31:00 To : maciej grzeszczuk 09 Oct 97 07:02:16 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Monday October 06 1997 20:33, maciej grzeszczuk wrote to Max Masyutin: mg> yes. it's simple on all software / hardware platforms. R50 would never moved to Argus/Binkd if modem emulation given by vmodem or watever worked nice. In fact vmodem's fat, buggy, unstable, slow and costs money. After all, we don't force everyone to use binkp, we just don't want to be forced to use vmodem. --- GoldED/2 3.00.Alpha5 UNREG * Origin: SET prompt=$i$e[1;32m$p$e[1;37m$s$g$s$e[0;37m (2:5020/79.31) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #389 [1995] Scn From : Lawrence Garvin 1:106/6018 08 Oct 97 07:58:42 To : Steve Woodmore 09 Oct 97 07:02:16 Subj : IP-connectivity ------------------------------------------------------------------------------- Steve Woodmore said in a message to Lech Szychowski: LS> Are you trying to say that you seriously think about allowing LS> IP-only SMTP-only non-permanently connected Fido nodes? :-O SW> NO!, I am trying to say we should allow any node that has any form SW> of IP transfer available to them, be it IP FTP SMTP Tunneling or SW> whatever, if they can transfer mail via the internet in some form SW> or another, then they should be listed as such. I disagree, Steve. We're talking about the NODELIST. The sole purpose of the nodelist (well, technically, anyway) is to allow an FTN mailer to lookup a telno (or in this case, an IP address) in order to place an FTN call. My FTP client (FIFTP), nor my SMTP mailer (sendmail) have no need to lookup anything in the Fidonet nodelist in order to send mail via FTP or SMTP. Therefore, I support the concept that only full-time, permanently connected, IP-dialable nodes are at issue for nodelist inclusion. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #390 [1995] Scn From : Amir Shabashvili 2:5049/12 08 Oct 97 10:52:48 To : Nick Soveiko 09 Oct 97 07:02:16 Subj : IP-access ------------------------------------------------------------------------------- Hello Nick! Žâ¢¥ç ï ­  ¯¨á쬮 Nick Soveiko ª Lech Szychowski: NS> for how many of the mailers do you have sources readily available? NS> (right of the top of my head) i can name only two: that's binkleyterm NS> and binkd. ifmail too ‚á¥å ¡« £, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #391 [1995] Scn From : Amir Shabashvili 2:5049/12 08 Oct 97 10:58:36 To : Fyodor Ustinov 09 Oct 97 07:02:16 Subj : IP-connectivity ------------------------------------------------------------------------------- Hello Fyodor! Žâ¢¥ç ï ­  ¯¨á쬮 Fyodor Ustinov ª maciej grzeszczuk: FU> Heh. Vmodem compatible with all software? Where _free_ vmodem? Where FU> _any_ vmodem for Win32? I playng with some modem-TCP emulations for win, and got lost time, nothing more. It was't usefull stuff. ‚á¥å ¡« £, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #392 [1995] Scn From : Denis McMahon 2:251/20 07 Oct 97 23:21:48 To : All 09 Oct 97 07:02:16 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello All! I think people are looking at the wrong problem here. Our objective, surely, is to find a way to increase FTN connectivity principally using TCP/IP techniques, but taking "other" non analogue technologies into account as well. OK, we are all happy with what TCP/IP means, but there are many ways in which TCP/IP can support FTN protocols. FTS-0001 defines several protocols, the main one is of course the FTS-0001 handshake applicable to analogue connections, but the FTS-0001 document also defines the protocol for passing a lump of data (ie a message packet) between FTN capable systems. Why don't we stop debating what is and is not a valid TCP/IP extension of FTS-0001, FTS-0006, EMSI, YooHoo, Wazoo etc, and instead concentrate on two things: 1) A mechanism for including "Internet" node adresses in nodelist entries. 2) A mechanism for distinguishing the capabilities of an "internet" node. Another issue is 3) A method for showing On-line times of an "internet" node. For (1) We have I think the following ideas: a) IP address in telno field behind non-country-code b) IP address or hostname in systemname field c) IP address or hostname in flags field d) DNS translation of f*.n*.z*.fidonet.org address For (2) we have flags. Methods are: Vmodem Telnet BinkP BinkD IFCICO FTP UUCP SMTP/UUEnc SMTP/Base64 and anything else that anyone cares to add. For each method, a standard means of implementation is needed, but we don't need to argue over whether "methods" are valid. Examples: FTP standard. Calling system uses username anonymous and password ":/". Called system accepts anonymous ftp upload of pkt and arcmail. FTP received on port .. SMTP/UUEnc standard. UUEncoded pkt / arcmail to user "fidouue" at hostname / ip address. SMTP received on port .. SMTP/Base64 standard. Base 64 encoded pkt / arcmail to user "fido64" at hostname / ip address. SMTP received on port .. Any system which supports the method has to accept pkt / arcmail according to the standard method from any other ip node, but any two sysops of ip systems can agree privately to implement any method however they like for communication between their two systems. For (3) we have flags How we handle each of the three issues is independant of how we handle the other two, but maybe we want a single multi-component flag that indicates IP, shows where in the nodelist line to find hostname or ip address or indicates to use fidonet.org address in DNS, and indicates methods supported and on-line times. IP:addressing:methods:times IP:a|b|c|d:hostname|e:ip-address:vtpdifus6[:xy] So: IP:a:v is an IP node with ip address in telno field (a) and vmodem (v) and is available during ZMH. IP:d:hostname:vt:ae is an IP node with hostname "hostname" supporting telnet and vmodem from 00:30 to 05:30 GMT. If we can agree a standrd for the addressing data that mandates either ip address or hostname then the adressing component of the IP flg is not needed. If not, then addressing component is used to tell system where to look and how to handle address data. Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #393 [1995] Scn From : Nick Soveiko 2:5030/23.101 07 Oct 97 17:08:56 To : Rune Johansen 09 Oct 97 07:02:16 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sun, 05 Oct 1997, 21:34, Rune Johansen (2:210/20) ==> Lech Szychowski: >> If a minimum protocol is to be used, I would vote for telnet. > Why not a "raw socket"? RJ> Because of that we should consider a possibility that there is a RJ> BBS running behind the mailer. Telnet is a "universal" tool on most RJ> platforms, and can be used by endusers to connect to the BBS. If we RJ> use raw socket as minimum protocol (if it should be some minimum RJ> protocol), they have to use specific software to connect. if a user opts to connect to a bbs using telnet, it's completely irrelevant to the way fidonet systems connect to each other. in the tcp/ip world we don't have to share one communication port for both mailer and bbs. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #394 [1995] Scn From : Lawrence Garvin 1:106/6018 08 Oct 97 07:40:30 To : Ward Dossche 09 Oct 97 07:02:16 Subj : A bit of steering ... ------------------------------------------------------------------------------- Ward Dossche said in a message to All: WD> Because including a node would become rather complicated. After WD> having dealt with the fido-structures a future IP-node must equally WD> have its IP-address or similar in the tables maintained by the WD> postmaster at z2.fidonet.org. Or whatever zone the node happens to be in. Forgive me, Ward, I didn't realize this was a Zone 2 only project, although I have noticed a critical dearth of otherzone sysops in this echo. :( WD> It also means that from a fido-environment we will be deciding the WD> behaviour of people in an internet-environment, we will have to WD> write a policy-document regulating the entry of IP- or WD> likewise-addresses in the internet-tables ... One presumes that a Fidonet-member-node should be maintaining the zone tables for the Fidonet-member-nodes. As for the 'work load' on the zX.fidonet.org HOSTmaster, there is absolutely nothing preventing that HOSTmaster from delegating zones to other places willing to maintain subsets for the Fidonet zone. WD> This is complicating the issue uselessly and making it top-heavy. Such is the nature of this proposal! WD> I think we are now looking into 3 things: WD> WD> 1) integrating the full-IP-address in the nodelist; Arguably acceptable, as pointed out by others, it does impede the freedom to freely change IP numbers on a host, although in a well managed network they don't change any more often than the telno would. And for those who are worried about dynamically assigned numbers from dialup ISPs, perhaps listing of IP numbers in the nodelist should be reserved for permanently connected -CM- IP nodes? WD> 2) integrating the domain-name in the nodelist; Not practical, Ward. Try adding: "bbs.eforest.houston.tx.us" or "bbs.hd.co.harris.tx.us" and still keep the node entry under the limit. :) WD> 3) both. Surely if the domain-name only solution presents challenges to line length issues, placing both in the nodelist is virtually impossible. WD> The next question is "where"? The phone-field is the obvious WD> sollution but then we need to do something about MAKENL and WD> FTS-0005. After much consideration, I must strongly object to using the telephone number field. I run IP-capable nodes on the same system/same node number as my V.34 nodes. I'd like to keep it that way. I see no advantage in using different node numbers to specific which 'port' (PSTN or IP) of my -node- (system) one is dialing into. That decision should be made by FLAG, not by NODE number. I'd like to be able to have telno and IP address in the same node listing, with a flag that allows one's mailer to choose which technology is available to the caller. WD> And finally, a draft-FTS needs to be written and presented to the WD> FTSC. Which FTSC? WD> Have I missed something? Yeah... but let's deal with the above, first. :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #395 [1995] Scn From : Lawrence Garvin 1:106/6018 08 Oct 97 07:49:30 To : Lech Szychowski 09 Oct 97 07:02:16 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Jan Ceuleers: > My main problem is that due to the caching function I mentioned above, > it doesn't seem to be possible to accomodate nodes whose ISP dynamically > assigns them an IP address as they log on. I don't think DNS can cope > with that, but I'd be happy to be proved wrong. LS> My first thought is setting TTL to near-zero seems to be one LS> possible solution. Although I have to admit that I don't remember LS> what RFCs say about minimal TTL (if this issue is dealt with at LS> all). Minimum TTL is recommended to be at least one hour. In fact, some hostmasters who are implementing automated zone checkers, will reject any domain-request where the DNS server has less than a one hour TTL configured. Keep in mind, also, that depending on the number of requests serviced by your servers, the shorter the TTL, the more time your system will spend answering DNS requests, instead of sending true service packets. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #396 [1995] Scn From : Lawrence Garvin 1:106/6018 08 Oct 97 07:53:00 To : Pedro Lima 09 Oct 97 07:02:16 Subj : IP-access ------------------------------------------------------------------------------- Pedro Lima said in a message to Lech Szychowski: LS> Yes. But at the expense of generating much additional netork traffic LS> and increasing server load - and therefore should be avoided whenever LS> possible. PL> If I understand correctly, the traffic increase occurs mainly PL> between the primary and secondary servers. TTL timelimits do not affect master<>slave exchanges. Those are controlled by the refresh/retry times defined in the SOA records. A slave server permanently caches all records for whatever time is specified in the expire field of the SOA record, which is when it throws away the zone after the refresh/retry has failed for the expire period of time. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #397 [1995] Scn From : Amir Shabashvili 2:5049/12 08 Oct 97 10:36:56 To : maciej grzeszczuk 09 Oct 97 07:02:16 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello maciej! Answering to the message from maciej grzeszczuk -> Slava Filimonov: >> binkd - multiplatform ip fido mailer mg> and vmodem is a standard for all existing platformes. I'd playing with vmodem sometimes ago; it's nice thing, but - binkd as real IP mailer with own binkp protocol is more better, smaller, more reliable and usefull, trust me:) Espetially for cases where IP only fido system exist - I use it in LAN enviroment, for example. But, it usefull in all cases, if you've online IP - because don't need any fido mailer stuff - modem/protocol/timeouts/_thousand_any_other_stuff *emulation*. Than, binkd is multilink mailer - you don't need one copy for every line, only 2 lines in config (Maxclient= and Maxserver=)Do you seen fido-session 2 days long? I've seen with binkd - it is usial sometimes if IP link is bad and slow, but in case you've permanent IP - why not? ‚á¥å ¡« £, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #398 [1995] Scn From : Amir Shabashvili 2:5049/12 08 Oct 97 11:15:40 To : Lawrence Garvin 09 Oct 97 07:02:16 Subj : IP-connectivity ------------------------------------------------------------------------------- Hello Lawrence! Žâ¢¥ç ï ­  ¯¨á쬮 Lawrence Garvin ª Lech Szychowski: LG> usable domain name of the aforementioned form: LG> zone#.net#.node#.fidonet.org -- without having to even store the LG> actual DNS naming information in the nodelist. try f64.n5049.z2.fidonet.net:) We (2:R50) was established this domain sometimes ago and planning to use it for fido-over-ip, in DNS-like manner. Only thing we discuss now is where in DNS record we'll store info about fido-related stuff. ‚á¥å ¡« £, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #399 [1995] Scn From : Amir Shabashvili 2:5049/12 08 Oct 97 11:41:32 To : Sean Rima 09 Oct 97 07:02:18 Subj : IP-access ------------------------------------------------------------------------------- Hello Sean! Žâ¢¥ç ï ­  ¯¨á쬮 Sean Rima ª Fyodor Ustinov: SR> I tried to do an DNS on fidonet.net but it doesn't appear to have any SR> of the BinkD mailers listed yet. >telnet f64.n5049.z2.fidonet.net 24554 SYS Flying_Dragon_Soft ZYZ Alex_Bakhtin LOC Kazan,_Russia NDL 64000,TCP,BND,NOSMTPTIME 1997/10/08 11:44:25" VER binkd/0.9.1/FreeBSD binkp/1.1O 2:5049/64@fidonet 2:5049/256@fidonet 2:5049/12.16@fidonet 2:5049/12.1@fidonet ... Other DNS support for binkp-like mailers is't ready yet. ‚á¥å ¡« £, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #400 [1995] Scn From : Mats Wallin 2:201/329.11 08 Oct 97 10:30:38 To : Lawrence Garvin 09 Oct 97 07:02:18 Subj : IP-connectivity ------------------------------------------------------------------------------- LG> Because P4 does not mandate the -telecommunications- LG> technology which must be used, but only the -computer LG> software capability-, I would suggest that an IP-only node LG> that is accessible during ZMH via IP-address is fully LG> compliant with Policy 4. That's exactly the same way I interpret Policy 4. Mats mw@defsol.se --- * Origin: Definite APXw (2:201/329.11) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #401 [1995] Scn From : rafal wiosna 2:480/33 08 Oct 97 09:12:50 To : Lawrence Garvin 09 Oct 97 07:02:18 Subj : what about... ------------------------------------------------------------------------------- þ (RAF, Sun Oct 05 1997) Lawrence Garvin -> rafal wiosna: LG> I'd suggest using the _NODENAME_ field, as opposed to the _SYSOPNAME_ LG> field Yes, that's what I meant. - Rafa’ "WXR" WiOS/2na. --- GoldED/2 2.51.A1026+ 30PL2 * Origin: Love W95? Try this: 'echo f000:0000 ffff 66 | debug' (2:480/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #402 [1995] Scn From : Chris Maddock 3:640/302 04 Oct 97 06:30:58 To : Pedro Lima 09 Oct 97 07:02:18 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- On 01 Oct at 01:12, Pedro Lima of 2:362/21 wrote to Ger Vloothuis: [.....] PL> A nodelisted number initiated with '000-' would fall in the last PL> category, so the translator would append the international prefix. This PL> makes the number an impossible number in Australia unless the PL> international prefix there is '0' or '00'. The International access number can be one of several depending on what one wants. They are a four digit number with the format 00xx i.e. 0011 To call you, I would dial 0019 351 1 886 2878. Regards, Chris Maddock chrism@bbs.st.net.au --- Msged/386 4.20 beta 2 * Origin: Diagnostic CBBS - DownUnder - (3:640/302) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #403 [1995] Scn From : Rune Johansen 2:210/20 08 Oct 97 08:43:02 To : Lawrence Garvin 09 Oct 97 07:02:18 Subj : IP-access ------------------------------------------------------------------------------- > Actually, isn't it the responsibility of the -client- to choose which port to > initiate the session against? Yes, that is true. > If I "telnet 23" then the telnetd on port 23 answers. > If I "telnet 3141" then the vmodemd on port 3141 answers. If I "telnet port", I expect a telnet handshake from the port I connect to. If I don't get a telnet handshake, I cannot use the telnet client program to connect to the port on the host. If the daemon on the host do telnet handshake on port 3141 in addition to other handshakes, that's ok. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #404 [1995] Scn From : Max Masyutin 2:469/38.12 08 Oct 97 15:01:22 To : All 09 Oct 97 07:02:18 Subj : The Real FidoNet Physical Layer (JFYI) ------------------------------------------------------------------------------- Hello All! Here is an extraction from FTS-0001: === cut === H. Physical Layer : the Actual Connection of Two FidoNet Systems Will one of the more hardware-oriented comm types give me some idea of what's needed here? Can we leave it open enough to allow implementation over a non-dial net? Thanks. === cut === Max. [Argus Team] --- * Origin: max@ritlabs.com (2:469/38.12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #405 [1995] Scn From : Amir Shabashvili 2:5049/12 08 Oct 97 12:55:12 To : Denis McMahon 09 Oct 97 07:02:18 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Denis! replying to message from Denis McMahon -> All: <...skipping a piece of wisdom..> DM> Why don't we stop debating what is and is not a valid TCP/IP extension DM> of FTS-0001, FTS-0006, EMSI, YooHoo, Wazoo etc, and instead DM> concentrate on two things: DM> 1) A mechanism for including "Internet" node adresses in nodelist DM> entries. DM> 2) A mechanism for distinguishing the capabilities of an DM> "internet" node. DM> Another issue is DM> 3) A method for showing On-line times of an "internet" node. DM> For (1) We have I think the following ideas: DM> a) IP address in telno field behind non-country-code DM> b) IP address or hostname in systemname field DM> c) IP address or hostname in flags field DM> d) DNS translation of f*.n*.z*.fidonet.org address The better way, IMHO, is got all info about protocol,... from DNS requests, only thing we are really need in nodelist is a first and last name of person and fido address. So I vote to IP nodelist, different from usial one, for all IP nodes, and IP address in flag field for nodes with both PSTN and IP. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #406 [1995] Scn From : Eugene Gladchenko 2:5061/15 08 Oct 97 14:11:16 To : Lawrence Garvin 09 Oct 97 07:02:18 Subj : IP addressing ------------------------------------------------------------------------------- Hello Lawrence! LG> when I tried placing something like this in my source segment: LG> IP:198*216*61*12 LG> I got a message about "illegal characters" in the telephone field. I think telephone field shouldn't be taken into account. It is *telephone* number field so let it contain only telephone number or "-Unpublished-". If there is any reason to place this information into nodelist it should be something like ",U,IP:194.65.123.45" or ",U,IP:ufm.prospect.com.ru". Do you agree that would be compatible with all existent and future fidonet software? --- * Origin: Try working in my shoes (FidoNet 2:5061/15) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #407 [1995] Scn From : Amir Shabashvili 2:5049/12 08 Oct 97 13:04:14 To : maciej grzeszczuk 09 Oct 97 07:02:18 Subj : IP-connectivity ------------------------------------------------------------------------------- Hello maciej! maciej grzeszczuk -> Pedro Lima: mg> Wed, 01 Oct 97 17:38:14 +0200 Pedro Lima napisal byl w mg> fido.ip_connect: >> be considered as a minimal standard is not an obvious choice, although >> BinkD seems to be supported in most of the platforms... mg> binkd cannot be treated as a standard, as it's compatible only with mg> itself. it's compatible with bink-style outbound, and that's enought Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #408 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 09 Oct 97 08:27:24 To : All Subj : Nodelist entries for IP-Nodes ------------------------------------------------------------------------------- Hello All! Just a few thoughts about fields and their purposes in the nodelist: > [excerpt from a future Segment of net 2:2446] >-8------------------------ byte here ------------------------8-< ,301,fido.nrh.de,Uedem_FRG,Lothar_Behet,49-2824-922240 ,CM,XA,V34,U,X75,VM,BNP, ... >-8------------------------ byte here ------------------------8-< If you take a close look at this example, you will see, that it contains all vital information for any kind of connectivity. Furthermore a simple way of backup-routing using another access media is integrated, so that this is just a question of mailer (task) tuning. This is independant of a new (better) nodelist format, but fulfills any need for our purposes based on the existing format and dependant software. In the new nodelist format a kind of backup node should be considered, so that even a total system crash does not disturb communications. The backup node should have equivalent capabilities concerning to connectivity and routing structures. Then we even had a failsafe system, as long as any communication lines (and energy:) are available. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #409 [1995] Rcv Scn From : Pedro Lima 2:362/21 08 Oct 97 05:29:40 To : Lothar Behet 10 Oct 97 07:01:36 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello, LB> 1. As it is impoosible to put a fqdn in the phone field (due to makenl LB> primarily), the system name field accepts both (fqdn or ip#). As far as LB> only one of both is needed, this one field offers maximum flexibility. Temptative. But if the problem is MakeNL, all we have to do is replace it, which should be a fairly simple thing to do. Using other than the phone field to place the address doesn't make sense to me, because the phone field in the nodelist serves the practical purpose of informing the mailer where he has to connect to. If using this field to carry this information proves to place unsurmountable difficulties (in the practical sense of the word), then I agree to use something else, but this seems not to be the case. There's also another rationale which is the possibility of creating a standard procedure for accomodating non-PSTN technologies. We're talking today about IP, but tomorrow we may be discussing X.25 nodes or some other technology. LB> 2. there is no dial translation problem in that case. True. LB> 3. No seperate nodelist entry for the additional ip-capability is LB> needed. Yes, as long as it's additional. LB> As you can see, all vital information (ip and pstn) is handled within LB> a single nodelist entry, as long as the flags are clearly defined. And as long as the node has both technologies. For IP-only nodes that would probably imply them being listed as Pvt which isn't actually adequate to a full-fledged node, IMHO. LB> As a hint for nodelist-compilers a flag IPF (->fqdn) or IPN (->ip#) LB> may be defined, but at moment i know no program, which handles these LB> differently. (Or just IP for FQDN/IP# in the system name field). I don't think there's a need to differentiate between a FQDN and an IP#. I don't even know if there's a need to differentiate between IPv4 and IPv6. But an identification flag (such as 'IP') would certainly be useful. LB> On long term we can specify an advanced nodelist format, which might LB> contain all information (even for a multiline-system with different LB> protocols) in a single entry. That would be the best solution, for sure, but it would imply replacing the existant software. Translation tools could be possible, but the translation of an entry of a multi-line system would be harder. Perhaps we could use Point entries in the translated nodelist? Anyway, we're yet somewhat far from getting to that discussion. LB> PS: This may be a quick and dirty solution, but in fact we can work LB> with it on a very short term without any interference to existing LB> software and without any annoying side effects to not especially LB> prepared sysops :) I don't see such a configuration to be so complicated that requires special sysop preparation. :-) Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #410 [1995] Scn From : Pedro Lima 2:362/21 08 Oct 97 05:29:24 To : Lech Szychowski 10 Oct 97 07:01:36 Subj : IP-access ------------------------------------------------------------------------------- LS> Do you mean "as opposed to the whole fidonet.org ie we don't care LS> about other zones" or "there will be no delegations and we have to LS> think in terms of a zone-wide DDNS server"? Actually, neither. I was saying that the delegation only makes sense in the fidonet.org domain (sorry for having included the z2), because other FQDNs may also be nodelisted. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #411 [1995] Scn From : Pedro Lima 2:362/21 08 Oct 97 04:33:46 To : Lech Szychowski 10 Oct 97 07:01:36 Subj : IP-connectivity ------------------------------------------------------------------------------- LS> I think I got it. Let me rephase it: an IP-node has to be accessible LS> for at least NNN minutes in one contiguos period each 24 hours, also LS> start and end of this period have to be explicitly declared using "T" LS> flags. LS> Did I miss something? No, that's precisely what I meant. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #412 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 10 Oct 97 09:56:32 To : Pedro Lima Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Pedro! On 08 Oct 97 wrote Pedro Lima to Lothar Behet: LB>> 1. As it is impoosible to put a fqdn in the phone field (due to LB>> makenl primarily), the system name field accepts both (fqdn or LB>> ip#). As far as only one of both is needed, this one field offers LB>> maximum flexibility. PL> Temptative. :) PL> But if the problem is MakeNL, all we have to do is replace PL> it, which should be a fairly simple thing to do. At first you have to replace Makenl on every instance, were "new data" is processed. In second order you have to assure, that every nodelistcompiler (even Frontdoor and for the Amiga/ST-system) can handle those data in an appropriate way. At least these programs are used by nodes (mebers of Fidonet, you remeber?:), which must not be locked up by a change, which was not approved on _all_ systems. PL> Using other than the phone field to place the address doesn't make PL> sense to me, because the phone field in the nodelist serves the PL> practical purpose of informing the mailer where he has to connect to. Is the system name not in a certain way equivalent? PL> If using this field to carry this information proves to place PL> unsurmountable difficulties (in the practical sense of the word), PL> then I agree to use something else, but this seems not to be the PL> case. At this moment, there is (as far as i know) no publicly available (and used) nodelistcompiler for all mailers, which supports any kind of ip-data in the nodelist for any mailer. PL> There's also another rationale which is the possibility of creating a PL> standard procedure for accomodating non-PSTN technologies. We're PL> talking today about IP, but tomorrow we may be discussing X.25 nodes PL> or some other technology. Maybe, that tomorrow we already have an extended nodelistformat, which supports any kind of communication access. I would appreciate that, but integration of IP-access is a problem today and should be handled as soon as possible. LB>> 2. there is no dial translation problem in that case. PL> True. LB>> 3. No seperate nodelist entry for the additional ip-capability is LB>> needed. PL> Yes, as long as it's additional. IMHO ip-access must be only an additional flag in the nodelist (!), as this the reference worldwide. Which entries circulate in regional or local lists (pointlists, etc.) does not have influence on international level. LB>> As you can see, all vital information (ip and pstn) is handled LB>> within a single nodelist entry, as long as the flags are clearly LB>> defined. PL> And as long as the node has both technologies. For IP-only nodes that PL> would probably imply them being listed as Pvt which isn't actually PL> adequate to a full-fledged node, IMHO. Yes, that is true and also my intention. If we would allow any kind of communication access to Fido on a too low level, the nodelist will grow in an extensive way. By putting the level slightly higher, the nodelist remains a usable intrument for "direct" international access, without blocking communication on a regional level, where there are pointlists, too. LB>> As a hint for nodelist-compilers a flag IPF (->fqdn) or IPN LB> (->> ip#) may be defined, but at moment i know no program, which LB>> handles these differently. (Or just IP for FQDN/IP# in the system LB>> name field). PL> I don't think there's a need to differentiate between a FQDN and an PL> IP#. I didn't have a real intention for that at the moment, but i feel the need to integrate a kind of general controling flag for IP. PL> I don't even know if there's a need to differentiate between IPv4 and PL> IPv6. But an identification flag (such as 'IP') would certainly be PL> useful. :) But "IP" itself could sign the nodelist conversion utility to use the contents of the system name (i.e.) in place of the phone number. LB>> On long term we can specify an advanced nodelist format, which LB>> might contain all information (even for a multiline-system with LB>> different protocols) in a single entry. PL> That would be the best solution, for sure, but it would imply PL> replacing the existant software. Translation tools could be possible, PL> but the translation of an entry of a multi-line system would be PL> harder. Perhaps we could use Point entries in the translated nodelist? PL> Anyway, we're yet somewhat far from getting to that discussion. That is true, it will last a certain time, before the extended nodelist can be used. But if we always wait for the better solution, we would never get one step further :) LB>> PS: This may be a quick and dirty solution, but in fact we can LB>> work with it on a very short term without any interference to LB>> existing software and without any annoying side effects to not LB>> especially prepared sysops :) PL> I don't see such a configuration to be so complicated that requires PL> special sysop preparation. :-) I do either, but others were constantly mourning about possible problems. So why not create a solution, which does not interfere with actual, widely used system setups? The new ip-connectivity requires (at this moment) a special setup (nodelist translation) on (at least) most systems, but as a standard is defined, the tools for this will be public in a short time. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #413 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 10 Oct 97 14:28:22 To : All Subj : Listing IP-only nodes? ------------------------------------------------------------------------------- Hello All! My mails about listing conditions for ip-nodes are a little prohibitive and i know that. Therefore i will explain some of my intentions in this mail. >-8------------------------ byte here ------------------------8-< Policy requirements: -------------------- 1. Mailer connect Our Fido-policy declares clearly, that there must be a direct connect between mailers. But it is open to the technology, which is used by each individual session. 2. Online times A normal node should be CM, but there at least the NMH is required. So there is a way for a beginning node to participate in Fido without a full-time dedecated line for this purpose. 3. Points They can do what they at any time of the day. Sometimes they poll their uplink regularly, soemtimes not. But they communicate with others using the fidonet as a medium. These are useful conditions for basic operation of the Fidonet. When we think about integration of IP as additonal access medium to fidonet, these basics should be honored. Conclusions: ------------ 1. IP-lines must allow a mailer session at least at a defined time slot. This is not met by ftp and mail-based protocols are completely out of control, because they are stored outside fido, until they are picked up by the individual. This can be a serious problem on the level of a routing system (ie. Hub or Host), as he is responsible for the delivery of mails. 2. Furthermore only a few programs respect the Txy-flag correctly, which results mostly in the use of zmh for basic communication in simple setups. An IP-node with a dialup-connection to the internet can not gurantee, that he is online at the wanted timeslot, as this is not under his control (at least, much less than a dedicated (or leased) pstn or ip line). 3. The general usage of domains with very short ttl might even be annoying in the internet (the medium and its carriers) itself, so that at a certain grade of usage this might lead to very unpleasant actions. So variable ip#'s on dialup lines are a general problem at this moment. What would happen, if the conditions for an ip-node are on a very low level? There would be an invasion of new nodes, which do not meet the basic conditions of a traditional fidonet member. In fact, the nodelsit might explode to a kind of "internet user list" and this will be a serious problem for the general node node, who does not operate his private system on a super-computer are large workstation. On the other hand, communication is the essence of fidonet (and any other mail network). If we define certain flags for additional ip-access, each interested indivdual can get a connection to fidonet and communicate with other members. So the flags should include non-direct methods for connectability information with a specified protocol. (As this is used, the selected system may grow to a routing system itself, which is responsible to its users. Furthermore it needs a safe connection to others routing systems, to guarantee the transport of mail itself and at an conveniant transmission time). For routing purposes only a dedicated (fulltime?) line fulfills this demand, as there is not only outgoing traffic, but also incoming. Consequences: ------------- 1. At least one mailer protocol (direct) must be listed for an ip-node 2. Others may be added and these may be of indirect kind (FTP,Email-based) 3. For general access to other members of fidonet a phonenumber should be be required, but a listing might be possible as a private node. The pvt-node is not a full member (elections for example) and should only happen according to the conditions as clearly stated in P4, paragraph 2.1.9. Anybody else, who is not part of the routing structure, nay be listed as a point. Regional pointlists normally use the same flags (or a superset) as the international nodelist and can contain an individual phone number (or something equivalent:). The communcication itself between the members of fidonet is not dependant on the status (anywhere between point and IC), but on the intentions of each single individual. The organization of the communciation flow is another aspect and should be considered on the appropriate level, as long as other members rely on it. >-8------------------------ byte here ------------------------8-< Think about it, before the flags (and their purposes) are finally defined and general usage for listing of ip-nodes is allowed. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #414 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 10 Oct 97 14:55:28 To : Amir Shabashvili Subj : IP-connectivity ------------------------------------------------------------------------------- Hello Amir! On 08 Oct 97 wrote Amir Shabashvili to maciej grzeszczuk: mg>> binkd cannot be treated as a standard, as it's compatible only mg>> with itself. AS> it's compatible with bink-style outbound, and that's enought As the protocol specification (BinkP) is available to the public, somebody may program "Backdoor" for mailers, which use another local organization structure, if he (or she) feels a real need to do this :) Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Nobody is angry about anybody, who waits for somebody (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #415 [1995] Rcv Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 02:08:00 To : Lothar Behet 10 Oct 97 19:00:10 Subj : A bit of steering ... ------------------------------------------------------------------------------- > As you can see, all vital information (ip and pstn) is handled within a > single nodelist entry, as long as the flags are clearly defined. Only as long as there is just one IP address for a Fidonet address. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #416 [1995] Scn From : Rune Johansen 2:210/20 09 Oct 97 01:06:08 To : Marco d'Itri 10 Oct 97 19:00:10 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>not change, but also allow vmodem connections. the standard that all ip nodes >> would accept shoudl be one. > If we must have just one standard, this standard should be binkp, not telnet. > Using telnet, emsi and zmodem over an IP link is a very stupid decision, > zmodem and EMSI (or FTS-1) are not intended to be used over a low latency > link. It seems like we would have two camps in this debate: One that would vote for BinkP (those who already run it), and those who want a session that you run ordinary mailer sessions over (those that run anything else _but_ BinkP). Of course you (and I) don't want to be forced to use any protocol that is not already being used by your own system. That is understandable. But, think of this: What terminal software makes it possible for a _person_ to log into a BBS system that is lying behind a fidonet mailer, via the BinkP protocol? BinkP is a mailer-session-only protocol, and cannot (as far as I have read the specs) be used for anything else. But, in a telnet session you can run BinkP as transfer protocol instead of ZModem. You can run BinkP handshaking instead of EMSI. You can even use Telix with IEMSI script via vmodem-like software. BinkP is a truly fast and efficient protocol, but it limits itself too much for future expansion and use, to be taken in as minimum common protocol. Telnet is a protocol that creates a reliable (TCP) session between two hosts. Then you can run whatever your heart desires on top of that. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #417 [1995] Scn From : maciej grzeszczuk 2:480/70 08 Oct 97 22:47:38 To : Victor Prylipko 10 Oct 97 19:00:10 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 07 Oct 97 10:11:44 +0200 Victor Prylipko napisal byl w fido.ip_connect: > At this point you are wrong. binkd is compartible with Argus. oh yeah. and vmodem is compatible with any mailer, as it's tunneled standard session. 479 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: Vale Fax-Modem (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #418 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 01:38:00 To : Lawrence Garvin 10 Oct 97 19:00:10 Subj : IP-connectivity ------------------------------------------------------------------------------- > registered name, then a mere modem flag (say, UIP) could be used to > override the telephone field in the source nodelist, and construct a > usable domain name of the aforementioned form: > zone#.net#.node#.fidonet.org -- without having to even store the actual > DNS naming information in the nodelist. Sure. And that's exactly the solution someone - please forgive me, I've forgot the name again :( - suggested a few days ago. It's IMHO a very attractive one. It uses existing mechanisms and maintains backward compatibility as much as will ever be possible... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #419 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 01:44:00 To : Fyodor Ustinov 10 Oct 97 19:00:10 Subj : IP-access ------------------------------------------------------------------------------- > BTW. Any node supported binkp protocol can be published in fidonet.net > domain. Now that's something I don't like. Another domain? What for? IMHO all it will bring would be some mess and misunderstangings. What we need is not a new domain - it is a common platform, a solution acceptable for (more or less) everyone from both technical and practical point of view. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #420 [1995] Rcv Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 01:50:00 To : Lothar Behet 10 Oct 97 19:00:10 Subj : Standards, was: IP-connectivity ------------------------------------------------------------------------------- > As long as fido is a hobby network of privateers, we should try to > exchange mail (and files) as cheap as possible for each individual > member and with as less management overhead as possible. I doubt that using SMTP of FTP contributes to decreasing the management overhead. > At this point of view, any discussion of a standard mailer (or protocol) > for ip-connectivity is completely without sense, too. If we are to say "IP capability is no more than an additon to normal PSTN node capabilities/requirements" we'll end up having no room left for the IP-only nodes. And I fail to see how we can have IP-only nodes without a standard way of communicating with one. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #421 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 01:55:00 To : Sean Rima 10 Oct 97 19:00:10 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- > program but Binkp/1.0 the protocol, which is now in Argus for normal > Teleco calls and is around 50% faster handshaking tham EMSI. How big the session negotiation/handshake overhead in everyday IP connections? And how much smaller we can make it by using BinkP? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #422 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 02:02:00 To : Rune Johansen 10 Oct 97 19:00:10 Subj : A bit of steering ... ------------------------------------------------------------------------------- > I have said this before, and I will say this again. We should not be so > narrowminded to rely on "fidonet.org" DNS for implementing a conformant [...] > Please, think of "othernets" too, even if you are not a member of such Yes, I see a valid point here. For a moment I felt very tempted to say that a mailer should take care of adding the right domain to the constructed fXX.nYY.zZZ - but I'm afraid it is a bit too much of a requirement for most mailers we have around. On the other hand, if we are talking about IP-capable mailers, we are talking about the software that is still being actively developed, which means the developers might quite fast implement this feature... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #423 [1995] Scn From : maciej grzeszczuk 2:480/70 08 Oct 97 22:44:34 To : Sean Rima 10 Oct 97 19:00:10 Subj : Re: BinkD (0.9.2) specification ------------------------------------------------------------------------------- From: maciej grzeszczuk Mon, 06 Oct 97 18:10:56 +0200 Sean Rima napisal byl w fido.ip_connect: > Maciej Grzeszczuk (Got it wrong???) did a couple of days ago. I think I > should i said that we should specify one standard, available at every ip-node system. and i proposed vmodem. i don't say that we shouldn't include binkd nodes in a nodelist, but they should also support vmodem connections - some kind of fst-0001 for ip-nodes. 478 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: jestem aptekarzem, przeciez MUSZE miec jakas wloc (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #424 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 01:52:00 To : Marco d'Itri 10 Oct 97 19:00:10 Subj : A bit of steering ... ------------------------------------------------------------------------------- > The mailer does not needs to know if the protocol is IPv4, IPv6, SLIP or > PPP. But it has to pass the address of the party it wants to connect to down the protocol stack (not even mentioning parsing the nodelist entries first). Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #425 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 03:35:00 To : Slava Filimonov 10 Oct 97 19:00:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > We're talking about ip-connectivity isn't it ? Yes, we are. > As long as you use BINK-style outboud, This assertion often fails. A lot of people does not have it. For example, my home system has never used one. > you can keep your old phone mailer I could, if (a) my old mailer would be supported on the platform I use my new one on, (b) both mailers could share this subdirectories with no problems. > Is this a real solution for all or what ? No. This is, I admit, a viable solution for people already using binkd-style mailer; especially if they have a lot of other systems running binkd mailers nearby. > Finally, if you want to stick with vmodem, than keep ip for your > convenience. Just alter your outbound to bink-style and keep 'em all - > old mailer, binkd, your old mailer with vmodem. What for, if we could have just one mailer supporting all the protocols we adopt as standard ones? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #426 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 02:21:00 To : Denis McMahon 10 Oct 97 19:00:14 Subj : IP-connectivity ------------------------------------------------------------------------------- > OK, so both ftp and uucp are means of transferring pkt, arcmail, > nodediffs, fidonews. In that case, surely both ftp and uucp are carrier > protocols between ftn systems. I'll still insist on treating FTP as somethimg much less suitable than UUCP, but in a way I can agree. > Hmm, this means you can have a fidonet node with no mailer, just a mail > processor and ftp / uucp. Is this valid? Messages are still transferred I'd say in case of UUCP uucico is much like the mailer :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #427 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 02:35:00 To : Denis McMahon 10 Oct 97 19:00:14 Subj : IP-access ------------------------------------------------------------------------------- > Thing is, his entry *MUST* (my understanding anyway) be in the DNS at > either z2.fidonet.org /or/ .n.z2.fidonet.org for it to be > looked up. Yes, it has. > If the entry isn't in one of those two locations, then a dns > query for fx.ny.z2.fidonet.org will not find the ip address for 2:y/x! DNS is a hierarchical beast. Each part (subtree) of the hierarchy can be anywhere, as long its parental part knows where it is. And this is universally true for all domains (except root, or course), so I see no special problem with fidonet.org domain. Some people do maintain nodelist segments, some people do maintain DNS domains - what's wrong with some of them maintaining domains for nodes? > Yes, but (again my understanding) is that dns entries within any > hierarchy have to be manually maintained at the recognised DNS server(s) > for that hierarchy. Both yes and no. Yes, because it is us humans who create entries, both in nodelist segments and DNS databases. No, because - unlike in FTN - DNS entries does not have to be "passed up" the hierarchy; resolvers will dynamically make all queries when necessary, walking down the hierarchy as deep/far as necessary. > LS> C'mon, let's be consistent. > More to the point, let's make sure what we're proposing can work, eh? I see no reason why constructing a canonical form of FQDN (ZZ:YY/XX -> fXX.nYY.zZZ.fidone) and then looking up the IP address using standard resolver API defined for a given platform should fail. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #428 [1995] Rcv Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 03:24:00 To : Lothar Behet 10 Oct 97 19:00:14 Subj : IP-access ------------------------------------------------------------------------------- > Which other implementations of Vmodem are available for other operating > systems and especially where is the source published? The "tx" version of ifmail claims to be vmodem compatible: fido 60179/tcp # the standard ifmail port (TCP) # incomming fido via telnet mode tfido 60177/tcp # (Vmodem) port used in Russia vmodem 666/tcp # (Vmodem) port used on OS/2 and Windows And yes, it is available as source. > Mail based protocols are buffered, so in that case you never know, > when a message reaches the destination. Further more stored packets > can easily be messed up, which is not possible in a direct connection > between mailers. It is only a question of routing. When we are not talking about direct calls, also in Fido we have "mail buffering" (store-and-forward). And routing policy is something every sysop can (from the technical point of view) define himself. One uucico talking to another is in this respect no different from one mailer taling to another. > BinkD (the mailer with BinkP) itself is available for OS/2, different > Unix dialects, Win 95 and NT (Not to forget the publicly available > source code). Ifmail README file says as follows: : There is also a special protocol optimized to use over TCP/IP connection, : contributed by Stanislav Voronyi , it is identified : by EMSI proto code TCP (not registered). So I think it might be worthwile to take a closer look there. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #429 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 02:17:00 To : Nick Soveiko 10 Oct 97 19:00:14 Subj : IP-access ------------------------------------------------------------------------------- > for how many of the mailers do you have sources readily available? > (right of the top of my head) i can name only two: that's binkleyterm > and binkd. What you wrote clearly indicates the source of the difference in opinions we'va seen here: there is a group of sysops that lives in a bink* realm and a group that lives is a ifmail one. It's not supposed to be any offense; it's just something I've noticed and mentioned without any intentions to depreciate any group. > uucp is probably fine. now comes the next question: can you propose a > technology for using any uucp flavour for the purpose of fidonet > transport? right now. that is, an already working technology. > i bet you not. Do we have UUCP implementations for almost every platform? I believe we have. Do we have IP (incl SLIP/PPP) stack implementation for almost every platform? I belive we have. Of course there is no (AFAIK) product readily availble that would support this kind of carrier protocol - but there is no product that supports other protocols like SMTP or FTP, either. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #430 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 03:45:00 To : Slava Filimonov 10 Oct 97 19:00:14 Subj : IP-access ------------------------------------------------------------------------------- > LS> What about using UUCP in these cases? Its implementations have been [...] > So let try binkp protocol to proove its simplicity and reliability. This issue (using UUCP vs using BinkP) is some kond of a misunderstanding. Are you trying to say that one should never consider using UUCP and go for BinkP instead? > And don't forget, UnixUnixCopyProtocol was designed for Unix systems ;) So what? Does it make it an unholy one? Or an unuseful one? I'd rather say that nowadays more and more platforms drift towards having filesystems and user concept more like the one supported already a long time ago by UUCP. Therefore, UUCP might turn out to have some advantages. > we're want FFCP - fidofidoCopyProtocol - binkp ;)) No. We want a protocol that most of us can use. The more, the better. > btw, and why do they start to use HTTP protocol, if UUCP were so good ? In short: UUCP is in some respects too/unnecessarily complicated, in some others too/unnecessarily powerful. But I'm afraid this question is well beyond the scope of this echo... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #431 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 03:46:00 To : Igor Bilyi 10 Oct 97 19:00:14 Subj : binkd vs vmodem ------------------------------------------------------------------------------- > vmodem is 2-3x slower than binkd, want to try? i'm ready In negotations or transfers? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #432 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 03:52:00 To : Sean Rima 10 Oct 97 19:00:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > So do I. But ruling out a protocol that is in daily use by over 100 > Ipmailers seems the wrong way to go. This is a double-edged sword. There might be a comparable number of nodes using some other protocol - and what then? :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #433 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 03:56:00 To : Sean Rima 10 Oct 97 19:00:14 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- >> allowed, but not as only protocol that ip node supports. > Okay, but the protocol is BinkP So it looks like we are about to say the lowest common capability is BinkP plus... EMSI over vmodem/telnet/raw? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #434 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 03:54:00 To : Sean Rima 10 Oct 97 19:00:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > I could not have a Telnet mailer operating on port 23 as I have to > telnet into my shell account to read some mail. Also to start and stop > both the mailer and tosser from time to time. Reconfigure your system to launch telnet server (for mailer or for human logins, whichever you like more) on some other port. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #435 [1995] Scn From : Steve Woodmore 2:254/410.1 08 Oct 97 18:01:02 To : Lech Szychowski 10 Oct 97 19:00:16 Subj : IP-connectivity ------------------------------------------------------------------------------- * Replying to a message in : SAVEAREA Hi Lech Szychowski, hope you are having a nice day 07-Oct-97 01:01:00, Lech Szychowski wrote to Steve Woodmore Subject: IP-connectivity LS> replaced with some reliable/controllable solution. SMTP has no LS> "resend from" capability, no guaranteed allowable message size, no LS> widely available software utils for dealing with files encoded LS> into message bodies, no session passwords etc. SMTP is great for LS> sending relatively small messages but certainly it is not a LS> protocol of choice when it comes to mocing files around. I'm Really?, then I come I send out upwards of 30MBs of echomail/day via smtp as well as files, using a commonly available program (Fido2int)? Which does all the things you say it doesn't -=> Steve Woodmore <=- --- Terminate 5.00/Pro * Origin: Leaving NET440 :( (2:254/410.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #436 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 04:22:00 To : Amir Shabashvili 10 Oct 97 19:00:16 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > if you've online IP - because don't need any fido mailer stuff - modem/ > protocol/timeouts/_thousand_any_other_stuff *emulation*. Than, binkd is Unless you happen to have a bad link - either between you and your ISP or somewhere in the routing path. And such a situation is not an imaginary one, believe me. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #437 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 04:23:00 To : Amir Shabashvili 10 Oct 97 19:00:16 Subj : IP-connectivity ------------------------------------------------------------------------------- > it for fido-over-ip, in DNS-like manner. Only thing we discuss now is > where in DNS record we'll store info about fido-related stuff. There is TXT record type available. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #438 [1995] Scn From : Steve Woodmore 2:254/410.1 08 Oct 97 18:00:00 To : Lech Szychowski 10 Oct 97 19:00:16 Subj : IP-connectivity ------------------------------------------------------------------------------- * Replying to a message in : SAVEAREA Hi Lech Szychowski, hope you are having a nice day 07-Oct-97 01:01:00, Lech Szychowski wrote to Steve Woodmore Subject: IP-connectivity LS> afraid if we follow your idea we are just a step away from stating LS> that if I agree to do my best to carry packets on floppies to a LS> friend of mine, he can be a Fidonet node :( Only if you are FTSC001 compliant during ZMH -=> Steve Woodmore <=- --- Terminate 5.00/Pro * Origin: Chislehurst Kent (2:254/410.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #439 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Oct 97 04:16:00 To : Denis McMahon 10 Oct 97 19:00:16 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- The answer to subject is if we are to allow IP-only nodes there should to be the minimal set of protocols such a node is capable of. > FTP > SMTP/UUEnc > SMTP/Base64 I stand firmly against the above ones. Reasons: - how do they deal with duplicated filenames? - how do they deal with putting something on hold (ie transfrerring to the calling party something which name this party has no way of knowing about beforehand)? - how do they deal with update requests? - how does SMTP deal with file requests? - how does SMTP deal with resuming failed transfers? - how does SMTP deal with authorisation? > FTP standard. Calling system uses username anonymous and password > ":/". Called system accepts anonymous ftp upload of pkt > and arcmail. FTP received on port .. You'd have to write an extended capability FTP agents for that. > SMTP/UUEnc standard. UUEncoded pkt / arcmail to user "fidouue" at > hostname / ip address. SMTP received on port .. You'd have to write an encoding/decoding/splitting/reassembling software for that. And I personally doubt using this protocols is worth the amount of work we have to put in before it works. > sysops of ip systems can agree privately to implement any method however > they like for communication between their two systems. As long as their satisfy other requirements for being a node, yes. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #440 [1995] Scn From : Rune Johansen 2:210/20 09 Oct 97 22:46:02 To : Lech Szychowski 10 Oct 97 19:00:16 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Because of that we should consider a possibility that there is a BBS >> running behind the mailer. Telnet is a "universal" tool on most >> platforms, and can be used by endusers to connect to the BBS. If we use > Using telnet protocol does not imply using WKS on port 23. One can > easily have "telnetable" BBS on port 23 and some other telnet-based > service on some other port. You are absolutely correct here. I am talking about the telnet handshake protocol, applicable for telnet sessions. You can run binary high-level protocols on top of a telnet session. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #441 [1995] Scn From : Rune Johansen 2:210/20 09 Oct 97 22:56:52 To : Lawrence Garvin 10 Oct 97 19:00:16 Subj : Flags in nodelist ------------------------------------------------------------------------------- >> For that, is several reasons: What if this technique is to be used >> in other fidonet technology networks? > Then let THEM register their own *.net or *.org domain and maintain their own > DNS servers. There's nothing wrong with an FTN standard (which, btw, really > only applies to Fidonet anyway, technically) mandating that the NETWORK must > provide their own DNS servers in order to implement the technology. Truly the Fidonet spirit. Purely egoistic thinking. Why don't we define a nodelist to be of zone 1-6, and nothing else too? >> What if fidonet.org disappears? > What if it does? What if -ANY- domain that somebody relies upon for internet > access disappears? The answer: Somebody reregisters it! Yes, somebody reregisters it, but it is not _certain_ that they will have the same structure, or even be associated with the Fidonet at all. > Currently George Peace is managing fidonet.org -- I highly doubt it's going > anywhere in the near future, but if that's the concern, I'm sure between at > least zones 1, 2, and 3, where this issue is of most significance, somebody >could make arrangements to generate fifty US bucks in perpetuity to insure the > domain continues to be paid for. Even if you pay for something, it's not certain that you will keep it. >> What if I don't have DNS resolver, but only a hosts-list? > Lame, Rune. No, not lame at all. With all the warfare going on in the 'net today, you should not be absolutely certain that all sites will have a possibility to do DNS resolving. It's not even certain that all administrators of DNS servers will allow requests for resolving the fidonet.org domain to pass through. > DNS resolvers are available for just about every operating system platform >known to the internet. You don't even have to be a zone managing node, you can > put a caching-only DNS, and resolve the whole world through your own personal > server. All I am trying to say, is that we should not put ourself relying on a service that could be out of our control, that is place the whole resolving of what IP address to connect to in the nodelist from the fidonet.org domain. Also, as I have pointed out earlier, by including the address directly in the nodelist, we would open up for other access mechanisms than internet, like X.25, X.21, etc. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #442 [1995] Rcv Scn From : Rune Johansen 2:210/20 09 Oct 97 23:05:08 To : Lothar Behet 10 Oct 97 19:00:16 Subj : Standards, especially Vmodem ------------------------------------------------------------------------------- >Just a short notification about standards (from Vmodem.Txt, Author Ray Gwinn): Just a short comment on Ray's interpretation on the well-known port number of VModem... > [...] > of 3141. The port number 3141 has been assigned to the Virtual Modem > Protocol (VMP) by the Internet Assigned Numbers Authority (IANA). The > [...] From RFC1700: While the IANA can not control uses of these ports it does register or list uses of these ports as a convienence to the community. [...] The Registered Ports are in the range 1024-65535. The port number of 3141 are only _registered_ with the IANA, not _assigned_ or _reserved_ by the IANA. It has got nothing to do with the discussion here, just wanted to comment on it. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #443 [1995] Scn From : Rune Johansen 2:210/20 09 Oct 97 23:08:06 To : Denis McMahon 10 Oct 97 19:00:16 Subj : IP-connectivity ------------------------------------------------------------------------------- > OK, so both ftp and uucp are means of transferring pkt, arcmail, nodediffs, >fidonews. In that case, surely both ftp and uucp are carrier protocols between > ftn systems. They can be used as method of file transfer, but not as carriers of FTS-0001 mailer sessions, as they are not necessarily direct between the mailers/tossers/whatever. > I could argue both sides of this, so I'll sit on the fence instead. :-) I saw that.. :-) Just don't sit there too long. You might get a fence-pole up your butt when the fences are being raised higher :-)) --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #444 [1995] Scn From : Rune Johansen 2:210/20 09 Oct 97 22:47:48 To : maciej grzeszczuk 10 Oct 97 19:00:16 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Telnet is a protocol. Nobody says telnet servers have to listen >> just on port 23. > but we shouldn't allow log in procedure when connecting to ftn mailer via > telnet. Huh? Why not? Or do you think of "log in" as "log into unix"? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #445 [1995] Scn From : Rune Johansen 2:210/20 09 Oct 97 23:18:30 To : Denis McMahon 10 Oct 97 19:00:18 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- > Our objective, surely, is to find a way to increase FTN connectivity > principally using TCP/IP techniques, but taking "other" non analogue > technologies into account as well. You message summarizes up most of it. Good work. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #446 [1995] Scn From : Fausto Carvalho 2:361/7 09 Oct 97 20:50:54 To : All 10 Oct 97 19:00:18 Subj : About DNS-based solution ------------------------------------------------------------------------------- Maybe some of you are not aware of that, but during last year at least twice we had a giant colapse for days in the Internet, because of DNS problems. Fidonet (as now) can survive for weeks, months, without Nodelist updates. Any DNS-based network will stop in few hours... I'd also like to stress that one of the key features of Fidonet is to allow one to one communication without depending on somebody else. -FC- --- Msged/NT 4.10 * Origin: Midithru' (2:361/7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #447 [1995] Scn From : Rune Johansen 2:210/20 09 Oct 97 23:22:34 To : All 10 Oct 97 19:00:18 Subj : Some comments... ------------------------------------------------------------------------------- Here are some comment that I received about the discussions in this echo: --Cut-- This new ip's in nodelist -talk is quite funny. OS/2 net is using domain names/ip's in phone-field and it works fine and very easily. This requires change to fts-5, which is on it's way by ftsc, and new makenl. Old softwares may not prevent new features! "modem calls to ip-phonenumbers" is crap. If somebody can't configure his mailer then it's his fault. This can happen even now with normal phonenumbers. "multiple nodenumbers for one system with different protocols" is reality even now, for example I have 4 different nodenumbers, one for my each phonenumber. Therefore having one nodenumber for phone and one (or more) for ip is acceptable. If this last thing must be solved then easiest way is to use: ,node,name,location,sysop,phone,flags;phone,flags;phone,flags;... Or, as BBBS does it now: ,node,name,location,sysop,phone:phone:phone:...,flags What am I missing here? ---Cut--- I agree wholeheartedly with these comments... --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #448 [1995] Scn From : Mario Mure' 2:335/533 09 Oct 97 18:42:18 To : Sean Rima 10 Oct 97 19:00:18 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- In a message dated < 07 Oct 97 22:59:00 >, addressed to Mario Mure' about < Re: IMPORTANT! standard of protocol for ip-nodes proposal. >, Sean Rima wrote: MM>> My vote for binkp ;-) I'm testing BinkD on agnese.fidoitalia.net MM>> [195.120.19.166] and it works great !!! SR> Is that a full time link? Yes, it is. Fidonet node 2:33/505 and 2:2/3008 starting from the next nodelist. But beware, there's only a CDA so from some "location" (in internet sense, not geographical) it could be very slow... Ciao ! /mario/ mure@sistemia.it --- DMreply v2.0 * Origin: Stay cool if your hard disk say goodbye (2:335/533@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #449 [1995] Scn From : Amir Shabashvili 2:5049/12 09 Oct 97 11:55:34 To : rafal wiosna 10 Oct 97 19:00:18 Subj : what about... ------------------------------------------------------------------------------- Hello rafal! Žâ¢¥ç ï ­  ¯¨á쬮 rafal wiosna ª Lawrence Garvin: LG>> I'd suggest using the _NODENAME_ field, as opposed to the _SYSOPNAME_ LG>> field rw> Yes, that's what I meant. Why we would not using user flag enry? Why we must override nice fields like sysopname or nodename? It is not direct destination of this fields - contain IP address or other techinfo. ‚á¥å ¡« £, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #450 [1995] Scn From : Amir Shabashvili 2:5049/12 09 Oct 97 12:14:08 To : Ward Dossche 10 Oct 97 19:00:18 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Ward! Reply to message from Ward Dossche to Lech Szychowski: WD> If as some imply you also want to push for working with another list WD> which is managed outside the Fidonet structures, then I have nothing WD> left but to wish you sweet dreams ... because ... over my dead body! I remember youself tell us about IPzone (in ENET.SYSOP). So what about it? Over ....(what)? Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #451 [1995] Scn From : Amir Shabashvili 2:5049/12 09 Oct 97 12:21:44 To : Ward Dossche 10 Oct 97 19:00:18 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Ward! Replying to a message from Ward Dossche to maciej grzeszczuk: >> a/ ,U,IP(ADR) flag, that would carry the address. (imho the best idea) WD> This is not my opinion. You'd have a serious problem defining then WD> IP-only nodes. Do we really need that? I think IP-only nodes cann't live in usial fidonet. Different transport - different policy. Common policy cannt be good enougth for both IP and PSTN nodes. It must be another private IP-network, with modified fido technology and own policy. May be we think first about PSTN nodes with IP connectivity? Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #452 [1995] Scn From : Slava Filimonov 2:469/33 09 Oct 97 13:29:14 To : Marco d'Itri 10 Oct 97 19:00:18 Subj : IP-access ------------------------------------------------------------------------------- Hello Marco! 06 Oct 97 14:33, Marco d'Itri wrote to maciej grzeszczuk: >> my idea has one advantage - it allows both pstn and ip nodes within >> one entry, with one node number. no problem with mail addressing, >> packing, and so on... MI> If we have to radically change the nodelist we could use the extended MI> nodelist proposal, it address this problem even better. ...And why not to give up with nodelist for ip completely ? Instead put everything you need in DNS records ? in form of A p*.f*.n*.*z.fidonet.net? other records can be used for sysname,etc,routing... -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #453 [1995] Scn From : Vilo Mlich 2:421/50 09 Oct 97 18:59:00 To : Slava Filimonov 10 Oct 97 19:00:18 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Slava! 06.10. 1997 10:15, Slava Filimonov wrote to Ward Dossche: WD>> The core of Fidonet is the nodelist, think twice about that. SF> The _real_ core of Fidonet still public phone line. Nodelist is just phone SF> directory like yellow pages in each phonebox. Guess what is the core of SF> internet , and then think twice about that. Nodelist is not phonebook only: - some nodes with LO flag allow session only with listed systems - nodelist content geographical and routing structure zone/region/network/hub - message editor need nodelist, too. Write netmail to node, which is not in nodelist, is more complicated. The real core of the fidonet is the nodelist. IP-nodes should be in normal nodelist and should have normal addresses, not some 'zone 7'. regards Vilo vmlich@mbox.vol.cz --- GoldED 2.50.Beta5+ * Origin: T-Mail support node (2:421/50) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #454 [1995] Scn From : Pedro Lima 2:362/21 09 Oct 97 12:41:12 To : Chris Maddock 10 Oct 97 19:00:18 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hello, CM> They are a four digit number with the format 00xx CM> i.e. 0011 CM> To call you, I would dial 0019 351 1 886 2878. If I understood correctly, you have different international access prefixes according to the destination? Anyway, to what would your nodelist compiler translate a nodelisted '000-'? Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #455 [1995] Scn From : Pedro Lima 2:362/21 09 Oct 97 12:16:50 To : Denis McMahon 10 Oct 97 19:00:18 Subj : IP-access ------------------------------------------------------------------------------- DM> IMHO it would be short sighted of us not to consider the fidonet.org DM> domain. A solution that only works in one zone is hardly ideal. Naturally. See my reply to Lech. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #456 [1995] Scn From : Fausto Carvalho 2:361/7 09 Oct 97 20:32:20 To : All 10 Oct 97 19:00:18 Subj : Yet another 2 cents ------------------------------------------------------------------------------- Hi I've been following the discussion silently, and hope now on to be able to participate more frequently. Since it's relevant, let me introduce my IP node. I used to run here a phone-only system on a dedicated (old) machine, since some ZCs and ZECs ago. Recently I turned off my 1988 PS/2 50 and moved to a small NT window running Binkley32 2.60 as a service. After trying very hard different approaches and feeds to use IP transport (since I've a permament IP connection) gladly I found BinkD. I'm using it sharing the outbound with Binkley, and I can tell I'm very very pleased. I'm using it with my feed a long time VModem supporter (abroad), with some nodes and also with all my points. No more Vmodem blues. No more FTPbyMail or e-mailbe pains. I hope that whatever conclusion we reach doesn't include SnailMail or diskette-mail as being IP capable nodes and excelent ideas and developments such as BinkD are not left out. -FC- --- Msged/NT 4.10 * Origin: Midithru' (2:361/7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #457 [1995] Scn From : Rune Johansen 2:210/20 09 Oct 97 23:19:48 To : Nick Soveiko 10 Oct 97 19:00:18 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >if a user opts to connect to a bbs using telnet, it's completely irrelevant to > the way fidonet systems connect to each other. in the tcp/ip world we don't > have to share one communication port for both mailer and bbs. But by doing it, we would do the same as you do for a phone line. You fall through the mailer to the BBS, if you are not a mailer yourself. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #458 [1995] Scn From : Rune Johansen 2:210/20 09 Oct 97 23:13:54 To : Pedro Lima 10 Oct 97 19:00:18 Subj : A bit of steering ... ------------------------------------------------------------------------------- >> To my knowledge, a DNS lookup on a hostname will return the specific >> IP address, wether it is a v4 or v6 style address. > Yes, I was thinking of the cases where the IP address is nodelisted > instead of the FQDN. A IPv4 address is like this: 123.45.67.89. A IPv6 is separated by colons, like this: FFFF::AC34:34 (zero fields can be omitted). --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #459 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 10 Oct 97 20:29:22 To : Lech Szychowski Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Lech! On 09 Oct 97 wrote Lech Szychowski to Lothar Behet: >> As you can see, all vital information (ip and pstn) is handled >> within a single nodelist entry, as long as the flags are clearly >> defined. LS> Only as long as there is just one IP address for a Fidonet address. Do you really need more than one _fqdn_ to handle several protocols on different ports on several computers? I believe strongly that there is no real need for multiline-ip-systems in the nodelist. For larger conventional systems with several phone lines it is no problem, to spread the ip-relevant information on several lines, if the services run on several computers. Furthermore there is an extension possibility with pvt-nodes, as they are really required for routing purposes. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #460 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 10 Oct 97 20:34:22 To : Lech Szychowski Subj : IP-access ------------------------------------------------------------------------------- Hello Lech! On 09 Oct 97 wrote Lech Szychowski to Lothar Behet: >> Which other implementations of Vmodem are available for other >> operating systems and especially where is the source published? LS> The "tx" version of ifmail claims to be vmodem compatible: Did you check it? Just call i.e. 2:2/3000 (Vmodem from SIO OS/2, port 3141 assigend to VMP) to prove it, as that is the cause for the testnodes. LS> fido 60179/tcp # the standard ifmail port (TCP) LS> # incomming fido via telnet mode LS> tfido 60177/tcp # (Vmodem) port used in Russia LS> vmodem 666/tcp # (Vmodem) port used on OS/2 and LS> Windows From which source did you retrieve port 666? LS> And yes, it is available as source. >> Mail based protocols are buffered, so in that case you never know, >> when a message reaches the destination. Further more stored packets >> can easily be messed up, which is not possible in a direct >> connection between mailers. LS> It is only a question of routing. When we are not talking about LS> direct calls, also in Fido we have "mail buffering" LS> (store-and-forward). Routing is an option in FTN to keep the total cost on a convenient level to each sysops decision, but direct connections are possible (and used often). LS> And routing policy is something every sysop can (from the technical LS> point of view) define himself. One uucico talking LS> to another is in this respect no different from one mailer taling to LS> another. I think, that normally the connect will be to a relay host, which in general is not operated by a fido member. LS> Ifmail README file says as follows: [... some stuff deleted ...] LS> So I think it might be worthwile to take a closer look there. I do not claim any special protocol to be the sole standard for fido-over-ip, so i see no need to prove anything :) I just give anyone the possibility to connect to several protocols on my system (VModem:3141 and BinkP:24554 at this moment) and prove the usability of an additional access medium, which most other testnodes did not use yet. With others there is a continuous link in the meantime (operated with normal addresses and flags of 2:2/3xxx). Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #461 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 19:40:06 To : Lothar Behet 10 Oct 97 23:57:26 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: >2. the online time must be clearly stated, CM is preferred I think we should assume CM when no time is specified. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #462 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 14:58:50 To : Lech Szychowski 10 Oct 97 23:57:26 Subj : Re: IP-access ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >The "tx" version of ifmail claims to be vmodem compatible: I don't think ifmail-tx is compatible with the vmodem protocol, it can do just ftn over telnet: tfido stream tcp nowait fnet /usr/lib/ifmail/ifcico ifcico -t1 vmodem stream tcp nowait fnet /usr/lib/ifmail/ifcico ifcico -t1 the suggested command lines are not different. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #463 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 15:10:20 To : Rune Johansen 10 Oct 97 23:57:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >But by doing it, we would do the same as you do for a phone line. You fall >through the mailer to the BBS, if you are not a mailer yourself. With PSTN we must do that because we can't reserve a phone number for the mailer and another one for the front end. TCP has ports. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #464 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 19:35:38 To : Lech Szychowski 10 Oct 97 23:57:26 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >- how do they deal with duplicated filenames? Where is the problem? They will rename arcmail packets in a way they will not overwrite anything in the inbound, like normal mailers do. My vmailer program does that. >- how do they deal with putting something on hold (ie transfrerring > to the calling party something which name this party has no way of > knowing about beforehand)? I can't understand why you think this is a problem. My vmailer sends hold files like any other file attach. >- how do they deal with update requests? What is an update request? >- how does SMTP deal with file requests? By sending a .req file. The receiving program will intercept this file and create a file attach for the other node. >- how does SMTP deal with resuming failed transfers? email usually never gets lost, but I thought about a simple protocol that address this concern. >- how does SMTP deal with authorisation? My protocol supports encrypted transferts, PGP-signed and/or encrypted transferts (following the S/MIME standard) and clear password protected transferts. Please note that SMTP is not an encapsulation protocol, email is. I don't think your concerns are serious enough to be considered. > > FTP standard. Calling system uses username anonymous and password > > ":/". Called system accepts anonymous ftp upload of pkt > > and arcmail. FTP received on port .. >You'd have to write an extended capability FTP agents for that. There is already one, with source and GPLed. >You'd have to write an encoding/decoding/splitting/reassembling >software for that. I wrote one. It does not split and reassembly because I don't need that, but it's not a difficult feature to add. It's written in perl and GPLed. >And I personally doubt using this protocols is worth the amount of >work we have to put in before it works. Ok, just don't use it. (BTW, I think that non-PSTN email only nodes should be only points.) -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #465 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 15:09:08 To : Lech Szychowski 10 Oct 97 23:57:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: > > if you've online IP - because don't need any fido mailer stuff - modem/ > > protocol/timeouts/_thousand_any_other_stuff *emulation*. Than, binkd is >Unless you happen to have a bad link - either between you and your ISP If you have a bad link then binkd works much better than the ftn handshake over telnet or over the socket. It also has a lower latency and an higher bandwidth. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #466 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 15:30:36 To : maciej grzeszczuk 10 Oct 97 23:57:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- krap@zwieracz.psych.uw.edu.pl wrote: >oh yeah. and vmodem is compatible with any mailer, as it's tunneled standard >session. It's slower. I don't want to waste money because I must use a suboptimal protocol. And any half decent C programmer can port binkd to his platform of choice, the source is very portable. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #467 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 19:20:44 To : Lothar Behet 10 Oct 97 23:57:26 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: >At this moment, there is (as far as i know) no publicly available (and used) >nodelistcompiler for all mailers, which supports any kind of ip-data in the >nodelist for any mailer. AFAIK fastlst supports the fqdn-or-ip-in-the-phone-field style. >Maybe, that tomorrow we already have an extended nodelistformat, which >supports any kind of communication access. I would appreciate that, but >integration of We have one (the extended nodelist format I formalized last month in NET_DEV), but without a "political" backing it will never be widely used. >But "IP" itself could sign the nodelist conversion utility to use the >contents of the system name (i.e.) in place of the phone number. I don't want to lose the system field nor the location field. >So why not create a solution, which does not interfere with actual, widely >used system setups? Because it's ugly and requires a lot of modifications in the software. Using the phone field is much easier. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #468 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 19:21:50 To : Eugene Gladchenko 10 Oct 97 23:57:26 Subj : Re: IP addressing ------------------------------------------------------------------------------- Eugene.Gladchenko@f15.n5061.z2.fidonet.org wrote: >something like ",U,IP:194.65.123.45" or ",U,IP:ufm.prospect.com.ru". Do you >agree that would be compatible with all existent and future fidonet software? No. This way we will run out of space in the flags field. If we do, we could as well use the extended nodelist format. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #469 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 15:15:12 To : Lech Szychowski 10 Oct 97 23:57:26 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >Only as long as there is just one IP address for a Fidonet address. It's like a node with two PSTN lines: it will get another AKA. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #470 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 15:28:54 To : Rune Johansen 10 Oct 97 23:57:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >Of course you (and I) don't want to be forced to use any protocol that is not >already being used by your own system. That is understandable. But, think of I'm not actively using binkd, I don't have a direct connection and I better like email encapsulation. >What terminal software makes it possible for a _person_ to log into a BBS >system that is lying behind a fidonet mailer, via the BinkP protocol? BinkP >is a I can login via telnet into a bbs I run on a linux system I administer. In the PSTN world the front end and the mailer must live chained because there is no way to select the protocol without having different telephone numbers. In the TCP world we have port numbers to select the protocol we want to use. It's a good idea to run a bbs on the telnet port (maybe behind the standard telnet daemon like I do) because this protocol is designed for interactive terminal-like connections. It's a bad idea to force more than one program to use the same port because there is no need to do that. >future expansion and use, to be taken in as minimum common protocol. Telnet >is a protocol that creates a reliable (TCP) session between two hosts. Then >you can A reliable connection is created without any help from the telnet protocol. The telnet protocol is needed just to exchange informations about the type of the terminal used, please read the RFCs, or at least read the manual of a true telnet client (e.g. the unix one). If we just have to exchange arcmail we don't need any of those informations because our connection is binary. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #471 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 19:42:26 To : Rune Johansen 10 Oct 97 23:57:28 Subj : Re: Some comments... ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >not prevent new features! "modem calls to ip-phonenumbers" is crap. If >somebody can't configure his mailer then it's his fault. This can happen even >now with I agree. Do these people advocate special prefixes for ISDN lines too? >If this last thing must be solved then easiest way is to use: >,node,name,location,sysop,phone,flags;phone,flags;phone,flags;... Looks like the extended nodelist proposal... :-) -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #472 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 11 Oct 97 00:36:36 To : Marco d'Itri Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Marco! On 10 Oct 97 wrote Marco d'Itri to Lothar Behet: >> At this moment, there is (as far as i know) no publicly available >> (and used) nodelistcompiler for all mailers, which supports any kind >> of ip-data in the nodelist for any mailer. MI> AFAIK fastlst supports the fqdn-or-ip-in-the-phone-field style. Yes, but not directly from the possible phone contents processed by makenl.. I use it for the vmodem-line, were a normal Binkley XE handles those calls and is fully integrated beside the pstn lines. The translation may be done by a little utility, which creates a private nodelist (at this moment). >> Maybe, that tomorrow we already have an extended nodelistformat, >> which supports any kind of communication access. I would appreciate >> that, but integration of MI> We have one (the extended nodelist format I formalized last month in MI> NET_DEV), but without a "political" backing it will never be widely MI> used. I have read it and on long term a change toward an/that extended format makes sense. But how long will that last? >> So why not create a solution, which does not interfere with actual, >> widely used system setups? MI> Because it's ugly and requires a lot of modifications in the software. MI> Using the phone field is much easier. It works without any interference to existing software and as far as i know, there is no standard (widely used) program, which directly supports phone translation for ip-nodes. It's no problem by itself to extract the required nodelist information from any field, as soon as a standard exists, but the standard should be compatible with all existing software, which is used now (and the next years, too), or at least not disturb the operation of a conventional node. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #473 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 11 Oct 97 00:39:50 To : Marco d'Itri Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Marco! On 10 Oct 97 wrote Marco d'Itri to Lothar Behet: >> 2. the online time must be clearly stated, CM is preferred MI> I think we should assume CM when no time is specified. I would be happy, if that were true. But in fact a missing CM or Txy flag just signals the accessability at ZMH and I see no reason, why ip-capable nodes should be handled exactly the other way round as normal nodes :( Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #474 [1995] Scn From : Ask Bjoern Hansen 2:235/224 10 Oct 97 02:06:34 To : Denis McMahon 11 Oct 97 07:17:36 Subj : IP-access ------------------------------------------------------------------------------- Hello Denis! Saturday October 04 1997 14:10, Denis McMahon wrote to Ask Bjoern Hansen: ABH>> It would be easy to redelegte the administration further down to ABH>> the RC, NC or whoever.. DM> No it would not, the administration would have to be done by whoever DM> maintained the dns at the level concerned. Most NCs, RCs etc have no DM> access to the DNS for z2.fidonet.org. I guess you should read something about how it works. It's very easy to redelegete f.x. n251.z2.fidonet.org to a nameserver controlled by someone in your net. Kind Regards, Ask --- GoldED/2 3.00.Alpha4+ * Origin: OS/2: Taking the wind out of Windows. (2:235/224) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #475 [1995] Scn From : Lawrence Garvin 1:106/6018 09 Oct 97 20:04:46 To : Eugene Gladchenko 11 Oct 97 07:17:36 Subj : IP addressing ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Eugene Gladchenko said in a message to Lawrence Garvin: EG> Hello Lawrence! LG> when I tried placing something like this in my source segment: LG> IP:198*216*61*12 LG> I got a message about "illegal characters" in the telephone field. EG> I think telephone field shouldn't be taken into account. It is EG> *telephone* number field so let it contain only telephone number or EG> "-Unpublished-". And subsequent to that test, and after much consideration, I agree, Eugene. Particularly because even _I_ would like to have both IP and PSTN connectivity available at the same node number, and tampering with the telno field would complicate that issue totally. EG> If there is any reason to place this information into nodelist it EG> should be something like ",U,IP:194.65.123.45" or EG> ",U,IP:ufm.prospect.com.ru". Do you agree that would be compatible EG> with all existent and future fidonet software? The problem is that no software currently exists to extract the IP number from inside of the user flags field -- nor for that matter to convert the actual node number into a formatted FQDN in fidonet.net or fidonet.org Obviously at some point, somebody will have to write a new nodelist -compiler- at a minimum, to take advantage of these new 'features'. After all I've read and thought about over the past couple of hundred messages in this echo, though, I'm inclined to support any, or all, of these concepts: (1) Use of the fidonet node address to construct a FQDN for DNS lookup to either an A record, or CNAME record, with the addition of an appropriate flag to designate availability at the Nodenumber constructed FQDN. (2) Placement of an alternative FQDN in the _NODENAME_ field of the nodelist with an appropriate flag to designate availability at that FQDN. (3) Inclusion of a specific IP address in the _NODENAME_ field of the nodelist with an appropriate flag to designate availability at that IP address. I understand that option (1) does involve the committment and obligation of a DNS zone somewhere, but from the viewpoint of a hostmaster running four zones right now (two in TX.US and two in ORG), it really is a trivial thing to setup a DNZ zone authoritative for a net or region level segment of fidonet.net or fidonet.org Obviously the most volatile issue of the whole plan is insuring the continued maintenance of the SLD itself! --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #476 [1995] Scn From : Chris Maddock 3:640/302 10 Oct 97 23:27:58 To : Rune Johansen 11 Oct 97 07:17:44 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- On 06 Oct at 09:44, Rune Johansen of 2:210/20 wrote to Lothar Behet: [.....] RJ> Wich country have got 00 as international access code _and_ 000 as RJ> emergency number? I doubt that there is any country that has got that. RJ> Australia has got 000 as emergency number. What is their international RJ> access code? The same for england: If their emergency number is 999, then RJ> you can be sure that their international access code is _not_ 99. Australia has an international access code of 00xx where xx depends on the type of call and even =who= the call is going through (Service Provider). i.e. Telstra uses 0011 for Phone, and 0015 for FAX . Optus uses 0011 for phone, and 0019 for FAX (You opt for the default service provider you want to use beforehand) 000 is also the National emergency number. Strange thing is, it works just fine. Regards, Chris Maddock chrism@bbs.st.net.au --- Msged/386 4.20 beta 2 * Origin: Diagnostic CBBS - DownUnder - (3:640/302) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #477 [1995] Scn From : Jesper Tragardh 2:200/108.21 06 Feb 06 06:28:15 To : Rune Johansen 11 Oct 97 19:19:30 Subj : IP-access ------------------------------------------------------------------------------- RJ> If I "telnet port", I expect a telnet handshake from the port RJ> I connect to. If I don't get a telnet handshake, I cannot use the RJ> telnet client program to connect to the port on the host. If the In that case most executables named "telnet", except yours, can use raw sockets. I can telnet to port 110 on my pop3-server to check my mail for instance... /Jesper --- timEd/386 1.10 * Origin: Pinga varandra i IP-trafiken /JL (2:200/108.21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #478 [1995] Scn From : Kim Heino 2:222/0 06 Feb 06 06:28:15 To : Rune Johansen 11 Oct 97 19:19:30 Subj : Some comments... ------------------------------------------------------------------------------- > and new makenl. Old softwares may not prevent new features! Software called nlmake can handle ip's/fqdn's in phone-field and it's even config-file compatible with makenl. Next fastlist (or whatever it was...) should also support them. So the software should not be a problem. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #479 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Feb 06 06:28:15 To : Amir Shabashvili 11 Oct 97 19:19:30 Subj : IP-connectivity ------------------------------------------------------------------------------- > mg> binkd cannot be treated as a standard, as it's compatible only with > mg> itself. > it's compatible with bink-style outbound, and that's enought Enough? Mayby for the local (ie limited to local disk/filesystem) compatibility this is really enough. But what about connectivity? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #480 [1995] Scn From : maciej grzeszczuk 2:480/70 06 Feb 06 06:28:15 To : Eugene Gladchenko 11 Oct 97 19:19:30 Subj : Re: BinkD (Was: IP-connectivity) ------------------------------------------------------------------------------- From: maciej grzeszczuk Wed, 08 Oct 97 08:12:21 +0200 Eugene Gladchenko napisal byl w fido.ip_connect: > Don't be so categorical. First, binkd is not the only one *fidonet* mailer > supporting binkp protocol already. oh, yeah. there are two of them. > Second, even if it was, it just would be the > first one. It happens to all new things, agree? Everyone is given all the sure. but we want to set something like fts-0001 for tcp connections. not every node have to use emsi, remember. as well as not every node will have to use binkd. but you _can_ use it, if you want to. > is an example. Third, it is not really compatible only with itself. It uses > the same binkley-style outbound as other *fidonet* mailers do. It does it so you can easily set up a vmodem mailer, also using the same binkley-style outbound. and you should do this, as there will be no way to reach you via vmodem system. i don't care what your outbound format is. i only want to make successful connections with your server. your outbound format is only your bussines. > Did you ever see binkd? If not please take a look. You will sure like it. > It's so simple to use and very powerful all the same time. i did. i prefer to use ifcico though. as it's compatible with everything. and binkd isn't. maybe binkd is powerfull, but it's useless, whenever you want to connect to a typical yet ip node. 490 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: i server cie wyrucha, takim wielkim czlonem gumow (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #481 [1995] Scn From : maciej grzeszczuk 2:480/70 06 Feb 06 06:28:15 To : Denis McMahon 11 Oct 97 19:19:30 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 07 Oct 97 22:21:48 +0200 Denis McMahon napisal byl w fido.ip_connect: > Vmodem > Telnet that's the same protocol. > BinkP > BinkD what are the differences between the last two? > IFCICO > FTP > UUCP > SMTP/UUEnc > SMTP/Base64 i disagree. we shouldn't treat ftp or other internet services as a valid fidonet transport. 491 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: jak bede miala dziecko, oddam je do aborcji... (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #482 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Feb 06 06:28:15 To : Lawrence Garvin 11 Oct 97 19:19:30 Subj : IP-access ------------------------------------------------------------------------------- > LS> possible solution. Although I have to admit that I don't remember > LS> what RFCs say about minimal TTL (if this issue is dealt with at all). > Minimum TTL is recommended to be at least one hour. Is it a recommendation or a requirement? I can see very well why such a recommendation is given (for the very same reasons we have mentioned as disadvantages when talking about dynamic DNS), but if it is just a recommendation... :) > In fact, some hostmasters who are implementing automated zone checkers, > will reject any domain-request where the DNS server has less than a one > hour TTL configured. Although that would seem offensive and illegal, we have to keep it mind when trying to find a working solution. > Keep in mind, also, that depending on the number of requests serviced by > your servers, the shorter the TTL, the more time your system will spend > answering DNS requests, instead of sending true service packets. I know that. That's the reason why I think delegating regional/netional subdomains is a must. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #483 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Feb 06 06:28:15 To : Lawrence Garvin 11 Oct 97 19:19:30 Subj : IP-access ------------------------------------------------------------------------------- > LS> problem can be partially solved by creating more DDNS servers > LS> servicing a smaller number of nodes; > Definitely! Although I suspect you meant more DNS servers, not more > DDNS servers. No? If we are to have "FQDN -> dynamically assigned IP" database that really works, all regional/netional DNS servers will have to be DDNS servers as well. At least I fail to see another solution. > LS> regional/netional subdomains of Z2 seem to be a natural/obvious > LS> choice. > Or any other zone as well. :) Absolutely. I think when I wrote it we had no participants from outside Z2 here, but now things have - fortunately - changed :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #484 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Feb 06 06:28:15 To : Lawrence Garvin 11 Oct 97 19:19:30 Subj : IP-connectivity ------------------------------------------------------------------------------- > Therefore, I support the concept that only full-time, permanently > connected, IP-dialable nodes are at issue for nodelist inclusion. If we are to consider IP-only nodes as something that should be realtively rare and used mainly for the purpose of making long distance bulk quantities mail transfers, I second your opinion. But more flexibility wouldn't hurt, and having something like ZMH (actually not necessarily common, one given with T flags in the nodelist entry would do) would IMHO be OK. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #485 [1995] Scn From : Jesper Tragardh 2:200/108.21 06 Feb 06 06:28:15 To : alla 11 Oct 97 19:19:30 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- * Quoting a message from Rune Johansen * RJ> What terminal software makes it possible for a _person_ to log into RJ> a BBS system that is lying behind a fidonet mailer, via the BinkP RJ> protocol? This is the "Fido" way to do things. Of course it's a valid way when using direct modem connections as you only have one communication channel. The TCP/IP way is to let each service answer on it's own port. Hence you are not restricted to one channel. The Fido way is to talk to one party at a time. With TCP/IP you can talk to several. E.g: I can open two ftp-connections, either to the same host or to two different. The ports in TCP/IP makes all adresses 2D (machine:port) while Fidoadresses are 1D (node number <-> PSTN number). Actually the TCP/IP way is a good way to do things when a 2D adress can be used. The implementor of a mailer does not need to concern himself with the concept of BBS-users and the other way around. Protection of common files etc is left to the operating system. BBS-users is not an argument for making FTS-0001 connections over Telnet. If mailers and users are to connect over the telnet port, the telnetd on the machine must be more advanced (especially if it's going to manage regular telnet connections as well). Using the telnet protocol on a different port is, imho, meaningless. Programs communicating over TCP should treat TCP as an error-free stream. I.e anything you send to TCP will come out in the other end in correct order and error free. Putting a protocol on top of this (telnet) and then another protocol (FTS-0001, EMSI etc) is redundant. Binkp is a handshaking protocol which uses the error-free TCP as a data carrier. There is no need for checksums etc. The only argument for making FTS-0001 connects over the telnet port is that some people might be sitting behind a firewall blocking everythin but the telnet, ftp and www ports. The telnetd on the remote machine must then be modified to watch for some escape-sequence to put it in "Fido-mode". If Fido is going to use TCP (we're are not going to use IP directly - because then we will have to hack our TCP/IP stacks) as an alternative to PSTN - then we should do things the internet way. Trying to redefine for instance the telnet protocol is not merely a waste of time. It's also counter-productive. If s.b were to let his 24h online TCP/IP machine offer Fido-service, he probably wouldn't be interested in a new telnetd. He would want a Fidod (using binkp or what ever) to answer on a specific port. Any programs using raw sockets and some handskaking protocol will be more efficient than a PSTN-mailer using Vmodem. However, I don't think FD and BT is going to be directly IP-aware in the near future and probably the only way to make them use IP instead of PSTN is IP-numbers in the PSTN-number field and Vmodem-solutions. IMHO the general "Fido over IP" solution should be totally IP-aware mailers (e.g argus and binkd) and use of DNS. Shipping around a lot of IP-numbers seems to be the hard way to do things. The solution of using CNAMEs in the fidonet.net DNS also solves the problem of dynamiclly changing IPs (DHCP or some dial-ups). The nodelist then reduces to a member list and for PTSN systems. This leaves us with the vmodem systems. How should they get correct numbers for their ATDT calls which vmodem picks up? Shifting out the old MakeNL and turning the St. Louis nodelist upside down is not possible. Making all nodes switch (or some elaborato "start with the exchange between ZCs") will probably fail as Fido hasn't been a technically dynamic structure to this day. IMHO the best way is to make a new nodelist format with flags specifying connect capabilities (IP, X.25, PSTN, ISDN). Each system recognizes what systems it can connect to and routes the rest of the mail over defined g/ws. Translation of nodenumbers to a valid adress (IP, PSTN-number, X.25) is left to the best way of each technique (DNS for IP, short format Fido-id, PSTN-number list for that one). Users of old mailers operating over Vmodem then just replace their nodelist compilers. The old nodelist will probably still be distributed to those in need using MakeNL to compile it with not PSTN-systems listed as Pvt and -unpublished-. /Jesper --- timEd/386 1.10 * Origin: Pinga varandra i IP-trafiken /JL (2:200/108.21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #486 [1995] Scn From : maciej grzeszczuk 2:480/70 06 Feb 06 06:28:15 To : Igor Bilyi 11 Oct 97 19:19:30 Subj : Re: binkd vs vmodem ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 07 Oct 97 09:50:58 +0200 Igor Bilyi napisal byl w fido.ip_connect: > mg> vmodem is supported on all software / hardware platforms. > floppynet is supported on all software / hardware platforms. with such argumentation we'll go nowhere. you act like a 10 years old kid. > vmodem is 2-3x slower than binkd, want to try? i'm ready if you can connect with your binkd to my vmodem / ifcico / telnet compatible mailers (listening on ports 60177 and 60179 of zwieracz.psych.uw.edu.pl)... 492 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: jestem niezly. ILUVATOR. (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #487 [1995] Scn From : Slava Filimonov 2:469/33 06 Feb 06 06:28:15 To : Lech Szychowski 11 Oct 97 19:19:32 Subj : binkd vs vmodem ------------------------------------------------------------------------------- Hello Lech! 09 Oct 97 03:46, Lech Szychowski wrote to Igor Bilyi: >> vmodem is 2-3x slower than binkd, want to try? i'm ready LS> In negotations or transfers? both. -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #488 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Feb 06 06:28:15 To : Marco d'Itri 11 Oct 97 19:19:32 Subj : IP-connectivity ------------------------------------------------------------------------------- > I agree that email incapsulation should be used only in special cases: [...] > ie: communications between a node that is not online 24h and another node. Suppose we adopt the idea of declaring online hours in nodelist ("T" flag) or in DNS records ("TXT" type). Is email encapsulation still necessaty then? My personal worries are SMTP encapsulation might give us more trouble than fun... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #489 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Feb 06 06:28:15 To : Marco d'Itri 11 Oct 97 19:19:32 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > IMHO this is a very important point. We should not accept as standard > any solution that is not 100% free. Certainly. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #490 [1995] Rcv Scn From : Lech Szychowski 2:480/33.7 06 Feb 06 06:28:14 To : Lothar Behet 11 Oct 97 19:19:32 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- > The following should be met for an ip-capable entry in the nodelist: >>-8------------------------ byte here ------------------------8-< > 1. IP may be listed only as additional media type to normal pstn > connections Then no IP-only nodes? Personally I like this idea, but at the same time I see there is a "common understanding" such nodes should be allowed. What about listing them as Pvt? I know it violates rules a bit, but solves compatibility problems; probably this solution is as good and as bad as putting -Unpublished- in the phone filed... > 3. there must at least be one FTS-conformant protocol on this line If the system is to qualify for a Fidonet node (PSTN aka traditional one; I think that was your idea behind 1. above) there is no need to add this requirement. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #491 [1995] Scn From : Sean Rima 2:252/356 06 Feb 06 06:28:15 To : Lech Szychowski 11 Oct 97 19:19:32 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hi Lech, On Stardate <9710.09>, you wrote me: >> I could not have a Telnet mailer operating on port 23 as I have to >> telnet into my shell account to read some mail. Also to start and >> stop both the mailer and tosser from time to time. LS> Reconfigure your system to launch telnet server (for mailer or for LS> human logins, whichever you like more) on some other port. Yes this could be done. So there could be Telnet Ipmailers running on ports 23, 35, 101 23400 ..... Not very user friendly. The standard must say that a protocol must run on a particular port allowing for the fact that some people's Ipmailers will be run on shell accounts provided by an ISP and not a direct connection. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: Just 'cause it won't work; YOU think its buggy (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #492 [1995] Scn From : Slava Filimonov 2:421/45.33 06 Feb 06 06:28:15 To : Vilo Mlich 11 Oct 97 19:19:32 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Vilo! 09 Oct 97 18:59, Vilo Mlich wrote to Slava Filimonov: WD>>> The core of Fidonet is the nodelist, think twice about that. SF>> The _real_ core of Fidonet still public phone line. Nodelist is SF>> just phone directory like yellow pages in each phonebox. Guess SF>> what is the core of internet , and then think twice about that. VM> Nodelist is not phonebook only: Okay, phonebook with other stuff included. VM> - some nodes with LO flag allow session only with listed systems VM> - nodelist content geographical and routing structure VM> zone/region/network/hub VM> - message editor need nodelist, too. Write netmail to node, which is VM> not in nodelist, is more complicated. As i said, IP node can have _only_IP_ flag without actual ip address - everything else(for IP nodes!) should be obtained from DNS. Using DNS does not mean, that we'll exclude IP nodes to new region/net/list etc... Non-IP mailer can call this node by phone ( if one exist ) or not call at all - in case PVT/unpublished flag - route mail for node hub or to /0 IP-address is unusful fot non-ip mailer. we don't need it. IP-mailer can try to find this node in DNS in form p*.f*.n*.z*.fidonet.net and nodelist is not nesessary in this case, cause we'll obtain node info from DNS. Otherwise, if node not in DNS, ip-mailer can try /0 from DNS or send it by default route. And mail freely can go from ip-node to non-ip and vs. No problems and no complications. VM> The real core of the fidonet is the nodelist. IP-nodes should be in VM> normal nodelist and should have normal addresses, not some 'zone 7'. -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:421/45.33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #493 [1995] Scn From : Slava Filimonov 2:469/33 06 Feb 06 06:28:15 To : maciej grzeszczuk 11 Oct 97 19:19:32 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hello maciej! 08 Oct 97 22:44, maciej grzeszczuk wrote to Sean Rima: mg> i said that we should specify one standard, available at every ip-node mg> system. and i proposed vmodem. mg> i don't say that we shouldn't include binkd nodes in a nodelist, but mg> they should also support vmodem connections - some kind of fst-0001 mg> for ip-nodes. We can't set vmodem as a standart protocol for ip session, cause it's based on non-free software. We should use binkd as a standart, which is free and protocol spec is avail, and vmodem as option. -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #494 [1995] Scn From : Slava Filimonov 2:469/33 06 Feb 06 06:28:15 To : maciej grzeszczuk 11 Oct 97 19:19:32 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello maciej! 08 Oct 97 22:47, maciej grzeszczuk wrote to Victor Prylipko: >> At this point you are wrong. binkd is compartible with Argus. mg> oh yeah. and vmodem is compatible with any mailer, as it's tunneled mg> standard session. But binkp support by other mailers is just question of time. The main reason, why we developing this binkp is that vmodem is not as good as it seems to be for fido over ip. Otherwise this arguing won't be exists. -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #495 [1995] Scn From : Slava Filimonov 2:469/33 06 Feb 06 06:28:15 To : Lech Szychowski 11 Oct 97 19:19:32 Subj : IP-access ------------------------------------------------------------------------------- Hello Lech! 09 Oct 97 03:45, Lech Szychowski wrote to Slava Filimonov: >> So let try binkp protocol to proove its simplicity and reliability. >> btw, and why do they start to use HTTP protocol, if UUCP were so >> good ? LS> In short: UUCP is in some respects too/unnecessarily complicated, LS> in some others too/unnecessarily powerful. LS> But I'm afraid this question is well beyond the scope of this echo... That's what i thought - UUCP is too/unnecessarily complicated for fido. -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #496 [1995] Scn From : Lech Szychowski 2:480/33.7 06 Feb 06 06:28:15 To : Pedro Lima 11 Oct 97 19:19:32 Subj : IP-access ------------------------------------------------------------------------------- > Actually, neither. I was saying that the delegation only makes sense in > the fidonet.org domain (sorry for having included the z2), because > other FQDNs may also be nodelisted. I see your point. Do you think we can try to work on a solution based upon a concept of "fXX.nYY.zZ constructed from FTN address, the rest of the FQDN either default (ie .fidonet.org) or explicitely listed in some flags field entry"? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #497 [1995] Scn From : Timur Hi-Rullin 2:5049/49 06 Feb 06 06:28:15 To : Lech Szychowski 11 Oct 97 19:19:32 Subj : IP-access ------------------------------------------------------------------------------- Hi Lech 09/10/97 *Lech Szychowski* wrote to *Fyodor Ustinov* about *IP-access*: >> BTW. Any node supported binkp protocol can be published in fidonet.net >> domain. LS> Now that's something I don't like. Another domain? What for? IMHO all LS> it will bring would be some mess and misunderstangings. What we need LS> is not a new domain - it is a common platform, a solution acceptable LS> for (more or less) everyone from both technical and practical point LS> of view. It's only one of some ways to put (or not :) a ip-address info into nodelist. For example, a ip-node have only ip-flag in the nodelist, not ip-address. It means that node have a ip-address 192.168.100.200, names fido-node.company.com and can be resolved as f49.n5049.z2.fidonet.net too. Therefore, there's no need to put _any_ ip-address to nodelist. Isn't it like good? LS> Leszek. . /t[mson --- mailto:tim@zarech.tatincom.ru * Origin: Warning - this message is Read Only (2:5049/49) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #498 [1995] Scn From : Amir Shabashvili 2:5049/12 06 Feb 06 06:28:15 To : Lech Szychowski 11 Oct 97 19:19:32 Subj : IP-access ------------------------------------------------------------------------------- Hello Lech! Replying to a message from Lech Szychowski to Fyodor Ustinov: >> BTW. Any node supported binkp protocol can be published in fidonet.net >> domain. LS> Now that's something I don't like. Another domain? What for? For testing all things (like DNS-nodelist resolving) we discuss in SU.IP.SYSOP echo last 6 month. For free operating, delegating DNS-mastering and so on. Where's a problem? LS> IMHO all LS> it will bring would be some mess and misunderstangings. What we need LS> is not a new domain - it is a common platform, a solution acceptable LS> for (more or less) everyone from both technical and practical point LS> of view. And we need something like fidonet.net as DNS-decision for IP nodes, with delegating DNS managing for every net to NC's or persons they point to. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #499 [1995] Scn From : Igor Bilyi 2:421/450 06 Feb 06 06:28:15 To : Lech Szychowski 11 Oct 97 19:19:32 Subj : Re: binkd vs vmodem ------------------------------------------------------------------------------- Hi Lech ! >> vmodem is 2-3x slower than binkd, want to try? i'm ready LS> In negotations or transfers? in trabsfers, 100 MB on 28.8 lines with > 2800 cps, try todo this with vmodem LS> Leszek. -i- --- FMail/2 1.22 * Origin: * IP NODE * (2:421/450) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #500 [1995] Scn From : Amir Shabashvili 2:5049/12 06 Feb 06 06:28:15 To : Lech Szychowski 11 Oct 97 19:19:32 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Lech! Replying to a message from Lech Szychowski to Amir Shabashvili: >> if you've online IP - because don't need any fido mailer stuff - modem/ >> protocol/timeouts/_thousand_any_other_stuff *emulation*. Than, binkd >> is LS> Unless you happen to have a bad link - either between you and your ISP LS> or somewhere in the routing path. And such a situation is not an LS> imaginary one, believe me. ? It is usial thing in our country, but in that case binkd as add-on mail daemon is more better then vmodem - espetially for slow/bad links. Besides - the last compiled version of binkd I use is 67 kb long, but previous was better - 38 kb :)(emx versions for OS/2). Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #501 [1995] Scn From : Amir Shabashvili 2:5049/12 06 Feb 06 06:28:15 To : Lech Szychowski 11 Oct 97 19:19:32 Subj : IP-connectivity ------------------------------------------------------------------------------- Hello Lech! Replying to a message from Lech Szychowski to Amir Shabashvili: >> it for fido-over-ip, in DNS-like manner. Only thing we discuss now is >> where in DNS record we'll store info about fido-related stuff. LS> There is TXT record type available. Yes, we planning to use TXT record. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #502 [1995] Scn From : Sean Rima 2:252/356 06 Feb 06 06:28:15 To : Amir Shabashvili 11 Oct 97 19:19:32 Subj : IP-access ------------------------------------------------------------------------------- Hi Amir, On Stardate <9710.08>, you wrote me: AS> Hello Sean! AS> ŽG¢¥t n ­  ¯¨á8¬® Sean Rima ª Fyodor Ustinov: SR>> I tried to do an DNS on fidonet.net but it doesn't appear to SR>> have any of the BinkD mailers listed yet. >>telnet f64.n5049.z2.fidonet.net 24554 AS> SYS Flying_Dragon_Soft ZYZ Alex_Bakhtin AS> LOC Kazan,_Russia NDL 64000,TCP,BND,NOSMTPTIME 1997/10/08 Great, I will try it on my next connect to the net. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: Kids wanna rock (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #503 [1995] Scn From : Sean Rima 2:252/356 06 Feb 06 06:28:15 To : Maciej Grzeszczuk 11 Oct 97 19:19:32 Subj : Re: BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hi maciej, On Stardate <9710.08>, you wrote me: mg> From: maciej grzeszczuk mg> Mon, 06 Oct 97 18:10:56 +0200 Sean Rima napisal byl w mg> fido.ip_connect: >> Maciej Grzeszczuk (Got it wrong???) did a couple of days ago. I >> think I should mg> i said that we should specify one standard, available at every mg> ip-node system. and i proposed vmodem. mg> i don't say that we shouldn't include binkd nodes in a nodelist, but mg> they should also support vmodem connections - some kind of fst-0001 mg> for ip-nodes. What you originally said that BinkD was not supported by anything else other than itself and should not be used as a standard. Why used Telephone based protocols over the Net. It is like having a Porsche with the engine from a Robin Reliant. Most telephone based protocols would not handle the weirdness of the net. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: Do I have to say the words? (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #504 [1995] Scn From : Sean Rima 2:252/356 06 Feb 06 06:28:15 To : Lech Szychowski 11 Oct 97 19:19:32 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hi Lech, On Stardate <9710.09>, you wrote me: >> program but Binkp/1.0 the protocol, which is now in Argus for >> normal Teleco calls and is around 50% faster handshaking tham >> EMSI. LS> How big the session negotiation/handshake overhead in everyday LS> IP connections? And how much smaller we can make it by using LS> BinkP? An average EMSI connection of the Net takes me around 3-5 seconds. An average BinkP is .5 - 1 second. And that is extensive use. My Ipmailer handles (In Arc mail) 3-5 megs per day, maybe more. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: Well! I'm impressed. (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #505 [1995] Scn From : Sean Rima 2:252/356 06 Feb 06 06:28:15 To : Lech Szychowski 11 Oct 97 19:19:32 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hi Lech, On Stardate <9710.09>, you wrote me: >> So do I. But ruling out a protocol that is in daily use by over >> 100 Ipmailers seems the wrong way to go. LS> This is a double-edged sword. There might be a comparable number LS> of nodes using some other protocol - and what then? :) I have not seen a nodelist for people using any other Ipmailer than BinkP protocol based mailers. So I cannot comment. But yes it is a double edged sword. And thank fully this echo and the discussions now taking place may sort this out. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: ((((( In Stereo Where Available ))))) (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #506 [1995] Rcv Scn From : Mario Mure' 2:335/533 06 Feb 06 06:28:14 To : Lothar Behet 11 Oct 97 19:19:32 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- In a message dated < 08 Oct 97 23:09:56 >, addressed to All about < Proposal for listing as IP-node >, Lothar Behet wrote: LB> 1. IP may be listed only as additional media type to normal pstn LB> connections LB> Explanation: LB> LB> 1. is self-explanatory: LB> There are no IP-only nodes in the nodelist. WHY ??? IMHO, it's a very short-sighted solution. LB> Please correct me, if i have overseen something important, but i hope, LB> that these basics will be honored, before ip-nodes will be listed beside LB> the few test-nodes. BTW, there's at least an IP-only node between test nodes: 2:2/3008. Ciao ! /mario/ mure@sistemia.it --- DMreply v2.0 * Origin: Stay cool if your hard disk say goodbye (2:335/533@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #507 [1995] Rcv Scn From : Frank Ellermann 2:240/5815.1 06 Feb 06 06:28:14 To : Lothar Behet 11 Oct 97 19:19:34 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hi Lothar, LB> 1. IP may be listed only as additional media type to normal pstn LB> connections [...] LB> Please correct me, if i have overseen something important, but i LB> hope, that these basics will be honored [...] Actually I don't agree with your 1st rule, how about this formula: > 1. IP only nodes may be listed only in a region (or nets) reserved > for this purpose. Greets, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #508 [1995] Scn From : Pedro Lima 2:362/21 06 Feb 06 06:28:15 To : Marco d'Itri 11 Oct 97 19:19:34 Subj : A bit of steering ... ------------------------------------------------------------------------------- Md> IPng addresses are different enough to be machine recognisable. Ok, then a single IP flag should be enough. :-) Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #509 [1995] Rcv Scn From : Sebastian Stein 2:2410/299.27 06 Feb 06 06:28:14 To : Lothar Behet 11 Oct 97 19:19:34 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Lothar Behet wrote in a message to All: Hello Lothar, LB> 1. IP may be listed only as additional media type to normal pstn LB> connections It's okay, because of conflicts with the actual policy. But later we should also accept Ip-only nodes because even today we have the tendence that the different networks grow together, e.g. telephone over internet etc. In the future IMHO there will be only one transport network with different logical channels for voice, data, tv, radio, video. LB> 2. As reachability at ZMH is a basic condition for a node, this LB> should be honored (and checked), before listing an ip entry in LB> the nodelist. But I think that we should have a different ZMH for IP-Access and normal telephone calls, because during the ZMH the mailer can wait for phone calls and during the IP-ZMH the node can then connect to his ISP. It's a cheaper way for becoming a node with ip-capabilities, because only one PSTN is needed. LB> 3. As FTS-001 is another basic condition for listing as node, LB> at least one protocol must be capable for a direct mailer to LB> mailer session. This would exclude BinkP-only-Nodes, am I right ? Bye, Sebastian --- timEd/2 1.10 * Origin: Fitze, Fitze, Fatze..... Fitze, Fitze, Fatz (2:2410/299.27) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #510 [1995] Scn From : Frank Ellermann 2:240/5815.1 06 Feb 06 06:28:15 To : Max Masyutin 11 Oct 97 19:19:34 Subj : The Real FidoNet Physical Layer (JFYI) ------------------------------------------------------------------------------- > H. Physical Layer : the Actual Connection of Two FidoNet Systems > Will one of the more hardware-oriented comm types give me some > idea of what's needed here? Can we leave it open enough to allow > implementation over a non-dial net? Thanks. ... :-) Tnx for this quote, bye, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #511 [1995] Scn From : Sean Rima 2:252/356 06 Feb 06 06:28:15 To : Lech Szychowski 11 Oct 97 19:19:34 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hi Lech, On Stardate <9710.09>, you wrote me: >>> allowed, but not as only protocol that ip node supports. >> Okay, but the protocol is BinkP LS> So it looks like we are about to say the lowest common capability LS> is BinkP plus... EMSI over vmodem/telnet/raw? And also the overhead that EMSI will have on the net. I know I have used it. EMSI disappeared after 3 days. Far too slow for the Net. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: Just My Opinion (But I'm ALWAYS Right!) (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #512 [1995] Scn From : Sebastian Stein 2:2410/299.27 06 Feb 06 06:28:15 To : maciej grzeszczuk 11 Oct 97 19:19:34 Subj : vmodem ------------------------------------------------------------------------------- maciej grzeszczuk wrote in a message to Victor Prylipko: Hello maciej, > At this point you are wrong. binkd is compartible with Argus. mg> oh yeah. and vmodem is compatible with any mailer, as it's tunneled mg> standard session. But AFAIK vmodem (port 3141 ?) is only available on os/2-maschines as a part of the sio communication package by Ray Gwinn: In addition to acting as a Telnet server, Vmodem uses a newly designed protocol for communications networks, called the Virtual Modem > Protocol (VMP). At this time, no other programs have implemented VMP, > thus Vmodem is required on both ends of the connection to use the VMP. However, VMODEM.EXE will accept inbound Telnet connections from any system, meaning a BBS under vmodem can be accessed by just about anyone with an Internet connection. Maybe do you mean telnet by saying vmodem, because the VMP isn't free? Every mailer can connect to each other, but only on the os/2-platform ! Correct me, if I am wrong ! My english isn't the best, maybe I misunderstood you ? Bye, Sebastian --- timEd/2 1.10 * Origin: Fitze, Fitze, Fatze..... Fitze, Fitze, Fatz (2:2410/299.27) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #513 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 11 Oct 97 19:45:00 To : Frank Ellermann Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Frank! On 06 Feb 06 wrote Frank Ellermann to Lothar Behet: LB>> 1. IP may be listed only as additional media type to normal pstn LB>> connections FE> [...] LB>> Please correct me, if i have overseen something important, but i LB>> hope, that these basics will be honored [...] FE> Actually I don't agree with your 1st rule, how about this formula: >> 1. IP only nodes may be listed only in a region (or nets) reserved >> for this purpose. And at least one seperate address for each IP# and protocol-combination :( No, thanks, i do not want to collect an infinite number of akas. Question: Is the internet as medium organized like a regional net? Yes, it surely is, (mostly) located at earth.sun.our_galaxy ... As you still accept them as a part of nodelist, how large should this list grow? Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #514 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 11 Oct 97 20:20:48 To : Lech Szychowski Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Lech! On 06 Feb 06 wrote Lech Szychowski to Lothar Behet: >> 1. IP may be listed only as additional media type to normal pstn >> connections LS> Then no IP-only nodes? Personally I like this idea, but at the same LS> time I see there is a "common understanding" such nodes should be LS> allowed. What about listing them as Pvt? The nodediff is transported world wide, a large part of its members (about 30.000 at this moment) still have analogue (pstn) access, which furthermore nust not be in the cheapest range. Lets estimate, that there are about 70.000 - 120.000 points worldwide, then it's 100.000 to 150.000 people who have to pay for it. Most of these members and users of fidonet operate their systems at home on their private computer, which normally will not be a "state of the art" box with infinite memory (RAM and disk) and computing power. I think, you would loose many of these, if the nodelist grows to, lets estimate, 250.000 nodes within a year or two. My first intention is therefore to keep the nodelist small through using combined entries. Therefore it is sufficent, that the routing systems (even a node with points is a routing system) are listed in it. But they ought to be online at defined timeslots (CM being the best for downlink accessebility). To participate in the communication via fidonet a pointaddress is enough. LS> I know it violates rules a bit, but solves compatibility problems; LS> probably this solution is as good and as bad as putting -Unpublished- LS> in the phone filed... Pvt-entries are only allowed, where routing definitely requires it. You may create a kind of "internet user list" anywhere else, but do not misuse the nodelist for it. >> 3. there must at least be one FTS-conformant protocol on this line LS> If the system is to qualify for a Fidonet node (PSTN aka traditional LS> one; I think that was your idea behind 1. above) there is no need to LS> add this requirement. Yes, it is another brake before the nodelist explodes by putting every silly entry into it. Because without direct session, you may use email-based protocols as medium. Then the data is buffered elsewhere (ie. my secondary MX may reside in Japan, while my locattion is in Germany), but normally that system is not operated by a fido sysop. And who is then responsible for the routed mail (including security)? You have to change the policy in many parts, before that would be acceptable. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #515 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 11 Oct 97 21:09:12 To : Mario Mure' Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Mario! On 06 Feb 06 wrote Mario Mure' to Lothar Behet: LB>> 1. is self-explanatory: LB>> There are no IP-only nodes in the nodelist. MM> WHY ??? IMHO, it's a very short-sighted solution. Wherefore do you really need ip-only nodes in the nodelist? They can participate as point in the same discussions. LB>> Please correct me, if i have overseen something important, but i LB>> hope, that these basics will be honored, before ip-nodes will be LB>> listed beside the few test-nodes. MM> BTW, there's at least an IP-only node between test nodes: 2:2/3008. That was not my action and therefore i can disagree with that now and not at a later time :) I recommend, that it will disappear after the test period. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #516 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 11 Oct 97 21:42:26 To : Sebastian Stein Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Sebastian! On 06 Feb 06 wrote Sebastian Stein to Lothar Behet: LB>> 3. As FTS-001 is another basic condition for listing as node, LB>> at least one protocol must be capable for a direct mailer to LB>> mailer session. SS> This would exclude BinkP-only-Nodes, am I right ? Give me a chance for a slightly different formulation: At least one protocol has to be a direct mailer to mailer session, equivalent as FTS-001 defines for direct pstn operation, which uses the fido address and optional passwords for authentication. There might come other protocols beside the existant, which may be used in the future. It is not my intention to define just one protocol as fido-conformant or exclude others for fido operation. Okay? Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #517 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 19:17:50 To : maciej grzeszczuk 11 Oct 97 22:07:40 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- krap@zwieracz.psych.uw.edu.pl wrote: >> Vmodem >> Telnet >that's the same protocol. It's not. The vmodem protocol is a different thing from an FTS-1 session carried over telnet. >> BinkP >> BinkD >what are the differences between the last two? binkp is the protocol, binkd is just a program supporting it. >i disagree. we shouldn't treat ftp or other internet services as a valid >fidonet transport. They move arcmail between nodes. I think this is enough. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #518 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 23:37:40 To : Slava Filimonov 11 Oct 97 22:07:40 Subj : Re: IP-access ------------------------------------------------------------------------------- Slava.Filimonov@f33.n469.z2.fidonet.org wrote: > MI> If we have to radically change the nodelist we could use the extended > MI> nodelist proposal, it address this problem even better. >...And why not to give up with nodelist for ip completely ? Instead put Because we would have to modify not just the nodelist compiler, but the mailer and the vmodem-like driver too. A DNS based solution can't work with current software. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #519 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 19:04:34 To : Lech Szychowski 11 Oct 97 22:07:40 Subj : Re: IP-access ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >If we are to have "FQDN -> dynamically assigned IP" database that >really works, all regional/netional DNS servers will have to be >DDNS servers as well. At least I fail to see another solution. We can use CNAME RRs. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #520 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Oct 97 19:07:56 To : Lech Szychowski 11 Oct 97 22:07:40 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >Suppose we adopt the idea of declaring online hours in nodelist ("T" flag) >or in DNS records ("TXT" type). Is email encapsulation still necessaty then? Those two things are not related in any way. >My personal worries are SMTP encapsulation might give us more trouble than >fun... Then don't use it. I use email (*NOT* "smtp") encapsulation and I'm happy about how it works. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #521 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 12 Oct 97 10:15:00 To : Mario Mure' Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Mario! On 06 Feb 06 wrote Mario Mure' to Lothar Behet: LB>> There are no IP-only nodes in the nodelist. MM> WHY ??? IMHO, it's a very short-sighted solution. MM> BTW, there's at least an IP-only node between test nodes: 2:2/3008. So you are telling us, that the other entries with the same name are fake entries? :) Or just another person? Regards, Lothar PS: Each entry 2:2/3* is at this moment IP-only at its own, but i could find a correspondant sysop name with "normal" lines to each of them in nodelist.283. --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #522 [1995] Scn From : Dieter Ringhofer 2:2476/14 12 Oct 97 10:02:04 To : Lech Szychowski, All 12 Oct 97 18:05:20 Subj : IP-connectivity ------------------------------------------------------------------------------- Lech Szychowski wrote to Marco d'Itri: >> I agree that email incapsulation should be used only in special cases: LS> [...] >> ie: communications between a node that is not online 24h and another node. LS> Suppose we adopt the idea of declaring online hours in nodelist ("T" flag) T-Flags impose another problem and are unusable in real practice: How do you want to get them working all around the world?? Situation is very annoying for having different 'standards': In many countries LAW (!!) related to representation of local time say that everything west of Greenwhich has to mark the offset with a plus sign, east of it with minus since more than 20 years (see air traffic control, navigation, ...). Example Germany: Correct localtime is UTC-1 or, with active daylight saving, UTC-2. Now, have a look at existing implementations (especially the ones developed in countries influenced by 'America', even when gouvernement of U.S.A., Canada, etc agreed to international Law of Time long time ago!): Many of them want to have the offset marked the opposit way. They still use already obsolete shortcuts like GMT or EST and, to make things much more worse, some of the products use EST instead of UTC as base for calculations! :(( My conclusion: Simply forget all except ZMH because it won't work in reality of an international network, even 'national' usage offers no warranty for correct behaviour. ZMH is already defined in localtime with fixed hours and minutes for all continents (read: major timezones) so we don't have any problem with it. Therefore we don't need something else in upcoming definitions and encapsulation must be done on IP's side for IP systems not being connectable. But: It can't be the task of any FTN standard to define behaviour of such IP related problems. The solution must be found where the problem exists to stay compliant with eventually changing standards there. btw: There has been the proposal about the well known problem of timezones somewhere in Usenet some years ago to use only localtime but, it leads to another problem (some FTN software like GMD or NoBogus is affected as well and limited in usability for this): Mails written in 'local future' may not be accepted for having 'invalid' time- and/or datestamps. Such behaviour can be an explanation for loss of mails in Usenet (some get lost in reality) when processing software checks without enough tolerance. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #523 [1995] Scn From : Dieter Ringhofer 2:2476/14 12 Oct 97 09:13:02 To : Jesper Tragardh 12 Oct 97 18:05:20 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- JT> IMHO the best way is to make a new nodelist format with flags specifying JT> connect capabilities (IP, X.25, PSTN, ISDN). Each system recognizes what JT> systems it can connect to and routes the rest of the mail over defined JT> g/ws. Translation of nodenumbers to a valid adress (IP, PSTN-number, X.25) JT> is left to the best way of each technique (DNS for IP, short format JT> Fido-id, PSTN-number list for that one). Users of old mailers operating JT> over Vmodem then just replace their nodelist compilers. The old nodelist JT> will probably still be distributed to those in need using MakeNL to JT> compile it with not PSTN-systems listed as Pvt and -unpublished-. There's no need to introduce a new nodelist format if people choose the correct place (read: field) to put needed data in. The last 'checkpoint' for every mailer are the flags reflecting capabilities of called system. Examples: System is not capable to serve dialup callers but offers continious IP Put IP number into phonenumber field, set correct flags. System is capable to serve dialup calls and IP Put IP number or DNS name in system name field, phonenumber in phonenumber field, set correct flags to reflect capabilities. You're out of trouble for maximum field length doing it this way. The onliest real drawback at this kind of solution is (currently) MakeNl because it doesn't accept other characters than numbers and 'dashes' in phonenumber field. The rest depends on implementation at the frontends in use and is compliant with existing software. Frontends like Xenia, Binkley or Cantaloup are totally happy with an IP address in phonenumber field and act according flag settings. Therefore many people don't have the need to set new software up, they can use the existing (and already registered) one. Even an IP dialup via a provider works fine this way, FTN protocols are more efficient and 'secure' than native IP protocols (those are streams). To distinguish between IP address and phonenumber and acting according found data is very easy because one includes dashes (= phonenumber), the other one (IP address) dots (IPv4) or colons (IPv6) so I can't see that much of a problem to introduce the second style. It might need an extension at the nodelist index (like at V7) but, that's not a real problem. Solution might be to introduce a second index to stay compliant with existing (and paid) software. Using things we aren't able to influence in any way (like trippled zero) is no real solution, it might happen to need a change at some time not forseeable (maybe tomorrow?) and break existing implementations than. Doing it all the 'Internet way' will lead to the same thing like it did with a network in Germany (Zerberus) which uses kind of Internet compliant standards (or the same): It almost vanished and can be called part of Internet nowadays. The net isn't free in decisions, it always must have a look at Usenet etc. If you want to kill Fidonet, do the same. Listing of first IP-only node not marked as pvt in the nodelist has been the first step in this direction (the same mistake has been done with ISDN-only systems). --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #524 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 13 Oct 97 00:36:32 To : All Subj : IP-Testnodes Report ------------------------------------------------------------------------------- Hello All! In the meantime I have connected every testnode except 3035 (until now) and send them a message, partly after readdressing because they did not present their 2:2/3* address. This was done with Vmodem for OS/2 and BinkD. I am waiting for the outstanding answers. On the other hand, about 40 other systems connected to my system with the above programs and additionally Argus. The developer of FrontToss (Dirk Astrath) tests his implementation on my BinkD port. Just to remind you, that the testnode is not just a silly additional aka, but should be used with a certain intention. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #525 [1995] Rcv Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 10:39:22 To : Lothar Behet 13 Oct 97 05:47:56 Subj : A bit of steering ... ------------------------------------------------------------------------------- Lothar Behet said in a message to Pedro Lima: PL> But if the problem is MakeNL, all we have to do is replace PL> it, which should be a fairly simple thing to do. LB> At first you have to replace Makenl on every instance, were "new LB> data" is processed. And THAT is the nightmare... because as widespread as IP-capable nodes are, and as sparsely populated as they are -- I expect I'd have a hell of a time getting my NC -and- RC -and- ZC to implement a new nodelist builder on demand, even though my net/region has a significant number of IP-capable nodes. PL> Using other than the phone field to place the address doesn't make PL> sense to me, because the phone field in the nodelist serves the PL> practical purpose of informing the mailer where he has to connect to. LB> Is the system name not in a certain way equivalent? Not at all, Lothar. If one wants to use the telno field, then you've denied that node number the ability to support PSTN FTS-0001 services on the same system. I think that if we develop a standard where the node can -still- support PSTN FTS-0001 connections during ZMH, we'll have a lot easier time getting the whole package accepted. Otherwise we'll get caught up in the sure-to-happen controversy over ZMH compliance. While I'm convinced that ZMH does not require a PSTN-capable node based on how Policy 4 and FTS-0001 is written, I'd also think it wise to avoid that discussion if at all possible. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #526 [1995] Scn From : rafal wiosna 2:480/33 11 Oct 97 12:04:46 To : Ward Dossche 13 Oct 97 05:47:56 Subj : 000 = emergency-number in Australia ------------------------------------------------------------------------------- þ (IP_CONNECT, Sun Sep 28 1997) Ward Dossche -> All: >> Yes, 000 is the Australian emergency number. I was thinking of 999 as a >> prefix code to use ... WD> Comments anyone? 999 is medical emergency in Poland. 8^) - Rafa’ "WXR" WiOS/2na. --- GoldED/2 2.51.A1026+ 30PL2 * Origin: This virus requires Microsoft Windows (2:480/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #527 [1995] Scn From : Lech Szychowski 2:480/33.7 12 Oct 97 02:04:00 To : Marco d'Itri 13 Oct 97 05:47:56 Subj : A bit of steering ... ------------------------------------------------------------------------------- >>Only as long as there is just one IP address for a Fidonet address. > It's like a node with two PSTN lines: it will get another AKA. Ain't this a bit like a pain in the *ss...? IMHO it is. For example, mailer has no way of knowing that a certain set of addresses denote the same system, which means it will try to use just the IP address corresponding to the Fido address specified in the mail packet. We already see this happen with multiline nodes... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #528 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 09:40:56 To : Ward Dossche 13 Oct 97 05:47:56 Subj : A bit of steering ... ------------------------------------------------------------------------------- Ward Dossche said in a message to Lech Szychowski: > Well, let me clarify one more thing: you are not trying to imply that > Z2 Fido IP-nodes should all be listed under z2.fidonet.org domain? WD> I am not implying it ... fact is I am stating it with a degree of WD> clarity that leaves no room for interpretation. WD> WD> The matter must stay manageable hence I see only 2 acceptable ways: WD> 1) The full-IP number in the nodelist; WD> 2) The FQDN in the nodelist. WD> WD> Both in the namefield, no more no less. Ward, while I fully agree with your point above concerning information in the nodelist namefield, I fail to see why it should be necessary, or mandatory, that the FQDN listed be assigned in z2.fidonet.org If the FQDN is used, then the mailer will need to do a DNS lookup anyway to get the IP address, and it then becomes irrelevant as to what DNS zone that FQDN is managed in. For example, I'm managing two FQDN zones right here on 106/6018 (eforest.houston.tx.us and tcrs.org) -- I own them -- I see no reason why I shouldn't be able to list hub.tcrs.org in the nodelist when such capability becomes available, or bbs.eforest.houston.tx.us -- subject, of course, to possible limitations on the FQDN string length that can be supported in the nodelist entry. In fact, for that matter, I can do exactly -that- right now, subject to the acceptance of the nodelisting change by my NC -- the only real issue is when mailers become capable of doing a DNS lookup on that field and 'calling' the returned A record value. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #529 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 09:41:56 To : Ward Dossche 13 Oct 97 05:47:56 Subj : A bit of steering ... ------------------------------------------------------------------------------- Ward Dossche said in a message to maciej grzeszczuk: WD> Putting the address in the phone-field and otherwise treat it as a WD> regular entry is the most simple and easy. But what about people like me that run an IP-capable mailer and a PSTN-capable mailer on the same system at the same node number? I'd like to be able to list -both- mailers at the same node number. Using some field -other- than the telno field is the only functional way to accomplish this. Your previous suggestion to use the NAMEfield for a FQDN is a better one, I think, than trying to put the IP address in the telno field. Besides, the latter would require a rewrite of MAKENL or a new nodelist builder which all coordinators would have to agree to utilize. The former requires NO changes in existing nodelist utilities AT ALL! --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #530 [1995] Rcv Scn From : Lech Szychowski 2:480/33.7 12 Oct 97 02:48:00 To : Lothar Behet 13 Oct 97 05:47:56 Subj : A bit of steering ... ------------------------------------------------------------------------------- > LS> Only as long as there is just one IP address for a Fidonet address. > Do you really need more than one _fqdn_ to handle several protocols on > different ports on several computers? On several non-interchangeable (ie not having the identical capabilities) machines? Yes. On one machine? No. > I believe strongly that there is no real need for multiline-ip-systems > in the nodelist. IMHO you are wrong. My system is reachable from the Internet as three IP addresses - and the reason behind it is it has three different physical links from different ISPs, for sake of redundancy and reliability. And I think it really makes sense to have all the IP addresses listed, to provide as much connectivity as possible. > For larger conventional systems with several phone lines it is no > problem, to spread the ip-relevant information on several lines, if the > services run on several computers. But if it is one multi-homed system? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #531 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 10:23:24 To : Lech Szychowski 13 Oct 97 05:47:56 Subj : A bit of steering ... ------------------------------------------------------------------------------- Lech Szychowski said in a message to Rune Johansen: > I have said this before, and I will say this again. We should not be so > narrowminded to rely on "fidonet.org" DNS for implementing a conformant LS> [...] > Please, think of "othernets" too, even if you are not a member of such LS> Yes, I see a valid point here. For a moment I felt very tempted to LS> say that a mailer should take care of adding the right domain to LS> the constructed fXX.nYY.zZZ - but I'm afraid it is a bit too much LS> of a requirement for most mailers we have around. Not necessarily, Lech. It's amazing how much we're thinking alike. Just after I read Rune's message I had the exact same reaction -- define a search list of domain suffixes in the mailer config file that the mailer would perform searches in. Then the FTS standard only has to specify that the mailer translate the Zone:Net/Node entry to a Node.Net.Zone prefix, and append the suffix of the SYSOP's choice to the string to complete the DNS lookup, and presto! we've become worldwide othernet compatible. For that matter, if one has properly configured their RESOLVER, it's arguable that this even needs to be in the mailer config. If I put FIDONET.ORG in my resolver config file, then any Node.Net.Zone hostname that doesn't resolve in my native domain will be searched in FIDONET.ORG -- or any other domain that I would be operating my mailer in. One does presume, however, that as a minimum each FTN ZONE would have a 'default' domain that these lookups would be defined in. Of course, there's still nothing precluding the support of a FQDN in the NODENAME field or LOCATION field either, except that mailers would also have to be programmed to use that information. LS> On the other hand, if we are talking about IP-capable mailers, we LS> are talking about the software that is still being actively LS> developed, which means the developers might quite fast implement LS> this feature... LS> Leszek. LS> ___ FastEcho+ 1.45 LS> - Origin: Abandon hope all ye enter here (2:480/33.7) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #532 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 11:32:14 To : Fausto Carvalho 13 Oct 97 05:48:00 Subj : About DNS-based solution ------------------------------------------------------------------------------- Fausto Carvalho said in a message to All: FC> Maybe some of you are not aware of that, but during last year at FC> least twice we had a giant colapse for days in the Internet, FC> because of DNS problems. FC> Fidonet (as now) can survive for weeks, months, without Nodelist FC> updates. Any DNS-based network will stop in few hours... FC> I'd also like to stress that one of the key features of Fidonet is FC> to allow one to one communication without depending on somebody FC> else. -FC- Good point, Fausto. It does lend credibility to allowing a system where the IP address would be included in the nodelist. But, then again, for somebody making regular connections to a stable address, if the TTL is long enough, a cached DNS record should eliminate most of these issues for most nodes. In each case, the DNS outages were only for a few hours. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #533 [1995] Rcv Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 10:45:36 To : Lothar Behet 13 Oct 97 05:48:00 Subj : A bit of steering ... ------------------------------------------------------------------------------- Lothar Behet said in a message to Lech Szychowski: >> As you can see, all vital information (ip and pstn) is handled >> within a single nodelist entry, as long as the flags are clearly >> defined. LS> Only as long as there is just one IP address for a Fidonet address. LB> Do you really need more than one _fqdn_ to handle several protocols LB> on different ports on several computers? Lothar, I think Lech's point was with respect to multiple-homed nodes.. those with more than one IP address. However, I agree with your point that -one- FQDN should serve the purpose, as it's quite likely that FQDN already has multiple address records in the DNS, and, as I mentioned to Lech, it's also quite likely that a multiple-homed system is also managing their own DNS zone, so I see no real issue in this case. LB> I believe strongly that there is no real need for LB> multiline-ip-systems in the nodelist. On the contrary, Lothar -- there are many advantages to a major zone hub having multiple IP addresses with routing through different paths. For one... echomail continues to flow to -some- regions even though a major trunk may be down. For two... even the systems on the other side of the broken trunk can route their connections to a different IP address, get the same node, and continue to transfer mail. Such -is- the nature of TCP/IP. LB> For larger conventional systems with several phone lines it is no LB> problem, to spread the ip-relevant information on several lines, if LB> the services run on several computers. Agreed, but very shortly I will likely have two IP addresses on 1:106/6018 from two different providers and both of them will be resolvable by the same FQDN, as I manage the FQDN zone. I'd like to be able to have both IP routes available to callers. More significantly, I'd like to be able to -prioritize- which route the Fidonet connects come in on, but I'm not suggesting that capability be addressed in the initial standard. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #534 [1995] Scn From : Lech Szychowski 2:480/33.7 11 Oct 97 03:23:00 To : Fausto Carvalho 13 Oct 97 05:48:00 Subj : About DNS-based solution ------------------------------------------------------------------------------- > Fidonet (as now) can survive for weeks, months, without Nodelist > updates. Any DNS-based network will stop in few hours... I'm afraid I cannot agree. Suppose we can't update nodelist any more. Ok, for the first week or so everything goes as usual. But then problems start to pop up: some nodes go down, new nodes are not introduced, routing start to break down (hubs/hosts being down but not listed as such in the nodelist). Yes, quite a lot of stuff still works, and Fidonet still survives - but not much more than that. Now suppose we can't update DNS databases any more. What happens? Pretty much the same as in previous case, with some quite minor differencies (eg no one week stability period). Frankly speaking, DNS being a hierarchically ditributed database is more likely to resistant against such failures. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #535 [1995] Scn From : Lech Szychowski 2:480/33.7 12 Oct 97 01:39:00 To : Timur Hi-Rullin 13 Oct 97 05:48:00 Subj : IP-access ------------------------------------------------------------------------------- > not ip-address. It means that node have a ip-address 192.168.100.200, > names fido-node.company.com and can be resolved as > f49.n5049.z2.fidonet.net too. Therefore, there's no need to put _any_ > ip-address to nodelist. Isn't it like good? Yes, it is. The only thing I'm against is the "fidonet.net." domain. Why not the usual "fidonet.org."? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #536 [1995] Scn From : Lech Szychowski 2:480/33.7 12 Oct 97 02:32:00 To : Sean Rima 13 Oct 97 05:48:00 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- > LS> How big the session negotiation/handshake overhead in everyday [...] > An average EMSI connection of the Net takes me around 3-5 seconds. An > average BinkP is .5 - 1 second. And that is extensive use. My Ipmailer OK, so let's say we spare 3 seconds on each session. These three seconds give us time to transmit something between 2KB and 20KB, 8KB being quite a good number if we are talking about dialup modem connections. That's not much. Which, of course, is not supposed to mean it's not worth fighting for :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #537 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 11:34:30 To : Slava Filimonov 13 Oct 97 05:48:00 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Slava Filimonov said in a message to maciej grzeszczuk: SF> Hello maciej! SF> 08 Oct 97 22:44, maciej grzeszczuk wrote to Sean Rima: mg> i said that we should specify one standard, available at every ip-node mg> system. and i proposed vmodem. mg> i don't say that we shouldn't include binkd nodes in a nodelist, but mg> they should also support vmodem connections - some kind of fst-0001 mg> for ip-nodes. SF> We can't set vmodem as a standart protocol for ip session, cause SF> it's based on non-free software. We should use binkd as a standart, SF> which is free and protocol spec is avail, and vmodem as option. Slava... I think the mistake in interpretation is the use of "vmodem" as a generic term. I suspect the proper terminology is a telnetd/fts-0001 capable node. While you are correct that VModem, per se, is not free, there are telnetd compatible implementations on every platform that are. Of course, I also wonder if somebody were to approach Ray Gwinn about assisting us with making VMP an FTS standard, and publishing the specifications, if not actually releasing the source code, he just might be willing to cooperate in the matter. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #538 [1995] Scn From : rafal wiosna 2:480/33 11 Oct 97 12:30:04 To : all 13 Oct 97 05:48:00 Subj : BinkD - _NOT_ the standard ------------------------------------------------------------------------------- þ (IP_CONNECT, Fri Oct 10 1997) maciej grzeszczuk -> Sean Rima: mg> ifcico+vmodem mailers. remember that they all use the same protocol! mg> and i bet that there is more of them than binkd. That's not the point. The main reason why VMODEM/telnet should be a standard [i.e. minimum IP-node requirement] is that old-style PSTN mailers could be prepared to talk to other mailers via internet with clever use of, for example, SIO/VMODEM under OS/2. And on what platforms BinkD is available? - Rafa’ "WXR" WiOS/2na. --- GoldED/2 2.51.A1026+ 30PL2 * Origin: Jaki typ monitora? Nie wiem, chyba 220V 50 Hz... (2:480/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #539 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 10:44:30 To : Lech Szychowski 13 Oct 97 05:48:00 Subj : A bit of steering ... ------------------------------------------------------------------------------- Lech Szychowski said in a message to Lothar Behet: > As you can see, all vital information (ip and pstn) is handled within a > single nodelist entry, as long as the flags are clearly defined. LS> Only as long as there is just one IP address for a Fidonet address. If the standard also allows for the use of FQDN, then multiple IP addresses can be resolved via DNS, and it ceases to be a nodelist issue. I tend to think that anybody with multiple IP addresses probably is managing their own DNS zone server anyway, so it shouldn't be any issue at all. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #540 [1995] Scn From : maciej grzeszczuk 2:480/70 12 Oct 97 14:23:44 To : Sebastian Stein 13 Oct 97 05:48:00 Subj : Re: vmodem ------------------------------------------------------------------------------- From: maciej grzeszczuk Fri, 10 Oct 97 18:24:09 +0200 Sebastian Stein napisal byl w fido.ip_connect: > Correct me, if I am wrong ! My english isn't the best, maybe I misunderstood > you ? both telnet (in your meaning) and vmodem are the same protocol. 545 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: rave (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #541 [1995] Scn From : Lech Szychowski 2:480/33.7 11 Oct 97 03:36:00 To : Rune Johansen 13 Oct 97 05:48:00 Subj : Flags in nodelist ------------------------------------------------------------------------------- > Truly the Fidonet spirit. Purely egoistic thinking. Why don't we define > a nodelist to be of zone 1-6, and nothing else too? We never said _a_ nodelist cannot include data for zones identified with numbers other than 1 thru 6. All we say is _the_Fidonet_ nodelist consists of zones 1 thru 6. > No, not lame at all. With all the warfare going on in the 'net today, > you should not be absolutely certain that all sites will have a > possibility to do DNS resolving. It's not even certain that all > administrators of DNS servers will allow requests for resolving the > fidonet.org domain to pass through. Come on, don't panic. You could as well start being afraid some day some routers might not route packets for some addresses. Sure we can't be absolutely sure the packets will be routed - but then we cant be absolutely just about one tring: we'll all die some day :) > All I am trying to say, is that we should not put ourself relying on a > service that could be out of our control, that is place the whole > resolving of what IP address to connect to in the nodelist from the > fidonet.org domain. Yes, I undestand it. But IMHO the chances for this nightmare becoming real are less than slight. > Also, as I have pointed out earlier, by including the address directly > in the nodelist, we would open up for other access mechanisms than > internet, like X.25, X.21, etc. You are absolutely right. Long term plans for adopting an extended nodelist format should have this idea included. But if we are to get a working viable solution fast, we have to respect compatibility issues. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #542 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 11:48:20 To : Rune Johansen 13 Oct 97 05:48:00 Subj : Flags in nodelist ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: >> What if fidonet.org disappears? > What if it does? What if -ANY- domain that somebody relies upon for > internet access disappears? The answer: Somebody reregisters it! RJ> Yes, somebody reregisters it, but it is not _certain_ that they RJ> will have the same structure, or even be associated with the RJ> Fidonet at all. RJ> Even if you pay for something, it's not certain that you will keep RJ> it. I highly doubt anybody's going to start playing games with the ownership of domain names. :) RJ> All I am trying to say, is that we should not put ourself relying RJ> on a service that could be out of our control, that is place the RJ> whole resolving of what IP address to connect to in the nodelist RJ> from the fidonet.org domain. Also, as I have pointed out earlier, RJ> by including the address directly in the nodelist, we would open up RJ> for other access mechanisms than internet, like X.25, X.21, etc. Rune... here's a thought... while FIDONET.ORG may be dependent upon the "Internet" -- there's also nothing keeping Fidonet(tm) from setting up our own proprietary ROOT SERVER in the Top Level Domain .FIDONET or .FIDO Since anybody needing to resolve a name in that domain would have access to the IP address of the ROOT servers -- it's always possible that Fidonet could have exclusive control of its own internal DNS system. It would also be wholly independent from the INTERNIC DNS and give us the option to alternative things with it that might not be acceptable in the Internic (or successor(s)) DNS. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #543 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 11:47:56 To : Rune Johansen 13 Oct 97 05:48:00 Subj : Flags in nodelist ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: >> For that, is several reasons: What if this technique is to be used >> in other fidonet technology networks? > Then let THEM register their own *.net or *.org domain and maintain > their own DNS servers. There's nothing wrong with an FTN standard > (which, btw, really only applies to Fidonet anyway, technically) > mandating that the NETWORK must provide their own DNS servers in > order to implement the technology. RJ> Truly the Fidonet spirit. Purely egoistic thinking. Why don't we RJ> define a nodelist to be of zone 1-6, and nothing else too? I think you've misunderstood my intent, Rune. I apologize for not being more clear. My point is that there is not any reason why this project must be restricted to FQDNs in the fidonet.org domain. I've read throughout the posts in this echo that the proposal should not be Fidonet(tm) specific, and I agree with that perspective. However, the natural requirement then is that othernets(tm) will have to have -some- FQD somewhere that is their own to use. No? --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #544 [1995] Rcv Scn From : maciej grzeszczuk 2:480/70 10 Oct 97 14:04:44 To : Lothar Behet 13 Oct 97 05:48:00 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 07 Oct 97 07:59:32 +0200 Lothar Behet napisal byl w fido.ip_connect: > Could you please tell me (and others:), which products support Vmodem for PC > based operating systems (DOS, Windows, Win96, Win95, WinNT) and where they > are available? i'm unix operator, i don't know where to find windows software. but i know for sure that vmodem is available on: amiga, os/2, win95, win3.1, winnt, unices, as i can see connections from systems using that os in my mailer log every day. > A software or protocol standard must be usable by most of the nodes. sure. and binkd (binkp) isn't such standard. it's only supported by small (2 i heard, third is under construction) number of mailers. 505 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: greg, pedz stad! (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #545 [1995] Scn From : maciej grzeszczuk 2:480/70 10 Oct 97 14:09:38 To : Slava Filimonov 13 Oct 97 05:48:00 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 07 Oct 97 09:37:02 +0200 Slava Filimonov napisal byl w fido.ip_connect: > fido over ip. Is this a real solution for all or what ? Finally, if you want > to stick with vmodem, than keep ip for your convenience. Just alter your > outbound to bink-style and keep 'em all - old mailer, binkd, your old mailer > with vmodem. listen. vmodem is just a tunnel for ANY mailer. so don't tell me that my 'old mailer with vmodem' is good or bad, if you don't know what are you talking about. we've already heard that your binkp is the most wonderfull thing, but how can you say such things if you didn't really seen anything working with vmodem, huh? 506 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: parasol (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #546 [1995] Scn From : maciej grzeszczuk 2:480/70 10 Oct 97 14:16:24 To : Slava Filimonov 13 Oct 97 05:48:00 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 07 Oct 97 09:58:53 +0200 Slava Filimonov napisal byl w fido.ip_connect: > At the end of the day you'll pay for this compatibility. As i said - keep > your old mailer. Set it up to bink-style. Add binkd (it takes about 10min to > install and configure it). why would i pay for the compatibility? > At the fido beginning there was only two nodes which had support for new mail sure. but all supported the old one. so you, guys with better protocol, keep using your excellent one, but also allow vmodem connections. > >> bwt, this echo comes to me through binkd. > mg> this echo comes to me through raw emsi via tcp. > Now tell me your link capacity and avg cps ? 64kbs, 14159cps, transferring zipped echomail, 155kbytes package. 507 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: ciri kocha krapa... w pupe... (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #547 [1995] Scn From : maciej grzeszczuk 2:480/70 10 Oct 97 14:20:16 To : Sean Rima 13 Oct 97 05:48:00 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 07 Oct 97 14:18:54 +0200 Sean Rima napisal byl w fido.ip_connect: > > using binkd of course. other mailers are not allowed. > Just a curious question. How many IFCICO mailers are there live on the Net. I > am curious. ifcico+vmodem mailers. remember that they all use the same protocol! and i bet that there is more of them than binkd. > I know a BBS use uses T-mail as his main mailer and for TCP/IP connectiuons > uses BinkD. Here has no problems with this setup and uses it daily. and i know bbs uses t-mail, using t-mail to connect to my ifcico, without configuring another mailer. everything is ready-for-action on his os/2. do you want me to show my log from that connection? > BinkD as a program is *NOT* able to be used on a Telephone line. It is a > small program to allow connects over the Net. It works along side T-Mail, > Argus and it won't work with t-mail. it works with the same outbound that t-mail does, but don't say that it works WITH it. > any other Binkley type mailer. And it is free. 508 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: policjant sam (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #548 [1995] Scn From : maciej grzeszczuk 2:480/70 10 Oct 97 14:23:32 To : Sean Rima 13 Oct 97 05:48:00 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 07 Oct 97 14:25:34 +0200 Sean Rima napisal byl w fido.ip_connect: > > if so, please tell me the location i can find the patch to my ifcico > > mailer. > I will try and find out the url for you. But I mean't the protocol BinkP. i'll be very happy if you do. > > using emsi over tcp about 30-40 times a day, and haven't noticed any > > problems > > with slow handshaking, nor dropped connections. > Umm, I did but then maybe it was me. i know about 15 nodes around me using emsi over tcp, and they haven't noticed any problems also... > I could not have a Telnet mailer operating on port 23 as I have to telnet > into my shell account to read some mail. Also to start and stop both the > mailer and tosser from time to time. you can always set your telnetd or your mailer onto another port. it makes no problem... 509 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: przepraszam bardzo, widzial pan busik? (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #549 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 10:58:58 To : Jesper Tragardh 13 Oct 97 05:48:00 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Jesper Tragardh said in a message to alla: JT> The only argument for making FTS-0001 connects over the telnet port JT> is that some people might be sitting behind a firewall blocking JT> everythin but the telnet, ftp and www ports. Not true, Jesper. There is another argument for FTS-0001 connects via telnet. As I mentioned in an earlier post, my interpretation is that Policy 4 and FTS-0001 do not specify the telecommunications methodology for Fidonet Policy compliance, but they do specify that the mailers MUST be able to negotiate an FTS-0001 compliant session (over whatever telecommunications system is chosen, whether it be PSTN or IP). If I understand BinkP correctly, it does NOT negotiate any FTS-0001 session, therefore, in the strictest sense of the word, is not Fidonet Policy 4 compliant as a minimum required standard. On the other hand, a TelnetD-generic session -can- negotiate a FTN FTS-0001 mailer-to-mailer session, and thus would meet the requirements for a minimum ZMH compliant node. I'm not at all opposed to the use of BinkP, and based on what I've read here in the past couple of days, I'm going to put a BinkP/BinkD node up on my systems along side my VModem nodes. Anybody with BinkP/BinkD capability throughout the world would also have the capability to put up ONE TelnetD/FTS-0001 compliant node for one hour each day. I think -that- is the minimum requirement for sustaining a legal listing in the nodelist, and doesn't seem too much to ask. Keep using BinkP to do -real- echomail/filebone transfers, but use the TelnetD/FTS-0001 session for ZMH compliance -- that way everybody is happy. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #550 [1995] Scn From : Lech Szychowski 2:480/33.7 11 Oct 97 03:25:00 To : Rune Johansen 13 Oct 97 05:48:00 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > You are absolutely correct here. I am talking about the telnet handshake > protocol, applicable for telnet sessions. You can run binary high-level > protocols on top of a telnet session. Just like a normal (ie PSTN) BBS, with a mailer answering calls and passing human callers down to BBS software? Sure. But I can't find any problem here - from Fidonet point of view the mailer is there and that's all we need. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #551 [1995] Scn From : Lech Szychowski 2:480/33.7 11 Oct 97 03:43:00 To : Jesper Tragardh 13 Oct 97 05:48:00 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > also counter-productive. If s.b were to let his 24h online TCP/IP > machine offer Fido-service, he probably wouldn't be interested in a new > telnetd. He would want a Fidod (using binkp or what ever) to answer on a > specific port. And that's precisely the way things work now. > IMHO the best way is to make a new nodelist format with flags specifying > connect capabilities (IP, X.25, PSTN, ISDN). In a long run, certainly. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #552 [1995] Scn From : Lech Szychowski 2:480/33.7 12 Oct 97 02:10:00 To : Marco d'Itri 13 Oct 97 05:48:00 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>oh yeah. and vmodem is compatible with any mailer, as it's tunneled standard >>session. > It's slower. > I don't want to waste money because I must use a suboptimal protocol. Nobody is trying to force you to use vmodem for your everyday mail traffic. Keep on using anything you and your links agree upon - but also support the vmodem as a "lowest common denominator", just in case someone wants to connect to your system usubg this protocol. Your PSTN mailer supports pure/raw FTS-0001 sessions, right? But no one says you _have_ to use _just_this_ flavor of sessions. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #553 [1995] Scn From : Lech Szychowski 2:480/33.7 12 Oct 97 02:33:00 To : Sean Rima 13 Oct 97 05:48:00 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>> So do I. But ruling out a protocol that is in daily use by over >>> 100 Ipmailers seems the wrong way to go. One more thing: it's not about ruling it out or declaring "not to be used". It's just about not making it a minimal standard that has to be supported by every node. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #554 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 08:53:28 To : All 13 Oct 97 05:48:00 Subj : Controversy Regarding Node Number ------------------------------------------------------------------------------- A recent 'decision' in Region 19, which seems to have universal support amonst the Zone 1 RCs (at least as far as I've heard so far) -- might also have impact for those of us dealing with IP nodes. Since Zone 1 has now, effectively, declared the absolution of geographical boundaries (some say in violation of P4, others are using very broad definitions of "local calling area"), it occurs to me that the door is open to establish an IP-only Region in whatever zone has a ZC willing to set the region up. Hey Ward! Can I get a Zone 2 node number? But seriously... would Zone 2 consider creating an IP-only Region? It might also make life a bit easier with regard to the issues of DNS management and IP/DNS/Nodenumber mappings -- after all, they could all be delegated to one server (and I have the facilities over here to run a North American secondary, if anybody is interested). ======================================================================= * Forwarded (from: R19SYSOP) by Lawrence Garvin using timEd/2 1.10+. * Originally from Bruce Bodger (1:170/400) to Michael White. * Original dated: Sat Oct 11, 12:01 Copied via Netmail to Michael White, Roger Etheredge, Ron Bemis, Bob Satti. * Crossposted to R19COORD This message, and the decision it contains, is relative to a controvesy which was called to my attention on Sept 17. Michael White, a former resident of Irving, Texas, and a member of Net 124 since March of 1996 moved to Denton, Texas in April of 1997. N124C allowed Michael to retain his Net 124 address since Michael had subscribed to a "Metro Calling Plan" which made his phone exchange (940) a local call both TO and FROM the Dallas area. For information purposes only, it was Michael's desire to retain his Net 124 node address. Sometime around the 2nd week of September of this year, N393C, having noticed that Michael had moved to Denton, informed him that he should prepare to drop his Net 124 address and assume a Net 393 address. Michael sought relief by contacting N124C who in turn contacted me to help decide if Michael could remain in Net 124 or should be "moved" into Net 393. It has taken me this long to come to a decision in this matter partially due to the fact that POLICY4, which was written in 1989, was written before calling plans such as the "Metro Calling Plan" existed thus making its definition of Network boundaries somewhat difficult to fit what we have in effect today. In my endeavor to formulate a fair decision I contacted Michael, N393C, N124C, Southwestern Bell (in order to ensure that I fully understood the "Metro Calling Plan,) the other Region Coordinators (three of which provided input,) and the Zone Coordinator (who supports the decision that I'm about to render.) Be advised that this decision is not in reply to a Policy Complaint and although it surely can be appealed to the Zone Coordinator, is not encumbered by any possible ex-parte protections that Policy Complaint appeals might be subject to. There are several sections of POLICY4 which address, or might address, the question at hand. The section which I relied on most heavily in the formulation of my decision is this one: ================================================================ 1.2.3 Networks and Network Coordinators A network is a collection of nodes in a local geographic area, usually defined by an area of CONVENIENT TELEPHONE CALLING. Networks coordinate their mail activity to decrease cost. (my emphasis) ================================================================ As Michael has chosen to subscribe to a calling plan which makes access TO his system toll free by the members and residents of the Dallas Net it certainly fullfills the "convenient telephone calling" item referenced above and provides justification for Michael to retain his Net 124 affiliation. The fact that Michael has to pay extra in order to make his system toll free from Dallas is irrelevant. Access TO Michael's system by those members and residents of the Denton Net is also toll free and "convenient." My final decision was based totally on Policy, as explained above. Other items OF INTEREST which surfaced during my discovery include: a) Michael's desire to remain in Net 124. b) The length of time which elapsed between his move to the Denton area (April "97) and the request for a decision (September "97) might provide some "grandfathering" which would work in Michael's favor. c) My belief that POLICY4, although obviously out of date, should be interpreted to help FidoNet members in good standing and not to be wielded AGAINST them in support of petty differences. d) A decison other than the one I've made would only inconvenience Michael, however slightly, who I view as an innocent victim in this dispute between two "rival" Network Coordinators. Therefore... Michael White may retain his Net 124 address as long as he retains a phone number which makes calls TO his system toll free from the Dallas area. I certainly don't expect this decision to satisfy all who read it. Each case of POLICY4 interpretation must be based on the best information available at the time the decision is made. Whether or not this decision establishes a precedent will be based solely on the details of each similar case to surface. Bruce Bodger Region Coordinator, Region 19 ___ - Origin: ** the TruckStop BBS ** Tulsa, OK (918) 254-6618 (1:170/400) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #555 [1995] Scn From : Lech Szychowski 2:480/33.7 12 Oct 97 02:26:00 To : Marco d'Itri 13 Oct 97 05:48:00 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >>- how do they deal with duplicated filenames? > Where is the problem? They will rename arcmail packets in a way they > will not overwrite anything in the inbound, like normal mailers do. FTP daemon will rename received files? >>- how do they deal with putting something on hold (ie transfrerring >> to the calling party something which name this party has no way of >> knowing about beforehand)? > I can't understand why you think this is a problem. My vmailer sends I think it is a problem because some people try to squeeze in here some protocols like FTP or SMTP. I'm perfectly aware one can write software that supports things like putting on hold, renaming etc. But it won't be the FTP protocol this software will use - it will be either an extension to this protocol or a completely new one. >>- how does SMTP deal with file requests? > By sending a .req file. The receiving program will intercept this file > and create a file attach for the other node. And how does SMTP pick the attach up? >>- how does SMTP deal with authorisation? > My protocol supports encrypted transferts, PGP-signed and/or encrypted > transferts (following the S/MIME standard) and clear password protected > transferts. SMTP nowadays supports nearly everythingh as a message body. But it has nothing to do with the session authorization. >>You'd have to write an extended capability FTP agents for that. > There is already one, with source and GPLed. My objection was mainly about using the name of "FTP" here. It will no longer be the FTP as RFC defines it. >>You'd have to write an encoding/decoding/splitting/reassembling >>software for that. > I wrote one. It does not split and reassembly because I don't need that, We certainly will need it. A lot of mailers enforce limits on the size of a single message. >>And I personally doubt using this protocols is worth the amount of >>work we have to put in before it works. > Ok, just don't use it. And I don't. > (BTW, I think that non-PSTN email only nodes should be only points.) At last something we have in common :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #556 [1995] Scn From : Lech Szychowski 2:480/33.7 12 Oct 97 01:47:00 To : Amir Shabashvili 13 Oct 97 05:48:00 Subj : IP-access ------------------------------------------------------------------------------- > LS> Now that's something I don't like. Another domain? What for? > For testing all things (like DNS-nodelist resolving) we discuss in Testing is OK. But once testing is over we should IMHO start using the fidonet.org. domain. > And we need something like fidonet.net as DNS-decision for IP nodes, with > delegating DNS managing for every net to NC's or persons they point to. Certainly we do. But why ".net", not ".org"? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #557 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 09:18:40 To : Lech Szychowski 13 Oct 97 05:48:00 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Lothar Behet: LS> What you seem to talk about is a mobile system. When I wrote LS> "multiple-homed" I meant one system that has three network LS> interfaces (all of them permanently/simultanously active). Lech, I think the simple answer to this is just multiple nodelist entries, just as we do now if one has multiple telnos on a node. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #558 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 09:48:06 To : Ward Dossche 13 Oct 97 05:48:00 Subj : IP-access ------------------------------------------------------------------------------- Ward Dossche said in a message to Ger Vloothuis: > Coming to think of it, why not keep the existing V7 Nodelist unchanged, > and make the mailer try to resolve the IP number from the default Fido > domain address: WD> > "p#.f#.n#.z#.fidonet.org" WD> WD> Because that would mean every IP-capable node should be listed in WD> extenso in the internet-tables. So... WD> That means we'd have nodelist-management governed by WD> policy-documents which can be enforced while there'd be the WD> management of internet-tables on which we have no grasp from WD> inside Fidonet. Not at all, Ward. The listing of -any- name in the DNS is already governed by existing RFCs. There is no need to publish Fidonet 'policies' which couldn't do anything except duplicate those RFCs anyway. Fidonet does not have any authority to change the DNS system, therefore there is no need, or purpose, to consider policy issues. The only thing that might need to exist is a published PROCEDURE, for how a node goes about getting assigned an entry in the appropriate Rxx.Z2.FIDONET.ORG zonefile. (I am, of course, assuming that the hostmaster at Z2.FIDONET.ORG is going to be willing to delegate subdomains to each Region). WD> It is a technical complication which in the end will be abused by WD> someone. So is the nodelist.... but it's a necessary evil. Or have we already forgotten Region 24? :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #559 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 10:05:18 To : Lech Szychowski 13 Oct 97 05:48:00 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Slava Filimonov: > btw, and why do they start to use HTTP protocol, if UUCP were so good ? LS> In short: UUCP is in some respects too/unnecessarily complicated, LS> in some others too/unnecessarily powerful. And in many, too/unnecessarily inefficient. For starters, it uses 7-bit transfers! Second, it's native 'g' protocol has so much overhead that the average efficiency of uucp is about 60% of capacity. Many forget that uucp was designed as a protocol to transfer email messages, which were short, and overhead wasn't a real issue. But then somebody bastardized it into doing file transfers and it's never been the same since. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #560 [1995] Scn From : Kim Heino 2:222/0 11 Oct 97 16:28:06 To : Jesper Tragardh 13 Oct 97 05:48:00 Subj : IP-access ------------------------------------------------------------------------------- > In that case most executables named "telnet", except > yours, can use raw sockets. No, they can't. Actually, they can't send/receive ascii 255 to/from raw socket, all other ascii's are ok. Between two telnets ascii 255 is not a problem. > I can telnet to port 110 on my pop3-server to check my mail for instance... Sure, as long as your pop3 doesn't send ascii 255. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #561 [1995] Rcv Scn From : Lech Szychowski 2:480/33.7 12 Oct 97 02:55:00 To : Lothar Behet 13 Oct 97 05:48:00 Subj : IP-access ------------------------------------------------------------------------------- > LS> The "tx" version of ifmail claims to be vmodem compatible: > Did you check it? No. That's why I wrote "claims to be" rather than "is". > Just call i.e. 2:2/3000 (Vmodem from SIO OS/2, port 3141 assigend to > VMP) to prove it, as that is the cause for the testnodes. I'll give it a try ASAP. > LS> vmodem 666/tcp # (Vmodem) port used on OS/2 and > LS> Windows > From which source did you retrieve port 666? It is a quote from some software included in the ifmail_tx package. > Routing is an option in FTN to keep the total cost on a convenient level > to each sysops decision, but direct connections are possible (and used > often). Right. But having access to the medium that does not vary its charges with the distance it routes packets to changes the traditional Fidonet routing ideas a lot. > I think, that normally the connect will be to a relay host, which in > general is not operated by a fido member. SMTP or UUCP connection - yes, maybe. > I do not claim any special protocol to be the sole standard for fido- > over-ip, so i see no need to prove anything :) It's not a question of an individual claiming this or that. It's a question of setting a certain minimal standard capabilities required from an IP capable node. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #562 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 10:08:02 To : Lech Szychowski 13 Oct 97 05:48:00 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Nick Soveiko: > uucp is probably fine. now comes the next question: can you propose a > technology for using any uucp flavour for the purpose of fidonet > transport? right now. that is, an already working technology. > i bet you not. LS> Do we have UUCP implementations for almost every platform? I LS> believe we have. Do we have IP (incl SLIP/PPP) stack implementation LS> for almost every platform? I belive we have. Of course there is no LS> (AFAIK) product readily availble that would support this kind of LS> carrier protocol - but there is no product that supports other LS> protocols like SMTP or FTP, either. Actually, to put this in better perspective, BinkleyTerm v2.50 actually provided for External Mail Handlers -- specifically with regard to providing access to uucp as an underlying transfer protocol. It -is- how the majority of Fidonet<>Internet gating was done through most of the early 90s, until direct IP connectivity and SLIP/PPP became available to the common user. I'm kind of fascinated that uucp is even in the discussion. I thought it had been abandoned years ago. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #563 [1995] Rcv Scn From : maciej grzeszczuk 2:480/70 12 Oct 97 15:04:52 To : Lothar Behet 13 Oct 97 05:48:00 Subj : Re: IP-access ------------------------------------------------------------------------------- From: maciej grzeszczuk Fri, 10 Oct 97 19:34:22 +0200 Lothar Behet napisal byl w fido.ip_connect: > LS> The "tx" version of ifmail claims to be vmodem compatible: > Did you check it? sure. i've got about 15 connections with vmodem daily. transferring large packages, about 500-1000kb. everything is absolutelly correct. 548 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: niezle ssie... (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #564 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 10:36:04 To : Lech Szychowski 13 Oct 97 05:48:00 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Pedro Lima: LS> I see your point. Do you think we can try to work on a solution LS> based upon a concept of "fXX.nYY.zZ constructed from FTN address, LS> the rest of the FQDN either default (ie .fidonet.org) or LS> explicitely listed in some flags field entry"? Now there's an idea! I hadn't thought of putting the domain suffix in the flags field, but it surely would address the issue, somewhat, of lengthy FQDNs in the nodelist. One would presume that, at worst, the domain suffix would be only a third level domain, and I suspect in the majority of cases would actually be a second level domain. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #565 [1995] Rcv Scn From : maciej grzeszczuk 2:480/70 10 Oct 97 14:34:16 To : Lothar Behet 13 Oct 97 05:48:00 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 07 Oct 97 07:43:42 +0200 Lothar Behet napisal byl w fido.ip_connect: > mg> binkd cannot be treated as a standard, as it's compatible only with > mg> itself. > ... on different platforms (Unix, Linux, OS/2, Win 95 and Win NT). and the vmodem is compatible with any mailer on any platform. is it so hard do understand? 510 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: szlifowanie walow i cylindrow... (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #566 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 10:01:18 To : Amir Shabashvili 13 Oct 97 05:48:00 Subj : what about... ------------------------------------------------------------------------------- Amir Shabashvili said in a message to rafal wiosna: AS> Hello rafal! AS> Žâ¢¥ç ï ­  ¯¨á쬮 rafal wiosna ª Lawrence Garvin: LG>> I'd suggest using the _NODENAME_ field, as opposed to the _SYSOPNAME_ LG>> field rw> Yes, that's what I meant. AS> Why we would not using user flag enry? Why we must override nice AS> fields like sysopname or nodename? It is not direct destination of AS> this fields - contain IP address or other techinfo. Amir, for one, it would be much easier from a programming point of view to extract a complete field from specifically identified delimiters, knowing for sure that the value will always be in field #2 of the nodelist, for example, than it would be to have to write a routine to parse the entire flags list and properly interpret what is a valid FQDN or IP address. Second, isn't the FQDN as descriptive of the node being called, as any other character string placed in the NODENAME field? In fact, I'm giving serious consideration to doing exactly that in my current Net106 entries. Third, I think the general consensus of everybody I've ever talked to, is that the NODENAME field of the nodelist is extraneous anyway --- so why not make some productive use of that character string? Fourth, there is, I believe, a limitation on the length of the FLAGS field, and trying to place an FQDN in the FLAGS field, could cause some problems -- take, for example: bbs.hd.co.harris.tx.us or bbs.eforest.houston.tx.us, which are actual VModem-capable nodes. Contrary to popular belief, not everybody is quartered in those concise little four letter second-level domain names. :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #567 [1995] Scn From : Lech Szychowski 2:480/33.7 11 Oct 97 03:07:00 To : Steve Woodmore 13 Oct 97 05:48:00 Subj : IP-connectivity ------------------------------------------------------------------------------- > LS> replaced with some reliable/controllable solution. SMTP has no > LS> "resend from" capability, no guaranteed allowable message size, no > LS> widely available software utils for dealing with files encoded > LS> into message bodies, no session passwords etc. SMTP is great for > LS> sending relatively small messages but certainly it is not a > LS> protocol of choice when it comes to mocing files around. I'm > Really?, then I come I send out upwards of 30MBs of echomail/day via > smtp as well as files, using a commonly available program (Fido2int)? Read my posting again. You will find no words like "cannot", "never", "impossible". One could also transmit 2.5 megs each day using 300bps modem, right? But if you hear someone is to transmit that much, I doubt you'll try to advise him to use his old 300bps modem rather than to get a new - say a cheap V32b - one. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #568 [1995] Scn From : rafal wiosna 2:480/33 11 Oct 97 12:12:42 To : Lawrence Garvin 13 Oct 97 05:48:00 Subj : IP-connectivity ------------------------------------------------------------------------------- þ (IP_CONNECT, Sun Oct 05 1997) Lawrence Garvin -> rafal wiosna: LG> Perhaps a workable solution is to ask NC's to create a HUB entry for such LG> systems that are "dual homed" (IP and PSTN), Only one such gate will do. - Rafa’ "WXR" WiOS/2na. --- GoldED/2 2.51.A1026+ 30PL2 * Origin: Nasze §ony wol† nas w jednym kawa’ku i w domu... (2:480/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #569 [1995] Scn From : rafal wiosna 2:480/33 11 Oct 97 12:21:32 To : Lech Szychowski 13 Oct 97 05:48:00 Subj : IP-connectivity ------------------------------------------------------------------------------- þ (IP_CONNECT, Wed Oct 08 1997) Pedro Lima -> Lech Szychowski: LS>> I think I got it. Let me rephase it: an IP-node has to be accessible LS>> for at least NNN minutes in one contiguos period each 24 hours, also LS>> start and end of this period have to be explicitly declared using "T" LS>> flags. And since the Txy flags nature, the NNN period should be AT LEAST 120 minutes. - Rafa’ "WXR" WiOS/2na. --- GoldED/2 2.51.A1026+ 30PL2 * Origin: Kultura Cisco-polo (2:480/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #570 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 09:07:58 To : Denis McMahon 13 Oct 97 05:48:00 Subj : IP-connectivity ------------------------------------------------------------------------------- Denis McMahon said in a message to maciej grzeszczuk: DM> If you can transfer FTS-0001 packets fully automated at both ends DM> then the connection is a fidonet connection. Dennis, it's not just FTS-0001 packets that are at issue, it's live, direct, one-to-one MAILER connections that should be the issue. Neither FTP, nor SMTP, fall into this classification. While I agree that it would be very useful to know which nodes support communications by FTP or SMTP, that information is not usable by my mailer (nor do I expect it ever will be), therefore, I see no functional purpose in its inclusion in a nodelist. I think that information should be published in an auxiliary listing of FTP and SMTP capable systems. Of course, if one has a full time FTP Server or SMTP Server, then one presumes that node is also capable of VModem/BinkD/IFCico, so perhaps the fundamental issue is back to defining the MINIMUM STANDARD for listing as an IP-node. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #571 [1995] Scn From : rafal wiosna 2:480/33 11 Oct 97 12:28:12 To : Amir Shabashvili 13 Oct 97 05:48:00 Subj : IP-connectivity ------------------------------------------------------------------------------- þ (IP_CONNECT, Wed Oct 08 1997) Amir Shabashvili -> maciej grzeszczuk: AS> it's compatible with bink-style outbound, and that's enought It's like saying "my bike is compatible with the weather today"... - Rafa’ "WXR" WiOS/2na. --- GoldED/2 2.51.A1026+ 30PL2 * Origin: Myžl‘, wi‘c jestem. Tak myžl‘... (2:480/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #572 [1995] Scn From : rafal wiosna 2:480/33 11 Oct 97 12:28:38 To : Lech Szychowski 13 Oct 97 05:48:00 Subj : IP-connectivity ------------------------------------------------------------------------------- þ (IP_CONNECT, Sat Sep 27 1997) Lech Szychowski -> rafal wiosna: LS> being a solution to this problem - there will be no difference LS> between "calling" your boss, someone in your region or some system in LS> another zone. That's only true for calling non-PSTN/ISDN nodes... - Rafa’ "WXR" WiOS/2na. --- GoldED/2 2.51.A1026+ 30PL2 * Origin: Windows 95 is like a box of chocolates... F. Gump (2:480/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #573 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 11:08:34 To : David Moufarrege 13 Oct 97 05:48:00 Subj : IP-connectivity ------------------------------------------------------------------------------- David Moufarrege said in a message to Lawrence Garvin: LG> Furthermore, with the (some say abuse) of DHCP, it's possible that LG> more and more IP-based systems will have dynamic addresses, even LG> where they did have permanent addresses before. DM> Well, using a service like Monolith allows you to "register" the DM> dynamic IP and "convert" it into a pre-assigned static IP address, I'm confused, so help me out here for a sec, David. If the IP address is truly dynamic, how would one be able to "register" it, as they would have no idea from call to call what it was going to be? DM> therefore being able to have a 24hr presence on the net even though DM> your ISP might use DHCP and not assign static addresses under any DM> circumstances. I agree, though, such would be helpful.. although I can't help but wonder on the side if that isn't undoing the very reason why the primary ISP implemented DHCP in the first place -- to conserve IP addresses -- and here we're registering even more -- somewhat redundant, isn't it? :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #574 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 11:22:10 To : Lech Szychowski 13 Oct 97 05:48:00 Subj : IP-connectivity ------------------------------------------------------------------------------- Lech Szychowski said in a message to Marco d'Itri: LS> Suppose we adopt the idea of declaring online hours in nodelist LS> ("T" flag) or in DNS records ("TXT" type). If it's for mailer use, then I think it will need to be in a T flag in the nodelist. The mailer does need to know whether it can initiate the call or not. If it's just for email/ftp issues, then publication in a TXT record would be sufficient, as the sysop would have to make the manual configurations to control those transfers anyway. LS> Is email encapsulation still necessaty then? My personal worries LS> are SMTP encapsulation might give us more trouble than fun... I really think we ought to limit ourselves to protocols that directly involve the use of an FTN mailer. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #575 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 09:11:40 To : Rune Johansen 13 Oct 97 05:48:00 Subj : IP-connectivity ------------------------------------------------------------------------------- Rune Johansen said in a message to Denis McMahon: > OK, so both ftp and uucp are means of transferring pkt, arcmail, nodediffs, > fidonews. In that case, surely both ftp and uucp are carrier > protocols between ftn systems. RJ> They can be used as method of file transfer, but not as carriers of RJ> FTS-0001 mailer sessions, as they are not necessarily direct RJ> between the mailers/tossers/whatever. I think the important criteria that should be considered, is whether or not the Fidonet nodelist is required to be involved to make the connection. My ftp transfers to PAOnline are done with FTP and all of the Fidonet 'node' related information is coded and handled internally to FIFTP -- it does not need a nodelist to transfer mail to/from my node and 1:270/101. Therefore, I would think that ftp is not a justifiable candidate for nodelist inclusion. As for uucp, the only thing one needs for that is the telno of the uucp modem (unless one is doing uucp over ip, to which I ask WHY?). The mailer(s) will handle "drop to external protocols" to handle the uucp transfers, and as far as the mailer is concerned, a telephone number is a telephone number. As long as the mailer is smart enough to exit to uucp when the other end answers and says "Hi I'm a uucp node, not an FTS-0001/EMSI node", I see no reason for any special listings for uucp nodes, except perhaps an authorized modem flag. Likewise, aren't SMTP tranfers managed by software completely external to the mailer? And as such, what would be the significance of any SMTP information in the nodelist, except to benefit a -human- reading the source listing? As I'm seeing it, VModem, BinkD, IFCico and any other IP tranfer methodologies that require a direct interaction with the Fido mailer are the only ones that -need- to be included in the nodelist. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #576 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 09:14:46 To : Steve Woodmore 13 Oct 97 05:48:00 Subj : IP-connectivity ------------------------------------------------------------------------------- Steve Woodmore said in a message to Pedro Lima: SW>> The IP address is mine, and you can send email to it at any time PL> I thought an e-mail in the form user@[aaa.bbb.ccc.ddd] would be PL> directed to port 25 of the machine at aaa.bbb.ccc.ddd, but maybe PL> it isn't as simple as that. SW> yes it is as simple as that or it isn't, any emails for me get held SW> at mail.demon.co.uk until I log on and collect them. SW> Like I say you can email me 24hrs, but only connect to me if I am SW> online. Actually, Steve, if one tries to send email direct to the IP address, as in steve@[aaa.bbb.ccc.ddd], the mail will only be delivered when your SMTPD is actually able to answer on port 25. Otherwise the mail is held in the -SENDER's- queue, until delivery is possible. The only way to get mail to be 'routed' through mail.demon.co.uk, is if they have a DNS entry with an MX record that the mail has been addressed to. And last I heard, I'm not aware of any way to associate an MX record to a physical IP address, unless some form of DNS naming is also associated with that IP address. Do you have a mail address established @mail.demon.co.uk? Perhaps this is how mail is being 'relayed' through that system? --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #577 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 09:44:20 To : Ward Dossche 13 Oct 97 05:48:00 Subj : IP-connectivity ------------------------------------------------------------------------------- Ward Dossche said in a message to Pedro Lima: > WD> Changing FTS-0001 would be fine ... but someone has a copyright on > WD> it and changing the text is forbidden via that same > WD> copyright-statement. > Is the reference 'FTS-0001' copyrighted? WD> Yes. You cannot copyright a document title, nor can you copyright a filename. You can only copyright the -presentation- of the information contained therein. In fact, even the -information- itself is not copyrighted, only the -presentation-. The contents of an FTS-0001 frame are public information and anybody with any writing skills should be able to write a 'new' document, describing the same frame format, and have it adopted as a 'new' Fidonet Technical Specification. And even if you could copyright the filename.. the FTS-xxxx.TXT format would be owned by the FTSC anyway, not the author of an FTSC approved document. At best the author could only claim copyright to the original FSC-xxxx.TXT filename that the document was submitted under. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #578 [1995] Rcv Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 11:24:40 To : Lothar Behet 13 Oct 97 05:48:00 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Lothar Behet said in a message to All: LB> Hello All! LB> The following should be met for an ip-capable entry in the LB> nodelist: >-8------------------------ byte here ------------------------8-< LB> 1. IP may be listed only as additional media type to normal pstn LB> connections LB> 2. the online time must be clearly stated, CM is preferred LB> 3. there must at least be one FTS-conformant protocol on this line LB> 4. additional protocols may be listed on the same line >-8------------------------ byte here ------------------------8-< Concur. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #579 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 11:26:22 To : Lech Szychowski 13 Oct 97 05:48:00 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Lech Szychowski said in a message to Lothar Behet: > 1. IP may be listed only as additional media type to normal pstn > connections LS> Then no IP-only nodes? Personally I like this idea, but at the same LS> time I see there is a "common understanding" such nodes should be LS> allowed. What about listing them as Pvt? I know it violates rules a LS> bit, but solves compatibility problems; probably this solution is LS> as good and as bad as putting -Unpublished- in the phone filed... I think the core of this issue gets back to MAKENL. I don't think MAKENL will permit -Unpublished- in the telno field unless it is also declared as a PVT node. If that's the case, we don't really have any choice. But I would think a PVT IP-only node would be acceptable. > 3. there must at least be one FTS-conformant protocol on this line LS> If the system is to qualify for a Fidonet node (PSTN aka LS> traditional one; I think that was your idea behind 1. above) there LS> is no need to add this requirement. I took it to mean a requirement that the IP-node be able to negotiate an FTS-0001 or FTS-0006 mailer session. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #580 [1995] Scn From : rafal wiosna 2:480/33 11 Oct 97 12:29:12 To : Denis McMahon 13 Oct 97 05:48:00 Subj : SMTP/FTP - QWK of the internet ------------------------------------------------------------------------------- þ (IP_CONNECT, Tue Oct 07 1997) Denis McMahon -> All: DM> FTP DM> SMTP/UUEnc DM> SMTP/Base64 IMHO those methods are not valid for Fido use. I'm not saying that you cannot use them to transfer ARCmail/netmail. But don't you think that if they were valid we'd use QWK for inter-node mail exhange?!?! I think NOT. - Rafa’ "WXR" WiOS/2na. --- GoldED/2 2.51.A1026+ 30PL2 * Origin: I see disaster. I see catastrophe. Worse, I see lawyers! (2:480/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #581 [1995] Scn From : Kim Heino 2:222/0 11 Oct 97 16:22:08 To : Rune Johansen 13 Oct 97 05:48:00 Subj : Some comments... ------------------------------------------------------------------------------- >> Software called nlmake can handle ip's/fqdn's in phone-field and it's even >> config-file compatible with makenl. > Which operating systems are the nlmake available for? I don't know, I have only os/2-binaries here (nlmake13.zip). The only thing I understood from the German docs was the authors contact info: > 21:491/1018@gernet > 81:449/6709@os2net > 142:102/1@sfnet > 256:4915/309@mxbbsnet (subject to change) > +49-6034-1455 V.32bis, V.42bis, V.fc, V.34 > +49-6034-930022 X.75, V.110 ISDNB, ISDNC > > ths@texbox.lahn.de > thomas.seeling@math.uni-giessen.de --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #582 [1995] Scn From : Rune Johansen 2:210/20 10 Oct 97 21:53:16 To : Kim Heino 13 Oct 97 05:48:00 Subj : Some comments... ------------------------------------------------------------------------------- >> and new makenl. Old softwares may not prevent new features! > Software called nlmake can handle ip's/fqdn's in phone-field and it's even > config-file compatible with makenl. Which operating systems are the nlmake available for? Is the sources available? > Next fastlist (or whatever it was...) should also support them. So the > software should not be a problem. Ok, then we have a replacement for Makenl. Now we have to adjust the FTS-0005 a little to make it more flexible in the characters that can be used in the different fields of the nodelist. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #583 [1995] Scn From : Chris Maddock 3:640/302 12 Oct 97 18:52:18 To : Pedro Lima 13 Oct 97 05:48:00 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- On 09 Oct at 12:41, Pedro Lima of 2:362/21 wrote to Chris Maddock: PL> Hello, CM>> They are a four digit number with the format 00xx CM>> i.e. 0011 CM>> To call you, I would dial 0019 351 1 886 2878. PL> If I understood correctly, you have different international access PL> prefixes according to the destination? Anyway, to what would your PL> nodelist compiler translate a nodelisted '000-'? Depends on what I tell it to do. I use Fastlst. I've thought about this at some length and I can see solutions that are needed. 1. A special character or sequence tha signifies a IP node or whatever, and translates the number (or some other field). The "Baud_Rate" field could do this easily ? It sure isn't used much for much else 'cept ISDN nodes. 2. Flags. A series of flags to indicate that a node is IP (or whatever) capable. 3. Routing. Some indication is required to indicate how to route the mail to the node and the Internet is not always going to be the only alternative. This particulary applies to crash-mail. 4. Nodelist compilers. We are going to need to convince the nodelist compiler and nodelist generator authors to make changes, but we are going to need to be able to say =exactly= what changes are required. 5. It has to be as simple as possible. It's no point making a system that becomes so complicated that any changes made in the future break it. 6. We may even have to look at a different type of nodelist - binary perhaps ? Something that could be run in parallel with the existing nodelist, only for IP nodes perhaps ? This would make any expansion into different technology much easier in the future and not break what we currently have. As far as 6. is concerned, we could even use the current nodelist to provide an index into the parallel nodelist ! Regards, Chris Maddock chrism@bbs.st.net.au --- Msged/386 4.20 beta 2 * Origin: Diagnostic CBBS - DownUnder - (3:640/302) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #584 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 11:20:08 To : Max Masyutin 13 Oct 97 05:48:00 Subj : The Real FidoNet Physical Layer (JFYI) ------------------------------------------------------------------------------- Max Masyutin said in a message to All: MM> === cut === MM> H. Physical Layer : the Actual Connection of Two FidoNet Systems MM> Will one of the more hardware-oriented comm types give me some MM> idea of what's needed here? Can we leave it open enough to allow MM> implementation over a non-dial net? Thanks. MM> === cut === Well... I guess that resolves any potential issues with -that- controversy! Thanks, Max! --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #585 [1995] Scn From : Lech Szychowski 2:480/33.7 12 Oct 97 01:45:00 To : Slava Filimonov 13 Oct 97 05:48:00 Subj : IP-access ------------------------------------------------------------------------------- >>> btw, and why do they start to use HTTP protocol, if UUCP were so good ? > LS> In short: UUCP is in some respects too/unnecessarily complicated, [...] > That's what i thought - UUCP is too/unnecessarily complicated for fido. Nope, I don't think so. Remeber we were talking about WWW servers, not about mail and file transfers - and these transfers are just exactly what UUCP was created for. I'm not trying to say we have to adopt UUCP. I'm trying to say that adopting FTP and SMTP is not the right way to go, especially if at the same time we exclude UUCP. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #586 [1995] Scn From : Lech Szychowski 2:480/33.7 11 Oct 97 03:01:00 To : Steve Woodmore 13 Oct 97 05:48:00 Subj : IP-connectivity ------------------------------------------------------------------------------- > LS> afraid if we follow your idea we are just a step away from stating > LS> that if I agree to do my best to carry packets on floppies to a > LS> friend of mine, he can be a Fidonet node :( > Only if you are FTSC001 compliant during ZMH Well, suppose I am. The only problem is no one can call me, but since that's the same as with IP nodes, then... then we have a problem if we want to be consistent. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #587 [1995] Scn From : Sean Rima 2:252/356 11 Oct 97 00:48:00 To : Mario Mure' 13 Oct 97 05:48:14 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hi Mario, On Stardate <9710.09>, you wrote me: MM> In a message dated < 07 Oct 97 22:59:00 >, addressed to Mario Mure' MM> about < Re: IMPORTANT! standard of protocol for ip-nodes proposal. >>, Sean Rima wrote: MM>>> My vote for binkp ;-) I'm testing BinkD on MM>>> agnese.fidoitalia.net [195.120.19.166] and it works great !!! SR>> Is that a full time link? MM> Yes, it is. Fidonet node 2:33/505 and 2:2/3008 starting from the next MM> nodelist. But beware, there's only a CDA so from some "location" (in MM> internet sense, not geographical) it could be very slow... Okay, I will put a link in from mine anyway. So ecpect a mail in a day or so ;-) Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: Modem Police...we clocked you at over 3300 cps. (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #588 [1995] Scn From : Slava Filimonov 2:469/33 11 Oct 97 13:33:26 To : Fausto Carvalho 13 Oct 97 05:48:14 Subj : About DNS-based solution ------------------------------------------------------------------------------- Hello Fausto! 09 Oct 97 20:50, Fausto Carvalho wrote to All: FC> Maybe some of you are not aware of that, but during last year at FC> least twice we had a giant colapse for days in the Internet, because FC> of DNS problems. Fidonet (as now) can survive for weeks, months, FC> without Nodelist updates. Any DNS-based network will stop in few FC> hours... I'm sure, Binkd still have both DNS-based resolution and fixed IP list. ( it depends on what you write in address field ). DNS-based routing is expected in future versions. -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #589 [1995] Scn From : Nick Soveiko 2:5030/23.101 10 Oct 97 17:44:08 To : Rune Johansen 13 Oct 97 05:48:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thu, 09 Oct 1997, 01:06, Rune Johansen (2:210/20) ==> Marco d'Itri: RJ> What terminal software makes it possible for a _person_ to log into RJ> a BBS system that is lying behind a fidonet mailer, via the BinkP RJ> protocol? BinkP is a mailer-session-only protocol, and cannot (as RJ> far as I have read the specs) be used for anything else. But, in a RJ> telnet session you can run BinkP as transfer protocol instead of RJ> ZModem. You can run BinkP handshaking instead of EMSI. You can even RJ> use Telix with IEMSI script via vmodem-like software. rude, you misunderstand what i've said before. in pstn worl you are *forced* to use a mailer as your bbs frontend, otherwise you have your communication port (com port in this case) serving only one purpose (either mailer or bbs). if your system is ip-capable, you have plenty of ports to offer for connection to *different services*. you can have port 23 for your bbs and ports 3141, 24554 and 60179 (for example) for different mailers. RJ> BinkP is a truly fast and efficient protocol, but it limits itself RJ> too much for future expansion and use, to be taken in as minimum RJ> common protocol. you haven't read binkp description. there are *plenty* of possibilities for extension. RJ> Telnet is a protocol that creates a reliable (TCP) session between RJ> two hosts. Then you can run whatever your heart desires on top of RJ> that. don't see any contradiction. binkp can run on top of any transport that provides a bidirectional reliable connection. this can be raw tcp/ip, telnet, lap-m, lap-d, x.25, frame relay, you name it... cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #590 [1995] Scn From : Nick Soveiko 2:5030/23.101 10 Oct 97 17:48:00 To : Lech Szychowski 13 Oct 97 05:48:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thu, 09 Oct 1997, 03:35, Lech Szychowski (2:480/33.7) ==> Slava Filimonov: > As long as you use BINK-style outboud, LS> This assertion often fails. A lot of people does not have it. For LS> example, my home system has never used one. patrice boucher from montreal (1:167/323) was running binkd together with his frondoor, which is an arcmail attach mailer. binkd also supports fileboxes. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #591 [1995] Scn From : Nick Soveiko 2:5030/23.101 10 Oct 97 22:43:02 To : Fausto Carvalho 13 Oct 97 05:48:14 Subj : About DNS-based solution ------------------------------------------------------------------------------- Thu, 09 Oct 1997, 20:50, Fausto Carvalho (2:361/7) ==> All: FC> Maybe some of you are not aware of that, but during last year at FC> least twice we had a giant colapse for days in the Internet, FC> because of DNS problems. FC> Fidonet (as now) can survive for weeks, months, without Nodelist FC> updates. Any DNS-based network will stop in few hours... FC> I'd also like to stress that one of the key features of Fidonet is FC> to allow one to one communication without depending on somebody FC> else. -FC- you can not communicate independently as you still depend on the nodelist and timely availability of correct updates. we've seen evidence as technical glitches in nodelist creation led to whole networks being accidentally dropped from it. many nodes compile nodediffs in automatic mode, this leading to dropped nodes being unreacheble both by direct and routed netmail. no technology is guaranteed from such disasters. my point he is that we can use dns for daily needs and resort to other sources (nodelist, explicit overrides for permanent links) in case of troubles with the former. that's apart from the question of nodelist update turnaround, which is 1 week in best possible case and typically takes 2-3 weeks. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #592 [1995] Scn From : Lawrence Garvin 1:106/6018 11 Oct 97 17:29:26 To : Lech Szychowski 13 Oct 97 05:48:14 Subj : IP-access ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Lech Szychowski said in a message to Lawrence Garvin: > LS> problem can be partially solved by creating more DDNS servers > LS> servicing a smaller number of nodes; > Definitely! Although I suspect you meant more DNS servers, not more > DDNS servers. No? LS> If we are to have "FQDN -> dynamically assigned IP" database that LS> really works, all regional/netional DNS servers will have to be LS> DDNS servers as well. At least I fail to see another solution. Well, I'm not so sure that we ought to be worrying about dynamically assigned IP nodes. Although that's not to preclude their use by nodes, only that the responsibility for correlating the DDNS and the dynamic IP node should be the responsibility of that node's ISP, not Fidonet or the hostmaster of any of the fidonet.* DNS zones. If properly done, the DDNS and dynamic Ip addressing should be totally invisible to Fidonet. LS> Absolutely. I think when I wrote it we had no participants from LS> outside Z2 here, but now things have - fortunately - changed :) Glad to be welcomed. I'm surprised, and disappointed, though, at the lack of Zone 1 participation to date. Perhaps that will change, also. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #593 [1995] Scn From : Lawrence Garvin 1:106/6018 11 Oct 97 23:00:12 To : Tobias Ernst 13 Oct 97 05:48:14 Subj : IP-access ------------------------------------------------------------------------------- Tobias Ernst said in a message to Ask Bjoern Hansen: ABH> in the routing, if some central routing point crashes you can ABH> still receive mail directly from any TCP/IP-able node. TE> Well, this just shifts to the point that a crash of the DNS TE> computer will stop any traffic in the whole Z2. ;-). One presumes that there are more than one computer providing DNS services for the z2.fidonet.org zone? :) TE> We should maintain more than one DNS computer, on the one hand for TE> backup purposes, on the other hand to reduce traffic for each TE> individual one. Ideally, each region in each zone would have the region dns delegated to somebody within the region, and the region dns server would act as a secondary to the zone dns server. It should also be an option to nets within each region to have their net dns delegated to a net dns server, although I suspect for the near future there won't be enough utilization at the net level to justify a delegated zone a the net level. Another option that regions might consider pursuing is registration of FIDONET.XX in each region where the domain is the country-level domain, such as FIDONET.UK, FIDONET.DE, FIDONET.FR, FIDONET.PL, etc. Unfortunately, in the U.S. this opportunity is not available because the University of Southern California, who manages the .US domain, is only issuing (STATE).US names -- although I suppose it wouldn't hurt to try and register FIDONET.US The worst that could happen is they'd say no. FIDONET.CA is available in Canada, though. Of course in this case, there's no easy way to tie the node number back to the domain, but it does open up a whole new tablet of domain names available to fidonet nodes. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #594 [1995] Scn From : Lawrence Garvin 1:106/6018 11 Oct 97 17:20:46 To : Lech Szychowski 13 Oct 97 05:48:14 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Lawrence Garvin: > LS> possible solution. Although I have to admit that I don't remember > LS> what RFCs say about minimal TTL (if this issue is dealt with at all). > Minimum TTL is recommended to be at least one hour. LS> Is it a recommendation or a requirement? To the best of my knowledge, Lech, I believe it is a recommendation. At least nobody's shut my delegation down for defining mine at one day. LS> I can see very well why such a recommendation is given (for the LS> very same reasons we have mentioned as disadvantages when talking LS> about dynamic DNS), but if it is just a recommendation... :) True. I also try to put a day's advance warning into the system when I'm about to make significant changes to multiple nodes, by reducing the TTL from one day to one hour; then make the changes, which guarantees updates within the immediate future; then change the TTL back to one day. Why force DNS servers to query for static information when you know it's going to be static? LS> I know that. That's the reason why I think delegating LS> regional/netional subdomains is a must. And I've been naturally assuming that's exactly what would happen. I think it totally impractical for an entire Fidonet Zone to be maintained in a single DNS Zone. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #595 [1995] Scn From : Lawrence Garvin 1:106/6018 11 Oct 97 22:55:44 To : Tobias Ernst 13 Oct 97 05:48:14 Subj : IP-access ------------------------------------------------------------------------------- Tobias Ernst said in a message to Ask Bjoern Hansen: TE> Hallo Ask! ABH>Hub,4000,Hub_Weissenhorn,Weissenhorn,Alto_Speckhardt,49-7309-7270,9600, ABH> ,CM,XA,VFC,V34,V42B,U,V110L,V110H,V120L,V120H,X75,IFC ABH> telling you accept IFC calls (default port 60179). There is no ABH> IP address told, but as you are 2:2487/4000 --> ABH> f4000.n2487.z2.fidonet.org then search it on DNS. TE> This would require every existing mailer to be rewritten in a way TE> to support IP-flags and to calculate the FQDN out of the node TE> number. Not necessarily true, Tobias. One solution, although not as dynamic as would be most ideal is for a nodelist compiler to recognize the appropriate flags in the flags field (a capability that already exists), and implement an option to 'build' the DNS name and do a lookup immediately, and then store the returned value in the compiled nodelist in aaa*bbb*ccc*ddd format, which -can- be read and processed by existing mailers. Remember, the limitations on storing the IP address in the nodelist are a function of MAKENL, not a function of the mailers we're currently using. Alternatively, the more usable option would be for the mailer to dynamically translate the node number to the DNS address, do the DNS lookup, and place the call to the returned A record. With the work currently going on with the Bink XR* mailers, it shouldn't be too difficult to find somebody who's already written additions for the XR* product to add a subsystem to the mailer that would perform this chore. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #596 [1995] Scn From : Lawrence Garvin 1:106/6018 11 Oct 97 22:37:00 To : Ward Dossche 13 Oct 97 05:48:16 Subj : IP-connectivity ------------------------------------------------------------------------------- Ward Dossche said in a message to Lech Szychowski: > Certainly. Policy4 never addressed issues we are discussing right now > because at the time it was created such issues were well beyond the > scope of interest and/or imagination. Time passes fast, technology > advances even faster and we just have to either write an amendment > to P4 or... (I wouldn't dare mentioning the alternative option). WD> Changing FTS-0001 would be fine ... but someone has a copyright on WD> it and changing the text is forbidden via that same WD> copyright-statement. While the -content- of the document may be protected, it's also worth noting that the -title- of a document is generally not part of that protection, and there's nothing preventing a properly recognized and authorized FTSC from reissuing a whole new document called "FTS-0001.TXT" Besides... when did claimed copyrights stop you from changing a document, Ward? --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #597 [1995] Scn From : Lawrence Garvin 1:106/6018 11 Oct 97 17:32:36 To : Lech Szychowski 13 Oct 97 05:48:16 Subj : IP-connectivity ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Lech Szychowski said in a message to Lawrence Garvin: > Therefore, I support the concept that only full-time, permanently > connected, IP-dialable nodes are at issue for nodelist inclusion. LS> If we are to consider IP-only nodes as something that should be LS> realtively rare and used mainly for the purpose of making long LS> distance bulk quantities mail transfers, I second your opinion. But LS> more flexibility wouldn't hurt, and having something like ZMH LS> (actually not necessarily common, one given with T flags in the LS> nodelist entry would do) would IMHO be OK. My point, Lech, is that I would be hesitant to support IP nodelisting for any node that is maintaining their system via a dialup PPP link. Such a listing is very unstable, doesn't guarantee availability of the node, and makes no provisions for autoconnect if the -node- has dropped the connection to their ISP. I would think, as a minimum, a dedicated IDSN link to a provider, or FrameRelay, T-whatever, or other such 'permanent' link that can answer a ping 24 hours a day, without dependence on a volatile dialup connection. Otherwise, I suspect we're likely to see a high incidence of 'node not available' responses from those listed with dialup IP nodes, simply due to the inherent unreliability of PSTN connectivity. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #598 [1995] Scn From : Lawrence Garvin 1:106/6018 11 Oct 97 22:27:56 To : Lech Szychowski 13 Oct 97 05:48:16 Subj : IP-connectivity ------------------------------------------------------------------------------- Lech Szychowski said in a message to Pedro Lima: > denying the possibility of a connection, since AFAIK, it's not possible > to send e-mail to a disconnected IP address. :-) LS> IP address? No. There are MX records, but I have yet to see MTA LS> trying to query DNS for an MX record of an *.in-addr.arpa. entity LS> :) Lech, if the sendmail.cf, or other MTA configs, were properly configured, it is possible to recognize and process mail addressed to an actual IP address. In such cases the MTA would bypass the normal DNS steps, and simply transport the message. However, I believe that such capabilities are the exceptions, not the norm, and I, for one, am not aware of any provisions in my two sendmail based systems, or my SCO MMDF based systems, to accept mail addressed to an IP address (e.g. lawrence@198.216.62.42). The receiving MTA, in many cases, particularly MMDF, expects to see a DNS resolvable address in the addressee field. Furthermore, it also requires that the sending system be reverse mapped in in-addr.arpa, or it will refuse the inbound connection. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #599 [1995] Scn From : Anatoli Gulidov 2:5020/388.1 09 Oct 97 22:44:48 To : Fyodor Ustinov 13 Oct 97 05:48:16 Subj : IP-connectivity ------------------------------------------------------------------------------- HELLO, Fyodor! 07 Oct 97 09:48, Fyodor Ustinov (2:5020/79) wrote to maciej grzeszczuk: FU> Where _any_ vmodem for Win32? Freq C95V102.* from my node. CHAO, Anatoli. ------------------------------------------------------(09 Oct 97 22:44) --- GEcho 1.11+ * Origin: http://members.wbs.net/homepages/a/n/h/anhtung.html (2:5020/388.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #600 [1995] Rcv Scn From : Nick Soveiko 2:5030/23.101 10 Oct 97 17:42:36 To : Lothar Behet 13 Oct 97 05:48:16 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Wed, 08 Oct 1997, 23:09, Lothar Behet (2:2446/301) ==> All: >-8------------------------ byte here ------------------------8-< LB> 1. IP may be listed only as additional media type to normal pstn LB> connections LB> 2. the online time must be clearly stated, CM is preferred LB> 3. there must at least be one FTS-conformant protocol on this line LB> 4. additional protocols may be listed on the same line >-8------------------------ byte here ------------------------8-< LB> Explanation: LB> 1. is self-explanatory: LB> There are no IP-only nodes in the nodelist. [] LB> 3. As FTS-001 is another basic condition for listing as node, LB> at least one protocol must be capable for a direct mailer to LB> mailer session. LB> I do not state any special protocol as required, because LB> several are in use widely and many systems can even support LB> different protocols listed on the same line. These may (and i LB> hope, normally they will) perform the duty as relay between LB> different protocols, if required. [] LB> Please correct me, if i have overseen something important, but i LB> hope, that these basics will be honored, before ip-nodes will be LB> listed beside the few test-nodes. paragraph 1 your proposal seem to me to be not so obvious. if a node supports fts-0001, it does not matter over which kind of transport layer this protocol is implemented (as somebody pointed out here). the only requirement one may leave to support the concept of universal connectivity is that a node non-capable of pstn connection (and i mean pots, not isdn or something else as fancy) should be listed under pstn-capable host and/or hub entry. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #601 [1995] Scn From : Lawrence Garvin 1:106/6018 11 Oct 97 22:32:02 To : Lech Szychowski 13 Oct 97 05:48:16 Subj : Why IP? ------------------------------------------------------------------------------- Lech Szychowski said in a message to Marco d'Itri: > - I can change the IP of my node and then reload the zone of my domain, > but if the nodelist has my IP I will be unreachable for some days LS> So would you if you were to change your phonenumber in between the LS> days nodelist is issued, right? The difference being that if one knows reasonably well in advance that they will be changing their DNS/IP mappings, the TTL can be set excruicatingly short so that when the change is actually installed, the time lag before worldwide update will be insignificant. Such is the advantage to one hour TTLs. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #602 [1995] Scn From : Ger Vloothuis 3:633/284 11 Oct 97 14:49:42 To : Denis McMahon 13 Oct 97 05:48:16 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hi Denis, Denis McMahon wrote in a message to Rune Johansen: DM> services. Does 0011-000 (Telstra) or 10011-000 (Optus) call DM> emergency services in Australia? Neither does. Both will produce a voice recorded message to say that the dialled number is invalid. BTW, the Optus prefix is no longer '1'. It is now '1456' Regards Ger --- WtrGate v0.93.p1 Unreg * Origin: Teletechnique Melbourne (3:633/284) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #603 [1995] Scn From : Ger Vloothuis 3:633/284 11 Oct 97 13:31:32 To : Pedro Lima 13 Oct 97 05:48:16 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hi Pedro, Pedro Lima wrote in a message to Ger Vloothuis: PL> It's quite likely that if Australia is moving to an '00' PL> international access code it will change the emergency number, as PL> it would be very easy to mistakenly dial '000' instead of '00'. PL> This means that the invalid '000' prefix is likely to be a good PL> choice for our purposes. It is unlikely to do any harm today. What it does tomorrow is a problem for another day, isn't it Pedro? Regards Ger --- WtrGate v0.93.p1 Unreg * Origin: Teletechnique Melbourne (3:633/284) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #604 [1995] Snt Loc Scn From : Lothar Behet 2:2446/300 13 Oct 97 08:46:18 To : maciej grzeszczuk Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello maciej! On 10 Oct 97 wrote maciej grzeszczuk to Lothar Behet: mg> sure. and binkd (binkp) isn't such standard. it's only supported by mg> small (2 i heard, third is under construction) number of mailers. BinkD itself is available for any pc-based operating systems except DOS and in compiled versions for different unices and linux. Furthermore the source is publicly available. As the protcol specufication is public, it is (and will be supported by more) other programs. It is not my intentipn to define one single program or protocol as fido-compliant, but offer ip-access as additional medium for a maximum number of nodes. Regards. Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/300) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #605 [1995] Snt Loc Scn From : Lothar Behet 2:2446/300 13 Oct 97 09:25:18 To : Lech Szychowski Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Lech! On 12 Oct 97 wrote Lech Szychowski to Lothar Behet: [... some stuff deleted ...] >> Do you really need more than one _fqdn_ to handle several protocols >> on different ports on several computers? [... some stuff deleted ...] LS> IMHO you are wrong. My system is reachable from the Internet as three LS> IP addresses - and the reason behind it is it has three different LS> physical links from different ISPs, for sake of redundancy and LS> reliability. And I think it really makes sense to have all the LS> IP addresses listed, to provide as much connectivity as possible. [... some stuff deleted ...] LS> But if it is one multi-homed system? Then it makes sense. If take a close look into the nodelist, than you will see, that there i.e. systems operated via ISDN-lines (with numbers in direct order), who "need" a nodelist entry for each line. With fqdn the machines in a subnet (same domain) can be addressed in one entry, as long as the protocols and other flags are equivalent. With a wisely choosen nodelist standard the ip-lines can be listed in the same entry as normal pstn lines, to keep the nodelist at on affordable size for each sysop. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/300) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #606 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Oct 97 13:53:44 To : All 13 Oct 97 18:10:14 Subj : Not on Zone 1 Backbone! ------------------------------------------------------------------------------- Hello All! I just discovered why there's no Zone 1 traffic in this echo -- seems that IP_CONNECT is not being distributed by our friends the "North American Backbone", and is only available to downlinks of PAOnline. Perhaps it's time to get this thing in Zonewide distribution. Or... I can send it up to the FidoSpine right now, without any of the malarky associated with the NAB -- and it will get -some- distribution. Who's in charge anyway? :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #607 [1995] Scn From : Manfred Schramm 2:2446/500 13 Oct 97 17:56:50 To : Frank Ellermann 13 Oct 97 19:57:26 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Moin moin Frank, LB> 1. IP may be listed only as additional media type to normal pstn LB> connections FE> [...] LB> Please correct me, if i have overseen something important, but i LB> hope, that these basics will be honored [...] FE> Actually I don't agree with your 1st rule, how about this formula: LB> 1. IP only nodes may be listed only in a region (or nets) reserved LB> for this purpose. I think this is half the way forward plus one step back to a convenient solution of the needs of fidonet and the needs of integration. Gruesse aus dem schoenen Wesel, Manfred. --- * Origin: (2:2446/500@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #608 [1995] Scn From : Sean Rima 2:252/358 12 Oct 97 12:19:00 To : Slava Filimonov 14 Oct 97 05:39:06 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hiya, Slava! At 10 Oct 97 10:40:28, Slava Filimonov wrote to maciej grzeszczuk: mg>> i said that we should specify one standard, available at every ip-node mg>> system. and i proposed vmodem. mg>> i don't say that we shouldn't include binkd nodes in a nodelist, but mg>> they should also support vmodem connections - some kind of fst-0001 mg>> for ip-nodes. SF> We can't set vmodem as a standart protocol for ip session, cause it's SF> based on SF> non-free software. We should use binkd as a standart, which is free and SF> protocol spec is avail, and vmodem as option. I agree. The specs as you say for BinkP are freely available. BinkD itself is part of the GNU licence. Considering the cost to most people of getting either a direct connection or a Unix shell account with a minimum of 100mb of HD space, then I think most people will go for FREE. Sean Rima Sysop DSP BBS and Ipmailer --- QDED alpha v3.57pl8/ FreeBSD * Origin: DSP BBS Ipmailer Reading England (2:252/358) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #609 [1995] Scn From : Denis McMahon 2:251/20 11 Oct 97 10:18:44 To : Pedro Lima 14 Oct 97 05:39:06 Subj : A bit of steering ... ------------------------------------------------------------------------------- Pedro Lima wrote to Lothar Behet: PL> Temptative. But if the problem is MakeNL, all we have to do is PL> replace it, which should be a fairly simple thing to do. Will you have a replacement coded by next week then? :-) If nyone hd the source code, or was in touch with Ben B and it's still available, maybe we can recode makenl to do what we want, but until we know what we want we can't do it, and we my have to start from "void main(void){}" Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #610 [1995] Scn From : Yuri Teterin 2:5030/239 12 Oct 97 21:26:16 To : Maciej Grzeszczuk 14 Oct 97 05:39:06 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello, Maciej ! Thu Oct 09 1997 maciej grzeszczuk writes to Denis McMahon: >> Vmodem >> Telnet mg> that's the same protocol. No. VModem as protocol has nothing in common with telnet. VMOTelnet - has, but this is only one of possible _realizations_ of FTN_over_telnet sessions, and there is really no _standards_ for such realizations. >> BinkP >> BinkD mg> what are the differences between the last two? BinkP is a protocol, BinkD - a mailer which use BinkP. >> IFCICO Once more, ifcico is a mailer, and not a protocol. The only ifcico-speciffic protocol is its 'raw TCP protocol', which can be considered as an alternative realization of FTN_over_telnet sessions. >> FTP >> UUCP >> SMTP/UUEnc >> SMTP/Base64 mg> i disagree. we shouldn't treat ftp or other internet services as a valid mg> fidonet transport. We could, but not internet services themselves, but some standartizited ways of using them in FTN-technology (so these should be really _new_ protocoles, based on mentioned internet services). And, of cause, there should be enough fido-nodes using these protocols. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #611 [1995] Scn From : Yuri Teterin 2:5030/239 12 Oct 97 22:34:22 To : Maciej Grzeszczuk 14 Oct 97 05:39:06 Subj : binkd vs vmodem ------------------------------------------------------------------------------- Hello, Maciej ! Thu Oct 09 1997 maciej grzeszczuk writes to Igor Bilyi: >> mg> vmodem is supported on all software / hardware platforms. >> floppynet is supported on all software / hardware platforms. mg> with such argumentation we'll go nowhere. you act like a 10 years old kid. Just like you do. As the matter of facts, there are two different protocols, used in SIO+vmodem: vmodem itself and VMOTelnet. As to vmodem - there is no _free_ realization of it on _some_ platform. As to VMOTelnet - there is only one free realization of it, only for Unix and only as a part of ifcico (there is vmotelnet in Argus too, but I am not sure it is 100% free). >> vmodem is 2-3x slower than binkd, want to try? i'm ready mg> if you can connect with your binkd to my vmodem / ifcico / telnet mg> compatible mailers (listening on ports 60177 and 60179 of mg> zwieracz.psych.uw.edu.pl)... Your mailer (ifcico 2.9) is _not_ vmodem-compatible (if you speak about protocol). Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #612 [1995] Scn From : Igor Bilyi 2:421/45.5 11 Oct 97 21:21:00 To : maciej grzeszczuk 14 Oct 97 05:39:06 Subj : binkd vs vmodem ------------------------------------------------------------------------------- Hi maciej ! >> mg> vmodem is supported on all software / hardware platforms. it's your argumentation and it's wrong >> floppynet is supported on all software / hardware platforms. and it's my argumentation and it's true mg> with such argumentation we'll go nowhere. mg> you act like a 10 years old kid. see yourself >> vmodem is 2-3x slower than binkd, want to try? i'm ready mg> if you can connect with your binkd to my vmodem / ifcico / telnet mg> compatible mailers (listening on ports 60177 and 60179 of mg> zwieracz.psych.uw.edu.pl)... ok, I'l try to send to you binkd091.zip mg> 492 -i- --- FMail/386 1.02 * Origin: * COMplete development station (2:421/45.5) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #613 [1995] Scn From : Denis McMahon 2:251/20 11 Oct 97 10:13:14 To : Amir Shabashvili 14 Oct 97 05:39:06 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Amir Shabashvili wrote to Denis McMahon: DM> a) IP address in telno field behind non-country-code DM> b) IP address or hostname in systemname field DM> c) IP address or hostname in flags field DM> d) DNS translation of f*.n*.z*.fidonet.org address AS> The better way, IMHO, is got all info about protocol,... from DNS AS> requests, only thing we are really need in nodelist is a first and AS> last name of person and fido address. So I vote to IP nodelist, AS> different from usial one, for all IP nodes, and AS> IP address in flag field for nodes with both PSTN and IP. Hey Amir, you don't want to communicate with non FTS-0001 nodes, fine. There's a lot who do, and a lot who think that 1989 policy and procedure is out of date in 2000. We're trying to develop a strategy in here that will allow the incorporation of new technology to fidonet. There's no place in this echo for anyone who doesn't agree with the incorporation of new technology, becaue this isn't where we debate "can we / should we", but "how can we". Take the "can we / should we" debate elsewhere! Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #614 [1995] Scn From : Denis McMahon 2:251/20 11 Oct 97 10:39:26 To : Rune Johansen 14 Oct 97 05:39:06 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Rune Johansen wrote to Denis McMahon: > Our objective, surely, is to find a way to increase FTN connectivity > principally using TCP/IP techniques, but taking "other" non analogue > technologies into account as well. RJ> You message summarizes up most of it. Good work. Thanks. I just wish we could get rid of the "no ip" lamers - they're in the wrong echo. The charter for this echo was how to do it, not whether to do it! :-) Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #615 [1995] Scn From : Yuri Teterin 2:5030/239 12 Oct 97 20:30:08 To : Maciej Grzeszczuk 14 Oct 97 05:39:06 Subj : BinkD (Was: IP-connectivity) ------------------------------------------------------------------------------- Hello, Maciej ! Thu Oct 09 1997 maciej grzeszczuk writes to Eugene Gladchenko: >> Did you ever see binkd? If not please take a look. You will sure like it. >> It's so simple to use and very powerful all the same time. mg> i did. i prefer to use ifcico though. as it's compatible with everything. In your case "everything" means only ifcico itself, vmodem with VMOTelnet enabled (which is not allways true - there are Vmodem nodes without VMOTelnet) and Argus. BinkD is compatible with itself and Argus too. So I do not see real differences between ifcico and binkd from the point of view of compatibility. Moreother, at my node I use both binkd (for IP) and ifcico (for phone lines), but during last year I _nether_ need telnet capability of ifcico and only one of my IP-links prefer to connect with my ifcico (he use ifcico too). The same time I have about 70 regular binkp-links; some of them have ifcico too, but prefer to use binkp for IP-connections. mg> and binkd isn't. maybe binkd is powerfull, but it's useless, whenever mg> you want to connect to a typical yet ip node. A "typical IP node" in regions 50 and 46 is now binkp-node. And these two regions cover 30% of zone 2. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #616 [1995] Scn From : Sean Rima 2:252/358 12 Oct 97 12:38:50 To : rafal wiosna 14 Oct 97 05:39:06 Subj : BinkD - _NOT_ the standard ------------------------------------------------------------------------------- Hiya, rafal! At 11 Oct 97 12:30:04, rafal wiosna wrote to all: mg>> ifcico+vmodem mailers. remember that they all use the same protocol! mg>> and i bet that there is more of them than binkd. rw> That's not the point. The main reason why VMODEM/telnet should be rw> a standard [i.e. minimum IP-node requirement] is that old-style PSTN rw> mailers could be prepared to talk to other mailers via internet with rw> clever use of, for example, SIO/VMODEM under OS/2. EMSI Handshaking is amazingly slow over the net. X-Modem is totally unreliable as a standard on the Net. And don't forget the cost and size of Vmodem programs. I have only limited room on the HD that runs my BBS. rw> And on what platforms BinkD is available? OS2, All *NIX, FreeBSD (See my tagline) , Windows 95/NT and the source is freely available to be ported to other OS. and it can be built into existing mailers with very little work. Sean Rima Sysop DSP BBS and Ipmailer --- QDED alpha v3.57pl8/ FreeBSD * Origin: DSP BBS Ipmailer Reading England (2:252/358) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #617 [1995] Scn From : Sean Rima 2:252/358 12 Oct 97 12:31:04 To : maciej grzeszczuk 14 Oct 97 05:39:08 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hiya, maciej! At 10 Oct 97 14:23:33, maciej grzeszczuk wrote to Sean Rima: >> > if so, please tell me the location i can find the patch to my ifcico >> > mailer. >> I will try and find out the url for you. But I mean't the protocol BinkP. mg> i'll be very happy if you do. I am searching. My list of URLS is 35 pages long, that is only BBS related stuff. So it is slow going. >> > using emsi over tcp about 30-40 times a day, and haven't noticed any >> > problems >> > with slow handshaking, nor dropped connections. >> Umm, I did but then maybe it was me. mg> i know about 15 nodes around me using emsi over tcp, and they haven't mg> noticed mg> any problems also... >> I could not have a Telnet mailer operating on port 23 as I have to telnet >> into my shell account to read some mail. Also to start and stop both the >> mailer and tosser from time to time. mg> you can always set your telnetd or your mailer onto another port. it makes mg> no problem... And then you end up with different port numbers instead of standard ones. That alone would make the nodelist a mess. Sean Rima Sysop DSP BBS and Ipmailer --- QDED alpha v3.57pl8/ FreeBSD * Origin: DSP BBS Ipmailer Reading England (2:252/358) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #618 [1995] Scn From : Denis McMahon 2:251/20 11 Oct 97 10:23:56 To : Lech Szychowski 14 Oct 97 05:39:08 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Lech Szychowski wrote to Denis McMahon: LS> The answer to subject is if we are to allow IP-only nodes there LS> should to be the minimal set of protocols such a node is capable LS> of. > FTP > SMTP/UUEnc > SMTP/Base64 LS> I stand firmly against the above ones. Reasons: LS> - how do they deal with duplicated filenames? Sysops problem. Sysop has to take care of it. LS> - how do they deal with putting something on hold (ie transfrerring LS> to the calling party something which name this party has no way LS> of knowing about beforehand)? Where in Policy or FTS is it mandated that a node must be able to place mail on hold for another node? LS> - how do they deal with update requests? LS> - how does SMTP deal with file requests? LS> - how does SMTP deal with resuming failed transfers? LS> - how does SMTP deal with authorisation? Where in Policy or FTDS does it mandate that a system be capable of any of these these features? If these methods do not meet your requirements, you do not have to use them to communicate with the next node, however the fact that they do not meet your requirements does not mean they are invalid as means of transferring fts-1 encapsulated message packets. Instead of trying to restrict the use of the available features and limit the number of people we open the doors to, why not throw them open to anyone who wants to come in. Natural selection will ensure we only get the intelligent ones - the dumbos will continue to use their auto-install aol/compuserve/msn acco8unts and not bother us. > FTP standard. Calling system uses username anonymous and password > ":/". Called system accepts anonymous ftp upload of pkt > and arcmail. FTP received on port .. LS> You'd have to write an extended capability FTP agents for that. Bollocks. My FTP daemon accepts anon login, anon upload, and any old name as login id. > SMTP/UUEnc standard. UUEncoded pkt / arcmail to user "fidouue" at > hostname / ip address. SMTP received on port .. LS> You'd have to write an encoding/decoding/splitting/reassembling LS> software for that. No you don't - the sysops that want to implement this method between them have to set it up. All they have to do is provide the capability. There is email receiver software that will auto regenerate the split encoded message and place it in a nominated directory. LS> And I personally doubt using this protocols is worth the amount of LS> work we have to put in before it works. You don't have to put in any work. Let the people who *WANT* to use and develop the protocols do the work, as they already are at the moment, and just leave a mechanism in plac so that they can continue to use, develop and expand the use of those protocols. Natural selection willl lead to the best solution getting the widest implementation at the end of the day, so there's no need for you to judge any protocol or technique as unsuitable before we cross the starting line! > sysops of ip systems can agree privately to implement any method however > they like for communication between their two systems. LS> As long as their satisfy other requirements for being a node, yes. Like I already sai to someone - wrong echo for that debate! Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #619 [1995] Scn From : Sean Rima 2:252/358 12 Oct 97 12:26:20 To : maciej grzeszczuk 14 Oct 97 05:39:08 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hiya, maciej! >> > using binkd of course. other mailers are not allowed. >> Just a curious question. How many IFCICO mailers are there live on the >> Net. I am curious. mg> ifcico+vmodem mailers. remember that they all use the same protocol! mg> and i bet that there is more of them than binkd. I have searched the Net for a Nodelist for ifcico,vmodem mailers but cannot find one. In fact the real only mention of ifcico is where to get the source. Maybe there are many more use vmodem but are these live on the net 24 hours. I would like to see if I could run vmodem on a small shell account under unix. >> I know a BBS use uses T-mail as his main mailer and for TCP/IP >> connectiuons uses BinkD. Here has no problems with this setup and uses it >> daily. mg> and i know bbs uses t-mail, using t-mail to connect to my ifcico, without mg> configuring another mailer. everything is ready-for-action on his os/2. mg> do you want me to show my log from that connection? I don't need to see your log as I know it can be done. What are the file sizes of Vmodem over BinkD. BinkD for NT is around 98K, there is also a compiled version of BinkD for OS2 EMX at 38k >> BinkD as a program is *NOT* able to be used on a Telephone line. It is a >> small program to allow connects over the Net. It works along side T-Mail, >> Argus and mg> it won't work with t-mail. it works with the same outbound that t-mail mg> does, mg> but don't say that it works WITH it. >> any other Binkley type mailer. And it is free. Sean Rima Sysop DSP BBS and Ipmailer --- QDED alpha v3.57pl8/ FreeBSD * Origin: DSP BBS Ipmailer Reading England (2:252/358) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #620 [1995] Scn From : Denis McMahon 2:251/20 12 Oct 97 23:20:26 To : maciej grzeszczuk 14 Oct 97 05:39:08 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- maciej grzeszczuk wrote to Denis McMahon: mg> From: maciej grzeszczuk mg> Tue, 07 Oct 97 22:21:48 +0200 Denis McMahon napisal byl w mg> fido.ip_connect: > Vmodem > Telnet mg> that's the same protocol. > BinkP > BinkD mg> what are the differences between the last two? I don't know - I merely went through the echo and listed the different transports / protocols that had been suggested (I think I listed them all). > IFCICO > FTP > UUCP > SMTP/UUEnc > SMTP/Base64 mg> i disagree. we shouldn't treat ftp or other internet services as a mg> valid fidonet transport. 1) You're being shortsighted. FTP and SMTP are *ALREADY* being used and have been for over a year to provide automated transfer FTS-0001 packets. 2) We're not here to decide what protocols are or are not valid, ultimately *ANY PROTOCOL OR TRANSPORT THAT WORKS IS VALID*. We're here to work out how to get the IP addressing data into the nodelist. Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #621 [1995] Scn From : Sean Rima 2:252/358 12 Oct 97 12:36:32 To : maciej grzeszczuk 14 Oct 97 05:39:08 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hiya, maciej! At 10 Oct 97 14:04:45, maciej grzeszczuk wrote to Lothar Behet: >> Could you please tell me (and others:), which products support Vmodem for >> PC based operating systems (DOS, Windows, Win96, Win95, WinNT) and where >> they are available? mg> i'm unix operator, i don't know where to find windows software. but i know mg> for sure that vmodem is available on: amiga, os/2, win95, win3.1, winnt, mg> unices, mg> as i can see connections from systems using that os in my mailer log every mg> day. >> A software or protocol standard must be usable by most of the nodes. mg> sure. and binkd (binkp) isn't such standard. it's only supported by small mg> (2 i heard, third is under construction) number of mailers. And as more programmers of mailers become involved I am sure that BinkP will be added as the source is freely available and free to implement. Sean Rima Sysop DSP BBS and Ipmailer --- QDED alpha v3.57pl8/ FreeBSD * Origin: DSP BBS Ipmailer Reading England (2:252/358) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #622 [1995] Scn From : Sean Rima 2:252/358 12 Oct 97 12:33:54 To : maciej grzeszczuk 14 Oct 97 05:39:08 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Hiya, maciej! At 10 Oct 97 14:34:17, maciej grzeszczuk wrote to Lothar Behet: mg> From: maciej grzeszczuk mg> Tue, 07 Oct 97 07:43:42 +0200 Lothar Behet napisal byl w fido.ip_connect: >> mg> binkd cannot be treated as a standard, as it's compatible only with >> mg> itself. >> ... on different platforms (Unix, Linux, OS/2, Win 95 and Win NT). mg> and the vmodem is compatible with any mailer on any platform. mg> is it so hard do understand? And the size and cost overheads? I pay a lot of monery every month for my Telephone lines (5) my Shell account with 1gb of HD space. So why pay more when I can get a perfectly working system for free. Sean Rima Sysop DSP BBS and Ipmailer --- QDED alpha v3.57pl8/ FreeBSD * Origin: DSP BBS Ipmailer Reading England (2:252/358) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #623 [1995] Scn From : Denis McMahon 2:251/20 12 Oct 97 23:29:46 To : rafal wiosna 14 Oct 97 05:39:08 Subj : SMTP/FTP - QWK of the internet ------------------------------------------------------------------------------- rafal wiosna wrote to Denis McMahon: DM> FTP DM> SMTP/UUEnc DM> SMTP/Base64 rw> IMHO those methods are not valid for Fido use. I'm not saying that rw> you cannot use them to transfer ARCmail/netmail. But don't you rw> think that if they were valid we'd use QWK for inter-node mail rw> exhange?!?! I think NOT. IMHO this echo is about how we incorporate the IP addressing data in the nodelist, not about which protocols and methods are valid or not. Can we try and keep to the objective? Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #624 [1995] Scn From : Denis McMahon 2:251/20 12 Oct 97 23:24:30 To : Ask Bjoern Hansen 14 Oct 97 05:39:08 Subj : IP-access ------------------------------------------------------------------------------- Ask Bjoern Hansen wrote to Denis McMahon: ABH>> It would be easy to redelegte the administration further down to ABH>> the RC, NC or whoever.. DM> No it would not, the administration would have to be done by DM> whoever DM> maintained the dns at the level concerned. Most NCs, RCs etc have no DM> access to the DNS for z2.fidonet.org. ABH> I guess you should read something about how it works. ABH> It's very easy to redelegete f.x. n251.z2.fidonet.org to a ABH> nameserver controlled by someone in your net. It should not be a requirement that a net maintain a nameserver before that net is allowed to contain IP nodes! Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #625 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 14 Oct 97 07:32:28 To : Denis McMahon Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Denis! On 12 Oct 97 wrote Denis McMahon to maciej grzeszczuk: >> Vmodem >> Telnet >> BinkP >> IFCICO These protocols basically are able to iniciate a direct handshake between two nodes, which is equivalent to a normal sessiopn on dial lines. They use FTN-data for authentication and are compliant in that way to normal fido policy requirements. >> FTP >> UUCP >> SMTP/UUEnc >> SMTP/Base64 mg>> i disagree. we shouldn't treat ftp or other internet services as mg>> a valid fidonet transport. DM> 1) You're being shortsighted. FTP and SMTP are *ALREADY* being used DM> and have been for over a year to provide automated transfer FTS-0001 DM> packets. They may be used, but they are independant in any way from fido technology and any fido data (nodelist). DM> 2) We're not here to decide what protocols are or are not valid, DM> ultimately *ANY PROTOCOL OR TRANSPORT THAT WORKS IS VALID*. We're here DM> to work out how to get the IP addressing data into the nodelist. Any fido node operates his system under certain conditions, one of them being the policy (P4 until now). He is responsible for the any routed data to his up- and downlinks. All E-mail based protocols may be buffered elsewhere and not under control of a fido sysop. Another thing is, how large will the nodelist grow, if any internet user may aquire a nodelist entry in fido? Can it be handled on a typcal private system with limited capacity? Therefore at least one handshaking protocol based on nodelist data must be required for a node with ip-flags, who has to fulfill the requirements according the policy (i.e. online times at least while ZMH). For any other entries the regional pointlist is completely sufficient to get a fido address and communicate with other members. The other protocols (ftp, email-based) may be mentioned as additional protocols in the nodelist for further distribution purposes as information to downlinks. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #626 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Oct 97 23:54:42 To : Lawrence Garvin 14 Oct 97 22:18:10 Subj : Re: IP-access ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >Although that's not to preclude their use by nodes, only that the >responsibility for correlating the DDNS and the dynamic IP node should be the >responsibility of that node's ISP, not Fidonet or the hostmaster of any of >the fidonet.* DNS zones. I agree. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #627 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Oct 97 23:28:18 To : Lech Szychowski 14 Oct 97 22:18:10 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: > > Where is the problem? They will rename arcmail packets in a way they > > will not overwrite anything in the inbound, like normal mailers do. >FTP daemon will rename received files? I think so. You can find the source for this modified wu-ftp on ftp.fido.de. >be the FTP protocol this software will use - it will be either an extension >to this protocol or a completely new one. Ok. Do you think is ok to allow the public[1] use of email and ftp transports if some requirements are meet? > >>- how does SMTP deal with file requests? > > By sending a .req file. The receiving program will intercept this file > > and create a file attach for the other node. >And how does SMTP pick the attach up? He does not. The file will be sent him to his email address, tunnelled like normal arcmail. > > My protocol supports encrypted transferts, PGP-signed and/or encrypted > > transferts (following the S/MIME standard) and clear password protected > > transferts. >SMTP nowadays supports nearly everythingh as a message body. But it has >nothing to do with the session authorization. My protocol provides multiple ways to verify the sender of a message. >My objection was mainly about using the name of "FTP" here. It will >no longer be the FTP as RFC defines it. It will be the same exact protocol, just the daemon will be smarter and will correctly move in the inbound/outbound the arcmail. > > I wrote one. It does not split and reassembly because I don't need that, >We certainly will need it. A lot of mailers enforce limits on the >size of a single message. In the modern internet? This is no true. Anyway, if you want splitting you can add it, you have the source. [1] If I want to receive my echomail via flying pidgeons (RFC 1149) and my boss agree no one should force us to use another transport. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #628 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Oct 97 23:29:14 To : rafal wiosna 14 Oct 97 22:18:10 Subj : Re: SMTP/FTP - QWK of the internet ------------------------------------------------------------------------------- rafal.wiosna@f33.n480.z2.fidonet.org wrote: > IMHO those methods are not valid for Fido use. I'm not saying that > you I don't think so. email tunnelling and ftp can transfert arcmail and files like any pstn mailer does. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #629 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Oct 97 23:32:44 To : Lawrence Garvin 14 Oct 97 22:18:10 Subj : Re: Flags in nodelist ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >"Internet" -- there's also nothing keeping Fidonet(tm) from setting up our >own proprietary ROOT SERVER in the Top Level Domain .FIDONET or .FIDO There is: what alternic/edns/etc says is crap. This kind of solution will never work. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #630 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Oct 97 23:56:26 To : maciej grzeszczuk 14 Oct 97 22:18:10 Subj : Re: IP-access ------------------------------------------------------------------------------- krap@zwieracz.psych.uw.edu.pl wrote: >sure. i've got about 15 connections with vmodem daily. transferring large You have got connections with EMSI over telnet. It's a whole different protocol. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #631 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Oct 97 23:36:42 To : Lech Szychowski 14 Oct 97 22:18:10 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >IMHO you are wrong. My system is reachable from the Internet as three >IP addresses - and the reason behind it is it has three different >physical links from different ISPs, for sake of redundancy and If this is your concern then you should use round robin DNS. If one link is down, next time the mailer will retry on the next one. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #632 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Oct 97 23:41:36 To : Lawrence Garvin 14 Oct 97 22:18:10 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >Your previous suggestion to use the NAMEfield for a FQDN is a better one, I >think, than trying to put the IP address in the telno field. Besides, the >latter would require a rewrite of MAKENL or a new nodelist builder which all >coordinators would have to agree to utilize. The former requires NO changes >in existing nodelist utilities AT ALL! But it requires modifying mailers, virtual fossil drivers and maybe nodelist compilers too. And I don't want to lose the system name. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #633 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Oct 97 23:45:42 To : maciej grzeszczuk 14 Oct 97 22:18:10 Subj : Re: vmodem ------------------------------------------------------------------------------- krap@zwieracz.psych.uw.edu.pl wrote: >both telnet (in your meaning) and vmodem are the same protocol. They aren't. The vmodem protocol (VMP) accepts connections at port 3141 and is a proprietary standard of the vmodem.sys virtual fossil. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #634 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Oct 97 23:17:46 To : Lawrence Garvin 14 Oct 97 22:18:10 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >I think the core of this issue gets back to MAKENL. I don't think MAKENL will I don't think we will use MAKENL anymore. That program is *old*. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #635 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Oct 97 23:34:58 To : Lawrence Garvin 14 Oct 97 22:18:10 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >system. I think that if we develop a standard where the node can -still- >support PSTN FTS-0001 connections during ZMH, we'll have a lot easier time >getting the whole package accepted. For ISDN you will get another node numeber, why you don't want one for IP? -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #636 [1995] Scn From : Marco d'Itri 2:335/680.666 14 Oct 97 14:33:30 To : Lech Szychowski 14 Oct 97 22:18:12 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >Carrying floppies or sending tapes via snail-mail also does. >Is that enough too? Yes. I never wrote that is a good idea to have an email-tunnelling only node, but I think that any node that wants to advertise this capability in the nodelist should be able to do that. email-tunnelling is a cheap way for a PSTN node to send crashmail or to get his echo feed. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #637 [1995] Scn From : Marco d'Itri 2:335/680.666 14 Oct 97 14:21:44 To : Lech Szychowski 14 Oct 97 22:18:12 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >I'm afraid that when we say "email" we have to think "SMTP" (not just, >but also). This is not always true and certainly not needed. SMTP is just a transport, e.g. my email comes to me via uucp. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #638 [1995] Scn From : Marco d'Itri 2:335/680.666 14 Oct 97 14:25:58 To : maciej grzeszczuk 14 Oct 97 22:18:12 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- krap@zwieracz.psych.uw.edu.pl wrote: >i mean we shouldn't allow getty's logon procedure between the handshaking. Why not? The login: prompt does not interferes with EMSI. Normal BBS always prompt some text for the user before accepting an EMSI session. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #639 [1995] Scn From : Marco d'Itri 2:335/680.666 14 Oct 97 14:20:12 To : Lech Szychowski 14 Oct 97 22:18:12 Subj : Re: IP-access ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >We can always go for "fidonet.org.", this option being >the proper one according to DNS pragmatic. Not all Registration Autorities register domains for everybody. In Italy we had to register fidoitalia.net because private entities can't register domains (we would need to register a formal fidonet association). -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #640 [1995] Scn From : Marco d'Itri 2:335/680.666 14 Oct 97 14:34:46 To : Yuri Teterin 14 Oct 97 22:18:12 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Yuri.Teterin@f239.n5030.z2.fidonet.org wrote: > Once more, ifcico is a mailer, and not a protocol. The only >ifcico-speciffic protocol is its 'raw TCP protocol', which can be considered >as an alternative realization of FTN_over_telnet sessions. It can't, there is no telnet protocol in an handshake over the raw TCP connection. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #641 [1995] Scn From : Marco d'Itri 2:335/680.666 14 Oct 97 14:42:44 To : Chris Maddock 14 Oct 97 22:18:12 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Chris.Maddock@f302.n640.z3.fidonet.org wrote: >1. A special character or sequence tha signifies a IP node or whatever, and >translates the number (or some other field). An user flag "IP" should be enough. >The "Baud_Rate" field could do this easily ? It sure isn't used much for much >else 'cept ISDN nodes. No, we can't specify an arbitrary baud rate (can you say "brain damaged standard"?). >2. Flags. A series of flags to indicate that a node is IP (or whatever) >capable. I have seen a good proposal in this echo. >3. Routing. Some indication is required to indicate how to route the mail to I can't understand what we should add in the nodelist. I think that the choice of the preferred protocol should be made by the calling sysop. The node can force a preference between protocols by specifying the flags in the prefered order. >and nodelist generator authors to make changes, but we are going to need to >be able to say =exactly= what changes are required. Compilers should just accept a longer flag field and an FQDN in the phone field. >5. It has to be as simple as possible. It's no point making a system that >becomes so complicated that any changes made in the future break it. My proposal is so simple that it already works with many compilers (e.g. fastlst). >6. We may even have to look at a different type of nodelist - binary perhaps >? You should read my extended nodelist proposal, I will attach it by email. [via email and echomail] -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #642 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 14 Oct 97 14:36:48 To : Lothar Behet 14 Oct 97 22:18:12 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: >Therefore at least one handshaking protocol based on nodelist data must be >required for a node with ip-flags, who has to fulfill the requirements >according I agree, but *all* nodes (PSTN or IP) should be able to advertise in the nodelist email or ftp service. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #643 [1995] Scn From : maciej grzeszczuk 2:480/70 12 Oct 97 20:33:48 To : Sean Rima 15 Oct 97 02:22:40 Subj : Re: BinkD (0.9.2) specification ------------------------------------------------------------------------------- From: maciej grzeszczuk Fri, 10 Oct 97 18:35:00 +0200 Sean Rima napisal byl w fido.ip_connect: > Why used Telephone based protocols over the Net. It is like having a Porsche > with the engine from a Robin Reliant. Most telephone based protocols would > not handle the weirdness of the net. please, in daily connections, use your binkd as often as you wish. but also support vmodem connections, in case someone would like to connect to your system. someone using other mailer, that binkd. 550 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: graba, jestes zajebisty. dziekuje. dam ci wina. (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #644 [1995] Scn From : Lech Szychowski 2:480/33.7 13 Oct 97 01:06:00 To : Lawrence Garvin 15 Oct 97 02:22:42 Subj : IP-connectivity ------------------------------------------------------------------------------- > Lech, if the sendmail.cf, or other MTA configs, were properly > configured, it is possible to recognize and process mail addressed to an > actual IP address. In such cases the MTA would bypass the normal DNS > steps, and simply transport the message. Yes, I'm aware of that. But I'm also aware that it is at least unreasonable to assume every MTA that happens to process such message will be configured as we'd like it to be. > norm, and I, for one, am not aware of any provisions in my two sendmail > based systems, or my SCO MMDF based systems, to accept mail addressed to > an IP address (e.g. lawrence@198.216.62.42). One writes such addresses as "lawrence@[198.216.62.42]", and I believe most MTAs know how to deal with them. Although they perform no MX lookups, because this way of addressing exists mainly to provide us with a "last resort" delivery scheme, when one wants to force MTA to deliver mail directly to a given system. > The receiving MTA, in many cases, particularly MMDF, expects to see a > DNS resolvable address in the addressee field. Furthermore, it also > requires that the sending system be reverse mapped in in-addr.arpa, or > it will refuse the inbound connection. Yes, either MTA itself or TCP wrapers (or both) may be configured to reject connection attempts coming from systems that have unconsistent IP-to-FQDN and FQDN-to-IP mappings. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #645 [1995] Scn From : maciej grzeszczuk 2:480/70 12 Oct 97 21:49:56 To : Igor Bilyi 15 Oct 97 02:22:42 Subj : Re: binkd vs vmodem ------------------------------------------------------------------------------- From: maciej grzeszczuk Fri, 10 Oct 97 12:36:56 +0200 Igor Bilyi napisal byl w fido.ip_connect: > LS> In negotations or transfers? > in trabsfers, 100 MB on 28.8 lines with > 2800 cps, try todo this with vmodem easily. 554 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: zawsze gdy cie widze mam ochote pierdolnac cie w (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #646 [1995] Scn From : maciej grzeszczuk 2:480/70 12 Oct 97 21:53:14 To : Frank Ellermann 15 Oct 97 02:22:42 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- From: maciej grzeszczuk Fri, 10 Oct 97 14:07:00 +0200 Frank Ellermann napisal byl w fido.ip_connect: > > 1. IP only nodes may be listed only in a region (or nets) reserved > > for this purpose. what for? 555 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: takiego grzegorza jak #polska cala! (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #647 [1995] Scn From : Lech Szychowski 2:480/33.7 13 Oct 97 00:06:00 To : Marco d'Itri 15 Oct 97 02:22:42 Subj : IP-access ------------------------------------------------------------------------------- >>If we are to have "FQDN -> dynamically assigned IP" database that >>really works, all regional/netional DNS servers will have to be >>DDNS servers as well. At least I fail to see another solution. > We can use CNAME RRs. Yes, as long as we are not using any of those as MXes and as long as we decide to live with keeping those DDNS servers and fidonet.org subdomains servers synchronized. IMHO these restrictions are acceptable, but I expect a lot of people to raise hell about not being allowed to be listed as its own MX; and once we start to really make use of DNS I'll stand rather firmly against delegating MXes to systems in domains other than fidonet.org. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #648 [1995] Scn From : Lech Szychowski 2:480/33.7 13 Oct 97 00:19:00 To : Lawrence Garvin 15 Oct 97 02:22:42 Subj : IP-access ------------------------------------------------------------------------------- > about to make significant changes to multiple nodes, by reducing the TTL > from one day to one hour; then make the changes, which guarantees > updates within the immediate future; then change the TTL back to one day. Sounds like you are running things the good old way. I try to do more or less the same; I think each hostmaster does it this way :) > LS> I know that. That's the reason why I think delegating > LS> regional/netional subdomains is a must. > And I've been naturally assuming that's exactly what would happen. I have quite a lot of doubts about it. At least at the moment there is a great deal of reluctancy from Z2 authorities. > I think it totally impractical for an entire Fidonet Zone to be > maintained in a single DNS Zone. I second this opinion. There was - and still is - a good reason behind making DNS a hierararchical structure. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #649 [1995] Scn From : Lech Szychowski 2:480/33.7 13 Oct 97 00:28:00 To : Lawrence Garvin 15 Oct 97 02:22:42 Subj : IP-access ------------------------------------------------------------------------------- > Although that's not to preclude their use by nodes, only that the > responsibility for correlating the DDNS and the dynamic IP node should > be the responsibility of that node's ISP, not Fidonet or the hostmaster > of any of the fidonet.* DNS zones. If we don't want to have FQDNs in fidonet.org domain, yes. But then we loose the option of having a default translation of the system's Fidonet address to its FQDN. > If properly done, the DDNS and dynamic Ip addressing should be totally > invisible to Fidonet. True enough. But - correct me if I'm wrong - you suggest we should allow IP nodes to have arbitrary (ie not falling within fXX.nYY.zZZ.fidonet.org pattern) FQDNs and this will have a negative impact on declaring MXes. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #650 [1995] Scn From : Lech Szychowski 2:480/33.7 13 Oct 97 01:20:00 To : Lawrence Garvin 15 Oct 97 02:22:42 Subj : IP-access ------------------------------------------------------------------------------- > It should also be an option to nets within each region to have their net > dns delegated to a net dns server, although I suspect for the near > future there won't be enough utilization at the net level to justify a > delegated zone a the net level. If I were the regional DNS maintainer, I'd make the delgations to nets right away, making a primary regional NS also a primary NS for them. Why? Because we here in Fidonet are lucky enough to already have a hierarchical structure that translates perfectly to DNS hierarchy; this Z/R/N structure is quite stable and I bet it will stay around for a while - and working with netional subdomains minimizes chances of sc*ewin up the whole region accidentally. > Another option that regions might consider pursuing is registration of > FIDONET.XX in each region where the domain is the country-level domain, > such as FIDONET.UK, FIDONET.DE, FIDONET.FR, FIDONET.PL, etc. This would require us to maintain and distribute some form of machine readable "region -> country" translation table. Yes, I know it can easily be done by assuming that "contry" field for the RC's system carries this info - but it's still another thing to remember about and another possible point of failure. > Unfortunately, in the U.S. this opportunity is not available because the > University of Southern California, who manages the .US domain, is only > issuing (STATE).US names -- although I suppose it wouldn't hurt to try We can always go for "fidonet.org.", this option being the proper one according to DNS pragmatic. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #651 [1995] Scn From : Lech Szychowski 2:480/33.7 13 Oct 97 00:09:00 To : Marco d'Itri 15 Oct 97 02:22:42 Subj : IP-connectivity ------------------------------------------------------------------------------- >>My personal worries are SMTP encapsulation might give us more trouble than > Then don't use it. I use email (*NOT* "smtp") encapsulation and I'm I'm afraid that when we say "email" we have to think "SMTP" (not just, but also). Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #652 [1995] Scn From : Lech Szychowski 2:480/33.7 13 Oct 97 00:43:00 To : Lawrence Garvin 15 Oct 97 02:22:42 Subj : IP-connectivity ------------------------------------------------------------------------------- > My point, Lech, is that I would be hesitant to support IP nodelisting > for any node that is maintaining their system via a dialup PPP link. My personal feelings are just like yours. But at the same time I know that having a leased line link to the Internet is still relatively rare in Europe and the demand to use Internet links as transfer media is growing; knowing that and reading other people messges in this echo I realize that sooner or later we'll have to allow some IP nodes with non-permanent links. > I would think, as a minimum, a dedicated IDSN link to a provider, or > FrameRelay, T-whatever, or other such 'permanent' link that can answer a > ping 24 hours a day, without dependence on a volatile dialup connection. That is the easiest and most safe (as long as reliability and robustness is concerned) approach. I'd like very much to see a few IP nodes providing hub/host/gate services and taking care of the large volume long distance transfers (kinda backbone-like) plus any (possibly even very large) number of other systems that ocassionally or on regular basis connect to those IP nodes (even via PPP and ISPs, but I admit I'd rather make them use "raw" PSTN). But, as I've already mentioned, there seems to be quite a lot of us having a much differnent opinion :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #653 [1995] Scn From : Lech Szychowski 2:480/33.7 13 Oct 97 01:29:00 To : Dieter Ringhofer 15 Oct 97 02:22:42 Subj : IP-connectivity ------------------------------------------------------------------------------- > T-Flags impose another problem and are unusable in real practice: > How do you want to get them working all around the world?? By listing hours in GMT and letting malers know their own GMT offset. I know it's not possible for all existing mailers, but we can write the new IP-capable ones so that it would. > Simply forget all except ZMH because it won't work in reality of an > international network, even 'national' usage offers no warranty for > correct behaviour. I think that if a calling party makes a mistake - ie tries to connect outside the hours indicated in nodelist - it's just its own fault. Since with IP nodes it would be not a real call (but just a packet or some packets sent/routed to an address that will turn unreachable or not responding) it does not mean waking anyone up in the middle of the night :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #654 [1995] Scn From : Lech Szychowski 2:480/33.7 13 Oct 97 00:11:00 To : Marco d'Itri 15 Oct 97 02:22:42 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >>i disagree. we shouldn't treat ftp or other internet services as a valid >>fidonet transport. > They move arcmail between nodes. I think this is enough. Carrying floppies or sending tapes via snail-mail also does. Is that enough too? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #655 [1995] Rcv Scn From : Lech Szychowski 2:480/33.7 13 Oct 97 00:55:00 To : Lothar Behet 15 Oct 97 02:22:42 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- > The nodediff is transported world wide, a large part of its members [...] > Lets estimate, that there are about 70.000 - 120.000 points worldwide, > then it's 100.000 to 150.000 people who have to pay for it. I don't think points (and even some nodes) have a full world nodelist. In most cases points would use just the regional/netional segment. > My first intention is therefore to keep the nodelist small through using > combined entries. Adopting default FTN-address -> FQDN translation scheme should make this task easier. > To participate in the communication via fidonet a pointaddress is > enough. Exactly. I became a node just because I run a Fidonet<->Internet gate, before that I've been happy as a point for some 5 or 6 years. OTOH being a point might be a bit too little for some people because of the formal/legal implications (Fidonet membership, voting etc). > Pvt-entries are only allowed, where routing definitely requires it. > You may create a kind of "internet user list" anywhere else, but do not > misuse the nodelist for it. I'm afraid we'll have to list such systems, unless we want netmail trackers to barf on any mail addressed to these nodes. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #656 [1995] Scn From : maciej grzeszczuk 2:480/70 12 Oct 97 20:28:02 To : Rune Johansen 15 Oct 97 02:22:42 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: maciej grzeszczuk Thu, 09 Oct 97 21:47:48 +0200 Rune Johansen napisal byl w fido.ip_connect: > > but we shouldn't allow log in procedure when connecting to ftn mailer via > > telnet. > Huh? Why not? Or do you think of "log in" as "log into unix"? i mean we shouldn't allow getty's logon procedure between the handshaking. 549 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: graba, jestes zajebisty. dziekuje. dam ci wina. (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #657 [1995] Scn From : David Moufarrege 1:2613/404 13 Oct 97 07:00:16 To : Lawrence Garvin 15 Oct 97 02:22:42 Subj : IP-connectivity ------------------------------------------------------------------------------- Hello Lawrence! In a message Lawrence Garvin wrote to David Moufarrege: LG> If the IP address is truly dynamic, how would one be able to LG> "register" it, as they would have no idea from call to call what it LG> was going to be? After you have gone through the dynamic IP assignment during log-on you then proceed to a special site and register with a pre-assigned password AND the current dynamic IP. That site updates its DNS every 10 minutes and matches a pre-assigned static IP to your current dynamic IP. Since it was pre-assigned to you and is exclusively yours you can give it out. The service does exist. LG> I agree, though, such would be helpful.. although I can't help but LG> wonder on the side if that isn't undoing the very reason why the LG> primary ISP implemented DHCP in the first place -- to conserve IP LG> addresses -- and here we're registering even more -- somewhat LG> redundant, isn't it? :) Yes, of course. But how many people outside the actual industry know that we're running out of numbers, what the process of obtaining a Class A, B or C registration is etc. ? I'll be interested in seeing how they finally implement v6 :-) -=David=- _____________________________ | e-mail : david@kraut.xg.com | | FidoNet: 1:2613/404 | | 1:13/0 | ----------------------------- ... How many times do you need to be tolled anyway? --- * Origin: Kraut Haus * Rochester, NY * 716-359-0871 (1:2613/404) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #658 [1995] Scn From : Amir Shabashvili 2:5049/12 13 Oct 97 13:05:04 To : Lech Szychowski 15 Oct 97 02:23:10 Subj : IP-access ------------------------------------------------------------------------------- Hello Lech! Replying to a message from Lech Szychowski to Amir Shabashvili: LS>>> Now that's something I don't like. Another domain? What for? >> For testing all things (like DNS-nodelist resolving) we discuss in LS> Testing is OK. But once testing is over we should IMHO start using the LS> fidonet.org. domain. probably.But - fidonet.net old Fido domain, used thousand:) years for gating&so on, and using other domain(s) for DNS-only may be better way. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #659 [1995] Scn From : Yuri Teterin 2:5030/239 13 Oct 97 18:59:52 To : Denis Mcmahon 15 Oct 97 02:23:10 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello, Denis ! Sun Oct 12 1997 Denis McMahon writes to maciej grzeszczuk: DM> 2) We're not here to decide what protocols are or are not valid, DM> ultimately *ANY PROTOCOL OR TRANSPORT THAT WORKS IS VALID*. We're here to DM> work out how to get the IP addressing data into the nodelist. But we must decide also how to indicate in nodelist which set of FTN-over-IP protocols does the node support. And to do this we must first of all get either full specifications for such protocols, or at least exact reference to standard implementations of them. "FTN, SMTP and so on" do not confirm this requirements, because there exists a lot of different ways to use them for transmission of FTN traffic. So we need some additional information before corresponding protocols will be considered as a valid protocol for IP node. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #660 [1995] Scn From : Amir Shabashvili 2:5049/12 13 Oct 97 12:42:28 To : Denis McMahon 15 Oct 97 02:23:10 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Denis! Replying to a message from Denis McMahon to Amir Shabashvili: DM> Hey Amir, you don't want to communicate with non FTS-0001 nodes, fine. I didn't say that. Only thing I trying to say is : It will the wrong way if we'll join IP and PSTN nodes in one file. Why? Well, IP transport and usial PSTN so differ, and cann't be cover by one policy. I think must be some part in policy for IP-only and some - for PSTN nodes only. And different nodelist files is good thing, from this point of view. DM> There's a lot who do, and a lot who think that 1989 policy and DM> procedure is out of date in 2000. And I'm too;) <...skipping a piece of wisdom..> DM> technology, becaue this isn't where we debate "can we / should we", DM> but "how can we". Take the "can we / should we" debate elsewhere! Ok. Is there some rules & moderator? Is this echo self-moderated? Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #661 [1995] Scn From : Nick Soveiko 2:5030/23.101 12 Oct 97 22:19:42 To : Lech Szychowski 15 Oct 97 02:23:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sun, 12 Oct 1997, 02:10, Lech Szychowski (2:480/33.7) ==> Marco d'Itri: LS> Nobody is trying to force you to use vmodem for your everyday mail LS> traffic. Keep on using anything you and your links agree upon - but LS> also support the vmodem as a "lowest common denominator", just in LS> case someone wants to connect to your system usubg this protocol. in order to maintain this just-in-case capability a sysop running os/2 or win nt has to go out and *buy* appropriate software. afaik, vmodem isn't free and neither are it's analogs for many other platforms. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #662 [1995] Scn From : Pedro Lima 2:362/21 13 Oct 97 05:33:52 To : Lech Szychowski 15 Oct 97 02:23:10 Subj : IP-access ------------------------------------------------------------------------------- LS> Do you think we can try to work on a solution LS> based upon a concept of "fXX.nYY.zZ constructed from FTN address, the LS> rest of the FQDN either default (ie .fidonet.org) or explicitely LS> listed in some flags field entry"? I think the latter would be preferable, although I also think nodelisting the IP address should not be disregarded as a possibility. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #663 [1995] Scn From : Dmitry Arsh 2:5100/21.1 13 Oct 97 08:05:04 To : Lech Szychowski 15 Oct 97 02:23:10 Subj : Re: IP-access ------------------------------------------------------------------------------- Hello Lech! Sunday October 12 1997 01:39, Lech Szychowski wrote to Timur Hi-Rullin: >> not ip-address. It means that node have a ip-address 192.168.100.200, >> names fido-node.company.com and can be resolved as >> f49.n5049.z2.fidonet.net too. Therefore, there's no need to put _any_ >> ip-address to nodelist. Isn't it like good? LS> Yes, it is. The only thing I'm against is the "fidonet.net." domain. LS> Why not the usual "fidonet.org."? AFAIU, you need something answering SMTP on port 25 to be listed in .fidonet.org. I.e. if there will be any e-mail from Internet to, say, somebody@f21.n5100.z2.fidonet.org and my IP is listed in the fidonet.org domain, I have to answer on port 25 to get this e-mail. I'm afraid there are nodes with IP which cannot do this. Darsh P.S. Correct me if I'm wrong --- GoldED 2.50+ * Origin: darsh@telekom.lv (FidoNet 2:5100/21.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #664 [1995] Scn From : Yuri Teterin 2:5030/239 13 Oct 97 20:44:40 To : Maciej Grzeszczuk 15 Oct 97 02:23:10 Subj : vmodem ------------------------------------------------------------------------------- Hello, Maciej ! Sun Oct 12 1997 maciej grzeszczuk writes to Sebastian Stein: >> Correct me, if I am wrong ! My english isn't the best, maybe I >> misunderstood you ? mg> both telnet (in your meaning) and vmodem are the same protocol. Once more: they aren't. These are quite different protocols. Just try to make telnet to your telnet port 60177 and then - to vmodem port 3142 of any vmodem-node, and you'll see the difference. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #665 [1995] Scn From : Yuri Teterin 2:5030/239 13 Oct 97 20:45:20 To : Maciej Grzeszczuk 15 Oct 97 02:23:10 Subj : IP-access ------------------------------------------------------------------------------- Hello, Maciej ! Sun Oct 12 1997 maciej grzeszczuk writes to Lothar Behet: >> LS> The "tx" version of ifmail claims to be vmodem compatible: >> Did you check it? mg> sure. i've got about 15 connections with vmodem daily. transferring large mg> packages, about 500-1000kb. everything is absolutelly correct. This is not vmodem protocol, but vmotelnet protocol. Reed the documentations for vmodem from SIO package - and things become more clear to you. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #666 [1995] Scn From : Fausto Carvalho 2:361/7 13 Oct 97 20:31:22 To : Nick Soveiko 15 Oct 97 02:23:10 Subj : About DNS-based solution ------------------------------------------------------------------------------- FC>> I'd also like to stress that one of the key features of Fidonet is FC>> to allow one to one communication without depending on somebody FC>> else. -FC- NS> NS> you can not communicate independently as you still depend on the nodelist NS> and timely availability of correct updates. we've seen evidence as Hi Nick (and others replying to my message) Certainly. But you can check on the previous human-readable version of your nodelist what is the phone number (as you can easily add your non-listed points directly) and you'll be able to communicate. In the DNS world, DNS down or garbled means no communication unless you know the IP. But that's exactly what we wouldn't have in the DNS based approach for listing the IP nodes... I don't know nothing about DNS hierarchy and administration delegation, and maybe that's why I fear an approach depending on third-parties. NS> no technology is guaranteed from such disasters. my point he is that we Of course. Not even the snail-mail :-))) NS> use dns for daily needs and resort to other sources (nodelist, explicit NS> overrides for permanent links) in case of troubles with the former. Other source to overcome DNS is either another DNS or a hosts file including all the listed IP nodes! Not very practical NS> that's apart from the question of nodelist update turnaround, which is 1 NS> week in best possible case and typically takes 2-3 weeks. As we all know there are segments not updated for months, nodediffs not applied for ages... I think you got my point, and anyway I'm just trying to contribute to the discussion with an aspect I haven't seen referred before. Regards -FC- --- Msged/NT 4.10 * Origin: Midithru' (2:361/7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #667 [1995] Scn From : Amir Shabashvili 2:5049/12 13 Oct 97 13:00:38 To : Lech Szychowski 15 Oct 97 02:23:10 Subj : IP-connectivity ------------------------------------------------------------------------------- Hello Lech! Replying to a message from Lech Szychowski to Amir Shabashvili: mg>>> binkd cannot be treated as a standard, as it's compatible only with mg>>> itself. >> it's compatible with bink-style outbound, and that's enought LS> Enough? Mayby for the local (ie limited to local disk/filesystem) LS> compatibility this is really enough. But what about connectivity? Binkd is 2nd mailer on most systems I know. 1st - usial mailer with bink-style outbound - bink/bink+/xenia/brake/t-mail/. (Back)door for IP connectivity. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #668 [1995] Rcv Scn From : Yuri Teterin 2:5030/239 13 Oct 97 19:27:00 To : Lothar Behet 15 Oct 97 02:23:10 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello, Lothar ! Sat Oct 11 1997 Lothar Behet writes to Mario Mure': LB> Wherefore do you really need ip-only nodes in the nodelist? Yes, we do. LB> They can participate as point in the same discussions. IP-only nodes are often large echo- and fileecho-hubs Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #669 [1995] Rcv Scn From : Mario Mure' 2:335/533 13 Oct 97 20:56:44 To : Lothar Behet 15 Oct 97 02:23:10 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Tachchen Lothar, in Deiner Nachricht vom < 11 Oct 97 21:09:12 >, an Mario Mure' hast Du ueber < Proposal for listing as IP-node > unter anderem folgendes geschrieben: LB> Wherefore do you really need ip-only nodes in the nodelist? They can LB> participate as point in the same discussions. What if this ip-only system is routing netmail/echo to other nodes/points ? LB> That was not my action and therefore i can disagree with that now and LB> not at a later time :) LB> LB> I recommend, that it will disappear after the test period. It can disappear sooner than now if Ward disagree too But, please let me know if the choice is to not EVER allow ip-only in fidonet nodelist. Ciao ! /mario/ mure@sistemia.it --- DMreply v2.0 * Origin: Djemaa El Fna (2:335/533@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #670 [1995] Rcv Scn From : Mario Mure' 2:335/533 13 Oct 97 21:04:04 To : Lothar Behet 15 Oct 97 02:23:10 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Tachchen Lothar, in Deiner Nachricht vom < 12 Oct 97 10:15:00 >, an Mario Mure' hast Du ueber < Proposal for listing as IP-node > unter anderem folgendes geschrieben: MM>> BTW, there's at least an IP-only node between test nodes: 2:2/3008. LB> So you are telling us, that the other entries with the same name are LB> fake entries? :) Which name ? My name ? I'm a bit cold at the moment, but I don't feel "fake" ...should I ? :-)) LB> PS: Each entry 2:2/3* is at this moment IP-only at its own, but i could LB> find a correspondant sysop name with "normal" lines to each of them in LB> nodelist.283. Yes, of course, but "normal" (telco) lines are attached to the same machine that is also an IP system ? I fear we're going nowhere with this discussion... :) Ciao ! /mario/ mure@sistemia.it --- DMreply v2.0 * Origin: Stay cool if your hard disk say goodbye (2:335/533@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #671 [1995] Scn From : Yuri Teterin 2:5030/239 13 Oct 97 20:47:24 To : Lech Szychowski 15 Oct 97 02:23:10 Subj : IP-access ------------------------------------------------------------------------------- Hello, Lech ! Mon Oct 13 1997 Dmitry Arsh writes to Lech Szychowski: LS>> Yes, it is. The only thing I'm against is the "fidonet.net." domain. LS>> Why not the usual "fidonet.org."? DA> AFAIU, you need something answering SMTP on port 25 to be listed in DA> .fidonet.org. I.e. if there will be any e-mail from Internet to, say, DA> somebody@f21.n5100.z2.fidonet.org and my IP is listed in the fidonet.org DA> domain, I have to answer on port 25 to get this e-mail. I'm afraid there DA> are nodes with IP which cannot do this. Even worse - fidonet.org is described now as a domain for fido-internet gates. So if any node is listed in fidonet.org it must have also properly configured fido-internet gate. And this will be not appropriate for majority of IP-nodes. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #672 [1995] Scn From : Dieter Ringhofer 2:2476/14 14 Oct 97 23:57:56 To : Lech Szychowski 15 Oct 97 05:39:10 Subj : IP-connectivity ------------------------------------------------------------------------------- >> T-Flags impose another problem and are unusable in real practice: >> How do you want to get them working all around the world?? LS> By listing hours in GMT and letting malers know their own GMT LS> offset. I know it's not possible for all existing mailers, LS> but we can write the new IP-capable ones so that it would. In most basic princip you're right but, ... >> Simply forget all except ZMH because it won't work in reality of an >> international network, even 'national' usage offers no warranty for >> correct behaviour. LS> I think that if a calling party makes a mistake - ie tries to connect LS> outside the hours indicated in nodelist - it's just its own fault. How can it be 'his' fault when he's using a legal term like UTC with legal authorized presign for the offset (f.e. UTC-1 for localtime in R24 or UTC+5 instead of EST resp. GMT-5)? See above: You used the shortcut GMT which is already obsolete according several legal authorities since more than 20 years. Do you see the problem with 'unspecific' times like being used at T-flag definitions now? ;) LS> or not responding) it does not mean waking anyone up in the middle LS> of the night :) That's the onliest positive aspect with it in this relation --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #673 [1995] Scn From : Gisbert Rudolph 2:2443/2161 13 Oct 97 07:23:14 To : Ward Dossche 15 Oct 97 05:39:22 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Ward, after reading a _lot_ of mail in this conference I'll try to give you an answer to one your older mails. First of all, IP nodes are/would be the new ones not the telephon based ones. So all thoughts about listing of IP nodes in our nodelist have to start at the current situation and must have smooth operation in mind. Friday September 26 1997 23:59, Ward Dossche wrote to All: WD> 2) integrating the domain-name in the nodelist; I would prefere the FQDN form of listing but that's an other thread. WD> The next question is "where"? The phone-field is the obvious sollution WD> but then we need to do something about MAKENL and FTS-0005. That's the point I would like to talk about. It's not a good idea to use some fields in the nodelist in an other way they are normally used. You have seen the discussion about some special phone numbers in some countries. The phone number field should be used for phone numbers and nothing more. The best way would be to have a new 'address' field. We don't have one, so we are forced to use the only (nearly) free form field(s) we have: flags. Have a thought about other form of addresses like X25, X400, ... I suggest to use flags like this (plus some capability flags). With this kind of addressing you are able to have both telephon number and some other address: IP: IP: X25:
X400:
A node without telephon number would have an -unpublished- entry in the phone number field. In the (far) future we might have flags like TEL:. ;-) Don't abuse the phone number field. Gisbert (gisbert@os2bbs.art-line.de) --- GoldED/386 3.00.Alpha5+ * Origin: Peaceful Corner, 42105 Wuppertal (2:2443/2161) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #674 [1995] Scn From : Tobias Ernst 2:2476/418 14 Oct 97 13:32:50 To : Lawrence Garvin 15 Oct 97 05:39:48 Subj : IP-access ------------------------------------------------------------------------------- Hallo Lawrence! LG> One solution, although not as dynamic as would be most ideal is for LG> a nodelist compiler to recognize the appropriate flags in the flags LG> field (a capability that already exists), and implement an option LG> to 'build' the DNS name and do a lookup immediately, and then store LG> the returned value in the compiled nodelist in aaa*bbb*ccc*ddd LG> format, which -can- be read and processed by existing mailers. You say it yourself: "not as dynamic as would be most ideal". As soon as dynamic DNS is introduced, this won't work anymore. There is another drawback, that is not valid for nodes with a static IP via a leased line, but for nodes with a dialup connection. Those nodes of course cannot be called via IP, but they could wish to make a outgoing connect to an IP node (large filerequest, etc. etc.). If the nodelist compiler has to do the nodenumber<->ip translation and has to call the DNS, those nodes would have to connect to the internet everytime they compile their nodelist. If the mailer does it, on the other hand, they only have to connect to the DNS when they connect to the internet anyway in order to do the call itself. LG> Remember, the limitations on storing the IP address in the nodelist LG> are a function of MAKENL, not a function of the mailers we're LG> currently using. Hmm. LG> With the work currently going on with the Bink XR* mailers, I acutally have written a quick "makenl workaround" for BTXE which translates every dash in the phone number to a dot, so you won't need NLIP any more with the next XE release :). LG> shouldn't be too difficult to find somebody who's already written LG> additions for the XR* product to add a subsystem to the mailer that LG> would perform this chore. Well, I don't know if anybody out of the XE team has IP programming knowledge. At least I doubt that such a subsystem has already been written, but of course it will be written sooner or later if we decide on this solution :). Viele Gruesse, Tobias. --- * Origin: Ring a dong! hop along! fal lal the willow! (2:2476/418) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #675 [1995] Scn From : Lawrence Garvin 1:106/6018 14 Oct 97 07:47:16 To : Lech Szychowski 15 Oct 97 05:39:54 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Lawrence Garvin: LS> True enough. But - correct me if I'm wrong - you suggest we should LS> allow IP nodes to have arbitrary (ie not falling within LS> fXX.nYY.zZZ.fidonet.org pattern) FQDNs and this will have a LS> negative impact on declaring MXes. Not at all, Lech. I just believe it's the responsibility of the HOSTmaster of -whatever- DNS zone to maintain the MX records. In the event somebody wants to use the default 'fidonet.org' zone, then obviously somebody in that heirarchy will have to maintain MX records for zone:net/node mapped DNS names. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #676 [1995] Scn From : Rune Johansen 2:210/20 12 Oct 97 14:59:16 To : Marco d'Itri 15 Oct 97 05:39:54 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > In the TCP world we have port numbers to select the protocol we want to use. > It's a good idea to run a bbs on the telnet port (maybe behind the standard > telnet daemon like I do) because this protocol is designed for interactive > terminal-like connections. It's a bad idea to force more than one program > to use the same port because there is no need to do that. I think it is a bad idea to force the protocols onto different ports, as they are basically to be communicate with the same program in the end. But, that's my personal opinion. I want to use _one_ port, that receive all the protocols and human callers. I have that today, and we are working on including autodetection of other protocols on the same port as well (BinkP). That also means that we can use BinkP as a mailer session protocol over normal PSTN. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #677 [1995] Scn From : Jesper Tragardh 2:200/108.21 13 Oct 97 16:07:00 To : Rune Johansen 15 Oct 97 05:39:54 Subj : IP-connectivity ------------------------------------------------------------------------------- RJ> system, as I have sent them successfully. The receiver has got a RJ> quota on his email account, and the email is being bounced by the RJ> mailer-daemon on the receiving system, with a note attached saying RJ> that the mailbox is full. Not only will the sender receive a bounce-message. Probably he we also se a "original message follows" which includes the whole packet coded in for instance base-64. A would say that this would be the ultimate definition of "wasting bandwidth". The only reason for making SMTP a transfer protocol would be for the people sitting behind very rigid firewalls. But in that case it probably wouldn't be possible to SMTP-connect directly to the system anyway. Incoming SMTP are probably routed to the mailserver - somewhere in the DMZ. As the definition of "Node" implies a direct connect - these machines cannot be nodes. As points the can probably seek a working solution with their bossnode. /Jesper --- timEd/386 1.10 * Origin: Pinga varandra i IP-trafiken /JL (2:200/108.21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #678 [1995] Scn From : rafal wiosna 2:480/33 14 Oct 97 08:17:32 To : Sean Rima 15 Oct 97 05:39:54 Subj : BinkD - _NOT_ the standard ------------------------------------------------------------------------------- þ (RAF, Sun Oct 12 1997) Sean Rima -> rafal wiosna: SR> EMSI Handshaking is amazingly slow over the net. Good thing it's only done at the begining of a session, not every 10234 nanoseconds. SR> X-Modem is totally unreliable as a standard on the Net. True! That's why we use EMSI, not FTS-0001. SR> And don't forget the cost and size of Vmodem programs. 54.272³vmodem.exe 996³vmodem.ico SR> I have only limited room on the HD that runs my BBS. DEL DOOM*.* - Rafa’ "WXR" WiOS/2na. --- GoldED/2 2.51.A1026+ 30PL2 * Origin: Za’oga windy pozdrawia oczekuj†cych (2:480/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #679 [1995] Scn From : Rune Johansen 2:210/20 12 Oct 97 14:36:02 To : Lech Szychowski 15 Oct 97 05:39:54 Subj : IP-connectivity ------------------------------------------------------------------------------- > Suppose we adopt the idea of declaring online hours in nodelist ("T" flag) > or in DNS records ("TXT" type). Is email encapsulation still necessaty then? > My personal worries are SMTP encapsulation might give us more trouble than > fun... I see a big problem within SMTP encapsulation: I create a bundle that is to be sent to a email address, where I embedd the bundle with some sort of encoding scheme. Then, I send the email off. When the email is sent, I delete the bundles from my system, as I have sent them successfully. The receiver has got a quota on his email account, and the email is being bounced by the mailer-daemon on the receiving system, with a note attached saying that the mailbox is full. The receving party will not get any warnings about this, so they cannot request a rescan of the messages, or the netmails that were lost, without human intervention. With a direct connection, you can automatically sense wether your bundle has been tranferred or not, and you will not delete the bundle until it has been transferred completely. This cannot be done in a reasonable way when using email. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #680 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 15 Oct 97 07:08:24 To : Marco d'Itri Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Marco! On 14 Oct 97 wrote Marco d'Itri to Lothar Behet: >> Therefore at least one handshaking protocol based on nodelist data >> must be required for a node with ip-flags, who has to fulfill the >> requirements according MI> I agree, but *all* nodes (PSTN or IP) should be able to advertise in MI> the nodelist email or ftp service. I always stated, that _additional_ protocols may be announced. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #681 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 15 Oct 97 07:30:40 To : Amir Shabashvili Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Amir! On 13 Oct 97 wrote Amir Shabashvili to Denis McMahon: DM>> technology, becaue this isn't where we debate "can we / should DM>> we", but "how can we". Take the "can we / should we" debate DM>> elsewhere! AS> Ok. AS> Is there some rules & moderator? Is this echo self-moderated? This echo was openend in september by Ward Dossche (Z2C) for discussion about technical integration of ip-nodes into the nodelist. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #682 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 15 Oct 97 07:42:20 To : Yuri Teterin Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Yuri! On 13 Oct 97 wrote Yuri Teterin to Lothar Behet: LB>> Wherefore do you really need ip-only nodes in the nodelist? YT> Yes, we do. Why? LB>> They can participate as point in the same discussions. YT> IP-only nodes are often large echo- and fileecho-hubs How do they deliver the collected data to their downlinks? You can not tell me, that a large system does not support any direct dial-in lines :( Under defined circumstances they may aquire for a pvt listing. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #683 [1995] Snt Loc Scn From : Lothar Behet 2:2446/300 15 Oct 97 07:49:50 To : Mario Mure' Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Mario! On 13 Oct 97 wrote Mario Mure' to Lothar Behet: MM> Tachchen Lothar, :) LB>> Wherefore do you really need ip-only nodes in the nodelist? They LB>> can participate as point in the same discussions. MM> What if this ip-only system is routing netmail/echo to other MM> nodes/points ? Pvt entries are allowed, as routing requires them substantielly. LB>> That was not my action and therefore i can disagree with that now LB>> and not at a later time :) I recommend, that it will disappear LB>> after the test period. MM> It can disappear sooner than now if Ward disagree too MM> But, please let me know if the choice is to not EVER allow ip-only in MM> fidonet nodelist. A node entry, which is not reachable by the most of other members of fidonet, does not serve any purpose in the nodelist for direct communication possibility, which is the major advantage of ftn above i.e. ip. So these entries have to be minimized on international level. The regional importance of a certain system may be noticed in a regional list (i.e. pointlist), as the international level does not interfere with it. A pointlist contains legal ftn-addresses and additional its own phonenumber and flags, so they can be called directly within their area. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/300) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #684 [1995] Snt Loc Scn From : Lothar Behet 2:2446/300 15 Oct 97 08:03:56 To : Yuri Teterin Subj : vmodem ------------------------------------------------------------------------------- Hello Yuri! On 13 Oct 97 wrote Yuri Teterin to Maciej Grzeszczuk: mg>> both telnet (in your meaning) and vmodem are the same protocol. YT> Once more: they aren't. These are quite different protocols. Just YT> try to make telnet to your telnet port 60177 and then - to vmodem port YT> 3142 of any vmodem-node, and you'll see the difference. Vmodem on port 3142 will fail in most cases, as the default (and mostly used) port is 3141 (if you are talking about Vmodem from the SIO-package for OS/2). Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/300) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #685 [1995] Scn From : Marco d'Itri 2:335/680.666 15 Oct 97 23:19:22 To : Dmitry Arsh 16 Oct 97 22:18:30 Subj : Re: IP-access ------------------------------------------------------------------------------- Dmitry.Arsh@p1.f21.n5100.z2.fidonet.org wrote: >.fidonet.org. I.e. if there will be any e-mail from Internet to, say, >somebody@f21.n5100.z2.fidonet.org and my IP is listed in the fidonet.org >domain, I have to answer on port 25 to get this e-mail. You will have to use MX RRs. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #686 [1995] Scn From : Marco d'Itri 2:335/680.666 15 Oct 97 23:10:40 To : Rune Johansen 16 Oct 97 22:18:30 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >I think it is a bad idea to force the protocols onto different ports, as they >are basically to be communicate with the same program in the end. They are not. Every service needs his own port numerb. >personal opinion. I want to use _one_ port, that receive all the protocols >and This is your own problem. People will not mess with their standard daemons for no good reason. >of other protocols on the same port as well (BinkP). That also means that we >can use BinkP as a mailer session protocol over normal PSTN. Argus already does that. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #687 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 15 Oct 97 23:15:56 To : Lothar Behet 16 Oct 97 22:18:30 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Lothar.Behet@f300.n2446.z2.fidonet.org wrote: >A node entry, which is not reachable by the most of other members of fidonet, >does not serve any purpose in the nodelist for direct communication >possibility, which is the major advantage of ftn above i.e. ip. Do you want to be points ISDN nodes too? -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #688 [1995] Scn From : Marco d'Itri 2:335/680.666 15 Oct 97 23:12:52 To : Gisbert Rudolph 16 Oct 97 22:18:30 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Gisbert.Rudolph@f2161.n2443.z2.fidonet.org wrote: >IP: >IP: If we exceed the limit on flags length we could as well use the extended nodelist format. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #689 [1995] Scn From : Marco d'Itri 2:335/680.666 15 Oct 97 23:17:50 To : Rune Johansen 16 Oct 97 22:18:30 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >bundle with some sort of encoding scheme. Then, I send the email off. When >the email is sent, I delete the bundles from my system, as I have sent them You shouldn't. You don't know if the recipient received them. >transferred completely. This cannot be done in a reasonable way when using >email. This is not true. You just have to use a good protocol. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #690 [1995] Scn From : Amir Shabashvili 2:5049/12 14 Oct 97 11:04:28 To : Lech Szychowski 17 Oct 97 05:37:30 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Lech! Replying to a message from Lech Szychowski to Lothar Behet: LS> IMHO you are wrong. My system is reachable from the Internet as three LS> IP addresses - and the reason behind it is it has three different LS> physical links from different ISPs, for sake of redundancy and LS> reliability. Is it full-time links with fixed IP-addresses? Or it is dial-up connection with getting random IP address from ISP's address spool? That's different things. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #691 [1995] Scn From : Pedro Lima 2:362/21 14 Oct 97 16:51:20 To : Denis McMahon 17 Oct 97 05:37:30 Subj : A bit of steering ... ------------------------------------------------------------------------------- DM> Will you have a replacement coded by next week then? :-) :-) DM> If nyone hd the source code, or was in touch with Ben B and it's still DM> available, maybe we can recode makenl to do what we want, but until we DM> know what we want we can't do it, and we my have to start from "void DM> main(void){}" So let us decide which field to use and what should we put in it. Namely, I'd like to know how nodelist compilers behave with dots in the phone field. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #692 [1995] Rcv Scn From : Pedro Lima 2:362/21 15 Oct 97 00:20:12 To : Lothar Behet 17 Oct 97 05:37:30 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hi, PL>> Temptative. LB> :) Oops, I meant "tempting", sorry. :-) LB> At first you have to replace Makenl on every instance, were "new data" LB> is processed. That's why it should be simple. Only the places where IP nodes are required will need to replace MakeNL. LB> In second order you have to assure, that every LB> nodelistcompiler (even Frontdoor and for the Amiga/ST-system) can LB> handle those data in an appropriate way. At least these programs are LB> used by nodes (mebers of Fidonet, you remeber?:), which must not be LB> locked up by a change, which was not approved on _all_ systems. Yes, we should be careful. The current Z2 test-nodes seem to be compatible (of course), but unless some known problem exists, I'd like to see other formats being tested (like using FQDNs in the phone field, direct quad-notation or the IPv6 notation). LB> Is the system name not in a certain way equivalent? It could be similar, if the IP address was listed in the phone field as well. :-) LB> Maybe, that tomorrow we already have an extended nodelistformat, which LB> supports any kind of communication access. I would appreciate that, LB> but integration of IP-access is a problem today and should be handled LB> as soon as possible. Implementing an extended format, as desireable as it may be, is very difficult to do, as it implies every node changing its software. If the current format can be used to handle several communication technologies, then I think it would be a mistake to complicate things. A different nodelist entry for a different technology seems the best and simplest approach for now, IMHO. LB> IMHO ip-access must be only an additional flag in the nodelist (!), as LB> this the reference worldwide. Which entries circulate in regional or LB> local lists (pointlists, etc.) does not have influence on LB> international level. But the attempt is to allow IP nodes, not only IP connectivity to the existant ones... LB> If we would allow any kind of communication access to Fido on a too LB> low level, the nodelist will grow in an extensive way. That's why I suggested that nodelist subsets were made available. But I'd say that the nodelist growth won't be that dramatical, even if the nodelist growed say three times larger than it is today it will still be manageable by the average system. LB> But "IP" itself could sign the nodelist conversion utility to use the LB> contents of the system name (i.e.) in place of the phone number. Yes, it could. LB> That is true, it will last a certain time, before the extended LB> nodelist can be used. But if we always wait for the better solution, we LB> would never get one step further :) Yes, I agree. Using a format for a purpose which wasn't intended in its creation is always a patch. Let's try to make this patch as comfortable and simple as possible to address the problem, and then we can discuss a new format. LB> I do either, but others were constantly mourning about possible LB> problems. So why not create a solution, which does not interfere with LB> actual, widely used system setups? I'm all for it. But I'm also aware that replacing the nodelist format is an extremely difficult thing to accomplish and that not only we're going to spend a great deal of time agreeing on a new format, as we're going to spend even more time implementing the change. On the other hand, the necessity to accomodate other communication technologies may not have this kind of time, so we need to foresee the use of the current format. Placing the IP address in the system name field may be a solution for solving the IP problem, but it creates an inconsistency in the fields' purposes which is not expandable for the use of other technologies, if we need to. LB> as a standard is defined, the tools for this will be public in a LB> short time. Yes, I agree. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #693 [1995] Rcv Scn From : Rune Johansen 2:210/20 15 Oct 97 02:42:18 To : Lothar Behet 17 Oct 97 05:37:32 Subj : A bit of steering ... ------------------------------------------------------------------------------- >With a wisely choosen nodelist standard the ip-lines can be listed in the same >entry as normal pstn lines, to keep the nodelist at on affordable size for eac > sysop. I don't remember: Have you proposed such a wisely chosen standard here? If so, could you netmail it to me, as it seems I cannot find it. If not, would you mind posting such a proposal here? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #694 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 02:39:36 To : Lech Szychowski 17 Oct 97 05:37:32 Subj : A bit of steering ... ------------------------------------------------------------------------------- >> I believe strongly that there is no real need for multiline-ip-systems >> in the nodelist. > IMHO you are wrong. My system is reachable from the Internet as three > IP addresses - and the reason behind it is it has three different > physical links from different ISPs, for sake of redundancy and > reliability. And I think it really makes sense to have all the > IP addresses listed, to provide as much connectivity as possible. You are a exception to the rule. :-)) You have one of two choices: 1) List three AKA's, with different IP addresses or FQDN's on them. People can then select wich QOS (Quality Of Service) they want to use. 2) List all three IP's under one FQDN, with only one AKA. Disadvantage is that people cannot control where they are connectiong to. Most people would prefer solution number 2, and if they want to use you as a regular connection, they would configure their system to use another address, informed by you, to use the most convenient address to your system. Solution number 2 would also be used on a node that has got several IP addresses, with load sharing by using round-robin DNS. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #695 [1995] Scn From : Fyodor Ustinov 2:5020/79 14 Oct 97 11:38:44 To : Lech Szychowski 17 Oct 97 05:37:32 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hi, Lech! Sunday October 12 1997, Lech Szychowski writes to Sean Rima: LS> OK, so let's say we spare 3 seconds on each session. Statistic of my node: ------------ Total Sessions : 5600 ------------ 5600*3/60/60 ~= 5 Hours.... With best regards, Fyodor --- GoldED/W32 3.00.Alpha5 UNREG * Origin: U.F.M Station [ufm@prospect.com.ru, 1086856#ICQ] (2:5020/79) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #696 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 02:23:52 To : Lech Szychowski 17 Oct 97 05:37:32 Subj : A bit of steering ... ------------------------------------------------------------------------------- > the same system, which means it will try to use just the IP address > corresponding to the Fido address specified in the mail packet. We > already see this happen with multiline nodes... Yes, that _is_ a problem with multiline nodes that don't have a hunt-group for their phone lines. Seen from the nodelist view, all nodes are separate systems. But then again, it would be too much of cleaning up the closet by trying to impose you-must-have-PSTN-if-you-want-to-be-a-IP-node when we already have this all over the world. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #697 [1995] Rcv Scn From : Lech Szychowski 2:480/33.7 15 Oct 97 04:21:00 To : Lothar Behet 17 Oct 97 05:37:32 Subj : A bit of steering ... ------------------------------------------------------------------------------- > If take a close look into the nodelist, than you will see, that there > i.e. systems operated via ISDN-lines (with numbers in direct order), who > "need" a nodelist entry for each line. The unfortunate truth is current nodelist format does not provide us with any means to indicate one system has more than one phone line/number. And if we want to define a new standard we should avoid repeating this mistake as hard as possible. > With fqdn the machines in a subnet (same domain) can be addressed in one > entry, as long as the protocols and other flags are equivalent. I'm afraid I don't get you. > With a wisely choosen nodelist standard the ip-lines can be listed in > the same entry as normal pstn lines, to keep the nodelist at on > affordable size for each sysop. The big question here IMHO is "do we really need to put into nodelist information that is completely outside the area of interest for PSTN nodes?". 3D/4D address is already there, and if we either indicate a domain or use the default "fidonet.org" we can very easily construct a unique FQDN for each system. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #698 [1995] Scn From : Sean Rima 2:252/358 14 Oct 97 06:59:00 To : maciej grzeszczuk 17 Oct 97 05:37:32 Subj : Re: BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hiya, maciej! At 12 Oct 97 20:33:49, maciej grzeszczuk wrote to Sean Rima: mg> From: maciej grzeszczuk mg> Fri, 10 Oct 97 18:35:00 +0200 Sean Rima napisal byl w fido.ip_connect: >> Why used Telephone based protocols over the Net. It is like having a >> Porsche with the engine from a Robin Reliant. Most telephone based >> protocols would not handle the weirdness of the net. mg> please, in daily connections, use your binkd as often as you wish. mg> but also support vmodem connections, in case someone would like to connect mg> to your system. someone using other mailer, that binkd. To add Vmodem support, I would need another mailer. And that means more space taken by programs and less to mail space. When I started my Ipmailer, a week prior to this whole discussion, my intention was to open the world of FidoNet to the people who have left BBS for the Net. I have friends who liked fido but wished it were on the Net. They are happy and I am happy. They have managed to stay in touch with old friends in BBS land and importantly for me, it has seen an increase in my mail traffic. As others have said, I think maybe we should concentrate o getting Ipmailers into the nodelist, qualifying each entry with a Flag showing what type of connections they support. Sean Rima Sysop DSP BBS and Ipmailer --- QDED alpha v3.57pl8/ FreeBSD * Origin: DSP BBS Ipmailer Reading England (2:252/358) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #699 [1995] Scn From : Yuri Teterin 2:5030/239 14 Oct 97 23:02:40 To : Lawrence Garvin 17 Oct 97 05:37:32 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hello, Lawrence ! Sun Oct 12 1997 Lawrence Garvin writes to Slava Filimonov: LG> Slava... I think the mistake in interpretation is the use of "vmodem" as a LG> generic term. LG> I suspect the proper terminology is a telnetd/fts-0001 capable node. LG> While you are correct that VModem, per se, is not free, there are telnetd LG> compatible implementations on every platform that are. Really? Can you give references for each platform (OS/2, Win31, Win95, WinNT, preferable with URL)? If such free implementations really exists and do not require a lot of system resources, it can change the situation. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #700 [1995] Scn From : Yuri Teterin 2:5030/239 14 Oct 97 23:32:36 To : Maciej Grzeszczuk 17 Oct 97 05:37:32 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hello, Maciej ! Sun Oct 12 1997 maciej grzeszczuk writes to Sean Rima: mg> please, in daily connections, use your binkd as often as you wish. mg> but also support vmodem connections, in case someone would like to connect mg> to your system. someone using other mailer, that binkd. We did not got as yet serious proofs that vmodem is more common and more appropriate than binkp. And without such proofs your statement is sinseless. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #701 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 03:05:08 To : Lawrence Garvin 17 Oct 97 05:37:32 Subj : A bit of steering ... ------------------------------------------------------------------------------- > I'd like to be able to list -both- mailers at the same node number. > Using some field -other- than the telno field is the only functional way to > accomplish this. > Your previous suggestion to use the NAMEfield for a FQDN is a better one, I > think, than trying to put the IP address in the telno field. Besides, the > latter would require a rewrite of MAKENL or a new nodelist builder which all >coordinators would have to agree to utilize. The former requires NO changes in > existing nodelist utilities AT ALL! So, you are suggesting this: Node with both PSTN/ISDN and IP address: ,123,fully.domain.name.her,....,47-12345678,9600,flags,U,IP Node with IP only: ,Pvt,fully.domain.name.her,....,-Unpublished-,300,flags,U,IP It will require rewrite of nodelist index compilers and mailers to utilitize the system name field, if they see the IP flag, if they prefer to use IP as transport instead of PSTN or ISDN. Yes, I can see that the complaints about not being able to list their "Bazooka BBS" in the system name woul be superseded by the extra functionality. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #702 [1995] Scn From : Sean Rima 2:252/358 14 Oct 97 06:46:34 To : Lech Szychowski 17 Oct 97 05:37:32 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hiya, Lech! At 12 Oct 97 02:32:00, Lech Szychowski wrote to Sean Rima: >> LS> How big the session negotiation/handshake overhead in everyday LS> [...] >> An average EMSI connection of the Net takes me around 3-5 seconds. An >> average BinkP is .5 - 1 second. And that is extensive use. My Ipmailer LS> OK, so let's say we spare 3 seconds on each session. These three seconds LS> give us time to transmit something between 2KB and 20KB, 8KB being quite LS> a good number if we are talking about dialup modem connections. That's LS> not much. LS> Which, of course, is not supposed to mean it's not worth fighting for :) I think as others have said that it is getting Ipmailers into the nodelist and not the protocols that is being debated. Although, the Vmodem V BinkP is interesting. But I like my 3 secs. I connect around 20 times a day to collect mail. which is roughly a minute per day, 356 minutes per year .......... Sean Rima Sysop DSP BBS and Ipmailer --- QDED alpha v3.57pl8/ FreeBSD * Origin: DSP BBS Ipmailer Reading England (2:252/358) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #703 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 02:11:52 To : Dieter Ringhofer 17 Oct 97 05:37:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >There's no need to introduce a new nodelist format if people choose the correc > place (read: field) to put needed data in. The last 'checkpoint' for every > mailer are the flags reflecting capabilities of called system. Oh, so true. By using the flags, PSTN-only nodes can prohibit "calling" IP-only nodes. By using flags, ISDN-only nodes can prohibit calling non-ISDN nodes. Simple and understandable. Example: At my primary system (210/20) I have one ISDN and one PSTN line. With my PSTN node I don't call systems that have ISDN-type flags. I would not call nodes that got a IP flag either. If I want to mail a ISDN system, I use my ISDN node. If I want to mail a IP system, I cannot, so I route it through my uplink, that I have a _established_ connection to, via one of the two methods available to me. Earlier, when I had PSTN only, I could not call ISDN-only nodes, so I did not call them. I have been involved with discussions around the wrong things here in IP_CONNECT, but I too see that some of us have missed the subject of this echo. It is not about what protocol should be minimum (why should there?) for IP nodes. It is about how we can use the nodelist to indicate where you can contact a IP-node, and with wich protocol. My suggestion is that if you have one node with PSTN or ISDN (or both), and also have the possibility to have a IP node online on the internet for a fixed period of time, or CM, you would need another AKA. This AKA would be marked with a flag that said "This node has got a internet address (IP/FQDN) in the phone field", for example "IP". If you are a node that has got dial-up access to the internet, but you don't have the possibility to be online 24h or in a Txy timeslot every day, you should not consider being listed as a IP node, but you can use the information of the nodes that _are_ capable of this, to exchange mail with these, or being their downlinks. I have expressed my "proposal" on these flags here earlier, and I still stand by these. It _will_ require a rewrite of MakeNL or a substitute for it, plus a rewrite of FTS-0005 to allow for additional characters in the "phone" field of the nodelist. In my region (21) we are three people using the MakeNL software (or equivalent). It is not a tool used by every node in a normal situation. Only by those who creates segments and diffs, and then again, the "new" software would only be used by those having their segments incorporated with IP nodes. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #704 [1995] Scn From : maciej grzeszczuk 2:480/70 15 Oct 97 00:56:20 To : Yuri Teterin 17 Oct 97 05:37:36 Subj : Re: binkd vs vmodem ------------------------------------------------------------------------------- From: maciej grzeszczuk Sun, 12 Oct 97 21:34:23 +0200 Yuri Teterin napisal byl w fido.ip_connect: > Your mailer (ifcico 2.9) is _not_ vmodem-compatible (if you speak about > protocol). sure about that? iftelnetd on port 60177 is allowing proper incoming vmodem connections. for outgoing vmodem connection i use ifcico-tx. everything goes just fine. 604 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: lubie wieczorami chodzic do parku z ciupaga i sra (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #705 [1995] Scn From : Yuri Teterin 2:5030/239 14 Oct 97 23:53:48 To : Lawrence Garvin 17 Oct 97 05:37:36 Subj : Flags in nodelist ------------------------------------------------------------------------------- Hello, Lawrence ! Sun Oct 12 1997 Lawrence Garvin writes to Rune Johansen: LG> Rune... here's a thought... while FIDONET.ORG may be dependent upon the LG> "Internet" -- there's also nothing keeping Fidonet(tm) from setting up our LG> own proprietary ROOT SERVER in the Top Level Domain .FIDONET or .FIDO We have extensively discussed such a possibility in Russia half a year ago - and it became clear that this solution will lead to a lot of troubles. That is why it was decided to register and use domain fidonat.net for this purpuses (that was much more easy than to try to modify fidonet.org, which has now status of domain for fido-internet gateways). Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #706 [1995] Scn From : Lech Szychowski 2:480/33.7 15 Oct 97 04:13:00 To : Dmitry Arsh 17 Oct 97 05:37:36 Subj : IP-access ------------------------------------------------------------------------------- > AFAIU, you need something answering SMTP on port 25 to be listed in > .fidonet.org. Listed as what? > I.e. if there will be any e-mail from Internet to, say, > somebody@f21.n5100.z2.fidonet.org and my IP is listed in the > fidonet.org domain, I have to answer on port 25 to get this e-mail. This would break all standards for sending mail. MTA has to look up the MX record(s) for the address first - and only if there is no MX listed it is supposed to look for the A record(s). > I'm afraid there are nodes with IP which cannot do this. There is a whole lot of FQDNs that are not running SMTP MTAs (actually, no MTAs at all). They either have some other system listed as their MX or are not able to accept any mail addressed to them. I think I know the reason behind your statement. Since MTA first looks for the MX record(s), every *.fidonet.org FQDN that we want to be able to address mail to has to have either MX or A record. To deal with such situation hostamsters use wildcard MX records, specifying MXes for the whole networks/regions. But such records are not valid for FQDNs that have any other data associated with them. Suppose a system is covered by a wildcard MX record. Then at the very moment we add any record (A being one of them, and having the IP address listed is nothing else than having an A record) the previously matching MX records stops to match. Of course we can add an explicit MX record for this FQDN and this record may point to the same MX as the wildcard one. But if we add just the A one, it breaks the mechanism down; MTAs will try to look for the MX record and finding none they will in turn look for an A record - this lookup will be successful so MTAs will try to connect to MTA on port 25 at the address listed in the A record and unless this system runs the MTA listening on that port they will fail. So in a way you are right: if a system is to have its address listed it has eiter to run the listening MTA or have its MX listed explicitly as well as the address - or mail addressed to this system will be undeliverable. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #707 [1995] Scn From : Slava Filimonov 2:469/33 13 Oct 97 13:31:04 To : maciej grzeszczuk 17 Oct 97 05:37:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello maciej! 10 Oct 97 14:09, maciej grzeszczuk wrote to Slava Filimonov: >> Just alter your outbound to bink-style and keep 'em all - old >> mailer, binkd, your old mailer with vmodem. mg> listen. vmodem is just a tunnel for ANY mailer. so don't tell me that mg> my 'old mailer with vmodem' is good or bad, if you don't know what are mg> you talking about. we've already heard that your binkp is the most mg> wonderfull thing, but how can you say such things if you didn't really mg> seen anything working with vmodem, huh? Listen, i've used vmodem for a long time with different mailers/protocols. I can say for both - vmodem for fido and binkd for fido. But you can't - cause u never used binkd yourself. I hate to promote myself, but i'm in fido now for a 6 yrs and i used to work with lots mailers/packers/readers and all outboud styles. I'm also a programmer and i know how this fido works, cause i'm author of fido point mailreader/tosser/scanner. Some folks still use it now. As former hub for my net i know all hub/routing problems across our ex-ussr networks. As a programmer, i know well, what this vmodem doing and how this whole thing works. -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #708 [1995] Scn From : Yuri Teterin 2:5030/239 14 Oct 97 22:37:36 To : Lawrence Garvin 17 Oct 97 05:37:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lawrence ! Sun Oct 12 1997 Lawrence Garvin writes to Jesper Tragardh: LG> Keep using BinkP to do -real- echomail/filebone transfers, but use the LG> TelnetD/FTS-0001 session for ZMH compliance -- that way everybody is LG> happy. Nobody will be happy, I think. A lot of IP-sysops were happy to get rid of VModem after appearance of BinkD, and now nobody will fall back to vmodem, which has no free implementations for main platforms (OS/2, Win95, WinNT) and will be really _never_ used at their systems (like FTS-0001 is never used now; but FTS-0001 at least does not need extra money for registration, extra 200-400K of disk space and extra memory, as Vmodem does). Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #709 [1995] Scn From : Slava Filimonov 2:469/33 13 Oct 97 13:31:50 To : maciej grzeszczuk 17 Oct 97 05:37:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello maciej! 10 Oct 97 14:16, maciej grzeszczuk wrote to Slava Filimonov: >> >> bwt, this echo comes to me through binkd. >> mg> this echo comes to me through raw emsi via tcp. >> Now tell me your link capacity and avg cps ? mg> 64kbs, 14159cps, transferring zipped echomail, 155kbytes package. This is unreal figure. No doubt, why you so sure about your mailer with vmodem. It will be better, if fiures will show dest nodes (at least 10 in different nets)/ avg transferred bytes/ average cps. Both for vmodem and binkd and for at least two platforms - *nix and win32 for exaple. I'm pretty sure, there will be no winner named 'vmodem'. -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #710 [1995] Scn From : Sean Rima 2:252/358 14 Oct 97 06:49:04 To : Lech Szychowski 17 Oct 97 05:37:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hiya, Lech! At 12 Oct 97 02:33:00, Lech Szychowski wrote to Sean Rima: >>>> So do I. But ruling out a protocol that is in daily use by over >>>> 100 Ipmailers seems the wrong way to go. LS> One more thing: it's not about ruling it out or declaring "not to be LS> used". It's just about not making it a minimal standard that has to LS> be supported by every node. Not sure if that will be required protocol wise. In a nodelist all you need to do is use the U, then the protocol. If you cannot connect to a node, then you route the mail. Can you imagine if this debate started today and people wanted the minimum to be FTS-0001, I think you would find that a lot of people would be against YooHoo as it is painsfully slow. Sean Rima Sysop DSP BBS and Ipmailer --- QDED alpha v3.57pl8/ FreeBSD * Origin: DSP BBS Ipmailer Reading England (2:252/358) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #711 [1995] Rcv Scn From : Sean Rima 2:252/358 14 Oct 97 07:04:42 To : Lothar Behet 17 Oct 97 05:37:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hiya, Lothar! At 13 Oct 97 08:46:18, Lothar Behet wrote to maciej grzeszczuk: LB> Hello maciej! LB> On 10 Oct 97 wrote maciej grzeszczuk to Lothar Behet: mg>> sure. and binkd (binkp) isn't such standard. it's only supported by mg>> small (2 i heard, third is under construction) number of mailers. LB> BinkD itself is available for any pc-based operating systems except DOS LB> and in compiled versions for different unices and linux. Furthermore the LB> source is publicly available. As the protcol specufication is public, it LB> is (and will be supported by more) other programs. LB> It is not my intentipn to define one single program or protocol as LB> fido-compliant, but offer ip-access as additional medium for a maximum LB> number of nodes. I suppose there is no real problem with porting BinkD to dos. It is just making it talk to winsock (opps) sock of some type. Porting into existing mailers is very simple. I know someone who did it in 3 days. So maybe if we also talk to the authors of existing mailers, T-Mail McMail etc then maybe Ipmail will get off the ground faster. Anyway, I have been at work all night, I need sleep. Sean Rima Sysop DSP BBS and Ipmailer --- QDED alpha v3.57pl8/ FreeBSD * Origin: DSP BBS Ipmailer Reading England (2:252/358) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #712 [1995] Scn From : maciej grzeszczuk 2:480/70 15 Oct 97 00:54:02 To : Igor Bilyi 17 Oct 97 05:37:36 Subj : Re: binkd vs vmodem ------------------------------------------------------------------------------- From: maciej grzeszczuk Sat, 11 Oct 97 20:21:01 +0200 Igor Bilyi napisal byl w fido.ip_connect: > mg> if you can connect with your binkd to my vmodem / ifcico / telnet > mg> compatible mailers (listening on ports 60177 and 60179 of > mg> zwieracz.psych.uw.edu.pl)... > ok, I'l try to send to you binkd091.zip if you do, i'll stop arguing about the incompatibility. 603 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: prefabet warszawa (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #713 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 02:30:56 To : Lech Szychowski 17 Oct 97 05:37:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> I don't want to waste money because I must use a suboptimal protocol. > Nobody is trying to force you to use vmodem for your everyday > mail traffic. Keep on using anything you and your links agree > upon - but also support the vmodem as a "lowest common denominator", > just in case someone wants to connect to your system usubg this > protocol. I have been involved in this discussion, by saying _if_ we must have a lowest common denominator protocol to connect to. I don't think there should be any, as the flags would imply what protocols are available on the IP node in question. The only thing a IP node needs, according to the policy documents, are a FTS-0001 capable "thingy" in the other end, at least. It is very difficult to change this policy (several has tried). According to my interpretation of discussions here and elsewhere, a BinkP-only IP-only node does not meet minimum requirements for being a public node in Fidonet. A FTS-0001 IP-only node _does_ meet the requirement, due to the FTS-0001 part. Wether it uses telnet, ifcico, SIO's VModem or raw TCP for its connection, does not matter. If it has got raw BinkP in addition, that's great. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #714 [1995] Scn From : Dima Maloff 2:5020/79.31 15 Oct 97 13:56:00 To : Lech Szychowski 17 Oct 97 05:37:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- * Crossposted in IP_CONNECT * Crossposted in SU.IP.SYSOP Sunday October 12 1997 02:10, Lech Szychowski wrote to Marco d'Itri: LS> Nobody is trying to force you to use vmodem for your everyday LS> mail traffic. Keep on using anything you and your links agree LS> upon - but also support the vmodem as a "lowest common denominator", LS> just in case someone wants to connect to your system usubg this LS> protocol. Lech, vmodem costs to much money (talking about Windows and OS/2 users: they should a) register a virtual modem driver; b) pay for more memory (needed to run additional mailer smoothly)), but TOTALLY USELESS for everyday use here (And vmodem has a bigger "cost of ownership"). Lech, don't you want to force 200+ xUSSR sysops to pay money just because you're too lazy to try binkd or argus? LS> Your PSTN mailer supports pure/raw FTS-0001 sessions, right? But LS> no one says you _have_ to use _just_this_ flavor of sessions. But supporting FTS-1 makes NO additional costs for a Fidonet sysop, right? --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5020/79.31) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #715 [1995] Scn From : Dima Maloff 2:5020/79.31 15 Oct 97 13:57:00 To : Lech Szychowski 17 Oct 97 05:37:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- * Crossposted in IP_CONNECT * Crossposted in SU.IP.SYSOP Sunday October 12 1997 02:33, Lech Szychowski wrote to Sean Rima: >>>> So do I. But ruling out a protocol that is in daily use by over >>>> 100 Ipmailers seems the wrong way to go. LS> One more thing: it's not about ruling it out or declaring "not to be LS> used". It's just about not making it a minimal standard that has to LS> be supported by every node. Lech, selecting Vmodem as a minimum will force those (I think, 200+) sysops to change something in their systems. Can you show me a BIGGER vmodem net, you are fighting for? Why, oh why, if in your theory, vmodem is fine, the biggest fido-over-IP community switched (in a month or so) from Vmodem to Binkp last fall?! --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5020/79.31) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #716 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 02:32:52 To : Nick Soveiko 17 Oct 97 05:37:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > in order to maintain this just-in-case capability a sysop running os/2 or win > nt has to go out and *buy* appropriate software. afaik, vmodem isn't free and > neither are it's analogs for many other platforms. I think I see a confusion between "Vmodem" and "vmodem", as "Vmodem" in Ray Gwinn's SIO package, and "vmodem" as a virtual modem driver that uses a form for transportation (IP in these cases). --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #717 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 03:23:14 To : Lawrence Garvin 17 Oct 97 05:37:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > If I understand BinkP correctly, it does NOT negotiate any FTS-0001 session, > therefore, in the strictest sense of the word, is not Fidonet Policy 4 > compliant as a minimum required standard. When thinking about it, you _could_ use BinkP to transfer the packets that make up a FTS-0001 session :-) The mailers involved would then have to react on the packets transferred immediately to "do tha thing". So, a BinkP-only node would have to implement this to be policy compliant. When this is done, there would be no objections. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #718 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 03:42:06 To : maciej grzeszczuk 17 Oct 97 05:37:36 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Huh? Why not? Or do you think of "log in" as "log into unix"? > i mean we shouldn't allow getty's logon procedure between the handshaking. Aha. If getty was rewritten to do mailer handshake, then it would be OK. Almost like if you telnet to fix.no, although the "normal" getty login is moved to another port, and the BBS with mailer is placed on port 23. Soon they will have other protocols there too. :-) --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #719 [1995] Scn From : Amir Shabashvili 2:5049/12 14 Oct 97 10:50:44 To : Marco d'Itri 17 Oct 97 05:37:36 Subj : IP addressing ------------------------------------------------------------------------------- Hello Marco! Replying to a message from Marco d'Itri to Eugene Gladchenko: >> something like ",U,IP:194.65.123.45" or ",U,IP:ufm.prospect.com.ru". Do >> you agree that would be compatible with all existent and future >> fidonet software? Md> No. This way we will run out of space in the flags field. If we do, we Md> could as well use the extended nodelist format. - extended nodelist format don't compatible with some nodelist compilers - do you know any limitation for the flags field space in nodelist? Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #720 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 03:17:00 To : Lawrence Garvin 17 Oct 97 05:37:36 Subj : IP-access ------------------------------------------------------------------------------- It's beside the scope of this echo, but... > I'm kind of fascinated that uucp is even in the discussion. I thought it had > been abandoned years ago. It's coming back in the Internet world too. I work for a company that does a lot of stuff regarding Internet and mail and our customers. For now, the only viable mail transfer protocol for companies that has got dial-up access to the internet, via a PPP-capable router, and gets a IP address assigned at connection, is UUCP, for their own domain. Why not use POP3 to fetch the mail? Because in POP3 you loose the envelope of a email, so you cannot be sure that the receiver in the email header lines are the correct receiver. In UUCP email you keep the information via the rmail command in the C file. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #721 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 03:33:02 To : Lawrence Garvin 17 Oct 97 05:37:36 Subj : Flags in nodelist ------------------------------------------------------------------------------- > I highly doubt anybody's going to start playing games with the ownership of > domain names. :) Ya never know :-)) > Rune... here's a thought... while FIDONET.ORG may be dependent upon the >"Internet" -- there's also nothing keeping Fidonet(tm) from setting up our own > proprietary ROOT SERVER in the Top Level Domain .FIDONET or .FIDO >Since anybody needing to resolve a name in that domain would have access to th >IP address of the ROOT servers -- it's always possible that Fidonet could have > exclusive control of its own internal DNS system. The only drawback with this (discussed thoroughly with the AlterNic incident on Usenet _and_ in the TCPIP echo) is: The DNS servers maintaining the querys by "our" members would have to point to "our" root servers to get them resolved. To be sure that "we" are being resolved correctly all the time, we need them to point _all_ their root entries to us, and we would point them to Internic's root servers for queries outside our FIDONET or FIDO root domains. That way they would get a answer from us to go there-and-there for com., org., etc. domains. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #722 [1995] Scn From : Lech Szychowski 2:480/33.7 15 Oct 97 04:26:00 To : Jesper Tragardh 17 Oct 97 05:37:38 Subj : IP-connectivity ------------------------------------------------------------------------------- > Not only will the sender receive a bounce-message. Probably he we also > se a "original message follows" which includes the whole packet coded in > for instance base-64. Nope. I believe most modern MTAs can be configured to return no more than a given number of lines in a "delivery failed" warning message. And postmasters do that often. But in general I do agree - SMTP as encapsulation has disadvantages so serious that it IMHO should not be considered seriously. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #723 [1995] Scn From : Slava Filimonov 2:469/33 13 Oct 97 13:08:58 To : Marco d'Itri 17 Oct 97 05:37:38 Subj : IP-access ------------------------------------------------------------------------------- Hello Marco! 10 Oct 97 23:37, Marco d'Itri wrote to Slava Filimonov: >> MI> If we have to radically change the nodelist we could use the >> MI> extended nodelist proposal, it address this problem even >> MI> better. >> ...And why not to give up with nodelist for ip completely ? Instead >> put MI> Because we would have to modify not just the nodelist compiler, but MI> the mailer and the vmodem-like driver too. A DNS based solution can't MI> work with current software. We're moving too fast towards strong fido-over ip realization. We can develop to suit best our needs BinkP and it's realization - binkd. So we can change both to adopt new stratgy - dns based routing very fast. and we can't wait for years, when new vmodem-like driver will came out. We can't change software, what is not supposed to work on ip. Imaginge that nonsense - thanks to vmodem it's possible to use old software over ip. And then one realized, that we're loosing internet advantages for sake of emulation. >> Instead simplifying fido-over-ip we're just increasing complexity of >> existing software! And even paying for it!!! That's my point. got it? There's nothing wrong with old software. Use it. but not for ip. You still have abitiy to send mail to ip-systems by snail fido way. Want use ip ? Then use new software. isn't it simple or what? -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #724 [1995] Scn From : Yuri Teterin 2:5030/239 14 Oct 97 22:00:26 To : Lawrence Garvin 17 Oct 97 05:37:38 Subj : IP-access ------------------------------------------------------------------------------- Hello, Lawrence ! Sun Oct 12 1997 Lawrence Garvin writes to Lech Szychowski: LS>> What you seem to talk about is a mobile system. When I wrote LS>> "multiple-homed" I meant one system that has three network LS>> interfaces (all of them permanently/simultanously active). LG> Lech, I think the simple answer to this is just multiple nodelist entries, LG> just as we do now if one has multiple telnos on a node. This is not a nice solution. First of all, only very narrow circle of direct links will know, that two (three, four, ...) nodelist entries belong really to one node. Secondary, in this case the nodelist grows rapidly. And after all - I have 8 phone lines with different phonenumbers and 3 different IP addresses at my station - so I should have 11 AKAs? So it would be much more convenient if multiple lines (both phones and IPs, may be ISDN and so on) were present at one line of nodelist. There are suggestions for such nodelist extensions, which were discussed in Russian sysop conferences during last 1.5 years, and it would be interesting to discuss them here too - but somewhat later, or in other conference. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #725 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 02:20:00 To : Dmitry Arsh 17 Oct 97 05:37:38 Subj : Re: IP-access ------------------------------------------------------------------------------- > AFAIU, you need something answering SMTP on port 25 to be listed in > .fidonet.org. I.e. if there will be any e-mail from Internet to, say, > somebody@f21.n5100.z2.fidonet.org and my IP is listed in the fidonet.org > domain, I have to answer on port 25 to get this e-mail. > I'm afraid there are nodes with IP which cannot do this. If the nodes with IP cannot do this, a MX record for the node would override this, telling them to send the mails to the host in the MX record instead. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #726 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 03:10:28 To : Lawrence Garvin 17 Oct 97 05:37:38 Subj : IP-access ------------------------------------------------------------------------------- > zonefile. (I am, of course, assuming that the hostmaster at Z2.FIDONET.ORG is > going to be willing to delegate subdomains to each Region). Why should he not? If, by delegating the NS responsibility, this would offload the requests of "his" nameservers, it would be great. And the changes and control of each region would be nearer the region. The region segments of the nodelist is already being compiled in the regions themselves, so why not the record in the DNS too? Not to speak of the offloading of hostmaster@z2.fidonet.org work when changes are to be incorporated. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #727 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 03:12:46 To : Lawrence Garvin 17 Oct 97 05:37:38 Subj : IP-access ------------------------------------------------------------------------------- > And in many, too/unnecessarily inefficient. >For starters, it uses 7-bit transfers! Second, it's native 'g' protocol has so > much overhead that the average efficiency of uucp is about 60% of capacity. Yes, UUCP-g is loaded with overhead. UUCP-t is not. :-) > Many forget that uucp was designed as a protocol to transfer email messages, > which were short, and overhead wasn't a real issue. >But then somebody bastardized it into doing file transfers and it's never been > the same since. Ooohhhh... If i search-n-replace "uucp" here with "fidonet", I still get the same result :-)) --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #728 [1995] Scn From : Joaquim Homrighausen 2:201/330.1 14 Oct 97 19:00:26 To : rafal wiosna 17 Oct 97 05:37:38 Subj : IP-connectivity ------------------------------------------------------------------------------- * On Wed 17 Sep 97 23.50, wrote: rw> So it will still dial some old lady who's phone number is rw> the same as the first seven digits of node's IP?... And if you tell would dial if the nodelist said 112? It'll dial whatever it has been told to dial, the translation stuff is there and intended to be a tool, configured and maintained by the SysOp. Or did I misunderstand something? %JoHo% joho@defsol.se * Origin: Definite Solutions ~/Stockholm, Sweden (2:201/330.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #729 [1995] Scn From : Lech Szychowski 2:480/33.7 15 Oct 97 04:33:00 To : Yuri Teterin 17 Oct 97 05:37:38 Subj : IP-access ------------------------------------------------------------------------------- > So if any node is listed in fidonet.org it must have also properly > configured fido-internet gate. Sure - otherwise it would not be able to receive any mail from the Internet. But DNS rules does not say this system has to be its own gate itself. Of course it seems more natural this way, but I can very well imagine an IP-system running binkp/binkd ot ifcico and not running an SMTP MTA; as far as I see there is nothing inherently wrong with such situation. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #730 [1995] Rcv Scn From : Sean Rima 2:252/358 14 Oct 97 06:55:36 To : Lothar Behet 17 Oct 97 05:37:38 Subj : IP-Testnodes Report ------------------------------------------------------------------------------- Hiya, Lothar! At 13 Oct 97 00:36:32, Lothar Behet wrote to All: LB> Hello All! LB> In the meantime I have connected every testnode except 3035 (until now) LB> and send them a message, partly after readdressing because they did not LB> present their 2:2/3* address. LB> This was done with Vmodem for OS/2 and BinkD. LB> I am waiting for the outstanding answers. Err did you get my answer (VBG) LB> On the other hand, about 40 other systems connected to my system with the LB> above programs and additionally Argus. LB> The developer of FrontToss (Dirk Astrath) tests his implementation on my LB> BinkD port. Maybe someone should have a work with the author of T-Mail and see if he would be willing to add Ip support. LB> Just to remind you, that the testnode is not just a silly additional aka, LB> but should be used with a certain intention. This AKA is the AKA for my Ipmailer. I run a T-Mail system to answer the phone during ZMH so that it can be inckuded in the nodelist. I am a serious Ip'er. Sean Rima Sysop DSP BBS and Ipmailer --- QDED alpha v3.57pl8/ FreeBSD * Origin: DSP BBS Ipmailer Reading England (2:252/358) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #731 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 03:36:12 To : Lawrence Garvin 17 Oct 97 05:37:38 Subj : Not on Zone 1 Backbone! ------------------------------------------------------------------------------- > I just discovered why there's no Zone 1 traffic in this echo -- seems that > IP_CONNECT is not being distributed by our friends the "North American > Backbone", and is only available to downlinks of PAOnline. Maybe the creator should have included it in the zone 2 echolist, to get it on the zone 1 backbone... > Perhaps it's time to get this thing in Zonewide distribution. Why can't we just decide everything here, and push it onto the other zones? > Who's in charge anyway? :) Ward Dossche created the echo first time as far as I know. He is the "owner" of the echo, but we have noone officialy in charge of it... --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #732 [1995] Pvt Scn From : Amir Shabashvili 2:5049/12 14 Oct 97 10:07:44 To : Yuri Teterin 17 Oct 97 05:37:38 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Yuri! Replying to a message from Yuri Teterin to Lothar Behet: LB>> Wherefore do you really need ip-only nodes in the nodelist? YT> Yes, we do. No, we don't:) I'm afraid we'll get large amound of wild ip-only nodes in our nodelist; there are some differences between IP and PSTN connection and I'm can imagine some flamewars around that.Of course we need to do something with this problem, but way to joining IP-only nodes in fidonet not so simple, I mean. LB>> They can participate as point in the same discussions. YT> IP-only nodes are often large echo- and fileecho-hubs I know some hidden IP-only nodes (like f204.n5020.z2.fidonet.net:), but not so much... Most large IP nodes I know have PSTN connection also. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #733 [1995] Scn From : Amir Shabashvili 2:5049/12 14 Oct 97 11:08:54 To : Frank Ellermann 17 Oct 97 05:37:38 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Frank! Replying to a message from Frank Ellermann to Lothar Behet: >> 1. IP only nodes may be listed only in a region (or nets) (or zones) ;) >> reserved >> for this purpose. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #734 [1995] Scn From : maciej grzeszczuk 2:480/70 15 Oct 97 00:51:52 To : Denis McMahon 17 Oct 97 05:37:38 Subj : Re: SMTP/FTP - QWK of the internet ------------------------------------------------------------------------------- From: maciej grzeszczuk Sun, 12 Oct 97 22:29:47 +0200 Denis McMahon napisal byl w fido.ip_connect: > IMHO this echo is about how we incorporate the IP addressing data in the > nodelist, not about which protocols and methods are valid or not. Can we try > and keep to the objective? i think that you are wrong. in this echo we're discussing about the ip nodes. not only about the nodelist. however, the protocol we're going to use also will be listed in the nodelist. 602 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: * jxm is now known as pirat (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #735 [1995] Scn From : Pedro Lima 2:362/21 14 Oct 97 16:13:48 To : Ger Vloothuis 17 Oct 97 05:37:38 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- GV> It is unlikely to do any harm today. What it does tomorrow is a GV> problem for another day, isn't it Pedro? Not quite. If we have information allowing us to know, even partially, what the future brings, then we'd be fools not to take it into account today. If we have no information at all, then you're right. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #736 [1995] Scn From : Pedro Lima 2:362/21 15 Oct 97 00:27:28 To : Chris Maddock 17 Oct 97 05:37:38 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hi, CM> Depends on what I tell it to do. I use Fastlst. I mean, with your present configuration, to what would FastLst translate '000-'? CM> 1. A special character or sequence tha signifies a IP node or CM> whatever, and translates the number (or some other field). The CM> "Baud_Rate" field could do this easily ? It sure isn't used much for CM> much else 'cept ISDN nodes. I'd use 300 as well... The intention of using 300 is to more easily filter the ISDN nodes from the rest with modem nodes, which is similar to the current IP situation. CM> 2. Flags. A series of flags to indicate that a node is IP (or CM> whatever) capable. A single flag would suffice to indicate general IP capability. Specifying the actual IP protocols may be dealt with via other flags. CM> 3. Routing. CM> 4. Nodelist compilers. CM> 5. It has to be as simple as possible. Agreed. CM> 6. We may even have to look at a different type of nodelist - binary CM> perhaps ? Something that could be run in parallel with the existing CM> nodelist, only for IP nodes perhaps ? This would make any expansion CM> into different technology much easier in the future and not break what CM> we currently have. CM> As far as 6. is concerned, we could even use the current nodelist to CM> provide an index into the parallel nodelist ! Yes. However, the degree of complexity of this solution is similar, IMHO, to changing the nodelist format and creating from it old-format nodelists (in a way, this is the reverse of what you're suggesting), which anyway will be a necessary move if we're ever planning to change the format to allow for old-style compilers to work. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #737 [1995] Scn From : Rune Johansen 2:210/20 15 Oct 97 02:56:04 To : Lawrence Garvin 17 Oct 97 05:37:38 Subj : IP-connectivity ------------------------------------------------------------------------------- >> They can be used as method of file transfer, but not as carriers of >> FTS-0001 mailer sessions, as they are not necessarily direct >> between the mailers/tossers/whatever. >I think the important criteria that should be considered, is whether or not th > Fidonet nodelist is required to be involved to make the connection. No nodelist things are _required_ to be involved, but that's beside the question :-)) > My ftp transfers to PAOnline are done with FTP and all of the Fidonet 'node' > related information is coded and handled internally to FIFTP -- it does not > need a nodelist to transfer mail to/from my node and 1:270/101. > Therefore, I would think that ftp is not a justifiable candidate for nodelist > inclusion. True. Candidates for nodelist inclusion are FTS-0001 capable nodes. If they have other capabilities in _addition_ (like YooHoo, EMSI, BinkP, FTP, SMTP, UUCP, Adidas-net etc.), it's great. > "Hi I'm a uucp node, not an FTS-0001/EMSI node", I see no reason for any > special listings for uucp nodes, except perhaps an authorized modem flag. Also true. > Likewise, aren't SMTP tranfers managed by software completely external to the >mailer? And as such, what would be the significance of any SMTP information in > the nodelist, except to benefit a -human- reading the source listing? The only thing I would use the nodelist for in a SMTP connection, with my autmated mailer, is to find the email address to send the bundles to, and information on how they should be included in the email. >As I'm seeing it, VModem, BinkD, IFCico and any other IP tranfer methodologies > that require a direct interaction with the Fido mailer are the only ones that > -need- to be included in the nodelist. Yes, and you (per today) also _need_ a FTS-0001 capable receiver on your nodelisted node according to policy, so IP nodes without this, is not eligible for nodelisting with _that_ as their only capabilities. This rules out SMTP-only nodes, UUCP-only nodes etc. But, if you have a node that has got FTP capabilities (a FTS server where you can log in and leave bundles, pkt files etc, and they will be processed somehow), and it has got a FTS-0001 capable amiler attaced to a PSTN, ISDN or IP address, we (c|sh)ould create ways of including this into in the nodelist. But, as you indicated earlier in your mail, you can agree on transfer method with the operator beforehand, and just skip all nodelist info.. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #738 [1995] Scn From : David Moufarrege 1:2613/404 09 Oct 97 19:46:22 To : All 17 Oct 97 05:41:18 Subj : Argus ------------------------------------------------------------------------------- Hello All! I've been trying to get Argus to even make an outbound call but to no avail. Who has experience with that mailers TCP/IP daemon and can lend me a hand? -=David=- _____________________________ | e-mail : david@kraut.xg.com | | FidoNet: 1:2613/404 | | 1:13/0 | ----------------------------- ... Surly to bed, and surly to rise. --- * Origin: Kraut Haus * Rochester, NY * 716-359-0871 (1:2613/404) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #739 [1995] Scn From : Sean Rima 2:252/356 15 Oct 97 17:31:00 To : All 17 Oct 97 05:43:00 Subj : FW: Re: Moderator List ------------------------------------------------------------------------------- Area : STN.ADMIN Date : Sun Oct 05, 19:50 From : Craig Box 111:8647/0 To : Vincent Danen Subj : Re: Moderator List ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ Ž VD> Hmmm... will have to take a look at that... NLmaint, eh? I like the sound VD> that... the only thing I dislike, now, is that I got a MakeNL clone called VD> NLMake/2 which is for OS/2... =) That almost makes it worth using still... VD> I'll take a look at this one tho and see how it is in comparison... thanx, VD> Craig. http://www.blaze.net.au/~davidn/BETA/ Beta Test Software WARNING: All of the software shown here is in alpha or beta test. It is placed here purely for the purpose of distribution to beta testers. It is not for the merely curious, but for people who are interested in looking at the software and evaluating it for problems. All of this software has known - and probably unknown - problems, bugs and misfeatures. The software may also not be properly documented, or not documented in a form suitable for and understandable by an end-user. No warranty or representation of any kind attaches to this software - if you download it, you are most certainly on your own. If you run this software, you are obliged to contact me at the address below and state that you have used it and to report any and all problems you may encounter in doing so. All software below is Copyright c by David L. Nugent & Unique Computing. NLTools NLTools is a comprehensive FidoNet "St Louis" format nodelist builder and maintainer, similar to Ben Baker's MAKENL. It is designed for FidoNet coordinator's use, to enable the automated building, checking, maintenance and distribution of nodelist segment(s). Current NLTools 0.99 source in ZIP format NLTools 0.99 exec/docs for DOS (16-bit) in ZIP format NLTools 0.99 exec/docs for DOS (32-bit DOS4GW) in ZIP format NLTools 0.99 exec/docs for OS/2 (32-bit) in ZIP format ... it's probably generated the Fidonet Zone-3 segment for years. ------------------------------------------------------------------------------- The word is that this may be able to handle IP addresses in instead of Telephone numbers. I have downloaded both the Source and 32bit Dos. I will see if it will or if it can be converted to handle IP addresses. Sean --- Renegade v96-143b dos * Origin: Toontown - the most fun you can have sober (111:8647/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #740 [1995] Scn From : Denis McMahon 2:251/20 14 Oct 97 10:14:40 To : Lawrence Garvin 17 Oct 97 05:43:00 Subj : IP-connectivity ------------------------------------------------------------------------------- Lawrence Garvin wrote to Denis McMahon: DM> If you can transfer FTS-0001 packets fully automated at both ends DM> then the connection is a fidonet connection. LG> Dennis, it's not just FTS-0001 packets that are at issue, it's LG> live, direct, one-to-one MAILER connections that should be the LG> issue. Lawrence, if you want me to believe that you understood what you read, you would do well to type in my name as it appears on your screen. A failure to do so implies that you can't actually see what you're looking at ..... You seem to be blinded by the dogma of Policy 4 - and are taking the viewpoint of "How can we restrict membership of Fidonet to ...... " rather than "How can we open up Fidonet membership to ...... " LG> Neither FTP, nor SMTP, fall into this classification. FTP and SMTP were in use for mail transfer before any other ip based protocols were developed, and they are still used. What I am saying is at this point it would be restrictive to disbar any technology as being inappropriate to FidoNet, what we should instead be doing is working out how to incorporate that technology! LG> While I agree that it would be very useful to know which nodes LG> support communications by FTP or SMTP, that information is not LG> usable by my mailer (nor do I expect it ever will be), therefore, I LG> see no functional purpose in its inclusion in a nodelist. There's a *LOT* of data in the nodelist that a lot of systems can't, or don't use. That's no reason to junk it. Examples are: (a) Modem flags - with current intelligent modems, how many sysops are still optimising their dial strings according to the flags on the modem they're calling? (b) Time field - I believe one mailer currently recognises the Txy flag? (c) *C / *EC / UUCP etc flags - These are only their for human convenience - I am not aware of *ANY* mailer that has implemented an algorithm to identify and use the nearest UUCP gate automatically. (d) Baud rate - which is almost totally meaningless now that of the 29793 lines in the nodelist from the first zone statement to the last node entry, 26392 are rated 9600, 2152 are rated 300 (of which about 6 may be genuine 300, the rest are ISDN etc), and 1178 lines are comments. LG> I think that information should be published in an auxiliary LG> listing of FTP and SMTP capable systems. No - the whole purpose is to keep all the information in one place. Apart from anything else, too many systems use the nodelist to validate in-transit netmail. If the system is to be recognised in FTN address space then it must be capable of being entered in the nodelist. Remember, what we're talking about here also has implications for other FTN networks, and it would be extremely shortsighetd of us to ignore that. Perhaps someone ought to see about opening the discussion up to other nets. Sod the Echopol restrictions on gateing, as long as the other nets don't have clashing zone numbers it should work. LG> Of course, if one has a full time FTP Server or SMTP Server, then LG> one presumes that node is also capable of VModem/BinkD/IFCico, so LG> perhaps the fundamental issue is back to defining the MINIMUM LG> STANDARD for listing as an IP-node. ftp / smtp servers can operate on a lot of platforms that vmodem / binkd / ifcico etc haven't been ported to! Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #741 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 17 Oct 97 11:10:36 To : Rune Johansen Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Rune! On 15 Oct 97 wrote Rune Johansen to Lothar Behet: >> With a wisely choosen nodelist standard the ip-lines can be listed in >> the same entry as normal pstn lines, to keep the nodelist at on >> affordable size for eac sysop. RJ> I don't remember: Have you proposed such a wisely chosen standard RJ> here? If so, could you netmail it to me, as it seems I cannot find it. RJ> If not, would you mind posting such a proposal here? Here it comes again: >-8------------------------ byte here ------------------------8-< - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #408 [743] Snt Loc Scn From : Lothar Behet 2:2446/301 09 Oct 97 08:27:24 To : All Subj : Nodelist entries for IP-Nodes ------------------------------------------------------------------------------- Hello All! Just a few thoughts about fields and their purposes in the nodelist: > [excerpt from a future Segment of net 2:2446] >-8------------------------ byte here ------------------------8-< ,301,fido.nrh.de,Uedem_FRG,Lothar_Behet,49-2824-922240 ,CM,XA,V34,U,X75,VM,BNP, ... >-8------------------------ byte here ------------------------8-< If you take a close look at this example, you will see, that it contains all vital information for any kind of connectivity. Furthermore a simple way of backup-routing using another access media is integrated, so that this is just a question of mailer (task) tuning. This is independant of a new (better) nodelist format, but fulfills any need for our purposes based on the existing format and dependant software. In the new nodelist format a kind of backup node should be considered, so that even a total system crash does not disturb communications. The backup node should have equivalent capabilities concerning to connectivity and routing structures. Then we even had a failsafe system, as long as any communication lines (and energy:) are available. >-8----------------------+- byte here ------------------------8-< Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #742 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 17 Oct 97 13:05:32 To : Marco d'Itri Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Marco! On 15 Oct 97 wrote Marco d'Itri to Lothar Behet: >> A node entry, which is not reachable by the most of other members of >> fidonet, does not serve any purpose in the nodelist for direct >> communication possibility, which is the major advantage of ftn above >> i.e. ip. MI> Do you want to be points ISDN nodes too? Just the other way round: If an ISDN-only node serves no routing purposes for the net, he might be a point :) As "ISDN-only node" was the first exception from the general connectability rule, listing conditions for ip-nodes should be examined precisely. Adspects of ISDN (against analogue connect): - fast and very reliable datatransfer - directly addressable from any other ISDN system with the same protocol (i.e. X.75, V110, V120), but generally only in the same country possible without problems. - only compatible to analogue protocols with special (mostly expensive) or additional equipment Aspects of IP: - low cost at long distance transmissions - directly adressable from other ip-nodes (dial-in and leased line) with different (matching) protocols - buffering protocols without direct mailer session are possible (i.e. email based), but then no secure transmission is possible (timestamp of arrival, confidential communication) - generally additional costs for each user, as ip-access requires additional charges to a service provider - highly varying bandwidth (depends on general internet usage), therefore required connect times (and costs) are not calculatable Some of these aspects have advantages above direct connects, but others just do not fulfil basic requirements concerning to our general fidonet policy. So i advise to exactly monitor all aspects of ip for fidonet and its members, before the listing campaign in the nodelist begins. At least one direct handshaking protocol between mailers in combination with CM (or at least a specified "online" time above ZMH) seems a reasonable claim for a nodelist entry. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #743 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 17 Oct 97 13:07:52 To : Pedro Lima Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Pedro! On 15 Oct 97 wrote Pedro Lima to Lothar Behet: PL>>> Temptative. LB>> :) PL> Oops, I meant "tempting", sorry. :-) As i did not address spelling, i hold my :) up. LB>> At first you have to replace Makenl on every instance, were "new LB>> data" is processed. PL> That's why it should be simple. Only the places where IP nodes are PL> required will need to replace MakeNL. Not in every case. There are several char fields in the nodelist, which may contain more useful data then just names. Some of them preserve a limited room, which has to checked for makenl and all nodelist compilters. LB>> In second order you have to assure, that every LB>> nodelistcompiler (even Frontdoor and for the Amiga/ST-system) can LB>> handle those data in an appropriate way. At least these programs LB>> are used by nodes (members of Fidonet, you remember?:), which must LB>> not be locked up by a change, which was not approved on _all_ LB>> systems. PL> Yes, we should be careful. The current Z2 test-nodes seem to be PL> compatible (of course), but unless some known problem exists, I'd like PL> to see other formats being tested (like using FQDNs in the phone PL> field, direct quad-notation or the IPv6 notation). LB>> Is the system name not in a certain way equivalent? PL> It could be similar, if the IP address was listed in the phone field PL> as well. :-) But then you loose the advantage of combined entries :(, which saves a lot of lines. On the other hand, still software with very limited aka-recognition is widely used. LB>> Maybe, that tomorrow we already have an extended nodelistformat, LB>> which supports any kind of communication access. I would LB>> appreciate that, but integration of IP-access is a problem today LB>> and should be handled as soon as possible. PL> Implementing an extended format, as desireable as it may be, is PL> very difficult to do, as it implies every node changing its software. Correct. PL> If the current format can be used to handle several communication PL> technologies, then I think it would be a mistake to complicate PL> things. A different nodelist entry for a different technology seems PL> the best and simplest approach for now, IMHO. At this moment there is no public support fpr ip-entries. Just a sample: I run Binkley XE on several conventional lines and one addtional task via Vmodem for OS/2. Furthermore BinkD handles port 24554. I use FastList v2 as nodelist compiler, which supports include files. So i can use a small utility program, which extracts Vmodem and Telnet entries from the nodelist (any field) to a phone translation table, which overrides the normal phonenumbers for the vmodem task, which uses a dedicated modem bit. BibkD nodes reside in a special list, where passwords are added from a seperate table (it could be the normal password table). As long as the nodelist compiler knows which fields and flags to monitor, it can create even a combination of different lists according to the mailers specifications. When i began with ISDN in early 1993, I used a nodelist-splitter for separating analogue and ISDN-entries for the individual lines, until i found and configured FastList correctly. LB>> IMHO ip-access must be only an additional flag in the nodelist LB>> (!), as this the reference worldwide. Which entries circulate in LB>> regional or local lists (pointlists, etc.) does not have LB>> influence on international level. PL> But the attempt is to allow IP nodes, not only IP connectivity to the PL> existant ones... The basics of fidonet was worldwide communication within a network of publicly accessable bbs's. Therefore the nodelist was created to allow the mail transfer between these systems. Some of them act as routing system and bundle regional mail for long distance calls. As the used software allowed only 3d addressing, the concept of fakenet-adresses allowed comfortable participation on a lower level. The points are nowadays fully integrated in the international communication exchange. Why should this concept not satisfy the purposes of an ip(-only) member in the international communication, as long as he has no downlinks (no routing)? If he gets downlinks, then i am quite sure, that he needs an additonal conventional entry. If you allow any ip-access as sufficient for a listing as node, then you must allow any point to be a node also. On the other hand, if there are more ip-nodes at a certain moment than conventional ones, who will stop the integration of fido into the internet then? LB>> If we would allow any kind of communication access to Fido on a LB>> too low level, the nodelist will grow in an extensive way. PL> That's why I suggested that nodelist subsets were made available. PL> But I'd say that the nodelist growth won't be that dramatical, even PL> if the nodelist growed say three times larger than it is today it PL> will still be manageable by the average system. I can remember systems, which ran into serious problems at more than 65535 entries (different FTNs and/or several pointlists). They had to use subsets, to reach a full regional connectivity. [... some stuff deleted ...] LB>> I do either, but others were constantly mourning about possible LB>> problems. So why not create a solution, which does not interfere LB>> with actual, widely used system setups? PL> I'm all for it. It's nice to see a certain level of common understanding. [... some stuff deleted ...] PL> On the other hand, the necessity to accomodate other communication PL> technologies may not have this kind of time, so we need to foresee PL> the use of the current format. Placing the IP address in the system PL> name field may be a solution for solving the IP problem, but it PL> creates an inconsistency in the fields' purposes which is not PL> expandable for the use of other technologies, if we need to. As far as i know, the existing format is not capable for indefinite long entries on most systems, so the redefination of some fields can only be a timely solution. But this intermediate patch should not exceed the tolerance of the general node and the capacity of an average system. Here in R24 is a strong opposition against any ip-entries at all, but sometimes it is based on a misunderstanding of the tunneling technique. LB>> as a standard is defined, the tools for this will be public in a LB>> short time. PL> Yes, I agree. Then we should focuse on a compatible solution for short term, while we begin to work on a better and more complete format. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #744 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 17 Oct 97 13:15:06 To : Lech Szychowski Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Lech! On 15 Oct 97 wrote Lech Szychowski to Lothar Behet: >> If take a close look into the nodelist, than you will see, that >> there i.e. systems operated via ISDN-lines (with numbers in direct >> order), who "need" a nodelist entry for each line. LS> The unfortunate truth is current nodelist format does not provide us LS> with any means to indicate one system has more than one phone LS> line/number. And if we want to define a new standard we should avoid LS> repeating this mistake as hard as possible. We do not have to repeat this fault with ip-nodes again, as the phone field has certain restrictions, which caannot be solved generally on short term. >> With fqdn the machines in a subnet (same domain) can be addressed >> in one entry, as long as the protocols and other flags are >> equivalent. LS> I'm afraid I don't get you. Example: My published addrees is: fido.nrh.de The domain file contains several lines of fido IN A 194.231.142.17 fido IN A 194.231.142.18 ... So i can spread the service in my subnet over several machines, which serves a load balancing between the individual computers and a local backup, if one machine stops the service. The publicated protocols (Vmodem, BNP, etc.) will have to be started on all computers, but in that case they serve all requests according to the round-robin switching in dns. >> With a wisely choosen nodelist standard the ip-lines can be listed >> in the same entry as normal pstn lines, to keep the nodelist at on >> affordable size for each sysop. LS> The big question here IMHO is "do we really need to put into nodelist LS> information that is completely outside the area of interest for PSTN LS> nodes?". 3D/4D address is already there, and if we either indicate LS> a domain or use the default "fidonet.org" we can very easily construct LS> a unique FQDN for each system. Yes, the publication in the nodelist makes sense, as other nodes with the same capability may initiate a direct link. 1. In case of a prepaid leased line, there is no additional cost on at least one system, but this data does not increase load (and maybe some cost) on other routing systems. 2. Furthermore you can exchange mail in a continuous way (leased line on both ends) completely without additional cost, whichs shortens some routing delays by days. 3. The tunneling of ftn-data may even be done by a average node beside his other activity in the internet (the web?) without a dedicated call for this. In all of these cases the published address is a advantage, as long as the called system is CM and serves routing for other nodes. As far as i read until now, the administration of subdomains for z2.fidonet.org is handled very restrictively and at this moment it is primarily intended for gateway administration. The fidonet.org name service just covers fido needs, but there are other widely spread ftn's. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #745 [1995] Scn From : Yuri Teterin 2:5030/239 16 Oct 97 22:25:30 To : Rune Johansen 17 Oct 97 19:05:18 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Wed Oct 15 1997 Rune Johansen writes to Nick Soveiko: >> in order to maintain this just-in-case capability a sysop running os/2 or >> win nt has to go out and *buy* appropriate software. afaik, vmodem isn't >> free and neither are it's analogs for many other platforms. RJ> I think I see a confusion between "Vmodem" and "vmodem", as "Vmodem" in RJ> Ray Gwinn's SIO package, and "vmodem" as a virtual modem driver that uses RJ> a form for transportation (IP in these cases). Do you know free implementation of this 'virtual modem driver' for OS/2, Windosw NT or Windows95 ? Where can they be found? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #746 [1995] Scn From : Yuri Teterin 2:5030/239 16 Oct 97 18:49:42 To : Marco D'itri 17 Oct 97 19:05:18 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello, Marco ! Mon Oct 13 1997 Marco d'Itri writes to Lech Szychowski: >> IMHO you are wrong. My system is reachable from the Internet as three >> IP addresses - and the reason behind it is it has three different >> physical links from different ISPs, for sake of redundancy and MI> If this is your concern then you should use round robin DNS. If one link MI> is down, next time the mailer will retry on the next one. If these IP-links differ significantly in speed or connectivity, this will be a bad solution, because 1/2 of all connections will use "pure" line in this case. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #747 [1995] Scn From : Yuri Teterin 2:5030/239 16 Oct 97 23:23:22 To : Nick Soveiko 17 Oct 97 19:05:18 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hello, Nick ! Tue Oct 14 1997 Nick Soveiko writes to Lawrence Garvin: NS> apart from ifcico, which exists for *nix only (and i'm not NS> sure if it supports *fts-0001* sessions anyway), It does, but for TCP-connection only ;-) (because getty or its clones, which listen usually at modem COM-port, can not recognize FTS-0001 session and so are not able to call ifcico itself). Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #748 [1995] Scn From : Nick Soveiko 2:5030/23.101 14 Oct 97 17:07:56 To : maciej grzeszczuk 17 Oct 97 19:05:18 Subj : binkd vs vmodem ------------------------------------------------------------------------------- Sun, 12 Oct 1997, 21:49, maciej grzeszczuk (2:480/70) ==> Igor Bilyi: > in trabsfers, 100 MB on 28.8 lines with > 2800 cps, try todo this > with vmodem mg> easily. if you don't have the problem doesn't mean nobody has the problem. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #749 [1995] Scn From : Denis McMahon 2:251/20 15 Oct 97 18:19:20 To : Amir Shabashvili 17 Oct 97 19:05:18 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Amir Shabashvili wrote to Denis McMahon: DM> Hey Amir, you don't want to communicate with non FTS-0001 nodes, fine. AS> I didn't say that. Only thing I trying to say is : It will the AS> wrong way if we'll join IP and PSTN nodes in one file. Why? Well, AS> IP transport and usial PSTN so differ, and cann't be cover by one AS> policy. I think must be some part in policy for IP-only and some - AS> for PSTN nodes only. And different nodelist files is good thing, AS> from this point of view. OK, I want to send a routed netmail to an ip system. I address it to the IP system. My mail tracker won't let it be sent because the destination system is not in the nodelist. One Fidonet - One Nodelist! DM> There's a lot who do, and a lot who think that 1989 policy and DM> procedure is out of date in 2000. AS> And I'm too;) AS> <...skipping a piece of wisdom..> DM> technology, becaue this isn't where we debate "can we / should we", DM> but "how can we". Take the "can we / should we" debate elsewhere! AS> Ok. AS> Is there some rules & moderator? Is this echo self-moderated? There's no real rules apart from be civilized I guess, and no real topic, but Ward formed the echo to discuss how we put ip adressing in the nodelist, so that is what we must try and do, and if anyone is the moderator he is, or hoever he says anyway. Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #750 [1995] Rcv Scn From : Amir Shabashvili 2:5049/12 16 Oct 97 19:35:34 To : Lothar Behet 17 Oct 97 19:05:18 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Lothar! Replying to a message from Lothar Behet to Amir Shabashvili: AS>> Is there some rules & moderator? Is this echo self-moderated? LB> This echo was openend in september by Ward Dossche (Z2C) for LB> discussion about technical integration of ip-nodes into the nodelist. ----------------------------------------------------------------------------- / Area : ENET.SYSOP (ENET.SYSOP) / From : Ward Dossche, 2:292/854 (Saturday August 30 1997 11:37) ============================================================================= <...skipping a piece of wisdom..> Therefor as of immediately I am offering a conference called IP_CONNECT to discuss and deal with IP-connectivity. (If someone has a better suggestion please step forward) ------------------------------------------------------------------------------ May be you know another Ward's words, but I mean this conference dealing with any sides of IP-fidonet connectivity problem, not only IP->nodelist. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #751 [1995] Scn From : Denis McMahon 2:251/20 15 Oct 97 18:21:28 To : Yuri Teterin 17 Oct 97 19:05:18 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Yuri Teterin wrote to Denis Mcmahon: DM> 2) We're not here to decide what protocols are or are not valid, DM> ultimately *ANY PROTOCOL OR TRANSPORT THAT WORKS IS VALID*. We're DM> here to work out how to get the IP addressing data into the DM> nodelist. YT> But we must decide also how to indicate in nodelist which set of YT> FTN-over-IP protocols does the node support. And to do this we must YT> first of all get either full specifications for such protocols, or YT> at least exact reference to standard implementations of them. Yes YT> "FTN, SMTP and so on" do not confirm this requirements, because FTP? YT> there exists a lot of different ways to use them for transmission YT> of FTN traffic. So we need some additional information before YT> corresponding protocols will be considered as a valid protocol for YT> IP node. So, as I said, for FTP, accept anonymous upload of *.pkt and arcmail files, just like happens during a session today. Everything else is recipient issue, as long as files arrive correctly. For smtp, define the encoding method and name to address the mail to at the ip address. As long as mail arrives, everything else is recipient issue. Nothing more is needed. Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #752 [1995] Scn From : Yuri Teterin 2:5030/239 16 Oct 97 19:42:36 To : Marco D'itri 17 Oct 97 19:05:18 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello, Marco ! Tue Oct 14 1997 Marco d'Itri writes to Yuri Teterin: >> The only ifcico-speciffic protocol is its 'raw TCP protocol', which >> can be considered as an alternative realization of FTN_over_telnet >> sessions. MI> It can't, there is no telnet protocol in an handshake over the raw TCP MI> connection. Yes, because they are just unnecessary in this case. If defaults of telnetd were apropriate for FTN session - this part of handshake would be unnessesary for 'EMSI over telnet' session too and we were able to use the same 'raw TCP' codes for telnet connection too. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #753 [1995] Scn From : Yuri Teterin 2:5030/239 16 Oct 97 19:59:18 To : Rune Johansen 17 Oct 97 19:05:18 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Wed Oct 15 1997 Rune Johansen writes to Dieter Ringhofer: RJ> My suggestion is that if you have one node with PSTN or ISDN (or both), RJ> and also have the possibility to have a IP node online on the internet for RJ> a fixed period of time, or CM, you would need another AKA. This is not convenient. The routing of netmail for this node will depend dramaticaly on the AKA used, and there will be no way for software at transit nodes to choose appropriate way (IP or PSTN) automaticaly. To have all the addresses of the node (phone-, IP-, and so on) in one line of nodelist (preferable - in flags) would be much more convenient. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #754 [1995] Scn From : Nick Soveiko 2:5030/23.101 14 Oct 97 17:16:42 To : Lawrence Garvin 17 Oct 97 19:05:18 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Sun, 12 Oct 1997, 11:34, Lawrence Garvin (1:106/6018) ==> Slava Filimonov: SF> We can't set vmodem as a standart protocol for ip session, cause SF> it's based on non-free software. We should use binkd as a standart, SF> which is free and protocol spec is avail, and vmodem as option. LG> Slava... I think the mistake in interpretation is the use of LG> "vmodem" as a generic term. LG> I suspect the proper terminology is a telnetd/fts-0001 capable LG> node. LG> While you are correct that VModem, per se, is not free, there are LG> telnetd compatible implementations on every platform that are. the issue is not just a telnetd implementation, but a telnetd/fts-0001 implementation. apart from ifcico, which exists for *nix only (and i'm not sure if it supports *fts-0001* sessions anyway), so far we have to resort to a telnetd that is capable of emulating com ports which a traditional fts-0001 compliant mailer can use. *such* telnetd is not free for every platform. vmodem term was used here to point out this problem on a particular platform (os/2). cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #755 [1995] Scn From : Amir Shabashvili 2:5049/12 16 Oct 97 19:09:46 To : Denis McMahon 17 Oct 97 19:05:18 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Denis! Replying to a message from Denis McMahon to Amir Shabashvili: DM> OK, I want to send a routed netmail to an ip system. I address it to DM> the IP system. My mail tracker won't let it be sent because the DM> destination system is not in the nodelist. Tracker I've working fine with all nodelist files I told him about. DM> One Fidonet - One Nodelist! Yes, I know this sound (with "!" at the end of sentence:) One transport - one nodelist file, IMHO. Except nodes with both PSTN and IP - I see no problem in that case, we can use any kind of IP flags. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #756 [1995] Scn From : Amir Shabashvili 2:5049/12 16 Oct 97 09:11:32 To : Mario Mure' 17 Oct 97 19:05:20 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Mario! Replying to a message from Mario Mure' to Lothar Behet: LB>> Wherefore do you really need ip-only nodes in the nodelist? They can LB>> participate as point in the same discussions. MM> What if this ip-only system is routing netmail/echo to other MM> nodes/points ? We need hubs for routing netmail/echo on PSTN, and one of main reasons for that is cost of long-distance connections. But on IP we free to change our uplinks - no phone boundaries, no additional money. I'm agree in some cases we need IP hubs, but we more free to choose it. Only case I can imagine we strongly need IP node - when this is both IP and PSTN hub. But, this is not IP-only case. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #757 [1995] Scn From : Yuri Teterin 2:5030/239 16 Oct 97 22:59:16 To : Rune Johansen 17 Oct 97 19:05:20 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Wed Oct 15 1997 Rune Johansen writes to Lech Szychowski: RJ> I have been involved in this discussion, by saying _if_ we must have a RJ> lowest common denominator protocol to connect to. I don't think there RJ> should be any, as the flags would imply what protocols are available on RJ> the IP node in question. The only thing a IP node needs, according to the RJ> policy documents, are a FTS-0001 capable "thingy" in the other end, RJ> at least. It is very difficult to change this policy (several has tried). FIDO-Policy describes the a net of phone-based stations. And the demand of FTS-0001 capability referes to node's phoneline only. Further, FTS-0001 describes a session based immediately on a _physical_ layer protocol. All the protocols you have mentioned (telnet, vmodem, ifcico's 'raw TCP') are not physical layer protocols and demand some software support, so FTS-0001 is not direcly applicable to them. And after all, if you do not worry what the low layer protocol is and leave this to implementations, sometimes rather complicated (as vmodem), - why do you worry about high-level protocols, which can be even more easy than the same vmodem? Why do you insist on FTS-0001, which is obsolated, quite unappropriate for TCP-IP and more complicated from the point of view of implementation, than binkp is? Are you quite shure that all modern mailers _really_ support FTS-0001 sessions? I know hundreds of nodes which used for years mailers which supported yoohoo and EMSI only (and did not supported FTS-0001) - and nobody worried about that. BTW, you almost shurely will be unable to make FTS-0001 session with _phone_ line of ifcico (but it will be OK with its IP-line). RJ> According to my interpretation of discussions here and elsewhere, a RJ> BinkP-only IP-only node does not meet minimum requirements for being a RJ> public node in Fidonet. A FTS-0001 IP-only node _does_ meet the RJ> requirement, due to the FTS-0001 part. Who's requirements? Not the requirements of FIDO-policy, because it require FIDO-node have phonenumber first of all. RJ> Wether it uses telnet, ifcico, SIO's VModem or raw TCP for its RJ> connection, does not matter. 1. ifcico and raw TCP are the same 2. what do you mean saying about telnet? When you use telnet for FTN-session the only used part of telnet protocol just turn off all its special features and turn the telnet chanel into the same 'raw TCP' chanel which ifcico uses. So from the point of view of your beloved FTS-0001 telnet and 'raw TCP' are also just the same. RJ> If it has got raw BinkP in addition, that's great. What for? Have you _ever_ seen FTS-0001 session in your life? And to implement features that will _never_ be used is at least very strange. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #758 [1995] Rcv Scn From : Yuri Teterin 2:5030/239 16 Oct 97 23:32:46 To : Lothar Behet 17 Oct 97 19:05:20 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello, Lothar ! Wed Oct 15 1997 Lothar Behet writes to Yuri Teterin: LB>>> Wherefore do you really need ip-only nodes in the nodelist? [......] LB> How do they deliver the collected data to their downlinks? LB> You can not tell me, that a large system does not support any direct LB> dial-in lines :( Why not? They communicate with hundreds of IP-nodes, that have dial-up lines, this is quite enough. LB> Under defined circumstances they may aquire for a pvt listing. _Now_ this is rather difficult, so I know the cases, then the places wich nice IP-connections but without phone lines, that could became such echohubs, prefere to leave points and were unable to help others IP-nodes to get fulfid of echos. If there will be common understanding that each net can have 5-10 such pvt IP-nodes, and it will be not so difficult to add them to nodelist - all will be OK, I think. Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #759 [1995] Scn From : Yuri Teterin 2:5030/239 16 Oct 97 23:30:34 To : Rune Johansen 17 Oct 97 19:05:20 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Wed Oct 15 1997 Rune Johansen writes to Lawrence Garvin: RJ> When thinking about it, you _could_ use BinkP to transfer the packets that RJ> make up a FTS-0001 session :-) The mailers involved would then have to RJ> react on the packets transferred immediately to "do tha thing". RJ> So, a BinkP-only node would have to implement this to be policy compliant. RJ> When this is done, there would be no objections. OK. Now I clame that I _have_ such implementation of binkp protocol, and it work at my station, but it is commercial one and you should pay $99999999 if you would like to use it. If you do not like to pay - you can use noncommercial version that is free and can make all what other mailers do, but does not support FTS-0001. Should it be OK to be present in nodelist? O, yes. If you'll be so stupid (or geneous) that will make your own implementation of this idea (just to check me) - it shurely will be incompatible with my Great Commercial Mailer, because your interpretation of 'physical layer' in FTS-0001 will differs from my one ;-). And specifications of my 'law layer protocol' are not free also (just like VMP is). What can your say in this case? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #760 [1995] Rcv Scn From : Yuri Teterin 2:5030/239 16 Oct 97 23:19:56 To : Lothar Behet 17 Oct 97 19:05:20 Subj : vmodem ------------------------------------------------------------------------------- Hello, Lothar ! Wed Oct 15 1997 Lothar Behet writes to Yuri Teterin: YT>> Just try to make telnet to your telnet port 60177 and then - to YT>> vmodem port 3142 of any vmodem-node, and you'll see the difference. LB> Vmodem on port 3142 will fail in most cases, as the default (and mostly LB> used) port is 3141 (if you are talking about Vmodem from the SIO-package LB> for OS/2). Yes, of cause, thank you. I stoped to use vmodem more than a year ago, and so forgot exact numbers. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #761 [1995] Scn From : Yuri Teterin 2:5030/239 16 Oct 97 19:50:12 To : Maciej Grzeszczuk 17 Oct 97 19:05:20 Subj : vmodem ------------------------------------------------------------------------------- Hello, Maciej ! Mon Oct 13 1997 Marco d'Itri writes to maciej grzeszczuk: >> both telnet (in your meaning) and vmodem are the same protocol. MI> They aren't. The vmodem protocol (VMP) accepts connections at port 3141 MI> and is a proprietary standard of the vmodem.sys virtual fossil. And look into the file README.TELNET in your ifmail distribution - you'll see 'VMP is not supported' there. Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #762 [1995] Scn From : Denis McMahon 2:251/20 17 Oct 97 00:15:18 To : Amir Shabashvili 17 Oct 97 19:05:20 Subj : SMTP/FTP - QWK of the internet ------------------------------------------------------------------------------- Amir Shabashvili wrote to Denis McMahon: DM> IMHO this echo is about how we incorporate the IP addressing data in DM> the nodelist, not about which protocols and methods are valid or not. DM> Can we try and keep to the objective? AS> I see you are only person who know precisely what is the objectives AS> of this echo. Could you send me rules of this echo or point to AS> moderator address? Hey, Ward Dossche started the echo so we could discuss how to include ip in the nodelist, after I suggested ip adress in telno field. The idea was we discuss the best way to incorporate ip based (and other new technologies) in the nodelist. I guess Ward is the moderator, unless he appointed someone, and that's where the rules come from. I only voice my opinions on what I think we should be discussing, and I don't think that drawing a line under *ANY* technology and saying "doesn't qualify" is correct for this forum - that (I think) is a policy makes thing, and this (I think) is meant to be a technical conference! Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #763 [1995] Rcv Scn From : Sebastian Stein 2:2410/299.27 17 Oct 97 18:38:18 To : Lothar Behet 17 Oct 97 22:36:00 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Lothar Behet wrote in a message to Sebastian Stein: Hello Lothar, LB>> 3. As FTS-001 is another basic condition for listing as node, LB>> at least one protocol must be capable for a direct mailer to LB>> mailer session. SS> This would exclude BinkP-only-Nodes, am I right ? LB> Give me a chance for a slightly different formulation: LB> At least one protocol has to be a direct mailer to mailer session, LB> equivalent as FTS-001 defines for direct pstn operation, which uses LB> the fido address and optional passwords for authentication. LB> There might come other protocols beside the existant, which may be LB> used in the future. It is not my intention to define just one LB> protocol as fido-conformant or exclude others for fido operation. LB> Okay? The formulation with 'EQUIVALENT' is much better ! :-) Direct Mailer-to-Mailer connection over TCP/IP is important for me, too ! Bye, Sebastian --- timEd/2 1.10 * Origin: Berlin, ick liebe Dir ! (2:2410/299.27) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #764 [1995] Scn From : Marco d'Itri 2:335/680.666 17 Oct 97 14:36:42 To : Rune Johansen 17 Oct 97 23:37:52 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >Aha. If getty was rewritten to do mailer handshake, then it would be OK. >Almost getty (mgetty) is able to do mailer handshakes, but telnetd never calls a getty. You would have to modify the telnet daemon. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #765 [1995] Scn From : Marco d'Itri 2:335/680.666 17 Oct 97 14:05:26 To : Amir Shabashvili 17 Oct 97 23:37:52 Subj : Re: IP addressing ------------------------------------------------------------------------------- Amir.Shabashvili@f12.n5049.z2.fidonet.org wrote: > Md> No. This way we will run out of space in the flags field. If we do, we > Md> could as well use the extended nodelist format. >- extended nodelist format don't compatible with some nodelist compilers Long flags neither. >- do you know any limitation for the flags field space in nodelist? Yes, the available space is simited (IIRC 63 chars). There is a thread about that in NET_DEV. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #766 [1995] Scn From : Marco d'Itri 2:335/680.666 17 Oct 97 14:21:32 To : Lech Szychowski 17 Oct 97 23:37:52 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >Nope. I believe most modern MTAs can be configured to return no more >than a given number of lines in a "delivery failed" warning message. Sendmail can't, nor qmail, nor AFAIK smail. There aren't many other widely used MTA. >But in general I do agree - SMTP as encapsulation has disadvantages >so serious that it IMHO should not be considered seriously. I receive my arcmail via email (it's *NOT* SMTP encapsulation, it's EMAIL incapsulation) since some months and I've never had any problem. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #767 [1995] Scn From : Marco d'Itri 2:335/680.666 17 Oct 97 14:31:26 To : maciej grzeszczuk 17 Oct 97 23:37:52 Subj : Re: binkd vs vmodem ------------------------------------------------------------------------------- krap@zwieracz.psych.uw.edu.pl wrote: >sure about that? iftelnetd on port 60177 is allowing proper incoming vmodem >connections. It allows a fidonet handshake over telnet. This is not the VMODEM protocol (VMP). -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #768 [1995] Scn From : Pedro Lima 2:362/21 16 Oct 97 04:43:36 To : Sean Rima 18 Oct 97 05:37:32 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- SR> I suppose there is no real problem with porting BinkD to dos. It is SR> just making it talk to winsock (opps) sock of some type. To a packet driver, perhaps? If someone attempts such a port, I'd *very much* like to know. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #769 [1995] Scn From : Pedro Lima 2:362/21 16 Oct 97 04:29:20 To : Marco d'Itri 18 Oct 97 05:37:32 Subj : IP-access ------------------------------------------------------------------------------- Md> Not all Registration Autorities register domains for everybody. In Md> Italy we had to register fidoitalia.net because private entities can't Md> register domains (we would need to register a formal fidonet Md> association). FWIW, same in Portugal. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #770 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 18 Oct 97 09:00:28 To : Yuri Teterin Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Yuri! On 16 Oct 97 wrote Yuri Teterin to Rune Johansen: YT> FIDO-Policy describes the a net of phone-based stations. And the YT> demand of FTS-0001 capability referes to node's phoneline only. I don't know which FTS-0001 you are referencing, but mine (FTS-0001.015, Aug. 30th 1990, part of Fidonet Technical Standard) just states one thing about physical connection: >-8------------------------ byte here ------------------------8-< H. Physical Layer : the Actual Connection of Two FidoNet Systems Will one of the more hardware-oriented comm types give me some idea of what's needed here? Can we leave it open enough to allow implementation over a non-dial net? Thanks. >-8------------------------ byte here ------------------------8-< As ip is just a special case of a non-dial net, i see no reason to treat ip-nodes in another way than any normal node, as soon as their integration in the nodelist is defined. Which additional protocols they provide for access, does not matter. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #771 [1995] Scn From : Jesper Tragardh 2:200/108.21 15 Oct 97 23:44:04 To : Rune Johansen 18 Oct 97 19:47:20 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- RJ> My suggestion is that if you have one node with PSTN or ISDN (or RJ> both), and also have the possibility to have a IP node online on the RJ> internet for a fixed period of time, or CM, you would need another RJ> AKA. This AKA would be marked with a flag that said "This node has RJ> got a internet address (IP/FQDN) in the phone field", for example And if you put the ip/fdqn in the system-name field no extra AKA would be needed. Nifty, isn't it? /Jesper --- timEd/386 1.10 * Origin: Pinga varandra i IP-trafiken /JL (2:200/108.21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #772 [1995] Scn From : Rune Johansen 2:210/20 18 Oct 97 02:12:02 To : Yuri Teterin 19 Oct 97 13:29:50 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> So, a BinkP-only node would have to implement this to be policy compliant. >> When this is done, there would be no objections. > Should it be OK to be present in nodelist? If you are a IP-only node, you would have to offer FTS-0001 sessions via the protocol you have specified in the nodelist entry. > O, yes. If you'll be so stupid (or geneous) that will make your own > implementation of this idea (just to check me) - it shurely will be > incompatible with my Great Commercial Mailer, because your interpretation of > 'physical layer' in FTS-0001 will differs from my one ;-). And specifications > of my 'law layer protocol' are not free also (just like VMP is). > What can your say in this case? (leaning back, lighting up a cigarrette, puffing a little on it, leaning back to the keyboard) You really want to be difficult, don't you? I have been talking about IP-only nodes. If your node runs BinkP protocol, I should be able to connect to you via BinkP protocol, and do a FTS-0001 handshake (and optional file/mail transfers) with you. You list the IP layer as the only "physical layer" available, so you have to do it on that. If you have listed a phone number too, there will be no problem, as you are then NOT a IP-only node. *Sigh* --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #773 [1995] Scn From : Rune Johansen 2:210/20 18 Oct 97 02:15:54 To : Marco d'Itri 19 Oct 97 13:29:50 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- >> email is sent, I delete the bundles from my system, as I have sent them > You shouldn't. You don't know if the recipient received them. True. >> transferred completely. This cannot be done in a reasonable way when using >> email. > This is not true. You just have to use a good protocol. So, here we are talking about a mail exchange protocol that must wait for a acknowledgement that the bundle has been received. Should this method of acknowledgment also be listen in the nodelist? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #774 [1995] Rcv Scn From : Rune Johansen 2:210/20 18 Oct 97 02:23:24 To : Lothar Behet 19 Oct 97 13:29:50 Subj : A bit of steering ... ------------------------------------------------------------------------------- >As far as i read until now, the administration of subdomains for z2.fidonet.or > is handled very restrictively and at this moment it is primarily intended for > gateway administration. Here in region 21, we have put up a pair of nameservers for our nets. A request for delegation of the NS records for these have been sent by our RC. We just have to see what the reasons for not delegating them will be. We have at least 4 nodes in region 21 running 24x7 on the Internet, and by using the name server system, we would get even better connectivity than we have today. Since the generation and maintenance of the regional part of the nodelist are being done inside the region, why should the DNS part of it be held outside? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #775 [1995] Scn From : Rune Johansen 2:210/20 18 Oct 97 02:04:34 To : Yuri Teterin 19 Oct 97 13:29:50 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > FIDO-Policy describes the a net of phone-based stations. And the demand of > FTS-0001 capability referes to node's phoneline only. No, the demand of FTS-0001 refers to being eligible for being a node. From my copy of policy4: "Any system which wishes to be a part of FidoNet must be able to receive mail during this time using the protocol defined in the current FidoNet Technical Standards Committee publication (FTS-0001 at this writing). It is permissible to have greater capability (for example, to support additional protocols or extended mail hours), but the minimum requirement is FTS-0001 capability during this one hour of the day." > Further, FTS-0001 describes a session based immediately on a _physical_ layer > protocol. No. It's an open question in FTS-0001 wether the Physical layer should be so open to include non-dialable (by phone systems) nets. > All the protocols you have mentioned (telnet, vmodem, ifcico's 'raw > TCP') are not physical layer protocols and demand some software support, so > FTS-0001 is not direcly applicable to them. The analogy between a IP layer and protocols on top of them (in the TCP level) and a serial port is in my views equal. >sessions? I know hundreds of nodes which used for years mailers which supporte > yoohoo and EMSI only (and did not supported FTS-0001) - and nobody worried > about that. Then you should have been in region 21 a couple of years ago. If you were not FTS-0001 comatible, you would not get a node number. Today we in region 21 are a little more leniant about this, but we require fallback to FTS-0001 if they are not using EMSI (that all of us uses). > Who's requirements? Not the requirements of FIDO-policy, because it require > FIDO-node have phonenumber first of all. Not necessarily, as private nodes can be used, if they are to the good of Fidonet. That is to judged by *C's. > 1. ifcico and raw TCP are the same OK, now I know that. I would then prefer to say "raw", as I want to avoid using names bound to products, if there are other alternatives. > 2. what do you mean saying about telnet? When you use telnet for FTN-session > the only used part of telnet protocol just turn off all its special features >and turn the telnet chanel into the same 'raw TCP' chanel which ifcico uses. S > from the point of view of your beloved FTS-0001 telnet and 'raw TCP' are also > just the same. See message from Kim Heino about this in this echo. >> If it has got raw BinkP in addition, that's great. > What for? Have you _ever_ seen FTS-0001 session in your life? And to > implement features that will _never_ be used is at least very strange. Yes, I have seen it a lot, both over phone lines and over IP. It actually works. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #776 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 19 Oct 97 13:47:48 To : Marco d'Itri Subj : IP-connectivity ------------------------------------------------------------------------------- Hello Marco! 18 Oct 97, wrote Rune Johansen to Marco d'Itri: >>> email is sent, I delete the bundles from my system, as I have sent >>> them >> You shouldn't. You don't know if the recipient received them. RJ> True. >>> transferred completely. This cannot be done in a reasonable way >>> when using email. >> This is not true. You just have to use a good protocol. Which email-based protocols are according to this requirement? RJ> So, here we are talking about a mail exchange protocol that must wait RJ> for a acknowledgement that the bundle has been received. Should this RJ> method of acknowledgment also be listen in the nodelist? As it should be part of the used protocol, than the acknowledgement facility needs not to be announced seperately. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #777 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 18 Oct 97 00:44:06 To : Lothar Behet 19 Oct 97 21:49:34 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: >If an ISDN-only node serves no routing purposes for the net, he might be a >point :) Why do you apply that only to ISDN-only nodes and not to other nodes that "serve no routing purposes"? >As "ISDN-only node" was the first exception from the general connectability >rule, listing conditions for ip-nodes should be examined precisely. In the past we had uncompatible standards on PSTN lines too. >- buffering protocols without direct mailer session are possible (i.e. email >based), but then no secure transmission is possible (timestamp of arrival, >confidential communication) I developed a standard that would resolve those issues. I will pubblish it ASAP. Anyway I think IP only nodes should have 24h connectivity, but this is a /political/ decision, and IP_CONNECT is for tecnical discussions. >- generally additional costs for each user, as ip-access requires additional >charges to a service provider IP is cheaper for many users. You can't assumer that every user has a local toll BBS in his area. >- highly varying bandwidth (depends on general internet usage), therefore >required connect times (and costs) are not calculatable Nodes without 24h connectivity IMHO should only use email tunnelling because it has deterministic connection times. >At least one direct handshaking protocol between mailers in combination with >CM (or at least a specified "online" time above ZMH) seems a reasonable claim >for a nodelist entry. I agree, but this is a political decision. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #778 [1995] Scn From : Lawrence Garvin 1:106/6018 17 Oct 97 20:29:10 To : Rune Johansen 19 Oct 97 22:07:16 Subj : A bit of steering ... ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: > Your previous suggestion to use the NAMEfield for a FQDN is a better one, I > > think, than trying to put the IP address in the telno field. Besides, the > latter would require a rewrite of MAKENL or a new nodelist builder which all > coordinators would have to agree to utilize. The former requires NO changes > in existing nodelist utilities AT ALL! RJ> So, you are suggesting this: RJ> Node with both PSTN/ISDN and IP address: RJ> ,123,fully.domain.name.her,....,47-12345678,9600,flags,U,IP RJ> Node with IP only: RJ> ,Pvt,fully.domain.name.her,....,-Unpublished-,300,flags,U,IP It would seem that those two options are the only ones acceptable to current technical capabilites and requirements of policy. Although even the PVT nodelist may see an uphill battle in some areas. RJ> It will require rewrite of nodelist index compilers and mailers to RJ> utilitize the system name field, if they see the IP flag, if they RJ> prefer to use IP as transport instead of PSTN or ISDN. I think not the nodelist compiler, as all they do is move the string into the compiled file anyway. The -mailer-, however, will have to have an option to recognize the "IP" modem flag and extract the NODENAME field, instead of the TELNO FIELD. btw.... BinkleyTerm/VModem -can- place a call with ATDTyour.modem.name. All that's missing is the mailer option to extract the alternative field from the nodelist. RJ> Yes, I can see that the complaints about not being able to list RJ> their "Bazooka BBS" in the system name woul be superseded by the RJ> extra functionality. Quite frankly, Rune, I really can't see where anybody would lose sleep over their 'nodename' saying bbs.bazooka.com rather than The_Bazooka_BBS -- it's stil an accurately descriptive name. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #779 [1995] Scn From : Lawrence Garvin 1:106/6018 17 Oct 97 20:34:38 To : Rune Johansen 19 Oct 97 22:07:16 Subj : IP-access ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: > And in many, too/unnecessarily inefficient. >For starters, it uses 7-bit transfers! Second, it's native 'g' >protocol has so > much overhead that the average efficiency of uucp is about 60% of capacity. RJ> Yes, UUCP-g is loaded with overhead. UUCP-t is not. :-) I'm not familiar with UUCP-t -- could you send me netmail/email with more info, or catch up with me in UNIX? --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #780 [1995] Scn From : Lawrence Garvin 1:106/6018 17 Oct 97 20:37:40 To : Rune Johansen 19 Oct 97 22:07:18 Subj : Flags in nodelist ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: > Rune... here's a thought... while FIDONET.ORG may be dependent upon > the "Internet" -- there's also nothing keeping Fidonet(tm) from > setting up our own proprietary ROOT SERVER in the Top Level Domain > .FIDONET or .FIDO RJ> The DNS servers maintaining the querys by "our" members would have RJ> to point to "our" root servers to get them resolved. To be sure RJ> that "we" are being resolved correctly all the time, we need them RJ> to point _all_ their root entries to us, and we would point them to RJ> Internic's root servers for queries outside our FIDONET or FIDO RJ> root domains. That way they would get a answer from us to go RJ> there-and-there for com., org., etc. domains. That is a potential issue, fer sure. And as I recall the discussion in TCPIP, it was with respect to a -worldwide- resolution issue.... However, if'n one presumes that my BBS machine is only being used for Fidonet and my BBS -- then there's no real harm in pointing my resolver at a DNS server inside the .FIDO zone and acting as if that's the only DNS zone in the whole world. Also, I can actually list TWO resolvers in my configs, the .FIDO DNS server first, and any other DNS server second. If the name fails in the .FIDO domain, then the resolver will attempt to look it up at the DNS server identified in the second line. In such a case, I don't believe it would be necessary for the .FIDO root servers to point to any Internic servers -- the obligation would fall back to those Fido nodes to provide for resolving in both systems -IF- they needed to actually resolve non-Fido DNS names from the Fido/BBS machine. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #781 [1995] Scn From : Lawrence Garvin 1:106/6018 17 Oct 97 20:35:32 To : Rune Johansen 19 Oct 97 22:07:18 Subj : IP-access ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: > Many forget that uucp was designed as a protocol to transfer email > messages, which were short, and overhead wasn't a real issue. > But then somebody bastardized it into doing file transfers and it's > never been the same since. RJ> Ooohhhh... If i search-n-replace "uucp" here with "fidonet", I RJ> still get the same result :-)) Hehehe... ain't that the truth! --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #782 [1995] Scn From : Lawrence Garvin 1:106/6018 17 Oct 97 22:01:10 To : All 19 Oct 97 22:07:18 Subj : FYI - FWIW ------------------------------------------------------------------------------- Hello All! Zorch Frezberg successfully polled my Vmodem port 23 Bink XE last Wednesday afternoon with an Argus on Win95 mailer. Mebbe there's more compatibility than we thought? I'm waiting for more details from Zorch as to exactly how he placed the call, but there it is! From 1:205/2 to 1:106/6355: 15 Oct 17:43:57 BINK 'RING' 15 Oct 17:43:57 BINK 'CONNECT 57600/ARQ/TEL FROM 209.77.232.2' * 15 Oct 17:44:01 BINK System: Net 205 Test Server (1:205/2) * 15 Oct 17:44:01 BINK Uses : Argus 2.8/95/UNREG : 15 Oct 17:44:01 BINK Sysop : Server Sysop from Fresno, California, USA 15 Oct 17:44:01 BINK Flags : CM,TCP,IFC,TEL,VMP,BND 15 Oct 17:44:01 BINK Phone : 209.77.232.2_2024 : 15 Oct 17:44:01 BINK Tranx : Wed Oct 15 15:45:32 1997. (-7108) : 15 Oct 17:44:01 BINK Local Mail on Hold: 0b : 15 Oct 17:44:02 BINK Session method: Hydra + 15 Oct 17:44:05 BINK Nothing to send to 1:205/2. * 15 Oct 17:44:08 BINK End of WaZOO/EMSI Session. 15 Oct 17:44:15 BINK Received: 0/0K Sent: 0/0K Total: 0/0K CPS: 0 * 15 Oct 17:44:15 BINK Seconds: 13 Tariff: 10 Fee: 0 RFee: 0 System: 1:205/2 --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #783 [1995] Scn From : Lawrence Garvin 1:106/6018 17 Oct 97 20:44:30 To : Denis McMahon 19 Oct 97 22:07:18 Subj : IP-connectivity ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Denis McMahon said in a message to Lawrence Garvin: DM> Lawrence Garvin wrote to Denis McMahon: DM> If you can transfer FTS-0001 packets fully automated at both ends DM> then the connection is a fidonet connection. LG> Dennis, it's not just FTS-0001 packets that are at issue, it's LG> live, direct, one-to-one MAILER connections that should be the LG> issue. DM> Lawrence, if you want me to believe that you understood what you DM> read, you would do well to type in my name as it appears on your DM> screen. A failure to do so implies that you can't actually see what DM> you're looking at ..... I'll dispense with the reading of the rest of your message on the off chance that yet another innocent mistake might give you cause to continue your petty bickering of which I'll not be a part of. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #784 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 19 Oct 97 22:47:02 To : Marco d'Itri Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Marco! On 18 Oct 97 wrote Marco d'Itri to Lothar Behet: >> If an ISDN-only node serves no routing purposes for the net, he >> might be a point :) MI> Why do you apply that only to ISDN-only nodes and not to other nodes MI> that "serve no routing purposes"? Because he can only be reached from a limited number of other nodes, exactly only by those who use the same technique (ISDN) and protocol (i.e. X75 in europe and v120 in america). Any other node (except 300/1200 bps) is open to calls from all around the world and should be able, to route inbound mail to its recipient. >> As "ISDN-only node" was the first exception from the general >> connectability rule, listing conditions for ip-nodes should be >> examined precisely. MI> In the past we had uncompatible standards on PSTN lines too. As far as i know, there was only a real bell/v21 problem in early times. Other modes could fall back to 2400 bps (V22bis?), as that mode was supported by all (AFAIK) high(er) speed modems, including PEP and HST. >> - buffering protocols without direct mailer session are possible >> (i.e. email based), but then no secure transmission is possible >> (timestamp of arrival, confidential communication) MI> I developed a standard that would resolve those issues. I will MI> pubblish it ASAP. Anyway I think IP only nodes should have 24h MI> connectivity, but this is a /political/ decision, and IP_CONNECT is MI> for tecnical discussions. IP-nodes in the nodelist should be reachable at least at a specified timeframe (CM prefered), otherwise they are useless in the nodelist, except for buffered (elsewhere!) email transfer without any acknowledgement about correct receipt. >> - generally additional costs for each user, as ip-access requires >> additional charges to a service provider MI> IP is cheaper for many users. You can't assumer that every user has a MI> local toll BBS in his area. Are we talking about fidonet and its members or about bbs-users, who are just using the fidonet (or generally ftn) for routing? I think, that fidonet primarily consists of nodes, who form a network for mail exchange between (mostly) bbs's. So we have to talk about steadily engaged members of this network, at first of the already existing ones and then about methods, how we can aquire new members, without annoying the old ones, who have to operate their system according to certain policies and specifications. >> - highly varying bandwidth (depends on general internet usage), >> therefore required connect times (and costs) are not calculatable MI> Nodes without 24h connectivity IMHO should only use email tunnelling MI> because it has deterministic connection times. Then you have no secure link in aspect of delivery and the time of it. >> At least one direct handshaking protocol between mailers in >> combination with CM (or at least a specified "online" time above >> ZMH) seems a reasonable claim for a nodelist entry. MI> I agree, but this is a political decision. It is a basic claim according to the fidonet policy and should also be honored in respect of the existing members, who operate their under these conditions. Otherwise any bbs-user has the right to claim a nodenumber, if any ip-user would get one :( This is no pure political decision, but we have to define a senseful border between nodes (members of fidonet) and other users. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Looking for a Cray, may be used (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #785 [1995] Scn From : Chris Maddock 3:640/302 19 Oct 97 09:30:42 To : Marco d'Itri 20 Oct 97 05:42:38 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- On 14 Oct at 14:42, Marco d'Itri of 2:335/680.666 wrote to Chris Maddock: >>1. A special character or sequence tha signifies a IP node or whatever, and >>translates the number (or some other field). Md> An user flag "IP" should be enough. >>The "Baud_Rate" field could do this easily ? It sure isn't used much for much >>else 'cept ISDN nodes. Md> No, we can't specify an arbitrary baud rate (can you say "brain damaged Md> standard"?). I can. No probs. The standard may have to be changed anyway so we may need to implement a set of standards to follow or insist that the old standards can be used if they are already sufficient. I suspect they are already sufficient but have not been followed. >>2. Flags. A series of flags to indicate that a node is IP (or whatever) >>capable. Md> I have seen a good proposal in this echo. Yes. I saw it a couple of days ago. Looked good. I am a little purturbed as to the large number of flags though. >>3. Routing. Some indication is required to indicate how to route the mail to Md> I can't understand what we should add in the nodelist. I think that the Md> choice of the preferred protocol should be made by the calling sysop. The Md> node can force a preference between protocols by specifying the flags in Md> the prefered order. >>and nodelist generator authors to make changes, but we are going to need to >>be >>able to say =exactly= what changes are required. Md> Compilers should just accept a longer flag field and an FQDN in the phone Md> field. That is one solution, and a valid one too. Other solutions need to be investigated as well for future use so that one change is needed only. >>5. It has to be as simple as possible. It's no point making a system that >>becomes so complicated that any changes made in the future break it. Md> My proposal is so simple that it already works with many compilers (e.g. Md> fastlst). >>6. We may even have to look at a different type of nodelist - binary perhaps >>? Md> You should read my extended nodelist proposal, I will attach it by email. Got it Marco. I've been working very long hours (I have my own business) and have only been able to give it a cursory look over so far. It looks good from what I saw so far and shows a lot of thought and professionalism. You are to commended. Regards, Chris Maddock chrism@bbs.st.net.au --- Msged/386 4.20 beta 2 * Origin: Diagnostic CBBS - DownUnder - (3:640/302) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #786 [1995] Scn From : Chris Maddock 3:640/302 19 Oct 97 09:22:10 To : Marco d'Itri 20 Oct 97 05:42:38 Subj : Re: IP-access ------------------------------------------------------------------------------- On 14 Oct at 14:20, Marco d'Itri of 2:335/680.666 wrote to Lech Szychowski: Md> Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >>We can always go for "fidonet.org.", this option being >>the proper one according to DNS pragmatic. Md> Not all Registration Autorities register domains for everybody. In Italy Md> we had to register fidoitalia.net because private entities can't register Md> domains (we would need to register a formal fidonet association). That then leaves the situation where fidonet.org. should be used by those that can and be in the care of the zone co-ordinator or in his absence, the Zone RCC, and whatever has to be in the others such as Italy. Hell ! Leave out the Z*C and leave it in the hands of the RCC in each zone so it can't be controlled or manipulated by only one person. This would also mean that one person could not be targeted by anyone or group because of the domain name caretaker role. Regards, Chris Maddock chrism@bbs.st.net.au --- Msged/386 4.20 beta 2 * Origin: Diagnostic CBBS - DownUnder - (3:640/302) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #787 [1995] Scn From : Chris Maddock 3:640/302 19 Oct 97 08:42:48 To : Pedro Lima 20 Oct 97 05:42:38 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- On 15 Oct at 00:27, Pedro Lima of 2:362/21 wrote to Chris Maddock: PL> Hi, CM>> Depends on what I tell it to do. I use Fastlst. PL> I mean, with your present configuration, to what would FastLst translate PL> '000-'? Good question. If I don't put any translation in. it would dial: 0015-000- CM>> 1. A special character or sequence tha signifies a IP node or CM>> whatever, and translates the number (or some other field). The CM>> "Baud_Rate" field could do this easily ? It sure isn't used much for CM>> much else 'cept ISDN nodes. PL> I'd use 300 as well... The intention of using 300 is to more easily PL> filter the ISDN nodes from the rest with modem nodes, which is similar PL> to the current IP situation. Yes. And if the noelist compiler authors made the baud field able to take any integer from 0-65535, we would be able to have a simple flag to indicate IP and the baud field could be used usefully for indicating exactly what is on the node as far as capabilities go. For instance, 9600 could stay as "high speed modem" which it is at the moment as a de-facto standard. We could use powers of 2 and add all the bits together to denote the total capability of the site. i.e. 1=Telnet 2=VMODem 4=BinkD etc CM>> 2. Flags. A series of flags to indicate that a node is IP (or CM>> whatever) capable. PL> A single flag would suffice to indicate general IP capability. PL> Specifying the actual IP protocols may be dealt with via other flags. Fair enough. IP as the first flag followed by a comma delimited indication. Whilst this would be easily human readable, it could take a lot of room. Not that that is really a huge problem. CM>> 3. Routing. CM>> 4. Nodelist compilers. CM>> 5. It has to be as simple as possible. PL> Agreed. I guess it is obvious and my comment was superfluous. CM>> 6. We may even have to look at a different type of nodelist - binary CM>> perhaps ? Something that could be run in parallel with the existing CM>> nodelist, only for IP nodes perhaps ? This would make any expansion CM>> into different technology much easier in the future and not break what CM>> we currently have. CM>> As far as 6. is concerned, we could even use the current nodelist to CM>> provide an index into the parallel nodelist ! PL> Yes. However, the degree of complexity of this solution is similar, PL> IMHO, to changing the nodelist format and creating from it old-format PL> nodelists (in a way, this is the reverse of what you're suggesting), PL> which anyway will be a necessary move if we're ever planning to change PL> the format to allow for old-style compilers to work. Hmmmm. On reflection, and as pointed out in Netmail and Email to me, my second suggestion is useless. Our biggest problem IMHO, is that the mailers we use and love so much (with good reason I might add) have to support whatever we compile with the compiler. For this reason I would love to see something like regional DNS's to resolve addressing and routing. I am also aware that this is apparently being addressed in another thread but some of the discussion is way over my head. I =do= want to see Fidonet survive and run as an alternative to the Internet newsgroups, and also to be a non-commercial alternative to same. I see the IP issue as the gateway to this end and it will also give Fidonet =back= to the amateur hobbiest at very little or even no cost and a huge return in benefits. Regards, Chris Maddock chrism@bbs.st.net.au --- Msged/386 4.20 beta 2 * Origin: Diagnostic CBBS - DownUnder - (3:640/302) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #788 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 20 Oct 97 08:03:30 To : Chris Maddock Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hello Chris! On 19 Oct 97 wrote Chris Maddock to Marco d'Itri: >>> 2. Flags. A series of flags to indicate that a node is IP (or >>> whatever) capable. Md>> I have seen a good proposal in this echo. Flag space may be saved if there would be a combined flag, which defines IP-capabilities like this Example: ,301,fido.nrh.de,Uedem_FRG,Lothar_Behet,49-2824-922240,9600,CM,XA,V34, U,X75,IPC:11 Conventional flags stay obviously as is. IPC advises the nodelistcompiler to use the node_name as valid ip address and gives information (in deciaml or hexadecimal form) about capabilities according to a key table: 1 Telnet 2 Vmodem 4 Ifcico 8 BinkP 16 FTP 32 ... to be continued ... This table may contain up to 32 different protocols, which would consume 4 (hex) to 5 (decimal) bytes of flag space. 64 possiblities would need 8 byte in hex-notation. As nodelist compilers have to be modified anyway to allow parallel processing of ip and conventional data, it would not be such a problem to teach them this protocol table additionally (it should be handled configurable). At the same time this would not cause any conflicts for conventional nodes and save a valuable amount in distribution size. The only disadvantage for human readers is the bitwise translation to a dedicated protocol. CM> Yes. I saw it a couple of days ago. Looked good. I am a little CM> purturbed as to the large number of flags though. If we are talking about the same sample, then this one should be much better. Md>> Compilers should just accept a longer flag field and an FQDN in Md>> the phone field. Unlikely there are many different compilers working in the wild, which surely have different capabilities and some may be quite special for a dedicated software and operating system. So we should search on short term for a solution with as less deviance from the known data (and amount), that is possible. >>> 6. We may even have to look at a different type of nodelist - binary >>> perhaps ? Md>> You should read my extended nodelist proposal, I will attach it by Md>> email. CM> Got it Marco. ... CM> It looks good from what I saw so far and shows a lot of thought CM> and professionalism. You are to commended. That is the long term solution. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #789 [1995] Scn From : Denis McMahon 2:251/20 18 Oct 97 17:28:10 To : Amir Shabashvili 20 Oct 97 08:38:16 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Amir Shabashvili wrote to Denis McMahon: DM> OK, I want to send a routed netmail to an ip system. I address it to DM> the IP system. My mail tracker won't let it be sent because the DM> destination system is not in the nodelist. AS> Tracker I've working fine with all nodelist files I told him about. I shouldn't have to use multiple nodelists to send a message to another fidonet sysop. Fidonet is defined by the fidonet nodelist. If IP nodes are to be "in fidonet" then they have to be in the fidonet nodelist. Next? Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #790 [1995] Scn From : Marco d'Itri 2:335/680.666 19 Oct 97 22:26:54 To : Rune Johansen 20 Oct 97 22:37:36 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >So, here we are talking about a mail exchange protocol that must wait for a >acknowledgement that the bundle has been received. Should this method of >acknowledgment also be listen in the nodelist? I think it should be, event if this should not be enough to get a node number. -- ciao, Marco --- ifmail v.2.11-tx8.5 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #791 [1995] Rcv Scn From : Pedro Lima 2:362/21 19 Oct 97 06:41:42 To : Lothar Behet 21 Oct 97 00:18:38 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hi, LB> As i did not address spelling, i hold my :) up. :-) LB> Not in every case. There are several char fields in the nodelist, LB> which may contain more useful data then just names. Some of them LB> preserve a limited room, which has to checked for makenl and all LB> nodelist compilters. People are usually very attached to what they have, and they won't be usually available to loose say the system name to convey an IP address or a FQDN. Also, using the phone field for the IP address is perfectly coherent with the purpose it now has. LB> But then you loose the advantage of combined entries :(, which saves a LB> lot of lines. LB> On the other hand, still software with very limited LB> aka-recognition is widely used. These problems can only be effectively solved by a new nodelist format. LB> As long as the nodelist compiler knows which fields and flags to LB> monitor, it can create even a combination of different lists according LB> to the mailers specifications. Ok, you have a versatile compiler. Other's don't, but have software which is going to look for an IP address in the phone field (although I admit the solution of the special prefix somewhat disturbs this process). LB> The basics of fidonet was worldwide communication within a network of LB> publicly accessable bbs's. Running a public BBS is not a requirement to become a FidoNet node. But more important than this, I disagree (sorry) that these are the basics of FidoNet. The basics of FidoNet are about uniting the voluntary efforts of a group of people to allow them to communicate with one another. It has nothing to do about being worldwide or public BBSing, those are eventually consequences, not the causes. LB> Why should this concept not satisfy the purposes of an ip(-only) LB> member in the international communication, as long as he has no LB> downlinks (no routing)? Because there's no reason why we shouldn't allow IP-only nodes. Are you afraid that FidoNet looses its identity if we're going to allow these nodes? How come, if its identity is what its participants choose it to be? LB> If you allow any ip-access as sufficient for a listing as node, then LB> you must allow any point to be a node also. I sincerely hope you're not implying that only distribution systems should be admitted into FidoNet? And no, I wouldn't admit *any* IP access, only those which allow for two mailers to connect to one another. LB> On the other hand, if there are more ip-nodes at a certain moment than LB> conventional ones, who will stop the integration of fido into the LB> internet then? Is that what the FidoNet sysops really want? Because if it is, then neither I or you would be able to stop it. All I can say is that I feel that FidoNet and Internet are two very different things, and these differences wouldn't go away even if all of FidoNet started working over the Internet. LB> As far as i know, the existing format is not capable for indefinite LB> long entries on most systems, so the redefination of some fields can LB> only be a timely solution. But this intermediate patch should not LB> exceed the tolerance of the general node and the capacity of an LB> average system. Well, we've had multiple akas at work for years, and if I can't say that there haven't been any problems, I surely can say that FidoNet wasn't compromised because of it. LB> Here in R24 is a strong opposition against any ip-entries at all, but LB> sometimes it is based on a misunderstanding of the tunneling LB> technique. I'd be interested to know some more about the grounds for this opposition, if you can summarize it. LB> Then we should focuse on a compatible solution for short term, while LB> we begin to work on a better and more complete format. Yes, I fully agree. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #792 [1995] Scn From : Frank Ellermann 2:240/5815.1 18 Oct 97 01:21:00 To : Marco d'Itri 21 Oct 97 07:01:10 Subj : was: A bit of steering ... ------------------------------------------------------------------------------- MdI> If we exceed the limit on flags length we could as well use MdI> the extended nodelist format. .. you didn't answer my questions in NET_DEV concerning your extended nodelist proposal until now ?! I forward it for info, see below, bye, Frank To : NET_DEV (Marco d'Itri) Subject : Re: Extended nodelist Date : Mo 22.09.97, 12:50 Message-ID : 2:240/5815.1@fidonet.org d4ac263c Hi Marco, MdI> Any comment is welcome (even about spelling!). ... :-) MdI> nodelist = header eol MdI> [ crc eol ] MdI> *(line eol) Today there is an EOF at the end, not included in the "compatibility CRC", as you call it... I still consider this EOF as optional, do you want to drop it completely ? Okay for me... (but my name is not MakeNL :-) MdI> / "Point" ACK... David has an old "Ogate" in his NLTools, IIRC. MdI> node_num = ( fido_addr / fido_num ) MdI> fido_addr = number ":" number "/" number MdI> [ "." number ] Full 3D- or 4D-address allowed ? What's wrong with the old 1D fido_num ? MdI> fido_num = number ; 16 bit signed integers except the point num. Hmmm... at least exclude 0 as fido_num, that's an old bug in FTS-0005. If you define a list, then unsigned 1..32767 is the best you can do. -1 is never listed, and whether it's treated as 65535 or -1 depends on the implementation => don't care. MdI> node_name = text MdI> location = text MdI> sysop_name = text Not "text", how about 0 to 63 "text7" ? MdI> phone_num = 1*( digit / "-" / "*" / "#" / "." / "_" / "+" ) "A", "B", "C", "D" ??? I'm just asking... MdI> compat_bps = ( "300" / "1200" / "2400" / "9600" / "19200" / "38400" ) Add 12000, 14400, 16800, 28800, 33600, 56000, 64000, and "" please. MdI> xtd_data = ( xt_phone I skip this part, because I'm only interested in the "compatible" sections... MdI> email_addr = "> ... but I don't like references to RFCs in FTS, resolve it please. MdI> comment_A = ";A " text ";A" is only a shorthand for ";SUF" today. Maybe we don't need ";F" anymore, then it's okay to replace the remaining ";SU" or ";US" by ";A" completely. MdI> day = ( "Monday" / "Tuesday" / "Wednesday" / "Thursday" MdI> / "Friday" / "Saturday" / "Sunday" ) Hmm... here you're specifying the header more rigid than FTS-0005, you should better avoid this... just an example, a private list I'm using here... ;A dummy pointlist for every day : 04106 ... what I'm looking for are 5 digits introduced by ": " at the end of the first line, then I consider this as a "compat_CRC". And I insist on ";A" at the beginning, but maybe even this "A" is too restrictive (?) MdI> text7 = 1*( range 0x20-0x7E except "," and " "> ) ... :-) How about "range 0x21 - 0x7E except 0x2C (comma)" ? MdI> text = 1*( text7 / in the range 0x80-0xFF> Interesting... do you really want to allow 0x80 - 0xFF ? Only in comments or also in names ? Which charset, Latin-1 ? Okay, at least a hint, that CRC-algorithms should not break for 0x80 - 0xFF could be an improvement... :-) MdI> If the local policy allows that, the checksum can be omitted, MdI> because the extended one works better. As long as I use old tools, the old checksum works better than only some new extended checksum... in other words: drop this comment, if you like, you can reinsert it 2010. MdI> cryptographically strong (i.e. SHA or the weaker MD5) Maybe you should resolve these references too. Or at least GIVE the reference, example code in C or whatever fits... When I once tried to improve FTS-0005, I added some lines of example C code for compat_CRC (without 8-bits-bug). MdI> extended data entries are stored after the ",U," user Mdl> flags delimiter; Pseudo flag "U" is still a special zone 2 convention, other zones use the old FTS-0005 U-string-concept like in ",USDS". MdI> The "ISKRA" type is not known by the writer of this Mdl> document [...] ... never heard of this one before, better omit it then ? MdI> VMP vmodem protocol (3141) Don't ask me why, but Ward and Lothar called this one "VM". Maybe they change it later, it's only an experiment. MdI> The "TCP" flag should not be used because it can't be Mdl> differenced from the Txy time flag. ACK. MdI> The "EMAIL" type advertises an Internet mailbox that Mdl> can receive arcmail or file attaches encoded in one of Mdl> those formats: Is this meant to replace Steve's proposal ? BTW, IMHO we're better off, if we split flag proposals from the general nodelist layout, flags change often, but the nodelist layout is still the same as in FTS-0005.TXT (1989, the predecessor of last year's FTS-0005.003 with a few minor enhancements). MdI> Nodelist processors must support 8 bit characters, but [...] Oops, tnx, ignore my charset question above... bye, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #793 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 03:33:00 To : Rune Johansen 21 Oct 97 07:23:50 Subj : A bit of steering ... ------------------------------------------------------------------------------- >> My system is reachable from the Internet as three IP addresses [...] > You are a exception to the rule. :-)) So were the multiline systems when nodelist as we have it now was designed. And real life has shown it was a bit shortsighted assumption. Now things change much faster than 10 years ago... > 2) List all three IP's under one FQDN, with only one AKA. [...] > Most people would prefer solution number 2, Yes, I think so. It's the only solution available now that makes use of the redundancy multiple links give. > your system. Solution number 2 would also be used on a node that has got > several IP addresses, with load sharing by using round-robin DNS. True round-robin DNS server is a complicated thing to design and buid. I/m not even sure if it's possible - this server would have to keep separate RR queue pointers for each requesting system and each type of record that it ever received a request for. Add things like hosts with multiple IP addresses and you are in deep sh*t. But I'm afraid that goes a bit beoynd the scope of this echo... :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #794 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 02:32:00 To : Marco d'Itri 21 Oct 97 07:23:50 Subj : A bit of steering ... ------------------------------------------------------------------------------- > If this is your concern then you should use round robin DNS. Which is not a standard feature, right? I can't remember RFC saying anything about round-robin behavior of NSes being obligatory. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #795 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 03:05:00 To : Marco d'Itri 21 Oct 97 07:23:50 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- > I agree, but *all* nodes (PSTN or IP) should be able to advertise in the > nodelist email or ftp service. sysop's email address can always be constructed as something like postmaster@fF.nN.zZ.fidonet.org, right? Just make this FQDN's MX point to the right name/address. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #796 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 02:31:00 To : Marco d'Itri 21 Oct 97 07:23:50 Subj : A bit of steering ... ------------------------------------------------------------------------------- > For ISDN you will get another node numeber, why you don't want one for IP? And have to tell your mailer manually that X, Y and Z are all aliases for the very same system, so it's a good idea to try all phone numbers (or IP addresses in this case) when trying to connect to any of X, Y and Z? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #797 [1995] Scn From : Rune Johansen 2:210/20 20 Oct 97 01:41:02 To : Lawrence Garvin 21 Oct 97 07:23:50 Subj : A bit of steering ... ------------------------------------------------------------------------------- > It would seem that those two options are the only ones acceptable to current > technical capabilites and requirements of policy. Although even the PVT > nodelist may see an uphill battle in some areas. I think that a Pvt-debate would be easier for people to give in to, rather than a "you all need a new nodelist compiler, to adopt to our outrageous attempts to include IP-only nodes in the nodelist". With nodelist compiler, I am thinking of MakeNL. >> It will require rewrite of nodelist index compilers and mailers to >> utilitize the system name field, if they see the IP flag, if they >> prefer to use IP as transport instead of PSTN or ISDN. > I think not the nodelist compiler, as all they do is move the string into the > compiled file anyway. The -mailer-, however, will have to have an option to > recognize the "IP" modem flag and extract the NODENAME field, instead of the > TELNO FIELD. I don't know how mailers use the nodelist indexes, so I cannot say more on this. I thought they made a file that the mailer used to figure out how they were to dial. > btw.... BinkleyTerm/VModem -can- place a call with ATDTyour.modem.name. :) My mailer can do this too (natively) :-)) > Quite frankly, Rune, I really can't see where anybody would lose sleep over > their 'nodename' saying bbs.bazooka.com rather than The_Bazooka_BBS -- it's > stil an accurately descriptive name. Me neither, but I have seen some whining about it in ENET.SYSOP earlier. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #798 [1995] Rcv Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 04:21:00 To : Lothar Behet 21 Oct 97 07:23:50 Subj : A bit of steering ... ------------------------------------------------------------------------------- > My published addrees is: fido.nrh.de > The domain file contains several lines of > fido IN A 194.231.142.17 > fido IN A 194.231.142.18 > ... > So i can spread the service in my subnet over several machines, which > serves a load balancing between the individual computers and a local > backup, if one machine stops the service. Now I see... Well, you are right here. But that's a feature you get for free from DNS (which in no case is supposed to diminish its worth). > LS> The big question here IMHO is "do we really need to put into nodelist > LS> information that is completely outside the area of interest for PSTN > LS> nodes?". 3D/4D address is already there, and if we either indicate > LS> a domain or use the default "fidonet.org" we can very easily construct > LS> a unique FQDN for each system. > Yes, the publication in the nodelist makes sense, as other nodes with > the same capability may initiate a direct link. I think this time you didn't get me right :) I was/am agains listing an FQDN if it can be constructed from the data we already have: node number, network and zone - plus the domain suffix, "fidonet.org" being the default one to be used if no other specified. > As far as i read until now, the administration of subdomains for > z2.fidonet.org is handled very restrictively and at this moment it is > primarily intended for gateway administration. I think it's an excessive restriction. If an IP system is to be used as a hub or echomail feed, it should IMHO be considered a good candidate to be listed. Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #799 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 04:33:00 To : Rune Johansen 21 Oct 97 07:23:50 Subj : A bit of steering ... ------------------------------------------------------------------------------- > Since the generation and maintenance of the regional part of the nodelist > are being done inside the region, why should the DNS part of it be held > outside? Very interesting question, indeed. Is it still within the allowed range of topics? Just asking, not complaining; I can't wait to see the answer to the original question too... Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #800 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 03:03:00 To : Marco d'Itri 21 Oct 97 07:23:50 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- > Yes. I never wrote that is a good idea to have an email-tunnelling only > node, but I think that any node that wants to advertise this capability > in the nodelist should be able to do that. As an additional capability which is there primarily for sending mail messages to sysop, yes. But not as a general transfort mechanism for mail routing. > email-tunnelling is a cheap way for a PSTN node to send crashmail Err... How can one combine "email" and "crash"? Hint: MX'es. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #801 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 02:54:00 To : Fyodor Ustinov 21 Oct 97 07:23:50 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- > Sunday October 12 1997, Lech Szychowski writes to Sean Rima: > LS> OK, so let's say we spare 3 seconds on each session. [...] > Total Sessions : 5600 > 5600*3/60/60 ~= 5 Hours.... We're not talking PSTN here - we are talking packets and multiple sumultaneous connections, right? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #802 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 04:07:00 To : Yuri Teterin 21 Oct 97 07:23:50 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- > It does, but for TCP-connection only ;-) (because getty or its > clones, which listen usually at modem COM-port, can not recognize > FTS-0001 session and so are not able to call ifcico itself). So is it ifcico's itself or "ifcico behind getty" team's fault? :) Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #803 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 03:58:00 To : Denis McMahon 21 Oct 97 07:23:50 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- > So, as I said, for FTP, accept anonymous upload of *.pkt and arcmail > files, just like happens during a session today. Name clashes? Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #804 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 02:28:00 To : Marco d'Itri 21 Oct 97 07:23:50 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >>FTP daemon will rename received files? > I think so. Sorry, but I don't. > You can find the source for this modified wu-ftp on ftp.fido.de. Ready to compile on what systems? And a more fundamental question: is this still the standard FTP protocol? I highly doubt we can claim it is. Therefore calling it "FTP" is seriously misleading and - IMHO - wrong. > Ok. Do you think is ok to allow the public[1] use of email and ftp > transports if some requirements are meet? Theoretically yes. But only theoretically, since - please don't hesitate to correct me if I'm wrong - some of the requirements cannot be met by the mentioned protocols in their current shape. >>And how does SMTP pick the attach up? > He does not. The file will be sent him to his email address, tunnelled > like normal arcmail. Your answer IMHO says just "any file can be delivered to any recipent". This is still true for systems using snail mail for sending human readable requests (ie names of the files written on a sheet of paper) and digital media (eg diskettes). But would you call this "networking" Fido? :) >>SMTP nowadays supports nearly everythingh as a message body. But it has >>nothing to do with the session authorization. > My protocol provides multiple ways to verify the sender of a message. It's damn easy once you start using tools like PGP. Then any carrier media will do. But is it still Fido? >>no longer be the FTP as RFC defines it. > It will be the same exact protocol, just the daemon will be smarter and > will correctly move in the inbound/outbound the arcmail. Nope. I'm afraid it's perfectly valid for an FTP client to assume when performing PUT operation that if a file of a given name already exists it will be either overwritten (if permissions allow) or operation will fail (if permissions do not allow it). If you modify this command behavior the protocol is not FTP any more. If you use another command, the protocol is still not FTP... >>We certainly will need it. A lot of mailers enforce limits on the >>size of a single message. > In the modern internet? Yes. For a very simple reason: it takes long to transfer a huge message. And everyone knows that routing breakes down from time to time, TCP connections have their timeouts and SMTP has no "RESTART" command. > [1] If I want to receive my echomail via flying pidgeons (RFC 1149) and > my boss agree no one should force us to use another transport. You're talking about point-to-boss traffic here, right? Than it's not a Fidonet issue :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #805 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 02:51:00 To : Amir Shabashvili 21 Oct 97 07:23:50 Subj : A bit of steering ... ------------------------------------------------------------------------------- > LS> My system is reachable from the Internet as three IP addresses [...] > Is it full-time links with fixed IP-addresses? Yes, these are leased lines and it's a "regular Internet host". > Or it is dial-up connection with getting random IP address from > ISP's address spool? That's different things. I'm quite aware of that. Actually I wrote more than once here that generally I'm against a dialup-connected system to be granted the IP-node status; the only exception I can allow for is a node that has decided to be online each day for a period of time listed in its nodelist entry using T flags :-) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #806 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 02:34:00 To : Sean Rima 21 Oct 97 07:23:50 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- > I think as others have said that it is getting Ipmailers into the > nodelist and not the protocols that is being debated. Of what use is a mailer without a protocol one can use to talk to it? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #807 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 04:29:00 To : Rune Johansen 21 Oct 97 07:23:52 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > IP-only nodes. If your node runs BinkP protocol, I should be able to > connect to you via BinkP protocol, and do a FTS-0001 handshake (and If I'm not completely wrong, BinkP is not a "transport layer" protocol, it's a "session layer" one - so it's used instead of FTS-0001. Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #808 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 02:36:00 To : Sean Rima 21 Oct 97 07:23:52 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Not sure if that will be required protocol wise. In a nodelist all you > need to do is use the U, then the protocol. If you cannot connect to a > node, then you route the mail. So you say all flags like ZYX, HST etc are not neeeded, because you can always make a call and see yourself if you can talk to remote part? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #809 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 03:24:00 To : Rune Johansen 21 Oct 97 07:23:52 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > the IP node in question. The only thing a IP node needs, according to > the policy documents, are a FTS-0001 capable "thingy" in the other end, > at least. It is very difficult to change this policy (several has tried). OK, I wholeheartedly agree I don't care much what protocol is used as a carrier media for FTS-0001 session - as long as the mailer attempting to connect can choose which one to use based upon flags in the called party's nodelist entry. > According to my interpretation of discussions here and elsewhere, a > BinkP-only IP-only node does not meet minimum requirements for being a > public node in Fidonet. That's my concern, too. Precisely. > A FTS-0001 IP-only node _does_ meet the requirement, due to the FTS-0001 > part. Wether it uses telnet, ifcico, SIO's VModem or raw TCP for its > connection, does not matter. Again, I second this. > If it has got raw BinkP in addition, that's great. Sure it is. If BinkP is as good as people claim it is, I'd be glad to add BinkP capability to my node. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #810 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 03:52:00 To : Dima Maloff 21 Oct 97 07:23:52 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Why, oh why, if in your theory, vmodem is fine, the biggest fido-over-IP > community switched (in a month or so) from Vmodem to Binkp last fall?! There is something here we have to clarify before we continue our discission; to spare other people's time and patience I've sent a netmail message to you. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #811 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 04:05:00 To : Yuri Teterin 21 Oct 97 07:23:52 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Who's requirements? Not the requirements of FIDO-policy, because it > require FIDO-node have phonenumber first of all. Can you quote a relevant section or direct me to it? > RJ> If it has got raw BinkP in addition, that's great. > What for? Have you _ever_ seen FTS-0001 session in your life? Yes, I did. And I'm pretty sure I'm not the only one... :) Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #812 [1995] Scn From : Rune Johansen 2:210/20 20 Oct 97 01:47:18 To : Lawrence Garvin 21 Oct 97 07:23:52 Subj : Flags in nodelist ------------------------------------------------------------------------------- > That is a potential issue, fer sure. And as I recall the discussion in TCPIP, > it was with respect to a -worldwide- resolution issue.... Well, it would be worldwide. > However, if'n one presumes that my BBS machine is only being used for Fidonet >and my BBS -- then there's no real harm in pointing my resolver at a DNS serve > inside the .FIDO zone and acting as if that's the only DNS zone in the whole > world. Ah, but that presumption would only be valid for a small fraction of all the machines that would use this system. > Also, I can actually list TWO resolvers in my configs, the .FIDO DNS server >first, and any other DNS server second. If the name fails in the .FIDO domain, > then the resolver will attempt to look it up at the DNS server identified in > the second line. Yes, this would be manageable, if you have a system that first of all can do their own DNS lookups (not blocked by a firewall and being forced to use a "internal" DNS server), and then can list several DNS servers. I think it would be more fuzz than gain in such a situation, even though it might be technically feasible. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #813 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 02:09:00 To : Slava Filimonov 21 Oct 97 07:23:52 Subj : IP-access ------------------------------------------------------------------------------- > old software. Use it. but not for ip. You still have abitiy to send > mail to ip-systems by snail fido way. Want use ip ? Then use new > software. isn't it simple or what? What if I want both? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #814 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 03:00:00 To : Marco d'Itri 21 Oct 97 07:23:52 Subj : IP-connectivity ------------------------------------------------------------------------------- >>I'm afraid that when we say "email" we have to think "SMTP" (not just, >>but also). > This is not always true and certainly not needed. SMTP is just a > transport, e.g. my email comes to me via uucp. I'm aware of that. But I'm afraid that in a process of reaching your system email addressed to you passes through some SMTP MTAs; in general, assuming that an email message will never be handled by an SMTP MTA is not a wise thing to do :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #815 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 03:13:00 To : Dieter Ringhofer 21 Oct 97 07:23:52 Subj : IP-connectivity ------------------------------------------------------------------------------- > See above: You used the shortcut GMT which is already obsolete according > several legal authorities since more than 20 years. Right. But nevertheless you undenstood what I meant, didn't you? > Do you see the problem with 'unspecific' times like being used at T-flag > definitions now? ;) Yes, I do. I'm aware of the problems since I first saw them when trying to set appropriate TZ on some strange un*x system. But if we just agree on listing all T flag values in relation to _one_ timezone (ie not depending on the local timezone for the system... :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #816 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 03:59:00 To : Marco d'Itri 21 Oct 97 07:23:52 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- > Do you want to be points ISDN nodes too? ISDN-_only_ nodes? Well, now that's a very sensitive/delicate issue... :) Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #817 [1995] Scn From : Lech Szychowski 2:480/33.7 20 Oct 97 02:44:00 To : Lawrence Garvin 21 Oct 97 07:23:52 Subj : IP-access ------------------------------------------------------------------------------- > Not at all, Lech. I just believe it's the responsibility of the > HOSTmaster of -whatever- DNS zone to maintain the MX records. In the > event somebody wants to use the default 'fidonet.org' zone, then > obviously somebody in that heirarchy will have to maintain MX records > for zone:net/node mapped DNS names. But then we have a very unefficient situation: a Z:N/F node capable of handling SMTP is not listed as the MX for *.fF.nN.zZ.fidonet.org - or we have to maintain two MX records instad of one. BTW: if there is an A record for an FQDN, there is no point in listing an MX record for this FQDN (unless we explicitely want to direct mail to some other place). Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #818 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 21 Oct 97 08:29:58 To : Pedro Lima Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Pedro! On 19 Oct 97 wrote Pedro Lima to Lothar Behet: PL> People are usually very attached to what they have, and they won't be PL> usually available to loose say the system name to convey an IP address PL> or a FQDN. Also, using the phone field for the IP address is PL> perfectly coherent with the purpose it now has. LB>> But then you loose the advantage of combined entries :(, which LB>> saves a lot of lines. On the other hand, still software with very LB>> limited aka-recognition is widely used. PL> These problems can only be effectively solved by a new nodelist PL> format. ... which will last some (a long?) time, until it generally used (even by those, who would use it). LB>> As long as the nodelist compiler knows which fields and flags to LB>> monitor, it can create even a combination of different lists LB>> according to the mailers specifications. PL> Ok, you have a versatile compiler. Fastlst does only a part of it, but some utilities do the rest at this moment. PL> Other's don't, but have software which is going to look for an IP PL> address in the phone field (although I admit the solution of the PL> special prefix somewhat disturbs this process). At this moment a special handling is required anyway (i.e. fastlst does no translation - to .). [... some stuff deleted ...] I think we are leaving the technical aspect of this area and should discuss this by netmail :) LB>> Here in R24 is a strong opposition against any ip-entries at all, LB>> but sometimes it is based on a misunderstanding of the tunneling LB>> technique. PL> I'd be interested to know some more about the grounds for this PL> opposition, if you can summarize it. Here it comes: 1. misunderstanding of tunneling ftn over ip (mainly fixed :) 2. some are generally against any ip-use 3. foreign messages (identified be typical gateway kludges) appearing in fido areas 4. connectivtiy issues between conventional and ip access, but on the other hand nobody wants to stop use ISDN (if he/she has it) 5. the known phone translation problems These are the main points discussed in regional areas. LB>> Then we should focuse on a compatible solution for short term, LB>> while we begin to work on a better and more complete format. PL> Yes, I fully agree. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #819 [1995] Rcv Scn From : Frank Ellermann 2:240/5815.1 14 Oct 97 14:02:00 To : Lothar Behet 21 Oct 97 20:38:44 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Lothar, LB> at least one seperate address for each IP# and protocol-combination :( ?!? Strange idea, most probably you completely misunderstood my message, compare my answer to Maciej (MsgID 2:240/5815.1@fidonet.org d56ce59b). Today the experimental nodes are listed and managed as 2:2/3xxx nodes. The next logical step could be, to create a region or test nets, where you're free to test new tools and other ideas than country code 000- It would be easy to integrate IP-nodes from other zones (e.g. Lawrence) in these dedicated nodelist segments. You stated it here: We can't have a "best" solution (probably requiring a new FTS-5 and new tools (?)) at once zonewide or even worldwide, and waiting for something to happen is no option. Small reversible steps, quick and dirty approaches like 000- and adjusting them as soon as something better is available. LB> Question: Is the internet as medium organized like a regional net? LB> Yes, it surely is, (mostly) located at earth.sun.our_galaxy ... What are you talking about ? Internet as geograhical area of convenient calling ? Replace "geographical" by "technical" and add "FTN", and it's okay for me... Back to FidoNet and communication, until now I see, what VM, BND, and IFC are about... but I still fail to understand IP and TELN, what have they to do with FTN-session over IP ? Maybe you're the wrong to ask, as you don't flag IP and TELN, but if you have some specifications, please don't hesitate to post it here or make it available as files... FTN file request of course please, not only FTP ;-) Bye, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #820 [1995] Scn From : Frank Ellermann 2:240/5815.1 14 Oct 97 13:29:00 To : maciej grzeszczuk 21 Oct 97 20:38:44 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hi Maciej, >>> IP only nodes may be listed only in a region (or nets) reserved >>> for this purpose. mg> what for? Nodelist management... the primary task of our *Cs. How should an average NC check all these new flags and capabilities, unless he has by accident IP access and the necessary software ? Maybe (probably ?) we'll come to the conclusion, that listing IP addresses with dummy country code 000- and dashes instead of dots is not the best solution, but anything else fails within the limits of MakeNL / NLMake / NLMaint. The next idea could be to try something like Marco's (or whoever invented it in R2:50) "extended nodelist format". In special nets or regions this could be easier than zonewide (or, see Lawrence's message, even worldwide). BTW, the "extended nodelist format" is IMHO _not_ compatible with the current format. And of course it won't work with MakeNL. Last but not least this technical problem also has its political side: What if an NC refuses to list IP nodes, because he's unable to verify it ? Greets, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #821 [1995] Scn From : Gisbert Rudolph 2:2443/2161 14 Oct 97 14:06:46 To : Denis McMahon 21 Oct 97 20:38:46 Subj : SMTP/FTP - QWK of the internet ------------------------------------------------------------------------------- Hello Denis, Sunday October 12 1997 23:29, Denis McMahon wrote to rafal wiosna: DM> IMHO this echo is about how we incorporate the IP addressing data in the DM> nodelist, not about which protocols and methods are valid or not. Can we DM> try and keep to the objective? It's about IP connectivity within FidoNet. Gisbert (gisbert@os2bbs.art-line.de) --- GoldED/386 3.00.Alpha5+ * Origin: Peaceful Corner, 42105 Wuppertal (2:2443/2161) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #822 [1995] Scn From : Marco d'Itri 2:335/680.666 21 Oct 97 20:02:06 To : Lech Szychowski 21 Oct 97 21:17:32 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: > >>FTP daemon will rename received files? > > I think so. >Sorry, but I don't. Then get the sources and verify that yourself. > > You can find the source for this modified wu-ftp on ftp.fido.de. >Ready to compile on what systems? Any system that can compile wu-ftpd. (=any unix system) >And a more fundamental question: is this still the standard FTP protocol? Yes. It moves files in the same way wu-ftpd does. >This is still true for systems using snail mail for sending human readable >requests (ie names of the files written on a sheet of paper) and digital >media (eg diskettes). But would you call this "networking" Fido? :) Why not? I know about some points that got their echomail on floppynet. email tunneling and FTP are not enough to get a node number, but those protocols should be allowed because they are useful and can save people's money. > > My protocol provides multiple ways to verify the sender of a message. >It's damn easy once you start using tools like PGP. Then any carrier >media will do. But is it still Fido? Yes. > > It will be the same exact protocol, just the daemon will be smarter and > > will correctly move in the inbound/outbound the arcmail. >Nope. I'm afraid it's perfectly valid for an FTP client to assume when >performing PUT operation that if a file of a given name already exists >it will be either overwritten (if permissions allow) or operation will >fail (if permissions do not allow it). If you modify this command behavior >the protocol is not FTP any more. If you use another command, the protocol This is silly. Please don't waste our time with such stupid arguments. The client does not even knows there is another file with the same name in the inbound and does not knows or cares if the server will rename it. > >>We certainly will need it. A lot of mailers enforce limits on the > >>size of a single message. > > In the modern internet? >Yes. For a very simple reason: it takes long to transfer a huge message. Only a few nodes does that, and the reason is that there are morons who likes sending huge attachments that will choke sendmail. Anyway, if you want to send small packets ask your ftn packer to create them small. > > [1] If I want to receive my echomail via flying pidgeons (RFC 1149) and > > my boss agree no one should force us to use another transport. >You're talking about point-to-boss traffic here, right? Than it's The same should apply to any other node. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #823 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 21 Oct 97 19:50:54 To : Lothar Behet 21 Oct 97 21:17:32 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: > MI> Why do you apply that only to ISDN-only nodes and not to other nodes > MI> that "serve no routing purposes"? >Because he can only be reached from a limited number of other nodes, exactly >only by those who use the same technique (ISDN) and protocol (i.e. X75 in >europe and v120 in america). Ok, when the *C will rule that ISDN-only nodes should not get a node number I will not argue anymore about that. >IP-nodes in the nodelist should be reachable at least at a specified >timeframe (CM prefered), otherwise they are useless in the nodelist, except >for buffered I agree. >(elsewhere!) email transfer without any acknowledgement about correct >receipt. You can tunnel arcmail in email and have receipts. > >> - generally additional costs for each user, as ip-access requires > >> additional charges to a service provider > MI> IP is cheaper for many users. You can't assumer that every user has a > MI> local toll BBS in his area. >Are we talking about fidonet and its members or about bbs-users, who are just >using the fidonet (or generally ftn) for routing? Please read: You can't assumer that every bbs has a local toll hub in his area. > >> - highly varying bandwidth (depends on general internet usage), > >> therefore required connect times (and costs) are not calculatable > MI> Nodes without 24h connectivity IMHO should only use email tunnelling > MI> because it has deterministic connection times. >Then you have no secure link in aspect of delivery and the time of it. You can have automated resending of lost packets. > MI> I agree, but this is a political decision. >It is a basic claim according to the fidonet policy and should also be >honored Yes: this is a political decision. I think IP_CONNECT is a technical area. >Otherwise any bbs-user has the right to claim a nodenumber, if any ip-user >would get one :( Not any IP user, a node number should be assigned to any permanently connected IP node. Non-24h nodes should be able to advertise in the nodelist their email tunnelling capabilities, because that can save other nodes money. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #824 [1995] Scn From : Marco d'Itri 2:335/680.666 21 Oct 97 20:25:08 To : Lech Szychowski 21 Oct 97 21:17:32 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: > > If this is your concern then you should use round robin DNS. >Which is not a standard feature, right? I can't remember RFC >saying anything about round-robin behavior of NSes being obligatory. Every modern BIND version supports round robin. I don't think other DNS software can be safely used in non-joke situations, and BIND is used by nearly all servers. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #825 [1995] Scn From : Marco d'Itri 2:335/680.666 21 Oct 97 20:05:04 To : Lech Szychowski 21 Oct 97 21:17:32 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: > > I agree, but *all* nodes (PSTN or IP) should be able to advertise in the > > nodelist email or ftp service. >sysop's email address can always be constructed as something like >postmaster@fF.nN.zZ.fidonet.org, right? Just make this FQDN's MX No. Non-24h nodes can't have their MX point to them. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #826 [1995] Scn From : Marco d'Itri 2:335/680.666 21 Oct 97 20:10:26 To : Chris Maddock 21 Oct 97 21:17:32 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Chris.Maddock@f302.n640.z3.fidonet.org wrote: >The standard may have to be changed anyway so we may need to implement a set >of standards to follow or insist that the old standards can be used if they >are already sufficient. I suspect they are already sufficient but have not >been followed. I agree. The only problem is with makenl, and this could be easily resolved by patching NLMake. Sadly I don't think we will ever agree on a common nodelist format, in R33 we will experiment with the generation of multiple nodelist formats (for binkd, BT, etc) from a master extended nodelist. I have nearly finished the software (some perl scripts), but looks like italian IP sysops are not interested about that, they didn't even sent me their nodelist entries. >Yes. I saw it a couple of days ago. Looked good. I am a little purturbed as >to the large number of flags though. I don't think we can avoid that. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #827 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 21 Oct 97 20:12:52 To : Lothar Behet 21 Oct 97 21:17:32 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: >Flag space may be saved if there would be a combined flag, which defines >IP-capabilities like this Example: I think this is too much twisted to implement. Also your proposal cannot cope with non standard port numbers. > Md>> Compilers should just accept a longer flag field and an FQDN in > Md>> the phone field. >Unlikely there are many different compilers working in the wild, which surely >have different capabilities and some may be quite special for a dedicated >software and operating system. So we should search on short term for a >solution with as less deviance from the known data (and amount), that is >possible. We will have to change the software anyway, why can't we do it right from the beginning? -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #828 [1995] Scn From : Marco d'Itri 2:335/680.666 21 Oct 97 20:21:14 To : Lawrence Garvin 21 Oct 97 21:17:32 Subj : Re: Flags in nodelist ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >However, if'n one presumes that my BBS machine is only being used for Fidonet >and my BBS -- then there's no real harm in pointing my resolver at a DNS >server I don't think this is a common situation. Most machines will be used for other services. >Also, I can actually list TWO resolvers in my configs, the .FIDO DNS server >first, and any other DNS server second. If the name fails in the .FIDO >domain, then the resolver will attempt to look it up at the DNS server >identified in the second line. Does not works this way. The second resolver is used only if the first one times out. >In such a case, I don't believe it would be necessary for the .FIDO root >servers to point to any Internic servers -- the obligation would fall back to >those Fido nodes to provide for resolving in both systems -IF- they needed to >actually resolve non-Fido DNS names from the Fido/BBS machine. Please, drop this idea. The whole concept of alternate root servers is evil and does not works (ask Paul Vixie for technical details :-) ). -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #829 [1995] Scn From : Marco d'Itri 2:335/680.666 21 Oct 97 20:22:00 To : Lech Szychowski 21 Oct 97 21:17:32 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: > > For ISDN you will get another node numeber, why you don't want one for IP? >And have to tell your mailer manually that X, Y and Z are all aliases >for the very same system, so it's a good idea to try all phone numbers >(or IP addresses in this case) when trying to connect to any of X, Y and Z? You have the same problem for PSTN multiline systems. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #830 [1995] Scn From : Marco d'Itri 2:335/680.666 21 Oct 97 20:04:00 To : Lech Szychowski 21 Oct 97 21:17:32 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: > > email-tunnelling is a cheap way for a PSTN node to send crashmail >Err... How can one combine "email" and "crash"? Hint: MX'es. Not all nodes can be on line 24h and have their MX point to them. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #831 [1995] Scn From : Marco d'Itri 2:335/680.666 21 Oct 97 20:27:10 To : Lech Szychowski 21 Oct 97 21:17:32 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >True round-robin DNS server is a complicated thing to design and buid. >I/m not even sure if it's possible - this server would have to keep >separate RR queue pointers for each requesting system and each type of >record that it ever received a request for. Add things like hosts with >multiple IP addresses and you are in deep sh*t. You never used BIND, didn't you? :-) This is all you need to configure to have a round robin domain: domain IN A 1.2.3.4 A 1.2.3.5 A 1.2.3.6 Done. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #832 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 21 Oct 97 21:58:06 To : Marco d'Itri Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Marco! On 21 Oct 97 wrote Marco d'Itri to Lothar Behet: >> (elsewhere!) email transfer without any acknowledgement about >> correct receipt. MI> You can tunnel arcmail in email and have receipts. Which programs or special (overlaid) protocols do support this and packet verification? MI> Please read: You can't assumer that every bbs has a local toll hub in MI> his area. That is the price to pay for a hobby :) But are you sure, that they have internet access in that area? >> MI> I agree, but this is a political decision. >> It is a basic claim according to the fidonet policy and should also >> be honored MI> Yes: this is a political decision. I think IP_CONNECT is a technical MI> area. It is part of the discussion about listing of ip-nodes. MI> Not any IP user, a node number should be assigned to any permanently MI> connected IP node. Here we are in conformity. MI> Non-24h nodes should be able to advertise in the nodelist their email MI> tunnelling capabilities, because that can save other nodes money. As long as i do not know of a "secure" email based protocol i cannot agree to this. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #833 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 21 Oct 97 22:02:56 To : Marco d'Itri Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hallo Marco! Am 21 Oct 97 schrieb Marco d'Itri an Lothar Behet: >> Flag space may be saved if there would be a combined flag, which >> defines IP-capabilities like this Example: MI> I think this is too much twisted to implement. Also your proposal MI> cannot cope with non standard port numbers. I know :), but it was just a hint about saving space in the flag field. BTW, will many nodes use non-standard ports? >> Md>> Compilers should just accept a longer flag field and an FQDN >> Md>> in the phone field. >> Unlikely there are many different compilers working in the wild, >> which surely have different capabilities and some may be quite >> special for a dedicated software and operating system. So we should >> search on short term for a solution with as less deviance from the >> known data (and amount), that is possible. MI> We will have to change the software anyway, why can't we do it right MI> from the beginning? Because it will last a long time. So an intermediate "patch" to the existing nodelist would be practical to those, who can and wish to use ip tunneling now and in the meantime the extended format can be prepared completely. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #834 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 21 Oct 97 22:15:30 To : Frank Ellermann Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Frank! On 14 Oct 97 wrote Frank Ellermann to Lothar Behet: LB>> at least one seperate address for each IP# and protocol-combination LB>> :( FE> ?!? Strange idea, Sure, it was the most unwanted extreme situation :) FE> Today the experimental nodes are listed and managed as 2:2/3xxx FE> nodes. FE> The next logical step could be, to create a region or test nets, where FE> you're free to test new tools and other ideas than country code 000- IMHO ip-nodes should be integrated in the nodelist, as they operate their system according to the fidonet policy. LB>> Question: Is the internet as medium organized like a regional net? LB>> Yes, it surely is, (mostly) located at earth.sun.our_galaxy ... FE> What are you talking about ? Internet as geograhical area of FE> convenient calling ? Yes, something about that :) FE> Back to FidoNet and communication, until now I see, what VM, BND, and FE> IFC are about... but I still fail to understand IP and TELN, what have FE> they to do with FTN-session over IP ? Telnet can not handle interactive access, but also session handshaking. If you rember my test report, i did not mention 2:2/3005 as untested, because i could sent a mail via Vmodem's telnet. Raw IP may handle any session layer, if both sides use the same (protocol). FE> Maybe you're the wrong to ask, as you don't flag IP and TELN, but if FE> you have some specifications, please don't hesitate to post it here FE> or make it available as files... FE> FTN file request of course please, not only FTP ;-) Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #835 [1995] Scn From : Dimitar Ganchev 2:350/14 20 Oct 97 20:52:00 To : Lech Szychowski 22 Oct 97 06:55:28 Subj : A bit of steering ... ------------------------------------------------------------------------------- Reply-To: dimitar.ganchev@mail.bol.bg > As far as i read until now, the administration of subdomains for > z2.fidonet.org is handled very restrictively and at this moment it is > primarily intended for gateway administration. LS> I think it's an excessive restriction. If an IP system is to LS> be used as a hub or echomail feed, it should IMHO be LS> considered a good candidate to be listed. I don't think the administration is restricted in any way. I've registered MX records for some systems and A records for all my AKAs within few hours. Anyone can use this FQDNs to connect to my system (ifmail at ports 23, 60177 and 60179): f3.n35.z2.fidonet.org f1.n350.z2.fidonet.org f12.n350.z2.fidonet.org However, I think it's a good idea if n* zones are delegated to a system, approved by the respective *C. Regards, .\\itko --- FMail 1.22 * Origin: The home of .\\itko (2:350/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #836 [1995] Scn From : Lech Szychowski 2:480/33.7 21 Oct 97 09:10:00 To : Dimitar Ganchev 22 Oct 97 06:55:28 Subj : A bit of steering ... ------------------------------------------------------------------------------- > I don't think the administration is restricted in any way. IMHO it is restrictive. > I've registered MX records for some systems and A records for all > my AKAs within few hours. And it took us _weeks_ to register our regional gateway. > However, I think it's a good idea if n* zones are delegated to a system, > approved by the respective *C. Exactly my point. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #837 [1995] Scn From : Slava Filimonov 2:469/33 20 Oct 97 16:49:28 To : Marco d'Itri 22 Oct 97 06:55:30 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Marco! 18 Oct 97 00:44, Marco d'Itri wrote to Lothar Behet: >> - highly varying bandwidth (depends on general internet usage), >> therefore required connect times (and costs) are not calculatable MI> Nodes without 24h connectivity IMHO should only use email tunnelling MI> because it has deterministic connection times. They can get their mail from fallback ip node - it maybe a /0 for node and /xx.0 for ip-point ;) in case we're using DNS for fidonet over ip. E-Mail tunneling is not a good at all. We should use simple services/protocols where it's possible. For FIDO we don't want to complicate simple fts packet/files transfer, aren't we ? TO ALL: I just love way of your thoughts. By increasing compatibility with old stuff/adding "old-fashion" features we increasing sofistication/complication of simple thing - fido mail packet/file echange over IP up to nonsense!!! It's like buying Windows for Internet communication, then upgrading your computer, coz windoze won't run fast enough your explorer. (Or explorer won't run fast in windoze) instead of installing linux for free and using Netscape under X. Just open your eyes on fidonet technology - everything from emsi to z-modem/hydra designed for transmission over unreliable media. But here, tcp/ip cares about it! At least everyone, who runs fido-over inet has e-mail box. So, you'll be able to contact every node/point by e-mail if they have one. In few words - lets use diesel power on highway and horse power on mountain road. And do not ride with a horse on highway. -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #838 [1995] Scn From : Lech Szychowski 2:480/33.7 21 Oct 97 09:15:00 To : Dimitar Ganchev 22 Oct 97 06:55:30 Subj : IP-access ------------------------------------------------------------------------------- > That's why f12.n35.z2.fidonet.org has both A and MX records with > different IP addresses. And that's the way it should be. All I wanted to say is there might be some point in saying that if a node gets an A record it should also be capable of accepting incoming mail via SMTP - and that technically it's not necessary, because we can add an MX record pinting to some other system. As a matter of fact, we'd most likely have to add an MX record anyway, to indicate that this system is a mail gateway for its points. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #839 [1995] Rcv Scn From : Yuri Teterin 2:5030/239 20 Oct 97 20:18:08 To : Lothar Behet 22 Oct 97 06:55:30 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lothar ! Sat Oct 18 1997 Lothar Behet writes to Yuri Teterin: LB> H. Physical Layer : the Actual Connection of Two FidoNet Systems LB> Will one of the more hardware-oriented comm types give me some idea LB> of what's needed here? Can we leave it open enough to LB> allow implementation over a non-dial net? Thanks. >> -8------------------------ byte here ------------------------8-< LB> As ip is just a special case of a non-dial net, i see no reason to treat LB> ip-nodes in another way than any normal node, as soon as their integration LB> in the nodelist is defined. 'To allow implementation over a non-dial net' means that such implementation is _possible_. But if you want _reqire_ FTS-0001 capability for the purpuse of compatibility, it shold be also _unique_. In the case of IP this is not true, because FTN-system has _no_ real access to 'physical layer' of IP. If you insist on implementation of FTS-0001 over IP, you sould implement it not over TCP but over UDP, which much more close to 'physical layer' than TCP is. So, are your ready to require support of FTN-0001 over UDP from any IP-node? (There is _no_ such implementations now, but if we try to follow Policy and FTS as strictly as possible, this if most logical sollution, isn't it?). Or do you suggest to require the implementation of FTS-0001 over _some_ protocol, including protocols without exact specifications, like vmodem or telnet-chanel? (telnet-chanel require some additional parameter settings to be ready for FTN-session, and this part is now unspecificated). Then, as I have writen before, you will nave no possibility to check that a node is realy FTS-0001 capable, because you will have no software for this. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #840 [1995] Scn From : Yuri Teterin 2:5030/239 20 Oct 97 20:49:36 To : Rune Johansen 22 Oct 97 06:55:30 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Sat Oct 18 1997 Rune Johansen writes to Yuri Teterin: >> FIDO-Policy describes the a net of phone-based stations. And the demand >> of FTS-0001 capability referes to node's phoneline only. RJ> No, the demand of FTS-0001 refers to being eligible for being a node. From RJ> my copy of policy4: The is so many referenses to phones and phonelines in Policy that it is clear for everybody that _all_ of its statement concerning calls and connections suppose that the nodes use some common space of phonelines with common space of phonenumbers. If we omit this supposition then a lot of sentences in Policy will became just a nonsence. >> Further, FTS-0001 describes a session based immediately on a _physical_ >> layer protocol. RJ> No. It's an open question in FTS-0001 wether the Physical layer should be RJ> so open to include non-dialable (by phone systems) nets. Exactly. So, this part of the standard is _open_ just because it was not _elaborated_. Not any protocol can be used as the base of FTS-0001 - nethertheless you insist on FTS-0001 capability as if this part of standard is clear and the implementation is unique. But this is not true - see my previous letter. >> All the protocols you have mentioned (telnet, vmodem, ifcico's 'raw >> TCP') are not physical layer protocols and demand some software support, >> so FTS-0001 is not direcly applicable to them. RJ> The analogy between a IP layer and protocols on top of them (in the TCP RJ> level) and a serial port is in my views equal. The _analogy_ only. There in nether standard implementation of this analogy nor full specifications for them. So how can you _require_ something at that pure basis? >> Who's requirements? Not the requirements of FIDO-policy, because it >> require FIDO-node have phonenumber first of all. RJ> Not necessarily, as private nodes can be used, if they are to the good of RJ> Fidonet. That is to judged by *C's. The nodes that do not accept inbound connections (PVT-nodes in your case) are not considered here - there is no problems of compatibility for them in any case. >> So from the point of view of your beloved FTS-0001 telnet and 'raw >> TCP' are also just the same. RJ> See message from Kim Heino about this in this echo. Yes, telnet session must at least double IAC characters in the streem. So, this only confirm my previos statement: there is no unique and standard method to turn telnet chanel into a chanel supposed by FTS-0001. Hence the statement "the system is ready to receive mail using FTS-0001 via telnet" is sinseless as yet: for some implementations of such telnet-to-'physical_layer' conversion it will be ready, for other - it will not. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #841 [1995] Scn From : Yuri Teterin 2:5030/239 20 Oct 97 22:37:48 To : Rune Johansen 22 Oct 97 06:55:30 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Sat Oct 18 1997 Rune Johansen writes to Yuri Teterin: RJ> If you are a IP-only node, you would have to offer FTS-0001 sessions via RJ> the protocol you have specified in the nodelist entry. Very well. So if I specify binkp as my IP-protocol, I must be able only to run _incoming_ FTN-0001 sessions _via_binkp_? That is, binkp-chanel should be turned first into 'physycal layer chanel' required by FTS-0001, and the method of such conversion can be arbitrary? But because there is no software that is able to make _outgoing_ FTS-0001 session _via_binkp_, nobody will be able sometimes check, am I realy able to do this or not, isn't it? And what sense has then your reqiurement in this case? RJ> You really want to be difficult, don't you? Not at all. I just want to understand, that is the difference between FTS-0001 session via closed protocol vmodem, which can be make only with help of a commercial program SIO, and FTS-0001 session via any other closed protocol, which will be available, for instance, only with help of some other commercial progam what costs $99999999 (or is not available at all). RJ> I have been talking about IP-only nodes. If your node runs BinkP RJ> protocol, I should be able to connect to you via BinkP protocol, and RJ> do a FTS-0001 handshake (and optional file/mail transfers) with you. Over binkp chanel as 'physical layer', isn't it? So you should have the same implementation of binkp->'physical layer' convertor that I have. And I am not obliged to supply you with such a converter (and have no moral duty to make this because running FTS-0001 session over binkp is absolutely senseless: if you have such converter you will be able to make handshake and file/mail transfer allready at this 'low level', without FTS-0001 overhead). So how can you check am I ready do make FTS-0001 session over binkp or not? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #842 [1995] Scn From : Dimitar Ganchev 2:350/14 20 Oct 97 21:05:00 To : Lech Szychowski 22 Oct 97 06:55:30 Subj : IP-access ------------------------------------------------------------------------------- Reply-To: dimitar.ganchev@mail.bol.bg LS> But then we have a very unefficient situation: a Z:N/F node LS> capable of handling SMTP is not listed as the MX for LS> *.fF.nN.zZ.fidonet.org - or we have to maintain two MX LS> records instad of one. LS> BTW: if there is an A record for an FQDN, there is no point LS> in listing an MX record for this FQDN (unless we explicitely LS> want to direct mail to some other place). I run my system on a multihomed system with 3 different routes (lines) to Internet. I use one of them for interactive communications (the faster one) and another one for non-interactive ones (email). That's why f12.n35.z2.fidonet.org has both A and MX records with different IP addresses. Regards, .\\itko --- FMail 1.22 * Origin: The home of .\\itko (2:350/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #843 [1995] Rcv Scn From : Dima Maloff 2:5047/13 19 Oct 97 23:02:00 To : Lothar Behet 22 Oct 97 06:55:30 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Saturday October 18 1997 09:00, Lothar Behet wrote to Yuri Teterin: LB> As ip is just a special case of a non-dial net, i see no reason to treat LB> ip-nodes in another way than any normal node, as soon as their integration LB> in the nodelist is defined. Listen, FTS-1 has sense when you need to multiplex a phone number in the nodelist between mailers and human callers. And it has sense as we want all regular mailers to be compatible. But in fido-over-IP world there ARE more nodes with binkp already than, may be, with all other protocols altogether. So introducing FTS-1 as a "standard" you'll BREAK the connectivity. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #844 [1995] Scn From : Yuri Teterin 2:5030/239 20 Oct 97 20:12:40 To : Lawrence Garvin 22 Oct 97 06:55:30 Subj : FYI - FWIW ------------------------------------------------------------------------------- Hello, Lawrence ! Fri Oct 17 1997 Lawrence Garvin writes to All: LG> Zorch Frezberg successfully polled my Vmodem port 23 Bink XE last LG> Wednesday afternoon with an Argus on Win95 mailer. LG> Mebbe there's more compatibility than we thought? Argus supports FTN-over-telnet sessions, as well as binkp and ifcico's 'raw TCP'. This is well known and was already mentioned here. There was an attempt to implement VMP in Argus too, but it was not quite successful. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #845 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 22 Oct 97 07:47:04 To : Dima Maloff Subj : FTS-0001 and IP ------------------------------------------------------------------------------- Hello Dima! On 19 Oct 97 wrote Dima Maloff to Lothar Behet: DM> But in fido-over-IP world there ARE more nodes with binkp already DM> than, may be, with all other protocols altogether. So introducing DM> FTS-1 as a "standard" you'll BREAK the connectivity. Read several other of my messages and especially the last ones between Yuri and me. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #846 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 22 Oct 97 07:57:58 To : Yuri Teterin Subj : FTS-0001 and IP ------------------------------------------------------------------------------- Hello Yuri! On 20 Oct 97 wrote Yuri Teterin to Lothar Behet: LB>> H. Physical Layer : the Actual Connection of Two FidoNet Systems LB>> Will one of the more hardware-oriented comm types give me LB>> some idea of what's needed here? Can we leave it open enough to LB>> allow implementation over a non-dial net? Thanks. >>> -8----------------------+- byte here ------------------------8-< LB>> As ip is just a special case of a non-dial net, i see no reason LB>> to treat ip-nodes in another way than any normal node, as soon as LB>> their integration in the nodelist is defined. YT> 'To allow implementation over a non-dial net' means that such YT> implementation is _possible_. It was your original statement, that FTS-0001 just strikes conventional (pstn) nodes. Therefore i posted this excerpt from FTS-0001. As mentioned in all my messages, i support any protocol for ftn-over-ip, that performs a direct handshake between two mailers (including binkp) _equivalent_ to conventional mode and uses nodelist data for authentication. This does not mean, that it only has to a real FTS-0001 session, as most conventional sessions are EMSI and even some newer programs do not include FTS-0001 sessions. The main point is the direct handshake between mailers, based on the nodelist entries. Not more, not less. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #847 [1995] Scn From : Marco d'Itri 2:335/680.666 22 Oct 97 15:33:32 To : Frank Ellermann 22 Oct 97 21:57:36 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Frank.Ellermann@p1.f5815.n240.z2.fidonet.org wrote: >BTW, the "extended nodelist format" is IMHO _not_ compatible with >the current format. And of course it won't work with MakeNL. The only part that will break older software is the longer flags field. I suppose extended format-aware compilers will not have any problem with that. If you have other concerns please move to NET_DEV (or email). >Last but not least this technical problem also has its political >side: What if an NC refuses to list IP nodes, because he's unable >to verify it ? I think the NC should appoint someone who can verify IP nodes. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #848 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 22 Oct 97 15:26:44 To : Lothar Behet 22 Oct 97 21:57:36 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: > MI> You can tunnel arcmail in email and have receipts. >Which programs or special (overlaid) protocols do support this and packet >verification? The program I'm writing. When I will have enough Free Time I will post to NET_DEV the description of the protocol for public review. TransX does some of that, but my protocol is much better. > MI> Please read: You can't assumer that every bbs has a local toll hub in > MI> his area. >But are you sure, that they have internet access in that area? At least in my country, yes. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #849 [1995] Scn From : Marco d'Itri 2:335/680.666 22 Oct 97 15:31:00 To : Frank Ellermann 22 Oct 97 21:57:36 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Frank.Ellermann@p1.f5815.n240.z2.fidonet.org wrote: >Back to FidoNet and communication, until now I see, what VM, BND, and >IFC are about... but I still fail to understand IP and TELN, what have >they to do with FTN-session over IP ? Maybe you're the wrong to ask, IFC is TELN with an optional optimized communication protocol. IP is needed to have a simple way to recognize IP nodes. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #850 [1995] Scn From : Marco d'Itri 2:335/680.666 22 Oct 97 15:28:38 To : Slava Filimonov 22 Oct 97 21:57:36 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Slava.Filimonov@f33.n469.z2.fidonet.org wrote: > MI> Nodes without 24h connectivity IMHO should only use email tunnelling > MI> because it has deterministic connection times. >They can get their mail from fallback ip node - it maybe a /0 for node and >/xx.0 for ip-point ;) in case we're using DNS for fidonet over ip. E-Mail Please explain that better. >tunneling is not a good at all. We should use simple services/protocols where >it's possible. For FIDO we don't want to complicate simple fts packet/files >transfer, aren't we ? If doing that saves me money, I want. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #851 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 22 Oct 97 15:34:56 To : Lothar Behet 22 Oct 97 21:57:36 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: >BTW, will many nodes use non-standard ports? Most unix nodes will. Port 23 is already used by the telnet daemon. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #852 [1995] Scn From : Dieter Ringhofer 2:2476/14 22 Oct 97 19:44:54 To : Yuri Teterin 22 Oct 97 22:31:36 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- YT> Very well. So if I specify binkp as my IP-protocol, I must be able YT> only to run _incoming_ FTN-0001 sessions _via_binkp_? That is, YT> binkp-chanel should be turned first into 'physycal layer chanel' required YT> by FTS-0001, and the method of such conversion can be arbitrary? But YT> because there is no software that is able to make _outgoing_ YT> FTS-0001 session _via_binkp_, nobody will be able sometimes check, am I YT> realy able to do this or not, isn't it? And what sense has then your YT> reqiurement in this case? Did you ever try to assign an IP-capable port to a software like Fido or do you talk without previous tests? Which software did you test and which one is NOT compliant to FTS-0001? You write about 200+ systems and their free software but, there're several thousands with already PAID software. Do you want to force some thousand people to throw their 'money' away?? What about trying to find a solution fitting both needs? binkP/D is free and available in source. Why shouldn't there be an extension according FTS? btw I'm using several paid licences of different operating systems (doesn't include Linux but Unix). I'm also running SIO (registered) and it's VModem port allows to use existing software further on without the need of setting up something else. And: My time is my money as well, some spare time is good for my health... --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #853 [1995] Scn From : Dieter Ringhofer 2:2476/14 22 Oct 97 19:26:28 To : Slava Filimonov 22 Oct 97 22:31:36 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- SF> installing linux for free and using Netscape under X. Just open your eyes SF> on fidonet technology - everything from emsi to z-modem/hydra designed for SF> transmission over unreliable media. But here, tcp/ip cares about it! Since when?? WHICH tcp/ip???? No common places, please. Call the child with it's name. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #854 [1995] Rcv Scn From : Dieter Ringhofer 2:2476/14 22 Oct 97 19:20:18 To : Lothar Behet 22 Oct 97 22:31:36 Subj : A bit of steering ... ------------------------------------------------------------------------------- Lothar Behet to Pedro Lima: PL>> I'd be interested to know some more about the grounds for this PL>> opposition, if you can summarize it. LB> Here it comes: LB> 1. misunderstanding of tunneling ftn over ip (mainly fixed :) signed LB> 2. some are generally against any ip-use signed LB> 3. foreign messages (identified be typical gateway kludges) appearing LB> in fido areas signed LB> 4. connectivtiy issues between conventional and ip access, but LB> on the other hand nobody wants to stop use ISDN (if he/she has it) not signed. ;) LB> 5. the known phone translation problems signed. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #855 [1995] Scn From : Dieter Ringhofer 2:2476/14 22 Oct 97 19:17:36 To : Lech Szychowski 22 Oct 97 22:31:36 Subj : IP-connectivity ------------------------------------------------------------------------------- >> See above: You used the shortcut GMT which is already obsolete according >> several legal authorities since more than 20 years. LS> Right. But nevertheless you undenstood what I meant, didn't you? I'm not to old to remember something at some times ;) Does it mean that every software being developed according valid law is wrong when it ignores something like this? >> Do you see the problem with 'unspecific' times like being used at T-flag >> definitions now? ;) LS> Yes, I do. I'm aware of the problems since I first saw them when LS> trying to set appropriate TZ on some strange un*x system. Don't ask how I did the trick with a commercial Unix over here... LS> But if we just agree on listing all T flag values in relation LS> to _one_ timezone (ie not depending on the local timezone for LS> the system... :) I don't see any need for it. I'm NOT in favour of T-flags as well as listed IP-only nodes not being connectable (I even don't want to see an ISDN-only node) especially for the 'little' problem with different implementations. There's also another point of view which I don't want to be ignored. Wether one wants to be a member of a network where almost any member is capable to connect almost any other one DIRECTLY (nonrouted!) or he might be point, user, . We do have some rules to become a member of Fidonet and: Wether we apply or we are no members. Participation is another task, it doesn't need a nodelist entry ;) Remember: I DO know about possible advantages for a user and (in more seldom circumstances) for a node when using IP for tunneling or the like. Therefore I would like to see technical extensions to make usage of this medium easier. It does NOT mean that I want to see Internet's 10hrs-free-twits in Fido's nodelist or that I want do loose chance of a direct (!) connect. Last issue also relates to encrypted mails and routing them outside of Internet (file routing included) for having NO privacy in Internet. Using Fido's technology the way it's thought to be used you don't need any encryption under normal circumstances (except against your secret service )... --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #856 [1995] Scn From : Yuri Teterin 2:5030/239 21 Oct 97 18:04:58 To : Lech Szychowski 22 Oct 97 22:32:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lech ! Mon Oct 20 1997 Lech Szychowski writes to Rune Johansen: LS> If I'm not completely wrong, BinkP is not a "transport layer" protocol, LS> it's a "session layer" one - so it's used instead of FTS-0001. You are quite right. It is theoretically possible to invite a "transport layer" protocol at the base of binkp, and even to run FTS-0001 session over this protocol, but this will be quite ineffective and absolutely senseless, because the same functionality (and much more) is already implemented at binkp level. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #857 [1995] Scn From : Lawrence Garvin 1:106/6018 21 Oct 97 22:49:48 To : Rune Johansen 22 Oct 97 22:32:56 Subj : A bit of steering ... ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: > It would seem that those two options are the only ones acceptable to > current technical capabilites and requirements of policy. Although > even the PVT nodelist may see an uphill battle in some areas. RJ> I think that a Pvt-debate would be easier for people to give in to, RJ> rather than a "you all need a new nodelist compiler, to adopt to RJ> our outrageous attempts to include IP-only nodes in the nodelist". RJ> With nodelist compiler, I am thinking of MakeNL. Oh, Definitely!!! :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #858 [1995] Scn From : Yuri Teterin 2:5030/239 21 Oct 97 17:52:48 To : Lech Szychowski 22 Oct 97 22:32:56 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hello, Lech ! Mon Oct 20 1997 Lech Szychowski writes to Yuri Teterin: >> It does, but for TCP-connection only ;-) (because getty or its >> clones, which listen usually at modem COM-port, can not recognize >> FTS-0001 session and so are not able to call ifcico itself). LS> So is it ifcico's itself or "ifcico behind getty" team's fault? :) This is not a fault at all. This just mean that almost all nodes using ifcico at their phonelines are not FTS-0001 capable. BTW, I know even hosts of large nets that are not FTS-0001 capable - and nobody worry about that. So FTS-0001 is just a tradition and not a working standard now. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #859 [1995] Scn From : Nick Soveiko 2:5030/23.101 21 Oct 97 08:44:02 To : Frank Ellermann 22 Oct 97 22:32:56 Subj : was: A bit of steering ... ------------------------------------------------------------------------------- Sat, 18 Oct 1997, 01:21, Frank Ellermann (2:240/5815.1) ==> Marco d'Itri: MdI> The "ISKRA" type is not known by the writer of this Mdl> document [...] FE> ... never heard of this one before, better omit it then ? iskra is a semiprivate telephone network in x-ussr countries. it's popular among the sysops because they have a flat rate long distance plan that for huge traffic works out cheaper than metered long distance with pstn. iskra phone numbers can not be listed now as in many cities this network usually has no gateways to pstn. cheers, nick ps. afaiu, credit for the 'extended nodelist format' idea should be given to alex konshin, 2:5030/217. --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #860 [1995] Scn From : Denis McMahon 2:251/20 21 Oct 97 18:28:48 To : Lech Szychowski 22 Oct 97 22:32:56 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Lech Szychowski wrote to Denis McMahon: > So, as I said, for FTP, accept anonymous upload of *.pkt and arcmail > files, just like happens during a session today. LS> Name clashes? Something the recipient has to handle, not part of the transport protocol! Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #861 [1995] Scn From : Lawrence Garvin 1:106/6018 21 Oct 97 22:51:14 To : Rune Johansen 22 Oct 97 22:32:56 Subj : Flags in nodelist ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: > Also, I can actually list TWO resolvers in my configs, the .FIDO DNS > server first, and any other DNS server second. If the name fails in > the .FIDO domain, then the resolver will attempt to look it up at the > DNS server identified in the second line. RJ> Yes, this would be manageable, if you have a system that first of RJ> all can do their own DNS lookups (not blocked by a firewall and RJ> being forced to use a "internal" DNS server), There does come a point where one has to make certain 'presumptions' in order to use the technology. Thiking about the liklihood that some company would be amenable to somebody trying to run an IP-Fidonet Node behind a corporate firewall seems a bit dichotomous to me. If the organization is concerned enough to put up a firewall, I don't expect the Network Administrators to take to kindly to wide-open Fidonet nodes sitting behind 'em. If'n I was in such a circumstance (and may be very soon at 106/6355), I'd tell 'em to put the Fido/IP node -outside- the firewall. RJ> and then can list several DNS servers. I think it would be more RJ> fuzz than gain in such a situation, even though it might be RJ> technically feasible. It wouldn't require 'several' DNS servers. For one, I don't know of any resolvers that will support more than three nameserver listings in resolv.conf anyway. For two, I expect the liklihood that the NODE itself would need DNS resolution in both systems to be a minority of the nodes involved -- unless they're running a true sendmail (or other MTA) on the same box. But even then, it's no big deal to add a second nameserver line to the resolv.conf file and press on -- heck, that particular sysop could even choose which domain to search first simply by the order of nameserver lines in the resolv.conf -- so no, I don't really think it's that significant of an issue. The significant part is finding two people willing to commit the time and energy to make sure the root servers (note plural, at least two) are up and running 24x7. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #862 [1995] Scn From : Nick Soveiko 2:5030/23.101 20 Oct 97 17:53:46 To : Rune Johansen 22 Oct 97 22:32:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sat, 18 Oct 1997, 02:12, Rune Johansen (2:210/20) ==> Yuri Teterin: > O, yes. If you'll be so stupid (or geneous) that will make your own > implementation of this idea (just to check me) - it shurely will be > incompatible with my Great Commercial Mailer, because your > interpretation of > 'physical layer' in FTS-0001 will differs from my one ;-). And > specifications > of my 'law layer protocol' are not free also (just like VMP is). > What can your say in this case? RJ> (leaning back, lighting up a cigarrette, puffing a little on it, RJ> leaning back to the keyboard) RJ> You really want to be difficult, don't you? I have been talking RJ> about IP-only nodes. If your node runs BinkP protocol, I should be RJ> able to connect to you via BinkP protocol, and do a FTS-0001 RJ> handshake (and optional file/mail transfers) with you. You list the RJ> IP layer as the only "physical layer" available, so you have to do RJ> it on that. If you have listed a phone number too, there will be no RJ> problem, as you are then NOT a IP-only node. well, the imaginary situation above is just an example of absurdity we can end up with if we adhere to the *letter* of policy. and the letter was written well ago... cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #863 [1995] Rcv Scn From : Nick Soveiko 2:5030/23.101 20 Oct 97 18:00:18 To : Lothar Behet 22 Oct 97 22:32:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sat, 18 Oct 1997, 09:00, Lothar Behet (2:2446/301) ==> Yuri Teterin: YT> FIDO-Policy describes the a net of phone-based stations. And the YT> demand of FTS-0001 capability referes to node's phoneline only. LB> I don't know which FTS-0001 you are referencing, but mine LB> (FTS-0001.015, Aug. 30th 1990, part of Fidonet Technical Standard) LB> just states one thing about physical connection: >-8------------------------ byte here ------------------------8-< LB> H. Physical Layer : the Actual Connection of Two FidoNet Systems LB> Will one of the more hardware-oriented comm types give me some LB> idea of what's needed here? Can we leave it open enough to LB> allow implementation over a non-dial net? Thanks. >-8------------------------ byte here ------------------------8-< LB> As ip is just a special case of a non-dial net, i see no reason to LB> treat ip-nodes in another way than any normal node, as soon as LB> their integration in the nodelist is defined. ip is *not* just a physical layer. ip is a network layer protocol (that is, in iso/osi reference model terms - 3rd layer). examples of physical layer protocols are: v.32bis, v.34. even v.42 is already data-link (second) layer. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #864 [1995] Scn From : Yuri Teterin 2:5030/239 21 Oct 97 17:08:48 To : Lech Szychowski 22 Oct 97 22:32:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lech ! Mon Oct 20 1997 Lech Szychowski writes to Yuri Teterin: >> Who's requirements? Not the requirements of FIDO-policy, because it >> require FIDO-node have phonenumber first of all. LS> Can you quote a relevant section or direct me to it? "2.2 How to obtain a node number [...........] Once you have located the network or region in your area, send a message containing a request for a node number to node zero of that network or region. The request must be sent by netmail, as this indicates that your system has FidoNet capability. [...........] The message you send must include at least the following information: 1) Your name. 2) Your voice telephone number 3) The name of your system. 4) The city and state where your system is located. > 5) The phone number to be used when calling your system. 6) Your hours of operation, netmail and BBS. 7) The maximum baud rate you can support. > 8) The type of mailer software and modem you are using." So according to Policy you should have 'phone number to be used when calling your system' with modem at it. And somewhat later, in section 2.3, it is explicitly supposed that you use phone for incoming calls, for example: "... the only thing which should ever answer the _telephone_ during periods when the nodelist indicates that your node will accept mail is FidoNet-compatible software which accepts mail." Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #865 [1995] Scn From : Yuri Teterin 2:5030/239 21 Oct 97 17:38:50 To : Lech Szychowski 22 Oct 97 22:32:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lech ! Mon Oct 20 1997 Lech Szychowski writes to Yuri Teterin: >> Have you _ever_ seen FTS-0001 session in your life? LS> Yes, I did. And I'm pretty sure I'm not the only one... :) I'm happy for you ;-) BTW, do you know, that FTS-0001 is a great hole in security of your system? And this hole is known for years, and even described in FTS-0001.015 itself: "...... Due to the lack of security in the pickup protocol (danger of pickup by a fake node), a change in the protocol may be expected in the near future." This was written years ago (before 1989) - so we can wait for this "near future" forever (last changes in FTS-0001 were made in 1990). So, if you are lucky to see FTS-0001 sessions often - this can just mean that some fake node steal mail from your system ;-))))) Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #866 [1995] Rcv Scn From : Yuri Teterin 2:5030/239 21 Oct 97 16:19:44 To : Lothar Behet 22 Oct 97 22:32:56 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hello, Lothar ! Mon Oct 20 1997 Lothar Behet writes to Chris Maddock: LB> IPC advises the nodelistcompiler to use the node_name as valid ip address LB> and gives information (in deciaml or hexadecimal form) about capabilities LB> according to a key table: LB> 1 Telnet LB> 2 Vmodem LB> 4 Ifcico LB> 8 BinkP LB> 16 FTP LB> 32 ... to be continued ... And how can you indicate the port for each connection in this case? At least for telnet it varries very much from node to node. LB> This table may contain up to 32 different protocols, which would consume 4 LB> (hex) to 5 (decimal) bytes of flag space. 64 possiblities would need 8 LB> byte in hex-notation. And if we will use radix 32 with 'digits' 0,...,9,A,...,Z, we will be able to make this field even shorter ;-) LB> The only disadvantage for human readers is the bitwise translation to a LB> dedicated protocol. There will be disadvantages for programs too, because with flags like VMP or BNP we are able to get list of nodes, available for our system, just with help of grep or something of this kind - and for your format we must definitely have some special program for this pupuse. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #867 [1995] Rcv Scn From : Nick Soveiko 2:5030/23.101 20 Oct 97 17:28:58 To : Lothar Behet 22 Oct 97 22:32:56 Subj : A bit of steering ... ------------------------------------------------------------------------------- Fri, 17 Oct 1997, 13:07, Lothar Behet (2:2446/301) ==> Pedro Lima: LB> On the other hand, if there are more ip-nodes at a certain moment LB> than conventional ones, who will stop the integration of fido into LB> the internet then? i don't see any problem here. internet (as we use it) is just a transport in the same way as pstn was our transport yesterday. i hope no sysop is afraid of 'integration of fido into the telephone network'. ;) cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #868 [1995] Scn From : Slava Filimonov 2:469/33 21 Oct 97 09:04:42 To : Lech Szychowski 22 Oct 97 22:32:56 Subj : IP-access ------------------------------------------------------------------------------- Hello Lech! 20 Oct 97 02:09, Lech Szychowski wrote to Slava Filimonov: >> old software. Use it. but not for ip. You still have abitiy to send ^^^^^^^^^^^^^^^^^^^^^^ >> mail to ip-systems by snail fido way. Want use ip ? Then use new >> software. isn't it simple or what? LS> What if I want both? Keep it, as it was before. There is _no_free_way_ to adopt old software to ip. You have to pay for this. But others won't pay for this if they can use free software with little brain work from them. Agreed? If so, then use bink-style outbound with old software and binkd for ip. You have to use that, because by using ip and pstn fido your node/point becomes _multiline_. Why i should pay for someone's sotware if i have software which performs same function for free with source code available and open functionality ? -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #869 [1995] Scn From : Lawrence Garvin 1:106/6018 21 Oct 97 22:59:08 To : Lech Szychowski 22 Oct 97 22:32:56 Subj : IP-access ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Lech Szychowski said in a message to Lawrence Garvin: > In the event somebody wants to use the default 'fidonet.org' zone, > then obviously somebody in that heirarchy will have to maintain MX > records for zone:net/node mapped DNS names. LS> But then we have a very unefficient situation: a Z:N/F node capable LS> of handling SMTP is not listed as the MX for *.fF.nN.zZ.fidonet.org But that can be changed for specific nodes. More likely though, it would be changed for entire nets, not a specific node. LS> - or we have to maintain two MX records instad of one. I'm not understanding your concern. As an SMTP node is added to the system, he/she sends an email to the HOSTmaster for the appropriate (DNS) zone and asks them to add the MX record for the appropriate wildcards. Apparently I'm missing something in your point. LS> BTW: if there is an A record for an FQDN, there is no point in LS> listing an MX record for this FQDN (unless we explicitely want to LS> direct mail to some other place). Au contrare, my friend. It is very helpful that -every- system in the DNS that has an A record, also be resolvable to an MX record somewhere. Sendmail v8 looks for -MX- records, and only looks for -A- records on the second go around. For every host that advertises only an A record, sendmail must do -two- DNS lookups before it can deliver the mail. It's trivial to add an MX record right under the A record, and it makes the mail move a heck of a lot smoother! --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #870 [1995] Rcv Scn From : Nick Soveiko 2:5030/23.101 20 Oct 97 18:18:32 To : Lothar Behet 22 Oct 97 22:32:56 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Fri, 17 Oct 1997, 13:05, Lothar Behet (2:2446/301) ==> Marco d'Itri: LB> Adspects of ISDN (against analogue connect): LB> - fast and very reliable datatransfer LB> - directly addressable from any other ISDN system with the same LB> protocol (i.e. X.75, V110, V120), but generally only in the same LB> country possible without problems. LB> - only compatible to analogue protocols with special (mostly LB> expensive) or additional equipment LB> Aspects of IP: LB> - low cost at long distance transmissions LB> - directly adressable from other ip-nodes (dial-in and leased line) LB> with different (matching) protocols LB> - buffering protocols without direct mailer session are possible LB> (i.e. email based), but then no secure transmission is possible LB> (timestamp of arrival, confidential communication) LB> - generally additional costs for each user, as ip-access requires LB> additional charges to a service provider LB> - highly varying bandwidth (depends on general internet usage), LB> therefore required connect times (and costs) are not calculatable concerning the cost, i should probably add that whenever long distance tolls apply, ip wins over pots dialup and isdn hands down. my guess is that a typical charge for *1 hour* of 33.6 dialup online ip-access in most countries would be the *same order of magnitude* as *1 minute* of overseas international call. and with more and more providers worldwide offering unlimited ip access... as for additional costs, i guess it applies to isdn as well. i am not sure about your telco, but for example, bell canada charges cad$60/mo + about cad$.02/min*b-channel from 7am to 7pm for isdn access vs. cad$15 for basic pots dialtone. plus applicable long distance toll: $.15 national, $.25 us, $.50-1 western europe, $1.50-2.50 eastern europe. on the other hand, typical cost of unlimited dialup ip is cad$30/mo. in some neibourghoods cable companies are already offering ip-over-cable at 400kbps 24/365 for about cad$60/mo. the numbers are even more impressing in eastern europe. for instance, in st.petersburg, russia: pots line with basic dialtone is about us$10/mo if you already have one. if you don't, installation is about us$500 and new service is generally available from 'alternative' telco only, that will charge $50/mo for basic dialtone + $.02/min for outgoing calls + applicable long distance toll. isdn is not available at all. examples of long distance rates are: $.50/min to moscow, $1-1.5/min to siberia, up to $2/min to far east, about $1/min to western europe, up to $2/min to north america. cost of dialup ip is $2/hour. i think, these numbers speak for themselves. now comes an interesting question: which system is easier accessible to other members of fidonet - the one with 2400bps/no error correction dialup, fts-0001 as transport/session and cost of calling to being $2/min, or another, binkp-only with 24/365 ip connection and cost of calling to being $2/hour. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #871 [1995] Scn From : Pedro Lima 2:362/21 20 Oct 97 04:51:08 To : Chris Maddock 22 Oct 97 22:32:56 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hi, CM> Good question. If I don't put any translation in. it would CM> dial: CM> 0015-000- Ok. This isn't surely a valid number, so a distracted sysop would not inconvenience somebody attempting to dial an IP address. CM> Yes. And if the noelist compiler authors made the baud field able to CM> take any integer from 0-65535 Yes, but since that would be similar to change the nodelist format, we can take the broader view and solve also a lot of other problems as well, like eliminating the need for several akas... And I'm not talking exclusively about the IP situation. CM> Fair enough. IP as the first flag followed by a comma delimited CM> indication. Whilst this would be easily human readable, it could take CM> a lot of room. Not that that is really a huge problem. Actually, there's a length limit on the whole of the flags. If we're going to list non-standard ports for several services this may be a problem, but then again, if we use a separate nodelist entry to declare IP capability, the risk of exceeding this limit would be minimized. CM> Our biggest problem IMHO, is that the mailers we use and love so much CM> (with good reason I might add) have to support whatever we compile CM> with the compiler. CM> For this reason I would love to see something like regional DNS's to CM> resolve addressing and routing. I am also aware that this is apparently CM> being addressed in another thread but some of the discussion is way CM> over my head. I understand. However, limiting the possibility to a specific FQDN (such as one in the fidonet.org hierarchy) is precisely that, a limitation. I really don't know how nodelist compilers would behave with a FQDN in the phone field, but it smells trouble, so perhaps we can compromise. If an IP node can list its IP address, the phone field is used. If the IP connectivity can only be assured via a FQDN (such as dynamic IP situations), then '-Unpublished-' would appear in the phone field, which I believe doesn't imply the entry to be Pvt, and the system name field would contain the FQDN. This would make for existant IP mailers to successfully call most of the IP nodes, and newer software may look into the system name field for the FQDN if: - The entry is not Pvt - The entry declares IP capability - '-Unpublished-' appears in the phone field For the sysop having an IP address, nothing stops him, if he wants to, to list its FQDN together with the IP address. This could be useful when the IP address has changed but the change has not yet reached the nodelist (and the FQDN remains the same), but this possibility would be left to the discretion of the sysop, not forced to him. CM> I =do= want to see Fidonet survive and run as an alternative to the CM> Internet newsgroups, and also to be a non-commercial alternative to CM> same. FidoNet already is such an alternative, but one of its major problems is that it didn't know how to evolve to accomodate new and cheaper technologies. ISDN helped, but I feel we need to go much farther. CM> I see the IP issue as the gateway to this end and it will also give CM> Fidonet =back= to the amateur hobbiest at very little or even no cost CM> and a huge return in benefits. Again we agree. :-) Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #872 [1995] Scn From : Slava Filimonov 2:469/33 21 Oct 97 09:33:12 To : Lech Szychowski 22 Oct 97 22:32:56 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Lech! 20 Oct 97 02:28, Lech Szychowski wrote to Marco d'Itri: >>> We certainly will need it. A lot of mailers enforce limits on the >>> size of a single message. >> In the modern internet? LS> Yes. For a very simple reason: it takes long to transfer a huge LS> message. And everyone knows that routing breakes down from time to LS> time, TCP connections have their timeouts and SMTP has no "RESTART" LS> command. It looks like BINKP has no such problems... -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- Judge DREDD 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #873 [1995] Scn From : Yuri Teterin 2:5030/239 21 Oct 97 19:15:16 To : Lech Szychowski 22 Oct 97 22:32:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lech ! Mon Oct 20 1997 Lech Szychowski writes to Rune Johansen: LS> OK, I wholeheartedly agree I don't care much what protocol is used LS> as a carrier media for FTS-0001 session [.......] >> According to my interpretation of discussions here and elsewhere, a >> BinkP-only IP-only node does not meet minimum requirements for being a >> public node in Fidonet. LS> That's my concern, too. Precisely. Why? Did you ever try to make an FTS-0001 session with binkp node 'using binkp as a carrier media'? If not - why are you so sure that 'binkp-only node does not meet minimum requirements'? >> A FTS-0001 IP-only node _does_ meet the requirement, due to the FTS-0001 >> part. Wether it uses telnet, ifcico, SIO's VModem or raw TCP for its >> connection, does not matter. Even taking into account that there is no specifications describing the methods of using telnet as 'carrier media', and lack of specifications for vmodem at all? How can two nodes make FTS-0001 session if they will use different implementation for this 'carrier media'? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #874 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 22 Oct 97 22:40:32 To : Yuri Teterin Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hello Yuri! On 21 Oct 97 wrote Yuri Teterin to Lothar Behet: LB>> IPC advises the nodelistcompiler to use the node_name as valid ip LB>> address and gives information (in deciaml or hexadecimal form) LB>> about capabilities according to a key table: LB>> 1 Telnet LB>> 2 Vmodem LB>> 4 Ifcico ... YT> And if we will use radix 32 with 'digits' 0,...,9,A,...,Z, we will YT> be able to make this field even shorter ;-) Sure, there are many things to do better :) But before misusing baudrate field for such a table, the flag field would be more appropriate. This was just an answer to that idea from ??? :) YT> There will be disadvantages for programs too, because with flags YT> like VMP or BNP we are able to get list of nodes, available for our YT> system, just with help of grep or something of this kind - and for YT> your format we must definitely have some special program for this YT> pupuse. There are many disadvantages in this table and i would prefer dedicated flags with optional ports. As we have talked now a long time about this and that, we should come back to business :) Regards Lothar - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #875 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 22 Oct 97 23:16:10 To : Marco d'Itri Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Marco! On 22 Oct 97 wrote Marco d'Itri to Lothar Behet: >> MI> You can tunnel arcmail in email and have receipts. >> Which programs or special (overlaid) protocols do support this and >> packet verification? MI> The program I'm writing. When I will have enough Free Time I will post MI> to NET_DEV the description of the protocol for public review. So in fact this advanced email-based overlayed handshake protocol is not available yet? MI> TransX does some of that, but my protocol is much better. >> MI> Please read: You can't assumer that every bbs has a local toll >> MI> hub in his area. >> But are you sure, that they have internet access in that area? MI> At least in my country, yes. But you can not assume, that it is everywhere the same, so that is IMHO no special advantege of ip :) Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #876 [1995] Rcv Scn From : Frank Ellermann 2:240/5815.1 21 Oct 97 02:55:00 To : Lothar Behet 23 Oct 97 05:42:18 Subj : was: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- LB> 1 Telnet LB> 2 Vmodem LB> 4 Ifcico LB> 8 BinkP LB> 16 FTP LB> 32 ... to be continued ... Seconded... as soon as I understand 1 and 16, which is unfortunately not the case yet Bye, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #877 [1995] Scn From : Marco d'Itri 2:335/680.666 23 Oct 97 15:02:10 To : Pedro Lima 23 Oct 97 22:18:04 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Pedro.Lima@f21.n362.z2.fidonet.org wrote: >an IP node can list its IP address, the phone field is used. If the IP >connectivity can only be assured via a FQDN (such as dynamic IP The problem is that specifying IP addresses should be the exception, not the rule. >situations), then '-Unpublished-' would appear in the phone field, which >I believe doesn't imply the entry to be Pvt, and the system name field >would contain the FQDN. This would make for existant IP mailers to >successfully call most of the IP nodes, and newer software may look into >the system name field for the FQDN if: fqdn-in-phone-field AFAIK works with all IP mailers with a modern nodelist compiler (e.g. fastlst). For your solution we would have to modify the compilers. If PSTN nodes with old compilers barfs on lines with fqdn this should not be a problem, those lines will just be skipped. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #878 [1995] Scn From : Marco d'Itri 2:335/680.666 23 Oct 97 15:14:20 To : Dieter Ringhofer 23 Oct 97 22:18:04 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Dieter.Ringhofer@f14.n2476.z2.fidonet.org wrote: >thousands with already PAID software. Do you want to force some thousand >people to throw their 'money' away?? If they locked themselves with non open software is their own problem, not mine. >binkP/D is free and available in source. Why shouldn't there be an extension >according FTS? Because it's a stupid thing to do. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #879 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 23 Oct 97 15:03:14 To : Lothar Behet 23 Oct 97 22:18:04 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: >So in fact this advanced email-based overlayed handshake protocol is not >available yet? The protocol is here on my desk, I have to type it. > >> MI> Please read: You can't assumer that every bbs has a local toll > >> MI> hub in his area. > >> But are you sure, that they have internet access in that area? > MI> At least in my country, yes. >But you can not assume, that it is everywhere the same, so that is IMHO no >special advantege of ip :) Then IP will be used only when cheaper, where is the problem? -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #880 [1995] Scn From : Lawrence Garvin 1:106/6018 22 Oct 97 08:23:34 To : Marco d'Itri 23 Oct 97 23:08:50 Subj : Flags in nodelist ------------------------------------------------------------------------------- Marco d'Itri said in a message to Lawrence Garvin: >In such a case, I don't believe it would be necessary for the .FIDO >root servers to point to any Internic servers -- the obligation would >fall back to those Fido nodes to provide for resolving in both >systems -IF- they needed to actually resolve non-Fido DNS names from >the Fido/BBS machine. Md> Please, drop this idea. Marco, you're more than welcome to NOT PARTICIPATE in this discussion, but I'll thankyou not to be so arrogant as to suggest what I can, and cannot, propose as ideas, nor what I can discuss. If you can't counterargue my points with useful information, then don't post. Md> The whole concept of alternate root servers is evil and does not Md> works (ask Paul Vixie for technical details :-) ). You're entitled to your personal opinions, as is Paul Vixie. And while I'm even inclined to agree that the concept AS PERTAINS TO THE INTERNET is probably not a good idea... it's also absolutely ludicrous to not consider implmenting the PROTOCOLS in a private network to the benefit of that private network! So.... until some DNS-knowledgeable person engaged in a mature and logical discourse with me as to why this is not a good idea, I'll continue to propose it as a POSSIBLE IMPLEMENTATION. Thankyouverymuch. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #881 [1995] Scn From : Lawrence Garvin 1:106/6018 22 Oct 97 08:22:16 To : Marco d'Itri 23 Oct 97 23:08:50 Subj : Flags in nodelist ------------------------------------------------------------------------------- Marco d'Itri said in a message to Lawrence Garvin: > Also, I can actually list TWO resolvers in my configs, the .FIDO DNS server > > first, and any other DNS server second. If the name fails in the .FIDO > domain, then the resolver will attempt to look it up at the DNS server > identified in the second line. Md> Does not works this way. The second resolver is used only if the Md> first one times out. And, Marco.. if you think about it... you'll realize that it WILL TIME OUT on the first resolver, if the first resolver doesn't contain the ROOT ZONE that is being requested! --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #882 [1995] Scn From : Lawrence Garvin 1:106/6018 22 Oct 97 08:18:44 To : Yuri Teterin 23 Oct 97 23:08:50 Subj : FYI - FWIW ------------------------------------------------------------------------------- Yuri Teterin said in a message to Lawrence Garvin: YT> Fri Oct 17 1997 Lawrence Garvin writes to All: LG> Zorch Frezberg successfully polled my Vmodem port 23 Bink XE last LG> Wednesday afternoon with an Argus on Win95 mailer. LG> Mebbe there's more compatibility than we thought? YT> Argus supports FTN-over-telnet sessions, as well as binkp and YT> ifcico's 'raw TCP'. This is well known and was already mentioned YT> here. Well, apparently that was before my time here, then. :) All I've seen in the past two weeks is the insistence of the BinkD/BinkP users that their software should be the standard, and the insistence of the telnet uses that BinkP is not a universally available protocol, nor an interoperable protocol. Somewhere along the line, somebody lost track of this very fundamental fact. There IS a bridge! Therefore.. since there IS a bridge, since the bridge is FREE, since the bridge comes with source code... there is NO reason why progress should not move on. The standard -is- telnet, and Argus is the bridge to BinkP. YT> There was an attempt to implement VMP in Argus too, but it YT> was not quite successful. Wonder why.... ?? Hmmm... It also needs is an OS/2 version! If it could do OS/2 on regular comm ports, it wouldn't need a VMP implementation, it could use the original. :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #883 [1995] Scn From : Kim Heino 2:222/0 22 Oct 97 07:18:50 To : Yuri Teterin 24 Oct 97 06:04:06 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > there is no unique and standard method to turn telnet chanel into a > chanel supposed by FTS-0001. RFC0856 (telnet is a physical layer protocol). --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #884 [1995] Scn From : Lech Szychowski 2:480/33.7 22 Oct 97 00:54:00 To : Yuri Teterin 24 Oct 97 06:04:06 Subj : FYI - FWIW ------------------------------------------------------------------------------- > Argus supports FTN-over-telnet sessions, as well as binkp and ifcico's > 'raw TCP'. This is well known and was already mentioned here. So what is all this "FTS-0001 as a standard for IP will get us disconnected" stuff about? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #885 [1995] Scn From : Lech Szychowski 2:480/33.7 22 Oct 97 00:48:00 To : Dima Maloff 24 Oct 97 06:04:06 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > But in fido-over-IP world there ARE more nodes with binkp already than, > may be, with all other protocols altogether. So introducing FTS-1 as a > "standard" you'll BREAK the connectivity. Are you trying to say "we are there, so dare not to declare as standard anything else than what we are compatible with, no matter what this other proposal might be"? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #886 [1995] Scn From : Lawrence Garvin 1:106/6018 18 Oct 97 10:53:58 To : Nick Soveiko 24 Oct 97 06:04:06 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Nick Soveiko said in a message to Lawrence Garvin: NS> the issue is not just a telnetd implementation, but a NS> telnetd/fts-0001 implementation. apart from ifcico, which exists NS> for *nix only (and i'm not sure if it supports *fts-0001* sessions NS> anyway), so far we have to resort to a telnetd that is capable of NS> emulating com ports which a traditional fts-0001 compliant mailer NS> can use. *such* telnetd is not free for every platform. vmodem term NS> was used here to point out this problem on a particular platform NS> (os/2). Well.. here's one to smoke on for a while... Zorch Fresberg just initiated and completed a Telnet Port 23 connection from his node to mine using Argus -- which also, btw, supports BinkP -- and, if one reads the flags that Argus self-generates, appears to also support VMoT on port 3141. So..... with the exception of making a chart of all the various options, and what runs where, methinks the rest of the issue is academic. You -can- get there from here. As for free.... well... I don't recall anybody, anywhere, ever promising that Fidonet or FTN-compatible software would be free. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #887 [1995] Scn From : Slava Filimonov 2:469/33 22 Oct 97 10:19:24 To : Yuri Teterin 24 Oct 97 06:04:06 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Yuri! 21 Oct 97 17:38, Yuri Teterin wrote to Lech Szychowski: YT> BTW, do you know, that FTS-0001 is a great hole in security of your YT> system? YT> And this hole is known for years, and even described in YT> FTS-0001.015 itself: So, we can't admit fts-0001  s a ip must-have protocol at all then. ...Or change it, which is not the real solution. And moreover, we have to change policy to reflect ip-specific problems too. -- --< C0PiRATE Cy.b33r.Net <> slf@mrp.cz <> www.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> Mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #888 [1995] Scn From : Dima Maloff 2:5047/13 22 Oct 97 19:14:00 To : Lech Szychowski 24 Oct 97 06:04:06 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Monday October 20 1997 04:29, Lech Szychowski wrote to Rune Johansen: >> IP-only nodes. If your node runs BinkP protocol, I should be able to >> connect to you via BinkP protocol, and do a FTS-0001 handshake (and LS> If I'm not completely wrong, BinkP is not a "transport layer" protocol, LS> it's a "session layer" one - so it's used instead of FTS-0001. Uhh. In terms of internetworking, Binkp is an application layer protocol, and FTS-1 is a mess doing the job of network, transport and application layers (we don't need internetwork layer for direct p2p connects). --- GoldED/2 3.00.Alpha5 UNREG * Origin: Would you give me a root message? I'm kinda tarred (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #889 [1995] Rcv Scn From : Mario Mure' 2:33/505 22 Oct 97 19:38:24 To : Lothar Behet 24 Oct 97 06:04:06 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- In a message dated 21 Oct 1997 about < Re: Proposal for listing as IP-node >, Lothar Behet wrote: > MI> Please read: You can't assumer that every bbs has a local toll hub in > MI> his area. LB> That is the price to pay for a hobby :) LB> But are you sure, that they have internet access in that area? This is the case in many places outside great cities, at least here in Italy. Ciao ! /mario/ mure@sistemia.it --- ifmail v.2.11-tx8.5 * Origin: Stay cool if your hard disk say goodbye (2:33/505@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #890 [1995] Scn From : Lech Szychowski 2:480/33.7 22 Oct 97 00:53:00 To : Slava Filimonov 24 Oct 97 06:04:06 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- > At least everyone, who runs fido-over inet has e-mail box. So, you'll be > able to contact every node/point by e-mail if they have one. Let's follow this idea a bit further - if we all have email, mayby we don't need Fidonet for message transfers any more? Like it? I don't. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #891 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 24 Oct 97 08:12:42 To : Slava Filimonov Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Slava! On 22 Oct 97 wrote Slava Filimonov to Yuri Teterin: SF> And moreover, we have to change policy to reflect ip-specific problems SF> too. Which points of the policy should be changed for ip-specific problems? Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #892 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 24 Oct 97 08:15:48 To : Lech Szychowski Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Lech! On 22 Oct 97 wrote Lech Szychowski to Slava Filimonov: >> At least everyone, who runs fido-over inet has e-mail box. So, >> you'll be able to contact every node/point by e-mail if they have >> one. LS> Let's follow this idea a bit further - if we all have email, mayby we LS> don't need Fidonet for message transfers any more? LS> Like it? I don't. Seconded :) Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #893 [1995] Scn From : Dieter Ringhofer 2:2476/14 24 Oct 97 05:27:20 To : Marco D'itri 24 Oct 97 09:09:30 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> thousands with already PAID software. Do you want to force some thousand >> people to throw their 'money' away?? MdI> If they locked themselves with non open software is their own problem, MdI> not mine. Why should they take care about you if you don't take care about them? Don't you see the need to find a solution fitting for both 'worlds'? A hardliner position in this relation against the 'real' Fido-nodes can only result in one thing: No listed IP-nodes. Be aware of this. >> binkP/D is free and available in source. Why shouldn't there be an >> extension according FTS? MdI> Because it's a stupid thing to do. But, overall the easier (and IMHO) the better way. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #894 [1995] Scn From : Lech Szychowski 2:480/33.7 23 Oct 97 02:49:00 To : Marco d'Itri 24 Oct 97 22:16:02 Subj : A bit of steering ... ------------------------------------------------------------------------------- >>And have to tell your mailer manually that X, Y and Z are all aliases >>for the very same system, so it's a good idea to try all phone numbers >>(or IP addresses in this case) when trying to connect to any of X, Y and Z? > You have the same problem for PSTN multiline systems. Yes, I know. That's why I know it's a pain in the a*s and should be eliminated/avoided if possible. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #895 [1995] Scn From : Rune Johansen 2:210/20 22 Oct 97 20:31:02 To : Lech Szychowski 24 Oct 97 22:16:02 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >> You can find the source for this modified wu-ftp on ftp.fido.de. > Ready to compile on what systems? > And a more fundamental question: is this still the standard FTP protocol? > I highly doubt we can claim it is. Therefore calling it "FTP" is seriously > misleading and - IMHO - wrong. Well, the FTP File Transfer Protocol is the same, but what it ends up in the other side as, is not the part of the transfer itself. Like, if you transfer a file with a long filename to a Win95 FTP daemon, it stores the file with another name than it has got, and uses a mapping table to map between long and 8+3 filename. It still uses the FTP protocol. The FTP client does not need to be modified to use this feature, since it is not a part of the protocol itself. > Nope. I'm afraid it's perfectly valid for an FTP client to assume when > performing PUT operation that if a file of a given name already exists > it will be either overwritten (if permissions allow) or operation will > fail (if permissions do not allow it). If you modify this command behavior > the protocol is not FTP any more. If you use another command, the protocol > is still not FTP... It's kind of like when you try to send a file to a mailer, it can say "skip file" or "retransmit from offset" where it tells you that the file actually exists already. If the file already exists, and is not a part of a broken transfer, most protocols would rename the file in current transfer to something else, so it does not overwrite it. Anyway, it has got nothing to do with the transfer itself. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #896 [1995] Scn From : Nick Soveiko 2:5030/23.101 23 Oct 97 17:16:22 To : Lech Szychowski 24 Oct 97 22:16:02 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wed, 22 Oct 1997, 00:48, Lech Szychowski (2:480/33.7) ==> Dima Maloff: > But in fido-over-IP world there ARE more nodes with binkp already than, > may be, with all other protocols altogether. So introducing FTS-1 as a > "standard" you'll BREAK the connectivity. LS> Are you trying to say "we are there, so dare not to declare LS> as standard anything else than what we are compatible with, LS> no matter what this other proposal might be"? he's trying to say exactly what he said: by enforcing fts-0001 as a standard for fido-over-ip, one will actually decrease connectivity between fidonet systems. ain't that simple? cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #897 [1995] Scn From : Lech Szychowski 2:480/33.7 23 Oct 97 03:03:00 To : Marco d'Itri 24 Oct 97 22:16:02 Subj : A bit of steering ... ------------------------------------------------------------------------------- > You never used BIND, didn't you? :-) Well, once or twice... :) > This is all you need to configure to have a round robin domain: > domain IN A 1.2.3.4 > A 1.2.3.5 > A 1.2.3.6 > Done. It might be round robin from the BIND's point of view. But definitely not necessarily so from its clients' one... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #898 [1995] Scn From : Nick Soveiko 2:5030/69.101 23 Oct 97 16:38:16 To : Lawrence Garvin 24 Oct 97 22:16:02 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Sat, 18 Oct 1997, 10:53, Lawrence Garvin (1:106/6018) ==> Nick Soveiko: LG> As for free.... well... I don't recall anybody, anywhere, ever LG> promising that Fidonet or FTN-compatible software would be free. i agree. now consider that the problem is not in 25 bucks that you have to pay for vmodem, but imagine that you have to pay it abroad. and banking regulations in your country make it next to impossible for a private person to make payments abroad. need i say that all shareware developers want nothing else, but an international money order or bank draft in their domestic currency. choices for a sysop in this situation are: look for freeware analogues, abandon the whole idea on the spot or resort to pirate the software. you wanna a few hundred pirated copies of vmodem running on fidonet systems - you'll get it. just adopt fts-0001 via telnet as a required protocol. cool, eh? ;) cheers, nick --- Handwritten * Origin: <-<-<- Houses of the hairy (Overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #899 [1995] Scn From : Lech Szychowski 2:480/33.7 23 Oct 97 03:00:00 To : Marco d'Itri 24 Oct 97 22:16:02 Subj : A bit of steering ... ------------------------------------------------------------------------------- > Every modern BIND version supports round robin. Are you 101% sure? I'm pretty sure it is not possible for BIND to guarantee that host X (possibly having more that one IP address) issuing N requests (possibly randomly distributed in quite a long period of time) for a type A record of a host Y (that has N addresses) will get all (ie N) addresses. BIND would need to maintain a fairly large and persistent database - and have some mechanism for guessing out that two request coming from two different IPs (remember host X possibly has more than one address) actually are issued by one host. Even worse - the forwarders mechanism breaks thing completely. In brief: although BIND might do its best to behave round-robin-like, it might turn out that for the client this behavior looks quite different. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #900 [1995] Rcv Scn From : Pedro Lima 2:362/21 24 Oct 97 02:58:02 To : Lothar Behet 24 Oct 97 22:16:02 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hi, LB> ... which will last some (a long?) time, until it generally used (even LB> by those, who would use it). Yes, that's why the "patching" of the current format should be made trying to foresee other similar needs. LB> Here it comes: Thanks. :-) Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #901 [1995] Scn From : Nick Soveiko 2:5030/23.101 23 Oct 97 22:30:32 To : Rune Johansen 24 Oct 97 22:16:02 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thu, 23 Oct 1997, 00:03, Rune Johansen (2:210/20) ==> Nick Soveiko: RJ> I see that. If we can argue that a system should be in the RJ> nodelist, even though it cannot do FTS-0001, since it is a RJ> BinkP-only system, then the FTS-0001 requirement can be scratched RJ> from policy, and you cannot be ensured that you can deliver mail to RJ> a node, if you have the means of it (speaking of POTS, ISDN or IP). RJ> That also means that I can develop my own handshake, and put only RJ> that one up, and be a nodelisted system, even if maybe just one RJ> other guy uses it, and that is my uplink. RJ> Since BinkP protocol is documented, anyone can create a BinkP RJ> protocol with the specs. That is true. But, by refusing FTS-0001 we RJ> are opening a can of worms, that we might not be able to close RJ> again, and Fidonet would be ripped apart. Even though we all "hate" RJ> FTS-0001 it's actually a protocol of last resort. as i already wrote to kim heino, the can of worms is already open. one have to set a standard for fts-0001 encapsulating protocol before it can 'legally' be used over tcp/ip. so, if we have to make amedments to fts anyway, why not set a standard for a new fidonet session layer protocol, designed specifically for operation under such conditions? and it is not going to obsolete fts-0001 as soon as we admit that fts-0001 was written implying direct modem connection over pstn. that is, it is not directly applicable to tcp/ip connections and a conventional dialup mailer would probably never want to connect to an ip-mailer using fts-0001. in fact, a fidonet standard proposal for binkp is being under preparation and anybody willing to help with this and/or get access to working materials is strongly encouraged to contact me by netmail. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #902 [1995] Scn From : Rune Johansen 2:210/20 23 Oct 97 00:03:44 To : Nick Soveiko 24 Oct 97 22:16:02 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >well, the imaginary situation above is just an example of absurdity we can end >up with if we adhere to the *letter* of policy. and the letter was written wel > ago... I see that. If we can argue that a system should be in the nodelist, even though it cannot do FTS-0001, since it is a BinkP-only system, then the FTS-0001 requirement can be scratched from policy, and you cannot be ensured that you can deliver mail to a node, if you have the means of it (speaking of POTS, ISDN or IP). That also means that I can develop my own handshake, and put only that one up, and be a nodelisted system, even if maybe just one other guy uses it, and that is my uplink. Since BinkP protocol is documented, anyone can create a BinkP protocol with the specs. That is true. But, by refusing FTS-0001 we are opening a can of worms, that we might not be able to close again, and Fidonet would be ripped apart. Even though we all "hate" FTS-0001 it's actually a protocol of last resort. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #903 [1995] Scn From : Lech Szychowski 2:480/33.7 23 Oct 97 02:39:00 To : Marco d'Itri 24 Oct 97 22:16:02 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >>Err... How can one combine "email" and "crash"? Hint: MX'es. > Not all nodes can be on line 24h and have their MX point to them. So how do I "crash" such a system? MTAs ask first for an MX RR for the FQDN. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #904 [1995] Scn From : Lech Szychowski 2:480/33.7 23 Oct 97 02:47:00 To : Marco d'Itri 24 Oct 97 22:16:02 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >>sysop's email address can always be constructed as something like >>postmaster@fF.nN.zZ.fidonet.org, right? Just make this FQDN's MX > No. Non-24h nodes can't have their MX point to them. If they have permanently assigned IP addresses they very well can. Just add another MX (that is "CM") with higher preference qualifier. But this is a bit twisted idea, right? :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #905 [1995] Scn From : Rune Johansen 2:210/20 23 Oct 97 22:42:28 To : Slava Filimonov 24 Oct 97 22:16:02 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >> time, TCP connections have their timeouts and SMTP has no "RESTART" >> command. > It looks like BINKP has no such problems... BinkP uses a TCP connection, so are as vulnerable to timeouts as other protocols (or transport mechanisms, if you like) that uses TCP. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #906 [1995] Scn From : Nick Soveiko 2:5030/23.101 23 Oct 97 17:21:34 To : Lawrence Garvin 24 Oct 97 22:16:02 Subj : FYI - FWIW ------------------------------------------------------------------------------- Wed, 22 Oct 1997, 08:18, Lawrence Garvin (1:106/6018) ==> Yuri Teterin: LG> Somewhere along the line, somebody lost track of this very LG> fundamental fact. There IS a bridge! LG> Therefore.. since there IS a bridge, since the bridge is FREE, LG> since the bridge comes with source code... there is NO reason why LG> progress should not move on. The standard -is- telnet, and Argus is LG> the bridge to BinkP. if you refer to argus to be THE bridge, then you're wrong - it's not free, it's a commercial (shareware?) product. see my comment on $$$ issue elsewhere in this echo. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #907 [1995] Scn From : Rune Johansen 2:210/20 22 Oct 97 20:43:04 To : Lech Szychowski 24 Oct 97 22:16:02 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> IP-only nodes. If your node runs BinkP protocol, I should be able to >> connect to you via BinkP protocol, and do a FTS-0001 handshake (and > If I'm not completely wrong, BinkP is not a "transport layer" protocol, > it's a "session layer" one - so it's used instead of FTS-0001. True, the BinkP protocol is a protocol that has got the handshake implemented, just like a FTS-0001 handshake. But, to be policy compliant, with a IP-only BinkP-only node, it has to accept and answer with files (transported via BinkP) that is in the FTS-0001 protocol. I am here excluding the XModem and File7 protocols as they are redundant in a protocol that transfers files OK in the first place. It's a "FTS-0001 encapsulated in BinkP" session. This seems like a comparison of "transfer FTS-0001 inside a EMSI session", but has got to be this compilcated, since there is no fallback in the BinkP protocol to a FTS-0001 protocol (as of the time of writing this article). The author of my BBS system has included BinkP as a protocol over IP, and we are in the final beta-testing of it. It does not include this FTS-0001 over BinkP, as it already can do FTS-0001 directly. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #908 [1995] Scn From : Rune Johansen 2:210/20 22 Oct 97 21:00:12 To : Yuri Teterin 24 Oct 97 22:16:02 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > But because there is no software that is able to make _outgoing_ FTS-0001 >session _via_binkp_, nobody will be able sometimes check, am I realy able to d > this or not, isn't it? > And what sense has then your reqiurement in this case? It there are no software that can do FTS-0001 over the protocol you have specified that your system is capable of (and there are no other ones either, that FTS-0001 can be used over, like a phone number where you can connect and do FTS-0001), then you have a system that is not FTS-0001 compatible at all, and would not meet the requirement in policy. You argue with the fact that "I have a protocol that noone speaks, and cannot check, so therefor I must be allowed as a node, since I claim to have requirements in place and functioning" I know it sounds totally ridicolous to use BinkP as a transport for FTS-0001 packets, but to be policy compliant, it has to be done that way. > Over binkp chanel as 'physical layer', isn't it? So you should have the >same implementation of binkp->'physical layer' convertor that I have. And I am No, I would not necessearily have to use your converter, as long as I can get/send the FTS-0001 packets via the BinkP protocol. > this because running FTS-0001 session over binkp is absolutely senseless: if > you have such converter you will be able to make handshake and file/mail > transfer allready at this 'low level', without FTS-0001 overhead). I _know_ that it would be a lot of overhead, and that you already have a session up and running via BinkP. I only tell you what must be done to a BinkP-only node to be compliant with policy. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #909 [1995] Scn From : Lech Szychowski 2:480/33.7 23 Oct 97 02:11:00 To : Slava Filimonov 24 Oct 97 22:16:02 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >>>> We certainly will need it. A lot of mailers enforce limits on the [...] > It looks like BINKP has no such problems... Here "mailer" stands for "MTA". Sorry, my fault, shouldn't have used this type of jargon here in Fido. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #910 [1995] Scn From : Lech Szychowski 2:480/33.7 23 Oct 97 02:19:00 To : Denis McMahon 24 Oct 97 22:16:02 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >> So, as I said, for FTP, accept anonymous upload of *.pkt and arcmail > LS> Name clashes? > Something the recipient has to handle, not part of the transport protocol! Precisely. Such handling is not a part of the FTP protocol. It means existing FTP servers are completely unprepared to serve as mailer substitutes - and that's why I'm afraid FTP cannot and should not be used for Fido sessions. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #911 [1995] Scn From : Nick Soveiko 2:5030/23.101 23 Oct 97 22:01:12 To : Kim Heino 24 Oct 97 22:16:02 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thu, 23 Oct 1997, 10:55, Kim Heino (2:222/0) ==> Rune Johansen: KH> No! BinkP is a session protocol, just like EMSI and FTS-001. There KH> is no "FTS-001 over BinkP", as BinkP replaces FTS-001. Raw, modem, KH> ISDN, ssl and telnet are physical layers, so you can run KH> EMSI/BinkP/FTS-001 over them. wrong. telnet is a session layer protocol as well as binkp. fts-0001 considers layers starting from datalink and goes up to (afair) presentation layer. so strictly speaking, the fact that fts-0001 incapsulation is possible into one session layer protocol (telnet) makes it's incapsulation into any other session layer protocol valid to the same degree (how 'bout fts-0001 over http?;). i'm not even considering here whether such incapsulation makes any sense from pure technical point of view. but it would be 100% politically correct ;). and since 'physical layer', i.e. encapsulating protocol is not defined in fts-0001, the can of worms is already open. voila! cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #912 [1995] Scn From : Lech Szychowski 2:480/33.7 23 Oct 97 02:37:00 To : Marco d'Itri 24 Oct 97 22:16:02 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >> >>FTP daemon will rename received files? [...] > Then get the sources and verify that yourself. Let's put it this way: last time I checked it did not. >>And a more fundamental question: is this still the standard FTP protocol? > Yes. It moves files in the same way wu-ftpd does. What if client _on_purpose_ tries to overwrite a file? >>media (eg diskettes). But would you call this "networking" Fido? :) > Why not? I know about some points that got their echomail on floppynet. Yeah, I also do. But these are points, not nodes, right? :) > email tunneling and FTP are not enough to get a node number, > but those protocols should be allowed because they are useful > and can save people's money. Now that's something I can agree with. If ftp'ing and sending via email is to be a purely optional capability that by itself does not entitle a system to be a Fidonet node it's a completely different situation. >> > My protocol provides multiple ways to verify the sender of a message. >>It's damn easy once you start using tools like PGP. Then any carrier >>media will do. But is it still Fido? > Yes. You are suggesting some revolutionary changes. I'm afraid I'm not flexible enough to accept them right away :) > The client does not even knows there is another file with the same name > in the inbound and does not knows or cares if the server will rename it. What you are saying is equivalent to claiming that "the filename client uses when doing PUT is meaningless since server can do with the received data filename whaterver it wants". > want to send small packets ask your ftn packer to create them small. What about file attaches? Split files using some external utility? >> > [1] If I want to receive my echomail via flying pidgeons (RFC 1149) and >> > my boss agree no one should force us to use another transport. >>You're talking about point-to-boss traffic here, right? Than it's > The same should apply to any other node. Sure. But still any and every node (except for private ones) has to support some common protocol for accepting/receiving netmail. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #913 [1995] Scn From : Nick Soveiko 2:5030/23.101 23 Oct 97 17:42:44 To : Dieter Ringhofer 24 Oct 97 22:16:02 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wed, 22 Oct 1997, 19:44, Dieter Ringhofer (2:2476/14) ==> Yuri Teterin: DR> You write about 200+ systems and their free software but, there're DR> several thousands with already PAID software. several thousands ip-capable nodes? you must be kidding! DR> Do you want to force some thousand people to throw their 'money' DR> away?? nobody said this. you can keep using it in the same way as before. DR> What about trying to find a solution fitting both needs? i most sincerely agree. what i propose will cost you nothing except half an hour of your time. what you propose will cost somebody else a perspective of legal problems. DR> binkP/D is free and available in source. Why shouldn't there be an DR> extension according FTS? afaik, one of the subscribers of this echoconference actually started doing it (i mean, fts-compliant free fido mailer). it proved to be just unworkable. as a result, a new protocol was developed and implemented and fts was abandoned for good. DR> I'm also running SIO (registered) and it's VModem port allows to DR> use existing software further on without the need of setting up DR> something else. i am glad that you have a possibility to pay for sio. many people don't, even if they have money and intention to do so. DR> And: My time is my money as well, some spare time is good for my DR> health... it took me half an hour to install binkd. and at that time there were absolutely no documentation for it whatsoever. just a sample config file. cheers, nick let's bet: you install binkd and if you won't like it after using for 1 month, i pay you the price of a keg of your favourite beer. if you like it (binkd, not the beer! ;), you'll announce it here as well as in other applicable echoes. no cost, no obligations, except being honest. deal? ;) --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #914 [1995] Scn From : Dimitar Ganchev 2:350/14 23 Oct 97 00:08:00 To : Lech Szychowski 24 Oct 97 22:16:04 Subj : IP-access ------------------------------------------------------------------------------- Reply-To: dimitar.ganchev@mail.bol.bg > That's why f12.n35.z2.fidonet.org has both A and MX records with > different IP addresses. LS> And that's the way it should be. All I wanted to say is LS> there might be some point in saying that if a node gets an A LS> record it should also be capable of accepting incoming mail LS> via SMTP - and that technically it's not necessary, because LS> we can add an MX record pinting to some other system. As a Sure. A system should be capable of accepting SMTP connection _only_ if it has no MX record. LS> matter of fact, we'd most likely have to add an MX record LS> anyway, to indicate that this system is a mail gateway for LS> its points. But we'll have to list it as a wildcard in $ORIGIN nNNN.fFFF.zZ.fidonet.org. * IN MX 10 whatever. instead of $ORIGIN fFFF.zZ.fidonet.org. nNNN IN A whatever. IN MX 10 whatever. Regards, .\\itko --- FMail 1.22 * Origin: The home of .\\itko (2:350/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #915 [1995] Scn From : Lech Szychowski 2:480/33.7 23 Oct 97 03:06:00 To : Yuri Teterin 24 Oct 97 22:16:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>> require FIDO-node have phonenumber first of all. > LS> Can you quote a relevant section or direct me to it? [...] >> 5) The phone number to be used when calling your system. Point taken. Then we have to either drop the idea of IP-only nodes or write a new FTS... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #916 [1995] Scn From : Kim Heino 2:222/0 23 Oct 97 10:55:34 To : Rune Johansen 24 Oct 97 22:16:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > If your node runs BinkP protocol, I should be able to connect to you via > BinkP protocol, and do a FTS-0001 handshake (and optional file/mail > transfers) with you. No! BinkP is a session protocol, just like EMSI and FTS-001. There is no "FTS-001 over BinkP", as BinkP replaces FTS-001. Raw, modem, ISDN, ssl and telnet are physical layers, so you can run EMSI/BinkP/FTS-001 over them. Nothing forbits using BinkP with modems too, feel free to test against me. :) You're right that BinkP alone is against policy, you must be able to do FTS-001 over raw or telnet too. If we think this scenario closely then the only suitable place for IP's in nodelist is the phone-field without any fake country-codes. Phone-field defines what is the node's address on that physical layer (phonenumber with modem/isdn, fqdn/ip with IP). Flags tells what protocols you can run there (V34/V42B/X75 with phonenumber, telnet/ssl/raw with IP). --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #917 [1995] Scn From : Rune Johansen 2:210/20 23 Oct 97 22:49:18 To : Kim Heino 24 Oct 97 22:16:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > No! BinkP is a session protocol, just like EMSI and FTS-001. There is no True. > "FTS-001 over BinkP", as BinkP replaces FTS-001. Raw, modem, ISDN, ssl and > telnet are physical layers, so you can run EMSI/BinkP/FTS-001 over them. > Nothing forbits using BinkP with modems too, feel free to test against me. :) :)) I will, I will.. >You're right that BinkP alone is against policy, you must be able to do FTS-00 > over raw or telnet too. That's what I have been trying to say to some people, that BinkP _only_ will not be according to current policy, as other, FTS-0001-capable "physical layer" protocols would be. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #918 [1995] Scn From : Nick Soveiko 2:5030/23.101 23 Oct 97 18:15:50 To : Pedro Lima 24 Oct 97 22:16:04 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Mon, 20 Oct 1997, 04:51, Pedro Lima (2:362/21) ==> Chris Maddock: PL> in the phone field, which I believe doesn't imply the entry to be PL> Pvt, and the system name field would contain the FQDN. why not put fqdn in the location field? imo, in the world of ip routing, it's not he geographical location that matters, but the network topology. you've never seen packets to a system across the street going via amsterdam, or even better, mae-east in new jersey, did you? from this point of view, it makes sense for me putting fqdn in location field. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #919 [1995] Scn From : Nick Soveiko 2:5030/23.101 23 Oct 97 17:31:44 To : Dieter Ringhofer 24 Oct 97 22:16:04 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Wed, 22 Oct 1997, 19:26, Dieter Ringhofer (2:2476/14) ==> Slava Filimonov: SF> on fidonet technology - everything from emsi to z-modem/hydra SF> designed for transmission over unreliable media. But here, tcp/ip SF> cares about it! DR> Since when?? since the rfc-793 was adopted as the internet standard. beginning of 80s, methinks. DR> WHICH tcp/ip???? transmission control protocol over internet protocol. do you know many of them? DR> No common places, please. Call the child with it's name. ok. tcp/ip is a reliable, stream-oriented, connection-oriented protocol. please, see appendix below for a brief glossary. sorry for posting all this, but i think we can better understand each other if we agree on the basic terminology. appendix: connection-oriented Data communication method in which communication proceeds through three well-defined phases: connection establishment, data transfer, connection release. TCP is a connection-oriented protocol. data link layer The OSI layer that is responsible for data transfer across a single physical connection, or series of bridged connections, between two Network entities. flow control A technique for ensuring that a transmitting entity does not overwhelm a receiving entity. HDLC (High level Data Link Control). Popular ISO standard bit-oriented, data link layer protocol derived from SDLC. HDLC specifies an encapsulated method of data on synchronous serial data links. IP (Internet Protocol). The Internet Protocol, defined in STD 5, RFC 791, is the network layer for the TCP/IP Protocol Suite. It is a connectionless, best-effort packet switching protocol. network layer Layer 3 of the OSI reference model. Layer 3 is the layer at which routing, addressing and connection management take place. OSI (Open Systems Interconnection) Reference Model A seven-layer structure designed to describe computer network architectures and the way that data passes through them. This model was developed by the ISO (International Organization for Standardization) in 1978 to clearly define the interfaces in multivendor networks, and to provide users of those networks with conceptual guidelines in the construction of such networks. physical layer The OSI layer that provides the means to activate and use physical connections for bit transmission. In plain terms, the Physical Layer provides the procedures for transferring a single bit across a Physical Media. Quality of Service (Also QoS). A measure of performance for a transmission system that reflects its transmission quality and availability of service. reliable transmission a type of transport service that: + recovers from errors by retransmitting errored frames + delivers frames in correct sequence (also known as stream-oriented) + usually is used in connection-oriented mode session layer Layer 5 of the OSI reference model. Coordinates session activity between aplications, including application-level error control, dialog control, and remote procedure calls. sliding window flow control Method of flow control in which a receiver gives transmitter permission to transmit data until a window is full. When the window is full, the transmitter must stop transmitting until the receiver advertises a larger window. socket Software structure operating as a communications and point within a network device. TCP Transmission Control Protocol. An Internet Standard transport layer reliable protocol defined in STD 7, RFC 793. It is connection-oriented and stream-oriented. TCP/IP protocol suite Transmission Control Protocol over Internet Protocol. This is a common shorthand which refers to the suite of transport and application protocols which runs over IP. transport layer Layer 4 of the OSI reference model. The transport layer is responsible for reliable network communication between end nodes. It implemnts flow and error control and often uses virtual circuits to ensure reliable data delivery. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #920 [1995] Scn From : Pedro Lima 2:362/21 24 Oct 97 00:45:20 To : Frank Ellermann 24 Oct 97 22:16:04 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hi, FE> Maybe (probably ?) we'll come to the conclusion, that listing IP FE> addresses with dummy country code 000- and dashes instead of dots FE> is not the best solution, but anything else fails within the limits FE> of MakeNL / NLMake / NLMaint. It also remains to verify how current nodelist (index) compilers would behave. FE> The next idea could be to try something like Marco's (or whoever FE> invented it in R2:50) "extended nodelist format". In special nets FE> or regions this could be easier than zonewide (or, see Lawrence's FE> message, even worldwide). FWIW, R2:36 is available for such tests, namely by creating a special net (say 369). FE> Last but not least this technical problem also has its political FE> side: What if an NC refuses to list IP nodes, because he's unable FE> to verify it ? Actually, it can be more complicated than that, because what's required is that the new node's application is sent crash from the prospective system. If the NC doesn't support IP, and the node-to-be is IP-only... If going by the book, the solution may be installing an IP hub, which besides acting as the NC delegate will also serve as a bridge between the two technologies. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #921 [1995] Scn From : Lech Szychowski 2:480/33.7 23 Oct 97 02:22:00 To : Yuri Teterin 24 Oct 97 22:16:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Why? Did you ever try to make an FTS-0001 session with binkp node > 'using binkp as a carrier media'? If not - why are you so sure that > 'binkp-only node does not meet minimum requirements'? A while ago someone posted here a brief description of BinkP. Maybe I got it all wrong, but it looked like it was a protocol to be used _instead_ of FTS-0001, like EMSI is. > specifications for vmodem at all? How can two nodes make FTS-0001 > session if they will use different implementation for this 'carrier > media'? They can't. That's one of the reasons we should have a standard defined. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #922 [1995] Scn From : Rune Johansen 2:210/20 22 Oct 97 23:57:10 To : Pedro Lima 24 Oct 97 22:16:04 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- > I really don't know how nodelist compilers would behave with a FQDN in > the phone field, but it smells trouble, so perhaps we can compromise. If > an IP node can list its IP address, the phone field is used. If the IP > connectivity can only be assured via a FQDN (such as dynamic IP > situations), then '-Unpublished-' would appear in the phone field, which > I believe doesn't imply the entry to be Pvt, and the system name field > would contain the FQDN. This would make for existant IP mailers to > successfully call most of the IP nodes, and newer software may look into > the system name field for the FQDN if: As a test (with IP addres, though), next weeks nodelist (on friday 24.) in zone 2 will contain a entry for 2:2/3011, with ,U,IP,TELN and -Unpublished- in phone field, and IP address in system name field. Just for testing purposes, of course. It is not a Pvt entry. So, we'll see how the nodelist compilers feel about that one? :-) --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #923 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 24 Oct 97 22:30:36 To : Rune Johansen Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hello Rune! On 22 Oct 97 wrote Rune Johansen to Pedro Lima: RJ> As a test (with IP addres, though), next weeks nodelist (on friday RJ> 24.) in zone 2 will contain a entry for 2:2/3011, with ,U,IP,TELN and RJ> -Unpublished- in phone field, and IP address in system name field. RJ> Just for testing purposes, of course. It is not a Pvt entry. RJ> So, we'll see how the nodelist compilers feel about that one? :-) If you take a look in your netmail folder, it should feel good :) Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #924 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 24 Oct 97 22:33:08 To : Nick Soveiko Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hello Nick! On 23 Oct 97 wrote Nick Soveiko to Pedro Lima: NS> why not put fqdn in the location field? imo, in the world of ip NS> routing, it's not he geographical location that matters, but the NS> network topology. For routing ftn-over-ip the location shows the sender a possible shortest way for routing to a geographical region. Neither ip# nor fqdn may give this information, just like a possible phone number of -unpublished-. NS> you've never seen packets to a system across the NS> street going via amsterdam, or even better, mae-east in new jersey, NS> did you? Yes, i do regularly, as ip-routing in germany uses sometimes peering in USA :) NS> from this point of view, it makes sense for me putting fqdn in NS> location field. You can put your bbs-name in the fqdn, as you select that name by yourself. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #925 [1995] Scn From : Marco d'Itri 2:335/680.666 24 Oct 97 14:55:40 To : Lawrence Garvin 24 Oct 97 23:37:44 Subj : Re: Flags in nodelist ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: > > Also, I can actually list TWO resolvers in my configs, the .FIDO DNS > > server first, and any other DNS server second. If the name fails in the >And, Marco.. if you think about it... you'll realize that it WILL TIME OUT on >the first resolver, if the first resolver doesn't contain the ROOT ZONE that >is being requested! It will not time out, BIND will reply with "no such domain". If you modify BIND to time out on non *.fido. domains, then for most operations (receiving mail, allowing some client to connect, connectiong to another host) your machine will wait for about one minute before being able to begin. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #926 [1995] Scn From : Marco d'Itri 2:335/680.666 24 Oct 97 15:04:40 To : Lawrence Garvin 24 Oct 97 23:37:44 Subj : Re: Flags in nodelist ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >If you can't counterargue my points with useful information, then don't post. I've done that: the whole idea behind multiple root servers is technically evil, and it's why alternic, edns and other kooks-managed alternate dns services like those will never work. >You're entitled to your personal opinions, as is Paul Vixie. Paul Vixie is the major authority about DNS, and his is not just an opinion. >So.... until some DNS-knowledgeable person engaged in a mature and logical >discourse with me as to why this is not a good idea, I'll continue to propose >it I reported what the most DNS-knowledgeable person on this planet wrote, but I can't remember the details. If you want to read the full discussion search the archive of the nanog mailng list at www.merit.edu or www.nanog.org. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #927 [1995] Scn From : Marco d'Itri 2:335/680.666 24 Oct 97 23:40:56 To : Dieter Ringhofer 25 Oct 97 17:57:34 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Dieter.Ringhofer@f14.n2476.z2.fidonet.org wrote: >Don't you see the need to find a solution fitting for both 'worlds'? There is only one solution that will make everyone happy: don't mandate any standard. Binkp is faster, it's more common and it's free on all platforms. Why should we use FTS-1 over telnet? Only to please some people that doesn't want to waste five minutes to configure a program that will not needs any maintenance? > >> binkP/D is free and available in source. Why shouldn't there be an > >> extension according FTS? > MdI> Because it's a stupid thing to do. >But, overall the easier (and IMHO) the better way. It's not easy to add FTS-1 to binkd, the authors would have to nearly write another mailer. And doing that just to follow a many years old policy that was designed for different things is not worth it. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #928 [1995] Scn From : Dieter Ringhofer 2:2476/14 25 Oct 97 07:05:52 To : Nick Soveiko 25 Oct 97 18:13:06 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> You write about 200+ systems and their free software but, there're DR>> several thousands with already PAID software. NS> several thousands ip-capable nodes? you must be kidding! oh well... i mean several thousands of FIDO nodes. ip-systems want to be listed in a ftn-nodelist. so, tell me why should they be listed if they don't have the capabilities needed to become a member of the club? which improvement takes place for the ftn? they can participate at the net without being listed (and do it since long time) but they can't get membership according the rules if they don't fullfill the rules. IF they are listed without it, f.e. I could ignore ZMH and every other 'order' from policy with my already listed lines. such a listing leads to a can of worms therefore be carefull when trying to get rid of something. if one wants to destroy fidonet, he ignores it's rules. DR>> Do you want to force some thousand people to throw their 'money' DR>> away?? NS> nobody said this. you can keep using it in the same way as before. so i stay compliant with fts-0001 and don't use any other software. DR>> What about trying to find a solution fitting both needs? NS> i most sincerely agree. what i propose will cost you nothing except half NS> an hour of your time. what you propose is the death of fidonet. NS> what you propose will cost somebody else a perspective of legal NS> problems. i know about your problems but, believe me, it wasn't that cheap and easy to have a separate line or even a modem some years ago over here as well. even sending some registration fee to u.s.a. brought very often more money to the banking institute than to the programmer. internet access is still expensive over here, a modem is normally needed for it. today you're in opposit position - cheap internet access without need of a modem (no phoneline -> no modem). fidonet is basing on possibility of direct connects, so, which number has to be dialed to connect an ip-system? don't you see the real differences and the real need to find something in between to have a workable solution?? DR>> binkP/D is free and available in source. Why shouldn't there be an DR>> extension according FTS? NS> afaik, one of the subscribers of this echoconference actually started NS> doing it (i mean, fts-compliant free fido mailer). it proved to be just NS> unworkable. as a result, a new protocol was developed and implemented and NS> fts was abandoned for good. and so should whole fidonet do now? DR>> And: My time is my money as well, some spare time is good for my DR>> health... NS> it took me half an hour to install binkd. those 30 minutes spare time per day (which are not given every day) i use to read and write some mails while having breakfast (have a look at the timestamp). my ftn-system works fine, why should i change something for internet?? if i wanna do some 'internetting' i do it as well with the very same system without any change at ftn-side (all lines are still connectable), i also don't need an entry for the line used for it in fido's nodelist. but: i only do it if there's no other choice for being to expensive and unreliable over here. i don't sell 'internet access' via my personal limited account like some known people do over here to lower their costs. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #929 [1995] Scn From : Dieter Ringhofer 2:2476/14 25 Oct 97 05:45:26 To : Nick Soveiko 25 Oct 97 18:13:06 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- SF>> on fidonet technology - everything from emsi to z-modem/hydra SF>> designed for transmission over unreliable media. But here, tcp/ip SF>> cares about it! DR>> Since when?? NS> since the rfc-793 was adopted as the internet standard. beginning of 80s, NS> methinks. tcp provides reliable point-to-point services (compare it with UDP) but, it isn't all you need. DR>> WHICH tcp/ip???? NS> transmission control protocol over internet protocol. what you mean is 'only' -tcp- (RFC 793 describes only TCP, in four-level model of transport layer IP is one level below, see also RFC 791). NS> do you know many of them? not many but, i know several tcp/ip implementations ;) DR>> No common places, please. Call the child with it's name. NS> ok. tcp/ip is a reliable, stream-oriented, connection-oriented protocol. every stream-oriented service is unreliable (even NFS). f.e. in dependancy of protocol you're using frames might be lost for ever and / or sequence at receiver's side is not according the sending sequence. this can result in bad files (f.e. .zip with some bytes in wrong order or missing bytes). to get things straight retransmission is necessary than. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #930 [1995] Scn From : Ask Bjoern Hansen 2:235/10 24 Oct 97 02:55:52 To : Denis McMahon 25 Oct 97 18:14:44 Subj : IP-access ------------------------------------------------------------------------------- Hello Denis! Sunday October 12 1997 23:24, Denis McMahon wrote to Ask Bjoern Hansen: ABH>> I guess you should read something about how it works. ABH>> It's very easy to redelegete f.x. n251.z2.fidonet.org to a ABH>> nameserver controlled by someone in your net. DM> It should not be a requirement that a net maintain a nameserver before DM> that net is allowed to contain IP nodes! Agree. But I didn't say you *have* to redelegate the zone, just that it's possible, and easy. I still think the best solution are getting the ip numbers via dns and not via some hack in the nodelist. Kind Regards, ask (dev@null.dk) --- GoldED/2 3.00.Alpha4+ * Origin: Programmers do it in the bytes (2:235/10) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #931 [1995] Scn From : Marco d'Itri 2:335/680.666 25 Oct 97 18:23:12 To : Lech Szychowski 25 Oct 97 21:57:32 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: > > Every modern BIND version supports round robin. >Are you 101% sure? I'm pretty sure it is not possible for BIND Yes. >to guarantee that host X (possibly having more that one IP address) >issuing N requests (possibly randomly distributed in quite a long >period of time) for a type A record of a host Y (that has N addresses) >will get all (ie N) addresses. BIND would need to maintain a fairly It's statistically guaranteed. >In brief: although BIND might do its best to behave round-robin-like, >it might turn out that for the client this behavior looks quite different. In practice that works fine enough. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #932 [1995] Scn From : Marco d'Itri 2:335/680.666 25 Oct 97 18:33:40 To : Lech Szychowski 25 Oct 97 21:57:32 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: > >>And a more fundamental question: is this still the standard FTP protocol? > > Yes. It moves files in the same way wu-ftpd does. >What if client _on_purpose_ tries to overwrite a file? Do you know any mailer that does that? While operating correctly? When my PSTN mailer receive a file with the same name of one present in the inbound, this file is renamed. > >>media (eg diskettes). But would you call this "networking" Fido? :) > > Why not? I know about some points that got their echomail on floppynet. >Yeah, I also do. But these are points, not nodes, right? :) Right. >Now that's something I can agree with. If ftp'ing and sending via email >is to be a purely optional capability that by itself does not entitle >a system to be a Fidonet node it's a completely different situation. I don't think someone here is suggesting that we should have FTP o email only nodes. We should just discuss a way to advertise those protocols. > > The client does not even knows there is another file with the same name > > in the inbound and does not knows or cares if the server will rename it. >What you are saying is equivalent to claiming that "the filename client >uses when doing PUT is meaningless since server can do with the received >data filename whaterver it wants". All PSTN mailers do that. >Sure. But still any and every node (except for private ones) has to >support some common protocol for accepting/receiving netmail. True. I was describing an optional protocol. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #933 [1995] Scn From : Rune Johansen 2:210/20 24 Oct 97 01:20:22 To : Lawrence Garvin 26 Oct 97 05:43:00 Subj : Flags in nodelist ------------------------------------------------------------------------------- > Thiking about the liklihood that some company would be amenable to somebody > trying to run an IP-Fidonet Node behind a corporate firewall seems a bit > dichotomous to me. > If the organization is concerned enough to put up a firewall, I don't expect >the Network Administrators to take to kindly to wide-open Fidonet nodes sittin > behind 'em. If'n I was in such a circumstance (and may be very soon at > 106/6355), I'd tell 'em to put the Fido/IP node -outside- the firewall. I don't say that the fido node should be placed within the internal network of a company, but maybe on a DMZ segment of that firewall. I would not run a node (for whatever purpose) straight on the internet, without any form of protection. But, when we are talking about internal or DMZ segments, we are still talking about "behind a firewall". I design and set up firewalls for both internet and intranet use in private and official businesses here in Norway. I can tell you one thing: administrators are a strange kind of people. Sometimes they won't listen to common sense, and sometimes they are leniant to solutions where they would not even need a firewall. :-) So, being allowed to have a fidonet node on a DMZ segment could be allowed, but maybe not doing DNS requests out from that segment again. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #934 [1995] Scn From : Sean Rima 2:252/356 24 Oct 97 14:37:00 To : Lech Szychowski 26 Oct 97 05:43:00 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hi Lech, On Stardate <9710.20>, you wrote me: >> I think as others have said that it is getting Ipmailers into the >> nodelist and not the protocols that is being debated. LS> Of what use is a mailer without a protocol one can use to talk to it? Some one mentioned that an additional Flag, ie IP:xx could be use to donate the type of mailer used. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: Oh! I get it! HAHAHAHAHAhahahaha....haha.. (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #935 [1995] Scn From : Denis McMahon 2:251/20 24 Oct 97 19:21:30 To : Lech Szychowski 26 Oct 97 05:43:00 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Lech Szychowski wrote to Denis McMahon: >> So, as I said, for FTP, accept anonymous upload of *.pkt and arcmail > LS> Name clashes? > Something the recipient has to handle, not part of the transport protocol! LS> Precisely. Such handling is not a part of the FTP protocol. It LS> means existing FTP servers are completely unprepared to serve as LS> mailer substitutes - and that's why I'm afraid FTP cannot and LS> should not be used for Fido sessions. Rubbish. FTP has been used for fidonet data transfer for some time, as has SMTP. The fact that it is used and it works shows that the problem you are trying to invent either does not occur, or is not insurmountable. Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #936 [1995] Scn From : Sean Rima 2:252/356 24 Oct 97 14:33:00 To : David Moufarrege 26 Oct 97 05:43:00 Subj : Argus ------------------------------------------------------------------------------- Hi David, In a message to All you wrote: DM> Hello All! DM> I've been trying to get Argus to even make an outbound call but to no DM> avail. Who has experience with that mailers TCP/IP daemon and can DM> lend me a hand? I run Argus locaally to collect mail from my Ipmailer. Basically try this. CONFIG --> Dial Up --> Restrictions and Edit the User Scheme --> Forbidden Add a new line and enter the AKA that you want to use as IP only (ie 2:252/358) then CONFIG --> TCP/IP Daemon --> Nodes Add a row then In Node enter the AKA (eg 2:252/358) in the Overrides enter The Ip (If symbolic use quotes) if you are connecting to BinkD then directly after the IP add _24554 then something like: ,CM,BND,TEL eg for 2:252/358: "alice.pcug.co.uk"_24554,CM,BND or 111.111.111.111_24554,CM,BND,TEL Then try a poll. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: Not a bug - an undocumented feature!! (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #937 [1995] Scn From : Rune Johansen 2:210/20 24 Oct 97 01:31:22 To : Marco d'Itri 26 Oct 97 05:43:00 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- >> BTW, will many nodes use non-standard ports? > Most unix nodes will. Port 23 is already used by the telnet daemon. If you run a unix system (you are the boss on it), and you want to run it as a BBS primarly, you would do as they have done on telnet://fix.no. They run the BBS at port 23, and have moved the telnetd daemon elsewhere. That way, people that wnats to use the BBS can just telnet in on port 23, but those with real unix accounts _know_ wich port to send their telnets to. If you are not a "owner" of the system you are running your node at, you would need the blessing of the system operator to put up a daemon on a non-standard port anyway. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #938 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 26 Oct 97 10:51:46 To : Sean Rima Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hello Sean! On 24 Oct 97 wrote Sean Rima to Lech Szychowski: >>> I think as others have said that it is getting Ipmailers into the >>> nodelist and not the protocols that is being debated. LS>> Of what use is a mailer without a protocol one can use to talk to LS>> it? SR> Some one mentioned that an additional Flag, ie IP:xx could be use to SR> donate the type of mailer used. This initiates some trouble, as a node may run different mailers under the same address and has to specify non-standard ports. Therefore i prefer the komma-seperated list of flags with optional port specification via ":". Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #939 [1995] Scn From : Lech Szychowski 2:480/33.7 24 Oct 97 10:10:00 To : Dieter Ringhofer 26 Oct 97 18:08:38 Subj : IP-connectivity ------------------------------------------------------------------------------- > LS> Right. But nevertheless you undenstood what I meant, didn't you? [...] > Does it mean that every software being developed according valid law is > wrong when it ignores something like this? No, of course not. New software has to use the recent/modern standards and it would just be nice if it allowed for some old stuff to (unless this stuff is a sc*ewed up one). > I don't see any need for it. I'm NOT in favour of T-flags as well as > listed IP-only nodes not being connectable (I even don't want to see an > ISDN-only node) especially for the 'little' problem with different So you'd go with "IP node = 24/7 online"? > privacy in Internet. Using Fido's technology the way it's thought to be > used you don't need any encryption under normal circumstances (except > against your secret service )... I agree that when it comes to transferring confidential stuff direct connectivity is a very big advantage. But nowadays we all have tools like PGP available for free, so it's more about being sure your message made it to the destination than being sure nobody read it on a way there. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #940 [1995] Scn From : Lech Szychowski 2:480/33.7 24 Oct 97 10:00:00 To : Lawrence Garvin 26 Oct 97 18:08:38 Subj : Flags in nodelist ------------------------------------------------------------------------------- > And, Marco.. if you think about it... you'll realize that it WILL TIME > OUT on the first resolver, if the first resolver doesn't contain the > ROOT ZONE that is being requested! You sure? I'd say there might be an authoritative answer "it does not exist". Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #941 [1995] Scn From : Lech Szychowski 2:480/33.7 24 Oct 97 10:18:00 To : Rune Johansen 26 Oct 97 18:08:38 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > compilcated, since there is no fallback in the BinkP protocol to a > FTS-0001 protocol (as of the time of writing this article). If - as many claim here - BinkP is free, why not have it implemented? It would stop a lot of arguing here :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #942 [1995] Scn From : Lech Szychowski 2:480/33.7 24 Oct 97 09:57:00 To : Lawrence Garvin 26 Oct 97 18:08:38 Subj : IP-access ------------------------------------------------------------------------------- > LS> - or we have to maintain two MX records instad of one. > I'm not understanding your concern. As an SMTP node is added to the > system, he/she sends an email to the HOSTmaster for the appropriate > (DNS) zone and asks them to add the MX record for the appropriate > wildcards. I agree. > Apparently I'm missing something in your point. What I'm trying to say is there is very little point in putting into a nodelist entry with an FQDN that is not in the relevant fidonet.org subdomain. If this node is capable of handling incoming SMTP connections then it should be listed as a Internet->Fido gateway for at least itself, which in turn requires having an MX record in a fidonet.org subdomain - so why trouble with another FQDN? > LS> BTW: if there is an A record for an FQDN, there is no point in > LS> listing an MX record for this FQDN (unless we explicitely want to > LS> direct mail to some other place). > Au contrare, my friend. It is very helpful that -every- system in the > DNS that has an A record, also be resolvable to an MX record somewhere. [...] > It's trivial to add an MX record right under the A record, and it makes > the mail move a heck of a lot smoother! From the point of keeping the packet flow as little as possible, yes, of course. And to list a host as an MX for itself with priority 0 is a good practice, too - but it is not necessary for enabling other hosts to deliver mail to this one. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #943 [1995] Scn From : Lech Szychowski 2:480/33.7 24 Oct 97 10:23:00 To : Kim Heino 26 Oct 97 18:08:38 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > You're right that BinkP alone is against policy, you must be able to do > FTS-001 over raw or telnet too. And that's precisely what we've been arguing about for a long time here :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #944 [1995] Scn From : Lech Szychowski 2:480/33.7 24 Oct 97 10:16:00 To : Rune Johansen 26 Oct 97 18:08:38 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- > transfer a file with a long filename to a Win95 FTP daemon, it stores > the file with another name than it has got, and uses a mapping table to > map between long and 8+3 filename. It still uses the FTP protocol. The Yes, and as long as the mapping algorithm is deterministic it makes almost no difference. What we are suggesting here is making indeterministic changes to names. > actually exists already. If the file already exists, and is not a part ^^^^^^^^^^ > of a broken transfer, most protocols would rename the file in current ^^^^^^^^^^^^^^^^^^^^ > transfer to something else, so it does not overwrite it. Yes again. But is there any way for FTP to check for the condtion underlined above? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #945 [1995] Scn From : Kim Heino 2:222/0 25 Oct 97 12:49:24 To : Nick Soveiko 26 Oct 97 18:12:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > telnet is a session layer protocol as well as binkp. Yes, in the InterNet world. From Fido's point of view it's more to physical layer as it is feasible to do FTS-001 over telnet. There are lot of 24h telnet-BBSes running mailer and BBS in telnet port. With this same thinking it's ok to do FTS-001 over HTTP, but until somebody does it we can forget it. Or, do considerer FTS-001 over raw socket as the minimal requirement? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #946 [1995] Scn From : Rune Johansen 2:210/20 25 Oct 97 12:36:20 To : Nick Soveiko 26 Oct 97 18:12:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > operation under such conditions? and it is not going to obsolete fts-0001 as > soon as we admit that fts-0001 was written implying direct modem connection > over pstn. that is, it is not directly applicable to tcp/ip connections and a >conventional dialup mailer would probably never want to connect to an ip-maile > using fts-0001. The whole discussion around FTS-0001 came from a suggestion that there should be at least one common protocol for IP nodes. Many people said that the obvious protocol should be BinkP, since there already are hundreds of nodes in fidonet using it. I then argued with that if we are to follow policy, then this protocol should be capable of carrying FTS-0001 handshake. Then it has been argued that this is a ridicolous solution. So, FTS-0001 over BinkP is not a solution. But, FTS-0001 is a solution over a telnet connection, or a raw IP connection. It is not a solution over SIO's VModem, since it has got a proprietary protocol, and would not be implemented on too many platforms, or would not be accessible on too many platforms. The basis question is still valid: Should the IP nodes have at least one protocol in common? For BinkP capable nodes this would not be any problem to implement, as they would use the listening port, autodetect BinkP vs. FTS-0001, and have a session accordingly. The same for a BBS that runs again a IP-fossil software; it would autodetect EMSI/FTS-6/FTS-1 when the fossil daemon hands over a hot connection. My software has got no problem with this. It can receive FTS-1, EMSI and BinkP protocol on inbound connections, regardless of it being IP or modem connection. > in fact, a fidonet standard proposal for binkp is being under preparation and > anybody willing to help with this and/or get access to working materials is > strongly encouraged to contact me by netmail. I really hope that the Standards Proposal will be more thoroughly documentetd than the BinkP specs that have been posted here, and that is available on the web. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #947 [1995] Scn From : Slava Filimonov 2:469/33 24 Oct 97 14:25:56 To : Lech Szychowski 26 Oct 97 18:12:26 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Lech! 22 Oct 97 00:53, Lech Szychowski wrote to Slava Filimonov: >> At least everyone, who runs fido-over inet has e-mail box. So, >> you'll be able to contact every node/point by e-mail if they have >> one. LS> Let's follow this idea a bit further Yes I did, that why i wanna ... LS> - if we all have email, mayby we LS> don't need Fidonet for message transfers any more? LS> Like it? I don't. ... fido to do simple things simle. As simple, as sending e-mail. Like it? I do. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #948 [1995] Scn From : Amir Shabashvili 2:5049/12 24 Oct 97 10:57:46 To : Lech Szychowski 26 Oct 97 18:12:26 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Lech! Replying to a message from Lech Szychowski to Amir Shabashvili: LS> I'm quite aware of that. Actually I wrote more than once here that LS> generally I'm against a dialup-connected system to be granted the LS> IP-node status; the only exception I can allow for is a node that has LS> decided to be online each day for a period of time listed in its LS> nodelist entry using T flags :-) Yes, I'm agree with that point of view. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #949 [1995] Scn From : Slava Filimonov 2:469/33 24 Oct 97 19:12:24 To : Rune Johansen 26 Oct 97 18:12:26 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Rune! 23 Oct 97 22:42, Rune Johansen wrote to Slava Filimonov: >>> time, TCP connections have their timeouts and SMTP has no "RESTART" >>> command. >> It looks like BINKP has no such problems... RJ> BinkP uses a TCP connection, so are as vulnerable to timeouts as other RJ> protocols (or transport mechanisms, if you like) that uses TCP. But binkd aware of thouse facts. binkd stores info about paritally-received files and can issue rest command. Name clashes also resolved. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #950 [1995] Rcv Scn From : Yuri Teterin 2:5030/239 24 Oct 97 20:11:12 To : Lothar Behet 26 Oct 97 18:12:26 Subj : FTS-0001 and IP ------------------------------------------------------------------------------- Hello, Lothar ! Wed Oct 22 1997 Lothar Behet writes to Yuri Teterin: LB> It was your original statement, that FTS-0001 just strikes conventional LB> (pstn) nodes. Therefore i posted this excerpt from FTS-0001. My statement was based on FIDO-Policy and not on FTS-0001. LB> As mentioned in all my messages, i support any protocol for ftn-over-ip, LB> that performs a direct handshake between two mailers (including binkp) LB> _equivalent_ to conventional mode and uses nodelist data for LB> authentication. Is so - we have no contradictions. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #951 [1995] Scn From : Yuri Teterin 2:5030/239 24 Oct 97 19:49:50 To : Lech Szychowski 26 Oct 97 18:12:26 Subj : FYI - FWIW ------------------------------------------------------------------------------- Hello, Lech ! Wed Oct 22 1997 Lech Szychowski writes to Yuri Teterin: >> Argus supports FTN-over-telnet sessions, as well as binkp and ifcico's >> 'raw TCP'. This is well known and was already mentioned here. LS> So what is all this "FTS-0001 as a standard for IP will get us LS> disconnected" stuff about? Argus exists for Win32 only and is shareware, not free. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #952 [1995] Scn From : Yuri Teterin 2:5030/239 24 Oct 97 20:08:02 To : Lawrence Garvin 26 Oct 97 18:12:26 Subj : FYI - FWIW ------------------------------------------------------------------------------- Hello, Lawrence ! Wed Oct 22 1997 Lawrence Garvin writes to Yuri Teterin: LG> Therefore.. since there IS a bridge, since the bridge is FREE, since the LG> bridge comes with source code... there is NO reason why progress should LG> not move on. The standard -is- telnet, and Argus is the bridge to BinkP. Argus is not free, and definitely does not comes with sources. And it exists for Win95 and WinNT only. Argus is really very nice but it can not be an universal solution in any case. YT>> There was an attempt to implement VMP in Argus too, but it YT>> was not quite successful. LG> Wonder why.... ?? Hmmm... Because there exist no specivication for VMP. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #953 [1995] Scn From : Slava Filimonov 2:469/33 24 Oct 97 14:31:40 To : Dieter Ringhofer 26 Oct 97 18:12:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dieter! 22 Oct 97 19:44, Dieter Ringhofer wrote to Yuri Teterin: DR> You write about 200+ systems and their free software but, there're DR> several thousands with already PAID software. Do you want to force DR> some thousand people to throw their 'money' away?? Millions cows eats green grass every day. Does that mean, that you should eat grass too, because of millions cows do so? Imho, paying money is extensive way(easiest), and use simple and free sw is intensive way(not simple, but effective and free). ps. sorry for offtopic. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #954 [1995] Scn From : Yuri Teterin 2:5030/239 24 Oct 97 18:43:16 To : Lech Szychowski 26 Oct 97 18:12:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lech ! Thu Oct 23 1997 Lech Szychowski writes to Yuri Teterin: >> Why? Did you ever try to make an FTS-0001 session with binkp node >> 'using binkp as a carrier media'? If not - why are you so sure that >> 'binkp-only node does not meet minimum requirements'? LS> A while ago someone posted here a brief description of BinkP. Maybe LS> I got it all wrong, but it looked like it was a protocol to be used LS> _instead_ of FTS-0001, like EMSI is. You are quite right. But this does not mean that it is _impossible_ to run FTS-0001 over binkp. This will be absolutely ineffective, quite stupid and will have no sense, but if whole FIDO-comunity will insist on it - this is posible. >> specifications for vmodem at all? How can two nodes make FTS-0001 >> session if they will use different implementation for this 'carrier >> media'? LS> They can't. That's one of the reasons we should have a standard defined. But there is no standards either on the implementation of FTN-over-telnet session both on vmodem, isn't it? So, how can some standards be based on them? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #955 [1995] Scn From : Yuri Teterin 2:5030/239 24 Oct 97 18:56:18 To : Rune Johansen 26 Oct 97 18:12:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Wed Oct 22 1997 Rune Johansen writes to Yuri Teterin: RJ> It there are no software that can do FTS-0001 over the protocol you have RJ> specified that your system is capable of (and there are no other ones RJ> either, that FTS-0001 can be used over, like a phone number where you can RJ> connect and do FTS-0001), then you have a system that is not FTS-0001 RJ> compatible at all Why not? I (and some of my friends) do have such software, but nobody can force us to supply somebody else with it. Or, as I have writen before, I can _sell_ if for $9999999. Then there will be no principal difference between this software and SIO+Vmodem, that are not free too, isn't it? >> Over binkp chanel as 'physical layer', isn't it? So you should have the >> same implementation of binkp->'physical layer' convertor that I have. RJ> No, I would not necessearily have to use your converter, as long as I can RJ> get/send the FTS-0001 packets via the BinkP protocol. But there are infinitely many ways to 'get/send FTS-0001 packets via the BinkP protocol'. You can with the same effect say 'I would not necessearily have to use any FTN-over-IP protocol, as long as I can get/send the FTS-0001 packets via IP' and try then make FTS-0001 session with VModem based mailer. Of cause, you'll fail in this case. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #956 [1995] Scn From : Slava Filimonov 2:469/33 24 Oct 97 19:10:38 To : Lech Szychowski 26 Oct 97 18:12:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Lech! 23 Oct 97 03:06, Lech Szychowski wrote to Yuri Teterin: LS> [...] >>> 5) The phone number to be used when calling your system. LS> Point taken. Then we have to either drop the idea of IP-only nodes LS> or write a new FTS... FTS concerning fido nodes using ip. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #957 [1995] Scn From : Yuri Teterin 2:5030/239 24 Oct 97 19:17:54 To : Dieter Ringhofer 26 Oct 97 18:12:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Dieter ! Wed Oct 22 1997 Dieter Ringhofer writes to Yuri Teterin: DR> Which software did you test and which one is NOT compliant to FTS-0001? For instance, very popular mailer T-Mail had not FTS-0001 for years, and got the ability to make FTS-0001 session only two months ago, and at incoming calls only. Just the same, as I have mentioned before, the majority of ifmail-based systems are not FTS-0001 compliant (this depend on the configuration of they ability to support standard login: at they ports). DR> You write about 200+ systems and their free software but, there're several DR> thousands with already PAID software. Do you want to force some thousand DR> people to throw their 'money' away?? That a strange idea? Nobody force them. But why should we be forced forever to be compatible with these ineffective (and undocumented, what is very important also) implementations of FTN-over-IP transfer? DR> What about trying to find a solution fitting both needs? DR> binkP/D is free and available in source. Why shouldn't there be an DR> extension according FTS? What kind of extension? It is absolutely senseless to try to make binkd to be compatible with the pare like Vmodem+existing_FTN-mailer. It will be more easy to write new mailer from scratch and run it separately from binkd at the same station. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #958 [1995] Scn From : Yuri Teterin 2:5030/239 24 Oct 97 20:18:26 To : Kim Heino 26 Oct 97 18:12:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Kim ! Wed Oct 22 1997 Kim Heino writes to Yuri Teterin: >> there is no unique and standard method to turn telnet chanel into a >> chanel supposed by FTS-0001. KH> RFC0856 (telnet is a physical layer protocol). RFC865 describes only one _command_ of telnet protocol. As for all other commands its support is optional for any telnet implementation. And it has nothing in common with physical layer too. Secondary, to use TRANSMIT-BINARY option we must: 1) enter this mode (and why are you sure it will be accepted by remote?) 2) set some other parameters of the chanel like echo and so on 3) be ready to process other telnet commands (what commands?) during the session. To implement these functions we require some additional protocol describing which commands of telnet protocol should be supported and when and how shold they be processed. This protocol can be rather simple (and it is simple in existing implementations), but its existence is a must. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #959 [1995] Scn From : Yuri Teterin 2:5030/239 24 Oct 97 20:37:50 To : Lech Szychowski 26 Oct 97 18:12:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lech ! Wed Oct 22 1997 Lech Szychowski writes to Dima Maloff: >> But in fido-over-IP world there ARE more nodes with binkp already than, >> may be, with all other protocols altogether. So introducing FTS-1 as a >> "standard" you'll BREAK the connectivity. LS> Are you trying to say "we are there, so dare not to declare LS> as standard anything else than what we are compatible with, LS> no matter what this other proposal might be"? If new proposals will allow to make software simpler, transfer files faster and require less system resources - they will be supported. But now you suggest just opposite solution - to get such standards that make software more complicated, transfer file slower and require more resources. So why are you surprised that other people do not like to support such a proposal? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #960 [1995] Scn From : Yuri Teterin 2:5030/239 24 Oct 97 21:12:30 To : Rune Johansen 26 Oct 97 18:12:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Wed Oct 22 1997 Rune Johansen writes to Lech Szychowski: RJ> True, the BinkP protocol is a protocol that has got the handshake RJ> implemented, just like a FTS-0001 handshake. But, to be policy compliant, RJ> with a IP-only BinkP-only node, it has to accept and answer with files RJ> (transported via BinkP) that is in the FTS-0001 protocol. FTS-0001 transfers only *.pkt-files, attached files and its names. Binkp makes just the same. So it is not clear that do you understand talking fallback to FTS-0001 in BinkP (if you exclude XModem from the list of requirements). Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #961 [1995] Scn From : Yuri Teterin 2:5030/239 24 Oct 97 21:32:20 To : Kim Heino 26 Oct 97 18:12:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Kim ! Thu Oct 23 1997 Kim Heino writes to Rune Johansen: KH> Raw, modem, ISDN, ssl and telnet are physical layers, so you can run KH> EMSI/BinkP/FTS-001 over them. telnet isn't. It can be only _used_ for _emulation_ of physical layer. KH> You're right that BinkP alone is against policy, you must be able to do KH> FTS-001 over raw or telnet too. You can not 'to do FTS-0001' just over telnet. You should use some additional protocol that will emulate 'physical layer' on the base of telnet. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #962 [1995] Scn From : Dima Maloff 2:5047/13 25 Oct 97 14:31:00 To : Lech Szychowski 26 Oct 97 18:12:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wednesday October 22 1997 00:48, Lech Szychowski wrote to Dima Maloff: >> But in fido-over-IP world there ARE more nodes with binkp already than, >> may be, with all other protocols altogether. So introducing FTS-1 as a >> "standard" you'll BREAK the connectivity. LS> Are you trying to say "we are there, so dare not to declare LS> as standard anything else than what we are compatible with, LS> no matter what this other proposal might be"? Hm. I just wanted to say that "FTS-1 over IP improves connectivity" argument should not be used as it's not true. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #963 [1995] Scn From : Slava Filimonov 2:469/33 24 Oct 97 14:40:10 To : Dieter Ringhofer 26 Oct 97 18:12:26 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Dieter! 22 Oct 97 19:26, Dieter Ringhofer wrote to Slava Filimonov: SF>> installing linux for free and using Netscape under X. Just open SF>> your eyes on fidonet technology - everything from emsi to SF>> z-modem/hydra designed for transmission over unreliable media. SF>> But here, tcp/ip cares about it! DR> Since when?? DR> WHICH tcp/ip???? DR> No common places, please. Call the child with it's name. I meant tcp cares almost of it. For reliable file transfers it will be enough simple protocol like tftp ( binkp does file transfers too ). In Fidonet all we have is raw output from modem port. And someone had to implement network layer( aimed for transmission over modem ). And the question is - Do we really need for fido-over-ip connection another network layer ? If we do, than next step is - what protocol to use. The most simple and most unefficient/unsecure is X-modem. The most complicated is emsi/hydra/zmodem. So all folks here basicly stands for two opinions : 1. Keep fido network layer over tcp. (use v-modem/etc/compatible with existing sw/ or/and implement fts001 ) 2. Do not keep fido network layer(as rudimentary). ( use simple binkp protocol for fido-over-ip ) Both are self-exclusive. Add compatibility between them means add fido network layer. ... Am i calling child with it's name ? -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #964 [1995] Scn From : Slava Filimonov 2:469/33 24 Oct 97 15:32:00 To : Marco d'Itri 26 Oct 97 18:12:26 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Marco! 22 Oct 97 15:28, Marco d'Itri wrote to Slava Filimonov: >> MI> Nodes without 24h connectivity IMHO should only use email >> MI> tunnelling because it has deterministic connection times. >> They can get their mail from fallback ip node - it maybe a /0 for >> node and /xx.0 for ip-point ;) in case we're using DNS for fidonet >> over ip. E-Mail MI> Please explain that better. I meant, i will be a wery useful thing, if you couldn't send mail directly you'll have ability to send mail as close as possible to the destination node. This rule covers sending mail to non-ip node, just let's name non-ip fido node ip-capable but with 0h connectivity. It this case, you can send mail to ip-hub next door to that node, assuming that two nodes in same net should exchange with mail. My thoughts about it went beyound fall-back exchange node towards fido over ip routing protocol. I've just assumed, that fido over ip like ip-network inside ip with different nodes naming and with it's own connectivity. In case you can't find path to destination node ( dest node not in your ip list - similar to ip, where nodes list can be obtained by broadcat ) you have to route mail to your uplink ( in ip - gateway ). Then you have list of nodes, to which you can send mail for differnt nets/nodes/zones - routing tables. (ip static routes). Then at this point fido-style connectivity ends. IP networks can have dynamic routing tables and routing discovery. In fido there is no approved dynamic routing. Only dynamic routing across existing static routes. If we add routing discovery for our fido connections we'll achieve two benefits - mail will be delivered as close as possible to the destination node(if you can't deliver it directly). That also means, that mail will not pass through all hubs - improving reliability/lowering traffic over zonegates/backbones. In worst case, when no fido-adress to ip adress from DNS not exist, such protocol can discover route from asking your uplink for some RR ( route records ). Or you can have that RR already - if your upling will advertize it's routes. These RR's can stript/combined to mach selected question - route to zone/ route to region/ route to net/ route to node/ ( 4 levels ). Then your uplink can send you it's RRs best match to your question. Then you can start asking RR's from other nodes. Let's suppose you have adress of your uplink uplink. Then you can ask for route that node. By this way you can go all way usual mail does down to destination node. Again, in worst case the only RR you have is your uplink. But this is not all. By setting TTL( time to live/recover or absolute expiration time ) to RR and starting advertizing your RR's to your uplinks/backbone we can eliminate problem with routing change if some node stops receiving mail for others. For example, if one node(hub) has dial-up ip or dial on demand it can set TTL on it's RR to time it going to stay on-line and advert it RR to uplink. If some node asks uplink for route to node(non-ip) in that hub segment and receives RR for it, than can take place mail transfer to that dial-up hub for non-ip node (assuming that RR is real that means destination node has link with that hub - this is what hub advertizing in its RR). How it sounds ? >> tunneling is not a good at all. We should use simple >> services/protocols where it's possible. For FIDO we don't want to >> complicate simple fts packet/files transfer, aren't we ? MI> If doing that saves me money, I want. First, it saves a lot of time. Next, you don't have to pay other people for implementing/coding complicate things. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #965 [1995] Scn From : Yuri Teterin 2:5030/239 24 Oct 97 20:55:10 To : Marco D'itri 26 Oct 97 18:12:26 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello, Marco ! Wed Oct 22 1997 Marco d'Itri writes to Frank Ellermann: MI> IFC is TELN with an optional optimized communication protocol. Interesting interpretation ;-). I'd say, that TEL is a IFC with spoiled transport level protocol. The only reason of existance of TEL-protocol is compatibility with Vmodem that does not support plain TCP connection for unknown reason. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #966 [1995] Scn From : Slava Filimonov 2:469/33 24 Oct 97 16:33:00 To : Lawrence Garvin 26 Oct 97 18:12:26 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hello Lawrence! 18 Oct 97 10:53, Lawrence Garvin wrote to Nick Soveiko: LG> As for free.... well... I don't recall anybody, anywhere, ever LG> promising that Fidonet or FTN-compatible software would be free. But we have to have ability to use free software as an option with same functionality. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #967 [1995] Scn From : Yuri Teterin 2:5030/239 24 Oct 97 21:05:30 To : Lawrence Garvin 26 Oct 97 18:12:26 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hello, Lawrence ! Sat Oct 18 1997 Lawrence Garvin writes to Nick Soveiko: LG> As for free.... well... I don't recall anybody, anywhere, ever promising LG> that Fidonet or FTN-compatible software would be free. But isn't is too strange and restrictive to _require_ from all IP-nodes to be compatible with _unique_ program that is not free and use protocols without any specifications? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #968 [1995] Scn From : Marco d'Itri 2:335/680.666 26 Oct 97 09:47:50 To : Rune Johansen 26 Oct 97 22:41:12 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >If you are not a "owner" of the system you are running your node at, you >would need the blessing of the system operator to put up a daemon on a >non-standard port anyway. This is not true, I can install any daemon I want on unprivileged ports. I just need a shell account. And I don't have to bother the sysadmin to change the configuration and so on. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #969 [1995] Scn From : Dieter Ringhofer 2:2476/14 26 Oct 97 10:22:44 To : Lech Szychowski 27 Oct 97 06:59:50 Subj : IP-connectivity ------------------------------------------------------------------------------- >> LS> Right. But nevertheless you undenstood what I meant, didn't you? >> Does it mean that every software being developed according valid law is >> wrong when it ignores something like this? LS> No, of course not. New software has to use the recent/modern standards LS> and it would just be nice if it allowed for some old stuff to (unless LS> this stuff is a sc*ewed up one). This little example screws up a lot of setups. >> I don't see any need for it. I'm NOT in favour of T-flags as well as >> listed IP-only nodes not being connectable (I even don't want to see an >> ISDN-only node) especially for the 'little' problem with different LS> So you'd go with "IP node = 24/7 online"? I would go for dialup systems showing additional (!) capabilities somewhere in their nodelist entry. Every working solution for this has my support and I'm testing several things over here for myself but, I'm NOT in favour of IP-only entries in any FTN-nodelist. Therefore the proposal of skipping an established minimal FTN-protocoll for IP-nodes has NO support from my side. The solution must or may be somewhere in between, ok, but if a conventional FTN-node has to fullfill requirenments an IP-system must fullfill them as well. Otherwise the FTN is killed. >> privacy in Internet. Using Fido's technology the way it's thought to be >> used you don't need any encryption under normal circumstances (except >> against your secret service )... LS> I agree that when it comes to transferring confidential stuff direct LS> connectivity is a very big advantage. But nowadays we all have tools LS> like PGP available for free, so it's more about being sure your message LS> made it to the destination than being sure nobody read it on a way there. Than you better stay in Internet. Internet is commercial while FTNs are normally privat and privat systems carrying the load and the costs are no common carrier. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #970 [1995] Rcv Scn From : Rune Johansen 2:210/20 26 Oct 97 02:50:48 To : Lothar Behet 27 Oct 97 07:07:54 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- >> As a test (with IP addres, though), next weeks nodelist (on friday >> 24.) in zone 2 will contain a entry for 2:2/3011, with ,U,IP,TELN and >> -Unpublished- in phone field, and IP address in system name field. >> Just for testing purposes, of course. It is not a Pvt entry. >> So, we'll see how the nodelist compilers feel about that one? :-) > If you take a look in your netmail folder, it should feel good :) Ooff, I see now from the nodelist, that is has been appointed as a Pvt entry. Seems like the MakeNL in Ward's place doesn't allow for a non-pvt phonenumber of -Unpublished-. Tough luck :-) --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #971 [1995] Scn From : Lawrence Garvin 1:106/6018 25 Oct 97 13:09:58 To : Nick Soveiko 27 Oct 97 07:07:54 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Nick Soveiko said in a message to Lawrence Garvin: LG> As for free.... well... I don't recall anybody, anywhere, ever LG> promising that Fidonet or FTN-compatible software would be free. NS> i agree. NS> now consider that the problem is not in 25 bucks that you have to NS> pay for vmodem, but imagine that you have to pay it abroad. and NS> banking regulations in your country make it next to impossible for NS> a private person to make payments abroad. need i say that all NS> shareware developers want nothing else, but an international money NS> order or bank draft in their domestic currency. Gee.. sounds like my nightmares with trying to get TimEd/2 registered. :) C'est la vie. NS> choices for a sysop in this situation are: look for freeware NS> analogues, abandon the whole idea on the spot or resort to pirate NS> the software. you wanna a few hundred pirated copies of vmodem NS> running on fidonet systems - you'll get it. just adopt fts-0001 via NS> telnet as a required protocol. Nick... if I were to speculate... I'd speculate that probably 2/3 of the VModem on OS/2 implementations along with the SIO supporting them are already running 'unregistered' -- and will probably continue to do so thru eternity. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #972 [1995] Scn From : Rune Johansen 2:210/20 26 Oct 97 02:03:42 To : Lech Szychowski 27 Oct 97 07:07:54 Subj : Flags in nodelist ------------------------------------------------------------------------------- >> And, Marco.. if you think about it... you'll realize that it WILL TIME >> OUT on the first resolver, if the first resolver doesn't contain the >> ROOT ZONE that is being requested! > You sure? I'd say there might be an authoritative answer "it does > not exist". I think you are correct here. If you question a root server (authorative for the . domain) and it tells you that the fido. does not exist, you have no reason for going to the next root server to try it again. If you should go to the next one, regardless of the answer from the first one you contact, there would be no use of distributing the autority of the root domain on several root servers. Concolusion will be: If you meet a root server that says it is authorative for the zone you are querying, it should not go to the next one. But, in a resolv.conf situation, I am more unsure, as I don't konw how different implementations would go to the next one if the first one answers autoratively on a query. I would believe that it would only go to the next one in line, after a (configurable) timeout on the query to the first one. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #973 [1995] Scn From : Lawrence Garvin 1:106/6018 26 Oct 97 08:53:22 To : Lech Szychowski 27 Oct 97 07:07:54 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Lawrence Garvin: LS> What I'm trying to say is there is very little point in putting LS> into a nodelist entry with an FQDN that is not in the relevant LS> fidonet.org subdomain. I disagree, Lech. We've already talked about adding a flag with a domain trailer in the flags area. I've just been looking through Fido<>Internet gating software, and every one of them supports the Fidonet naming convention (p##.f##.n##.z##.domain.name) -- that's not exclusive to fidonet.org. Therefore, there seems to be no reason to restrict this to fidonet.org FQDN listings only. LS> If this node is capable of handling incoming SMTP connections then LS> it should be listed as a Internet->Fido gateway for at least LS> itself, Except that being able to handle incoming SMTP does not equate to being a functional gateway. LS> which in turn requires having an MX record in a fidonet.org LS> subdomain - so why trouble with another FQDN? It requires having an MX record in -some- domain, but not necessarily fidonet.org LS> From the point of keeping the packet flow as little as possible, LS> yes, of course. And to list a host as an MX for itself with LS> priority 0 is a good practice, too - but it is not necessary for LS> enabling other hosts to deliver mail to this one. Technically, you are correct. :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #974 [1995] Scn From : Rune Johansen 2:210/20 26 Oct 97 02:08:10 To : Lech Szychowski 27 Oct 97 07:07:54 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- > Yes, and as long as the mapping algorithm is deterministic it makes > almost no difference. What we are suggesting here is making indeterministic > changes to names. It would be the same as a non-secure session uploading a pkt-file with the same name as a pkt-file already lying in the inbound directory of the mailer. How does the current mailers treat that? Do they overwrite the file, or do they rename it? >> actually exists already. If the file already exists, and is not a part >> ^^^^^^^^^^ >> of a broken transfer, most protocols would rename the file in current >> ^^^^^^^^^^^^^^^^^^^^ >> transfer to something else, so it does not overwrite it. > Yes again. But is there any way for FTP to check for the condtion > underlined above? I do not know if a PUT command also sends filesize with as parameter. If it does, a FTP daemon can draw conclusions based on those facts. I alsoo do not know if the FTP daemon has got the capability of issuing a command back that requests a transfer from a specific offset. I know that FTP clients can do it, but the other way around? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #975 [1995] Scn From : Rune Johansen 2:210/20 26 Oct 97 02:19:04 To : Lech Szychowski 27 Oct 97 07:07:54 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> compilcated, since there is no fallback in the BinkP protocol to a >> FTS-0001 protocol (as of the time of writing this article). > If - as many claim here - BinkP is free, why not have it implemented? > It would stop a lot of arguing here :) A suggestion I got in another conversation (in netmail), is a one that I will include in a near proposal posting here: Since ports in a IP connection is "free", why not use a fallback to a telnet or raw port where you can use FTS-0001, if your mailer does not run a BinkP compatible protocol. That would mean that the BinkP node should run a FTS-0001 capable mailer on a well-konwn port, in addition to the BinkP protocol mailer on the BinkP port. Besides, the BinkP/1.0 protocol description sucks (it got many flaws in it, especially around the part with passwords), and the only BinkP/1.1 spec I have found is written in russian. I do not understand russian, so if someone would be so kind to translate it, several people would be happy. Maybe things are looking better there. About the password things in BinkP: There is not mentioned anywhere in the specs that if you have no password, you should use "-" as password. Only found this by looking at the source of Binkd 0.9.1. And, there could be lots of misunderstanding in the password routine, by having case-sensitive password checking. And, it assumes that since you have a TCP session, all transfers are error-free. That is not always the truth. There should be some kind of CRC32 on the total file that is being transferred, to check for convertings made by links in the 'net. And, the BinkP protocol binds itself to IP. I do not believe in submitting protocols as an FSP that requires a special layer to run on top of. There is nothing wrong with using BinkP over a modem connection, except for the errorchecking part. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #976 [1995] Scn From : Lawrence Garvin 1:106/6018 26 Oct 97 18:41:30 To : Slava Filimonov 27 Oct 97 18:12:04 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Slava Filimonov said in a message to Lawrence Garvin: SF> Hello Lawrence! SF> 18 Oct 97 10:53, Lawrence Garvin wrote to Nick Soveiko: LG> As for free.... well... I don't recall anybody, anywhere, ever LG> promising that Fidonet or FTN-compatible software would be free. SF> But we have to have ability to use free software as an option with SF> same functionality. No, Slava, you don't. :) I repeat... being a member of Fidonet, and participating in this hobby, has NEVER carried with it any suggestion, much less guarantee, that the tools necessary to participate would be FREE. The fact of the matter is, had it not been for Vince Perriello, Bob Hartman, Scott Dudley, and a few others whose names don't come immediately to mind (I don't use their software) -- the membership of Fidonet may well have been half of what it ever was. It was that FREE software that those gentlemen designed, wrote, and made available to the masses that allowed many of us to explore where before we never would have considered exploring (try to become an amateur radio operator, for example). But the bottom line still remains, there are no guarantees, and for people, like us, who enjoy sitting on the cutting edge of technology, there are generally only two options: (1) Write it ourselves (which -does- cost us money -- last I heard most of the good compilers, save for the GNU compilers, were commercial software products -- and even the GNU compilers cost somebody some money somewhere to obtain the files). (2) Rely upon somebody else to write the software -- and expect that they'll want compensation for THEIR TIME AND EXPENSE in writing a product that might not be accepted by those on the 'cutting edge' because somebody else might write something just a little bit better. Either way..... TANSTAAFL. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #977 [1995] Scn From : Slava Filimonov 2:469/33 26 Oct 97 15:20:16 To : Amir Shabashvili 27 Oct 97 18:12:04 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Amir! 24 Oct 97 10:57, Amir Shabashvili wrote to Lech Szychowski: LS>> I'm quite aware of that. Actually I wrote more than once here LS>> that generally I'm against a dialup-connected system to be LS>> granted the IP-node status; the only exception I can allow for is LS>> a node that has decided to be online each day for a period of LS>> time listed in its nodelist entry using T flags :-) AS> Yes, I'm agree with that point of view. Even dial-up/and all other non-ip fido nodes or points can be granted the IP-capable fido node. As soon as alternative 24h ( fallback ) mail exchanger(s) can be found for such node. You'll still have ability to send them mail. but not directly. And this should be done transparently. The only thing remains, that such node can't ( or can but not 24h ) accept direct connection. LETS assume we do have protocol, which can forward file or file request. Then is there is a problem with contacting any fido-ip system indirectly ? -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #978 [1995] Scn From : Lawrence Garvin 1:106/6018 26 Oct 97 17:21:02 To : Lech Szychowski 27 Oct 97 18:12:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Lech Szychowski said in a message to Yuri Teterin: >>> require FIDO-node have phonenumber first of all. > LS> Can you quote a relevant section or direct me to it? LS> [...] >> 5) The phone number to be used when calling your system. LS> Point taken. Then we have to either drop the idea of IP-only nodes LS> or write a new FTS... Even a new FTS won't get around that (unfortunate) "procedure" contained in the policy document (which shouldn't have been there in the first place!). Policy requires a telco number and a modem... I had missed that requirement myself, notwithstanding the permissiveness of FTS-0001. Alas, nothing short of a policy amendment will permit IP-only nodes. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #979 [1995] Scn From : Yuri Teterin 2:5030/239 26 Oct 97 15:22:44 To : Lech Szychowski 27 Oct 97 18:12:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lech ! Fri Oct 24 1997 Lech Szychowski writes to Kim Heino: >> You're right that BinkP alone is against policy, you must be able to do >> FTS-001 over raw or telnet too. LS> And that's precisely what we've been arguing about for a long time here :) Will you be really satisfied if any binkp-node will be able to support FTS-0001 over raw TCP? Taking into account that this will not improve its connectivity with IP-fossil based nodes (those can not work over raw TCP) and so will improve its connection with ifcico only (but ifcico-based nodes have now no problems with binkp - they just run additionaly binkd and are happy). As to FTS-0001 over telnet - can you explain, what is the advantage of telnet against any over protocol (keeping in mind that it is not effective as the transport and require extra processor resources, and there is no specifications on using telnet as transport protocol for FTN-session)? As far as I understand the only reason that it is supported now is its implementation in Vmodem - but how long should we be the slaves of (ineffective and unspecificated) decisions of the author of Vmodem? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #980 [1995] Scn From : Lawrence Garvin 1:106/6018 26 Oct 97 12:50:42 To : Denis McMahon 27 Oct 97 18:12:04 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Denis McMahon said in a message to Lech Szychowski: DM> Rubbish. FTP has been used for fidonet data transfer for some time, DM> as has SMTP. The fact that it is used and it works shows that the DM> problem you are trying to invent either does not occur, or is not DM> insurmountable. Whether it works, or not, or any other related concept is irrelevant. What is -relevant- is can the FTN MAILER do anything useful with that information, and until somebody provides for replaceable parameters in the config files of FIFTP or other utilities, I'd say the answer is no. My FIFTP sessions run totally independent of the existence of any nodelist, as does the inbound and outbound processing of echomail to and from those ftp sites. Therefore, it serves no purpose at all (at least for me) for SMTP or FTP protocol information to be in the -nodelist-. Either I already know that, and have configured the appropriate software to handle that, or it doesn't matter at all, I'm still going to send mail via landline telco FTN connect. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #981 [1995] Scn From : Lawrence Garvin 1:106/6018 26 Oct 97 16:46:34 To : Nick Soveiko 27 Oct 97 18:12:04 Subj : echomail uplink iz z1, anyone? ------------------------------------------------------------------------------- Nick Soveiko said in a message to all: NS> i kindly apologize for being slightly offtopic, but i can't think NS> of a better place to ask for this. NS> any kind soul from z1 reading us can provide this gentleman with NS> further directions on where he can get an echofeed via ip? Nick, as you can see I'm a bit behind, but I did send a reply to Eric and offered him point access, etc. from my node, presuming that's what he's interested in. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #982 [1995] Scn From : Yuri Teterin 2:5030/239 26 Oct 97 15:08:58 To : Rune Johansen 27 Oct 97 18:12:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Sat Oct 25 1997 Rune Johansen writes to Nick Soveiko: RJ> The whole discussion around FTS-0001 came from a suggestion that there RJ> should be at least one common protocol for IP nodes. This is desirable but not necessary. Is we decide to use flags like IFC, BNP, VMP in nodelist, each node can calculate all common protocols for destination node and make the call at most appropriate one. RJ> Many people said that the obvious protocol should be BinkP, since RJ> there already are hundreds of nodes in fidonet using it. Nobody said that. Everybody can continue to use vmodem ore ifcico as before and be listed in lidelist. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #983 [1995] Scn From : Slava Filimonov 2:469/33 26 Oct 97 15:36:58 To : Dieter Ringhofer 27 Oct 97 18:12:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dieter! 25 Oct 97 07:05, Dieter Ringhofer wrote to Nick Soveiko: DR> so i stay compliant with fts-0001 and don't use any other software. DR>>> What about trying to find a solution fitting both needs? NS>> i most sincerely agree. what i propose will cost you nothing NS>> except half an hour of your time. DR> what you propose is the death of fidonet. That only means death of redundant protocol. fidonet are us, but not some protocol. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #984 [1995] Scn From : Lawrence Garvin 1:106/6018 26 Oct 97 18:18:50 To : Rune Johansen 27 Oct 97 18:12:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen said in a message to Nick Soveiko: RJ> The whole discussion around FTS-0001 came from a suggestion that RJ> there should be at least one common protocol for IP nodes. Many RJ> people said that the obvious protocol should be BinkP, since there RJ> already are hundreds of nodes in fidonet using it. The obvious counter argument to this is that there are also hundreds of nodes in fidonet doing EMSI/FTS-6/FTS-1 over telnet. :) RJ> I then argued with that if we are to follow policy, then this RJ> protocol should be capable of carrying FTS-0001 handshake. Then it RJ> has been argued that this is a ridicolous solution. "Following policy is a ridiculous solution" -- I have a -real- big problem with that philosophy. Granted, I think there are some really stupid things in Policy 4, just like many others, but there -is- a reason why there are "minimum standards to be used as fallback". Nothing says normal daily operations have to use those minimum standards, but the software -does- have to have the capability "just in case". RJ> So, FTS-0001 over BinkP is not a solution. But, FTS-0001 is a RJ> solution over a telnet connection, or a raw IP connection. And based on what I've read in the past few hours (messages posted over the past two weeks), BinkD -can- be written to support FTS-0001 connectivity to a telnet-based IP-mailer (such as Binkley/vmodem) -- Argus has proven that. RJ> It is not a solution over SIO's VModem, since it has got a RJ> proprietary protocol, and would not be implemented on too many RJ> platforms, or would not be accessible on too many platforms. Just food for thought, but this past week I obtained 'new' licenses for my SIO. The registratio numbers were 10025130 and 10025131. Where do you suppose he started numbering? Also keep in mind that I know he started numbering after v1.15, since my officemate at work has a v1.15 registered by his -name- not a serial number. My point... is to try to demonstrate how many -registered- SIO implementations there are, and every SIO implementation is a -potential- VModem implementation, only lacking a PPP dialup connection. :) RJ> The basis question is still valid: Should the IP nodes have at RJ> least one protocol in common? I've been thinking about protocols in general. Particularly with observation to the implementations of X.75 and V.110/V.120. It would seem, based on the willingness of the ZCs to allow listings of ISDN-only X.75 and V.110/V.120 nodes, that -protocol- (i.e. communications-link protocol) is not an issue. I would expect, then, that this would also extend to IP protocols (such as telnet, vmotelnet, vmp, binkp, ftp, smpt, and pick another half dozen just for good measuere). What is still -required-, even for those X.75 and V.110/V.120 nodes, though, is a -mailer- at the other end that will negotiate a FTS-0001 session with whatever might initiate a call on a protocol supported by that node. This concept really goes all the way back to basic modem communications ever since the introduction of HST. Up until that point, there were basically only three modem protocols: 1200bps (V.22), 2400bps(V.22bis), and 9600bps (V.32). But then some modem manufacturers got creative, and we ended up with all sorts of combinations -- and only some of the pick were available in any one box. As a result, it became the responsibility of the SYSOP to make sure they were initiating a call to a node that had a common protocol -- HST and VFC are the two that come immediately to mind. However, the same basic rule still applied. _IF_ two nodes could establish a common communications-link protocol, whatever that may be, we don't care, it was still a -requirement- that both of them be able to negotiate an FTS-0001 MAILER SESSION. In light of all of that history, it's my humble opinion, at this time, that issues of PROTOCOL or IP vs PSTN are not relevant at all. The flags field -should- be used to specify whatever protocols that node supports (and those flags will have to be ZC approved, in any case), and the MAILERs _MUST_ be able to negotiate an FTS-0001 session AS A MINIMUM STANDARD. Note, again, for those with short term memories -- this does NOT mean that they have to actually USE FTS-0001 -- only support it. It should be programmed as a -fallback- negotiation standard, for when nothing else will work. The only remaining questions to be determined is -- where does the IP number or FQDN go in the nodelist source -- and who's going to write the nodelist generator(s), nodelist compiler(s), and mailer modification(s) that will allow US to use these new features. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #985 [1995] Scn From : Slava Filimonov 2:469/33 26 Oct 97 15:40:08 To : Kim Heino 27 Oct 97 18:12:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Kim! 25 Oct 97 12:49, Kim Heino wrote to Nick Soveiko: KH> Yes, in the InterNet world. From Fido's point of view it's more to KH> physical layer as it is feasible to do FTS-001 over telnet. There are KH> lot of 24h telnet-BBSes running mailer and BBS in telnet port. With KH> this same thinking it's ok to do FTS-001 over HTTP, but until somebody KH> does it we can forget it. telnet-BBSes has nothing to do with fido mail transfers. Same thinking does not works here. if HTTP itself exist(but not HTTP over ftp or smtp or telnet!), why it's a problem for BinkP do it purpose in internet world? -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #986 [1995] Scn From : Lawrence Garvin 1:106/6018 26 Oct 97 17:17:20 To : Yuri Teterin 27 Oct 97 18:12:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Yuri Teterin said in a message to Lothar Behet: YT> If you insist on implementation of FTS-0001 over IP, you sould YT> implement it not over TCP but over UDP, which much more close to YT> 'physical layer' than TCP is. So, are your ready to require YT> support of FTN-0001 over UDP from any IP-node? I suspect that if you took a look at the file-transfer protocols used in association with those FTS-0001 sessions, you'll find that their nature is such that they -need- to have a TCP connection, and will not be able to function adequately across a UDP connection. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #987 [1995] Scn From : Yuri Teterin 2:5030/239 26 Oct 97 15:21:48 To : Lech Szychowski 27 Oct 97 18:12:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lech ! Fri Oct 24 1997 Lech Szychowski writes to Rune Johansen: >> compilcated, since there is no fallback in the BinkP protocol to a >> FTS-0001 protocol (as of the time of writing this article). LS> If - as many claim here - BinkP is free, why not have it implemented? LS> It would stop a lot of arguing here :) Because nobody could explained that kind of such 'fallback' is expected (if we want not just to fulfill the requirements of Policy but to improve the connectivity between FIDO-nodes). Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #988 [1995] Scn From : Lawrence Garvin 1:106/6018 26 Oct 97 18:51:00 To : Yuri Teterin 27 Oct 97 18:12:04 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Yuri Teterin said in a message to Lawrence Garvin: YT> Hello, Lawrence ! YT> Sat Oct 18 1997 Lawrence Garvin writes to Nick Soveiko: LG> As for free.... well... I don't recall anybody, anywhere, ever promising LG> that Fidonet or FTN-compatible software would be free. YT> But isn't is too strange and restrictive to _require_ from all YT> IP-nodes to be compatible with _unique_ program that is not free YT> and use protocols without any specifications? Don't know, Yuri, perhaps. But isn't it also equally as "strange and restrictive" to require me to run two different mailers on my OS/2 just so I can have connectivity with you -and- the rest of Fidonet? At least my BinkleyTerm/VModem will run on both physical and artifical COM ports. Oh, and btw, the -VMODEM- was 'free'. It was the -SIO- (the Communications Port Driver Software) that I had to register, whether I wanted IP connectivity or not! To my recollection, there are very few OS/2 Sysops who are NOT using SIO in place of the stock IBM OS/2 Comm drivers. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #989 [1995] Scn From : Lawrence Garvin 1:106/6018 26 Oct 97 12:48:56 To : Denis McMahon 27 Oct 97 18:12:04 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Denis McMahon said in a message to Lech Szychowski: DM> Lech Szychowski wrote to Denis McMahon: > So, as I said, for FTP, accept anonymous upload of *.pkt and arcmail > files, just like happens during a session today. LS> Name clashes? DM> Something the recipient has to handle, not part of the transport DM> protocol! Anybody who accepts -anonymous- upload of PKT and ARCMail files has just violated rule number one of Fidonet security -- SESSION LEVEL PASSWORDS! I am strictly opposed to the use of anonymous ftp for the transport of Fidonet mail. All ftp should be done on a closed-account basis, password protected, and even then, although not normally done, should probably include packet level passwords. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #990 [1995] Scn From : Dima Maloff 2:5047/13 27 Oct 97 08:34:00 To : Dieter Ringhofer 27 Oct 97 18:12:04 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wednesday October 22 1997 19:44, Dieter Ringhofer wrote to Yuri Teterin: DR> You write about 200+ systems and their free software but, there're several DR> thousands with already PAID software. Do you want to force some thousand DR> people to throw their 'money' away?? Dieter, even if a sysop has paid for FTS-1-style Fido software, it still CANNOT do Fido-over-IP. So he has either pay more money for a fossil driver w/TCP/IP support, or add free binkd. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #991 [1995] Scn From : Lawrence Garvin 1:106/6018 26 Oct 97 13:07:14 To : Lech Szychowski 27 Oct 97 18:12:06 Subj : IP-connectivity ------------------------------------------------------------------------------- Lech Szychowski said in a message to Jesper Tragardh: > Not only will the sender receive a bounce-message. Probably he we also > se a "original message follows" which includes the whole packet coded in > for instance base-64. LS> Nope. I believe most modern MTAs can be configured to return no LS> more than a given number of lines in a "delivery failed" warning LS> message. And postmasters do that often. Nonetheless.. the mail has been lost. Reason enough, I would think, for not relying upon such technologies -- much less to worry about identifying them in a nodelist. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #992 [1995] Scn From : Lawrence Garvin 1:106/6018 26 Oct 97 12:53:54 To : Denis McMahon 27 Oct 97 18:12:06 Subj : IP-access ------------------------------------------------------------------------------- Denis McMahon said in a message to Ask Bjoern Hansen: DM> It should not be a requirement that a net maintain a nameserver DM> before that net is allowed to contain IP nodes! No... but SOMEWHERE, that node is going to have to be listed in somebody's nameserver in order to get IP service. It matters not who runs the server, the fact remains, it must exist. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #993 [1995] Scn From : Yuri Teterin 2:5030/239 26 Oct 97 15:26:06 To : Dieter Ringhofer 27 Oct 97 18:12:06 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Dieter ! Sat Oct 25 1997 Dieter Ringhofer writes to Nick Soveiko: DR> so i stay compliant with fts-0001 and don't use any other software. Very well. But you should realise that the way your FTS-0001 compliant software use Internet is based at ineffective and unspecificated implementations of basic protocol. So you should be ready that your software will be not able do connect with new software based on new standards and in any case can not _force_ others to be compatible with your software. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #994 [1995] Scn From : Slava Filimonov 2:469/33 26 Oct 97 17:55:26 To : All 27 Oct 97 18:12:06 Subj : mirrors ------------------------------------------------------------------------------- Hello All! binkd/other fido-via-ip related stuff mirrored at ftp://lx.mrp.cz/pub/mirrors binkd: www.doe.carleton.ca/~nsoveiko/fido/binkd/ ftp.prospect.com.ru/FidoNet/Mailers/BinkD/ tts.magadan.su/~maloff/binkd/ ftp.falcon.spb.su/pub/fido/BinkD/ argus fido.ritlabs.com -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #995 [1995] Scn From : Pedro Lima 2:362/21 26 Oct 97 14:18:22 To : Rune Johansen 27 Oct 97 18:12:06 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- RJ> So, we'll see how the nodelist compilers feel about that one? :-) I doubt there will be a problem. However, the TELN flag may be confused with the Txx flag... :-) Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #996 [1995] Scn From : Nick Soveiko 2:5030/23.101 25 Oct 97 08:42:22 To : Rune Johansen 27 Oct 97 18:12:06 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Fri, 24 Oct 1997, 01:31, Rune Johansen (2:210/20) ==> Marco d'Itri: RJ> If you are not a "owner" of the system you are running your node RJ> at, you would need the blessing of the system operator to put up a RJ> daemon on a non-standard port anyway. usually (at least, in my experience) the system is set up to allow binding to ports not occupied by well-known services. this lasts as long as running user daemons do not create any problems, such as excessive system load and/or some kind of illegal activities, such as distributing pirate software. it would be even easier to get permission from sysadmins to run fido services if we could agree on type of these services and prepare an informational rfc. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #997 [1995] Scn From : Marco d'Itri 2:335/680.666 26 Oct 97 22:27:54 To : Slava Filimonov 27 Oct 97 22:25:54 Subj : Re: Proposal for listing as IP-node ------------------------------------------------------------------------------- Slava.Filimonov@f33.n469.z2.fidonet.org wrote: >I meant, i will be a wery useful thing, if you couldn't send mail directly You will never send directly email, that way you would'nt have any reason to use email instead of binkp or telnet. You will always route it trought your provider's server. >dynamic routing across existing static routes. If we add routing discovery >for our fido connections we'll achieve two benefits - mail will be delivered >as I don't think this is useful, and it would be really too much work. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #998 [1995] Scn From : Marco d'Itri 2:335/680.666 27 Oct 97 13:30:54 To : Rune Johansen 27 Oct 97 22:25:54 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >having case-sensitive password checking. And, it assumes that since you have >a TCP session, all transfers are error-free. That is not always the truth. >There Please, be so kind to point me some of such transferts. >should be some kind of CRC32 on the total file that is being transferred, to >check for convertings made by links in the 'net. No conversion is done at TCP layer. >And, the BinkP protocol binds itself to IP. I do not believe in submitting Argus supports binkp over dialup, I suppose this is only a documentation flaw. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #999 [1995] Scn From : Dieter Ringhofer 2:2476/14 27 Oct 97 17:59:52 To : Slava Filimonov 28 Oct 97 05:38:08 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> what you propose is the death of fidonet. SF> That only means death of redundant protocol. fidonet are us, but not some SF> protocol. than i skip zmh with my modems. it's the same for anybody like an ip-only system for a non-ip one. got the point? --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1000 [1995] Scn From : Dieter Ringhofer 2:2476/14 27 Oct 97 18:14:34 To : Dima Maloff 28 Oct 97 05:38:08 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> You write about 200+ systems and their free software but, there're DR>> several thousands with already PAID software. Do you want to force some DR>> thousand people to throw their 'money' away?? DM> even if a sysop has paid for FTS-1-style Fido software, it still CANNOT do DM> Fido-over-IP. that's wrong. i can do so and: i don't need any other software than the one already being set up over here. DM> So he has either pay more money for a fossil driver w/TCP/IP DM> support, or add free binkd. nobody told that software development is for free. i BOUGHT several compilers and i need TIME to write the code. both lead to money. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1001 [1995] Scn From : Dieter Ringhofer 2:2476/14 27 Oct 97 17:56:42 To : Yuri Teterin 28 Oct 97 05:38:08 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> so i stay compliant with fts-0001 and don't use any other software. YT> Very well. But you should realise that the way your FTS-0001 compliant YT> software use Internet is based at ineffective and unspecificated YT> implementations of basic protocol. So you should be ready that your YT> software will be not able do connect with new software based on new YT> standards and in any case can not _force_ others to be compatible with YT> your software. who is listed? the ftn-compliant system or the ip-system? you want to break all rules being valid for every simple node. count nodelist entries, please. fidonet is no common carrier, it has its rules. change the rules or apply as good as possible. this area is for discussions to find a way for it related to listing of ip-nodes. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1002 [1995] Scn From : Marco d'Itri 2:335/680.666 27 Oct 97 23:00:46 To : Slava Filimonov 28 Oct 97 21:41:36 Subj : Re: mirrors ------------------------------------------------------------------------------- Slava.Filimonov@f33.n469.z2.fidonet.org wrote: >binkd/other fido-via-ip related stuff mirrored at Debian GNU/Linux users can get the debian package from ftp.debian.org and mirrors. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1003 [1995] Scn From : Lech Szychowski 2:480/33.7 26 Oct 97 02:42:00 To : Marco d'Itri 29 Oct 97 05:59:44 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > If they locked themselves with non open software is their own problem, > not mine. They didn't. We will if we change standards inconsideratly. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1004 [1995] Scn From : Lech Szychowski 2:480/33.7 26 Oct 97 02:51:00 To : Nick Soveiko 29 Oct 97 05:59:44 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > he's trying to say exactly what he said: by enforcing fts-0001 as a > standard for fido-over-ip, one will actually decrease connectivity > between fidonet systems. ain't that simple? If "connectivity" stands here for "potential connectivity", I support this opinion. But if the whole deal is about "existing connectivity", I dare to remind him it's his fault and his problem that he started using software that was (and still is) not a standard one. If we adopt BinkP because of its advantages I will not say a word against it - but if anyone's gonna raise the issue of "existing installations etc" I shall complain like hell. For the very simple reason: if one can say "my idea is better 'cause I already have it implemented and have been using it for a while", so can I. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1005 [1995] Scn From : Lech Szychowski 2:480/33.7 26 Oct 97 03:05:00 To : Denis McMahon 29 Oct 97 05:59:44 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- > Rubbish. FTP has been used for fidonet data transfer for some time, as > has SMTP. The fact that it is used and it works shows that the problem > you are trying to invent either does not occur, or is not insurmountable. ...or just haven't been happening often enough to be brought to our attention - a situation that may change dramatically with introduction of the large scale transfers. We are not Microsoft, are we? The idea here is to deisgn something that will work certainly, not just hopefully. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1006 [1995] Scn From : David Moufarrege 1:2613/404 27 Oct 97 07:00:46 To : Lawrence Garvin 29 Oct 97 05:59:44 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Lawrence! In a message Lawrence Garvin wrote to Denis McMahon: LG> My FIFTP sessions run totally independent of the existence of any LG> nodelist, as does the inbound and outbound processing of echomail to LG> and from those ftp sites. Therefore, it serves no purpose at all (at LG> least for me) for SMTP or FTP protocol information to be in the LG> -nodelist-. A 100% correct observation! -=David=- _____________________________ | e-mail : david@kraut.xg.com | | FidoNet: 1:2613/404 | | 1:13/0 | ----------------------------- ... Society prepares the crime; the criminal commits it. --- * Origin: Kraut Haus * Rochester, NY * 716-359-0871 (1:2613/404) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1007 [1995] Scn From : Rune Johansen 2:210/20 27 Oct 97 01:13:04 To : Slava Filimonov 29 Oct 97 05:59:44 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >> BinkP uses a TCP connection, so are as vulnerable to timeouts as other >> protocols (or transport mechanisms, if you like) that uses TCP. > But binkd aware of thouse facts. binkd stores info about paritally-received > files and can issue rest command. Name clashes also resolved. BinkD is the mailer. BinkP is the protocol. I say that BinkP is as vulnerable as others running on top of TCP. But, BinkP does not have retransmits or checksums included, so they will timeout. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1008 [1995] Scn From : Lech Szychowski 2:480/33.7 26 Oct 97 03:01:00 To : Sean Rima 29 Oct 97 05:59:44 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- > LS> Of what use is a mailer without a protocol one can use to talk to it? > Some one mentioned that an additional Flag, ie IP:xx could be use to > donate the type of mailer used. We still need to know/define what exactly those flags are going to stand for - we have to describe the protocols in a way strict enough to enable anyone who wants to create his own implementation to do so. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1009 [1995] Scn From : Lech Szychowski 2:480/33.7 26 Oct 97 02:57:00 To : Rune Johansen 29 Oct 97 05:59:46 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- > If you are not a "owner" of the system you are running your node at, you > would need the blessing of the system operator to put up a daemon on a > non-standard port anyway. Nope. Just go above the first 2^10... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1010 [1995] Scn From : Rune Johansen 2:210/20 27 Oct 97 01:16:02 To : Yuri Teterin 29 Oct 97 05:59:46 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> No, I would not necessearily have to use your converter, as long as I can >> get/send the FTS-0001 packets via the BinkP protocol. > But there are infinitely many ways to 'get/send FTS-0001 packets via the > BinkP protocol'. You can with the same effect say 'I would not necessearily > have to use any FTN-over-IP protocol, as long as I can get/send the FTS-0001 >packets via IP' and try then make FTS-0001 session with VModem based mailer. O > cause, you'll fail in this case. As I have stated in my 1st proposal, I have changed a little in my views. I now consider BinkP as a protocol alongside EMSI, FTS-6 and FTS-1 over a raw TCP session. As long as BinkD cannot do FTS-1 fallback, it will not meet the requirements of a Fidonet Nodestatus. If you have a mailer that has got the fallback, you can use it. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1011 [1995] Scn From : Rune Johansen 2:210/20 26 Oct 97 23:32:12 To : All 29 Oct 97 05:59:46 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- Proposal for implementation of alternate transport protocols for the Fidonet community. By Rune Johansen, 2:210/20 (rune@bbbs.net) Date: October 25th 1997 - 1st revision Filename: ipflag.txt Summary This proposal will give my views and suggestion on how to include transport protocols other than normal, PSTN/ISDN based, transport of Fidonet mailer sessions. It will to some extent discuss the different (dis)advantages with some of the ideas. This proposal is to be posted in the IP_CONNECT echo of Fidonet, and may be posted elsewhere, where I or other people see fit. I will assume that people reading this proposal are already aware of how a "traditional" fidonet mailer session is being conducted. +++++ The nodelist specifications today are a bit limiting, and to some extent specific on what type of transport medium a fidonet mailer session are to run on top of. Everything assumes either directly or indirectly that a modem/ISDN session are being used. But, this may not be the fact in the future, and is not true for all mailer sessions today. Broadly speaking, we could see fidonet mailer sessions over a variety of transports, including (but not limited to) Internet Protocol, X25 networks, Proprietary Protocols over a proprietary network, X.400 sessions, X.500 sessions. I will go further into the Internet Protocol parts of this, but I underscore that the possibilities of using other transports. When I talk about fidonet mailer sessions, I talk about the direct connection between two fidonet mailer programs, that exchange handshakes and files. I do not look upon sending files to a email address for extraction there as a mailer session. Almost "everybody" knows that a IP address has got several ports that a program can connect to, to be sure to get the correct type of connection. Examples of programs would be that a telnet client connects to the servers port number 23, as it is a well-known port, to talk to a telnet daemon program, that will welcome your client. The same applies for other types of client programs, as they connect to their corresponding port, to get to their serverdaemon. With ordinary Modem/ISDN sessions, we have only one such "port" available, and the different protocols that are to be available have to autodetect what type o f client there is trying to connect. This is usually being done by trying to detect a "highest common protocl", with fallback to other, less favourable protocols. By definition in the fidonet policy, this "last protocol of resort" is the handshake and file transfers described in FTS-0001. By using this method of autodetecting, we do not use flags in the nodelist to denote what type of handshake that is supposed to be used. The three protocols that are being used over modem/ISDN sessions today (to my knowledge) are: FTS-0001, FTS-0006 and EMSI. Additionaly there are tests going on using BinkP as modem/ISDN handshake protocol, in addition to the three protocols mentioned. As already pointed out, a IP connection can utilize different port numbers for different handshake protocols, but there is no hindering in autodetecting these as well (as are being done in the modem/ISDN sessions today). For those who asks: Yes, BinkP _can_ be autodetected, but will require a more leniant way of implementation to the clients. To accomodate for future connection technologies, the "phone" field in the nodelist should be redefined to a "address" field. This "address" field would then be used as the connection identifier for a fidonet mailer to connect to, to get a mailer session running with another fidonet mailer. This address would be a phone number, a IP address, a fully qualified domain name, a X.25 address, a X.400 address, and so on. To make a mailer using one type of transport medium to recognize another type of compatible medium, we would need some kind of flag that denotes what kind of address is contained in the "address" field of the nodelist. My suggestion is that ordinary modem (PSTN) addresses does not use any such flag, so it would be the default type of transport. ISDN transports already have their own flags (V110L, V110H, V120L, V120H, X75, ISDNA, ISDNB, ISDNC and probably some more). For connections using an IP address or a fully qualified domain name (FQDN) I suggest that we should use IP as flag. For other types of transports, these flags should be proposed later, but should not crash with existing flags. For example, a X.25 address could use a flag called X25 to denote address type. Some transport mechanisms have the possibility to carry other transports at the same time, transparently. An example of this would be that ISDN nodes can have the possibility to support analog modems too. Then we would use both ordinary modem flags, and ISDN flags on the system at the same time. IP addresses are fundamentally different from modem/ISDN transports, so they would not be able to co-exist in this proposal, and would therefor be listed as different nodes in the nodelist. This also means that a IP-only node would have no difficulties being listed in the nodelist. Now, over to the IP specific flags. I have already stated that we should use a flag that denotes that the address in the nodelist is a IP address, via the IP flag. For exchanging a handshake between two mailers, we must tell the caller what transport protocol should be used. The protocols discussed in IP_CONNECT are: Telnet (capable of carrying several handshake protocols) Raw TCP (capable of carrying several handshake protocols) VModem (proprietary protocol of Ray Gwinn's SIO package, capable of carrying several handshake protocols) The handshake protocols used over these are: FTS-1 FTS-6 EMSI BinkP The BinkP protocol is being looked at as a separate protocol, even though it is no different from any of the other protocols over a raw TCP session. This is important to remember, when I discuss this protocol later in this document. Several people have suggested different wording of the flags for the transport protocols, and I will do my best to keep everybody confused, by adding my own suggestions (but I will also explain _why_ I don't use what everybody else wants to use). Telnet - IPT - default port number 23 Why not use TELN or TEL? Well, since we already are using Txy falgs to denote mail hours in the nodelist, there will be a great danger that this flag would be parsed incorrectly. By using IPT, it will be unique, and would keep the software authors focus on the importance of parsing correctly. Raw TCP - IFC Why not use TCP? Why use IFC? Well, the TCP part is easy, look at Telnet explanation :-) Why use IFC? ifcico were the first mailer to my knowledge using a raw TCP session for exchanging FTS-1/FTS-6/EMSI session handshakes. That's why. If it is arguable, we could use IPR (IPRaw), just like IPT (IPTelnet) VModem - VMO - Default port 3141 Since the SIO package is widely used amongst OS/2 based BBS systems, and SIO has the possibility to have it's own, encrypted, virtual modem transport, the nodelist should denote this directly. I am fully aware of the possibility for using VModem as a telnet server, but then the IPT flag would correctly denote that capability. Maybe we should consider IPV (IPVmodem)? "What about BinkP then?" will some people certainly ask. Well, BinkP is a session handshake/file transfer protocol, running on top of a raw TCP session. It is NOT a transport protocol. It is swimming alongside EMSI, FTS-6 and FTS-1. The only difference is that current implementation of BinkP (in the BinkD 0.9.1) is not capable of falling back to other protocols, like EMSI, FTS-6 or FTS-1. In a IP world this is not too important, as the fallback can be done to another port, running a mailer capable of this. Let's have some thought experiments here: A node running BinkD would like to run a BINKP or BND flag to denote it's capability. This means in straight words: I run a RAW TCP mailer, capable of ONE PROTOCOL ONLY, and that's BinkP. (At least in current implementations of BinkD) So, if I run a raw TCP mailer capable of EMSI only, I would like to run the flag EMSI to denote that: I run a RAW TCP mailer, capable of ONE PROTOCOL ONLY, and that's EMSI. To accomodate the demand of a BINKP/BND flag, we must also allow for other mailer handshake flags, like FTS1, FTS6 and EMSI. These three protocols are already widely autodetected with fallback to FTS1 in most mailers, so the BinkP should not be considered a special case, as it is easily autodetected too. This is the reason for me NOT including BINKP as a own flag in this proposal. Now, we can turn our attention to the three protocols that _are_ different transport protocols. For nodelist examples, these will show what I mean: ,Number,Name,Loc,SysOp,Address,Baud,Flags One example of a node running at address 1.2.3.4, with various protocols on their default port numbers: ,1,BBS,Here,SysOp,1.2.3.4,300,IP,IPT,VMO,IFC One example of the same node, running the raw TCP at port number 24554: ,1,BB,Here,SysOp,1.2.3.4,300,IP,IPT,VMO,IFC:24554 The same node, running telnet protocol on port 1024, and VModem at 1025, and raw TCP on port 61234: ,1,BBS,Here,SysOp,1.2.3.4,300,IP,IPT:1024,IFC:61234,VMO:1025 As you can see, I suggest denoting non-standard port numbers as a parameter to the protocol flag, separated by a colon. The spec would be like this: Flag[:portnumber] The Baud field is something I have not considered at all, and is kept there for compatability reasons. When policy will let the requirement of being FTS-1 capable, I will suggest a way of denoting what handshake protocol is available at which port. As I said before, in the IP world, you can fall back to another port, if the port you have connected to does not do FTS-1 or another protocol that you can handle. Wether this should be a IFC or a IPT session port, I will not discuss here. I only say it is possible to do this in the IP world, but maybe not in other forms of networks (like modem/ISDN or X.25 or X.400 or X.500 or...) So, to summarize it all: IP - denotes IP address in address field. Uses the following transports: IPT[:portnumber] IFC[:portnumber] VMO[:portnumber] --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1012 [1995] Scn From : Lech Szychowski 2:480/33.7 26 Oct 97 03:12:00 To : Rune Johansen 29 Oct 97 05:59:46 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > The basis question is still valid: Should the IP nodes have at least one > protocol in common? Are you seriously afraid that not everyone agrees with this statement? Well, if your doubts are true we are in big trouble... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1013 [1995] Scn From : Chris Maddock 3:640/302 27 Oct 97 22:49:04 To : Marco d'Itri 29 Oct 97 05:59:46 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- On 21 Oct at 20:10, Marco d'Itri of 2:335/680.666 wrote to Chris Maddock: Md> Chris.Maddock@f302.n640.z3.fidonet.org wrote: >>The standard may have to be changed anyway so we may need to implement a set >>of standards to follow or insist that the old standards can be used if they >>are already sufficient. >>I suspect they are already sufficient but have not been followed. Md> I agree. The only problem is with makenl, and this could be easily resolved Md> by patching NLMake. What we really need is the source code for MAKENL and/or NLMAKE. David Nugent made a nice nodelist program that addresses many of the problems in MAKNL, =and= the source code is available. Md> Sadly I don't think we will ever agree on a common nodelist format, in R33 Md> we will experiment with the generation of multiple nodelist formats (for Md> binkd, BT, etc) from a master extended nodelist. I have nearly finished Md> the software (some perl scripts), but looks like italian IP sysops are not Md> interested about that, they didn't even sent me their nodelist entries. >>Yes. I saw it a couple of days ago. Looked good. I am a little purturbed as >>to the large number of flags though. Md> I don't think we can avoid that. Ways to cut down the space are needed I feel. I suggest a bit-code for the different protocols and capabilities may be the answer and while it is not easily machine readable, it holds great promise. The day will come where we will need to go to a binary nodelist. I dread the day, but I also think it is inevitable. Regards, Chris Maddock chrism@bbs.st.net.au --- Msged/386 4.20 beta 2 * Origin: Diagnostic CBBS - DownUnder - (3:640/302) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1014 [1995] Scn From : Chris Maddock 3:640/302 27 Oct 97 22:54:02 To : Pedro Lima 29 Oct 97 05:59:46 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- On 20 Oct at 04:51, Pedro Lima of 2:362/21 wrote to Chris Maddock: PL> Hi, CM>> Good question. If I don't put any translation in. it would CM>> dial: CM>> 0015-000- PL> Ok. This isn't surely a valid number, so a distracted sysop would not PL> inconvenience somebody attempting to dial an IP address. Correct. The only problem may be with a new node incorrectly setting up their software. CM>> Yes. And if the noelist compiler authors made the baud field able to CM>> take any integer from 0-65535 PL> Yes, but since that would be similar to change the nodelist format, we PL> can take the broader view and solve also a lot of other problems as PL> well, like eliminating the need for several akas... And I'm not talking PL> exclusively about the IP situation. Okay. You are referring to hubs, *EC's etc I guess ?? CM>> Fair enough. IP as the first flag followed by a comma delimited CM>> indication. Whilst this would be easily human readable, it could take CM>> a lot of room. Not that that is really a huge problem. PL> Actually, there's a length limit on the whole of the flags. If we're PL> going to list non-standard ports for several services this may be a PL> problem, but then again, if we use a separate nodelist entry to declare PL> IP capability, the risk of exceeding this limit would be minimized. Yes. That may be the solution. I would consider it a poor solution and other means may be preferable. CM>> Our biggest problem IMHO, is that the mailers we use and love so much CM>> (with good reason I might add) have to support whatever we compile CM>> with the compiler. CM>> For this reason I would love to see something like regional DNS's to CM>> resolve addressing and routing. I am also aware that this is apparently CM>> being addressed in another thread but some of the discussion is way CM>> over my head. PL> I understand. However, limiting the possibility to a specific FQDN PL> (such as one in the fidonet.org hierarchy) is precisely that, a PL> limitation. Yes. But Fidonet only =is= a limitation. We are proposing to add the internet to our capabilities. Or is that what you meant ? PL> I really don't know how nodelist compilers would behave with a FQDN in PL> the phone field, but it smells trouble, so perhaps we can compromise. If PL> an IP node can list its IP address, the phone field is used. If the IP PL> connectivity can only be assured via a FQDN (such as dynamic IP PL> situations), then '-Unpublished-' would appear in the phone field, which PL> I believe doesn't imply the entry to be Pvt, and the system name field PL> would contain the FQDN. This would make for existant IP mailers to PL> successfully call most of the IP nodes, and newer software may look into PL> the system name field for the FQDN if: A FDQN in the phoneNumber field =is= trouble - at the moment. Your second suggestion sounds fine. PL> - The entry is not Pvt PL> - The entry declares IP capability PL> - '-Unpublished-' appears in the phone field Yep. PL> For the sysop having an IP address, nothing stops him, if he wants to, PL> to list its FQDN together with the IP address. This could be useful when PL> the IP address has changed but the change has not yet reached the PL> nodelist (and the FQDN remains the same), but this possibility would be PL> left to the discretion of the sysop, not forced to him. Good. CM>> I =do= want to see Fidonet survive and run as an alternative to the CM>> Internet newsgroups, and also to be a non-commercial alternative to CM>> same. PL> FidoNet already is such an alternative, but one of its major problems is PL> that it didn't know how to evolve to accomodate new and cheaper PL> technologies. ISDN helped, but I feel we need to go much farther. Agreed. We are only now trying to change and develop forward thinking whilst retaining the present "flavour" of Fidonet. Seeing the amount of discussion here is great ! In the words of the Z3C, Fidonet is an experimental network. To cease experimenting is fatal and we came close to dying. CM>> I see the IP issue as the gateway to this end and it will also give CM>> Fidonet =back= to the amateur hobbiest at very little or even no cost CM>> and a huge return in benefits. PL> Again we agree. :-) Lets see what we can do to help. Regards, Chris Maddock chrism@bbs.st.net.au --- Msged/386 4.20 beta 2 * Origin: Diagnostic CBBS - DownUnder - (3:640/302) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1015 [1995] Rcv Scn From : Chris Maddock 3:640/302 27 Oct 97 22:39:06 To : Lothar Behet 29 Oct 97 05:59:46 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- On 20 Oct at 08:03, Lothar Behet of 2:2446/301 wrote to Chris Maddock: LB> Hello Chris! LB> On 19 Oct 97 wrote Chris Maddock to Marco d'Itri: >>>> 2. Flags. A series of flags to indicate that a node is IP (or >>>> whatever) capable. Md>>> I have seen a good proposal in this echo. LB> Flag space may be saved if there would be a combined flag, which defines LB> IP-capabilities like this Example: LB> ,301,fido.nrh.de,Uedem_FRG,Lothar_Behet,49-2824-922240,9600,CM,XA,V34, LB> U,X75,IPC:11 LB> Conventional flags stay obviously as is. Okay. Should work too. Neat. Saves space. LB> IPC advises the nodelistcompiler to use the node_name as valid ip address LB> and gives information (in deciaml or hexadecimal form) about capabilities LB> according to a key table: LB> 1 Telnet LB> 2 Vmodem LB> 4 Ifcico LB> 8 BinkP LB> 16 FTP LB> 32 ... to be continued ... Yep. Thats the way. LB> This table may contain up to 32 different protocols, which would consume 4 LB> (hex) to 5 (decimal) bytes of flag space. 64 possiblities would need 8 byte LB> in hex-notation. I'd say we will need more than 32. We may have to make it bigger right from the outset - but how big ?? A Double-4byte word may be the answer here. LB> As nodelist compilers have to be modified anyway to allow parallel LB> processing of ip and conventional data, it would not be such a problem to LB> teach them this protocol table additionally (it should be handled LB> configurable). Yes. I think it would be easy to code for. LB> At the same time this would not cause any conflicts for conventional nodes LB> and save a valuable amount in distribution size. Thats the aim. Good. LB> The only disadvantage for human readers is the bitwise translation to a LB> dedicated protocol. Yes. I guess we can't always have it perfectly human-readable. At least a simple table can resolve any questions. CM>> Yes. I saw it a couple of days ago. Looked good. I am a little CM>> purturbed as to the large number of flags though. LB> If we are talking about the same sample, then this one should be much LB> better. I'd say we are. The proposal was great though. Well thought out and proffessional appearing. A little bit of fine tuning is fine though. Md>>> Compilers should just accept a longer flag field and an FQDN in Md>>> the phone field. LB> Unlikely there are many different compilers working in the wild, which LB> surely have different capabilities and some may be quite special for a LB> dedicated software and operating system. So we should search on short term LB> for a solution with as less deviance from the known data (and amount), that LB> is possible. Okay. Are we going for maximum compatibility woth broken software or are we after compatibility with what the software =should= be ?? >>>> 6. We may even have to look at a different type of nodelist - binary >>>> perhaps ? Md>>> You should read my extended nodelist proposal, I will attach it by Md>>> email. CM>> Got it Marco. ... CM>> It looks good from what I saw so far and shows a lot of thought CM>> and professionalism. You are to commended. LB> That is the long term solution. Yes. While I don't look forward to it, I guess it is inevitable. I'm sort of attached to the human readable form. It's just so damned big and cumbersome. Regards, Chris Maddock chrism@bbs.st.net.au --- Msged/386 4.20 beta 2 * Origin: Diagnostic CBBS - DownUnder - (3:640/302) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1016 [1995] Scn From : Amir Shabashvili 2:5049/12 27 Oct 97 09:57:52 To : Slava Filimonov 29 Oct 97 06:04:08 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello Slava! Replying to a message from Slava Filimonov to Amir Shabashvili: SF> Even dial-up/and all other non-ip fido nodes or points can be granted SF> the IP-capable fido node. As soon as alternative 24h ( fallback ) SF> mail exchanger(s) can be found for such node. You'll still have SF> ability to send them mail. but not directly. And this should be done SF> transparently. The only thing remains, that such node can't ( or can SF> but not 24h ) accept direct connection. LETS assume we do have SF> protocol, which can forward file or file request. Then is there is a SF> problem with contacting any fido-ip system indirectly ? We have't such protocol.We have't protocol or mechanism like sendmail(MX) for fido netmail you describe us. So we cann't use this scheme when we construct ours nodelist. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1017 [1995] Scn From : Pedro Lima 2:362/21 27 Oct 97 04:33:28 To : Rune Johansen 29 Oct 97 06:04:08 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- RJ> The basis question is still valid: Should the IP nodes have at least RJ> one protocol in common? FWIW, and IMO, no. The technology allowing the existance of IP nodes in FidoNet should be regarded for now as experimental. If a standard proves in practice to be needed, then we can address the subject with a knowledge base impossible to foresee presently. On the other hand, if it doesn't, then the issue is irrelevant and the regulations would need to be altered or extended (namely Policy or FTS-1) in a way coherent with practice. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1018 [1995] Scn From : Lawrence Garvin 1:106/6018 27 Oct 97 21:24:08 To : Rune Johansen 29 Oct 97 06:04:08 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Rune Johansen said in a message to Lech Szychowski: RJ> It would be the same as a non-secure session uploading a pkt-file RJ> with the same name as a pkt-file already lying in the inbound RJ> directory of the mailer. How does the current mailers treat that? RJ> Do they overwrite the file, or do they rename it? Good question, actually. I should do a test on that. I know that the mailers will rename -archive- files, but I've not observed what they'll do with PKT files.. hang on while I do a test with Binkley XR5. [ * * * some time later ] It goes like this.... I created a 006a2055.CUT file (which was a legit PKT file) being addressed to my node 106/8277. When it was received by 106/8277, the file was -renamed- upon receipt, so the name 006a2055.PKT is not necessarily the inbound PKT name. I also copied the same *.CUT file to a file named 0B404DA9.PKT, listed it in a Binkley FLO file (006a2055.CLO), and sent it. I then repeated the above transfer of those two files, both named exactly the same. The 006a2055.CUT file was given a whole new name on the inbound side (apparently this naming is date/time related); however, the 0B404DA9.PKT file was -refused- by the mailer as it was "already here". --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1019 [1995] Scn From : Lawrence Garvin 1:106/6018 27 Oct 97 21:35:04 To : Rune Johansen 29 Oct 97 06:04:08 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Rune Johansen said in a message to Lech Szychowski: RJ> I do not know if a PUT command also sends filesize with as RJ> parameter. If it does, a FTP daemon can draw conclusions based on RJ> those facts. I alsoo do not know if the FTP daemon has got the RJ> capability of issuing a command back that requests a transfer from RJ> a specific offset. I know that FTP clients can do it, but the other RJ> way around? By definition, a PUT command sends -no- information, merely a byte stream. The premise of FTP is that the filesystems are totally independent, therefore any information that might be filesystem dependent, such as file sizes (some systems store size according to sectors used, others store actual byte counts), create/modify/access times, and file attributes (read/write/archive) is not sent -- nay, -cannot- be sent. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1020 [1995] Scn From : Nick Soveiko 2:5030/23.101 26 Oct 97 12:16:38 To : Kim Heino 29 Oct 97 06:04:08 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sat, 25 Oct 1997, 12:49, Kim Heino (2:222/0) ==> Nick Soveiko: KH> Or, do considerer FTS-001 over raw socket as the minimal KH> requirement? afaik, only ifcico is capable of doing this. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1021 [1995] Scn From : Nick Soveiko 2:5030/23.101 26 Oct 97 12:50:28 To : Rune Johansen 29 Oct 97 06:04:08 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sat, 25 Oct 1997, 12:36, Rune Johansen (2:210/20) ==> Nick Soveiko: RJ> The whole discussion around FTS-0001 came from a suggestion that RJ> there should be at least one common protocol for IP nodes. see my reply to dieter on the prerequisites of this. my opinion is: common protocol for ip-only nodes, and this protocol to be binkp. RJ> Many people said that the obvious protocol should be BinkP, since RJ> there already are hundreds of nodes in fidonet using it. I then RJ> argued with that if we are to follow policy, then this protocol RJ> should be capable of carrying FTS-0001 handshake. Then it has been RJ> argued that this is a ridicolous solution. i second the ridiculousness. RJ> So, FTS-0001 over BinkP is not a solution. it is 100% politically correct and at the same time 100% ridiculous solution. RJ> But, FTS-0001 is a solution over a telnet connection, or a raw IP RJ> connection. fts-0001 over telnet or over raw ip is just *a little bit* less ridiculous than fts-0001 over binkp. RJ> It is not a solution over SIO's VModem, since it has got a RJ> proprietary protocol, and would not be implemented on too many RJ> platforms, or would not be accessible on too many platforms. agree on this one. RJ> The basis question is still valid: Should the IP nodes have at RJ> least one protocol in common? this falls into a political question: should ip-only nodes be allowed in the nodelist? RJ> For BinkP capable nodes this would not be any problem to implement, RJ> as they would use the listening port, autodetect BinkP vs. RJ> FTS-0001, and have a session accordingly. sorry for repeating this, but it won't be a technical problem only. for some nodes that's going to be a monetary/legal problem. RJ> I really hope that the Standards Proposal will be more thoroughly RJ> documentetd than the BinkP specs that have been posted here, and RJ> that is available on the web. i am doing my best, but i have a fulltime job besides this ;). i hope it to be documented at least as good as the existing fts and having way more possibilities for extension than them. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1022 [1995] Scn From : Nick Soveiko 2:5030/23.101 26 Oct 97 13:12:00 To : Dieter Ringhofer 29 Oct 97 06:04:08 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sat, 25 Oct 1997, 07:05, Dieter Ringhofer (2:2476/14) ==> Nick Soveiko: DR>> You write about 200+ systems and their free software but, there're DR>> several thousands with already PAID software. NS> several thousands ip-capable nodes? you must be kidding! DR> oh well... i mean several thousands of FIDO nodes. ip-systems DR> want to be listed in a ftn-nodelist. so, tell me why should they be DR> listed if they don't have the capabilities needed to become a DR> member of the club? which improvement takes place for the ftn? DR> they can participate at the net without being listed (and do it DR> since long time) but they can't get membership according the rules DR> if they don't fullfill the rules. IF they are listed without it, DR> f.e. I could ignore ZMH and every other 'order' from policy with my DR> already listed lines. DR> such a listing leads to a can of worms therefore be carefull when DR> trying to get rid of something. if one wants to destroy fidonet, he DR> ignores it's rules. ok, let's put it straight. consider 3 types of systems: 1) systems having only pstn connectivity (i mean analogue plain old telephone service, not isdn) 2) systems having both pstn and some kind of ip connectivity (not necessarily 24/365) 3) systems having only ip connectivity (24/365) systems (1) got together a long time ago, when they were in 100% majority, and decided that each and every of them should support fts-0001. fine. i'd prefer fts-0001 to be replaced with emsi these days, but here is not the place to discuss it. for systems (2) i don't really see any problem at all. on the pstn side they support the protocol chosen by nodes (1). on the ip side they are free to support whatever they want, as this is an *additional* capability for them. it's obvious that for system (1) there's *no way* to directly connect to system (3) in absolutely the same way as now there's no way for a pots-only node to connect to an isdn-only node. therefore, it makes no sense to force systems (3) to support the same protocol systems (1) communicate to each other. so it's quite natural that some of the systems (3) together with participating systems (2) get together and develop a protocol that's convenient for interconnection between them, i.e. simple, efficient, robust, secure and flexible protocol. they propose this protocol as a standard for communication between systems (3) and ip side of systems (2). this proposal is backed by free portable software and open specification. some (2) systems say that they don't have half an hour to spend installing this new software and propose as a standard protocol (1) with some emulation software that enables it over tcp/ip. this emulation software is not 100% free and protocol (1) is er, far from being robust and efficient when used over trcp/ip. that's the situation we have today. now let's see what's happening on the political side of the game. today having node (3) in fidonet is formally illegal, unless one convinces the coordinator to have a pvt entry. now, if fidonet coordinators keep ruling systems (3) out of the nodelist, than the issue is closed right away. there is nothing to argue besides specific techniques to get some new flags into the nodelist. *imho*, *that* fidonet is doomed. in 2 years zone 1 will be gone for good and in 5 years 90% of zone 2 nodes will be from regions 44-51, with their sysop population start declining as well. have a look at the nodelist statistics if you don't agree. you say, there's no point in including systems (3) in the nodelist as nodes (1) can't connect them. yes, they can't connect directly, but availability of tcp/ip increases at enormous pace. right now there are already cases when getting some kind of ip connectivity for a system (1) is cheaper than getting pstn connectivity for a system (3). and i see this trend to progress tremendously during the next few years with the number of (3)-capable systems increasing. yes, there's nothing but their very own goodwill that can *force* systems (1) to get this connectivity. again, even now nothing but their own goodwill can force people to spend their own time and money to participate in fidonet. disclaimer: the views expressed above are of myself only. DR>> Do you want to force some thousand people to throw their 'money' DR>> away?? NS> nobody said this. you can keep using it in the same way as before. DR> so i stay compliant with fts-0001 and don't use any other software. please, feel free to do so. DR>> What about trying to find a solution fitting both needs? NS> i most sincerely agree. what i propose will cost you nothing except half NS> an hour of your time. DR> what you propose is the death of fidonet. arguable. NS> what you propose will cost somebody else a perspective of legal NS> problems. DR> i know about your problems but, believe me, it wasn't that cheap DR> and easy to have a separate line or even a modem some years ago DR> over here as well. you don't need to explain this to me. i've been living in both (east) and (west) and i believe i know problems of both worlds and compare them ;). you've now got telecom demonopolisation in germany and the situation is going to improve to the same degree as it did in canada 5 years ago and in usa 15 years ago. DR> even sending some registration fee to u.s.a. brought very often DR> more money to the banking institute than to the programmer. but it never was illegal and you never had to travel a few thousand kilometres to the nearest bank doing such things, right? DR> internet access is still expensive over here, a modem is normally DR> needed for it. (assuming modem is needed in any case) what is cheaper for cm in germany now: to get a second phone line or a unix shell account? DR> today you're in opposit position - cheap internet access without DR> need of a modem (no phoneline -> no modem). what's really amases here me is the fact that it's happening almost simultaneously on both sides of the globe - in ottawa, canada and moscow, russia. i am sure, germany won't lag behind for too long. DR> fidonet is basing on possibility of direct connects, so, which DR> number has to be dialed to connect an ip-system? the number of your local isp. DR> don't you see the real differences and the real need to find DR> something in between to have a workable solution?? but enforcing fts-0001 support for ip-only systems is not going to improve the situation in any way as they still won't be able to connect directly to pstn-only systems! DR>> binkP/D is free and available in source. Why shouldn't there be an DR>> extension according FTS? NS> afaik, one of the subscribers of this echoconference actually started NS> doing it (i mean, fts-compliant free fido mailer). it proved to be just NS> unworkable. as a result, a new protocol was developed and NS> implemented and fts was abandoned for good. DR> and so should whole fidonet do now? the whole fidonet has a choice now. DR>> And: My time is my money as well, some spare time is good for my DR>> health... NS> it took me half an hour to install binkd. DR> those 30 minutes spare time per day (which are not given every day) you're not going to install binkd every day. believe me, it's a pretty robust daemon and not windows/95 ;) DR> i use to read and write some mails while having breakfast (have a DR> look at the timestamp). i very much appreciate your willingness to discuss this matter at the risk of spilling coffee on the keyboard ;) i've even offered you compensation for your moral damages arising from missing a breakfast ;). i am sorry, but flying over to germany, installing binkd for you and coming back would be kinda too expensive for me at this time. if you can give me login at your system, i can do it remotely. what else can i do for you? DR> my ftn-system works fine, why should i change something for DR> internet?? there's no reason for you to do anything besides your goodwill to communicate with other people. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1023 [1995] Scn From : Nick Soveiko 2:5030/23.101 26 Oct 97 15:59:42 To : Yuri Teterin 29 Oct 97 06:04:08 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sun, 26 Oct 1997, 15:21, Yuri Teterin (2:5030/239) ==> Lech Szychowski: YT> Because nobody could explained that kind of such 'fallback' is YT> expected (if we want not just to fulfill the requirements of Policy YT> but to improve the connectivity between FIDO-nodes). i think that improving connectivity between fido nodes is *the spirit* of policy. disclaimer: this is my own personal opinion. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1024 [1995] Scn From : Nick Soveiko 2:5030/23.101 26 Oct 97 21:46:50 To : Rune Johansen 29 Oct 97 06:04:08 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sun, 26 Oct 1997, 02:19, Rune Johansen (2:210/20) ==> Lech Szychowski: RJ> only BinkP/1.1 spec I have found is written in russian. I do not RJ> understand russian, so if someone would be so kind to translate it, RJ> several people would be happy. i think we've clarified this by email. RJ> About the password things in BinkP: RJ> There is not mentioned anywhere in the specs that if you have no RJ> password, you should use "-" as password. Only found this by RJ> looking at the source of Binkd 0.9.1. i'll check this. thanks for pointing out. RJ> And, there could be lots of misunderstanding in the password RJ> routine, by having case-sensitive password checking. this is documented in binkd user guide, . i am still not sure if this should be a part of a formal *session* layer protocol specs. RJ> And, it assumes that since you have a TCP session, all transfers RJ> are error-free. binkp mailers are around for about a year now. my top of the head and *very conservative* estimation is that about 500-1000 gigabytes of files have been transferred around the globe using this protocol. i am not aware of any evidence that this assumption is not true. RJ> And, the BinkP protocol binds itself to IP. I do not believe in RJ> submitting protocols as an FSP that requires a special layer to run RJ> on top of. There is nothing wrong with using BinkP over a modem RJ> connection, except for the errorchecking part. binkp has been implemented in argus as an over-modem protocol as well. the error correction part is taken care of by means of proprietary underlying hdlc-like datalink protocol. i hope to include description of this as an appendix on binkp implementation together with the emsi/fts-0001 fallback procedures. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1025 [1995] Scn From : Nick Soveiko 2:5030/23.101 26 Oct 97 21:44:38 To : Lawrence Garvin 29 Oct 97 06:04:08 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Sat, 25 Oct 1997, 13:09, Lawrence Garvin (1:106/6018) ==> Nick Soveiko: LG> As for free.... well... I don't recall anybody, anywhere, ever LG> promising that Fidonet or FTN-compatible software would be free. [skipped a bit of wisdom] LG> Nick... if I were to speculate... I'd speculate that probably 2/3 LG> of the VModem on OS/2 implementations along with the SIO supporting LG> them are already running 'unregistered' -- and will probably LG> continue to do so thru eternity. that's exactly the reason i'm spending my spare time supporting a gnu project - binkd. i feel myself uncomfortable running the stuff 'unregistered' and i do not want to encourage other people running it in that way. by means of avoiding commercial/shareware whenever possible. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1026 [1995] Scn From : Lawrence Garvin 1:106/6018 27 Oct 97 21:37:18 To : Rune Johansen 29 Oct 97 06:04:08 Subj : Flags in nodelist ------------------------------------------------------------------------------- Rune Johansen said in a message to Lech Szychowski: RJ> I think you are correct here. If you question a root server RJ> (authorative for the . domain) and it tells you that the fido. does RJ> not exist, you have no reason for going to the next root server to RJ> try it again. If you should go to the next one, regardless of the RJ> answer from the first one you contact, there would be no use of RJ> distributing the autority of the root domain on several root RJ> servers. After some thought on this matter, although not actually testing it, I will concede this point. In fact, I vaguely recall making that statement some time ago in another echo (perhaps TCPIP, and being wrong that time as well ). What -will- work, though, is for such a site to setup a caching slave server, and download -both- zones into a single server, and use that server as the resolution point. (I think. ) RJ> I would believe that it would only go to the next one in line, RJ> after a (configurable) timeout on the query to the first one. Yes, I believe that is, in fact, the correct situation. The second nameserver is only queried -if- the first listed nameserver is unavailable, not if it return a "no RR answer". Oh well.... so much for that idea. :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1027 [1995] Scn From : Nick Soveiko 2:5030/23.101 26 Oct 97 12:31:30 To : Dieter Ringhofer 29 Oct 97 06:04:10 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Sat, 25 Oct 1997, 05:45, Dieter Ringhofer (2:2476/14) ==> Nick Soveiko: DR> tcp provides reliable point-to-point services (compare it with UDP) DR> but, it isn't all you need. yep, it's not all. what you need is (1) reliable service (2) stream-oriented. tcp/ip provides both. it's also connection-oriented, bit we don't really care about that. NS> do you know many of them? DR> not many but, i know several tcp/ip implementations ;) does any of them lack reliable and/or stream-oriented performance? NS> ok. tcp/ip is a reliable, stream-oriented, connection-oriented protocol. DR> every stream-oriented service is unreliable (even NFS). f.e. in DR> dependancy of protocol you're using frames might be lost for ever DR> and / or sequence at receiver's side is not according the sending DR> sequence. this can result in bad files (f.e. .zip with DR> some bytes in wrong order or missing bytes). to get things straight DR> retransmission is necessary than. this message i'm writing right now will be delivered to you by means of binkp over tcp/ip. binkp has *neither* error control, nor packet sequence recovery. if tcp/ip is not a reliable and/or stream-oriented service (as you seem to claim), you won't be reading this. if you do, either something is wrong with your arguments or my english is not good enough to understand you. elaborate, please. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1028 [1995] Scn From : Lawrence Garvin 1:106/6018 27 Oct 97 21:43:42 To : Yuri Teterin 29 Oct 97 06:04:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Yuri Teterin said in a message to Lech Szychowski: YT> Will you be really satisfied if any binkp-node will be able to YT> support FTS-0001 over raw TCP? Yes! YT> Taking into account that this will not improve its connectivity YT> with IP-fossil based nodes (those can not work over raw TCP) and YT> so will improve its connection with ifcico only (but ifcico-based YT> nodes have now no problems with binkp - they just run additionaly YT> binkd and are happy). Yuri, the ifcico IP-fossil based nodes will also have to address this minimum capability as well. YT> As to FTS-0001 over telnet - can you explain, what is the YT> advantage of telnet against any over protocol (keeping in mind YT> that it is not effective as the transport and require extra YT> processor resources, and there is no specifications on using YT> telnet as transport protocol for FTN-session)? The IP protocol is irrelevant. The point is that the -mailer- must be able to negotiate an FTS-0001 session over ANY PROTOCOL that is chooses to 'answer' on. Just as with a PSTN connection, it is irrelevant whether it is X.75, V.34, V.22bis, HST, or whatever, it -must- offer a fallback option to FTS-0001. That is all that is expected for any mailer working over telnet, vmodem, vmp, raw, etc. YT> As far as I understand the only reason that it is supported now is YT> its implementation in Vmodem - but how long should we be the YT> slaves of (ineffective and unspecificated) decisions of the author YT> of Vmodem? I think you miss the point. The only reason 'vmodem' is in the discussion is because it does allow a standard PSTN FTS-0001 mailer to function across IP connectivity. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1029 [1995] Scn From : Lawrence Garvin 1:106/6018 27 Oct 97 21:47:36 To : Yuri Teterin 29 Oct 97 06:04:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Yuri Teterin said in a message to Rune Johansen: YT> Hello, Rune ! YT> Sat Oct 25 1997 Rune Johansen writes to Nick Soveiko: RJ> The whole discussion around FTS-0001 came from a suggestion that there RJ> should be at least one common protocol for IP nodes. YT> This is desirable but not necessary. It most certainly -is- necessary, Yuri. It's -mandated- by Fidonet Policy 4, and until you can get enough RC's to agree to drop that FTS-0001 requirement from Fidonet Policy 4, -WE- have no choice in the matter. YT> Is we decide to use flags like IFC, BNP, VMP in nodelist, each YT> node can calculate all common protocols for destination node and YT> make the call at most appropriate one. Yes, but please do not confuse COMMUNICATIONS PROTOCOL with FIDO MAILER SESSION. Protocol is things like V.34, X.75, HST, vmp, telnet, ftp, etc. Sesssion is things like FTS-0001, FTS-0006, EMSI. Session works independently of Protocol, and a given session should be available on -all- protocols supported. Protocols are listed in the Flags field of the nodelist. Session is something mandated by policy and Fidonet Technical Standards. The two are not the same thing. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1030 [1995] Scn From : Pedro Lima 2:362/21 27 Oct 97 05:26:00 To : Nick Soveiko 29 Oct 97 06:04:10 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- NS> you've never seen packets to a system across the NS> street going via amsterdam, or even better, mae-east in new jersey, NS> did you? FWIW, I've seen it happen for a system in the same room. NS> from this point of view, it makes sense for me putting fqdn in NS> location field. By that point of view, it makes much more sense to put it in the phone field, since the phone numbering system usually corresponds with the PSTN topology. :-) Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1031 [1995] Scn From : Pedro Lima 2:362/21 27 Oct 97 04:57:06 To : Marco d'Itri 29 Oct 97 06:04:10 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Md> The problem is that specifying IP addresses should be the exception, Md> not the rule. There are advantages and disadvantages on either side of the question "IP vs FQDN". I'd prefer that the choice is left to the sysop and that the phone field is used for whatever that choice is. However, there may be nodelist index compilers choking on something outside the set {0,1,2,3,4,5,6,7,8,9,-,-Unpublished-}. Are there such compilers? Assuming the worst scenario, i.e., that indeed there are such compilers, then we can't use the phone field to list a FQDN, but we can certainly use it for an IP address, even if we have to separate it with '-'. By the same reasoning, we can certainly list FQDNs in the system name field. So you see, my suggestion is both attempting to minimize possible problems with the existant scenario and compromising on the question "IP vs FQDN". As I said, I'd prefer however something simpler. Md> fqdn-in-phone-field AFAIK works with all IP mailers with a modern Md> nodelist compiler (e.g. fastlst). For your solution we would have to Md> modify the compilers. The IP mailers you know of also work with an IP address in the phone field, right? :-) Md> If PSTN nodes with old compilers barfs on lines with fqdn this should Md> not be a problem, those lines will just be skipped. Did you try it? Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1032 [1995] Rcv Scn From : Nick Soveiko 2:5030/23.101 26 Oct 97 16:04:14 To : Lothar Behet 29 Oct 97 06:04:10 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Fri, 24 Oct 1997, 22:33, Lothar Behet (2:2446/301) ==> Nick Soveiko: NS> why not put fqdn in the location field? imo, in the world of ip NS> routing, it's not he geographical location that matters, but the NS> network topology. LB> For routing ftn-over-ip the location shows the sender a possible LB> shortest way for routing to a geographical region. LB> Neither ip# nor fqdn may give this information, just like a LB> possible phone number of -unpublished-. my proposal is under the assumption that ip entries in the nodelist do not get a separate zone/region/net, but are listed according to their geographical location, or, better to say, convenience of delivering mail to the zone/net/region they belong to. so, if i want to send mail to net 12345 and there's an ip entry for a node 12345/6789, i will route the mail to this node. by virtue of p4.07 1.2.3.1 it would be convenient for this node to deliver it to the destination node. if there are few ip capable nodes listed in net 12345, one could determine routing based on better connection quality etc... (absolutely imaginary example) i have a node 2:5030/9876 and my system lists nsoveiko.rogers.wave.ca in location field. before obtaining a nodelist entry under 2:5030 i assume that it would be convenient to deliver mail from 2:5030 to my node at the same expence as to the other nodes of the network. it is my problem how i assuire this. now, any north american node seeng .ca domain in my fqdn can expect quite decent connectivity and would want to route mail to n5030/r50/z2 through my system. my exact geographical location becomes in this case completely irrelevant. however, before doing this all ip capable nodes should formally agree to relay reasonable amounts of mail for their own net/region/zone from the outside. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1033 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 04:58:00 To : Marco d'Itri 29 Oct 97 06:07:22 Subj : A bit of steering ... ------------------------------------------------------------------------------- >> > Every modern BIND version supports round robin. >>Are you 101% sure? I'm pretty sure it is not possible for BIND [...] > In practice that works fine enough. I think I can quite safely agree with that :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1034 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 05:04:00 To : Rune Johansen 29 Oct 97 06:07:24 Subj : Flags in nodelist ------------------------------------------------------------------------------- > Conclusion will be: If you meet a root server that says it is authorative > for the zone you are querying, it should not go to the next one. Correction: if you meet any server that is listed as authoritatve for the zone you are querying, it should not go to the next one. And I'm in doubt whether I should/could replace "is listed as" with "claims to be"; most likely not. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1035 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 05:01:00 To : Marco d'Itri 29 Oct 97 06:07:24 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >>What if client _on_purpose_ tries to overwrite a file? > Do you know any mailer that does that? While operating correctly? No. But when we are talking FTP, we are talking not just mailers, but all other FTP clients too. > I don't think someone here is suggesting that we should have FTP o email > only nodes. We should just discuss a way to advertise those protocols. I hope you are right. >>What you are saying is equivalent to claiming that "the filename client >>uses when doing PUT is meaningless since server can do with the received >>data filename whaterver it wants". > All PSTN mailers do that. But not FTP clients/servers. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1036 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 05:14:00 To : Rune Johansen 29 Oct 97 06:07:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > compatible protocol. That would mean that the BinkP node should run a > FTS-0001 capable mailer on a well-konwn port, in addition to the BinkP > protocol mailer on the BinkP port. Looks like it will work with no problems. But BinkP people will probably raise hell about it - and in a way I undestand their reasons. > Besides, the BinkP/1.0 protocol description sucks (it got many flaws in It's not very important. I mean as long as the concept of this protocol has no internal flaws we can always write a better/adequate docs when necesary (certainly before we adopt it as a standard of any kind). > top of. There is nothing wrong with using BinkP over a modem connection, > except for the errorchecking part. That's a good point. Could we here some more on the performance of BinkP run over the PSTN connections from someone who uses that kind of setup? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1037 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 05:08:00 To : Rune Johansen 29 Oct 97 06:07:24 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- > It would be the same as a non-secure session uploading a pkt-file with > the same name as a pkt-file already lying in the inbound directory of > the mailer. How does the current mailers treat that? Do they overwrite > the file, or do they rename it? If this is a pkt file, then it is to be unpacked and processed by the system, right? Then it makes no difference what name it's given for the (short) rest of its lifetime. > do not know if the FTP daemon has got the capability of issuing a > command back that requests a transfer from a specific offset. > I know that FTP clients can do it, but the other way around? Nope. FTP is a truly client-server protocol, with really distinctive server and client sides; client sends requests, server processes them and sends back responses. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1038 [1995] Scn From : Rune Johansen 2:210/20 28 Oct 97 10:23:00 To : Pedro Lima 29 Oct 97 06:07:24 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- >> So, we'll see how the nodelist compilers feel about that one? :-) > I doubt there will be a problem. However, the TELN flag may be confused > with the Txx flag... :-) I know, but this is only for testing purposes. :-) --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1039 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 04:51:00 To : Yuri Teterin 29 Oct 97 06:07:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > now you suggest just opposite solution - to get such standards that make > software more complicated, transfer file slower and require more > resources. So why are you surprised that other people do not like to > support such a proposal? Because by setting new standards totally incompatible with the older/existing ones (and with no fallback to those older ones) you are seriously limiting connectivity. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1040 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 04:56:00 To : Dima Maloff 29 Oct 97 06:07:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Hm. I just wanted to say that "FTS-1 over IP improves connectivity" > argument should not be used as it's not true. Well, it does not improve connectivity with binkp nodes. But it allowes for using existing mailers - if you want a twisted example - running over a named pipe piggybacked to a raw socket connection :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1041 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 04:49:00 To : Yuri Teterin 29 Oct 97 06:07:24 Subj : FYI - FWIW ------------------------------------------------------------------------------- > Argus exists for Win32 only and is shareware, not free. Oh, yeah? So we are back to the "the only (free multiplatform) mailer to support BinkP is BinkD" situation? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1042 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 04:46:00 To : Slava Filimonov 29 Oct 97 06:07:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > LS> Point taken. Then we have to either drop the idea of IP-only nodes > LS> or write a new FTS... > FTS concerning fido nodes using ip. Exactly. Moreover, we should remember about the existence of the PSTN world and try to work on a solution as smoothly integrateable with it as possible; I mean we have at least to try to cover issues like dual (IP and PSTN) systems. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1043 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 05:38:00 To : Yuri Teterin 29 Oct 97 06:07:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Will you be really satisfied if any binkp-node will be able to support > FTS-0001 over raw TCP? More or less, yes. Then we could say "a Fidonet IP node is just like a PSTN one, only running over raw socket instead of modem link". I think it could make a whole lot of things easier. > TCP) and so will improve its connection with ifcico only (but ifcico- > based nodes have now no problems with binkp - they just run additionaly > binkd and are happy). Could you point me to sources for this mailer/daemon? I'm genuinely interested in trying it out in my system. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1044 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 05:40:00 To : Lawrence Garvin 29 Oct 97 06:07:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Policy requires a telco number and a modem... I had missed that > requirement myself, notwithstanding the permissiveness of FTS-0001. > Alas, nothing short of a policy amendment will permit IP-only nodes. Tough luck. Anyone volunteering for convincing the rest of the world we really need policy changed?... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1045 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 05:46:00 To : Lawrence Garvin 29 Oct 97 06:07:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > the past two weeks), BinkD -can- be written to support FTS-0001 > connectivity to a telnet-based IP-mailer (such as Binkley/vmodem) -- > Argus has proven that. If this is actually true, why not make ifcico support BinkP and declare (both or any) FTS-0001 over raw socket and BibkP the standard we're talking about? > seem, based on the willingness of the ZCs to allow listings of ISDN-only > X.75 and V.110/V.120 nodes, that -protocol- (i.e. communications-link > protocol) is not an issue. I would expect, then, that this would also > extend to IP protocols (such as telnet, vmotelnet, vmp, binkp, ftp, Yeah, if only the &^$%^ "phone number" catch disappeared... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1046 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 05:21:00 To : Lawrence Garvin 29 Oct 97 06:07:24 Subj : IP-access ------------------------------------------------------------------------------- > LS> What I'm trying to say is there is very little point in putting > LS> into a nodelist entry with an FQDN that is not in the relevant > LS> fidonet.org subdomain. [...] > Therefore, there seems to be no reason to restrict this to fidonet.org > FQDN listings only. Sorry, my mistake. I wrote something that could be misleading. Of course I meant the "pW.fX.nY.zZ.", with stress on "pW.fX.nY.zZ" .part > LS> If this node is capable of handling incoming SMTP connections then > LS> it should be listed as a Internet->Fido gateway for at least > LS> itself, > Except that being able to handle incoming SMTP does not equate to being > a functional gateway. For just itself? Not being a hub, host or any non-leaf in routing topology? IMHO it's enough. Maybe there will be no software there to convert mail incoming via SMTP to Fido standards, but at least the person mail is addressed to will be able to read/get it. > LS> which in turn requires having an MX record in a fidonet.org > LS> subdomain - so why trouble with another FQDN? > It requires having an MX record in -some- domain, but not necessarily > fidonet.org True. But why not in fidonet domain? We are Fidonet, aren't we? Ain't that a good reason? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1047 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 05:30:00 To : Lawrence Garvin 29 Oct 97 06:07:24 Subj : IP-connectivity ------------------------------------------------------------------------------- > Reason enough, I would think, for not relying upon such technologies -- > much less to worry about identifying them in a nodelist. If above stands for "SMTP support is not to be considered enough for the system to be granted a Fidonet node status" you have my full support here. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1048 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 05:27:00 To : Dieter Ringhofer 29 Oct 97 06:07:24 Subj : IP-connectivity ------------------------------------------------------------------------------- > I'm NOT in favour of IP-only entries in any FTN-nodelist. Therefore the > proposal of skipping an established minimal FTN-protocoll for IP-nodes > has NO support from my side. This is a quite coherent attitude. I'd be a great supporter of yours if I were not seriously afraid that we're gonna have IP only nodes anyway, no matter how "illegal" we make it. > Than you better stay in Internet. Internet is commercial while FTNs are No, I don't want to stay just in the Internet. I've been there for many years and I still think Fidonet has several quite serious advantages. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1049 [1995] Scn From : Kim Heino 2:222/0 28 Oct 97 13:33:24 To : Rune Johansen 29 Oct 97 06:07:24 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- > My suggestion is that ordinary modem (PSTN) addresses does not use any such > flag, so it would be the default type of transport. ISDN transports already > have their own flags (V110L, V110H, V120L, V120H, X75, ISDNA, ISDNB, ISDNC Modems too have flags, V34, V42B, etc. > IP - denotes IP address in address field. Uses the following transports: > IPT[:portnumber] > IFC[:portnumber] > VMO[:portnumber] Why is the IP-flag needed? IPT, IPR (IFC) and IPV (VMO) are enough. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1050 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 05:33:00 To : Yuri Teterin 29 Oct 97 06:07:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > LS> If - as many claim here - BinkP is free, why not have it implemented? > LS> It would stop a lot of arguing here :) > Because nobody could explained that kind of such 'fallback' is > expected (if we want not just to fulfill the requirements of Policy but > to improve the connectivity between FIDO-nodes). To enable a system to run just one mailer on all its "lines": PSTN or IP, no difference. One mailer means substantially less problems with sharing directories, maintaing configuration etc. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1051 [1995] Scn From : Lech Szychowski 2:480/33.7 28 Oct 97 04:43:00 To : Yuri Teterin 29 Oct 97 06:07:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > LS> They can't. That's one of the reasons we should have a standard > LS> defined. > But there is no standards either on the implementation of FTN-over- > telnet session both on vmodem, isn't it? So, how can some standards be > based on them? I'm not implying the standard-to-be has to be based upon any specific existing or nonexisting yet standard/description. All I'm saying is we IMHO definitely need a standard for IP connecetions/nodes and that IMHO most natural/simple one would be FTS-0001 over raw or telnet. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1052 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 29 Oct 97 09:07:24 To : All Subj : ifcico: Nodelist Flags ------------------------------------------------------------------------------- Hello All! ifcico uses 60179 by itself and 60177 for telnet sessions. Does this port 60177 behave in any way other than the default telnet port 23? Is port 60177 supported by any ifcico in the same way? Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1053 [1995] Scn From : Slava Filimonov 2:469/33 28 Oct 97 10:52:12 To : Lawrence Garvin 29 Oct 97 18:14:32 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hello Lawrence! 26 Oct 97 18:41, Lawrence Garvin wrote to Slava Filimonov: SF>> But we have to have ability to use free software as an option SF>> with same functionality. LG> No, Slava, you don't. :) LG> I repeat... being a member of Fidonet, and participating in this LG> hobby, has NEVER carried with it any suggestion, much less guarantee, LG> that the tools necessary to participate would be FREE. Yes, i do. If i had one for FREE and one non-free, i'd rather choose for free, because there is a chance, that someone will not abuse it. Otherwise i will have to choose 2b or not 2b member of fidonet. And i just trying to publish the thing (Binkp/d) which already prooven it's simplicity and stability. It works! not just for me, but for many other folks too...As someone said here - it sertainly works, not hopefully. ( I'm am not just end user. I used to write sotware for fido and i know all techical problems. I used to have hub system for my net for 3yrs ) And all i can say about it - if you want good ECHOTAG for fido, try binkd. If you want to screw up whole idea - go for evil combination of vmodem/fts001/telnet/ftp/email tunnels/uucp/etc for simple fido mail exchange and pay bucks for this. And do not wonder afterwards, why fido is dead... -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1054 [1995] Scn From : Slava Filimonov 2:469/33 28 Oct 97 10:53:24 To : Rune Johansen 29 Oct 97 18:14:32 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Rune! 27 Oct 97 01:13, Rune Johansen wrote to Slava Filimonov: >> But binkd aware of thouse facts. binkd stores info about >> paritally-received files and can issue rest command. Name clashes >> also resolved. RJ> BinkD is the mailer. BinkP is the protocol. I say that BinkP is as RJ> vulnerable as others running on top of TCP. But, BinkP does not have RJ> retransmits or checksums included, so they will timeout. Okay then. Let's forget about technical side for a moment. From usage statistics side of view binkd with its binkp is more reliable on poor links than vmodem with its crc and retransmission support. In Russia ip links are not as good as in europe or america - so by using binkd sysops there vote in favor of binkp. in few words - binkp vulnerability is tcp/ip issue. if were tcp/ip were so vulnerable, why it still spans the globe? -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1055 [1995] Scn From : Frank Ellermann 2:240/5815.1 28 Oct 97 22:31:00 To : Pedro Lima 29 Oct 97 18:14:34 Subj : was: Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Pedro... PL> If going by the book, the solution may be installing an IP hub, PL> which besides acting as the NC delegate will also serve as a PL> bridge between the two technologies. ... sounds like a good idea, as soon as most nets have such IP-hubs. How was the same problem solved with the first ISDN-only nodes some years ago ? For the beginning we're most probably better off, if we either collect such nodes in special IP-"areas", or if we discourage IP-only nodes, until many nodes supporting both technologies exist. Greets, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1056 [1995] Scn From : Frank Ellermann 2:240/5815.1 28 Oct 97 22:50:00 To : Nick Soveiko 29 Oct 97 18:14:34 Subj : was: A bit of steering ... ------------------------------------------------------------------------------- Hi Nick... ... tnx for info about ISKRA. Are these special phone numbers, a special area code maybe ? NS> credit for the 'extended nodelist format' idea should be NS> given to alex konshin, 2:5030/217. Of course, Marco did this in his translation posted in NET_DEV some weeks ago. Greets, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1057 [1995] Scn From : Slava Filimonov 2:469/33 28 Oct 97 10:43:12 To : Dieter Ringhofer 29 Oct 97 18:14:34 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dieter! 27 Oct 97 17:59, Dieter Ringhofer wrote to Slava Filimonov: SF>> That only means death of redundant protocol. fidonet are us, but SF>> not some protocol. DR> than i skip zmh with my modems. it's the same for anybody like an DR> ip-only system for a non-ip one. Modem connectivity stands for established rules. There is no point to change this. But ip-only system is unique thing, which fidonet parents never dreamed about. As i said before, it's like riding a horse on a highway. Highway is not designed for using with horses but it's possible... -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1058 [1995] Scn From : Frank Ellermann 2:240/5815.1 28 Oct 97 22:39:00 To : Amir Shabashvili 29 Oct 97 18:14:34 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hi Amir... [special region or net(s)] AS> (or zones) ;) ... could be a problem with moving echomail. The actual versions of FSC-0074 and 93 don't support interzone cyclic path detection. So before end of next year we'll better don't try tricks with new zones, unless R2:50 volunteers as test-zone 7 perhaps... :-) Bye ! --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1059 [1995] Scn From : Dieter Ringhofer 2:2476/14 29 Oct 97 05:45:00 To : Nick Soveiko 29 Oct 97 18:14:38 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- [...] DR>> such a listing leads to a can of worms therefore be carefull when DR>> trying to get rid of something. if one wants to destroy fidonet, he DR>> ignores it's rules. NS> ok, let's put it straight. NS> consider 3 types of systems: NS> 1) systems having only pstn connectivity (i mean analogue plain old NS> telephone service, not isdn) NS> 2) systems having both pstn and some kind of ip connectivity (not NS> necessarily 24/365) NS> 3) systems having only ip connectivity (24/365) i agree so far but, i would take a fourth one into consideration: isdn-only nodes. they're similar to type 3. NS> for systems (2) i don't really see any problem at all. on the pstn side NS> they support the protocol chosen by nodes (1). on the ip side they are NS> free to support whatever they want, as this is an *additional* capability NS> for them. NS> it's obvious that for system (1) there's *no way* to directly connect to NS> system (3) in absolutely the same way as now there's no way for a NS> pots-only node to connect to an isdn-only node. therefore, it makes no NS> sense to force systems (3) to support the same protocol systems (1) NS> communicate to each other. so it's quite natural that some of the systems NS> (3) together with participating systems (2) get together and develop a NS> protocol that's convenient for interconnection between them, i.e. simple, NS> efficient, robust, secure and flexible protocol. they propose this NS> protocol as a standard for communication between systems (3) and ip side NS> of systems (2). this proposal is backed by free portable software and open NS> specification. some (2) systems say that they don't have half an hour to NS> spend installing this new software and propose as a standard protocol (1) NS> with some emulation software that enables it over tcp/ip. this emulation NS> software is not 100% free and protocol (1) is er, far from being robust NS> and efficient when used over trcp/ip. NS> that's the situation we have today. but it skips the smallest common dominator. if there's an implementation of fts-0001 it doesn't mean that one has to use it instead a more efficient solution. it offers the chance for systems to use it in case of having nothing else available but real ftn-software. don't forget what we're talking about (hint: listing of ip-systems in a ftn-nodelist). check bbbs and you will see: it's possible. NS> now let's see what's happening on the political side of the game. NS> today having node (3) in fidonet is formally illegal, unless one convinces NS> the coordinator to have a pvt entry. NS> now, if fidonet coordinators keep ruling systems (3) out of the nodelist, NS> than the issue is closed right away. there is nothing to argue besides NS> specific techniques to get some new flags into the nodelist. *imho*, NS> *that* fidonet is doomed. in 2 years zone 1 will be gone for good and in 5 NS> years 90% of zone 2 nodes will be from regions 44-51, with their sysop NS> population start declining as well. have a look at the nodelist statistics NS> if you don't agree. this rapid shrinking in z1 is mostly a result of their calling cost scheme: free local calls. as long as you don't have this a ftn-dialup is always a chance for lowering costs for having more efficient protocols and higher speed available. NS> you say, there's no point in including systems (3) in the nodelist as NS> nodes (1) can't connect them. yes, they can't connect directly, but NS> availability of tcp/ip increases at enormous pace. right now there are NS> already cases when getting some kind of ip connectivity for a system (1) NS> is cheaper than getting pstn connectivity for a system (3). and i see this NS> trend to progress tremendously during the next few years with the number NS> of (3)-capable systems increasing. yes, there's nothing but their very own NS> goodwill that can *force* systems (1) to get this connectivity. again, NS> even now nothing but their own goodwill can force people to spend their NS> own time and money to participate in fidonet. so far, so good but: don't mix participation with being a member. ;) DR>>> What about trying to find a solution fitting both needs? NS>> i most sincerely agree. what i propose will cost you nothing except half NS>> an hour of your time. DR>> what you propose is the death of fidonet. NS> arguable. not that much: any ftn is basing on chance of DIRECT connects. that's impossible for ip. DR>> even sending some registration fee to u.s.a. brought very often DR>> more money to the banking institute than to the programmer. NS> but it never was illegal and you never had to travel a few thousand NS> kilometres to the nearest bank doing such things, right? right. DR>> internet access is still expensive over here, a modem is normally DR>> needed for it. NS> (assuming modem is needed in any case) what is cheaper for cm in germany NS> now: to get a second phone line or a unix shell account? in my area: a second (third, ...) line. DR>> fidonet is basing on possibility of direct connects, so, which DR>> number has to be dialed to connect an ip-system? NS> the number of your local isp. this charges additionally to my normal phonebill. i need to have a phoneline and a modem (analog or ISDN) to get a connect as well. DR>> don't you see the real differences and the real need to find DR>> something in between to have a workable solution?? NS> but enforcing fts-0001 support for ip-only systems is not going to improve NS> the situation in any way as they still won't be able to connect directly NS> to pstn-only systems! for being the most common dominator i don't see a way around. NS>> implemented and fts was abandoned for good. DR>> and so should whole fidonet do now? NS> the whole fidonet has a choice now. to skip it's own rules. DR>>> And: My time is my money as well, some spare time is good for my DR>>> health... NS>> it took me half an hour to install binkd. DR>> those 30 minutes spare time per day (which are not given every day) NS> you're not going to install binkd every day. believe me, it's a pretty NS> robust daemon and not windows/95 ;) but unreliable (not autoresume etc). DR>> i use to read and write some mails while having breakfast (have a DR>> look at the timestamp). NS> i very much appreciate your willingness to discuss this matter at the risk NS> of spilling coffee on the keyboard ;) you're welcome but, now i've to hurry up and leave... :( --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1060 [1995] Scn From : Dieter Ringhofer 2:2476/14 29 Oct 97 05:34:42 To : Nick Soveiko 29 Oct 97 18:14:38 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- DR>> tcp provides reliable point-to-point services (compare it with UDP) DR>> but, it isn't all you need. NS> yep, it's not all. what you need is (1) reliable service (2) NS> stream-oriented. tcp/ip provides both. it's also connection-oriented, bit NS> we don't really care about that. that's the part of tcp and makes the whole thing almost reliable. NS>> do you know many of them? DR>> not many but, i know several tcp/ip implementations ;) NS> does any of them lack reliable and/or stream-oriented performance? under some circumstances they ALL lack reliability. NS>> ok. tcp/ip is a reliable, stream-oriented, connection-oriented NS>> protocol. DR>> every stream-oriented service is unreliable (even NFS). f.e. in DR>> dependancy of protocol you're using frames might be lost for ever DR>> and / or sequence at receiver's side is not according the sending DR>> sequence. this can result in bad files (f.e. .zip with DR>> some bytes in wrong order or missing bytes). to get things straight DR>> retransmission is necessary than. NS> this message i'm writing right now will be delivered to you by means of NS> binkp over tcp/ip. binkp has *neither* error control, nor packet sequence NS> recovery. that's bad and it's somewhat unusable for this. one of my tests with tcp was getting a somewhat huge filenet from a ip-system. i tried it three days and stopped it than, getting it with normal FTN long distance calls is cheaper for me. NS> if tcp/ip is not a reliable and/or stream-oriented service (as NS> you seem to claim), you won't be reading this. if you do, either NS> something is wrong with your arguments or my english is not good enough NS> to understand you. elaborate, please. see documentation of tcp/ip development kit from IBM as an example of explanation, please, it's written by native english speaking persons. most propably lack of knowledge of english language is on my side ;) --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1061 [1995] Scn From : Lawrence Garvin 1:106/6018 28 Oct 97 21:17:46 To : Rune Johansen 29 Oct 97 18:16:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen said in a message to Yuri Teterin: RJ> As I have stated in my 1st proposal, I have changed a little in my RJ> views. I now consider BinkP as a protocol alongside EMSI, FTS-6 and RJ> FTS-1 over a raw TCP session. Any chance I could persuade you to invert your usage of the terms protocol and session? I'd prefer to see BinkP, EMSI, FTS-6, and FTS-1 referred to as -SESSION-, and TCP (telnet/ftp/smtp), UDP (http), X.75, V.34, and others of that ilk refered to as -PROTOCOLS-. The SESSION runs on top of the PROTOCOL. No? :) RJ> As long as BinkD cannot do FTS-1 fallback, it will not meet the RJ> requirements of a Fidonet Nodestatus. If you have a mailer that has RJ> got the fallback, you can use it. Notwithstanding the terminology gap, I agree with this basic principle. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1062 [1995] Scn From : Marco d'Itri 2:335/680.666 29 Oct 97 15:35:36 To : Chris Maddock 29 Oct 97 21:42:10 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Chris.Maddock@f302.n640.z3.fidonet.org wrote: >Md> I agree. The only problem is with makenl, and this could be easily >Md> resolved by patching NLMake. >David Nugent made a nice nodelist program that addresses many of the problems >in MAKNL, =and= the source code is available. This is why I wrote this problem could be easily resolved. Even if I would prefere a perl compiler. :-) >Ways to cut down the space are needed I feel. I suggest a bit-code for the >different protocols and capabilities may be the answer and while it is not >easily machine readable, it holds great promise. I think this is too difficult to parse. The small saving in the compressed nodelist does not justify that. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1063 [1995] Scn From : Marco d'Itri 2:335/680.666 29 Oct 97 15:39:00 To : Pedro Lima 29 Oct 97 21:42:10 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Pedro.Lima@f21.n362.z2.fidonet.org wrote: >There are advantages and disadvantages on either side of the question >"IP vs FQDN". I'd prefer that the choice is left to the sysop and that >the phone field is used for whatever that choice is. However, there may I agree. >be nodelist index compilers choking on something outside the set >{0,1,2,3,4,5,6,7,8,9,-,-Unpublished-}. Are there such compilers? I hope there are not. Those compilers should just ignore the field or at least the node. >use it for an IP address, even if we have to separate it with '-'. By >the same reasoning, we can certainly list FQDNs in the system name field. We would need to modify much things in our software. > Md> fqdn-in-phone-field AFAIK works with all IP mailers with a modern > Md> nodelist compiler (e.g. fastlst). For your solution we would have to > Md> modify the compilers. >The IP mailers you know of also work with an IP address in the phone >field, right? :-) Right. Binkley does that, and AFAIK tmail does too. > Md> If PSTN nodes with old compilers barfs on lines with fqdn this should > Md> not be a problem, those lines will just be skipped. >Did you try it? I did not, maybe this will be a chance to dump some of the old programs that are used in fidonet. :-) -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1064 [1995] Scn From : Marco d'Itri 2:335/680.666 29 Oct 97 15:12:46 To : Lech Szychowski 29 Oct 97 21:42:10 Subj : Re: FYI - FWIW ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >Oh, yeah? So we are back to the "the only (free multiplatform) mailer >to support BinkP is BinkD" situation? Please correct me if I am wrong, but I can't see a free and multiplatform mailer that supports FTN over telnet. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1065 [1995] Scn From : Marco d'Itri 2:335/680.666 29 Oct 97 15:28:36 To : Lawrence Garvin 29 Oct 97 21:42:10 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >sites. Therefore, it serves no purpose at all (at least for me) for SMTP or >FTP protocol information to be in the -nodelist-. I need to know which nodes supports email tunneling, e.g. to send them crash mail. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1066 [1995] Scn From : Marco d'Itri 2:335/680.666 29 Oct 97 15:31:40 To : Lech Szychowski 29 Oct 97 21:42:10 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >If above stands for "SMTP support is not to be considered enough for >the system to be granted a Fidonet node status" you have my full >support here. I agree with that, but there is no reason the system supporting those *OPTIONAL* protocols shouldn't announce them in the nodelist. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1067 [1995] Scn From : Marco d'Itri 2:335/680.666 29 Oct 97 15:26:02 To : Rune Johansen 29 Oct 97 21:42:10 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: > Telnet - IPT - default port number 23 > Why not use TELN or TEL? Well, since we already are using Txy falgs to > denote mail hours in the nodelist, there will be a great danger that this > flag would be parsed incorrectly. By using IPT, it will be unique, and would > keep the TEL is wrong, but I think we should use TELN because it's already in use in some networks and is easy to understand. I don't think there are programs so broken to misparse TELN as a Txy flag, it this is true we would have to outlaw all T* headers. > Raw TCP - IFC > Why not use TCP? Why use IFC? Well, the TCP part is easy, look at Telnet > explanation :-) Why use IFC? ifcico were the first mailer to my knowledge > using a raw TCP session for exchanging FTS-1/FTS-6/EMSI session handshakes. Please note that the current use of the IFC flag implies supporting the RAW flag (i.e. what you described) and an optimized communication protocol proprietary of ifcico. > VModem - VMO - Default port 3141 Nodes are already using VMP (VModem Protocol), which is more correct IMHO. >So, if I run a raw TCP mailer capable of EMSI only, I would like to run the >flag EMSI to denote that: I don't think is useful adding that. (I agree about other issues, your proposal looks very good.) -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1068 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 29 Oct 97 15:11:36 To : Lothar Behet 29 Oct 97 21:42:10 Subj : Re: ifcico: Nodelist Flags ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: >ifcico uses 60179 by itself and 60177 for telnet sessions. No, 60179 is used for an ftn handshake over the raw TCP connection. >Does this port 60177 behave in any way other than the default telnet port 23? It has no telnet daemon listening, just ifcico. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1069 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 30 Oct 97 00:48:08 To : Marco d'Itri Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hello Marco! On 29 Oct 97 wrote Marco d'Itri to Pedro Lima: >> Md> fqdn-in-phone-field AFAIK works with all IP mailers with a >> Md> modern nodelist compiler (e.g. fastlst). For your solution we >> Md> would have to modify the compilers. >> The IP mailers you know of also work with an IP address in the phone >> field, right? :-) MI> Right. Binkley does that, and AFAIK tmail does too. If you mean Vmodem with Binkley, than this combination only works after a translation of dahses to points or stars. Other mailers have to be checked yet. >> Md> If PSTN nodes with old compilers barfs on lines with fqdn this >> Md> should not be a problem, those lines will just be skipped. Or they abort with an error. >> Did you try it? MI> I did not, maybe this will be a chance to dump some of the old MI> programs that are used in fidonet. :-) This might include a complete new system setup for some nodes, if their software is not supported any more. As long as nobody nobody checked it at least for widely spread programs (i.e. Frontdoor, Intermail or some Amiga/ST programs) I would prefer some more caution with such plans. Regards Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1070 [1995] Rcv Scn From : Sean Rima 2:252/356 28 Oct 97 13:04:00 To : Lothar Behet 30 Oct 97 05:42:40 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hi Lothar, On Stardate <9710.26>, you wrote me: LB> Hello Sean! LB> On 24 Oct 97 wrote Sean Rima to Lech Szychowski: >>>> I think as others have said that it is getting Ipmailers into >>>> the nodelist and not the protocols that is being debated. LS>>> Of what use is a mailer without a protocol one can use to talk LS>>> to it? SR>> Some one mentioned that an additional Flag, ie IP:xx could be SR>> use to donate the type of mailer used. LB> This initiates some trouble, as a node may run different mailers LB> under the same address and has to specify non-standard ports. LB> Therefore i prefer the komma-seperated list of flags with optional LB> port specification via ":". Yes you are right, but BinkP, IFcico, Telnet all use different ports anyway. but the comma seperated list sounds like a good idea. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: Start a download. Get a beer. Multitasking. (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1071 [1995] Scn From : Sean Rima 2:252/356 28 Oct 97 13:09:00 To : Lech Szychowski 30 Oct 97 05:42:40 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hi Lech, On Stardate <9710.26>, you wrote me: >> LS> Of what use is a mailer without a protocol one can use to >> talk to it? Some one mentioned that an additional Flag, ie IP:xx >> could be use >> to donate the type of mailer used. LS> We still need to know/define what exactly those flags are going to LS> stand for - we have to describe the protocols in a way strict enough LS> to enable anyone who wants to create his own implementation to do so. True, so if your used BND = BinkD, IFC = IFcico, VM = VModem etc as the flags and there would be a RFC to describe in detail how each protocol would work, minimum standards so as to speak. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: A desk is a wastebasket with drawers (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1072 [1995] Scn From : Denis McMahon 2:251/20 28 Oct 97 10:14:48 To : Lawrence Garvin 30 Oct 97 05:42:42 Subj : IP-access ------------------------------------------------------------------------------- Lawrence Garvin wrote to Denis McMahon: DM> It should not be a requirement that a net maintain a nameserver DM> before that net is allowed to contain IP nodes! LG> No... but SOMEWHERE, that node is going to have to be listed in LG> somebody's nameserver in order to get IP service. It matters not LG> who runs the server, the fact remains, it must exist. Agreed, however I was disputing the suggestion that nameserver entries should be handled by the NCs, how many NCs run nameservers? Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1073 [1995] Scn From : Denis McMahon 2:251/20 28 Oct 97 10:07:36 To : Lawrence Garvin 30 Oct 97 05:42:42 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Lawrence Garvin wrote to Denis McMahon: DM> Rubbish. FTP has been used for fidonet data transfer for some time, DM> as has SMTP. The fact that it is used and it works shows that the DM> problem you are trying to invent either does not occur, or is not DM> insurmountable. LG> Whether it works, or not, or any other related concept is LG> irrelevant. LG> What is -relevant- is can the FTN MAILER do anything useful with LG> that information, and until somebody provides for replaceable LG> parameters in the config files of FIFTP or other utilities, I'd say LG> the answer is no. Not at all, if the anon inbound is examined after every session, then any arcmail and pkt files can be processed or moved to a holding area, depending on the sysops wishes, and it can be done automatically. The software doing the move can handle any renaming, there's no need to change the ftp software at all. LG> My FIFTP sessions run totally independent of the existence of any LG> nodelist, as does the inbound and outbound processing of echomail LG> to and from those ftp sites. Therefore, it serves no purpose at all LG> (at least for me) for SMTP or FTP protocol information to be in the LG> -nodelist-. So because it's of no benefit *TO YOU* *AT THE MOMENT* it's not needed eh? It's of no benefit whatsoever to me at the moment either, my system is purely analogue PSTN as far as the fido side goes, and likely to stay that way for some time (until I can afford a direct connection, which means either a big drop in connection prices or I win the lottery) but at least the fact that IP connected nodes, whatever their transport method, are in the nodelist means that I can send them netmail without it being bounced by message trackers, and if we can develop a standard format for the presentation of IP connection info in the nodelist then maybe some of the software authors will start using the info. Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1074 [1995] Scn From : Denis McMahon 2:251/20 28 Oct 97 09:57:18 To : Lawrence Garvin 30 Oct 97 05:42:42 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Lawrence Garvin wrote to Denis McMahon: LG> Anybody who accepts -anonymous- upload of PKT and ARCMail files has LG> just violated rule number one of Fidonet security -- SESSION LEVEL LG> PASSWORDS! OK, suppose a node that doesn't have a session password wants to send you a crash netmail? How does he do it? Answer, he dials your telno and sends it. He presents *ANY* valid nodenumber in the nodelist, and as long as you don't have a session password set with the node address presented your system accepts his mail. End of session. This is *NO DIFFERENT* to accepting anonymous upload! Of course, what you do with mail from an anonymous source (hold for inspection, process immediately etc) is up to you, but it doesn't form part of the session protocol either! Personally I only accept echomail from agreed systems over password protected links, but I accept pkt files from any node in the nodelist, and process them if they fit certain size and number of message criteria. I even process arcmail from unprotected sources providing the compression factor is above a certain level, and the enclosed packet meets the above criteria and only contains netmail. LG> I am strictly opposed to the use of anonymous ftp for the transport LG> of Fidonet mail. All ftp should be done on a closed-account basis, LG> password protected, and even then, although not normally done, LG> should probably include packet level passwords. Yeah? So what do you do with incoming pkt and arcmail files in your fidonet inbound from nodes that don't have a session password? Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1075 [1995] Scn From : Denis McMahon 2:251/20 28 Oct 97 10:29:38 To : Rune Johansen 30 Oct 97 05:42:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen wrote to Nick Soveiko: RJ> The basis question is still valid: Should the IP nodes have at RJ> least one protocol in common? It would be nice if they did, but there are too many different protocols and transports about to allow it. Maybe we need two different types of ip node entry? One for FTN session level transports, and one for RFC based transports? Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1076 [1995] Scn From : Denis McMahon 2:251/20 28 Oct 97 10:34:30 To : Nick Soveiko 30 Oct 97 05:42:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Nick Soveiko wrote to Yuri Teterin: YT> Because nobody could explained that kind of such 'fallback' is YT> expected (if we want not just to fulfill the requirements of Policy YT> but to improve the connectivity between FIDO-nodes). NS> i think that improving connectivity between fido nodes is *the NS> spirit* of policy. I can not disagree, but I think also improving communication between people? Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1077 [1995] Scn From : Lech Szychowski 2:480/33.7 29 Oct 97 02:21:00 To : Nick Soveiko 30 Oct 97 05:42:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > RJ> The basis question is still valid: Should the IP nodes have at > RJ> least one protocol in common? > this falls into a political question: should ip-only nodes be allowed in > the nodelist? Nope, these are IMHO two different issues. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1078 [1995] Scn From : Denis McMahon 2:251/20 28 Oct 97 10:19:42 To : Lech Szychowski 30 Oct 97 05:42:42 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Lech Szychowski wrote to Denis McMahon: > Rubbish. FTP has been used for fidonet data transfer for some time, as > has SMTP. The fact that it is used and it works shows that the problem > you are trying to invent either does not occur, or is not insurmountable. LS> ...or just haven't been happening often enough to be brought to our LS> attention - a situation that may change dramatically with LS> introduction of the large scale transfers. LS> We are not Microsoft, are we? The idea here is to deisgn something LS> that will work certainly, not just hopefully. OK, but why do you insist on ignoring a method that does work? OK, I have only ever set up one ftp server, and it had the facility to accept anonymous upload. It also had an ability to prevent over-write / deletion of files in the upload directory. Non anonymous callers could have their own or a common upload directory accessed with userid and password. I assume these features are generally available in other ftp servers. There are 3 types of file that might be transmitted during a fido session: (1) PKT file (2) Arcmail (3) Other file Other file includes nodediff, fidonews, binaries etc. Now, PKT file can usually be processed when received, although some sysops may want to apply some additional security checks to anon received pkt, and might also want to make sure no echomail. Arcmail file - sysop may want to check compression ratio, then unpack pkt files and process them like (1). Other files, sysop probably wants to see what they are before processing. Maybe after ftp session has closed one runs a session utility that looks at inbounds, processes received files, does any move and rename needed to files for later eamination etc? I don't know, maybe someone needs to recompile an ftp daemon with an after-session call? However, it would be short sighted to dismiss the transport method just because some people can only see problems where others see solutions! Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1079 [1995] Scn From : Denis McMahon 2:251/20 28 Oct 97 10:37:02 To : Pedro Lima 30 Oct 97 05:42:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Pedro Lima wrote to Rune Johansen: RJ> The basis question is still valid: Should the IP nodes have at least RJ> one protocol in common? PL> FWIW, and IMO, no. The technology allowing the existance of IP PL> nodes in FidoNet should be regarded for now as experimental. If a PL> standard proves in practice to be needed, then we can address the PL> subject with a knowledge base impossible to foresee presently. On PL> the other hand, if it doesn't, then the issue is irrelevant and PL> the regulations would need to be altered or extended (namely PL> Policy or FTS-1) in a way coherent with practice. Hey, we agree on something. That's a big day for this echo - two people agree :-) Regards Denis --- timEd/386 1.10 * Origin: Pickaxe (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1080 [1995] Scn From : Frank Ellermann 2:240/5815.1 29 Oct 97 04:24:00 To : Nick Soveiko 30 Oct 97 06:00:34 Subj : was: IMPORTANT [...] ------------------------------------------------------------------------------- Hi Nick... NS> disclaimer: the views expressed above are of myself only. ... be absolutely sure, that this disclaimer is the _only_ statement in your message, with which I strongly disagree. ;-) Concerning your other message: maybe you should try to define "reliable" somehow. In a net-layer sense it means, that packets are either delivered once and in order to the peer, or the connection fails. In this sense I don't understand "reliable connectionless" ?!? Seen from the seesion layer, if you want some concept of "transactions", this reliability of the transport layers is only relevant, if these connections make it until an agreed upon DISConnect... the "reliable" indication of an out-of-order state won't help forever... :-) Greets, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1081 [1995] Scn From : Lech Szychowski 2:480/33.7 29 Oct 97 08:54:00 To : Denis McMahon 30 Oct 97 06:00:34 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- > OK, but why do you insist on ignoring a method that does work? Because it just might seem to work. As soon as someone demontrates it _does_ (read: does always and will always) work, I'll withdraw my objections. > Now, PKT file can usually be processed when received, Provided it was received complete. What if it wasn't? > Maybe after ftp session has closed one runs a session utility that looks > at inbounds, processes received files, does any move and rename needed > to files for later eamination etc? We have a big problem here. We have to assume that system running FTP daemon is a multitasking one (it very well may be, right?). Then we run into a huge problems - there might be numerous FTP sessions being opened, being closed or active at any given moment of time (unless we run some kind of a heavili modified daemon). > I don't know, maybe someone needs to recompile an ftp daemon with > an after-session call? It's not enough. See the aforementioned reasons. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1082 [1995] Scn From : Rune Johansen 2:210/20 29 Oct 97 01:19:22 To : Yuri Teterin 30 Oct 97 06:00:34 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>> You're right that BinkP alone is against policy, you must be able to do >>> FTS-001 over raw or telnet too. >> And that's precisely what we've been arguing about for a long time here :) > Will you be really satisfied if any binkp-node will be able to support > FTS-0001 over raw TCP? I, for one, would be satisfied if BinkP implementations would have the possibility to fall back to the FTS-1 (and other) protocols regardless of the transport in runs on top of. That means that you could use BinkP over other things too, like a modem line, or X.25 or... --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1083 [1995] Scn From : Rune Johansen 2:210/20 29 Oct 97 01:22:28 To : Yuri Teterin 30 Oct 97 06:00:34 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> The whole discussion around FTS-0001 came from a suggestion that there >> should be at least one common protocol for IP nodes. > This is desirable but not necessary. Is we decide to use flags like IFC, > BNP, VMP in nodelist, each node can calculate all common protocols for > destination node and make the call at most appropriate one. Then we should list EMSI and FTS-6 and FTS-1 too. BinkP is a handshake alongside those mentioned. If it is to get a special flag in the nodelist, so should the others too. >> Many people said that the obvious protocol should be BinkP, since >> there already are hundreds of nodes in fidonet using it. > Nobody said that. Yes, people said that. Look backwards in this echo, and you'll find it. > Everybody can continue to use vmodem ore ifcico as before and be listed in > lidelist. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1084 [1995] Scn From : Rune Johansen 2:210/20 29 Oct 97 01:39:04 To : Lawrence Garvin 30 Oct 97 06:00:34 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > And based on what I've read in the past few hours (messages posted over the > past two weeks), BinkD -can- be written to support FTS-0001 connectivity to a > telnet-based IP-mailer (such as Binkley/vmodem) -- Argus has proven that. BBBS (the mailer I use) also proves that. :-) It can do BinkP, EMSI and FTS-1 on the same listening device, wether it is raw TCP, Telnet or modem. >Just food for thought, but this past week I obtained 'new' licenses for my SIO > The registratio numbers were 10025130 and 10025131. Where do you suppose he > started numbering? 1002500 ?? :-)) > However, the same basic rule still applied. _IF_ two nodes could establish a > common communications-link protocol, whatever that may be, we don't care, it > was still a -requirement- that both of them be able to negotiate an FTS-0001 > MAILER SESSION. You are correct here. I would like to extend it a little, with the special case of IP based systems. Since you can have several daemons listening on different ports, you would only need to negotiate a FTS-0001 session on _one_ of them. The question is then: wich one, and how do I find it? The simplest solution is to make the daemon fallback to FTS-0001 if it does not manage to make a handshake of it's own kind. >The only remaining questions to be determined is -- where does the IP number o > FQDN go in the nodelist source -- and who's going to write the nodelist >generator(s), nodelist compiler(s), and mailer modification(s) that will allow > US to use these new features. According to my 1st proposal, it would be an address field, where the phone number is located today. The flags would show what type of address there is in the addres field, and your mailer would act accordingly. If the mailer does not have the option to connect to that type of address (PSTN trying to call ISDN only, or PSTN trying to call IP), then the connection cannot be made. It's a fact in today's nodelist. When it comes to nodelist generators, I have not played around with nlmake enough yet, to tell if it can do the job already. Nodelist compilers would be the task of existing compiler programmers, and/or the mailer programmers themselves. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1085 [1995] Scn From : Rune Johansen 2:210/20 29 Oct 97 02:12:54 To : Nick Soveiko 30 Oct 97 06:00:34 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> The whole discussion around FTS-0001 came from a suggestion that >> there should be at least one common protocol for IP nodes. > see my reply to dieter on the prerequisites of this. my opinion is: common > protocol for ip-only nodes, and this protocol to be binkp. Using BinkP as a must-have common protocol is what you want. That is noted. This is a political question, tied together with FidoNet in particular (yes, we are discussing FidoNet here). Let's say my friend has got a IP-capable system, that does FTS-1, FTS-6 and EMSI, like any full-fledged current modem/ISDN based node of today uses. He has the possibility to use a virtual COM-port redirector, that enables him do "dial" a IP system, with telnet OR raw TCP (both are available). Then he connects to a IP node, just to find that it won't do any of his protocols. He can connect fine, so the transport is OK. If that system he connects to can do fallback to one of his protocols, with FTS-1 as last resort, all will be good and OK. If he was to support BinkP in addition, it would be even better, but he cannot. >> Many people said that the obvious protocol should be BinkP, since >> there already are hundreds of nodes in fidonet using it. I then >> argued with that if we are to follow policy, then this protocol >> should be capable of carrying FTS-0001 handshake. Then it has been >> argued that this is a ridicolous solution. > i second the ridiculousness. Just because BinkD in it's current implementation cannot do fallback to FTS-1 when it is a called party? What does it take to implement a simple FTS-1 fallback routine into BinkD, to make it able to receive all mailers that can do raw TCP? Compared to implementing BinkP protocol in all mailers that would be considered doing connections over a (possibly FOSSIL-compliant) raw TCP "dialer"? >fts-0001 over telnet or over raw ip is just *a little bit* less ridiculous tha > fts-0001 over binkp. No, that's where we disagree. >> For BinkP capable nodes this would not be any problem to implement, >> as they would use the listening port, autodetect BinkP vs. >> FTS-0001, and have a session accordingly. > sorry for repeating this, but it won't be a technical problem only. for some > nodes that's going to be a monetary/legal problem. In what ways will that be a legal problem? I don't see the difference between using a BinkP or a FTS-1 daemon, or a BinkP daemon that can fallback to FTS-1? On the monetary side, I would like to bet that someone (maybe myself) would implement such a "hook" in BinkD (which is the most broadly used implementation of a mailer that uses BinkP today), to allow it for autodetection of an incoming FTS-1 session on it's listening port. >i am doing my best, but i have a fulltime job besides this ;). i hope it to be > documented at least as good as the existing fts and having way more > possibilities for extension than them. Good. I really hope that the specifications of the BinkP protocol would allow for implementing fallback to other protocols, so it can be easily implemented by the implementors. :-)) Just take a look at the EMSI specs for the receiver: : Monitor line for EMSI_INQ and : : possible other protocol start : : characters and if received, : : attempt to handshake immediately.: That's how easy it can be done. Specs should also allow for "junk" before finding the BinkP protocol chars, to allow for autosensing when calling another system. Just a way of being leniant on what is on the other end. "Be leniant in what you accept, and strict in what you send" is a good, old jungleword used by successfull software developers all over the world. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1086 [1995] Scn From : Rune Johansen 2:210/20 29 Oct 97 02:22:14 To : Nick Soveiko 30 Oct 97 06:00:34 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > i think we've clarified this by email. Yep, thanks. >> And, there could be lots of misunderstanding in the password >> routine, by having case-sensitive password checking. >this is documented in binkd user guide, ido/binkd/man>. i am still not sure if this should be a part of a formal > *session* layer protocol specs. I believe that such an important part should be specified in the BinkP specs itself, to avoid different interpretations in the future implementations of this protocol in other mailers. You should not be forced to read another _mailers_ documentation, to implement a specific protocol. When that is said, I would suggest you take thing that applies directly to BinkD's implementation of BinkP out of the specs. Like that part with "If extra data frames are received, BinkD currently appends it to the file received". It has already been misunderstood, waiting for a M_EOB or M_FILE before a M_GOT has been sent. Just shows how people misunderstand good intentions :-) > hdlc-like datalink protocol. i hope to include description of this as an > appendix on binkp implementation together with the emsi/fts-0001 fallback > procedures. Supert! --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1087 [1995] Scn From : Rune Johansen 2:210/20 29 Oct 97 02:15:50 To : Nick Soveiko 30 Oct 97 06:00:34 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Or, do considerer FTS-001 over raw socket as the minimal >> requirement? > afaik, only ifcico is capable of doing this. If, for example, Vmodem could create a raw socket, so could FrontDoor, BinkleyTerm, etc. etc. If WinFossil could do this, so could all the mailers under windows do this. It's an easy way of getting other mailer to connect too, when the underlaying transport is compatible (raw versus telnet versus VModem specific). --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1088 [1995] Scn From : Rune Johansen 2:210/20 29 Oct 97 02:26:30 To : Marco d'Itri 30 Oct 97 06:00:34 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> And, the BinkP protocol binds itself to IP. I do not believe in submitting >Argus supports binkp over dialup, I suppose this is only a documentation flaw. Documentation is the basis of all discussions. If documentation describes one thing, and the fact is another, documentation must change. I know now that Nick is including other examples and various carriers in the BinkP "formal" docs, so that has been taken care of. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1089 [1995] Scn From : Rune Johansen 2:210/20 29 Oct 97 01:42:38 To : Kim Heino 30 Oct 97 06:00:34 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- > Modems too have flags, V34, V42B, etc. True. I will rephrase. >> IP - denotes IP address in address field. Uses the following transports: >> IPT[:portnumber] >> IFC[:portnumber] >> VMO[:portnumber] > Why is the IP-flag needed? IPT, IPR (IFC) and IPV (VMO) are enough. Also true. Then a IP-based mailer could trigger in the first two chars, and select the transport on the third (and beyond). I will restructure to accommodate this, as it would shorten the node's linelenght. I will also suggest the other variants of the "names" as default. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1090 [1995] Scn From : Rune Johansen 2:210/20 29 Oct 97 01:24:44 To : Marco d'Itri 30 Oct 97 06:00:34 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- >> If you are not a "owner" of the system you are running your node at, you > would >>need the blessing of the system operator to put up a daemon on a non-standard >> port anyway. > This is not true, I can install any daemon I want on unprivileged ports. > I just need a shell account. And I don't have to bother the sysadmin to > change the configuration and so on. _you_ can, yes. I can too, until the SysAdmin at the ISP login server figures out what I am doing. Then I'll get kicked out. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1091 [1995] Scn From : Lech Szychowski 2:480/33.7 29 Oct 97 09:00:00 To : Slava Filimonov 30 Oct 97 06:00:34 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- > if tcp/ip were so vulnerable, why it still spans the globe? Because it's a damn simple protocol when compared to other ones. And the error checking/corrections it supports (plus packet resequencing if necessary) is enough for most apllication. Although there are tcp/ip based protocol/applications that do their own checking, rigth? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1092 [1995] Scn From : Lawrence Garvin 1:106/6018 29 Oct 97 07:54:06 To : Lech Szychowski 30 Oct 97 18:22:16 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Lawrence Garvin: > Except that being able to handle incoming SMTP does not equate to > being a functional gateway. LS> For just itself? Not being a hub, host or any non-leaf in routing LS> topology? Nope. Just because my system can send/receive SMTP, does not imply that it has the necessary software gateways installed to make that information available to Fidonet. Ostensibly SMTP attachments are relatively simple, they can just be 'stored' in the mailer inbound, and most tossers are intelligent enough to separate the wheat from the chaff. But that's about the extent of it. Of course, there is a very simple SMTP<>Fidonet gateway that will read RCV files out of an inbound queue, and write 'em to a local MSG or Squish area. But it only runs on OS/2. :) > It requires having an MX record in -some- domain, but not necessarily > fidonet.org LS> True. But why not in fidonet domain? We are Fidonet, aren't we? LS> Ain't that a good reason? I see no reason not to support it in fidonet.org; but that will require the complete cooperation of the Hostmaster@fidonet.org, as well as designated hostmasters for delegated regions/nets. On the other hand, I have a gateway domain setup here, that nodes in my CRP might prefer to be identifed in, or at least identified dually. A lot depends on how cooperative hostmaster@fidonet.org is with this whole situation. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1093 [1995] Scn From : Slava Filimonov 2:469/33 28 Oct 97 16:28:58 To : Sean Rima 30 Oct 97 18:22:56 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hello Sean! 28 Oct 97 13:09, Sean Rima wrote to Lech Szychowski: SR> True, so if your used BND = BinkD, IFC = IFcico, VM = VModem etc as Little remark - BND means program, BNP means protocol, which binkd uses. So we should use BNP flag instead. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1094 [1995] Scn From : Dima Maloff 2:5047/13 29 Oct 97 21:32:00 To : Lawrence Garvin 30 Oct 97 18:22:56 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Sunday October 26 1997 18:41, Lawrence Garvin wrote to Slava Filimonov: LG> I repeat... being a member of Fidonet, and participating in this hobby, LG> has NEVER carried with it any suggestion, much less guarantee, that the LG> tools necessary to participate would be FREE. But if they ARE free, why not to use them? I'm starting to think that you are paid by Ray Gwinn. :) LG> (2) Rely upon somebody else to write the software -- and expect that LG> they'll want compensation for THEIR TIME AND EXPENSE in writing a product LG> that might not be accepted by those on the 'cutting edge' because somebody LG> else might write something just a little bit better. *sigh* It's their problem. Sad, but true. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1095 [1995] Scn From : Yuri Teterin 2:5030/239 29 Oct 97 12:11:30 To : Lawrence Garvin 30 Oct 97 18:22:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lawrence ! Sun Oct 26 1997 Lawrence Garvin writes to Rune Johansen: LG> And based on what I've read in the past few hours (messages posted over LG> the past two weeks), BinkD -can- be written to support FTS-0001 LG> connectivity to a telnet-based IP-mailer (such as Binkley/vmodem) -- Argus LG> has proven that. Argus support FTS-0001 session at separate port, not at BinkP port. Such a support is easy for Argus because it is a general-purpuse mailer and already has all necessary codes in it. Contrary, to implement FTS-0001 over telnet in binkd is absolutely senseless - it would be much more easy to write instead a separate mailer for this and run it at a separate port. LG> -protocol- (i.e. communications-link protocol) is not an issue. I LG> would expect, then, that this would also extend to IP protocols (such LG> as telnet, vmotelnet, vmp, binkp, ftp, smpt, and pick another half LG> dozen just for good measuere). That do you understand under 'communication-link protocol'? Are you sure telnet, binkp, ftp, smtp are such kind of protocols? I am sure, they are not. LG> However, the same basic rule still applied. _IF_ two nodes could establish LG> a common communications-link protocol, whatever that may be, we don't LG> care, it was still a -requirement- that both of them be able to negotiate LG> an FTS-0001 MAILER SESSION. Such requirement is senseless as far as we did not defined what is 'communication-link protocol' in our case. In any case to 'negotiate an FTS-0001 MAILER SESSION' over ftp, smtp, binkp or telnet is impossible without some additional specifications, and for first 3 protocols this is quite senseless too. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1096 [1995] Scn From : Dima Maloff 2:5047/13 29 Oct 97 21:35:00 To : Dieter Ringhofer 30 Oct 97 18:22:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Monday October 27 1997 18:14, Dieter Ringhofer wrote to Dima Maloff: DM>> even if a sysop has paid for FTS-1-style Fido software, it still DM>> CANNOT do Fido-over-IP. DR> that's wrong. i can do so and: i don't need any other software than the DR> one already being set up over here. We are not talking about you. We want to connect as many nodes as possible, aren't we? DM>> So he has either pay more money for a fossil driver w/TCP/IP DM>> support, or add free binkd. DR> nobody told that software development is for free. i BOUGHT several DR> compilers and i need TIME to write the code. both lead to money. We do not force you to make free software. You do not force us to use non-free software. Deal? --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1097 [1995] Scn From : Slava Filimonov 2:469/33 29 Oct 97 12:59:26 To : Denis McMahon 30 Oct 97 18:22:58 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Denis! 28 Oct 97 09:57, Denis McMahon wrote to Lawrence Garvin: DM> Yeah? So what do you do with incoming pkt and arcmail files in your DM> fidonet inbound from nodes that don't have a session password? same way senmail does. at least senmail adds ip addresses of remote hosts. Upon lookup at ip adresses records you can try to trace back to origin. Reason: there is no common way to authenticate one-time sender. By adding protection and authentication we'll cut ourself from incoming mail from unknown/unvalidated systems. Here, if ip adress of calling node is the same as for fido node in dns we can try to trust such node. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1098 [1995] Scn From : Yuri Teterin 2:5030/239 29 Oct 97 12:01:52 To : Lawrence Garvin 30 Oct 97 18:22:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lawrence ! Sun Oct 26 1997 Lawrence Garvin writes to Yuri Teterin: LG> I suspect that if you took a look at the file-transfer protocols used in LG> association with those FTS-0001 sessions, you'll find that their nature is LG> such that they -need- to have a TCP connection, and will not be able to LG> function adequately across a UDP connection. Why not? FTS-0001 does not suppose that the connection is error-free. And any non-errorfree connection can be implemented very well with help of UDP. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1099 [1995] Scn From : Dima Maloff 2:5047/13 29 Oct 97 21:39:00 To : Lech Szychowski 30 Oct 97 18:22:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sunday October 26 1997 03:12, Lech Szychowski wrote to Rune Johansen: >> The basis question is still valid: Should the IP nodes have at least one >> protocol in common? LS> Are you seriously afraid that not everyone agrees with this statement? LS> Well, if your doubts are true we are in big trouble... AFAIK, the common idea in SU.IP.SYSOP (an echo for ex-USSR IP-sysops, the echo is 2 yrs old, BTW) is that we don't need a standard protocol. At least right now. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1100 [1995] Scn From : Dima Maloff 2:5047/13 29 Oct 97 00:04:00 To : Dieter Ringhofer 30 Oct 97 18:22:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Monday October 27 1997 17:59, Dieter Ringhofer wrote to Slava Filimonov: DR> than i skip zmh with my modems. it's the same for anybody like an ip-only DR> system for a non-ip one. DR> got the point? Why not to skip ZMH? --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1101 [1995] Scn From : Slava Filimonov 2:469/33 29 Oct 97 12:56:46 To : Denis McMahon 30 Oct 97 18:22:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Denis! 28 Oct 97 10:29, Denis McMahon wrote to Rune Johansen: DM> Maybe we need two different types of ip node entry? One for FTN DM> session level transports, and one for RFC based transports? Sounds very attractive ;) -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1102 [1995] Scn From : Dima Maloff 2:5047/13 29 Oct 97 21:32:00 To : Lawrence Garvin 30 Oct 97 18:22:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sunday October 26 1997 18:18, Lawrence Garvin wrote to Rune Johansen: LG> The obvious counter argument to this is that there are also hundreds of LG> nodes in fidonet doing EMSI/FTS-6/FTS-1 over telnet. :) How can you prove? (I can mail you a list of binkp-compatible hosts, go, check them.) LG> in Policy 4, just like many others, but there -is- a reason why there are LG> "minimum standards to be used as fallback". Yes. But there is ABSOLUTELY NO sense to have a common applictaion level protocol for modem connections vs TCP/IP. LG> Nothing says normal daily operations have to use those minimum LG> standards, but the software -does- have to have the capability "just LG> in case". Yes. And today having binkp means "to be compatible". LG> And based on what I've read in the past few hours (messages posted over LG> the past two weeks), BinkD -can- be written to support FTS-0001 LG> connectivity to a telnet-based IP-mailer (such as Binkley/vmodem) -- Argus LG> has proven that. But writing a FTS-1 support takes much more time than for binkp support. Why don't you like free or cheap software? If having binkp support is enough a) to be compatible; b) to be fast; c) to be effective, why not allow binkp only nodes? LG> Just food for thought, but this past week I obtained 'new' licenses for my LG> SIO. The registratio numbers were 10025130 and 10025131. Where do you LG> suppose he started numbering? Also keep in mind that I know he started LG> numbering after v1.15, since my officemate at work has a v1.15 registered LG> by his -name- not a serial number. Who knows why they had to buy Vmodem. But for Fido-over-IP it's the last choice, as far as I see -- almost nobody uses it in R50 to transfer mail. LG> However, the same basic rule still applied. _IF_ two nodes could establish LG> a common communications-link protocol, whatever that may be, we don't LG> care, it was still a -requirement- that both of them be able to negotiate LG> an FTS-0001 MAILER SESSION. No way. For every new environment (at least for those which are really different) new protocols should be allowed. LG> (and those flags will have to be ZC approved, in any case), and the LG> MAILERs _MUST_ be able to negotiate an FTS-0001 session AS A MINIMUM LG> STANDARD. No, thanks. Let FTS-1 be "the must" for your network, not ours :) LG> Note, again, for those with short term memories -- this does NOT mean LG> that they have to actually USE FTS-0001 -- only support it. It should be LG> programmed as a -fallback- negotiation standard, for when nothing else LG> will work. Why waste time/money supporting something that will NEVER be used? --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1103 [1995] Scn From : Dima Maloff 2:5047/13 29 Oct 97 21:33:00 To : Lech Szychowski 30 Oct 97 18:22:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sunday October 26 1997 02:42, Lech Szychowski wrote to Marco d'Itri: >> If they locked themselves with non open software is their own problem, >> not mine. LS> They didn't. We will if we change standards inconsideratly. Wrong. They will have to change something in their systems either way. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1104 [1995] Scn From : Slava Filimonov 2:469/33 29 Oct 97 16:33:56 To : Lech Szychowski 30 Oct 97 18:22:58 Subj : IP-connectivity ------------------------------------------------------------------------------- Hello Lech! 28 Oct 97 05:27, Lech Szychowski wrote to Dieter Ringhofer: LS> No, I don't want to stay just in the Internet. I've been there LS> for many years and I still think Fidonet has several quite serious LS> advantages. People still the main advantage of fido. Everything else are just technial standarts, transport media... as for me, i still here for many years and now i'm just moved to ip-only mode due to my physical location and technical problems. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1105 [1995] Scn From : Marco d'Itri 2:335/680.666 29 Oct 97 21:54:02 To : Lawrence Garvin 30 Oct 97 21:41:52 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >I'd prefer to see BinkP, EMSI, FTS-6, and FTS-1 referred to as -SESSION-, and >TCP (telnet/ftp/smtp), UDP (http), X.75, V.34, and others of that ilk refered >to as -PROTOCOLS-. TCP, X.75, PSTN are transports, not protocols. (http is carried over TCP, not UDP) -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1106 [1995] Scn From : Dieter Ringhofer 2:2476/14 30 Oct 97 19:10:08 To : Dima Maloff 31 Oct 97 05:39:20 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> than i skip zmh with my modems. it's the same for anybody like an DR>> ip-only system for a non-ip one. DR>> got the point? DM> Why not to skip ZMH? because it's the onliest time at which a fidonode has a real chance to connect any other one (if it's not a isdn-only counterpart :( ). there's a direct relation between being listed and this issue, don't forget this. without direct connectivity at a fixed time (read: zmh) there's no listed fidonode for longer terms. if we reach a state of unconnectable systems being accepted as real listed nodes we can say 'good night, fido. wherever you are.'. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1107 [1995] Scn From : Dieter Ringhofer 2:2476/14 30 Oct 97 19:13:50 To : Dima Maloff 31 Oct 97 05:39:20 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DM>>> even if a sysop has paid for FTS-1-style Fido software, it still DM>>> CANNOT do Fido-over-IP. DR>> that's wrong. i can do so and: i don't need any other software than the DR>> one already being set up over here. DM> We are not talking about you. We want to connect as many nodes as DM> possible, aren't we? yes, we are. but think about meaning of 'node' first before trying to beat that horse with arguments like you've used last time. YOU want to have something, other people already have it. to participate at fido does not mean to be a member of it! DM>>> So he has either pay more money for a fossil driver w/TCP/IP DM>>> support, or add free binkd. DR>> nobody told that software development is for free. i BOUGHT several DR>> compilers and i need TIME to write the code. both lead to money. DM> We do not force you to make free software. You do not force us to use DM> non-free software. Deal? That's not point of discussion. Subtopic is to get a common protocol for all media in use to (topic) have a chance to list systems using another medium. You (or '200+ persons') can't expect that 30.000+ people change their programs to do you a favour. We have to use a compliant program if we want to be a member of the club. Additional protocols fitting the needs of a specific medium are another issue. It's similar like using Hydra instead of ZedZap, both implementations offer the chance to use FTS-0001 as fallback commonly triggered by a failing EMSI handshake. Maybe this leads to an understandable example for you: How does Binkd react when a password error occures (caused by a typo)? --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1108 [1995] Scn From : maciej grzeszczuk 2:480/70 29 Oct 97 22:31:44 To : Frank Ellermann 31 Oct 97 05:45:40 Subj : Re: was: Proposal for listing as IP-node ------------------------------------------------------------------------------- From: maciej grzeszczuk Tue, 28 Oct 97 22:31:00 +0100 Frank Ellermann napisal byl w fido.ip_connect: > IP-only nodes, until many nodes supporting both technologies exist. from now on my node supports pstn, vmodem (telnet), raw (ifcico) and binkd (binkp) connections (on it's standard port). 775 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: tak, tak, wanna (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1109 [1995] Scn From : Rune Johansen 2:210/20 30 Oct 97 19:17:00 To : Lech Szychowski 31 Oct 97 05:45:40 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >> It would be the same as a non-secure session uploading a pkt-file with >> the same name as a pkt-file already lying in the inbound directory of >> the mailer. How does the current mailers treat that? Do they overwrite >> the file, or do they rename it? > If this is a pkt file, then it is to be unpacked and processed by the > system, right? Then it makes no difference what name it's given for > the (short) rest of its lifetime. Yes, and that means that if a FTP server renames the file on it's side, it does not matter to the transfer protocol (FTP in this case). --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1110 [1995] Scn From : Rune Johansen 2:210/20 30 Oct 97 19:30:24 To : Slava Filimonov 31 Oct 97 05:45:40 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >> BinkD is the mailer. BinkP is the protocol. I say that BinkP is as >> vulnerable as others running on top of TCP. But, BinkP does not have >> retransmits or checksums included, so they will timeout. > Okay then. Let's forget about technical side for a moment. From usage > statistics side of view binkd with its binkp is more reliable on poor links >than vmodem with its crc and retransmission support. In Russia ip links are no >as good as in europe or america - so by using binkd sysops there vote in favor > of binkp. > in few words - binkp vulnerability is tcp/ip issue. if were tcp/ip were so > vulnerable, why it still spans the globe? Icannot say why for example Zmodem over a telnet protocol or Zmodem over a raw TCP session is more vulnerable than a BinkP session over a raw TCP session. Is it? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1111 [1995] Scn From : maciej grzeszczuk 2:480/70 29 Oct 97 22:37:00 To : Yuri Teterin 31 Oct 97 05:45:40 Subj : Re: FYI - FWIW ------------------------------------------------------------------------------- From: maciej grzeszczuk Fri, 24 Oct 97 20:08:02 +0200 Yuri Teterin napisal byl w fido.ip_connect: > YT>> There was an attempt to implement VMP in Argus too, but it > YT>> was not quite successful. whatever was implemented in argus, it allows connections with my ifcico. one of my link uses argus to fetch ~600kb packets every day with no problems. 776 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: czy mierzyles jej fi dupy? (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1112 [1995] Scn From : Rune Johansen 2:210/20 30 Oct 97 09:49:52 To : Lawrence Garvin 31 Oct 97 05:45:40 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >Any chance I could persuade you to invert your usage of the terms protocol and > session? Yes, that can be done. :-) But, I think it would be more correct to use the terms transport and session. They are both protocols. A protocol is a defined set of terms that both parties agree to. Transport protocol and session protocol. > The SESSION runs on top of the PROTOCOL. No? :) No. Session runs on top of transport. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1113 [1995] Scn From : Rune Johansen 2:210/20 30 Oct 97 19:34:08 To : Slava Filimonov 31 Oct 97 05:45:40 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> than i skip zmh with my modems. it's the same for anybody like an >> ip-only system for a non-ip one. > Modem connectivity stands for established rules. There is no point to change > this. But ip-only system is unique thing, which fidonet parents never dreamed >about. As i said before, it's like riding a horse on a highway. Highway is not > designed for using with horses but it's possible... For those people not having your automobiles on your highway, why would you not build a small horsetrail on the side, so they can use it until they get a automobile? If a horsetrail is the current minimum on a road today, why should the highway refuse to have it? It won't hinder any of the automobiles already running there. It enhances the possibility of people getting on your highway. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1114 [1995] Scn From : Jesper Tragardh 2:200/108.21 03 Nov 97 22:36:50 To : Rune Johansen 31 Oct 97 05:45:40 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- RJ> The Baud field is something I have not considered at all, and is RJ> kept there for compatability reasons. Introducing letters in the "phone"-field will confuse MakeNL anyway. Then why not skip the baud-field. Maximum connect speed can be calculated from the modemflags anyway. If we're going to redefine the nodelist a mechanism for having several "adresses" (in your meaning - replacing the phone-field) per node would be good. /Jesper --- timEd/386 1.10 * Origin: Pinga varandra i IP-trafiken /JL (2:200/108.21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1115 [1995] Scn From : Rune Johansen 2:210/20 30 Oct 97 19:15:30 To : Lech Szychowski 31 Oct 97 05:45:40 Subj : Flags in nodelist ------------------------------------------------------------------------------- > Correction: if you meet any server that is listed as authoritatve > for the zone you are querying, it should not go to the next one. > And I'm in doubt whether I should/could replace "is listed as" > with "claims to be"; most likely not. I think "claims to be" is the correct one here. If it should be "is listed as" you'd have to go to the level above to check if it is listed as an authorative server for that zone. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1116 [1995] Scn From : Rune Johansen 2:210/20 30 Oct 97 19:22:52 To : Lech Szychowski 31 Oct 97 05:45:40 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> compatible protocol. That would mean that the BinkP node should run a >> FTS-0001 capable mailer on a well-konwn port, in addition to the BinkP >> protocol mailer on the BinkP port. > Looks like it will work with no problems. But BinkP people will probably > raise hell about it - and in a way I undestand their reasons. The question that arises then is: How should the fallback port be denoted in the nodelist? To comly with this, the listing of available session protocols on each port must be done. To avoid this, a simple fallback routine in the listening daemon could be implemented. >> top of. There is nothing wrong with using BinkP over a modem connection, >> except for the errorchecking part. > That's a good point. Could we here some more on the performance of > BinkP run over the PSTN connections from someone who uses that kind > of setup? I have not run a full poll with BinkP with lots of files to transfer both ways yet over PSTN, but I will test it someday now. :-) The only problem I would see with it, is if I get a non-error-correcting connect with the other side. That way I could be in serious trouble. But, BinkP assumes error-free connection, so I'll have to see what I can do on the modem side. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1117 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 02:22:28 To : Sean Rima 31 Oct 97 05:46:02 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:39 +0100, Sean Rima said: SR> Strange, I connect to an IFCICO mailer evey day with no problems. There is SR> an addon for Ifcico to allow it to use BinkP which is use by BinkD Where can it be found ? I'm very interested on that. -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1118 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 03:03:40 To : Amir Shabashvili 31 Oct 97 05:46:02 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:47 +0100, Amir Shabashvili said: AS> The better way, IMHO, is got all info about protocol,... from DNS AS> requests, No, because there aren't standard libraries to request any DNS funny field, also it is much more interesting to know the supported protocols before doing the call, when the downlink is not yet even online he looks at the nodelist for a node whith same capabilities as him then connects to the internet and poll. Your method implies that the downlink does all the research while online. -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1119 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 01:25:02 To : Marco d'Itri 31 Oct 97 05:46:02 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:43 +0100, Marco d'Itri said: Md> Using telnet, emsi and zmodem over an IP link is a very stupid decision, I agree about telnet and zmodem, but not about EMSI. Using EMSI packets to identify each other is instead a good think and very easy to implement (I think that all TCP/IP able mailers already have the needed functions to handle EMSI packets) -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1120 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 01:32:02 To : Rune Johansen 31 Oct 97 05:46:02 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:49 +0100, Rune Johansen said: RJ> mailer-session-only protocol, and cannot (as far as I have read the specs) RJ> be used for anything else. But, in a telnet session you can run BinkP as RJ> transfer protocol instead of ZModem. You can run BinkP handshaking instead RJ> of EMSI. You can even use Telix with IEMSI script via vmodem-like RJ> software. You don't need that ! TCP/IP, unlike phone lines, allows for multiple conenctions, so you can do a connection to the mailer and another connection to the BBS. There is no need to stuck the both on the same port, indeed I think it is wrong. That will lead to complexity and problems on programs as they need to be able to detect various different protocols. While if you keep one port per protocol there is no need for all that complexity, the protocol to be expected is determined by the port used. Try thinking on what will be if http, ftp, smtp, nntp, nfs, ... etc use all the same port ? You will need a program that need to know all those protocols and call the right server for each connection. A real taste of what could be the hell... RJ> BinkP is a truly fast and efficient protocol, but it limits itself too RJ> much for future expansion and use It limits itself to what it has been designed to: a FTN mailer protocol. There is absolutely no point in making it handle interactive sessions or things like that. -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1121 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 02:09:50 To : maciej grzeszczuk 31 Oct 97 05:46:02 Subj : Re: BinkD (0.9.2) specification ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:49 +0100, maciej grzeszczuk said: mg> i said that we should specify one standard, available at every ip-node mg> system. and i proposed vmodem. No. vmodem is not technically a good solution, other than that its specifications seems not to be free. Maybe you thought of telnet-vmodem ? It is still technically a hack. The real solutions for a common standard will be BINKP and TCP, both are even available on source code so implementing it could be very easy (not just a cut'n'paste, unless the program onto which you include the code is also to be released in source code and free, that due to licensing binkd is under GPL IIRC. But having the source code of a working implementation can help tremendously in understanding the protocol if some commercial mailer wants to implement it and don't release the source code) However, I don't think you should enforce any protocol now, just document: * the (user) flags to be used in the nodelist to tell of a given capacity * the way of retrieving the internet address of the node. Then nodes whith common protocols can poll each other. imposing a standard now will de facto create less connectivity than before. I suggest we only document the above then allowing for better connectivity by allowing the info to reach the nodes. Then if the TCP/IP channel gets popular the standards will automatically emerge by themselves. Think of TCP/IP nodes as ISDN ones; there is no obligation to support a given type of ISDN protocol to have the ISDN capabilities listed. So it should be for IP nodes. As for the documenting I think of something like: * (user) flags: IFC : ifcico-compatible, port 60177 BINKP : binkp-compatible, port ???? IPTEL : telnet-vmodem, port 23 VMP : vmodem, port ???? whith that flags beeing able of having a =XXX appended where XXX is a port number when it differs from the standard for the given protocol IPTxy : Same as the actual Txy flag, but denoting internet online time. while the abscence of Txy flags imply ZMH only, the abscence of IPTxy should imply it is 24h/24 on the internet (so no need for a IPCM ;-) ) * how to get the internet addres: convert to f...n...z...domain and use the DNS to get the A records. the domain for fidonet being "fidonet.org", up to other FTN networks to get their own. The mailers should use gethostbyname() instead of a lower level function directly requesting the DNS, so people can define local name->IPaddress rules (in /etc/hostname on unix, MS-Windows has the same file but on another place I forget) for nodes not on the DNS (because they aren't yet listed (new IP nodes) or they don't wan't to, or the DNS keeper doesn't wan't to or because there is anothr FTN network whithout a registered domain) -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1122 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 02:31:14 To : Rune Johansen 31 Oct 97 05:46:02 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:41 +0100, Rune Johansen said: > Why not a "raw socket"? RJ> Because of that we should consider a possibility that there is a BBS RJ> running behind the mailer. No. That is nonsense. That is the result of conceptions that doesn't take in account the nature of TCP/IP ! The mailer uses one protocol on one port, and the interactive session (aka BBS) uses another. The cases where there is a mailer and BBS on telnet or vmodem is because those programs ARE NOT internet able programs, they still thing they are using a modem and a phone line. But IMHO that is using a MS-Windows emulator on Macintosh or DOS 16 bits programs on WinNT, it is a hack, a workaround, but not a serious long term solution. The way to go is to add internet functionality to the programs to make them use the advantages of it. RJ> used by endusers to connect to the BBS. If we use raw socket as minimum RJ> protocol (if it should be some minimum protocol), they have to use RJ> specific software to connect. They have to anyway ! You can't just use a normal modem mailer on a telnet client. You need a special maler supporting vmodem or telnet. So as it is needed to get a new mailer anyway why not to get one that fully uses the medium capabilities instead of one that downgrade the performances ? -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1123 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 02:53:48 To : Slava Filimonov 31 Oct 97 05:46:02 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:45 +0100, Slava Filimonov said: SF> it's time to make faq for this echo ;) about ifcico: http://www.average.org/ifmail/ http://www.z2.fidonet.org/ifmail-tx/ IFC mailers for OS/2 and win32 can maybe be found somewhere at http://www.stben.be/ -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1124 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 02:20:40 To : maciej grzeszczuk 31 Oct 97 05:46:02 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:41 +0100, maciej grzeszczuk said: > Do you suggest FTS-0001 session via VModem as the standard? mg> yes. it's simple on all software / hardware platforms. That's wrong. There are binkd and IFC mailers that do *only* binkd or IFC, not telnet nor vmodem, much less fts-0001 or even yoohoo ! Imposign such "standards" will have as a consequence that IP nodes won't register as such to still be able to freely use the protocol they want. And the situation won't improve, it will be just as now :-( -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1125 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 02:34:20 To : Slava Filimonov 31 Oct 97 05:46:02 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:45 +0100, Slava Filimonov said: SF> We're talking about ip-connectivity isn't it ? As long as you use SF> BINK-style outboud, you can keep your old phone mailer and add binkd SF> mailer to exchange fido over ip. BTW is there any TCP/IP able mailer that uses otherthing than a binkley compatible in/outbound tree ? I know of none. -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1126 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 02:49:06 To : Sean Rima 31 Oct 97 05:46:02 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:44 +0100, Sean Rima said: SR> Just a curious question. How many IFCICO mailers are there live on the SR> Net. I am curious. That is impossible to tell until a standard on how to put that data on the nodelist isn't built. >> binkd isn't compatible with any of the stuff listed, and more - it >> isn't compatible with anything else. and it won't. The programs doesn't matter, only the protocols, so I suppose you meant binkp. Well, binkp is only copatible whith itself.... that's also the case for all others, IFC is only compatible whith IFC, VMP is only compatible whith VMP and telnet is only compatible whith telnet :) -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1127 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 01:06:42 To : Lech Szychowski 31 Oct 97 05:46:04 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:38 +0100, Lech Szychowski said: LS> If above is true (I'm not implying it is not - I am just not sure) LS> vmodem is a better choice. No. Because vmodem is encapsulating protocols designed for modems; vmodem isn't very happy whith the irregular flow, slow downs and latences that can be experienced on internet connections. I use ifcico to poll a node in zone 4, sometimes the cps drops to less than 100, it is blocked, then restarts again, whith ifcico native protocol (call it IFC for now) I manage to get the files and send mines anyway; but I fear that whith vmodem that wouldn't be the case whithout dropping of mailer connection. -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1128 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 01:14:38 To : Lech Szychowski 31 Oct 97 05:46:04 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:50 +0100, Lech Szychowski said: >> Which other implementations of Vmodem are available for other operating >> systems and especially where is the source published? LS> The "tx" version of ifmail claims to be vmodem compatible: It is in fact "telnet-vmodem", not the real Vmodem. I don't know the differences between the two so I jsut stick to the terminology used by the author of the patches that added that "telnet-vmodem" support. LS> Ifmail README file says as follows: LS> : There is also a special protocol optimized to use over TCP/IP LS> connection, : contributed by Stanislav Voronyi , it LS> is identified : by EMSI proto code TCP (not registered). LS> So I think it might be worthwile to take a closer look there. BTW, what are the codes used by other TCP/IP protocols on EMSI ? ifcico compatibles use "TCP", what uses binkp ? Vmodem and telnet-vmodem seem to use nothing as their philosophy is to make the mailer think it uses a real phone line. But maybe it isn't impossible to use protocol codes for raw TCP connections and have the mailers use the better common TCP protocol ? -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1129 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 01:00:16 To : Pedro Lima 31 Oct 97 05:46:04 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:40 +0100, Pedro Lima said: PL> Agreed, but we're only talking about the z2.fidonet.org domain. The reason is that it is already done in z2.fidonet.org, while on other zones DNS there are only MX entries (=Mail eXchangers=internet->fido mail gateways) and not A entries (=IP addresses=fidonet nodes TCP/IP pollables). The z2.fidonet.org is thus an exemple, in "real life" of what we are trying to standardize here, hence the many references to it. But I think that if it is standardized and works well the other zones DNS will follow. -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1130 [1995] Rcv Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 02:13:52 To : Lothar Behet 31 Oct 97 05:46:04 Subj : Re: IP-Test 2:2/3000 ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:37 +0100, Lothar Behet said: LB> ;S VM Vmodem (default port 3141) VMP seems more current practice. also this one: ;S IPTEL telnet (default port 23) (just TEL isn't acceptable here as it conflicts whith Txy flag telling online time !) -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1131 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 00:50:42 To : Lech Szychowski 31 Oct 97 05:46:04 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! Lech Szychowski said: LS> BTW: Do you happen to know why Pablo is not active here? I'm here now, thanks to Ask Bjoern Hansen who is now my uplink.... ...trough TCP/IP :) -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1132 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 01:34:16 To : Marco d'Itri 31 Oct 97 05:46:04 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:52 +0100, Marco d'Itri said: Md> I don't think ifmail-tx is compatible with the vmodem protocol, it can do Md> just ftn over telnet: indeed Md> tfido stream tcp nowait fnet /usr/lib/ifmail/ifcico ifcico -t1 Md> vmodem stream tcp nowait fnet /usr/lib/ifmail/ifcico ifcico -t1 Md> the suggested command lines are not different. BTW, does anyone tested it on real life ? I use "ifcico -t1" successfuly on outgoing calls but I don't know how it performs on incoming ones. -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1133 [1995] Scn From : Pablo Saratxaga 2:293/2219 29 Oct 97 01:40:42 To : Marco d'Itri 31 Oct 97 05:46:04 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 00:20:42 +0100, Marco d'Itri said: Md> Anyway I think your solution is too difficult to implement. If we require Md> that all mailers will have to be modified to support IP (instead of using Not all mailers, only those wanting to communicate over TCP/IP. Such a mailer will most probably be linked against a library containing tcpip functions, on such libraries there is a function called gethostbyname() so the only extra work is to add a little function to convert the Z:NN/FFF[.PPP]@FTNDOMAIN to [pPPP.]fFFFF.nNNNN.zZZZ.internetdomain such a function is really trivial to write. Anyway to talk about a TCP/IP mailer that can't or wan't use DNS resolver functions sounds like a joke to me. The only real extra work is to add a method to get the internet address. But that extra work has to be done anyway as almost any program uses its own different and incompatible method, so when a standard will emerge the extra work would be needed anyway, so why not to use the more obvious and natural solution ? -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1134 [1995] Scn From : Rune Johansen 2:210/20 30 Oct 97 22:58:24 To : Jesper Tragardh 01 Nov 97 09:20:14 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- >> The Baud field is something I have not considered at all, and is >> kept there for compatability reasons. > Introducing letters in the "phone"-field will confuse MakeNL anyway. Then why > not skip the baud-field. Maximum connect speed can be calculated from the > modemflags anyway. My proposal only "redefines" the use of one field. It does not take away any filed, nor does it add any fields. To redefine the field, a change to FTS-0005 would be needed, to allow for other chars than numbers and dashes. The need for the baud field is a completely different discussion. For this echo's topic, we want to find a way to integrate IP connectivity into the nodelist, not reform the whole nodelist :-)) --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1135 [1995] Scn From : Pedro Lima 2:362/21 30 Oct 97 19:58:38 To : Chris Maddock 01 Nov 97 09:20:14 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hello, CM> Correct. The only problem may be with a new node incorrectly setting CM> up their software. The same would apply with the current situation. E.g. if I decided to translate the '351' prefix to '115' then every time I tried to poll a portuguese node I'd be calling the emergency service... :-) That's why I think that the '000' prefix solution is addressing a problem that should not exist. But as it does, and as we can avoid most of its drawbacks with a simple solution, then why not? CM> Okay. You are referring to hubs, *EC's etc I guess ?? For example. CM> Yes. But Fidonet only =is= a limitation. CM> We are proposing to add the internet to our capabilities. Or is that CM> what you meant ? I'm not sure of what you're saying here. If you're saying that using solely the telephone network is a limitation, yes, I agree, and I also think it's fairly easy to extend the possibilities for a FidoNet connection, such as using the Internet. In the case of the Internet, I see no need to limit the FQDN possibilities, since that would be similar, in the case of the PSTN, to only allow the numbers of certain telcos into the nodelist. CM> Seeing the amount of discussion here is great ! It's specially the overall quality of the discussion I'm liking. :-) Lets see what we can do to help. That's the FidoNet spirit. :-) Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1136 [1995] Scn From : Nick Soveiko 2:5030/23.101 29 Oct 97 14:58:38 To : Lech Szychowski 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Tue, 28 Oct 1997, 05:38, Lech Szychowski (2:480/33.7) ==> Yuri Teterin: > TCP) and so will improve its connection with ifcico only (but ifcico- > based nodes have now no problems with binkp - they just run additionaly > binkd and are happy). LS> Could you point me to sources for this mailer/daemon? I'm genuinely LS> interested in trying it out in my system. which one? ifcico is the mailer part of ifmail package http://www.average.org/ifmail/ (if i recall the url correctly) latest binkd can be found at http://www.magadan.su/~maloff/binkd/. a 0.9.2 release is coming anytime now. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1137 [1995] Scn From : Nick Soveiko 2:5030/23.101 29 Oct 97 15:46:40 To : Lech Szychowski 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Tue, 28 Oct 1997, 05:46, Lech Szychowski (2:480/33.7) ==> Lawrence Garvin: > the past two weeks), BinkD -can- be written to support FTS-0001 > connectivity to a telnet-based IP-mailer (such as Binkley/vmodem) -- > Argus has proven that. LS> If this is actually true, why not make ifcico support BinkP and LS> declare (both or any) FTS-0001 over raw socket and BibkP the LS> standard we're talking about? the problem with ifcico that it's not really portable. i mean, it compiles fine under major *nix flavours, but that's it. so, it might be actually easier to incorporate protocol part of ifcico into binkd. but even this would require some serious hacking. now this could make a truly ip-capable mailer that no one would probably object. any volunteers out here? cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1138 [1995] Scn From : Nick Soveiko 2:5030/23.101 29 Oct 97 18:59:34 To : Yuri Teterin 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wed, 29 Oct 1997, 12:01, Yuri Teterin (2:5030/239) ==> Lawrence Garvin: LG> I suspect that if you took a look at the file-transfer protocols used in LG> association with those FTS-0001 sessions, you'll find that their LG> nature is such that they -need- to have a TCP connection, and will LG> not be able to function adequately across a UDP connection. YT> Why not? FTS-0001 does not suppose that the connection is YT> error-free. And any non-errorfree connection can be implemented YT> very well with help of UDP. i think the question here is connection-oriented vs connectionless. there's a provision in fts-0001 to monitor modem carrier - read active connection. yes, it's possible to hack it by simulating always high cd and relying upon timeouts only. but thats a hack. speaking about flexibility of current fidonet standards... cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1139 [1995] Scn From : Vilo Mlich 2:421/50 30 Oct 97 12:29:00 To : Lawrence Garvin 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Lawrence! 27.10.1997 21:47, Lawrence Garvin wrote to Yuri Teterin: LG> Yes, but please do not confuse COMMUNICATIONS PROTOCOL with FIDO MAILER LG> SESSION. Protocol is things like V.34, X.75, HST, vmp, telnet, ftp, etc. LG> Sesssion is things like FTS-0001, FTS-0006, EMSI. LG> Session works independently of Protocol, and a given session should be LG> available on -all- protocols supported. Protocols are listed in the Flags LG> field of the nodelist. Session is something mandated by policy and Fidonet LG> Technical Standards. The two are not the same thing. What is BinkP here, session or protocol? regards Vilo vmlich@mbox.vol.cz --- GoldED 2.50.Beta5+ * Origin: T-Mail support node (2:421/50) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1140 [1995] Scn From : Yuri Teterin 2:5030/239 30 Oct 97 16:51:38 To : Dieter Ringhofer 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Dieter ! Mon Oct 27 1997 Dieter Ringhofer writes to Slava Filimonov: DR> than i skip zmh with my modems. it's the same for anybody like an ip-only DR> system for a non-ip one. DR> got the point? Or like an ISDN-only system for a non-ISDN one. But there are already about 600 ISDN-only systems in nodelist, and nobody complain on this fact. Got the point? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1141 [1995] Scn From : Slava Filimonov 2:469/33 30 Oct 97 11:45:10 To : Rune Johansen 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Rune! 29 Oct 97 01:19, Rune Johansen wrote to Yuri Teterin: RJ> I, for one, would be satisfied if BinkP implementations would have the RJ> possibility to fall back to the FTS-1 (and other) protocols regardless RJ> of the transport in runs on top of. That means that you could use RJ> BinkP over other things too, like a modem line, or X.25 or... But it's almost obvious to use each protocol in area for which it was designed. Otherwise you'll loose all protocol benefits. What about me, i'd like to use different tcp/ip ports for FTS-1/FTS-whatsoever and standalone port with BinkP so FTS-1 realisation in binkp will not screw it up completely... In such case 'fallback' is not required - because 'fallback' comes from protocol stack on single modem port. Do we really out of tcp/ip protocol ports? -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1142 [1995] Scn From : Slava Filimonov 2:469/33 30 Oct 97 12:06:10 To : Rune Johansen 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Rune! 29 Oct 97 02:12, Rune Johansen wrote to Nick Soveiko: >> i second the ridiculousness. RJ> Just because BinkD in it's current implementation cannot do fallback RJ> to FTS-1 when it is a called party? What does it take to implement a RJ> simple FTS-1 fallback routine into BinkD, to make it able to receive RJ> all mailers that can do raw TCP? Compared to implementing BinkP RJ> protocol in all mailers that would be considered doing connections RJ> over a (possibly FOSSIL-compliant) raw TCP "dialer"? Let's not be ridiculous twice - we can use _another_ port for FTS-* and BinkP on it's own in single program/daemon. Why all of you stuck on word FALLBACK? what's wrong to have separate protocols on separate ports? Just imagine TCP/IP having one port and FALLBACK to FTP/HTTP/SMTP/POP3/all other protocols... -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1143 [1995] Scn From : Dima Maloff 2:5047/13 30 Oct 97 13:45:00 To : Lech Szychowski 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Tuesday October 28 1997 04:51, Lech Szychowski wrote to Yuri Teterin: >> now you suggest just opposite solution - to get such standards that make >> software more complicated, transfer file slower and require more >> resources. So why are you surprised that other people do not like to >> support such a proposal? LS> Because by setting new standards totally incompatible with the LS> older/existing ones (and with no fallback to those older ones) LS> you are seriously limiting connectivity. In Fido-over-IP there is nothing to be compatible with. Either way (vmodem or binkp) demands additional software. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1144 [1995] Scn From : Dima Maloff 2:5047/13 30 Oct 97 13:47:00 To : Lech Szychowski 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Tuesday October 28 1997 04:56, Lech Szychowski wrote to Dima Maloff: >> Hm. I just wanted to say that "FTS-1 over IP improves connectivity" >> argument should not be used as it's not true. LS> Well, it does not improve connectivity with binkp nodes. LS> But it allowes for using existing mailers - Binkd allowes you to use your existing mailer too. LS> if you want a twisted example - running over a named pipe piggybacked LS> to a raw socket connection :) The same with binkp. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1145 [1995] Scn From : Yuri Teterin 2:5030/239 30 Oct 97 14:50:16 To : Rune Johansen 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Mon Oct 27 1997 Rune Johansen writes to Yuri Teterin: RJ> As I have stated in my 1st proposal, I have changed a little in my views. RJ> I now consider BinkP as a protocol alongside EMSI, FTS-6 and FTS-1 over a RJ> raw TCP session. Your proposal is logicaly true. The only disadvantage is that it does not reflect the requirements of the real life, so it will not be used by at least 1/2 of IP-nodes. RJ> As long as BinkD cannot do FTS-1 fallback, it will not meet the RJ> requirements of a Fidonet Nodestatus. If you have a mailer that has got RJ> the fallback, you can use it. But it can be stated rather definitely that none of existing mailers run BinkP and FTS-0001 at the same port, and there is no reasons to suspect that some mailer will ever do this. So your proposal will actualy cut all BinkP-based part of FIDO and leave it out of nodelist. This can not force somebody to add FTS-0001 compatibility to they BinkP implementation, but will force all BinkP-comunity to relay on themselves only and develop they own structures with own nodelist (or Binkp-list, or own DNS, supporting first of all BinkP-nodes), may be - with own policy of mail routing. These are not just the words. All these processes run in ex-SU now. If new proposals concerning IP-nodes will not be usefull for BinkP sysops and authors of FIDO software (and yours definitely aren't), they just will not be taken into account. As a result all IP-sysops will be divided into 2 separate groups without common interests, that will develop separately and independantly. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1146 [1995] Scn From : Yuri Teterin 2:5030/239 30 Oct 97 16:27:28 To : Lech Szychowski 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lech ! Sun Oct 26 1997 Lech Szychowski writes to Rune Johansen: >> The basis question is still valid: Should the IP nodes have at least one >> protocol in common? LS> Are you seriously afraid that not everyone agrees with this statement? LS> Well, if your doubts are true we are in big trouble... We tried to explain here for rather long time that this is desirable but not obligatory, as far as we are forced to look at IP-flags in nodelist in any case. And the idea of running FTS-0001 over _some_ transport protocol has nothing in common with the idea "any IP nodes should have at least one protocol in common". Indeed, what is the difference from the point of view of a node, supporting FTS-0001 over raw TCP only (i.e. IFC-only node), between telnet-only (IPT), Vmodem-only (VM) or BinkP-only (BNP) nodes? In any case it is unable to connect any of them. And if it should in any case separate from nodelist only nodes with IFC (IPR) flag - how can nodes with BNP flag make harm to it? Why are they worse than VMP-only or IPT-only nodes? The connectivity will be the same for all of them. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1147 [1995] Scn From : Kim Heino 2:222/0 30 Oct 97 23:02:12 To : Nick Soveiko 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Or, do considerer FTS-001 over raw socket as the minimal requirement? > afaik, only ifcico is capable of doing this. BBBS can do that too. But the question is still valid, which one is the minimal requirement: FTS-001 over raw or FTS-001 over telnet? In my opinion, it's ok if a node can do raw OR telnet. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1148 [1995] Scn From : Kim Heino 2:222/0 30 Oct 97 22:31:20 To : Yuri Teterin 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Secondary, to use TRANSMIT-BINARY option we must: > 1) enter this mode (and why are you sure it will be accepted by remote?) > 2) set some other parameters of the chanel like echo and so on > 3) be ready to process other telnet commands (what commands?) during the > session. Sure, so what? This is a job of telnet-module/program/gateway/whatever, not a job of a mailer's FTS-001/EMSI/whatever module. If the telnet-module can't get the session it wants (binary, no echo, sga) then it reports "NO CARRIER" to the mailer module, just like with modems. No harm done. > which commands of telnet protocol should be supported > and when and how shold they be processed. We have rfc's for that. If your telnet-module wants option x and mine refuses to do it, then they still can try to send the data, or report failure, depending on the option. Is there a telnetd which does not support binary, no echo and sga options? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1149 [1995] Scn From : Pedro Lima 2:362/21 31 Oct 97 01:31:28 To : Denis McMahon 01 Nov 97 09:20:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DM> Hey, we agree on something. That's a big day for this echo - two DM> people agree :-) :-) Actually, it happened before... Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1150 [1995] Scn From : Amir Shabashvili 2:5049/12 30 Oct 97 13:11:28 To : Frank Ellermann 01 Nov 97 09:20:14 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Hello Frank! Replying to a message from Frank Ellermann to Amir Shabashvili: FE> [special region or net(s)] AS>> (or zones) ;) FE> ... could be a problem with moving echomail. The actual versions FE> of FSC-0074 and 93 don't support interzone cyclic path detection. But, if we use really organized echomail-gates between zones, there is no problemo. FE> So before end of next year we'll better don't try tricks with new FE> zones, unless R2:50 volunteers as test-zone 7 perhaps... :-) Bye ! :) When I using zone7 (r50-test-zone) echomail, I've no problems with it Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1151 [1995] Scn From : Slava Filimonov 2:469/33 30 Oct 97 09:48:28 To : Lech Szychowski 01 Nov 97 09:20:14 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Lech! 29 Oct 97 09:00, Lech Szychowski wrote to Slava Filimonov: >> if tcp/ip were so vulnerable, why it still spans the globe? LS> Because it's a damn simple protocol when compared to other ones. LS> And the error checking/corrections it supports (plus packet LS> resequencing if necessary) is enough for most apllication. LS> Although there are tcp/ip based protocol/applications that LS> do their own checking, rigth? It's like damn simple binkp compared to other ones ;)). -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1152 [1995] Scn From : Pedro Lima 2:362/21 31 Oct 97 01:32:16 To : Frank Ellermann 01 Nov 97 09:20:14 Subj : was: Proposal for listing as IP-node ------------------------------------------------------------------------------- FE> For the beginning we're most probably better off, if we FE> either collect such nodes in special IP-"areas", or if we discourage FE> IP-only nodes, until many nodes supporting both technologies exist. I think these are "political" decisions, and that they can be left, at least for the time being, to the discretion of the *Cs. The technical format by which IP nodes appear must be defined beforehand, though. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1153 [1995] Scn From : Dima Maloff 2:5047/13 30 Oct 97 13:43:00 To : Lech Szychowski 01 Nov 97 09:20:14 Subj : FYI - FWIW ------------------------------------------------------------------------------- Tuesday October 28 1997 04:49, Lech Szychowski wrote to Yuri Teterin: >> Argus exists for Win32 only and is shareware, not free. LS> Oh, yeah? So we are back to the "the only (free multiplatform) mailer LS> to support BinkP is BinkD" situation? So what? There is no free vmodem-like driver for, say, OS/2 at all. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1154 [1995] Scn From : Rune Johansen 2:210/20 31 Oct 97 00:46:18 To : Marco d'Itri 01 Nov 97 09:20:14 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- > TEL is wrong, but I think we should use TELN because it's already in use in > some networks and is easy to understand. To try to make IP flags coherent, I will suggest using a prefix of IP to all of them, like Kim suggested. IPT - Telnet, IPR - Raw TCP, IPV - Vmodem Protocol, IPI - Raw TCP Ifcico proprietary (?) > I don't think there are programs so broken to misparse TELN as a Txy flag, it > this is true we would have to outlaw all T* headers. That is what I am trying to do. Outlaw them all. :-)) > Please note that the current use of the IFC flag implies supporting the > RAW flag (i.e. what you described) and an optimized communication protocol > proprietary of ifcico. Ifcico has to my knowledge fallback to both FTS-1 and EMSI. But, by indication a IPI flag, we would have that one included as well. If ifcico protocol is not supported, a IPR flag would suffice. In all the transport protocols I describe, I assume a fallback to the current minimum common sessions protocol as defined by policy of the FTN network. For Fidonet today that is FTS-0001. For Othernets that could be EMSI (or BinkP for that sake). Beware that the flags can be longer, if needed. Like: IPTEL, IPVMP, IPIFC if we run out of A-Z letters :-)) >> So, if I run a raw TCP mailer capable of EMSI only, I would like to run the >> flag EMSI to denote that: > I don't think is useful adding that. True. So, a BinkP flag would also not be useful, if EMSI is not. > (I agree about other issues, your proposal looks very good.) Thanks. I intend to get Ward to use these flags in the listing of 2:2/3011 when he comes back from his business trip. The only problem is, for me to let BinkP nodes poll me, I have to use one port explicitly for BinkP, since current BinkD mailer cannot autodetect my BinkP capability when I answer. So, I'll add a BinkP flag just for the testing of it. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1155 [1995] Scn From : Pablo Saratxaga 2:293/2219 30 Oct 97 03:45:22 To : Lawrence Garvin 01 Nov 97 09:20:58 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Mon, 27 Oct 97 21:47:36 +0100, Lawrence Garvin said: RJ>>> should be at least one common protocol for IP nodes. YT>> This is desirable but not necessary. LG> It most certainly -is- necessary, Yuri. It's -mandated- by Fidonet Policy LG> 4, and until you can get enough RC's to agree to drop that FTS-0001 LG> requirement from Fidonet Policy 4, -WE- have no choice in the matter. No, as long as a given node has a POTS line whith a fts-0001 mailer on it that's OK. There is no need to force a common protocol on other transport layers. I can even say it will be stupid to do so at this stage as the effect of that will be to put a break on any developpement for better suited protocols for new transport layers. LG> Yes, but please do not confuse COMMUNICATIONS PROTOCOL with FIDO MAILER LG> SESSION. Protocol is things like V.34, X.75, HST, vmp, telnet, ftp, etc. LG> Sesssion is things like FTS-0001, FTS-0006, EMSI. THe fidonet mailer session can be a part of the protocol, for a transport like internet that makes sense. -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1156 [1995] Scn From : Pablo Saratxaga 2:293/2219 30 Oct 97 06:43:40 To : Yuri Teterin 01 Nov 97 09:20:58 Subj : Re: BinkD (0.9.2) specification ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Thu, 16 Oct 97 23:23:22 +0200, Yuri Teterin said: NS>> apart from ifcico, which exists for *nix only (and i'm not NS>> sure if it supports *fts-0001* sessions anyway), YT> It does, but for TCP-connection only ;-) That's not true, I just checked the sources of mgetty and it does detect TSYNC and YOOHOO. -- A bient“t, Pablo Saratxaga --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1157 [1995] Scn From : Pablo Saratxaga 2:293/2219 30 Oct 97 03:41:10 To : Yuri Teterin 01 Nov 97 09:20:58 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Sun, 26 Oct 97 15:08:58 +0100, Yuri Teterin said: RJ>> should be at least one common protocol for IP nodes. YT> This is desirable but not necessary. Is we decide to use flags like YT> IFC, BNP, VMP in nodelist, each node can calculate all common protocols YT> for destination node and make the call at most appropriate one. I second your motion. The first step is to define a way to list the various protocols that exist. Once they are listed their use will increase and standards will automatically emerge. -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1158 [1995] Scn From : Pablo Saratxaga 2:293/2219 30 Oct 97 05:14:20 To : Lech Szychowski 01 Nov 97 09:20:58 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 21:40:34 +0100, Lech Szychowski said: >> LS> vmodem 666/tcp # (Vmodem) port used on OS/2 and LS> Windows >> From which source did you retrieve port 666? LS> It is a quote from some software included in the ifmail_tx package. And is more likely wrong. I'll delete that. -- A bient“t, Pablo Saratxaga :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1159 [1995] Scn From : Pablo Saratxaga 2:293/2219 30 Oct 97 04:49:42 To : Dmitry Arsh 01 Nov 97 09:20:58 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 21:40:38 +0100, Dmitry Arsh said: DA> AFAIU, you need something answering SMTP on port 25 to be listed in DA> .fidonet.org. Are you sure ? I think you are wrong. However if you put an A entry (=IP address) for a name xyz you then need to also put one or more MX entries (=machines to send the email to) for the xyz and maybe *.xyz (if applicable. in the case of the fidonet names you must remember to have an MX for *.f...n...z.. otherwise points won't get the mail). This should be perfectly valid: f999.n5100.z2.fidonet.org. A 123.45.67.89 MX 10 somewhere.else.net MX 20 and.another.one.ru *.f999.n5100.z2.fidonet.org. MX 10 somewhere.else.net MX 20 and.another.one.ru However a machine that can put a fido mailer for incoming mail can more probably put a smtp server too, so most put themselves as main MX for them; it is more practical and fast. -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1160 [1995] Scn From : Pablo Saratxaga 2:293/2219 30 Oct 97 03:09:04 To : Marco d'Itri 01 Nov 97 09:20:58 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 21:40:40 +0100, Marco d'Itri said: Md> For ISDN you will get another node numeber, No. Most ISDN nodes just use one single node number for both PSTN and ISDN, there is no need to have a new aka (unless you want to feel important by having two or more line on the nodelist :) ) Md> why you don't want one for IP? I don't know why he doesn't want, but I don't want it because I think it is futile and non practical (is much easier to remember that Mr XYZ is node number 123 than that Mr ABS is 145 and 58 and 125 and ...) Other than that I think that the current policy about nodelisting is to avoid useless akas. -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1161 [1995] Scn From : Pablo Saratxaga 2:293/2219 30 Oct 97 05:06:18 To : Lech Szychowski 01 Nov 97 09:20:58 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Mon, 20 Oct 97 02:44:00 +0200, Lech Szychowski said: LS> But then we have a very unefficient situation: a Z:N/F node capable LS> of handling SMTP is not listed as the MX for *.fF.nN.zZ.fidonet.org That is more efficient that not having it listed at all. Before: email sent to the MX, no mailer connections. After: email sent to the MX, mailer connections. I have to disagree but I think it is much more efficient instead ! LS> - or we have to maintain two MX records instad of one. In any case, there should be at least two MX. LS> BTW: if there is an A record for an FQDN, there is no point in LS> listing an MX record for this FQDN (unless we explicitely want Each fqdn that wants to receive email *MUST* have an MX, it can point to itseld. But whithout an MX there is no guarantee at all that mail will be sent. In other words: f33.n480.z2.fidonet.org. A 123.45.67.89 is wrong. f33.n480.z2.fidonet.org. A 123.45.67.89 MX 1 f33.n480.z2.fidonet.org. MX 10 elsewhere.net. * MX 10 f33.n480.z2.fidonet.org. MX 20 elsewhere.net. is right -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 #! rnews 1262 Path: news.chanae.stben.be!not---- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1162 [1995] Scn From : Pablo Saratxaga 2:293/2219 30 Oct 97 04:58:10 To : Lawrence Garvin 01 Nov 97 09:20:58 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 21:40:28 +0100, Lawrence Garvin said: LG> Another option that regions might consider pursuing is registration of LG> FIDONET.XX in each region where the domain is the country-level domain, LG> such as FIDONET.UK, FIDONET.DE, FIDONET.FR, FIDONET.PL, etc. No, that can't be done. Each country jas its owns policies about fqdn and some doesn't allow names just after the country name, there should be fidonet.or.xx for exemple. Others don't allow for names that don't belong to companies, there is also the posibility of the name already registered by someone else (a company selling dogs' food for exemple :) ) -- A bient“t, Pablo Saratxaga fido.belg.* ? Visitez http://www.z2.fidonet.org/news/fido.belg.news/ :wq ;-) PGP Key available, key ID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1163 [1995] Scn From : Lawrence Garvin 1:106/6018 30 Oct 97 20:37:08 To : Rune Johansen 01 Nov 97 09:22:18 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: > Just food for thought, but this past week I obtained 'new' licenses > for my SIO The registration numbers were 10025130 and 10025131. Where > do you suppose he started numbering? RJ> 1002500 ?? :-)) Well.... now that I've baited you, let me give you some more information. Earlier this year when I sent in my check and request for the two licenses, it got misinterpreted and I was sent a single 10-user license. The 'new' licenses I obtained this week were 'replacements' for the original one I received. The original 10-user license, however, was numbered 10024422, which means that it started a bit back before 10025000. :) Yeah? I'm skeptical that he's registered 25,000 of these things, but I think it highly likely that he's registered in excess of 5,000 of 'em. So my gut feeling is that he started at 10020000 -- and, as I suggested a few messages ago, I suspect the registered copies is about 1/3 the total number of users. In any event, though.. it sure puts the lid down on a "hundreds" of BinkD users. > However, the same basic rule still applied. _IF_ two nodes could > establish a common communications-link protocol, whatever that may > be, we don't care, it was still a -requirement- that both of them be > able to negotiate an FTS-0001 MAILER SESSION. RJ> You are correct here. I would like to extend it a little, with the RJ> special case of IP based systems. Since you can have several RJ> daemons listening on different ports, you would only need to RJ> negotiate a FTS-0001 session on _one_ of them. This is a point that I'd lost track of as well, because there are multiple ports available, unlike PSTN. RJ> The question is then: wich one, and how do I find it? The simplest RJ> solution is to make the daemon fallback to FTS-0001 if it does not RJ> manage to make a handshake of it's own kind. My gut feeling is that the "lowest common denominator" is FTS-0001 over telnet, listening on port 23. > The only remaining questions to be determined is -- where does the IP > number or FQDN go in the nodelist source -- and who's going to write > the nodelist generator(s), nodelist compiler(s), and mailer > modification(s) that will allow US to use these new features. RJ> According to my 1st proposal, it would be an address field, where RJ> the phone number is located today. The flags would show what type RJ> of address there is in the addres field, and your mailer would act RJ> accordingly. If the mailer does not have the option to connect to RJ> that type of address (PSTN trying to call ISDN only, or PSTN trying RJ> to call IP), then the connection cannot be made. It's a fact in RJ> today's nodelist. My only problem with this Rune, is how does one deal with the desire to have the -same- node number on both the PSTN node and the IP node? I'm not sure I'm enthralled with the idea of having to maintain a second identity, just so I can add Fido-IP connectivity to my single existing node. RJ> When it comes to nodelist generators, I have not played around with RJ> nlmake enough yet, to tell if it can do the job already. Nodelist RJ> compilers would be the task of existing compiler programmers, RJ> and/or the mailer programmers themselves. Well, we might want to see about soliciting/encouraging one or more of 'em to get involved with this process, before we discover we've created a monster that we can't even implement until months down the road 'cuz nobody's committed to writing software. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1164 [1995] Scn From : Lawrence Garvin 1:106/6018 30 Oct 97 20:52:10 To : Denis McMahon 01 Nov 97 09:22:18 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Denis McMahon said in a message to Lawrence Garvin: DM> Rubbish. FTP has been used for fidonet data transfer for some time, DM> as has SMTP. The fact that it is used and it works shows that the DM> problem you are trying to invent either does not occur, or is not DM> insurmountable. LG> Whether it works, or not, or any other related concept is LG> irrelevant. LG> What is -relevant- is can the FTN MAILER do anything useful with LG> that information, and until somebody provides for replaceable LG> parameters in the config files of FIFTP or other utilities, I'd say LG> the answer is no. DM> Not at all, if the anon inbound is examined after every session, DM> then any arcmail and pkt files can be processed or moved to a DM> holding area, depending on the sysops wishes, and it can be done DM> automatically. The software doing the move can handle any renaming, DM> there's no need to change the ftp software at all. Denis, methinks you missed my point. We're talking about mailers that make OUTBOUND calls. Okay? :) We're not talking about whether ftp is being used successfully. I -KNOW- it's being used successfully, I move the entire filebone between four nodes via FTP, the only thing I move via VModem is echomail. However ,unless my FIDONET MAILER can make a decision about where or how to send mail based on information in the nodelist, that information is worthless and shouldn't be in the nodelist. The fact that somebody only accepts echomail via SMTP-Attach is totally USELESS information to my mailer -- it does not have the capability to create an email message, address it based upon information contained in the nodelist entry, and file attach the contents of a Binkley FLO file to that email. It also doesn't have the ability to initiate an ftp client session and force the contents of that FLO file to be sent via FTP. LG> My FIFTP sessions run totally independent of the existence of any LG> nodelist, as does the inbound and outbound processing of echomail LG> to and from those ftp sites. Therefore, it serves no purpose at all LG> (at least for me) for SMTP or FTP protocol information to be in the LG> -nodelist-. DM> So because it's of no benefit *TO YOU* *AT THE MOMENT* it's not DM> needed eh? Uh.. Denis... this isn't about my -personal- nonbenefit.. it's a basic point of reality that NO FIDONET MAILER has that capability -- and I seriously doubt that anybody currently working on Fidonet Mailer Software is going to write in a whole bunch of interfaces to read modem flags from the nodelist and pipe the FLO file out to SMTP or FTP. DM> It's of no benefit whatsoever to me at the moment either, Thankyou for your candor. I suggest it's of no benefit to any FIDONET SYSOP at this moment, or any moment in the future, and for that reason, there serves no purpose for listing such information in the nodelist. DM> but at least the fact that IP connected nodes, whatever their DM> transport method, are in the nodelist means that I can send them DM> netmail without it being bounced by message trackers, Denis.. I have nothing against the listing of IP-connected nodes.. for crying out loud, why do you think I'm in this echo! However, I see NO PURPOSE in listing FTP or SMTP flags in the nodelist entry for those IP-connected nodes. The FIDONET MAILER cannot use that information for anything worthwhile -- and anybody that -is- going to send Fidonet via SMTP or FTP needs a heck of a lot more information than can be squeezed inside a nodelist entry. DM> and if we can develop a standard format for the presentation of IP DM> connection info in the nodelist then maybe some of the software DM> authors will start using the info. Agreed. But that 'standard format' needs to be confined to what is NECESSARY for FIDONET MAILER functionality -- it should not try to become the be-all end-all to everything-you-ever-wanted-to-know-about-my-IP-configuration, but were afraid to ask. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1165 [1995] Scn From : Lawrence Garvin 1:106/6018 30 Oct 97 21:00:54 To : Denis McMahon 01 Nov 97 09:22:18 Subj : IP-access ------------------------------------------------------------------------------- Denis McMahon said in a message to Lawrence Garvin: DM> It should not be a requirement that a net maintain a nameserver DM> before that net is allowed to contain IP nodes! LG> No... but SOMEWHERE, that node is going to have to be listed in LG> somebody's nameserver in order to get IP service. It matters not LG> who runs the server, the fact remains, it must exist. DM> Agreed, however I was disputing the suggestion that nameserver DM> entries should be handled by the NCs, how many NCs run nameservers? Who said anything about the -NC- running the nameserver? ? ? ???? However, SOMEBODY in the -NET- or -REGION- had better be capable and willing to run a nameserver if they want IP-connectivity in Fidonet. Relying on one hostmaster to provide DNS services for the whole Fidonet Zone is, not only foolish, but totally anathema to the whole concept of the distributed database system that makes DNS what it is. It takes about fifteen minutes to setup a functional DNS server on a permanently connected IP node. I have one running on my OS/2 machine right now -- actually providing DNS services for -two- different domains, and about to add secondary services for a third. I'll tell you this, also -- setting up the DNS server was a cakewalk compared to the nightmare I went through to get GIGO set up and running. So for anybody already running a Fido<>Internet gateway, and relying upon somebody else's DNS server to hold the MX record -- I suggest it's a painless addition to have your net/region delegated to you where you can run your own server. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1166 [1995] Scn From : Lawrence Garvin 1:106/6018 30 Oct 97 20:45:36 To : Denis McMahon 01 Nov 97 09:22:18 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Denis McMahon said in a message to Lawrence Garvin: DM> OK, suppose a node that doesn't have a session password wants to DM> send you a crash netmail? How does he do it? Answer, he dials your DM> telno and sends it. He presents *ANY* valid nodenumber in the DM> nodelist, and as long as you don't have a session password set with DM> the node address presented your system accepts his mail. End of DM> session. Not quite. If a mailer identifying itself here with a node number that I don't have a session password set up for drops off mail, it gets put into an INSECURE directory, and NOTHING touches that mail until I personally (manually) inspect it to make sure it's not 'dangerous'. DM> This is *NO DIFFERENT* to accepting anonymous upload! It sure as heck is! When uploads occur via a REAL account/password, like they do at PAOnline or Southern Star -- there is at least somebody directly accountable for what comes in via that account. Granted, I'm not so naiv‚ as to think that there isn't some sharing of accounts and passwords going on -- but there's a heck of a lot more accountability than just accepting mail bundles via anonymous logons. DM> Of course, what you do with mail from an anonymous source (hold for DM> inspection, process immediately etc) is up to you, but it doesn't DM> form part of the session protocol either! True. DM> Personally I only accept echomail from agreed systems over password DM> protected links, but I accept pkt files from any node in the DM> nodelist, and process them if they fit certain size and number of DM> message criteria. Same here. It is the -compressed- mail that gets held back for my personal perusal. DM> I even process arcmail from unprotected sources providing the DM> compression factor is above a certain level, and the enclosed DM> packet meets the above criteria and only contains netmail. Not I. :) LG> I am strictly opposed to the use of anonymous ftp for the transport LG> of Fidonet mail. All ftp should be done on a closed-account basis, LG> password protected, and even then, although not normally done, LG> should probably include packet level passwords. DM> Yeah? So what do you do with incoming pkt and arcmail files in your DM> fidonet inbound from nodes that don't have a session password? I manually inspect them, and if they look like they belong in my inbound, I put them there. But you forget one very important point -- I still have a way to trace back where that packet originated from -- mailer logs, filenames, and if it's ugly enough, telephone records. Anonymous FTP gives the FTP Server Operator none of the above. No logs that identify who dropped off the packet and no way to trace the source of the session if it comes to pass that the mail dropped off is really really ugly. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1167 [1995] Scn From : Lawrence Garvin 1:106/6018 30 Oct 97 23:11:16 To : Pablo Saratxaga 01 Nov 97 09:23:00 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Pablo Saratxaga said in a message to Lawrence Garvin: LG> It most certainly -is- necessary, Yuri. It's -mandated- by Fidonet LG> Policy 4, and until you can get enough RC's to agree to drop that LG> FTS-0001 requirement from Fidonet Policy 4, -WE- have no choice in LG> the matter. PS> No, as long as a given node has a POTS line whith a fts-0001 mailer PS> on it that's OK. PROVIDED that the POTS line and the IP-line are able to share the SAME node number. Otherwise, if they have different node numbers, or in the case of an IP-only node -- they will be unable to honor that basic requirement. PS> There is no need to force a common protocol on other transport PS> layers. There is as long as Policy 4 rules Fidonet. And please note, I'm not disagreeing with your valid perception that doing so is stupid. I agree as well. it's not going to be used in real practice. HOWEVER, the requirement exists. And lest we forget that -WE- are trying to 'sell' this concept as a minority of nodes. The majority of Fidonet nodes do NOT have IP-connectivity, and they could care less. The ONLY way we'll ever get Fidonet as a whole to buy into permitting the listing of IP capable nodes in the Fidonet Nodelist is if we can show that every node is 100% Policy 4 and FTS-0001 compliant. Anything less than that, and the answer is a simple "No!". And we lose. PS> I can even say it will be stupid to do so at this stage as the PS> effect of that will be to put a break on any developpement for PS> better suited protocols for new transport layers. Well.... all I can say is that for those wanting to use BinkD/BinkP in their PRIVATE networks -- more power to 'em. But for those wantingto use BinkD/BinkP in -FIDONET- -- they need to do a reality check and real quick, because their mailer is not Fidonet compliant. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1168 [1995] Scn From : Lawrence Garvin 1:106/6018 30 Oct 97 22:57:02 To : Yuri Teterin 01 Nov 97 09:23:00 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Yuri Teterin said in a message to Lawrence Garvin: LG> I suspect that if you took a look at the file-transfer protocols LG> used in association with those FTS-0001 sessions, you'll find that LG> their nature is such that they -need- to have a TCP connection, LG> and will not be able to function adequately across a UDP LG> connection. YT> Why not? FTS-0001 does not suppose that the connection is YT> error-free. And any non-errorfree connection can be implemented YT> very well with help of UDP. Ahh... if that is your impression of the differences between TCP and UDP, then you've misunderstood much, Yuri. The difference is not about "error-free". Regardless of whether TCP or UDP is used, it is still the responsibility of the upper layer protocols to insure that what was received was what was intended to be sent. The fundamental difference between TCP and UDP is whether or not each end is continuously aware of a "connection" to the other end. TCP is a connection-oriented protocol, in that each end 'negotiates' certain parameters of communications, and continually acknowledge receipt of each other's transmissions so that the sending end knows immediately whether the packet was received or not -- or at least, if the packet was received in a damaged state. Also, TCP is implemented with a sliding window protocol, which allows for dynamic optimization of the transmit/acknowledge timeouts, so that, optimally, the sender is sending at the maximum possible speed that the receiver can receive at, under the current conditions of communication. UDP, on the other hand, is a connectionless protocol. The sender has no knowledge of whether the receiver exists at that moment or not. The packet is simply sent out to the ether with the hopes that it will be received and acted upon. It is the responsibility of the -sending- side of the UDP connection to provide for a timeout, a point at which it gives up, and reports back to the user that all is lost, and the communication cannot be completed. Even then, the packet may well have been received -and- acted upon, but the -acknowledgement- is lost on the return trip. The result of this is that the whole process is repeated. As a minimum, it is virtually impossible to implement any sort of efficient streaming file transfer over UDP - And isn't that pretty much what Fidonet is?: The transfer of file via expedient streaming technologies? --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1169 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 01 Nov 97 11:28:34 To : Rune Johansen Subj : Proposals, policies, FTS's and that stuff ------------------------------------------------------------------------------- Hello Rune! On 30 Oct 97 wrote Rune Johansen to Jesper Tragardh: RJ> For this echo's topic, we want to find a way to integrate IP RJ> connectivity into the nodelist, not reform the whole nodelist :-)) A new nodelist format will last some time, until it is supported by every system. Some nodes may have to change their complete system setup to support another nodelist format or they have to run an additional conversion program. On the other hand, an extended format will solve many of todays problems. On short term we should concentrate on the implementation of ip-nodes in the existing nodelist format, without disturbing the operation of conventional nodes to much. There are several possibilities to reach this aim with only one program to fix: the nodelist compiler at the location, where ip-access is needed. Any other node does not get involved in the additional access technology and the required work may be minimized. Perhaps some people should try to interprete FTS-1 and the policy with a certain focus on the aim, as some of these documents are to old to support the available technologies characterwise, but the sense of these documents (_organization_ of a special communication technology called ftn) may be kept. Then we can focuse on the extended nodelist format and define a complete solution for the next decades. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1170 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:24:54 To : Slava Filimonov 01 Nov 97 18:30:06 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Slave, > WD> The core of Fidonet is the nodelist, think twice about that. > The _real_ core of Fidonet still public phone line. Nodelist is just > phone directory like yellow pages in each phonebox. Guess what is the > core of internet , and then think twice about that. 1) The core of Fidonet is the nodelist. 2) We are discussing the use of IP as a carrier for Fido-sessions. 3) We are not discussing what the core of the internet is. So any sollution that will be adopted will have to be a nodelist-sollution. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1171 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:49:50 To : All 01 Nov 97 18:30:06 Subj : Yoohoo ------------------------------------------------------------------------------- Due to job-related time-constraints I have been a bit absent here. This will now be a bit better. >I've gone through all the mail which was addressed to me and to "All". If >someone thinks I missed something essential then please netmail me. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1172 [1995] Scn From : Lech Szychowski 2:480/33.7 31 Oct 97 03:58:00 To : Rune Johansen 01 Nov 97 18:30:06 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- >> If this is a pkt file, then it is to be unpacked and processed by the >> system, right? Then it makes no difference what name it's given for >> the (short) rest of its lifetime. > Yes, and that means that if a FTP server renames the file on it's side, > it does not matter to the transfer protocol (FTP in this case). As long as one can be sure it _is_ the pkt file. Mailer can be almost sure, because there are some standars for filenames which can be expected to be adhered to by all other mailers. Which IMHO is not the case with FTP server and its clients. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1173 [1995] Scn From : Lawrence Garvin 1:106/6018 31 Oct 97 08:27:44 To : Marco d'Itri 01 Nov 97 18:30:06 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Marco d'Itri said in a message to Lawrence Garvin: Md> Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >sites. Therefore, it serves no purpose at all (at least for me) for SMTP or >FTP protocol information to be in the -nodelist-. Md> I need to know which nodes supports email tunneling, e.g. to send Md> them crash mail. Can you program your FIDONET MAILER to make a decision on whether to tunnel the stuff via email or dial 'em up on the PSTN? Can it make that decision -dynamically-, as the stuff is dropped in the mailer outbound directory? Or do you have to 'preconfigure' your system to send ALL MAIL for a specific node via email tunneling? If you have to 'preconfigure' your system, then any arrangements for email tunneling had to have been negotiated on an individual basis, therefore you received your knowledge about that capability from some means other than your -MAILER- making the decision. So.... Marco.... which is it? :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1174 [1995] Scn From : Lech Szychowski 2:480/33.7 31 Oct 97 03:55:00 To : Rune Johansen 01 Nov 97 18:30:06 Subj : Flags in nodelist ------------------------------------------------------------------------------- > I think "claims to be" is the correct one here. If it should be "is > listed as" you'd have to go to the level above to check if it is listed > as an authorative server for that zone. Having spent a bit more time thinking about it I am willing to agree :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1175 [1995] Scn From : Lech Szychowski 2:480/33.7 31 Oct 97 03:48:00 To : Dima Maloff 01 Nov 97 18:30:06 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > If having binkp support is enough a) to be compatible; b) to be fast; > c) to be effective, why not allow binkp only nodes? If all these conditions are met, there is no reason not to allow them - "compatible" being the main keyword here. > No, thanks. Let FTS-1 be "the must" for your network, not ours :) There is no "his" network. There is Fido. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1176 [1995] Scn From : Lech Szychowski 2:480/33.7 31 Oct 97 03:49:00 To : Dima Maloff 01 Nov 97 18:30:06 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>> If they locked themselves with non open software is their own problem, >>> not mine. > LS> They didn't. We will if we change standards inconsideratly. > Wrong. They will have to change something in their systems either way. Why? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1177 [1995] Scn From : Lech Szychowski 2:480/33.7 31 Oct 97 03:51:00 To : Dima Maloff 01 Nov 97 18:30:06 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > AFAIK, the common idea in SU.IP.SYSOP (an echo for ex-USSR IP-sysops, > the echo is 2 yrs old, BTW) is that we don't need a standard protocol. > At least right now. Therefore there is no total connectivity... Or is there? If so, why not adopt something literarily everyone supports as a standard? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1178 [1995] Scn From : Lech Szychowski 2:480/33.7 31 Oct 97 04:03:00 To : Rune Johansen 01 Nov 97 18:30:06 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > The question that arises then is: How should the fallback port be > denoted in the nodelist? To comly with this, the listing of available > session protocols on each port must be done. To avoid this, a simple > fallback routine in the listening daemon could be implemented. If I get you right, what you're saying is equivalent to "any mailer should itself support fallback to standard protocol". And that's precisly something I'd say about it. > problem I would see with it, is if I get a non-error-correcting connect > with the other side. That way I could be in serious trouble. But, BinkP > assumes error-free connection, so I'll have to see what I can do on the > modem side. IHMO if BinkP can't handle "no-error-correction-by-modem" situation, it should let the other side know about it and disconnect ASAP, to save money. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1179 [1995] Scn From : Lech Szychowski 2:480/33.7 31 Oct 97 03:39:00 To : Lawrence Garvin 01 Nov 97 18:30:06 Subj : IP-access ------------------------------------------------------------------------------- > LS> For just itself? Not being a hub, host or any non-leaf in routing > LS> topology? > Nope. Just because my system can send/receive SMTP, does not imply that > it has the necessary software gateways installed to make that > information available to Fidonet. Not to Fidonet, but just to _you_, the sysop of the node. > I see no reason not to support it in fidonet.org; but that will require > the complete cooperation of the Hostmaster@fidonet.org, as well as > designated hostmasters for delegated regions/nets. Ain't that a quite natural? > A lot depends on how cooperative hostmaster@fidonet.org is with this > whole situation. Certainly; and/or hostmasters of subdomains. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1180 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:12:26 To : Lech Szychowski 01 Nov 97 18:30:06 Subj : Re: IP-access ------------------------------------------------------------------------------- > Why are you so afraid that someone will abuse DNS? What's so different > about nodelist that you are not afraid of letting regions manage their > segments/parts while you are afraid of letting them manage their > subdomains? Quite easy ... managing nodelist-segments has been regulated inside fido. That's the difference. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1181 [1995] Scn From : Lech Szychowski 2:480/33.7 31 Oct 97 03:44:00 To : Marco d'Itri 01 Nov 97 18:30:06 Subj : IP-connectivity ------------------------------------------------------------------------------- >>If above stands for "SMTP support is not to be considered enough for >>the system to be granted a Fidonet node status" you have my full >>support here. > I agree with that, but there is no reason the system supporting those > *OPTIONAL* protocols shouldn't announce them in the nodelist. Again, I agree. But please, no overinventive plans to include things like FSP, ICQ or NFS there :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1182 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:18:08 To : Pedro Lima 01 Nov 97 18:30:06 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Pedro, >> Is the reference 'FTS-0001' copyrighted? > WD> Yes. > Ok, then we'll have to interpret what's said in P4 in a different way > (as I believe it was intended in the first place anyway), or replace P4 > altogether, if we want to do it 'by the book'. So far, concerning trying to get IP in, I think nothing is (nor can be) according to the book. BTW, some guys are threatening me with formal complaints if I continue this effort. I think they picked the wrong target to waste ammunition. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1183 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:16:06 To : David Moufarrege 01 Nov 97 18:30:06 Subj : Re: IP-nodes ... ------------------------------------------------------------------------------- David, > I'd be interested to see this. Anyway I can get you to e-mail attach me > that segment for review here? You can freq "IP" here. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1184 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:27:46 To : Chris Maddock 01 Nov 97 18:30:06 Subj : Re: IP-nodes ... ------------------------------------------------------------------------------- Chris, > Alwyn (Z3C) may be interested in your "local" segment. > You might want to check with him. I'll get in touch with him. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1185 [1995] Rcv Scn From : Ward Dossche 2:292/854 31 Oct 97 20:19:26 To : Lothar Behet 01 Nov 97 18:30:06 Subj : Re: IP-Test 2:2/3000 ------------------------------------------------------------------------------- Lothar, > WD> ... I got worried at some point when at a Fridaymorning the > WD> modem was so silent.. > The silence did disturb your rest? :) Indeed ... \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1186 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:34:30 To : Lawrence Garvin 01 Nov 97 18:30:06 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lawrence, > Forgive me, Ward, I didn't realize this was a Zone 2 only project, > although I have noticed a critical dearth of otherzone sysops in this > echo. :( If the other ZC's want to join the exercise I have no problem to make this a worldwide thing, you know. I just didn't want to bother anyone outside my realm of dictatorship. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1187 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:42:08 To : Lawrence Garvin 01 Nov 97 18:30:06 Subj : Re: Controversy Regarding Node Number ------------------------------------------------------------------------------- Lawrence, > Hey Ward! Can I get a Zone 2 node number? > But seriously... In the test-environment this should be possible ... you'd have to run the zone-2 version of the nodelist as well though. If you want to give it a try a raise hell I'm your man ... ;-) \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1188 [1995] Scn From : Ask Bjoern Hansen 2:235/10 31 Oct 97 13:29:34 To : Rune Johansen 01 Nov 97 18:30:52 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hello Rune! Wednesday October 29 1997 01:24, Rune Johansen wrote to Marco d'Itri: >> This is not true, I can install any daemon I want on unprivileged >> ports. I just need a shell account. And I don't have to bother the >> sysadmin to change the configuration and so on. > _you_ can, yes. I can too, until the SysAdmin at the ISP login server > figures out what I am doing. Then I'll get kicked out. But the sysadmin would also get a good laugh if you asked him to replace his telnetd with fidosoftware or some 'fidoenabled telnetdaemon'. *If* it's possible to get fidosoftware installed, it's a lot more possible to get it done on some unprivileged port (or at least a nonstandard one). kind regards, ask --- GoldED/2 3.00.Alpha4+ * Origin: http://www.netcetera.dk/ - ask@netcetera.dk (2:235/10) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1189 [1995] Scn From : Ask Bjoern Hansen 2:235/10 31 Oct 97 17:41:06 To : Lawrence Garvin 01 Nov 97 18:30:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Lawrence! Thursday October 30 1997 23:11, Lawrence Garvin wrote to Pablo Saratxaga: PS>> There is no need to force a common protocol on other transport PS>> layers. LG> There is as long as Policy 4 rules Fidonet. I think that we should use what P4 says about 'common sense' when it's hopeless outdated and stopping us from getting any further elsewhere. ... LG> But for those wantingto use BinkD/BinkP in -FIDONET- -- they need to LG> do a reality check and real quick, because their mailer is not LG> Fidonet compliant. If it works for us, why shouldn't we use it? Because of P4? Like we're not having 4D points because P4 states that we don't do it that way. No? kind regards, ask --- GoldED/2 3.00.Alpha4+ * Origin: PC=Programmable Chaos! Call the Source! <+45-36305533> (2:235/10) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1190 [1995] Scn From : Lawrence Garvin 1:106/6018 31 Oct 97 20:22:50 To : Ask Bjoern Hansen 02 Nov 97 05:39:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Ask Bjoern Hansen said in a message to Lawrence Garvin: PS>> There is no need to force a common protocol on other transport PS>> layers. LG> There is as long as Policy 4 rules Fidonet. ABH> I think that we should use what P4 says about 'common sense' when ABH> it's hopeless outdated and stopping us from getting any further ABH> elsewhere. Uh... unless you've got a different Policy 4 than I have, there's only one reference to "common sense" in that entire document, and it's a specific reference in paragraph 2.1.6.2, with consideration to "private mail". Now, I will concede that there is also an unwritten presumption that any consideration of any "policy" incorporates a certain amount of common sense when implementing the intent of the policy. However, Policy is quite clear on certain things, and gives no leeway at all for 'interpretation' or 'common sense' modifications. One of those unequivocable requirements is that EVERY NODE listed in the nodelist (except those flagged as PVT), must be capable of negotiating an FTS-0001 session during Zone Mail Hour. LG> But for those wantingto use BinkD/BinkP in -FIDONET- -- they need to LG> do a reality check and real quick, because their mailer is not LG> Fidonet compliant. ABH> If it works for us, why shouldn't we use it? Hey.. I -NEVER- said don't use it. I'm just pointing out that those who wrote the software were a bit deficient in their design specifications. They specifically wrote a piece of software for use in a Fidonet network, and flat out failed to make the software compliant with the Policy document or the minimum Technical Standards document. Use the software all you want -- heck, I'm about to install one myself on this node here -- but make no mistake -- the software, by itself, does not qualify the operator as a compliant-node for inclusion in the Fidonet nodelist. ABH> Because of P4? Like we're not having 4D points because P4 states ABH> that we don't do it that way. No? P4 doesn't say anything at all about points, except that they're not recognized members of Fidonet. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1191 [1995] Scn From : Lawrence Garvin 1:106/6018 31 Oct 97 20:28:08 To : Rune Johansen 02 Nov 97 05:39:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: >Any chance I could persuade you to invert your usage of the terms >protocol and > session? RJ> Yes, that can be done. :-) But, I think it would be more correct to RJ> use the terms transport and session. They are both protocols. A RJ> protocol is a defined set of terms that both parties agree to. RJ> Transport protocol and session protocol. Okay.. I'll buy into that. > The SESSION runs on top of the PROTOCOL. No? :) RJ> No. Session runs on top of transport. Gotcha! Ain't compromise wonderful! --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1192 [1995] Scn From : Sean Rima 2:252/356 31 Oct 97 08:12:14 To : Slava Filimonov 02 Nov 97 05:39:46 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Slava Filimonov wrote in a message to Sean Rima: SR> True, so if your used BND = BinkD, IFC = IFcico, VM = VModem etc as SF> Little remark - BND means program, BNP means protocol, which binkd SF> uses. So we should use BNP flag instead. I stand corrected. I knew something was wrong when I typed it. SF> -- - ---< binkd : fido.mrp.cz <> mobile: +420 603 228496 Must link to you sometime this week :-) BTW, there is now an echo for IPmailers to chat in, IPMAILER Later, Sean --- timEd/386 1.10 * Origin: DSP BBS Reading Berks {0118 961 4636} (2:252/356) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1193 [1995] Scn From : Dima Maloff 2:5047/13 01 Nov 97 12:07:00 To : Pablo Saratxaga 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wednesday October 29 1997 02:22, Pablo Saratxaga wrote to Sean Rima: SR>> Strange, I connect to an IFCICO mailer evey day with no problems. SR>> There is an addon for Ifcico to allow it to use BinkP which is use by SR>> BinkD PS> Where can it be found ? I'm very interested on that. I know one sysop who wanted to make such a patch, but he dropped the idea -- installation of binkd under major UNIXes is as simple as sh configure; make; vi binkd.cfg; binkd binkd.cfg. Binkd works together with ifcico perfectly on the same outbound directory. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1194 [1995] Scn From : Amir Shabashvili 2:5049/12 31 Oct 97 12:37:44 To : Pablo Saratxaga 02 Nov 97 05:39:48 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Pablo! Replying to a message from Pablo Saratxaga to Amir Shabashvili: AS>> The better way, IMHO, is got all info about protocol,... from DNS AS>> requests, PS> No, because there aren't standard libraries to request any DNS funny PS> field, also it is much more interesting to know the supported PS> protocols before doing the call, when the downlink is not yet even PS> online he looks at the nodelist for a node whith same capabilities as PS> him then connects to the internet and poll. Your method implies that PS> the downlink does all the research while online. Yes. I told about scheme we discuss in r50 for one protocol - binkp. Now we manage to realize it under fidonet.net domain. If we'll have any results, I'll describe it there. Cheers, Amir. PS It's like the early time aviation born: there was a lot of constructions - but only Wright Brother's airplane got a success:) --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1195 [1995] Scn From : Dima Maloff 2:5047/13 01 Nov 97 12:04:00 To : Rune Johansen 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thursday October 30 1997 19:22, Rune Johansen wrote to Lech Szychowski: RJ> The question that arises then is: How should the fallback port be denoted RJ> in the nodelist? On the standard one for a standard protocol, if it happens. RJ> I have not run a full poll with BinkP with lots of files to transfer both RJ> ways yet over PSTN, but I will test it someday now. :-) The only problem I RJ> would see with it, is if I get a non-error-correcting connect with the RJ> other side. That way I could be in serious trouble. But, BinkP assumes RJ> error-free connection, so I'll have to see what I can do on the modem RJ> side. Yes. It's very easy to loss data with binkp over "raw" modem connection (even with MNP5/LAPM/V42B). This will not work in the real life by design. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1196 [1995] Scn From : Dima Maloff 2:5047/13 01 Nov 97 12:07:00 To : Dieter Ringhofer 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thursday October 30 1997 19:13, Dieter Ringhofer wrote to Dima Maloff: DM>> We are not talking about you. We want to connect as many nodes as DM>> possible, aren't we? DR> yes, we are. but think about meaning of 'node' first before trying to beat DR> that horse with arguments like you've used last time. YOU want to have DR> something, other people already have it. to participate at fido does DR> not mean to be a member of it! We (or I) do not WANT, we've DONE already. And now we don't want more problems for the largest fido-over-IP community. DR> That's not point of discussion. Subtopic is to get a common protocol for DR> all media in use to (topic) have a chance to list systems using another DR> medium. You (or '200+ persons') can't expect that 30.000+ people change DR> their programs to do you a favour. We have to use a compliant program if DR> we want to be a member of the club. Additional protocols fitting the needs DR> of a specific medium are another issue. It's similar like using Hydra DR> instead of ZedZap, both implementations offer the chance to use FTS-0001 DR> as fallback commonly triggered by a failing EMSI handshake. 30.000+ will have to change something to use IP anyway. And listen, after all, we do not want for BINKP to be a mandatory standard. We just hate to be forced to add vmodem. DR> Maybe this leads to an understandable example for you: DR> How does Binkd react when a password error occures (caused by a typo)? Reports a error. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1197 [1995] Scn From : Dima Maloff 2:5047/13 31 Oct 97 14:08:00 To : Lawrence Garvin 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Tuesday October 28 1997 21:17, Lawrence Garvin wrote to Rune Johansen: LG> I'd prefer to see BinkP, EMSI, FTS-6, and FTS-1 referred to as -SESSION-, LG> and TCP (telnet/ftp/smtp), UDP (http), X.75, V.34, and others of that ilk LG> refered to as -PROTOCOLS-. No. It's terminologically incorrect. RJ>> As long as BinkD cannot do FTS-1 fallback, it will not meet the RJ>> requirements of a Fidonet Nodestatus. If you have a mailer that has RJ>> got the fallback, you can use it. LG> Notwithstanding the terminology gap, I agree with this basic principle. ANY IP-only node, per Policy, cannot be listed in the nodelist. So do not mention Policy in IP_CONNECT. :) --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1198 [1995] Scn From : Vilo Mlich 2:421/50 31 Oct 97 09:41:00 To : Pablo Saratxaga 02 Nov 97 05:39:48 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hello Pablo! Streda Rijen 29 1997 02:09, Pablo Saratxaga wrote to maciej grzeszczuk: PS> IPTEL : telnet-vmodem, port 23 PS> IPTxy : Same as the actual Txy flag, but denoting internet online time. PS> while the abscence of Txy flags imply ZMH only, the abscence of PS> IPTxy should imply it is 24h/24 on the internet (so no need for a PS> IPCM ;-) ) Flag IPTEL is for node, which is on internet 4:00-1:00 UTC ? regards Vilo vmlich@mbox.vol.cz --- GoldED 2.50.Beta5+ * Origin: T-Mail support node (2:421/50) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1199 [1995] Scn From : Nick Soveiko 2:5030/23.101 30 Oct 97 17:26:10 To : Lawrence Garvin 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Tue, 28 Oct 1997, 21:17, Lawrence Garvin (1:106/6018) ==> Rune Johansen: LG> Any chance I could persuade you to invert your usage of the terms LG> protocol and session? LG> I'd prefer to see BinkP, EMSI, FTS-6, and FTS-1 referred to as LG> -SESSION-, and TCP (telnet/ftp/smtp), UDP (http), X.75, V.34, and LG> others of that ilk refered to as -PROTOCOLS-. LG> The SESSION runs on top of the PROTOCOL. No? :) nope, *session* runs on top of *transport*. but there are protocols for both. osi/iso layers are: presentation too vague to give examples application e.g. mime, *.pkt, html, bink-style outbound session e.g. ftp, http, smtp, pop3, binkp, emsi transport e.g. tcp, udp network e.g. ip, ipx/spx, ftn nodelist datalink e.g. hdlc, xmodem, zmodem physical e.g. v.34, g.703/g.704 fts-1 tries to cover everything and fails miserably in many aspects. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1200 [1995] Scn From : Dima Maloff 2:5047/13 31 Oct 97 14:19:00 To : Nick Soveiko 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wednesday October 29 1997 15:46, Nick Soveiko wrote to Lech Szychowski: NS> easier to incorporate protocol part of ifcico into binkd. but even NS> this would require some serious hacking. now this could make a truly NS> ip-capable mailer that no one would probably object. NS> any volunteers out here? Nick, I think, this should not be done. 1st -- if Fido will not get rid of FTS-1 in TCP/IP-world, it will never get rid of it. 2nd -- remember, thouse, who say "standard should be FTS-1 over TCP/IP" don't even try to think how should this "standard" work in the real life: 1) over "raw" TCP (as in ifcico) or over TELNET (as in vmodem) or over rlogin (as in rlfossil)? 2) if over TELNET -- which TELNET options should one negotiate before establishing FTS-1? 3) if over TELNET -- why, if TELNET is terrible for bulk data transfers? 4) if over "raw" TCP -- what about OS/2 users? Vmodem does not support "raw" TCP. 5) how to fight "ECHO" bug of vmodem drivers? 6) which TCP port to use? Why? 7) how one should multiplex protocols -- by TCP ports or inside of an established connection? Why? 8) if without using of TCP ports -- why, if it is against the nature of TCP? 9) what about timeouts? Can one use TCP timeouts and ignore xmodem and FTS-1 timeoluts or not? 10) how to process concurrent connections -- by forking or "one-by-one" or "process one and send some "BUSY" signal to the others"? 11) if send "BUSY" -- how? 12) are inbound only, recv only FTS-1 sessions enough to be "compatible"? --- GoldED/2 3.00.Alpha5 UNREG * Origin: getppid()? -- Yes, son? -- I want to kill() you! (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1201 [1995] Scn From : Nick Soveiko 2:5030/69.101 30 Oct 97 14:37:08 To : Frank Ellermann 02 Nov 97 05:39:48 Subj : was: A bit of steering ... ------------------------------------------------------------------------------- Tue, 28 Oct 1997, 22:50, Frank Ellermann (2:240/5815.1) ==> Nick Soveiko: FE> ... tnx for info about ISKRA. Are these special phone numbers, a FE> special area code maybe ? generally, these are special numbers not diallable from pstn. afaik, in moscow one can get a line that's accesible from both pstn and iskra, but not in the other cities. that's why they can't be listed in nodelist and iskra-capable sysops had to issue their own nodelist segment and compile it on top of z2-list. iskra was a major long haul transport in r50 some time ago. my understanding is that now binkp over tcp/ip mostly took over, except for the places that didn't get ip connectivity yet. cheers, nick --- Handwritten * Origin: <-<-<- Houses of the hairy (Overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1202 [1995] Scn From : Nick Soveiko 2:5030/69.101 30 Oct 97 17:12:34 To : Rune Johansen 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wed, 29 Oct 1997, 02:12, Rune Johansen (2:210/20) ==> Nick Soveiko: RJ> Using BinkP as a must-have common protocol is what you want. That RJ> is noted. This is a political question, tied together with FidoNet RJ> in particular (yes, we are discussing FidoNet here). thank you for admitting that it's a political question ;) RJ> Let's say my friend has got a IP-capable system, that does FTS-1, RJ> FTS-6 and EMSI, like any full-fledged current modem/ISDN based RJ> node of today uses. He has the possibility to use a virtual RJ> COM-port redirector, that enables him do "dial" a IP system, with RJ> telnet OR raw TCP (both are available). this 'possibility to use a virtual com-port redirector' does not arise from nowhere. there's either time or money,  ­¤ ãáã ««ë both associated with it. then why get free binkd instead of (possibly commercial) com port emulation? so far i can see only one case where this is impossible - that's macintosh (i don't seriously consider running an ip-node under dos these days. and yes, you can get binkd for amiga now). i am not aware of availability of com-port emulators for mac either. >> Many people said that the obvious protocol should be BinkP, since >> there already are hundreds of nodes in fidonet using it. I then >> argued with that if we are to follow policy, then this protocol >> should be capable of carrying FTS-0001 handshake. Then it has been >> argued that this is a ridicolous solution. > i second the ridiculousness. RJ> Just because BinkD in it's current implementation cannot do RJ> fallback to FTS-1 when it is a called party? What does it take to RJ> implement a simple FTS-1 fallback routine into BinkD, to make it RJ> able to receive all mailers that can do raw TCP? Compared to RJ> implementing BinkP protocol in all mailers that would be considered RJ> doing connections over a (possibly FOSSIL-compliant) raw TCP RJ> "dialer"? the ridiculousness follows immediately from absurdity of running over tcp an unsecure and non-robust protocol designed for 2400bps modems without error correction. >fts-0001 over telnet or over raw ip is just *a little bit* less >ridiculous tha fts-0001 over binkp. RJ> No, that's where we disagree. you mean it's as ridiculous as fts-1 over binkp? ok, you've convinced me! ;) >> For BinkP capable nodes this would not be any problem to implement, >> as they would use the listening port, autodetect BinkP vs. >> FTS-0001, and have a session accordingly. > sorry for repeating this, but it won't be a technical problem only. > for some nodes that's going to be a monetary/legal problem. RJ> In what ways will that be a legal problem? sorry, i misundersood your point for running a com-port emulator. as for introducing fts-1 autodetect into binkd, it's only the problem of who actually would bother to do this and introduce new bugs in this otherwise pretty good piece of software. RJ> On the monetary side, I would like to bet that someone (maybe RJ> myself) would implement such a "hook" in BinkD (which is the most RJ> broadly used implementation of a mailer that uses BinkP today), to RJ> allow it for autodetection of an incoming FTS-1 session on it's RJ> listening port. and firing up an external xmodem, probably via named pipe? that sounds to me like a viable compromise. RJ> Good. I really hope that the specifications of the BinkP protocol RJ> would allow for implementing fallback to other protocols, so it can RJ> be easily implemented by the implementors. :-)) no objection and it's in my todo list. RJ> Specs should also allow for "junk" before finding the BinkP RJ> protocol chars, to allow for autosensing when calling another RJ> system. Just a way of being leniant on what is on the other end. RJ> "Be leniant in what you accept, and strict in what you send" is a RJ> good, old jungleword used by successfull software developers all RJ> over the world. specs do allow junk. but for autodetect instead of just discard it, you analyze it. think about such analisys as a pipe to the trashcan ;). no contradiction. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1203 [1995] Scn From : Nick Soveiko 2:5030/69.101 30 Oct 97 17:24:54 To : Rune Johansen 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wed, 29 Oct 1997, 02:22, Rune Johansen (2:210/20) ==> Nick Soveiko: > i am still not sure if this should be a part of a formal *session* > layer protocol specs. RJ> I believe that such an important part should be specified in the RJ> BinkP specs itself, to avoid different interpretations in the RJ> future implementations of this protocol in other mailers. you mean we should actually say that in any binkp implementation passwords are case-sensitive? RJ> You should not be forced to read another _mailers_ documentation, RJ> to implement a specific protocol. agreed. lot's of misunderstanding arises here from the fact tha binkp was born at the same time as binkd, and for some time they were synonyms. the formal binkp specs that are underway now are based on description of it's binkd implementation. that's why references of 'binkd does this and binkd does that' pop up here and there. RJ> When that is said, I would suggest you take thing that applies RJ> directly to BinkD's implementation of BinkP out of the specs. sure. there will be a discussion of implementation over tcp connection and, probably reference do binkd sources as an example of such implementation. but that's it. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1204 [1995] Scn From : Nick Soveiko 2:5030/23.101 30 Oct 97 17:37:32 To : Rune Johansen 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wed, 29 Oct 1997, 01:22, Rune Johansen (2:210/20) ==> Yuri Teterin: RJ> Then we should list EMSI and FTS-6 and FTS-1 too. BinkP is a RJ> handshake alongside those mentioned. If it is to get a special flag RJ> in the nodelist, so should the others too. so? what's the problem? list session level protocols alongside with transport and port and make default the same as majority supports. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1205 [1995] Scn From : Nick Soveiko 2:5030/23.101 30 Oct 97 19:03:16 To : Rune Johansen 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wed, 29 Oct 1997, 02:15, Rune Johansen (2:210/20) ==> Nick Soveiko: >> Or, do considerer FTS-001 over raw socket as the minimal >> requirement? > afaik, only ifcico is capable of doing this. RJ> If, for example, Vmodem could create a raw socket, the problem is that it can't. as they say in russian: if a grandmother could have a dick, she would be a grandfather ;) cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1206 [1995] Scn From : Dima Maloff 2:5047/13 31 Oct 97 13:30:00 To : Dieter Ringhofer 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wednesday October 29 1997 05:45, Dieter Ringhofer wrote to Nick Soveiko: DR> but it skips the smallest common dominator. if there's an DR> implementation of fts-0001 it doesn't mean that one has to use it DR> instead a more efficient solution. it offers the chance for systems DR> to use it in case of having nothing else available but real DR> ftn-software. Wrong. One will need a Vmodem-like driver. Moreover, even if you'll use a Vmodem-like to run your old Fido-software, you'll have to run, say, 3 mailers to accept 3 concurrent inbound connections. Unlike Binkd or Argus (they start new line only on incoming calls). DR> don't forget what we're talking about (hint: listing of ip-systems in DR> a ftn-nodelist). check bbbs and you will see: it's possible. Sure. But why support something that will never be used? NS>> the whole fidonet has a choice now. DR> to skip it's own rules. No. To make life easier by letting us not to support obsolete standards in the new environment. NS>> you're not going to install binkd every day. believe me, it's a NS>> pretty robust daemon and not windows/95 ;) DR> but unreliable (not autoresume etc). Wrong. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1207 [1995] Scn From : Pedro Lima 2:362/21 31 Oct 97 04:33:16 To : Marco d'Itri 02 Nov 97 05:39:48 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hi, Md> I agree. Denis, are you reading this? Md> I hope there are not. Those compilers should just ignore the field or Md> at least the node. Unfortunately, hoping is not enough in this case. We have to be pretty sure about it. Md> We would need to modify much things in our software. Correct, but the IP situation is yet fairly new, and modifications to IP mailers are simpler to accomplish than with PSTN mailers. Md> I did not, maybe this will be a chance to dump some of the old Md> programs that are used in fidonet. :-) Together with the people using it? I'd rather not. Come on, it's perfectly possible to have both the old programs and IP connectivity in FidoNet. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1208 [1995] Scn From : Nick Soveiko 2:5030/69.101 30 Oct 97 17:04:40 To : Dieter Ringhofer 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wed, 29 Oct 1997, 05:45, Dieter Ringhofer (2:2476/14) ==> Nick Soveiko: NS> 1) systems having only pstn connectivity (i mean analogue plain old NS> telephone service, not isdn) NS> 2) systems having both pstn and some kind of ip connectivity (not NS> necessarily 24/365) NS> 3) systems having only ip connectivity (24/365) DR> i agree so far but, i would take a fourth one into consideration: DR> isdn-only nodes. they're similar to type 3. yep, they are very similar to (3), and i gave reference to this similarity below. NS> for systems (2) i don't really see any problem at all. on the pstn side NS> they support the protocol chosen by nodes (1). on the ip side they are NS> free to support whatever they want, as this is an *additional* NS> capability for them. NS> it's obvious that for system (1) there's *no way* to directly connect to NS> system (3) in absolutely the same way as now there's no way for a NS> pots-only node to connect to an isdn-only node. therefore, it makes no NS> sense to force systems (3) to support the same protocol systems (1) NS> communicate to each other. [] NS> that's the situation we have today. DR> but it skips the smallest common dominator. the common denominator issue was covered quite elaborately in my message, i think. refer back on the reply chain, as i'd better avoid overquoting. DR> if there's an implementation of fts-0001 it doesn't mean that one DR> has to use it instead a more efficient solution. it offers the DR> chance for systems to use it in case of having nothing else DR> available but real ftn-software. it still does not. you have to have (1) 'real' ftn-software, (2) ip-fossil emulation and (3) ip connection. DR> don't forget what we're talking about (hint: listing of ip-systems DR> in a ftn-nodelist). check bbbs and you will see: it's possible. i am not saying that it's technically impossible to do. as soon as a free portable solution for fts-1 over ip is available, i immediately withdraw my objections for it to be the least common denominator. let this daemon hang in the background as long as it doesn't create problems. i'll still reserve myself a right to think of this daemon as a rudimentary and silly thing. btw, where can i check out this bbbs thing? NS> now, if fidonet coordinators keep ruling systems (3) out of the NS> nodelist, than the issue is closed right away. there is nothing to NS> argue besides specific techniques to get some new flags into the NS> nodelist. *imho*, *that* fidonet is doomed. in 2 years zone 1 will NS> be gone for good and in 5 years 90% of zone 2 nodes will be from NS> regions 44-51, with their sysop population start declining as NS> well. have a look at the nodelist statistics if you don't agree. DR> this rapid shrinking in z1 is mostly a result of their calling cost DR> scheme: free local calls. that's a poor explanation. z1 is big. there are different telcos there having different pricing approaches and different calling plans. there is flat rate local calling, there are per-call charges, there are per-minute charges, and there are all possible combinations of the above. my explanation is that shrinking of z1 is facilitated by (a) really cheap internet access and (b) unflexibility of fidonet political and technical documents. there might be a gazillion of other personal reasons for every particular sysop, but this is the trend. and with the ongoing telco demonopolisation in europe, you'll get the same thing in a few years: cheap internet available over many physical media - pstn, cable, wireless, power utility lines. add here the same frozen in late 80s fido, and here you go! NS> to get this connectivity. again, even now nothing but their own NS> goodwill can force people to spend their own time and money to NS> participate in fidonet. DR> so far, so good but: don't mix participation with being a member. DR> ;) i am not mixing it. i've used this word here on purpose, as myself i am not a member of fidonet, but i am spending my time and money to be here. DR>> what you propose is the death of fidonet. NS> arguable. DR> not that much: any ftn is basing on chance of DIRECT connects. DR> that's impossible for ip. i could argue that direct connect between any given pair of fidonet nodes is not always possible over pstn too. so? is fidonet *already* dead? DR>> internet access is still expensive over here, a modem is normally DR>> needed for it. NS> (assuming modem is needed in any case) what is cheaper for cm in germany NS> now: to get a second phone line or a unix shell account? DR> in my area: a second (third, ...) line. what??? you mean installation of a second phone line plus a *second modem* is cheaper than setting up a unix account with daemon privileges? how much per month it's than? DR>> fidonet is basing on possibility of direct connects, so, which DR>> number has to be dialed to connect an ip-system? NS> the number of your local isp. DR> this charges additionally to my normal phonebill. i need to have a DR> phoneline and a modem (analog or ISDN) to get a connect as well. i assume that having a fidonode you already have a phoneline and a modem. now: if you want to call an ip-only fidonode that's going to be long distance, you pay: (1) local access charges and (2) isp charges. if you want to call a pstn-only node that's going to be long distance, you pay (1) local access charges and (3) long distance toll. (1) is the same in both cases. (2) is obviously lower than (3), i've given some examples here last week. even if you don't pay (1) when you access long distance carrier, (1)+(2) will work out cheaper than (3). if the ip-only node you want to call is local for you, then you either connect to it's hub (which in any case shall support both transports to act as a gateway) paying the same charge (1) as for connecting to any other pstn node, or, should you prefer to connect directly, you pay premium (2). so, for you it works out more expensive in the only case when you want to connect a local ip-node directly. but it's still possible as a last resort and not *that much* more expensive. NS> but enforcing fts-0001 support for ip-only systems is not going to NS> improve the situation in any way as they still won't be able to NS> connect directly to pstn-only systems! DR> for being the most common dominator i don't see a way DR> around. i still don't see any logical sequence here. NS> the whole fidonet has a choice now. DR> to skip it's own rules. to adopt new technologies that address today realities. NS>> it took me half an hour to install binkd. DR>> those 30 minutes spare time per day (which are not given every day) NS> you're not going to install binkd every day. believe me, it's a pretty NS> robust daemon and not windows/95 ;) DR> but unreliable (not autoresume etc). it is as realiable as you can be over tcp (and i mean it literally - it's even more reliable than ftp, i've got the experience) and it does have autoresume. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1209 [1995] Scn From : Pedro Lima 2:362/21 31 Oct 97 04:23:26 To : Pablo Saratxaga 02 Nov 97 05:39:48 Subj : IP-access ------------------------------------------------------------------------------- PS> But I think that if it is standardized and works well the other zones PS> DNS will follow. I apologize for not having explained myself clearly. What I was saying is that I agreed with the proposed delegation within the fidonet.org domain. But, although I have full confidence in the managers of the fidonet.org domain, I disagree to limit the possibilities of FQDN usage in FidoNet to one particular domain (or a limited number of), be it fidonet.org, microsoft.com or whatever.dom. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1210 [1995] Scn From : Nick Soveiko 2:5030/69.101 30 Oct 97 15:40:52 To : Dieter Ringhofer 02 Nov 97 05:39:48 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Wed, 29 Oct 1997, 05:34, Dieter Ringhofer (2:2476/14) ==> Nick Soveiko: DR>> tcp provides reliable point-to-point services (compare it with UDP) DR>> but, it isn't all you need. NS> yep, it's not all. what you need is (1) reliable service (2) NS> stream-oriented. tcp/ip provides both. it's also NS> connection-oriented, bit we don't really care about that. DR> that's the part of tcp and makes the whole thing almost reliable. what do you mean by 'almost unreliable'? NS>> do you know many of them? DR>> not many but, i know several tcp/ip implementations ;) NS> does any of them lack reliable and/or stream-oriented performance? DR> under some circumstances they ALL lack reliability. sorry for a long quote, but i feel it necessary here.
TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION 1. INTRODUCTION The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks. [skip] 1.5. Operation As noted above, the primary purpose of the TCP is to provide reliable, securable logical circuit or connection service between pairs of processes. To provide this service on top of a less reliable internet communication system requires facilities in the following areas: Basic Data Transfer Reliability Flow Control Multiplexing Connections Precedence and Security The basic operation of the TCP in each of these areas is described in the following paragraphs. Basic Data Transfer: The TCP is able to transfer a continuous stream of octets in each direction between its users by packaging some number of octets into segments for transmission through the internet system. In general, the TCPs decide when to block and forward data at their own convenience. Sometimes users need to be sure that all the data they have submitted to the TCP has been transmitted. For this purpose a push function is defined. To assure that data submitted to a TCP is actually transmitted the sending user indicates that it should be pushed through to the receiving user. A push causes the TCPs to promptly forward and deliver data up to that point to the receiver. The exact push point might not be visible to the receiving user and the push function does not supply a record boundary marker. Reliability: The TCP must recover from data that is damaged, lost, duplicated, or delivered out of order by the internet communication system. This is achieved by assigning a sequence number to each octet transmitted, and requiring a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a timeout interval, the data is retransmitted. At the receiver, the sequence numbers are used to correctly order segments that may be received out of order and to eliminate duplicates. Damage is handled by adding a checksum to each segment transmitted, checking it at the receiver, and discarding damaged segments. As long as the TCPs continue to function properly and the internet system does not become completely partitioned, no transmission errors will affect the correct delivery of data. TCP recovers from internet communication system errors. Flow Control: TCP provides a means for the receiver to govern the amount of data sent by the sender. This is achieved by returning a "window" with every ACK indicating a range of acceptable sequence numbers beyond the last segment successfully received. The window indicates an allowed number of octets that the sender may transmit before receiving further permission. Multiplexing: To allow for many processes within a single Host to use TCP communication facilities simultaneously, the TCP provides a set of addresses or ports within each host. Concatenated with the network and host addresses from the internet communication layer, this forms a socket. A pair of sockets uniquely identifies each connection. That is, a socket may be simultaneously used in multiple connections. The binding of ports to processes is handled independently by each Host. However, it proves useful to attach frequently used processes (e.g., a "logger" or timesharing service) to fixed sockets which are made known to the public. These services can then be accessed through the known addresses. Establishing and learning the port addresses of other processes may involve more dynamic mechanisms. Connections: The reliability and flow control mechanisms described above require that TCPs initialize and maintain certain status information for each data stream. The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection. Each connection is uniquely specified by a pair of sockets identifying its two sides. When two processes wish to communicate, their TCP's must first establish a connection (initialize the status information on each side). When their communication is complete, the connection is terminated or closed to free the resources for other uses. Since connections must be established between unreliable hosts and over the unreliable internet communication system, a handshake mechanism with clock-based sequence numbers is used to avoid erroneous initialization of connections. Precedence and Security: The users of TCP may indicate the security and precedence of their communication. Provision is made for default values to be used when these features are not needed. [skip] 2.2. Model of Operation Processes transmit data by calling on the TCP and passing buffers of data as arguments. The TCP packages the data from these buffers into segments and calls on the internet module to transmit each segment to the destination TCP. The receiving TCP places the data from a segment into the receiving user's buffer and notifies the receiving user. The TCPs include control information in the segments which they use to ensure reliable ordered data transmission. The model of internet communication is that there is an internet protocol module associated with each TCP which provides an interface to the local network. This internet module packages TCP segments inside internet datagrams and routes these datagrams to a destination internet module or intermediate gateway. To transmit the datagram through the local network, it is embedded in a local network packet. The packet switches may perform further packaging, fragmentation, or other operations to achieve the delivery of the local packet to the destination internet module. At a gateway between networks, the internet datagram is "unwrapped" from its local packet and examined to determine through which network the internet datagram should travel next. The internet datagram is then "wrapped" in a local packet suitable to the next network and routed to the next gateway, or to the final destination. A gateway is permitted to break up an internet datagram into smaller internet datagram fragments if this is necessary for transmission through the next network. To do this, the gateway produces a set of internet datagrams; each carrying a fragment. Fragments may be further broken into smaller fragments at subsequent gateways. The internet datagram fragment format is designed so that the destination internet module can reassemble fragments into internet datagrams. A destination internet module unwraps the segment from the datagram (after reassembling the datagram, if necessary) and passes it to the destination TCP. This simple model of the operation glosses over many details. One important feature is the type of service. This provides information to the gateway (or internet module) to guide it in selecting the service parameters to be used in traversing the next network. Included in the type of service information is the precedence of the datagram. Datagrams may also carry security information to permit host and gateways that operate in multilevel secure environments to properly segregate datagrams for security considerations. [skip] 2.6. Reliable Communication A stream of data sent on a TCP connection is delivered reliably and in order at the destination. Transmission is made reliable via the use of sequence numbers and acknowledgments. Conceptually, each octet of data is assigned a sequence number. The sequence number of the first octet of data in a segment is transmitted with that segment and is called the segment sequence number. Segments also carry an acknowledgment number which is the sequence number of the next expected data octet of transmissions in the reverse direction. When the TCP transmits a segment containing data, it puts a copy on a retransmission queue and starts a timer; when the acknowledgment for that data is received, the segment is deleted from the queue. If the acknowledgment is not received before the timer runs out, the segment is retransmitted. An acknowledgment by TCP does not guarantee that the data has been delivered to the end user, but only that the receiving TCP has taken the responsibility to do so. To govern the flow of data between TCPs, a flow control mechanism is employed. The receiving TCP reports a "window" to the sending TCP. This window specifies the number of octets, starting with the acknowledgment number, that the receiving TCP is currently prepared to receive. [skip]
so what you said essentially means that *all* tcp implementations are not rfc-compliant. it means that that's *not* tcp. period. NS> this message i'm writing right now will be delivered to you by means of NS> binkp over tcp/ip. binkp has *neither* error control, nor packet NS> sequence recovery. DR> that's bad and it's somewhat unusable for this. one of my tests DR> with tcp was getting a somewhat huge filenet from a ip-system. i DR> tried it three days and stopped it than, getting it with normal FTN DR> long distance calls is cheaper for me. did the protocol you've been using have autoresume? this, together with the ability to control timeouts, makes a big difference on really poor quality tcp connections. NS> if tcp/ip is not a reliable and/or stream-oriented service (as NS> you seem to claim), you won't be reading this. if you do, either NS> something is wrong with your arguments or my english is not good enough NS> to understand you. elaborate, please. DR> see documentation of tcp/ip development kit from IBM as an example DR> of explanation, please, it's written by native english speaking DR> persons. most propably lack of knowledge of english language is on DR> my side ;) url? i've searched ibm site today and found nothing remotely resembling what you claim. and i highly doubt than a tcp/ip stack from ibm would be not rfc-793 compliant. cheers, nick --- Handwritten * Origin: <-<-<- Houses of the hairy (Overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1211 [1995] Scn From : Pedro Lima 2:362/21 31 Oct 97 03:53:20 To : Rune Johansen 02 Nov 97 05:39:48 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- RJ> Then a IP-based mailer could trigger in the first two RJ> chars, and select the transport on the third (and beyond). How can I filter out these entries with my PSTN mailer (FD 2.02/NC), not being forced to specify all existant "variants" of IP* flags? Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1212 [1995] Scn From : Nick Soveiko 2:5030/23.101 30 Oct 97 17:38:02 To : Rune Johansen 02 Nov 97 05:39:48 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Wed, 29 Oct 1997, 01:24, Rune Johansen (2:210/20) ==> Marco d'Itri: > This is not true, I can install any daemon I want on unprivileged ports. > I just need a shell account. And I don't have to bother the sysadmin to > change the configuration and so on. RJ> _you_ can, yes. I can too, until the SysAdmin at the ISP login RJ> server figures out what I am doing. Then I'll get kicked out. i've spent some time today surfing web pages of isp's offering shell accounts. most of them allow running background daemon processes either as is, or for a nominal additional fee that totals to about $10-15/mo including 10-20 megs of disk quota. provided, ofcourse, the daemons don't create security problems. after all, that's what most of shell accounts are most useful for - irc bots ant stuff like that. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1213 [1995] Scn From : Dima Maloff 2:5047/13 01 Nov 97 12:09:00 To : Kim Heino 02 Nov 97 05:39:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thursday October 30 1997 23:02, Kim Heino wrote to Nick Soveiko: KH> But the question is still valid, which one is the minimal requirement: KH> FTS-001 over raw or FTS-001 over telnet? In my opinion, it's ok if a node KH> can do raw OR telnet. If both are ok, then why not to allow binkp? FTS-1 over TELNET and FTS-1 over TCP are not compatible anyway. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1214 [1995] Scn From : Ger Vloothuis 3:633/284 26 Oct 97 13:43:34 To : Ask Bjoern Hansen 02 Nov 97 05:39:48 Subj : IP-access ------------------------------------------------------------------------------- Hi Ask, Ask Bjoern Hansen wrote in a message to Denis McMahon: ABH>> I guess you should read something about how it works. ABH>> It's very easy to redelegete f.x. n251.z2.fidonet.org to a ABH>> nameserver controlled by someone in your net. DM> It should not be a requirement that a net maintain a nameserver before DM> that net is allowed to contain IP nodes! ABH> Agree. But I didn't say you *have* to redelegate the zone, just ABH> that it's possible, and easy. ABH> I still think the best solution are getting the ip numbers via dns ABH> and not via some hack in the nodelist. Hear, hear. Numbers are for machines. Domain names are for humans. Machines and IP addresses can change without effect on the universal and portable domain name. Fully agree. Regards Ger --- WtrGate v0.93.p2 Unreg * Origin: Teletechnique Melbourne (3:633/284) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1215 [1995] Scn From : Rune Johansen 2:210/20 01 Nov 97 04:02:36 To : Slava Filimonov 02 Nov 97 18:19:50 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Let's not be ridiculous twice - we can use _another_ port for FTS-* and > BinkP on it's own in single program/daemon. Why all of you stuck on word And how do you suggest that it should be indicated in a nodelist? > FALLBACK? what's wrong to have separate protocols on separate ports? Just > imagine TCP/IP having one port and FALLBACK to FTP/HTTP/SMTP/POP3/all other > protocols... I am stuck on the word fallback to the (always) current minimum session protocol in fidonet. That's because if you have only one port available for a IP-only node, it must have at least one protocol to talk with, if the calling party does not speak your flavor of session protocol. Today that required protocol is FTS-0001. Tomorrow it may be BinkP. I have four different ways of connecting via IP (IPT, IPR, IPC and IPI). You support IPR (IP raw TCP). If I have the possibility to connect to you via IPR, I can call you via IP, since I have a transport protocol interface to my mailer that can do it. So, when I connect, I cannot talk BinkP, because that is not implemented in my mailer. But, I can talk FTS-0001, since it is required as a minimum protocol in fidonet. Do you see the difference between the raw TCP and the BinkP? One is the connection type, the other is the session handshake. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1216 [1995] Scn From : Lech Szychowski 2:480/33.7 01 Nov 97 14:46:00 To : Pablo Saratxaga 02 Nov 97 18:19:50 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- > Then nodes whith common protocols can poll each other. imposing a > standard now will de facto create less connectivity than before. Perhaps for a while, yes. But just for a while. > Then if the TCP/IP channel gets popular the standards will automatically > emerge by themselves. From my personal point of view it is acceptable. But it breaks the old Fidonet rule of defining standards common to everyone and ensuring total connectivity - and that frightens me a bit. > Think of TCP/IP nodes as ISDN ones; there is no obligation to support a > given type of ISDN protocol to have the ISDN capabilities listed. > So it should be for IP nodes. If there was no existing casus like the ISDN one, I wouldn't even dare to suggest such solution :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1217 [1995] Scn From : Rune Johansen 2:210/20 01 Nov 97 03:41:26 To : Pablo Saratxaga 02 Nov 97 18:19:50 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > to the BBS. There is no need to stuck the both on the same port, indeed I > think it is wrong. That will lead to complexity and problems on programs as What does a mailer today do? It tries to detect a mailer handshake, and if it fails, it connects you to the BBS, or tell you "Press ESC to enter BBS". Whats the difference between a mailer that listens to _one_ port on IP and a mailer that listens to _one_ modem port? The complexity already exists in a ordinary mailer. > they need to be able to detect various different protocols. While if > you keep one port per protocol there is no need for all that complexity, > the protocol to be expected is determined by the port used. If you are not able to (or willing to) run the "default" ports, you have to indicate what session handshake protocol is available on wich IP port. That means that we would have to say that "this port handles EMSI, this port handles BinkP, this port handles FTS-0001" and so on. If all ports would handle a fallback to the current lowest protocol (today that is FTS-0001, tomorrow maybe something else), there would be no problem for a conencting mailer. How else whould it be denoted what port to fallback to if they have not got the respective protocol available? > Try thinking on what will be if http, ftp, smtp, nntp, nfs, ... etc use all > the same port ? You will need a program that need to know all those protocols > and call the right server for each connection. A real taste of what could be > the hell... For direct mailer-to-mailer communication we have today four different types of connection in use: Via telnet, via raw TCP, via VModem prop., and via ifcico proprietary protocol. When http-able mailers comes to a implemented protocol, we will address it. FTP is per today not a mailer-to-mailer compatible protocol (handshake etc.), netiher are the others you describe. >> BinkP is a truly fast and efficient protocol, but it limits itself too >> much for >> future expansion and use > It limits itself to what it has been designed to: a FTN mailer protocol. >There is absolutely no point in making it handle interactive sessions or thing > like that. It limits itself to FTN networks, that is true. But, that's waht it has been designed for. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1218 [1995] Scn From : Rune Johansen 2:210/20 01 Nov 97 03:50:40 To : Pablo Saratxaga 02 Nov 97 18:19:50 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >The cases where there is a mailer and BBS on telnet or vmodem is because those > programs ARE NOT internet able programs, they still thing they are using > a modem and a phone line. Oh? So, if I use a FOSSIL-able telnet daemon, giving my mailer a RING when a incoming connection is being made is not internet-able? They use something they believe to be a modem, but it's internet-able anyway. It has got a mailer, AND a BBS available on the same port. Or even better: try to telnet to fix.no, and see what you get there. It's a BBS, sending EMSI handshake, and has got a fallback to FTS-0001. It's fully internet capable, AND it has got a BBS running on it. We have been transferring fidonet mail sessions over the internet on it for over a year now. They don't need to add a mailer on another port. > They have to anyway ! You can't just use a normal modem mailer on a telnet > client. You need a special maler supporting vmodem or telnet. Why is it that 2:20/11 has got a FrontDoor 2.30 running on telnet daemon then? It's a DOS program running behind a telnet daemon, with fallback to a BBS program. Looks to me as a normal modem mailer on a telnet daemon. For the polling, there has to be a special program, yes, but that has got nothing to do with the daemons running. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1219 [1995] Scn From : Rune Johansen 2:210/20 01 Nov 97 03:51:14 To : Pablo Saratxaga 02 Nov 97 18:19:50 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > BTW is there any TCP/IP able mailer that uses otherthing than a binkley > compatible in/outbound tree ? I know of none. Yes, BBBS uses FrontDoor-style outbound. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1220 [1995] Scn From : Lech Szychowski 2:480/33.7 01 Nov 97 14:49:00 To : Nick Soveiko 02 Nov 97 18:19:50 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > LS> Could you point me to sources for this mailer/daemon? I'm genuinely > which one? [...] > latest binkd can be found at http://www.magadan.su/~maloff/binkd/. a > 0.9.2 release is coming anytime now. The above. Thanks a lot, will try it soon. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1221 [1995] Scn From : Lech Szychowski 2:480/33.7 01 Nov 97 15:19:00 To : Ward Dossche 02 Nov 97 18:19:50 Subj : A bit of steering ... ------------------------------------------------------------------------------- > So any sollution that will be adopted will have to be a nodelist- > sollution. I think we all agree on that. What we have different opinions on is how we get an IP node listed :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1222 [1995] Scn From : Rune Johansen 2:210/20 01 Nov 97 04:14:34 To : Yuri Teterin 02 Nov 97 18:19:50 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> As I have stated in my 1st proposal, I have changed a little in my views. >> I now consider BinkP as a protocol alongside EMSI, FTS-6 and FTS-1 over a >> raw TCP session. > Your proposal is logicaly true. The only disadvantage is that it does not > reflect the requirements of the real life, so it will not be used by at least > 1/2 of IP-nodes. It reflects the requirement of being a node in Fidonet, the possibility to accept a FTS-0001 session handshake on the transport protocol that you have a mailer on. >> As long as BinkD cannot do FTS-1 fallback, it will not meet the >> requirements of a Fidonet Nodestatus. If you have a mailer that has got >> the fallback, you can use it. > But it can be stated rather definitely that none of existing mailers run > BinkP and FTS-0001 at the same port, and there is no reasons to suspect that > some mailer will ever do this. BBBS (that I run) can do BinkP, EMSI and FTS-0001 on the same port. > So your proposal will actualy cut all BinkP-based part of FIDO and leave it > out of nodelist. It will cut all current BinkD 0.9.1-only IP-only nodes, until it has implemented a fallback routine to the required minimum session handshake protocol in Fidonet. > These are not just the words. All these processes run in ex-SU now. If new >proposals concerning IP-nodes will not be usefull for BinkP sysops and authors > of FIDO software (and yours definitely aren't), they just will not be taken >into account. As a result all IP-sysops will be divided into 2 separate groups > without common interests, that will develop separately and independantly. That is completely true. But, by ex-SU sysops only using BinkD, they fail to adhere to the basic rule of connectivity in Fidonet, namely the requirement of accepting a FTS-0001 session, if the caller has got no other session handshake protocol in common. In practice that means that they already have their own network, that is non-fidonet compatible. If BinkD (that is used in the ex-SU) would implement a FTS-0001 handshake if the BinkP handshake fails, it would be compliant with the current requirement of Fidonet. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1223 [1995] Scn From : Lawrence Garvin 1:106/6018 01 Nov 97 11:57:50 To : Lech Szychowski 02 Nov 97 18:19:50 Subj : IP-access ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Lech Szychowski said in a message to Lawrence Garvin: > LS> For just itself? Not being a hub, host or any non-leaf in routing > LS> topology? > Nope. Just because my system can send/receive SMTP, does not imply > that it has the necessary software gateways installed to make that > information available to Fidonet. LS> Not to Fidonet, but just to _you_, the sysop of the node. Even to that extent, the SMTP may still be totally separate from the Fidonet. For several weeks after I got the sendmail and domain running, the only way I had to read mail was from a POP server on the system and my Netscape for OS/2 mail reader. It wasn't until some time later that I installed the gateway so that the email was available to the BBS and my FTN reader. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1224 [1995] Scn From : Lech Szychowski 2:480/33.7 01 Nov 97 14:27:00 To : Pablo Saratxaga 02 Nov 97 18:19:50 Subj : IP-access ------------------------------------------------------------------------------- > The reason is that it is already done in z2.fidonet.org, while on other > zones DNS there are only MX entries (=Mail eXchangers=internet->fido mail > gateways) and not A entries (=IP addresses=fidonet nodes TCP/IP pollables). You mean they have all their MX'es in other domains? Strange idea... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1225 [1995] Scn From : Lech Szychowski 2:480/33.7 01 Nov 97 14:37:00 To : Pablo Saratxaga 02 Nov 97 18:19:50 Subj : IP-access ------------------------------------------------------------------------------- > BTW, what are the codes used by other TCP/IP protocols on EMSI ? > ifcico compatibles use "TCP", what uses binkp ? I can't remember I had any connections with BinkD or Argus, so I'm afraid I can't help you here. > But maybe it isn't impossible to use protocol codes for raw TCP > connections and have the mailers use the better common TCP protocol ? TCP seems to be the protocol of choice here since it provides us with much of an error control by itself - and I think this is the common opinion among all of us here. The big question is what kind of protocol(s) we should run over this TCP/IP link... Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1226 [1995] Scn From : Chris Maddock 3:640/302 01 Nov 97 08:29:54 To : Pedro Lima 02 Nov 97 18:19:50 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- On 30 Oct at 19:58, Pedro Lima of 2:362/21 wrote to Chris Maddock: PL> Hello, CM>> Correct. The only problem may be with a new node incorrectly setting CM>> up their software. PL> The same would apply with the current situation. E.g. if I decided to PL> translate the '351' prefix to '115' then every time I tried to poll a PL> portuguese node I'd be calling the emergency service... :-) Yes. I guess it could cut that way. I was more referring to the likelyhood of someone not configuring the software with =any= long-distance codes. But the defaults normally would take care of that. They would have to strip out the default settings. So a moot objection on my part. PL> That's why I PL> think that the '000' prefix solution is addressing a problem that should PL> not exist. But as it does, and as we can avoid most of its drawbacks PL> with a simple solution, then why not? Absolutely. It is certainly the easiest of all the solutions I've seen. CM>> Okay. You are referring to hubs, *EC's etc I guess ?? PL> For example. CM>> Yes. But Fidonet only =is= a limitation. CM>> We are proposing to add the internet to our capabilities. Or is that CM>> what you meant ? PL> I'm not sure of what you're saying here. Sorry. I read it a moment ago and understand why you are puzzled as to what I meant. I meant "But Fidonet-only, =is= a limitation." PL> If you're saying that using PL> solely the telephone network is a limitation, yes, I agree, and I also PL> think it's fairly easy to extend the possibilities for a FidoNet PL> connection, such as using the Internet. That is what I meant. That we can expand our horizons to encompass the Internet, and =any= other technology, would be great! . PL> In the case of the Internet, I see no need to limit the FQDN PL> possibilities, since that would be similar, in the case of the PSTN, to PL> only allow the numbers of certain telcos into the nodelist. Agreed. It needs to be expandable almost indefinitely. The limitations early-Fidonet imposed on itself must be avoided at all costs. The most notable limitation was software that processed the nodelist - as the size grew, the software repeatedly broke. This scenario =must= be avoided. CM>> Seeing the amount of discussion here is great ! PL> It's specially the overall quality of the discussion I'm liking. :-) Absolutely. Magic! PL> Lets see what we can do to help. PL> That's the FidoNet spirit. :-) Agreed. That's why I'm here. Dunno if I can help, but I'll try, and I'm here. Regards, Chris Maddock chrism@bbs.st.net.au --- Msged/386 4.20 beta 2 * Origin: Diagnostic CBBS - DownUnder - (3:640/302) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1227 [1995] Scn From : Lech Szychowski 2:480/33.7 01 Nov 97 15:17:00 To : Ward Dossche 02 Nov 97 18:19:50 Subj : IP-access ------------------------------------------------------------------------------- >> about nodelist that you are not afraid of letting regions manage their >> segments/parts while you are afraid of letting them manage their >> subdomains? > Quite easy ... managing nodelist-segments has been regulated inside > fido. That's the difference. RC is responsible for managing his regional segment but does not have to do it himself, right? He can have another person undertake this task on his behalf - this changes nothing in the aspect of his being responsible for the results. Why can't you say that if RC claims his region can have his own subdomain delegated and if he proves it (establishing MX'es, filling in all necessary records etc - the usual procedure with delegating subdomains satisfied) he can be allowed to do so? DNS is a hierarchical structure, if anything goes haywire with this subdomain all you have to do is remove the delegation at the next upper level. Leszek. To All: sorry for keeping on discussing this issue here, but IMHO without delegating subdomains all the idea of IP-based connectivity for Fidonet is substantially broken. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1228 [1995] Scn From : Lech Szychowski 2:480/33.7 01 Nov 97 15:01:00 To : Pablo Saratxaga 02 Nov 97 18:19:50 Subj : IP-access ------------------------------------------------------------------------------- > LS> BTW: if there is an A record for an FQDN, there is no point in > LS> listing an MX record for this FQDN (unless we explicitely want > Each fqdn that wants to receive email *MUST* have an MX, it can point to > itseld. But whithout an MX there is no guarantee at all that mail will > be sent. Are you 101% sure about that? I think vast majority of existing MTAs will first try MX for a given FQDN and if it fails (ie DNS query returns no MX type records) they go for the A record(s) instead. > f33.n480.z2.fidonet.org. A 123.45.67.89 > is wrong. Why? If 123.45.67.89 is an SMTP capable host, it will work. It might be not the most elegant solution, I agree. It might also be against recommendations. But it will work. > f33.n480.z2.fidonet.org. A 123.45.67.89 > MX 1 f33.n480.z2.fidonet.org. > MX 10 elsewhere.net. > * MX 10 f33.n480.z2.fidonet.org. > MX 20 elsewhere.net. > is right Only if you put $ORIGIN f33.n480.z2.fidonet.org. in front of the wildcard record :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1229 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:12:26 To : Lech Szychowski 02 Nov 97 18:22:26 Subj : Re: IP-access ------------------------------------------------------------------------------- > Why are you so afraid that someone will abuse DNS? What's so different > about nodelist that you are not afraid of letting regions manage their > segments/parts while you are afraid of letting them manage their > subdomains? Quite easy ... managing nodelist-segments has been regulated inside fido. That's the difference. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1230 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:24:54 To : Slava Filimonov 02 Nov 97 18:22:26 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Slave, > WD> The core of Fidonet is the nodelist, think twice about that. > The _real_ core of Fidonet still public phone line. Nodelist is just > phone directory like yellow pages in each phonebox. Guess what is the > core of internet , and then think twice about that. 1) The core of Fidonet is the nodelist. 2) We are discussing the use of IP as a carrier for Fido-sessions. 3) We are not discussing what the core of the internet is. So any sollution that will be adopted will have to be a nodelist-sollution. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1231 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:42:08 To : Lawrence Garvin 02 Nov 97 18:22:26 Subj : Re: Controversy Regarding Node Number ------------------------------------------------------------------------------- Lawrence, > Hey Ward! Can I get a Zone 2 node number? > But seriously... In the test-environment this should be possible ... you'd have to run the zone-2 version of the nodelist as well though. If you want to give it a try a raise hell I'm your man ... ;-) \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1232 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:34:30 To : Lawrence Garvin 02 Nov 97 18:22:26 Subj : Re: A bit of steering ... ------------------------------------------------------------------------------- Lawrence, > Forgive me, Ward, I didn't realize this was a Zone 2 only project, > although I have noticed a critical dearth of otherzone sysops in this > echo. :( If the other ZC's want to join the exercise I have no problem to make this a worldwide thing, you know. I just didn't want to bother anyone outside my realm of dictatorship. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1233 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:18:08 To : Pedro Lima 02 Nov 97 18:22:26 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Pedro, >> Is the reference 'FTS-0001' copyrighted? > WD> Yes. > Ok, then we'll have to interpret what's said in P4 in a different way > (as I believe it was intended in the first place anyway), or replace P4 > altogether, if we want to do it 'by the book'. So far, concerning trying to get IP in, I think nothing is (nor can be) according to the book. BTW, some guys are threatening me with formal complaints if I continue this effort. I think they picked the wrong target to waste ammunition. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1234 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:16:06 To : David Moufarrege 02 Nov 97 18:22:26 Subj : Re: IP-nodes ... ------------------------------------------------------------------------------- David, > I'd be interested to see this. Anyway I can get you to e-mail attach me > that segment for review here? You can freq "IP" here. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1235 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:27:46 To : Chris Maddock 02 Nov 97 18:22:26 Subj : Re: IP-nodes ... ------------------------------------------------------------------------------- Chris, > Alwyn (Z3C) may be interested in your "local" segment. > You might want to check with him. I'll get in touch with him. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1236 [1995] Rcv Scn From : Ward Dossche 2:292/854 31 Oct 97 20:19:26 To : Lothar Behet 02 Nov 97 18:22:26 Subj : Re: IP-Test 2:2/3000 ------------------------------------------------------------------------------- Lothar, > WD> ... I got worried at some point when at a Fridaymorning the > WD> modem was so silent.. > The silence did disturb your rest? :) Indeed ... \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1237 [1995] Scn From : Ward Dossche 2:292/854 31 Oct 97 20:49:50 To : All 02 Nov 97 18:22:28 Subj : Yoohoo ------------------------------------------------------------------------------- Due to job-related time-constraints I have been a bit absent here. This will now be a bit better. >I've gone through all the mail which was addressed to me and to "All". If someone thinks I missed something essential then please netmail me. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1238 [1995] Scn From : Dieter Ringhofer 2:2476/14 02 Nov 97 11:06:58 To : Dima Maloff 03 Nov 97 05:38:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> but it skips the smallest common dominator. if there's an DR>> implementation of fts-0001 it doesn't mean that one has to use it DR>> instead a more efficient solution. it offers the chance for systems DR>> to use it in case of having nothing else available but real DR>> ftn-software. DM> Wrong. One will need a Vmodem-like driver. i already have it since longer time than binkp exists ;) DM> Moreover, even if you'll use a Vmodem-like to run your old DM> Fido-software, you'll have to run, say, 3 mailers to accept 3 DM> concurrent inbound connections. Unlike Binkd or Argus (they start new DM> line only on incoming calls). that's somewhat wrong because it's a question of implementation and secure functionality. you forgot to mention Adept where every line is a thread only ;) the problem with such solutions is total loss of connectivity if ONE process (task) is interrupted or (much more worse) 'hanging' in some way. running several processes with the same program increases secure functionality, with a good operating system it doesn't cause significant increase of needed system resources for loading the program only once in reality and using only process specific additional memory (you need this for seperated threads as well). connectivity might be lost for one port (independant of being a comport or a daemon) but, this can be checked very easy and appropriate action can be triggered. running one process only for all functions needs a much more sofisticated watchdog to ensure functionality. such egg-laying wool-milk-pigs aka all-in-one solutions are not always the best way to go. DR>> don't forget what we're talking about (hint: listing of ip-systems in DR>> a ftn-nodelist). check bbbs and you will see: it's possible. DM> Sure. But why support something that will never be used? if i try to connect at a FD or Xenia system and there's a typo at password setup those frontends kick connection ASAP. without fts-0001 i have no chance to ask the sysop of the other system why such reaction occured with a crashmail. in such cases it's still in use and needed. f.e. with Cantaloup there's no real need for it, it puts received packets into insecure inbound and doesn't send anything in such sessions when being called resp. does a password overwrite at an outgoing call and sends only bundles for the aka being the called one. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1239 [1995] Scn From : Dieter Ringhofer 2:2476/14 02 Nov 97 08:08:26 To : Yuri Teterin 03 Nov 97 05:38:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> than i skip zmh with my modems. it's the same for anybody like an DR>> ip-only system for a non-ip one. DR>> got the point? YT> Or like an ISDN-only system for a non-ISDN one. But there are already YT> about 600 ISDN-only systems in nodelist, and nobody complain on this fact. even when having all technologies available and in use (isdn, analog up to x2-server) i'm complaining about. imo it has been a mistake to list such systems as full featured nodes (according policy) because they aren't. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1240 [1995] Scn From : Dieter Ringhofer 2:2476/14 02 Nov 97 08:22:14 To : Nick Soveiko 03 Nov 97 05:38:56 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- DR>>> tcp provides reliable point-to-point services (compare it with UDP) DR>>> but, it isn't all you need. NS>> yep, it's not all. what you need is (1) reliable service (2) NS>> stream-oriented. tcp/ip provides both. it's also NS>> connection-oriented, bit we don't really care about that. DR>> that's the part of tcp and makes the whole thing almost reliable. NS> what do you mean by 'almost unreliable'? 'un' means some kind of protocols. NS>>> do you know many of them? DR>>> not many but, i know several tcp/ip implementations ;) NS>> does any of them lack reliable and/or stream-oriented performance? DR>> under some circumstances they ALL lack reliability. NS> sorry for a long quote, but i feel it necessary here. no need, i've this (and more) available locally. NS> A stream of data sent on a TCP connection is delivered reliably and in NS> order at the destination. what about datagram oriented services? NS> An acknowledgment by TCP does not guarantee that the data has been NS> delivered to the end user, but only that the receiving TCP has taken NS> the responsibility to do so. ! don't forget this. NS> so what you said essentially means that *all* tcp implementations are not NS> rfc-compliant. it means that that's *not* tcp. period. i say that some of underlaying protocols (remember: tcp is layer 4) don't take care about some issues mentioned. this can cause (and causes sometimes) loss of data or defect transmission. NS>> binkp over tcp/ip. binkp has *neither* error control, nor packet NS>> sequence recovery. DR>> that's bad and it's somewhat unusable for this. one of my tests DR>> with tcp was getting a somewhat huge filenet from a ip-system. i DR>> tried it three days and stopped it than, getting it with normal FTN DR>> long distance calls is cheaper for me. NS> did the protocol you've been using have autoresume? i tried it with conventional tcp/ip services as well as via vmodem. the link has been unreliable everytimes. DR>> see documentation of tcp/ip development kit from IBM as an example DR>> of explanation, please, it's written by native english speaking DR>> persons. most propably lack of knowledge of english language is on DR>> my side ;) NS> url? no url except a password protected one at IBM, it's a commercial product. NS> what you claim. and i highly doubt than a tcp/ip stack from ibm would NS> be not rfc-793 compliant. they are, but they know about the problems ;) --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1241 [1995] Scn From : Dieter Ringhofer 2:2476/14 02 Nov 97 10:01:46 To : Dima Maloff 03 Nov 97 05:38:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DM> We (or I) do not WANT, we've DONE already. And now we don't want more DM> problems for the largest fido-over-IP community. where's the problem with being compliant to the rest of the fido-world to offer ftn-fallback even via ip? DR>> That's not point of discussion. Subtopic is to get a common protocol DR>> for all media in use to (topic) have a chance to list systems using DR>> another medium. DM> 30.000+ will have to change something to use IP anyway. no, there's absolutely no need for it. check available software (not only binkd) and you must agree. we have the chance to use improved things but, there's no need for it to get functionality. watch this little difference, please! DM> And listen, after all, we do not want for BINKP to be a mandatory DM> standard. We just hate to be forced to add vmodem. there should be a mandatory standard to ensure connectivity or we can get rid of every ftn. the least common dominator in fidonet is fts-0001, that's reality. skipping it makes things more worse than they are in between. think about what you want and accept needed things. DR>> Maybe this leads to an understandable example for you: DR>> How does Binkd react when a password error occures (caused by a typo)? DM> Reports a error. will bundles be transferred and accepted than? --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1242 [1995] Scn From : Dieter Ringhofer 2:2476/14 02 Nov 97 10:50:50 To : Nick Soveiko 03 Nov 97 05:38:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- NS> [] NS>> that's the situation we have today. DR>> but it skips the smallest common dominator. NS> the common denominator issue was covered quite elaborately in my message, NS> i think. refer back on the reply chain, as i'd better avoid overquoting. umpf {looking at the number of available messages....} my brain is intact so far to remember some main opportunities and the name of the writer. DR>> if there's an implementation of fts-0001 it doesn't mean that one DR>> has to use it instead a more efficient solution. it offers the DR>> chance for systems to use it in case of having nothing else DR>> available but real ftn-software. NS> it still does not. you have to have (1) 'real' ftn-software, (2) ip-fossil NS> emulation and (3) ip connection. if you try to look at pstn and ip as a medium only it's not the question how you access it. the question is the protocol being used between 'caller' and 'called' system. compare it with german and russian language: we can talk together, each of us using his native language. as long as there's a medium carrying the waves to the ear of the other one, we can listen and talk. this does not mean that we understand what the other one is talking. to achieve this we have to use a common language. that's what we are discussing here: usage of another medium. i'm in favour of it if it helps to improve something but we still must have a common 'language' (read: handshake). NS> btw, where can i check out this bbbs thing? have a look at scandinavia, there're several systems using it. Rune Johansen should be able to give you some pointers (he's registration site in norway). one finnish system running it is connecting here regullary since several months without problems. NS>> well. have a look at the nodelist statistics if you don't agree. DR>> this rapid shrinking in z1 is mostly a result of their calling cost DR>> scheme: free local calls. NS> that's a poor explanation. z1 is big. there are different telcos there NS> having different pricing approaches and different calling plans. there is NS> flat rate local calling, there are per-call charges, there are per-minute NS> charges, and there are all possible combinations of the above. i talked about this issue f.e. with Scott Dudley in june (he's a canadian but currently living and working in u.s.). he has been very surprised when he realized the cost scheme for telephone and internet being in use in germany. his comment: much more expensive, no real chance to become a common carrier at these prices. he is a trustworthy person for me who has a lot of knowledge in communication technologies and how to use it. i believe what he told about situation on the other side of the pond and his informations are 'first hand'. NS> my explanation is that shrinking of z1 is facilitated by (a) really NS> cheap internet access and (b) unflexibility of fidonet political and NS> technical documents. the second one is an issue but i don't believe that it beats the 'last node' that hard. NS> and with the ongoing telco demonopolisation in europe, you'll get the same NS> thing in a few years: cheap internet available over many physical media - i'm waiting for 1998 NS>> to get this connectivity. again, even now nothing but their own NS>> goodwill can force people to spend their own time and money to NS>> participate in fidonet. DR>> so far, so good but: don't mix participation with being a member. ;) NS> i am not mixing it. i've used this word here on purpose, as myself i am NS> not a member of fidonet, but i am spending my time and money to be here. i do the same over here and that's why i'm doing it: we can communicate. DR>>> what you propose is the death of fidonet. NS>> arguable. DR>> not that much: any ftn is basing on chance of DIRECT connects. DR>> that's impossible for ip. NS> i could argue that direct connect between any given pair of fidonet nodes NS> is not always possible over pstn too. so? is fidonet *already* dead? in parts, it is. see isdn-only systems, missing ic, ... NS>> (assuming modem is needed in any case) what is cheaper for cm in germany NS>> now: to get a second phone line or a unix shell account? DR>> in my area: a second (third, ...) line. NS> what??? you mean installation of a second phone line plus a *second modem* NS> is cheaper than setting up a unix account with daemon privileges? how much NS> per month it's than? installation of a phoneline (analog or isdn) takes DM 100.- once at the time. a cheap isdn-device for data transmission takes less than DM 100. monthly rate for isdn (two phonelines) is something about DM 44 at least (depends on services being ordered). a 'full account' at an isp without fixed ip-number and without own domain takes DM 30.- (or 35) per month at the cheapest isp over here for privat (personal) use. it does not include full featured daemon configuration capability for personal adaption according special needs, no directory at isp's server for continuous access from all over the world, ... when one wants to have a domain it takes several hundred DM to get it, it's additionally charged in dependancy of volume being transferred (commercial account). for both one needs to have a device to connect there via phoneline and the phoneline, so there're the same basic costs for minimal technical equipment to establish a connection. a permanent line charges with up to several thousand DM for installation and a very high fixed rate per month. some time ago there was the chance of a socalled 'semi permanent' line which charged something about DM 300,- per month for short distances (local calls). DR>>> fidonet is basing on possibility of direct connects, so, which DR>>> number has to be dialed to connect an ip-system? NS>> the number of your local isp. DR>> this charges additionally to my normal phonebill. i need to have a DR>> phoneline and a modem (analog or ISDN) to get a connect as well. NS> i assume that having a fidonode you already have a phoneline and a modem. if this line is in use i need to have another one for ip activities as well as additional equipment. NS> now: NS> if you want to call an ip-only fidonode that's going to be long distance, NS> you pay: (1) local access charges and (2) isp charges. NS> if you want to call a pstn-only node that's going to be long distance, you NS> pay (1) local access charges and (3) long distance toll. we have another scheme which is based on defined length of a 'unit' in dependancy of distance, daytime, etc (typically complicated like every german ruling). f.e. calling somebody in u.s. charges with price of one unit every seven seconds normally. NS> (1) is the same in both cases. (2) is obviously lower than (3), i've NS> given some examples here last week. even if you don't pay (1) when you NS> access long distance carrier, (1)+(2) will work out cheaper than (3). not everytimes. if process to transfer something via an isp takes more than the time of one 'cost unit' a simple crashmail being transferred within one unit is cheaper and one knows that it's at recipiant's system. NS> so, for you it works out more expensive in the only case when you want NS> to connect a local ip-node directly. but it's still possible as a last NS> resort and not *that much* more expensive. that's the reason why i'm searching for a solution to add ip-connectivity to ftn-systems. it does not mean that i want to get rid of ftn because it has several advantages over ip services. NS>> but enforcing fts-0001 support for ip-only systems is not going to NS>> improve the situation in any way as they still won't be able to NS>> connect directly to pstn-only systems! DR>> for being the most common dominator i don't see a way DR>> around. NS> i still don't see any logical sequence here. the 'club' decided that every member accepts incoming calls using this handshake. so, if i want to be a member of the club, i've to do the same. at the very first moment it's of no interest what i'm using additionally. NS>> the whole fidonet has a choice now. DR>> to skip it's own rules. NS> to adopt new technologies that address today realities. the question isn't about adding additional capabilities. nobody prohibits to introduce new things being ADDITIONAL. it happened with emsi, hydra, ... so it's possible with binkp as well. NS>> you're not going to install binkd every day. believe me, it's a pretty NS>> robust daemon and not windows/95 ;) DR>> but unreliable (not autoresume etc). NS> it is as realiable as you can be over tcp (and i mean it literally - it's NS> even more reliable than ftp, i've got the experience) and it does have NS> autoresume. that's fine ;) when it's capable to react properly on fts-0001 connects it might be ok to be used with fido. as long as it can't do this it's worthless for a fidonode. sorry, but there's still a piece of way to go. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1243 [1995] Scn From : Dima Maloff 2:5047/13 01 Nov 97 20:33:00 To : Lawrence Garvin 03 Nov 97 05:43:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thursday October 30 1997 23:11, Lawrence Garvin wrote to Pablo Saratxaga: LG> HOWEVER, the requirement exists. And lest we forget that -WE- are trying LG> to 'sell' this concept as a minority of nodes. The majority of Fidonet LG> nodes do NOT have IP-connectivity, and they could care less. The ONLY way LG> we'll ever get Fidonet as a whole to buy into permitting the listing of IP LG> capable nodes in the Fidonet Nodelist is if we can show that every node is Bad news, Garvin. You are in "a minority of a minority" -- most nodes DO use binkp. At least in regions 45, 46, 47, 50 and 51. LG> 100% Policy 4 and FTS-0001 compliant. The whole idea of an IP-only node is AGAINST the current Policy. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1244 [1995] Scn From : Sean Rima 2:252/356 01 Nov 97 09:10:00 To : Dima Maloff 03 Nov 97 05:43:10 Subj : FYI - FWIW ------------------------------------------------------------------------------- Hi Dima, In a message to Lech Szychowski you wrote: DM> Tuesday October 28 1997 04:49, Lech Szychowski wrote to Yuri Teterin: >>> Argus exists for Win32 only and is shareware, not free. LS>> Oh, yeah? So we are back to the "the only (free multiplatform) LS>> mailer to support BinkP is BinkD" situation? DM> So what? There is no free vmodem-like driver for, say, OS/2 at all. And as the protocol, BinkP, has been built into Argus for both TCP/IP and Telco connections, is coming in the TCP/IP version of Beemail and a third mailer is getting it and the source code is freely available, there is no reason why BinkP cannot be built into or added to other mailers. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: A professor is one who talks in someone else's sleep. (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1245 [1995] Rcv Scn From : Pablo Saratxaga 2:293/2219 31 Oct 97 21:10:12 To : Lothar Behet 03 Nov 97 05:43:10 Subj : Re: ifcico: Nodelist Flags ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 29 Oct 97 09:07:24 +0100, Lothar Behet said: LB> ifcico uses 60179 by itself and 60177 for telnet sessions. LB> Does this port 60177 behave in any way other than the default telnet port LB> 23? For a FTN mailer point of view no. LB> Is port 60177 supported by any ifcico in the same way? The server has to setup it, it is not done by default and most don't add it. I really think that the telnet protocol for FTN mailers has no future at all. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1246 [1995] Scn From : Sean Rima 2:252/356 01 Nov 97 09:06:00 To : Pablo Saratxaga 03 Nov 97 05:43:10 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hi Pablo, On Stardate <9710.29>, you wrote me: PS> From: Pablo Saratxaga PS> Kaixo! on Wed, 29 Oct 97 00:20:39 +0100, PS> Sean Rima said: SR>> Strange, I connect to an IFCICO mailer evey day with no SR>> problems. There is an addon for Ifcico to allow it to use BinkP SR>> which is use by BinkD PS> Where can it be found ? I'm very interested on that. I spoke to my friend. He actually uses both. As his BinkD files only take up 110k he is not worried. He even gets BinKD to start the IFmail tosser. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: A man without a God is like a fish without a bicycle. (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1247 [1995] Scn From : Sean Rima 2:252/356 01 Nov 97 09:08:00 To : Pablo Saratxaga 03 Nov 97 05:43:10 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hi Pablo, On Stardate <9710.29>, you wrote me: PS> From: Pablo Saratxaga PS> Kaixo! on Wed, 29 Oct 97 00:20:44 +0100, PS> Sean Rima said: SR>> Just a curious question. How many IFCICO mailers are there live SR>> on the Net. I am curious. PS> That is impossible to tell until a standard on how to put that data PS> on the nodelist isn't built. The reason I asked is that I am thinking about running a IFCICO mailer as well beside my BinkD so that I can offer much more. But yes, I agree, a standard format would be great. >>> binkd isn't compatible with any of the stuff listed, and more - >>> it isn't compatible with anything else. and it won't. PS> The programs doesn't matter, only the protocols, so I suppose you PS> meant binkp. Well, binkp is only copatible whith itself.... that's PS> also the case for all others, IFC is only compatible whith IFC, VMP PS> is only compatible PS> whith VMP and telnet is only compatible whith telnet :) True. Bye bye! Sean DSP BBS - Reading England DSP BinkD Ipmailer: alice.pcug.co.uk --- Argus NT/ WaterGate * Origin: A pedestrian hit me and went under my car. (2:252/356.0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1248 [1995] Scn From : Max Masyutin 2:469/38.12 01 Nov 97 13:52:26 To : Dima Maloff 03 Nov 97 05:43:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dima! 01 Nov 97 20:41, Dima Maloff wrote to Lech Szychowski: DM> Moreover, only 1 of 4 binkp-capable nodes with static IP addresses from my DM> net are in those lists. :) My net - 3 of 11, including points :-) Max. [Argus Team] --- * Origin: max@ritlabs.com (2:469/38.12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1249 [1995] Scn From : Lawrence Garvin 1:106/6018 01 Nov 97 18:27:36 To : Nick Soveiko 03 Nov 97 05:43:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Nick Soveiko said in a message to Lawrence Garvin: NS> Tue, 28 Oct 1997, 21:17, Lawrence Garvin (1:106/6018) ==> Rune NS> Johansen: LG> Any chance I could persuade you to invert your usage of the terms LG> protocol and session? LG> I'd prefer to see BinkP, EMSI, FTS-6, and FTS-1 referred to as LG> -SESSION-, and TCP (telnet/ftp/smtp), UDP (http), X.75, V.34, and LG> others of that ilk refered to as -PROTOCOLS-. LG> The SESSION runs on top of the PROTOCOL. No? :) NS> nope, *session* runs on top of *transport*. but there are protocols NS> for both. Yeah, I knew that... just lost track of my perceptions for a moment. As you may be able to see from my reply to Rune.. I've compromised, provided the protocols are separated and explicitly referred to as transport and session protocols. My whole purpose was to establish the fact that there was a significant difference between the 'protocols' that are mandated by Fidonet Policy (essentially the session protocols) and the ones that Fidonet don't care about, but does document in the nodelist (essentially transport protocols). NS> session e.g. ftp, http, smtp, pop3, binkp, emsi NS> transport e.g. tcp, udp NS> fts-1 tries to cover everything and fails miserably in many NS> aspects. Actually it doesn't Nick. Randy explicitly discounts issues of physical transport layers from FTS-0001. I believe that was designed to specifically provide for connectivity over something other than the PSTN. To that we should be grateful to Randy for his vision. It is -POLICY- that is hamstringing this effort by: (1) Improperly incorporating an operational PROCEDURE, vis-a-vis, how to get a node number, and (2) Improperly references the document entitled FTS-0001 as the minimum protocol standard. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1250 [1995] Scn From : Lawrence Garvin 1:106/6018 01 Nov 97 18:32:52 To : Nick Soveiko 03 Nov 97 05:43:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Nick Soveiko said in a message to Lawrence Garvin: NS> osi/iso layers are: NS> presentation too vague to give examples NS> application e.g. mime, *.pkt, html, bink-style outbound NS> session e.g. ftp, http, smtp, pop3, binkp, emsi NS> transport e.g. tcp, udp NS> network e.g. ip, ipx/spx, ftn nodelist NS> datalink e.g. hdlc, xmodem, zmodem NS> physical e.g. v.34, g.703/g.704 I question whether v.34, et.al are actually a physical link layer. The physical link layer in a PSTN system is actually hidden from the user, and is managed by the telco switching equipment. Arguably so is the datalink layer. I truly believe that modem communications protocols belong in the network layer along with ip and ipx. Incidentally, SPX is a transport layer protocol, just like TCP and UDP. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1251 [1995] Scn From : Dima Maloff 2:5047/13 01 Nov 97 19:26:00 To : Lech Szychowski 03 Nov 97 05:43:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Friday October 31 1997 03:49, Lech Szychowski wrote to Dima Maloff: >>>> If they locked themselves with non open software is their own problem, >>>> not mine. >> LS> They didn't. We will if we change standards inconsideratly. >> Wrong. They will have to change something in their systems either way. LS> Why? Buy and install vmodem-like driver; (sometimes) buy a mailer license for additional lines; run more copies of their mailer. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1252 [1995] Scn From : Dima Maloff 2:5047/13 01 Nov 97 20:35:00 To : Lawrence Garvin 03 Nov 97 05:43:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thursday October 30 1997 20:37, Lawrence Garvin wrote to Rune Johansen: LG> highly likely that he's registered in excess of 5,000 of 'em. So my gut LG> feeling is that he started at 10020000 -- and, as I suggested a few LG> messages ago, I suspect the registered copies is about 1/3 the total LG> number of users. LG> In any event, though.. it sure puts the lid down on a "hundreds" of BinkD LG> users. Haha. Those vmodem-nodes seem to hide very well :) LG> My gut feeling is that the "lowest common denominator" is FTS-0001 over LG> telnet, listening on port 23. Grrr. This will cut off all UNIX systems. More -- transferring bulk data from/to port 23 is not a fair play: routers will think that such a TCP connection serves an interactive session and will route it's TCP segments with the highest priority. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1253 [1995] Scn From : Dima Maloff 2:5047/13 01 Nov 97 20:41:00 To : Lech Szychowski 03 Nov 97 05:43:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Friday October 31 1997 03:51, Lech Szychowski wrote to Dima Maloff: >> AFAIK, the common idea in SU.IP.SYSOP (an echo for ex-USSR IP-sysops, >> the echo is 2 yrs old, BTW) is that we don't need a standard protocol. >> At least right now. LS> Therefore there is no total connectivity... Or is there? If so, why LS> not adopt something literarily everyone supports as a standard? Look, in Alex Konshin's automatic extended nodelist at http://www.falcon.spb.su/iplist.html there are 108 entries today. 90 of them (from regions 24, 25, 45, 46, 50, 51) have BND flag. 83.3%. (24 nodes have TELNET capability, 20 -- ifcico, and 5 have no inet at all :)) Moreover, there are 139 entries in the "binkd list" by Ruslan Hakurate. Moreover, only 1 of 4 binkp-capable nodes with static IP addresses from my net are in those lists. :) So, I think, there are AT LEAST from 140 to 560 (do you remember "1 of 4"?) or so nodes w/binkp in Fido already (and we even did not try to count dialup users!!) --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1254 [1995] Scn From : Dima Maloff 2:5047/13 01 Nov 97 19:23:00 To : Lech Szychowski 03 Nov 97 05:43:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Friday October 31 1997 03:48, Lech Szychowski wrote to Dima Maloff: >> If having binkp support is enough a) to be compatible; b) to be fast; >> c) to be effective, why not allow binkp only nodes? LS> If all these conditions are met, there is no reason not to allow them LS> - "compatible" being the main keyword here. Dare you to say that binkp nodes are a minority? --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1255 [1995] Scn From : Dmitry Arsh 2:5100/21.1 01 Nov 97 19:44:40 To : Lech Szychowski 03 Nov 97 05:43:10 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Lech! Saturday November 01 1997 20:41, Dima Maloff wrote to Lech Szychowski: DM> Moreover, only 1 of 4 binkp-capable nodes with static IP addresses from my DM> net are in those lists. :) 4 of about 20 in R51 are listed in these lists -- quiet the same. Darsh --- GoldED/386 2.50+ * Origin: The Evil Spirit (FidoNet 2:5100/21.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1256 [1995] Scn From : Dima Maloff 2:5047/13 01 Nov 97 20:44:00 To : All 03 Nov 97 05:43:10 Subj : A word about setting standards too fast ------------------------------------------------------------------------------- :) * Forwarded from HUMOR.FILTERED by Dima Maloff (2:5047/13). * Originally by: Leo V. Mironoff (2:5020/293), Friday October 31 1997 21:18. * Originally to: All. From : Vlad Komkov (2:5020/369.75@fidonet), Thu Oct 30 1997 22:20 /skipped/ "Programming is like sex: One mistake and you have to support it for life." - Michael Sinz, Commodore Engeneering. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1257 [1995] Scn From : Pedro Lima 2:362/21 01 Nov 97 07:20:10 To : Ward Dossche 03 Nov 97 05:43:12 Subj : IP-connectivity ------------------------------------------------------------------------------- WD> So far, concerning trying to get IP in, I think nothing is (nor can WD> be) according to the book. I agree we have to overcome some of the limitations placed by the current regulation, even if it implies ignoring them and assuming collectively the responsibility. FidoNet is a live organism and it can't be fossilized at a given state. WD> BTW, some guys are threatening me with formal complaints if I continue WD> this effort. I can't believe it... I'm lying, I can. WD> I think they picked the wrong target to waste ammunition. FWIW, you have my full support. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1258 [1995] Scn From : Rune Johansen 2:210/20 02 Nov 97 13:25:06 To : Nick Soveiko 03 Nov 97 06:00:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Then we should list EMSI and FTS-6 and FTS-1 too. BinkP is a >> handshake alongside those mentioned. If it is to get a special flag >> in the nodelist, so should the others too. > so? what's the problem? list session level protocols alongside with transport > and port and make default the same as majority supports. How should majority be counted? Today in Fidonet, I believe (I don't have any numbers though) that the majority of nodes support EMSI. The majority of nodes I have connected to over the internet via telnet transport protocol supports EMSI. Before BinkD was known outside ex-SU, the majority of raw TCP nodes supported EMSI too. All of these mailers also supports FTS-1 as a fallback. I agree with Lawrence when it comes to what we have to present to the rest of the Fidonet community. We want to have alternate transport mechanisms in the nodelist (namely telnet, raw socket, Vmodem and Ifcico). But then also say that "we won't do FTS-1" would be outrageus. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1259 [1995] Scn From : Kim Heino 2:222/0 02 Nov 97 12:07:42 To : Lawrence Garvin 03 Nov 97 06:00:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > how does one deal with the desire to have the -same- node number on both > the PSTN node and the IP node? Is that really needed? If you take a look at the current nodelist you'll find that many nodes already have multiple nodenumbers. For example I have 4 (plus two administrative) nodenumbers because I have 4 phonenumbers. With IP the situation is the same, you have two addresses, PSTN and IP, and therefore you should have two nodenumbers. IP+PSTN is a smaller problem than multiple PSTN. Both should be solved someday, but this would require a bigger change to the nodelist. For example: keyword,number,name,location,sysop,address1,flags1;address2,flags2;... --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1260 [1995] Scn From : Rune Johansen 2:210/20 02 Nov 97 12:42:08 To : Lawrence Garvin 03 Nov 97 06:00:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> You are correct here. I would like to extend it a little, with the >> special case of IP based systems. Since you can have several >> daemons listening on different ports, you would only need to >> negotiate a FTS-0001 session on _one_ of them. > This is a point that I'd lost track of as well, because there are multiple > ports available, unlike PSTN. Yep. How should it be denoted that "This is the port you'd have to connect to to get a FTS-0001 session negotiated"? >> The question is then: wich one, and how do I find it? The simplest >> solution is to make the daemon fallback to FTS-0001 if it does not >> manage to make a handshake of it's own kind. >My gut feeling is that the "lowest common denominator" is FTS-0001 over telnet > listening on port 23. I think we should look at telnet transports versus raw socket transports the same way as you'd look at PSTN transport versus ISDN-Only transport. They are different transport mechanisms. The lowest session protocol described by Fidonet policy is FTS-0001. That should be the minimum capability of a mailer, regardless of what transport mechanism it uses. > My only problem with this Rune, is how does one deal with the desire to have >the -same- node number on both the PSTN node and the IP node? I'm not sure I'm >enthralled with the idea of having to maintain a second identity, just so I ca > add Fido-IP connectivity to my single existing node. One deals with it just the same way that one deals with the desire to have the same node number on their PSTN node and their ISDN-only node. You'd get two node numbers. I have one ISDN adapter with PSTN capabilities, and one PSTN-only modem. They cannot be on the same node number, as they have different capabilities (my analogue modem has got no ISDN capability). > Well, we might want to see about soliciting/encouraging one or more of 'em to >get involved with this process, before we discover we've created a monster tha > we can't even implement until months down the road 'cuz nobody's committed to > writing software. True. I'd maybe start looking at NLMake to see if it needs changes. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1261 [1995] Scn From : Rune Johansen 2:210/20 02 Nov 97 12:55:52 To : Nick Soveiko 03 Nov 97 06:00:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > btw, where can i check out this bbbs thing? www.bbbs.net Beware: BinkP capability and raw TCP capability is not in the version lying there. It's in alphatest only. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1262 [1995] Scn From : Rune Johansen 2:210/20 02 Nov 97 13:16:32 To : Nick Soveiko 03 Nov 97 06:00:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>> Or, do considerer FTS-001 over raw socket as the minimal >>> requirement? >> afaik, only ifcico is capable of doing this. >> If, for example, Vmodem could create a raw socket, > the problem is that it can't. as they say in russian: if a grandmother could > have a dick, she would be a grandfather ;) So, you exclude the possibility of what a particular piece of software can do in the future? Do you only look at what's available today, and say "That's how it is, and will ever be!"? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1263 [1995] Scn From : Rune Johansen 2:210/20 02 Nov 97 13:18:28 To : Nick Soveiko 03 Nov 97 06:00:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> I believe that such an important part should be specified in the >> BinkP specs itself, to avoid different interpretations in the >> future implementations of this protocol in other mailers. >you mean we should actually say that in any binkp implementation passwords are > case-sensitive? If BinkP sessions passwords _must_ be case-sensitive, you should say so, to avoid misinterpretations. >> When that is said, I would suggest you take thing that applies >> directly to BinkD's implementation of BinkP out of the specs. > sure. there will be a discussion of implementation over tcp connection and, > probably reference do binkd sources as an example of such implementation. but > that's it. Great. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1264 [1995] Scn From : Ward Dossche 2:292/854 02 Nov 97 09:58:46 To : Ward Dossche 03 Nov 97 06:00:26 Subj : !!!!!!!!!!!!!!!!!!!! ------------------------------------------------------------------------------- No I don't enjoy writing mail to myself but obviously we have a dupelink via the US again. > PATH: 292/854 480/33 70 106/6018 8277 270/101 2433/225 1200 2432/200 > PATH: 292/854 I will get in touch with the concerned people by netmail because I am feeding already 2:292/876 who, as far as I'm concerned, is the official feed for 1:270/101 from Europe. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1265 [1995] Scn From : Kim Heino 2:222/0 02 Nov 97 14:55:24 To : Nick Soveiko 03 Nov 97 06:00:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > then why get free binkd instead of (possibly commercial) com port emulation? Let's consider a node that runs FrontDoor and BBS behind it. He propably wants to allow telnet users into his BBS, so he gets com port emulator. Or, can BinkD allow telnet users too? Now you are saying that he should install yet another mailer (BinkD), which won't even support his current system (FD)? >> Specs should also allow for "junk" before finding the BinkP protocol chars, > specs do allow junk. So, BinkD violates BinkP specs? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1266 [1995] Scn From : Kim Heino 2:222/0 02 Nov 97 15:14:30 To : Dima Maloff 03 Nov 97 06:00:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > If both are ok, then why not to allow binkp? FTS-1 over > TELNET and FTS-1 over TCP are not compatible anyway. Neither can Bell 212A and ITU-T V.22 talk to each other, but nodes behind them still can do FTS-1, which is required by policy. BinkP should be allowed, but not as the only available protocol. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1267 [1995] Scn From : Rune Johansen 2:210/20 02 Nov 97 13:14:22 To : Nick Soveiko 03 Nov 97 06:00:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Using BinkP as a must-have common protocol is what you want. That >> is noted. This is a political question, tied together with FidoNet >> in particular (yes, we are discussing FidoNet here). > thank you for admitting that it's a political question ;) Yes. In a othernet EMSI might be the session protocol required of all nodes. > the ridiculousness follows immediately from absurdity of running over tcp an > unsecure and non-robust protocol designed for 2400bps modems without error > correction. It has got nothing to do with that. It's not a question of the security of the session protocol, it's a question of wether another mailer that has got no BinkP implementation can connect to you via the required minimum protocol. >> fts-0001 over telnet or over raw ip is just *a little bit* less >> ridiculous tha fts-0001 over binkp. >> No, that's where we disagree. > you mean it's as ridiculous as fts-1 over binkp? ok, you've convinced me! ;) Running FTS-1 inside a BinkP session protocol is stupid, since you then would already have the BinkP protocol. Running FTS-1 over a raw TCP session is not stupid, if the other protocols running on it is not available in both ends. >> On the monetary side, I would like to bet that someone (maybe >> myself) would implement such a "hook" in BinkD (which is the most >> broadly used implementation of a mailer that uses BinkP today), to >> allow it for autodetection of an incoming FTS-1 session on it's >> listening port. > and firing up an external xmodem, probably via named pipe? that sounds to me > like a viable compromise. or include it as a function within the BinkD sources itself. >> Good. I really hope that the specifications of the BinkP protocol >> would allow for implementing fallback to other protocols, so it can >> be easily implemented by the implementors. :-)) > no objection and it's in my todo list. Great. >> Specs should also allow for "junk" before finding the BinkP >> protocol chars, to allow for autosensing when calling another >> system. Just a way of being leniant on what is on the other end. >> "Be leniant in what you accept, and strict in what you send" is a >> good, old jungleword used by successfull software developers all >> over the world. >specs do allow junk. but for autodetect instead of just discard it, you analyz > it. think about such analisys as a pipe to the trashcan ;). no contradiction. OK, they might allow for it, but BinkD does not use it. Example: My mailer listens to a raw TCP port. It detects a incoming session. My mailer shows a banner, sends EMSI inits, and a BinkP init. All in the same packet. Current BinkD does not see the BinkP init, and times out. If BinkD (the most commonly used BinkP mailer around today) would scan the incoming packets for BinkP, I could run this solution, with only one port accomodating BinkD, Ifcico, BBBS, etc. etc. over raw TCP. Then I would (to give even more connectivity) run a telnet daemon, supporting the same protocols there, to accomodate for those that has got no raw TCP dialers, but has to use Vmodem's telnet. One port for each transport protocol I can support. All protocols supported within each transport protocol. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1268 [1995] Scn From : Ward Dossche 2:292/854 02 Nov 97 18:43:16 To : All 03 Nov 97 06:00:26 Subj : IP - Call for opinion votes ------------------------------------------------------------------------------- Yow All, This is a query-sheet to collect opinions on how to integrate ip-nodes into the nodelist. If you don't want such integration you need not answer and simply reading this conference for you constitutes a loss of time. Some people announced proposals, which are discussed seperatly. I hope, that this query sheet concentrates the different aspects and will lead to one proposal. Netmail your reply back to 2:292/854. Take care, \x/ard ************************* Query-sheet IP-NODES ************************* This query sheet is independant of an extended nodelist format, which might solve a more complete capability solution in the future. It also has no influence on entries in regional lists (like pointlists etc.), which may follow the same specifications as the international nodelist. 1. Where to position the IP#/FQDN 1.1 [ ] node_name field 1.2 [ ] location field 1.3 [ ] phone number field 1.4 [ ] flag field 2. Format of flags 2.1 [ ] individual flags with optional port (colon separated) 2.2 [ ] packed flags (decimal coded 32 bit) Sample: 2.2 uses a table like this: 1 Raw IP 2 Telnet (port 23) 4 Vmodem (port 3141) 8 ifcico (port 60179) 16 ifc-Telnet (port 60177) 32 BinkP (port 24554) 64 ... to be continued ... 256 FTP 512 TransX 1024 ... to be continued ... This might result in a flag like IPC38 for a node, who supports Telnet, Vmodem and BinkP. Non-standard ports are not supported. The same node would present TELN,VMO,BNP:24554 with optional portnumber as individual flags according to 2.1. 3. Direct Mailer handshake via IP required for nodelist entry 3.1 [ ] Yes 3.2 [ ] No A direct mailer handshake uses nodelist data for authentication between the two systems and handles interactive transactions according to the protocols, which are used between conventional systems. In opposite are i.e. ftp and email-based protocols (indirect), which are buffered elsewhere and do not rely on any nodelist based information for data exchange. 4 Announcements of additional protocols allowed? 4.1 [ ] Yes 4.2 [ ] No This is part 2 of question 3: If a direct handshaking protocol is a claim for the nodelist entry, should the indirect protocols be announced anyway? 5. IP may be used only as additional capability 5.1 [ ] Yes 5.2 [ ] No Explanation: In case of YES: IP nodes must have at least one conventional entry in the nodelist to get another nodenumber for announcing ip-cpabilities or list additional ip flags. 6. Should IP-nodes fullfill standard claims like ZMH or at least clearly stated online times according to the fidonet policy? 6.1 [ ] Yes 6.2 [ ] No 7. Additional comments (concerning to above questions) ************************************************************************** --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1269 [1995] Scn From : Lech Szychowski 2:480/33.7 02 Nov 97 13:26:00 To : Lawrence Garvin 03 Nov 97 06:00:26 Subj : IP-access ------------------------------------------------------------------------------- > LS> Not to Fidonet, but just to _you_, the sysop of the node. > Even to that extent, the SMTP may still be totally separate from the > Fidonet. Yes, I know it might be a totally separate thing - or, to be more precise, I know it may be made to be. But ain't that a twisted setup? Is there any real (ie existing in real life) reasons for separating this two kinds of messages ("separating" standing for "making them not to go to the same person eventually")? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1270 [1995] Scn From : Rune Johansen 2:210/20 02 Nov 97 12:28:48 To : Pedro Lima 03 Nov 97 06:00:26 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- >> Then a IP-based mailer could trigger in the first two >> chars, and select the transport on the third (and beyond). > How can I filter out these entries with my PSTN mailer (FD 2.02/NC), not > being forced to specify all existant "variants" of IP* flags? To allow for other addresing schemes to not be called, you would only accept to call those trasnport mechanisms that your mailer support. That means that you don't filter out the IP's. You only allow your mailer to call those that has got PSTN flags. Currently you would choose it from these flags (taken from nodelist.304): ;S V22 ITU-T V22 1200 bps full duplex ;S V29 ITU-T V29 9600 bps half duplex ;S V32 ITU-T V32 9600 bps full duplex ;S V32b ITU-T V32bis 14400 bps full duplex ;S V33 ITU-T V33 ;S V34 ITU-T V34 33600 bps full duplex ;S V42 LAP-M error correction w/fallback to MNP 1-4 ;S V42b LAP-M error correction w/fallback to MNP 1-5 ;S MNP Microcom Networking Protocol error correction ;S H96 Hayes V9600 ;S HST USR Courier HST ;S H14 USR Courier HST up to 14.4Kbps ;S H16 USR Courier HST up to 16.8Kbps ;S MAX Microcom AX/96xx series ;S PEP Packet Ensemble Protocol ;S CSP Compucom Speedmodem ;S V32T V.32 Terbo mode (implies V.32Bis) ;S VFC Rockwell's V.Fast Class ;S ZYX Zyxel 16.8 Kbps (implies V.32Bis & V.42Bis) Include only those flags that your modem is capable of. How you do that in FD 2.02/NC, I do not know, as I don't use that specific mailer. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1271 [1995] Scn From : Kim Heino 2:222/0 02 Nov 97 15:22:26 To : Pedro Lima 03 Nov 97 06:00:26 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- > How can I filter out these entries with my PSTN mailer (FD 2.02/NC), not > being forced to specify all existant "variants" of IP* flags? Can't FD filter out flags starting with IP? How do you filter out ISDN flags then? How about filtering out all nodes having baud rate 300. Can FD do that? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1272 [1995] Scn From : Marco d'Itri 2:335/680.666 01 Nov 97 01:08:26 To : Pablo Saratxaga 03 Nov 97 09:12:20 Subj : Re: IP-access ------------------------------------------------------------------------------- srtxg@linux.chanae.stben.be wrote: >BTW, what are the codes used by other TCP/IP protocols on EMSI ? >ifcico compatibles use "TCP", what uses binkp ? binkp does not runs over EMSI or FTS-1. >But maybe it isn't impossible to use protocol codes for raw TCP connections >and have the mailers use the better common TCP protocol ? Do you mean binkd? :-) -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1273 [1995] Scn From : Marco d'Itri 2:335/680.666 01 Nov 97 01:06:54 To : Pablo Saratxaga 03 Nov 97 09:12:20 Subj : Re: IP-access ------------------------------------------------------------------------------- srtxg@linux.chanae.stben.be wrote: >Not all mailers, only those wanting to communicate over TCP/IP. Many mailers just needs a special fossil driver. >extra work would be needed anyway, so why not to use the more obvious and >natural solution ? You will just have to tell that to those sysops... -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1274 [1995] Rcv Scn From : Marco d'Itri 2:335/680.666 01 Nov 97 01:19:12 To : Lothar Behet 03 Nov 97 09:12:20 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Lothar.Behet@f301.n2446.z2.fidonet.org wrote: >As long as nobody nobody checked it at least for widely spread programs (i.e. >Frontdoor, Intermail or some Amiga/ST programs) I would prefer some more >caution with such plans. Do you think we will ever agree on a common format? Here in R33 we will[1] have an extended nodelist from which all other formats will be generated: with stars, with dots, in the system field and so on. Do people thinks having a separate IP nodelist is evil? [1] When IP sysops will bother to send me their data -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1275 [1995] Scn From : Marco d'Itri 2:335/680.666 30 Oct 97 22:52:14 To : Rune Johansen 03 Nov 97 09:12:20 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >Also true. Then a IP-based mailer could trigger in the first two chars, and >select the transport on the third (and beyond). I will restructure to I don't like that. By changing all flag names you will confuse users. I don't we need to save those three bytes. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1276 [1995] Scn From : Marco d'Itri 2:335/680.666 01 Nov 97 01:15:28 To : Jesper Tragardh 03 Nov 97 09:12:20 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- Jesper.Tragardh@p21.f108.n200.z2.fidonet.org wrote: >If we're going to redefine the nodelist a mechanism for having several >"adresses" (in your meaning - replacing the phone-field) per node would be >good. We already have a proposal that does that and much more: ftp://ftp.linux.it/pub/ILS/People/md/xtd-nl.zip -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1277 [1995] Scn From : Ask Bjoern Hansen 2:235/10 02 Nov 97 20:11:40 To : Lawrence Garvin 03 Nov 97 18:08:20 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Lawrence! Friday October 31 1997 20:22, Lawrence Garvin wrote to Ask Bjoern Hansen: PS>>> There is no need to force a common protocol on other transport PS>>> layers. LG>> There is as long as Policy 4 rules Fidonet. ABH>> I think that we should use what P4 says about 'common sense' ABH>> when it's hopeless outdated and stopping us from getting any ABH>> further elsewhere. LG> Uh... unless you've got a different Policy 4 than I have, there's only LG> one reference to "common sense" in that entire document, and it's a LG> specific reference in paragraph 2.1.6.2, with consideration to LG> "private mail". "Judgement and common sense should be used in this area as in all other aspects of FidoNet behavior." LG> Now, I will concede that there is also an unwritten presumption that LG> any consideration of any "policy" incorporates a certain amount of LG> common sense when implementing the intent of the policy. Indeed.. LG> However, Policy is quite clear on certain things, and gives no leeway LG> at all for 'interpretation' or 'common sense' modifications. LG> One of those unequivocable requirements is that EVERY NODE listed in LG> the nodelist (except those flagged as PVT), must be capable of LG> negotiating an FTS-0001 session during Zone Mail Hour. Thats correct, yes. But I wouldn't have any problems with any nodes without FTS-0001 capabilities at this time. I'm pretty sure that theres only a few nodes in all Z2 that can't do anything but a FTS-0001 session. ABH>> Because of P4? Like we're not having 4D points because P4 ABH>> states that we don't do it that way. No? LG> P4 doesn't say anything at all about points, except that they're not LG> recognized members of Fidonet. "In supporting points, the bossnode makes use of a private net number [..]" Are you following this part of P4? Should you? kind regards, ask --- GoldED/2 3.00.Alpha4+ * Origin: vmodem.fido.dk, ifcico.fido.dk and binkd.fido.dk (2:235/10) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1278 [1995] Scn From : Ask Bjoern Hansen 2:235/10 02 Nov 97 20:12:36 To : Ward Dossche 03 Nov 97 18:08:20 Subj : IP-connectivity ------------------------------------------------------------------------------- Hello Ward! Friday October 31 1997 20:18, Ward Dossche wrote to Pedro Lima: WD> BTW, some guys are threatening me with formal complaints if I continue WD> this effort. I think they picked the wrong target to waste ammunition. Indeed. ask --- GoldED/2 3.00.Alpha4+ * Origin: Netcetera: ifcico, binkd, vmodem, v34, isdn .. (2:235/10) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1279 [1995] Scn From : Pablo Saratxaga 2:293/2219 02 Nov 97 07:58:06 To : Rune Johansen 03 Nov 97 18:08:22 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Fri, 31 Oct 97 00:46:18 +0100, Rune Johansen said: >>> So, if I run a raw TCP mailer capable of EMSI only, I would like to run the >>> flag EMSI to denote that: >> I don't think is useful adding that. RJ> True. So, a BinkP flag would also not be useful, if EMSI is not. The fact is that: "BinkP" is enough to describe how to connect to a node. "IFC" is enough to describe how to connect to a node. "Telnet" + port number is enough to describe how to connect to a node. Those three aren't equivalent, for exemple BinkP describes a handshaking while the two other not, but in practice the two others only use EMSI (there are even mailers compatible whith IFC raw TCP method that can do only EMSI). So even if they aren't equivalent the fact is that they fully describe how to connect to a node, whithout any need for additional info. And also the fact is that using "RAW" + "handshake method" isn't enough, as there can be several implementations of "RAW" Then the need for the four flags BINKP, IFC, TELNET and VMP (or whatever they will finally be called) nothing more nothing less. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1280 [1995] Scn From : Marco d'Itri 2:335/680.666 03 Nov 97 15:40:54 To : Rune Johansen 03 Nov 97 23:11:48 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >To try to make IP flags coherent, I will suggest using a prefix of IP to all >of them, like Kim suggested. IPT - Telnet, IPR - Raw TCP, IPV - Vmodem >Protocol, This is just a stylistic issue. I think it's more desirable to support current practices. >> I don't think there are programs so broken to misparse TELN as a Txy flag, >> it this is true we would have to outlaw all T* headers. >That is what I am trying to do. Outlaw them all. :-)) They are not the problem. The problem are broken mailers, so we should outlaw broken software. >>> flag EMSI to denote that: >> I don't think is useful adding that. >True. So, a BinkP flag would also not be useful, if EMSI is not. The EMSI flag is implicit for TELN, RAW, VMP and IFC systems. >nodes poll me, I have to use one port explicitly for BinkP, since current >BinkD mailer cannot autodetect my BinkP capability when I answer. I can't understand why do you think this is a problem, you will not get short of TCP ports. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1281 [1995] Scn From : Marco d'Itri 2:335/680.666 03 Nov 97 14:41:16 To : Pedro Lima 03 Nov 97 23:11:48 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Pedro.Lima@f21.n362.z2.fidonet.org wrote: >Together with the people using it? I'd rather not. Come on, it's >perfectly possible to have both the old programs and IP connectivity in >FidoNet. What about separating IP nodes in an IP-list? This way we would not need any ugly kludge to maintain backward compatibility. IP only nodes would get a Pvt entry in the standard nodelist. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1282 [1995] Scn From : Marco d'Itri 2:335/680.666 03 Nov 97 14:59:50 To : Lawrence Garvin 03 Nov 97 23:11:48 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: > Md> I need to know which nodes supports email tunneling, e.g. to send > Md> them crash mail. >Can you program your FIDONET MAILER to make a decision on whether to tunnel >the stuff via email or dial 'em up on the PSTN? Yes, I can write a program that will parse the nodelist and will write in /var/qmail/control/virtualdomains the routing statements. Then all netmail for this node will be sent crash. I can write such a program in less than one hour, and if and when email tunnelling informations will go in the nodelist I will write it. >Can it make that decision -dynamically-, as the stuff is dropped in the >mailer outbound directory? It's a waste of resources, I need to do that only when I receive a new nodelist. >Or do you have to 'preconfigure' your system to send ALL MAIL for a specific >node via email tunneling? No, I don't. >If you have to 'preconfigure' your system, then any arrangements for email >tunneling had to have been negotiated on an individual basis, therefore you >received your knowledge about that capability from some means other than your >-MAILER- making the decision. Even if I'd have to work out specific requirements with other systems, I think a flag specifying tunnelling support would be useful. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1283 [1995] Scn From : Marco d'Itri 2:335/680.666 03 Nov 97 15:28:22 To : Kim Heino 03 Nov 97 23:11:48 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Kim.Heino@f0.n222.z2.fidonet.org wrote: >But the question is still valid, which one is the minimal requirement: >FTS-001 over raw or FTS-001 over telnet? In my opinion, it's ok if a node can >do raw OR telnet. This is not useful at all, those transports are not compatible. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1284 [1995] Scn From : Marco d'Itri 2:335/680.666 03 Nov 97 15:45:56 To : Ward Dossche 03 Nov 97 23:11:48 Subj : Re: IP - Call for opinion votes ------------------------------------------------------------------------------- Ward.Dossche@f854.n292.z2.fidonet.org wrote: >2.2 [ ] packed flags (decimal coded 32 bit) Please not that packed flags does not supports specifying non standard port numbers. That would prevent most unix systems to run ftn over telnet. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1285 [1995] Scn From : Marco d'Itri 2:335/680.666 03 Nov 97 15:02:28 To : Lawrence Garvin 03 Nov 97 23:11:48 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >Anonymous FTP gives the FTP Server Operator none of the above. No logs that It gives you an IP, and this is much more than what you get for a PSTN call (if you don't receive caller ID). -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1286 [1995] Scn From : Yuri Teterin 2:5030/239 02 Nov 97 17:30:40 To : Lawrence Garvin 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Lawrence ! Thu Oct 30 1997 Lawrence Garvin writes to Yuri Teterin: YT>> Why not? FTS-0001 does not suppose that the connection is YT>> error-free. And any non-errorfree connection can be implemented YT>> very well with help of UDP. LG> Ahh... if that is your impression of the differences between TCP and UDP, LG> then you've misunderstood much, Yuri. My impression is that a modem link without ARP is much more like an UDP-based session than a TCP-session. LG> The fundamental difference between TCP and UDP is whether or not each LG> end is continuously aware of a "connection" to the other end. That is implemented with help of timeouts only. We can make just the same with help of UDP. [ advantajes of TCP skiped ] - they are obvious but does not mean that FTS-0001 over TCP is more natural then FTS-0001 over UDP (and this was the point, if you remember) LG> UDP, on the other hand, is a connectionless protocol. The sender has LG> no knowledge of whether the receiver exists at that moment or not. LG> The packet is simply sent out to the ether with the hopes that it LG> will be received and acted upon. We have just the same situation at modem link without ARP ind with carrier, that can miss for 20-30 seconds - but FTN-software did work in such conditions, and in 1989, when FTS-0001 was written, this was a standard sutuation. LG> It is the responsibility of the -sending- side of the UDP LG> connection to provide for a timeout, a point at which it gives up, LG> and reports back to the user that all is lost, and the communication LG> cannot be completed. Even then, the packet may well have been received LG> -and- acted upon, but the -acknowledgement- is lost on the return trip. LG> The result of this is that the whole process is repeated. Yes, and the same we have at the pure modem connection I have written above. LG> As a minimum, it is virtually impossible to implement any sort of LG> efficient streaming file transfer over UDP - And isn't that pretty much LG> what Fidonet is?: The transfer of file via expedient streaming LG> technologies? There are implementations on file transfer based at UDP, that are used instead of FTP (and the servers based at that protocol reqiure less resourses than FTP-servers). And my aim was not to show that we should switch to using UDP instead of TCP. Remember, it was written when we discussed the meaning of 'physical layer' in FTS-0001, and I wroute that if we try to extend this notion to TCP/IP, than the natural anologue of 'physical layer' for FTS-0001 in not TCP, but UDP. And I continue insist on that because if we try to implement FTS-0001 over TCP then 9/10 of FTS-0001 specifications became unnecesary and redundant (and if we eliminate this redundantary, we'll get just something like BinkP, but much more simple and less elaborated). Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1287 [1995] Scn From : Denis McMahon 2:251/20 02 Nov 97 11:14:38 To : Lawrence Garvin 04 Nov 97 05:43:12 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Lawrence Garvin wrote to Denis McMahon: LG> Denis McMahon said in a message to Lawrence Garvin: DM> OK, suppose a node that doesn't have a session password wants to DM> send you a crash netmail? How does he do it? Answer, he dials your DM> telno and sends it. He presents *ANY* valid nodenumber in the DM> nodelist, and as long as you don't have a session password set with DM> the node address presented your system accepts his mail. End of DM> session. LG> Not quite. If a mailer identifying itself here with a node number LG> that I don't have a session password set up for drops off mail, it LG> gets put into an INSECURE directory, and NOTHING touches that mail LG> until I personally (manually) inspect it to make sure it's not LG> 'dangerous'. DM> This is *NO DIFFERENT* to accepting anonymous upload! LG> It sure as heck is! Not at all - accepting FTN session from a non passworded node is the same as accepting anonymous ftp. You don't *KNOW* where the files came from, only where they claim to be from, and should treat them in the same manner. LG> I am strictly opposed to the use of anonymous ftp for the transport LG> of Fidonet mail. All ftp should be done on a closed-account basis, LG> password protected, and even then, although not normally done, LG> should probably include packet level passwords. Non passworded FTN sessions are just as anonymous, as you can not assume that the presented address is the correct one. LG> But you forget one very important point -- I still have a way to LG> trace back where that packet originated from -- mailer logs, LG> filenames, and if it's ugly enough, telephone records. But, your mailer records only tell you what the caller wants them to tell you, it does not take any sysop long to configure a false identity for his system to call you with. LG> Anonymous FTP gives the FTP Server Operator none of the above. No LG> logs that identify who dropped off the packet and no way to trace LG> the source of the session if it comes to pass that the mail dropped LG> off is really really ugly. If your ftp daemon doesn't record the ip address of the delivering system, that's a shortfall in your ftp daemon. The ip address of the caller is probably more reliable than the FTN address presented during a non passworded session. Regards Denis --- timEd/386 1.10 * Origin: Vote Denis McMahon for ZEC2 (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1288 [1995] Scn From : Denis McMahon 2:251/20 02 Nov 97 11:20:12 To : Lawrence Garvin 04 Nov 97 05:43:12 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Lawrence Garvin wrote to Denis McMahon: LG> Denis, methinks you missed my point. We're talking about mailers LG> that make OUTBOUND calls. Okay? :) No, we're talking about the use of IP protocols in the Fidonet environment. LG> We're not talking about whether ftp is being used successfully. I LG> -KNOW- it's being used successfully, I move the entire filebone LG> between four nodes via FTP, the only thing I move via VModem is LG> echomail. LG> However ,unless my FIDONET MAILER can make a decision about where LG> or how to send mail based on information in the nodelist, that LG> information is worthless and shouldn't be in the nodelist. Wrong. Whether any current individual fidonet mailer can use the information or not is not the issue. The whole idea of this discussion is to place data in the nodelist in some agreed format so that future generation mailers can use that information. LG> The fact that somebody only accepts echomail via SMTP-Attach is LG> totally USELESS information to my mailer -- it does not have the LG> capability to create an email message, address it based upon LG> information contained in the nodelist entry, and file attach the LG> contents of a Binkley FLO file to that email. No, it doesn't, but hopefully one day it will be possible to do that, and then hopefully instead of sending me netmail by calling trans-atlantic you can send it to your local dial-up isp and it will arrive here and be processed by my mailer. LG> It also doesn't have the ability to initiate an ftp client session LG> and force the contents of that FLO file to be sent via FTP. That's right, it doesn't yet, and unless there is data in the nodelist in a standard format that it can use then there is no need for mailer developers to incorporate the functionality. Hopefully we will at some point see embedded in the mailer the ability to dial an isp using slip, ppp etc, and send mail, arcmail and file attaches via smtp or anon or passworded ftp to an ip destination address. However, this development will not be able to take place until the nodelist contains information that the mailer can use to send that message. I can, at the moment, use gigo, ka9q and k2g2k with squish to send netmail over the internet, but it's not elegant and requires a lot of manual configuration. If we are to work towards an objective where such things can be done automatically then we must first incorporate information in the nodelist for such automated processes to use. DM> So because it's of no benefit *TO YOU* *AT THE MOMENT* it's not DM> needed eh? LG> Uh.. Denis... this isn't about my -personal- nonbenefit.. it's a LG> basic point of reality that NO FIDONET MAILER has that capability DM> It's of no benefit whatsoever to me at the moment either, LG> Thankyou for your candor. I suggest it's of no benefit to any LG> FIDONET SYSOP at this moment, I agree with this, but LG> or any moment in the future, and for that reason, there serves no LG> purpose for listing such information in the nodelist. With this I strongly disagree. We are both arguing about how the future should be shaped, however I seem to be arguing that we should provide information that software developers can use to increase functionality and reduce sysop costs if they want to, whilst you're arguing that there's no point because the software developers won't be interested. Regards Denis --- timEd/386 1.10 * Origin: Vote Denis McMahon for ZEC2 (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1289 [1995] Scn From : Yuri Teterin 2:5030/239 02 Nov 97 17:02:34 To : Maciej Grzeszczuk 04 Nov 97 05:43:12 Subj : FYI - FWIW ------------------------------------------------------------------------------- Hello, Maciej ! Wed Oct 29 1997 maciej grzeszczuk writes to Yuri Teterin: >> YT>> There was an attempt to implement VMP in Argus too, but it >> YT>> was not quite successful. mg> whatever was implemented in argus, it allows connections with my ifcico. mg> one of my link uses argus to fetch ~600kb packets every day with no mg> problems. I have already written - this is not VMP (because neither Argus nor ifcico do suport VMP), this is FTN-over-telnet (and this should be written in the logs of your ifcico too - look for the wotd 'telnet' there). Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1290 [1995] Scn From : Nick Soveiko 2:5030/23.101 01 Nov 97 08:39:48 To : Lech Szychowski 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Fri, 31 Oct 1997, 04:03, Lech Szychowski (2:480/33.7) ==> Rune Johansen: > problem I would see with it, is if I get a non-error-correcting connect > with the other side. That way I could be in serious trouble. But, BinkP > assumes error-free connection, so I'll have to see what I can do on the > modem side. LS> IHMO if BinkP can't handle "no-error-correction-by-modem" LS> situation, it should let the other side know about it and LS> disconnect ASAP, to save money. argus handles this arrangement (binkp-over-modem) by using a proprietary error correction protocol that runs under binkp and provides reliable mailer-to-mailer connection (smth like sockets afaiu). i have no windows machines around me so i can't set it up and explore further. maybe max masiutin can educate us more on this? cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1291 [1995] Scn From : Nick Soveiko 2:5030/23.101 01 Nov 97 21:00:48 To : Lawrence Garvin 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Fri, 31 Oct 1997, 20:22, Lawrence Garvin (1:106/6018) ==> Ask Bjoern Hansen: LG> However, Policy is quite clear on certain things, and gives no LG> leeway at all for 'interpretation' or 'common sense' modifications. ok, let's forget 'common sense' for a minute. LG> One of those unequivocable requirements is that EVERY NODE listed LG> in the nodelist (except those flagged as PVT), must be capable of LG> negotiating an FTS-0001 session during Zone Mail Hour. fts-0001 has a *really huge* hole in it: it leaves the question of physical layer open. it means that my system could be 100% fts-0001 compliant during the zmh and at the same time you have 0% chances to connect to it. here you go. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1292 [1995] Scn From : Nick Soveiko 2:5030/23.101 01 Nov 97 21:01:06 To : Rune Johansen 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sat, 01 Nov 1997, 04:02, Rune Johansen (2:210/20) ==> Slava Filimonov: > Let's not be ridiculous twice - we can use _another_ port for FTS-* and > BinkP on it's own in single program/daemon. Why all of you stuck on word RJ> And how do you suggest that it should be indicated in a nodelist? via a triplet flag :port:. i've proposed it here a few days ago. i can email it to you if you didn't get this message. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1293 [1995] Scn From : Nick Soveiko 2:5030/23.101 01 Nov 97 21:02:34 To : Rune Johansen 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sat, 01 Nov 1997, 04:14, Rune Johansen (2:210/20) ==> Yuri Teterin: > Your proposal is logicaly true. The only disadvantage is that it does not > reflect the requirements of the real life, so it will not be used by > at least 1/2 of IP-nodes. RJ> It reflects the requirement of being a node in Fidonet, the RJ> possibility to accept a FTS-0001 session handshake on the transport RJ> protocol that you have a mailer on. neither policy, nor fts-0001 does not say that fidonode has to support fts-0001 on each and every port. they simply don't say anything about ports. > But it can be stated rather definitely that none of existing mailers run > BinkP and FTS-0001 at the same port, and there is no reasons to > suspect that some mailer will ever do this. RJ> BBBS (that I run) can do BinkP, EMSI and FTS-0001 on the same port. so, you're trying to sell us a proposal that reflects your particular mailer using one particular approach of miltiplexing different services and different protocols on one port. your proposal rules out the other approach which does not contradict with policy and is in perfect agreement with current internet technology and practices. > So your proposal will actualy cut all BinkP-based part of FIDO and leave it > out of nodelist. RJ> It will cut all current BinkD 0.9.1-only IP-only nodes, it will also prevent *anybody* from indicating port-multiplexed capabilities. it will prevent sysops with dual (pstn and binkp/ip) from indicating their ip capability in the nodelist. *that's really bad*. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1294 [1995] Scn From : Nick Soveiko 2:5030/23.101 01 Nov 97 21:05:08 To : all 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sat, 01 Nov 1997, 14:49, Lech Szychowski (2:480/33.7) ==> Nick Soveiko: > LS> Could you point me to sources for this mailer/daemon? I'm genuinely > which one? LS> [...] > latest binkd can be found at http://www.magadan.su/~maloff/binkd/. a > 0.9.2 release is coming anytime now. LS> The above. Thanks a lot, will try it soon. btw, if any of the subscribers of this echo haven't yet checked the fido-over-ip faq, it can be found at http://www.doe.carleton.ca/~nsoveiko/fido/fido-over-ip.FAQ.english.html i know that it's far from being comprehensive and misses many points and pieces of software. but it's better than nothing and that's why i'm posting the url here: send me comments, additions and relevant links. i'll try to keep it updated on a regular basis. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1295 [1995] Scn From : Lawrence Garvin 1:106/6018 02 Nov 97 16:33:24 To : Ask Bjoern Hansen 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Ask Bjoern Hansen said in a message to Lawrence Garvin: ABH>> I think that we should use what P4 says about 'common sense' ABH>> when it's hopeless outdated and stopping us from getting any ABH>> further elsewhere. LG> Uh... unless you've got a different Policy 4 than I have, there's LG> only one reference to "common sense" in that entire document, and LG> it's a specific reference in paragraph 2.1.6.2, with consideration LG> to "private mail". ABH> "Judgement and common sense should be used in this area as in all ABH> other aspects of FidoNet behavior." Okay.. one for you. :) ABH> But I wouldn't have any problems with any nodes without FTS-0001 ABH> capabilities at this time. Personally, I wouldn't either. If'n they couldn't negotiate a session with me, I'd just host-route the mail and let their NC deal with the situation. ABH> I'm pretty sure that theres only a few nodes in all Z2 that can't ABH> do anything but a FTS-0001 session. I'm told there are at least a half dozen in Region 10 alone, and perhaps a few more over in Region 18. And the there's the whole of Zone 5, which from what I hear, is lucky to even get a carrier on what passes for their public telephone network, much less to hope for negotiating a high-tech session like EMSI over international lines. ABH>> Because of P4? Like we're not having 4D points because P4 ABH>> states that we don't do it that way. No? LG> P4 doesn't say anything at all about points, except that they're not LG> recognized members of Fidonet. ABH> "In supporting points, the bossnode makes use of a private net ABH> number [..]" ABH> Are you following this part of P4? Should you? And in that situation, the addresses are 3D address not 4D addresses. Furthermore, that paragraph is a -guideline-, in fact another 'procedure' that is entirely inappropriate for a policy document anyway. I do not recall that anything in it mandates that points -must- be implemented using a private net number. At the time that P4 was written, 4D addresses didn't exist. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1296 [1995] Scn From : Yuri Teterin 2:5030/239 02 Nov 97 17:08:10 To : Kim Heino 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Kim ! Thu Oct 30 1997 Kim Heino writes to Yuri Teterin: >> Secondary, to use TRANSMIT-BINARY option we must: >> 1) enter this mode (and why are you sure it will be accepted by remote?) >> 2) set some other parameters of the chanel like echo and so on >> 3) be ready to process other telnet commands (what commands?) during the >> session. KH> Sure, so what? This is a job of telnet-module/program/gateway/whatever, KH> not a job of a mailer's FTS-001/EMSI/whatever module. If the telnet-module KH> can't get the session it wants (binary, no echo, sga) then it reports "NO KH> CARRIER" to the mailer module, just like with modems. No harm done. This mean that 'plain telnet' without extra specifications is not a transport protocol. If we can not be sure that any two 'telnet-module/.../whatever' can provide us a transport for FTS-session instead of saying "NO CARRIER" - we can not include corresponding flag (TELN, or IPT, or what it should be) in nodelist. >> which commands of telnet protocol should be supported >> and when and how shold they be processed. KH> We have rfc's for that. If your telnet-module wants option x and mine KH> refuses to do it, then they still can try to send the data, or report KH> failure, depending on the option. Nobody will be satisfied if they 'try to send the data' without switching to binary mode or just 'report failure', breaking the conection. BTW, there is no common understanding, that should do telnet-module if get IAC followed by a byte that it can not idenify with a command of telnet-protocol. Current implementation of telnet in ifcico, for instance, put IAC with this byte in the stream (and due to telnet specification it should be ignored). KH> Is there a telnetd which does not support binary, no echo and sga options? Why should we be interested in telnetd? FTN-software can not cooperate with it, it should use its own implementation of telnet protocol in any case. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1297 [1995] Scn From : Yuri Teterin 2:5030/239 02 Nov 97 21:09:46 To : Ward Dossche 04 Nov 97 05:43:12 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hello, Ward ! Fri Oct 31 1997 Ward Dossche writes to Slava Filimonov: WD> 1) The core of Fidonet is the nodelist. WD> 2) We are discussing the use of IP as a carrier for Fido-sessions. WD> 3) We are not discussing what the core of the internet is. WD> So any sollution that will be adopted will have to be a WD> nodelist-sollution. That is why I insist so hard that _any_ FTN-protocol that is used by a significant number of sysops for Fido-sessions (including BinkP) should be allowed in nodelist. Any other approach just force the sysops using these protocols to look for alternative ways of improving connectivity between them, with their own nodelist and so on. Potentially this lead to the spliting of the net. In particular, if telnet-only nodes will be allowed in nodelist and BinkP-only nodes will not, this most likely will lead to the situation, when these BinkP-nodes will be present in nodelist, but as fake 'proxy' telnet-nodes (as I have described in the letter to Rune Johansen). In this case the whole BinkP-community, that counts allready more than 200 nodes, will be forced to use its own nodelist (or its analogue) to communicate between themselves, and the official nodelist will not reflect the real situation. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1298 [1995] Scn From : Yuri Teterin 2:5030/239 02 Nov 97 17:57:56 To : Rune Johansen 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Sat Nov 01 1997 Rune Johansen writes to Yuri Teterin: >> Your proposal is logicaly true. The only disadvantage is that it does not >> reflect the requirements of the real life, so it will not be used by at >> least 1/2 of IP-nodes. RJ> It reflects the requirement of being a node in Fidonet, the possibility to RJ> accept a FTS-0001 session handshake on the transport protocol that you RJ> have a mailer on. We have alredy discussed this point. If you intend to follow Policy literally, then you must run this 'session handshake' at _phone_ line, not at IP (see sect.2.2). And if you reject this part of Policy - why do you insist on literally following sect.2.1.8? After all, it requires first of all "be able to receive mail during this time using the protocol defined in the current FidoNet Technical Standards Committee publication", and even now there exist not only FTS-0001, but also FTS-0006, so the reference to FTS-0001 only in Policy is out of date. And it is not written somethere that all further 'protocols defined in the FidoNet Technical Standards Committee publications' should implement autodetection and fallback to previous protocols - but your proposal assume for some reason that this must be true forever. >> But it can be stated rather definitely that none of existing mailers run >> BinkP and FTS-0001 at the same port, and there is no reasons to suspect >> that some mailer will ever do this. RJ> BBBS (that I run) can do BinkP, EMSI and FTS-0001 on the same port. And a modificated BinkD that I run at one of my stations can use BinkP as a transport-level protocol for FTS-0001. So include, please, BNP in the list of IP-flags as a transport protocol in your proposal too. >> So your proposal will actualy cut all BinkP-based part of FIDO and leave >> it out of nodelist. RJ> It will cut all current BinkD 0.9.1-only IP-only nodes, until it has RJ> implemented a fallback routine to the required minimum session handshake RJ> protocol in Fidonet. They'll never do that because this is senseless. The only result that you'll get if your proposal will be accepted will be appearence of new fake 'FTS-0001 compliant' IP-nodes. Look, in the case of IP-nodes this is much more easy than in the case of PSTN-nodes: just now I can switch off EMSI and YOOHOO in one of my ifcico, leaving FTS-0001 only, and write in DNS 200 aliases for compyter, running this ifcico. After that any BinkP-only node can write any of this aliases as its address (if it will be necesary to write in nodelist not a DNS-name, but an IP-address, it is possible to write aliases for them too). Everybody will know that a lot of addresses in nodelist are just a fake, so they will relay not on nodelist, but on the information from BINKD-lists or DNS first off all, and BinkP-only nodes will live happy and exchange mail and files. But if somebody decide ever send mail to the nodelist address of that node - OK, my ifcico will receive it (and I even should not write extra AKA in my configurations for this because no AKA is presented during FTS-0001 session), and then this mail will be send to real BinkP-node with help of BinkP. Do you like such a situation? And who will win in this case? Why would it be worse if that node had its _real_ address in nodelist and BNP flag? Everybody who can not run BinkP are able to route the mail to this node via any other IP-node that would be compatible with his software. The result would be the same, but with significant advantage that the information in nodelist would describe _real_ situation, and not a lot of faken 'FTS-0001 compliant' nodes. RJ> That is completely true. But, by ex-SU sysops only using BinkD, they fail RJ> to adhere to the basic rule of connectivity in Fidonet, namely the RJ> requirement of accepting a FTS-0001 session, if the caller has got no RJ> other session handshake protocol in common. This is not a real rule of connectivity, but only an anachronism now. A lot of nodes can not really run FTS-0001 for years, and nobody complain (as the matter of fact very often nobody, including the sysops of this nodes, even knows of this fact). RJ> In practice that means that they already have their own network, that RJ> is non-fidonet compatible. Not at all. Does somebody notice such a division to separate networks? No. Mail and echomail run smoothly (and even much better than before), nobody have troubles with conectivity. And this just mean, that FTS-0001 is not necessary for connectivity in FIDOnet now. RJ> If BinkD (that is used in the ex-SU) would implement a FTS-0001 RJ> handshake if the BinkP handshake fails, it would be compliant with RJ> the current requirement of Fidonet. What for? It would be much more easy to run another software at other port if we are fond of FTS-0001. And why should somebody have such a strange idea as to go with FTS-0001 to BinkP port? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1299 [1995] Scn From : Ward Dossche 2:292/854 02 Nov 97 19:18:00 To : Dieter Ringhofer 04 Nov 97 05:43:12 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Dieter, > even when having all technologies available and in use (isdn, analog up > to x2-server) i'm complaining about. imo it has been a mistake to list > such systems as full featured nodes (according policy) because they > aren't. You are 100% correct ... politically. I blame that to a lack of vision of those that devised Peefore. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1300 [1995] Scn From : Yuri Teterin 2:5030/239 02 Nov 97 19:59:42 To : Rune Johansen 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Sat Nov 01 1997 Rune Johansen writes to Pablo Saratxaga: >> The cases where there is a mailer and BBS on telnet or vmodem is because >> those programs ARE NOT internet able programs, they still thing they are >> using a modem and a phone line. RJ> Oh? So, if I use a FOSSIL-able telnet daemon, giving my mailer a RING when RJ> a incoming connection is being made is not internet-able? They use RJ> something they believe to be a modem, but it's internet-able anyway. It RJ> has got a mailer, AND a BBS available on the same port. Really very inconvenient decision. It would be much more convenient if the part of FOSSIL listening port 23 runs BBS immediately, without any EMSI and 'ESC-ESC', and a separate port be used for MO FTN station (withowt any fallback to BBS on timeouts and so on). RJ> Or even better: try to telnet to fix.no, and see what you get there. It's RJ> a BBS, sending EMSI handshake, and has got a fallback to FTS-0001. It's RJ> fully internet capable, AND it has got a BBS running on it. What for? Does any human caller, trying to connect your BBS with help of telnet, fond of your EMSI and 'ESC-ESC' prompt? Or does any mailer connecting with your station, like to see every time the banner of your BBS? What is implemented at your site is just an _disadvantage_, connected with 'modem history' of your software, and nothing more. RJ> We have been transferring fidonet mail sessions over the internet on RJ> it for over a year now. They don't need to add a mailer on another RJ> port. And we have been transferring fidonet mail (and not only mail) sessions over two years now. And we do not need a universal mailer on uniqie port - it is much more convenient to use separate ports for different protocols. >> They have to anyway ! You can't just use a normal modem mailer on a >> telnet client. You need a special maler supporting vmodem or telnet. RJ> Why is it that 2:20/11 has got a FrontDoor 2.30 running on telnet daemon RJ> then? It's a DOS program running behind a telnet daemon, with fallback to RJ> a BBS program. An ordinary telnet client or server can not have anything 'running behind' it. So your telnet software seems to be a special one, elaborated for BBS or FTN, isn't it? RJ> Looks to me as a normal modem mailer on a telnet daemon. We never heard about 'mailer on a telnet daemon'. What kind of telnet daemon do you use? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1301 [1995] Scn From : Yuri Teterin 2:5030/239 02 Nov 97 20:24:02 To : Rune Johansen 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Sat Nov 01 1997 Rune Johansen writes to Slava Filimonov: >> Let's not be ridiculous twice - we can use _another_ port for FTS-* and >> BinkP on it's own in single program/daemon. Why all of you stuck on word RJ> And how do you suggest that it should be indicated in a nodelist? Just as it is indicated there now: with help of BNP (or BND) flag. That's the problem? RJ> I am stuck on the word fallback to the (always) current minimum session RJ> protocol in fidonet. That's because if you have only one port available RJ> for a IP-only node, it must have at least one protocol to talk with, if RJ> the calling party does not speak your flavor of session protocol. Why? We have now 6 distinct flags for ISDN-nodes, which use 'only one port available' and that can not usualy 'talk with' any PSTN-nodes or even with ISDN-nodes having over flags. Does this worried you very much? RJ> You support IPR (IP raw TCP). If I have the possibility to connect to you RJ> via IPR, I can call you via IP, since I have a transport protocol RJ> interface to my mailer that can do it. So, when I connect, I cannot talk RJ> BinkP, because that is not implemented in my mailer. Then consider BinkP-only nodes like ISDN-only nodes (or vmodem-only nodes, if you have no vmodem) and do not try to connect with them. That is the problem? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1302 [1995] Scn From : Yuri Teterin 2:5030/239 02 Nov 97 21:43:22 To : Rune Johansen 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Thu Oct 30 1997 Rune Johansen writes to Lech Szychowski: RJ> I have not run a full poll with BinkP with lots of files to transfer both RJ> ways yet over PSTN, but I will test it someday now. :-) The only problem I RJ> would see with it, is if I get a non-error-correcting connect with the RJ> other side. To run BinkP just over a phone-line connection is not a goot idea, even if the connection is error-corrected. Your software can loose bytes in COM-port, and in the case of BinkP you'll know about this only then you'll get the whole file. Argus can run BinkP over phone-lines, but it incapsulate the data into packets and perform his own error-correction. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1303 [1995] Scn From : Yuri Teterin 2:5030/239 02 Nov 97 21:54:24 To : Rune Johansen 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Thu Oct 30 1997 Rune Johansen writes to Slava Filimonov: >> As i said before, it's like riding a horse on a highway. Highway is >> not designed for using with horses but it's possible... RJ> For those people not having your automobiles on your highway, why would RJ> you not build a small horsetrail on the side, so they can use it until RJ> they get a automobile? Because this require extra money and extra resources. If to trasfer the luggage and even the horses with help of trailers if cheeper than to build a horsetrail - why should we spend money for it? In our case nobody force anybody to connect with BinkD-node directly. If you have no BinkP, you can send netmail to it by route (just like any node without IP access) - what is the problem? RJ> If a horsetrail is the current minimum on a road today, why should RJ> the highway refuse to have it? It won't hinder any of the automobiles RJ> already running there. Did you seen a lot of highways with hosetrail along it now? I did not. The horses should not run along the highway, they should look for other ways (just like sending netmail by route in the case of FIDOnet). Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1304 [1995] Scn From : Denis McMahon 2:251/20 02 Nov 97 11:32:20 To : Lawrence Garvin 04 Nov 97 05:43:12 Subj : IP-access ------------------------------------------------------------------------------- Lawrence Garvin wrote to Denis McMahon: DM> It should not be a requirement that a net maintain a nameserver DM> before that net is allowed to contain IP nodes! LG> No... but SOMEWHERE, that node is going to have to be listed in LG> somebody's nameserver in order to get IP service. It matters not LG> who runs the server, the fact remains, it must exist. DM> Agreed, however I was disputing the suggestion that nameserver DM> entries should be handled by the NCs, how many NCs run nameservers? LG> Who said anything about the -NC- running the nameserver? ? ? ???? Ask Bjorn Hansen (I hope I spelled it right), in the message that I originally replied to suggested that the nameserver should operate at the net level. LG> However, SOMEBODY in the -NET- or -REGION- had better be capable LG> and willing to run a nameserver if they want IP-connectivity in LG> Fidonet. It might be the case in your part of the world that individuals can afford permanently connected machines at home, or work in an environment where they have control of what is visible publicly to the rest of the internet rather than kept behind a firewall, however in other parts of the world this may not be the case. My domestic connectivity is purely dial-up, and my employer has a firewall that I have no control over whatsoever. Regards Denis --- timEd/386 1.10 * Origin: Vote Denis McMahon for ZEC2 (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1305 [1995] Scn From : Denis McMahon 2:251/20 02 Nov 97 11:12:04 To : Ward Dossche 04 Nov 97 05:43:12 Subj : IP-connectivity ------------------------------------------------------------------------------- Ward Dossche wrote to Pedro Lima: >> Is the reference 'FTS-0001' copyrighted? WD> > WD> Yes. WD> > Ok, then we'll have to interpret what's said in P4 in a different way > (as I believe it was intended in the first place anyway), or replace P4 > altogether, if we want to do it 'by the book'. WD> WD> So far, concerning trying to get IP in, I think nothing is (nor can WD> be) according to the book. It must be accoring to the book, we just have to re-write the book. :-) WD> BTW, some guys are threatening me with formal complaints if I WD> continue this effort. I think they picked the wrong target to waste WD> ammunition. You think? I know :-) Regards Denis --- timEd/386 1.10 * Origin: Vote Denis McMahon for ZEC2 (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1306 [1995] Scn From : Sean Rima 2:252/356 02 Nov 97 21:56:14 To : All 04 Nov 97 05:43:12 Subj : IPMAILER ------------------------------------------------------------------------------- Hello All! New to the Z1 backbone: IPMAILER Topic: IPMAILER Moderator: Patrice Boucher, 1:167/323 Requested: 09 Oct 97 Expiry: 12 Nov 97 Region Rqst: 10 18 Later, Sean --- timEd/386 1.10 * Origin: DSP BBS Reading Berks {0118 961 4636} (2:252/356) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1307 [1995] Scn From : Yuri Teterin 2:5030/239 02 Nov 97 20:55:38 To : Rune Johansen 04 Nov 97 05:43:12 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- Hello, Rune ! Fri Oct 31 1997 Rune Johansen writes to Marco d'Itri: RJ> To try to make IP flags coherent, I will suggest using a prefix of IP to RJ> all of them, like Kim suggested. IPT - Telnet, IPR - Raw TCP, IPV - Vmodem RJ> Protocol, IPI - Raw TCP Ifcico proprietary (?) That is from your point of view the difference between IPR and IPI ant how this is connected with your classification of protocols from the point of view of transport-layer only? ifcico have an optimized protocol indeed, but this is a session-layer protocol, that can be used both over IPR and over IPT. It is turned on by means of an (unregistered) EMSI prot code TCP. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1308 [1995] Scn From : Yuri Teterin 2:5030/239 02 Nov 97 19:39:40 To : Rune Johansen 04 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Sat Nov 01 1997 Rune Johansen writes to Pablo Saratxaga: RJ> If you are not able to (or willing to) run the "default" ports, you have RJ> to indicate what session handshake protocol is available on wich IP port. RJ> That means that we would have to say that "this port handles EMSI, this RJ> port handles BinkP, this port handles FTS-0001" and so on. That would be really very nice and convenient. Have you ever seen as mailers running FTN-over-telnet try to fallback to YOOHOO or FTS-0001 at pure IP-lines due to timeouts only? :-( Unfortunately existing software can not do this. But why should we reject this nice approach when we implement _new_ features in software? RJ> If all ports would handle a fallback to the current lowest protocol RJ> (today that is FTS-0001, tomorrow maybe something else), there would RJ> be no problem for a conencting mailer. There would be overhead for protocol detection and the same problem with fallback to ineffective protocols at pure lines. And what for? RJ> How else whould it be denoted what port to fallback to if they have RJ> not got the respective protocol available? The software should have the information about available protocols before connection and initiate (or not initiate) the call using this information. Why do you accept this approach in the case of transport protocols but do not accept it in the case of session-layer protocols? Why do you suggest to leave only one port for all FTN-connections and then autodetect telnet or vmodem protocol or 'fallback' to raw TCP? RJ> For direct mailer-to-mailer communication we have today four different RJ> types of connection in use: Via telnet, via raw TCP, via VModem prop., and RJ> via ifcico proprietary protocol. 'raw TCP' and 'ifcico proprietary' are the same. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1309 [1995] Scn From : Dieter Ringhofer 2:2476/14 03 Nov 97 20:16:36 To : Ward Dossche 04 Nov 97 05:43:40 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> even when having all technologies available and in use (isdn, analog up >> to x2-server) i'm complaining about. imo it has been a mistake to list >> such systems as full featured nodes (according policy) because they >> aren't. WD> You are 100% correct ... politically. I blame that to a lack of vision of WD> those that devised Peefore. you're shure about them having no vision? think about the missing layer in fts-0001. they described a network basing on dialup connects and fixed a minimal common protocol. as worse as it is, it's a common dominator which works with any known transport layer. skipping this makes whole fidonet obsolete, it's name should be changed to 'micro-internet' or whatever one is pleased to call it. don't forget that in early 90s the some german systems did transfer of fidomails even via permanent lines using tcp/ip services (one of them has been my fido-host and ftn-uplink for several years). they didn't need a nodelist entry for this ;) --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1310 [1995] Scn From : Ward Dossche 2:292/854 02 Nov 97 18:43:16 To : All 04 Nov 97 07:09:32 Subj : IP - Call for opinion votes ------------------------------------------------------------------------------- Yow All, This is a query-sheet to collect opinions on how to integrate ip-nodes into the nodelist. If you don't want such integration you need not answer and simply reading this conference for you constitutes a loss of time. Some people announced proposals, which are discussed seperatly. I hope, that this query sheet concentrates the different aspects and will lead to one proposal. Netmail your reply back to 2:292/854. Take care, \x/ard ************************* Query-sheet IP-NODES ************************* This query sheet is independant of an extended nodelist format, which might solve a more complete capability solution in the future. It also has no influence on entries in regional lists (like pointlists etc.), which may follow the same specifications as the international nodelist. 1. Where to position the IP#/FQDN 1.1 [ ] node_name field 1.2 [ ] location field 1.3 [ ] phone number field 1.4 [ ] flag field 2. Format of flags 2.1 [ ] individual flags with optional port (colon separated) 2.2 [ ] packed flags (decimal coded 32 bit) Sample: 2.2 uses a table like this: 1 Raw IP 2 Telnet (port 23) 4 Vmodem (port 3141) 8 ifcico (port 60179) 16 ifc-Telnet (port 60177) 32 BinkP (port 24554) 64 ... to be continued ... 256 FTP 512 TransX 1024 ... to be continued ... This might result in a flag like IPC38 for a node, who supports Telnet, Vmodem and BinkP. Non-standard ports are not supported. The same node would present TELN,VMO,BNP:24554 with optional portnumber as individual flags according to 2.1. 3. Direct Mailer handshake via IP required for nodelist entry 3.1 [ ] Yes 3.2 [ ] No A direct mailer handshake uses nodelist data for authentication between the two systems and handles interactive transactions according to the protocols, which are used between conventional systems. In opposite are i.e. ftp and email-based protocols (indirect), which are buffered elsewhere and do not rely on any nodelist based information for data exchange. 4 Announcements of additional protocols allowed? 4.1 [ ] Yes 4.2 [ ] No This is part 2 of question 3: If a direct handshaking protocol is a claim for the nodelist entry, should the indirect protocols be announced anyway? 5. IP may be used only as additional capability 5.1 [ ] Yes 5.2 [ ] No Explanation: In case of YES: IP nodes must have at least one conventional entry in the nodelist to get another nodenumber for announcing ip-cpabilities or list additional ip flags. 6. Should IP-nodes fullfill standard claims like ZMH or at least clearly stated online times according to the fidonet policy? 6.1 [ ] Yes 6.2 [ ] No 7. Additional comments (concerning to above questions) ************************************************************************** --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1311 [1995] Scn From : Lawrence Garvin 1:106/6018 02 Nov 97 21:03:56 To : Lech Szychowski 04 Nov 97 07:09:32 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Lawrence Garvin: > Even to that extent, the SMTP may still be totally separate from the > Fidonet. LS> Yes, I know it might be a totally separate thing - or, to be more LS> precise, I know it may be made to be. But ain't that a twisted LS> setup? Is there any real (ie existing in real life) reasons for LS> separating this two kinds of messages ("separating" standing for LS> "making them not to go to the same person eventually")? I don't thihk that is so much an issue with anybody -wanting- to keep them separate -- it's just that most of the SMTP<>FTN gating software that -I- have looked at is lousy. It's poorly documented; it's way to complicated for such a simple task; most of it is built to move news<>echomail as well as smtp<>netmail, which just confuses the issue; they're kludgy, and most of them require two or three -additional- third party products just to get them working; some of the writers have dropped out of sight; others have a warped idea of support, even one writer stooped to replying in a very sarcastic tone when I misunderstood his poorly written documentation which implied capabilities that most definitely did not exist. The -one- product I did find, which I'm currently using, which -is- well documented, -is- simple to setup, -does- stick just to smtp<>netmail, -does- work natively with OS/2 sendmail and my Squish, and thus does not require any third party products at all, is still only available in a single node gateway version. There is a beta available that purports to provide multidomain capability, but it don't work. The good news is that the writer has been very responsive to my needs, but, alas, he's moving cross country, and doesn't expect to be able to release another beta version until late this month. :( Therefore... while I'm sure the -desire- exists, the technological hurdles to merge the two capabilities is difficult, at best, for an experienced person to deal with. Of course, there's also the simple issue involving domain registrations, name servers, et. al. that become major hurdles to many as well. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1312 [1995] Scn From : Lawrence Garvin 1:106/6018 02 Nov 97 22:14:10 To : Kim Heino 04 Nov 97 07:09:32 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Kim Heino said in a message to Lawrence Garvin: > how does one deal with the desire to have the -same- node number on both > the PSTN node and the IP node? KH> Is that really needed? Yes! KH> If you take a look at the current nodelist you'll find that many KH> nodes already have multiple nodenumbers. Only in Zone 2, Kim. :( KH> For example I have 4 (plus two administrative) nodenumbers because KH> I have 4 phonenumbers. With IP the situation is the same, you have KH> two addresses, PSTN and IP, and therefore you should have two KH> nodenumbers. So... how would you suggest that I toss echomail then? I need -one- identity to toss/receive echomail. That identity is currently 1:106/6018. I have some systems that receive echomail from 1:106/6018 by PSTN, and I have other systesm that receive (or pickup via poll) echomail from 1:106/6018 by IP. If my IP node has a different node number, you would expect the downlinks to configure their system to toss to -one- node, and actually -send- to another? Surely you wouldn't suggest that I maintain two separate echomail bases for each node? What if a downlink's IP connection goes down, and they decide they want to pick up their mail from the PSTN node? different node numbers means that I need to have different -outbound- directories -- therefore, the downlink could not pickup mail from the PSTN node in such a case. What really would happen is that both nodes, PSTN and IP, would present -both- node numbers all of the time, and share a single outbound directory. But if that is the configuration, then the second node number is totally redundant, and thus, totally unnecessary. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1313 [1995] Scn From : Lech Szychowski 2:480/33.7 03 Nov 97 01:23:00 To : Dima Maloff 04 Nov 97 07:09:32 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>> is that we don't need a standard protocol. At least right now. > LS> Therefore there is no total connectivity... Or is there? [...] > there are 108 entries today. 90 of them (from regions 24, 25, 45, > 46, 50, 51) have BND flag. 83.3%. (24 nodes have TELNET capability, I'm not trying to say there is just a few binkp-capable nodes out there> I'm just trying to make us realize that unless we adopt some common standard protocol total connectivity is most likely pure fiction; although 83.3% is a vast majority by any standards, it is nowhere near total connectivity. I don't want to be able to connect to eighty something percent of IP nodes - I want to be able to establish a session with any given one. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1314 [1995] Scn From : Lech Szychowski 2:480/33.7 03 Nov 97 01:14:00 To : Dima Maloff 04 Nov 97 07:09:32 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>> If having binkp support is enough a) to be compatible; b) to be fast; >>> c) to be effective, why not allow binkp only nodes? > LS> If all these conditions are met, there is no reason not to allow them > LS> - "compatible" being the main keyword here. > Dare you to say that binkp nodes are a minority? No, why? Is there anything in the above quote that implies they are? :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1315 [1995] Scn From : Ward Dossche 2:292/854 02 Nov 97 09:58:46 To : Ward Dossche 04 Nov 97 07:09:32 Subj : !!!!!!!!!!!!!!!!!!!! ------------------------------------------------------------------------------- No I don't enjoy writing mail to myself but obviously we have a dupelink via the US again. > PATH: 292/854 480/33 70 106/6018 8277 270/101 2433/225 1200 2432/200 > PATH: 292/854 I will get in touch with the concerned people by netmail because I am feeding already 2:292/876 who, as far as I'm concerned, is the official feed for 1:270/101 from Europe. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1316 [1995] Scn From : Lawrence Garvin 1:106/6018 02 Nov 97 22:36:32 To : Rune Johansen 04 Nov 97 07:11:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: >My gut feeling is that the "lowest common denominator" is FTS-0001 >over telnet listening on port 23. RJ> I think we should look at telnet transports versus raw socket RJ> transports the same way as you'd look at PSTN transport versus RJ> ISDN-Only transport. Well, first, I think this concept of a "raw socket transport" is misleading. There must be -some- protocol that works at the network layer to accomplish the data transportation from one system to another. RJ> The lowest session protocol described by Fidonet policy is RJ> FTS-0001. That should be the minimum capability of a mailer, RJ> regardless of what transport mechanism it uses. I agree, but that's apparently not indicative of reality, at least as far as BinkD is concerned. I'm looking at putting up a BinkD node on my system, but it'll never (even if we work this out) be entitled to a node number of its own (not that I'd want one, of course) - because it can't do FTS-0001. Instead, it will have to 'share' a node number with my primary node, which is on PSTN, and my two VModem nodes. All four nodes will identify themselves as 1:106/6018. The only difference between nodes 2, 3, and 4 will be that node 4 will only be accessible on port and will only support BinkP protocols, where as nodes 2 and 3 will be available on ports 23, 3141, and 3142 and they will support FTS-1 connects, along with FTS-6 and EMSI. But for an IP-only node, in order to accomodate the implementation of BinkD and other BinkP-only mailers -- I think that it's not unreasonable at all to say -- if you want to get an FTS-1 session via IP, you'll have to do it on port 23. > My only problem with this Rune, is how does one deal with the desire > to have the -same- node number on both the PSTN node and the IP > node? I'm not sure I'm enthralled with the idea of having to > maintain a second identity, just so I can add Fido-IP connectivity to > my single existing node. RJ> One deals with it just the same way that one deals with the desire RJ> to have the same node number on their PSTN node and their ISDN-only RJ> node. You'd get two node numbers. Except that is not necessary at all! Perhaps not in Europe, but in the U.S. I can put an analog V.34 modem -and- a V.110/V.120 ISDN modem on the SAME telephone number. The ISDN modem senses whether the inbound call is digital or analog, and if it's analog, it'll route it to the POTS port and the V.34 modem will answer. If it's digital, then the ISDN modem will answer and you get a V.110/V.120 connection. Both happen at the same telephone number, though. RJ> I have one ISDN adapter with PSTN capabilities, and one PSTN-only RJ> modem. They cannot be on the same node number Why not? Can you not plug your PSTN modem into the POTS port on the back of the ISDN adapter? Or is this built in to the ISDN adapter? If it is built in, then your limitation is the fact that you have two physical devices, not that your ISDN adapter is incapable of providing both services on the same telephone number. RJ> True. I'd maybe start looking at NLMake to see if it needs changes. I see that the latest version of Fastlist now has capabilities to compile IP numbers from a source nodelist. That's a good start -- but now what we need is a nodelist generator that will allow IP numbers in the telephone field. Obviously that's the only way we're going to be able to implement IP connectivity in the immediate future, if the IP number needs to be in the nodelist. Hopefully, though, down the road, we'll have nodelist compilers and mailers that have support for FQDNs in one of the text fields, and then a FQDN and PSTN-telco number can coexist on the same node number. In the meantime.. -I- have an immediate need for a nodelist generator that is liberal enough to allow some minor modifications in the content of the telno field. And.. while we're on that subject, I think I have a new idea for how to modify the nodelist generator software, but still provide some protections for the telno field. All it needs to do is accept * and # in the telno field, and remove the restrictions that the first character must be 0-9. Then, use the octothorpe (#) as the first character of an IP address. VModem already looks for the octothorpe as the first character of the telno (IP address) in order to determine whether to initiate the call as a telnet call on port 23, or a VMP call on port 3141. The sysop could choose to either leave that # in the address, or remove it. For example, by placing a simple translation configuration line in my nodelist compiler config file, I can tell it to translate all numbers starting with a #, and rewrite it with the same #. This, then, prevents the natural inclination of the nodelist compiler to prepend the international dial prefix default on a number not explicitly defined -and- it has the added benefit that now, all IP calls from my system would automatically default to vmp protocols. I could define a ModemTrans parameter to override that default if the VMP flag was not present in the nodelist. Or, I could configure my nodelist compiler to strip the octothrope on all numbers, and configure a ModemTrans parameter to use ATDT# instead of ATDT if it identifies a VMP flag in the nodelist, otherwise the default would be to initiate a generic telnet call on port 23. I even suspect that it might be possible to authorize those two characters # and * in the telno field just by doing a patch to the binary executable -- presuming one can find the offset where the program checks for the range 0-9 Actually, it probably could be patched easier to permit all of the special characters from ASCII 34 (#) through ASCII 57 (9) to be used in the telno field, then we've got a whole bunch of opportunities to use the first character of the telno field to indicate all sorts of things, including protocols! If the digit is 0-9, then it's assumed to be a PSTN number; however, if it's a special character ASCII 34 through ASCII 47, it can mean anything the writer of the nodelist compiler wants it to mean. For example, again, the presence of the # as the first character could indicate an IP address with vmp services available on port 3141. A $ could indicate a node with binkd/binkp running on port sixty thousand something. * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) --- Squish/386 v1.11 * Origin: The Enchanted Forest * Houston, Texas (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1317 [1995] Rcv Scn From : maciej grzeszczuk 2:480/70 03 Nov 97 14:08:38 To : Lothar Behet 04 Nov 97 07:12:36 Subj : Re: ifcico: Nodelist Flags ------------------------------------------------------------------------------- From: maciej grzeszczuk Wed, 29 Oct 97 09:07:24 +0100 Lothar Behet napisal byl w fido.ip_connect: > ifcico uses 60179 by itself and 60177 for telnet sessions. > Does this port 60177 behave in any way other than the default telnet port 23? at my system on port 60177 stands iftelnetd which passes to ifcico. without it telnet connectivity would be impossible i think... > Is port 60177 supported by any ifcico in the same way? you need iftelnetd. it's free, included in sources to the ifmail distribution. 1222 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9 * Origin: rw> whoa! chix with lots of boobs! LS> yeah... f (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1318 [1995] Scn From : Marco d'Itri 2:335/680.666 04 Nov 97 14:20:42 To : Lech Szychowski 04 Nov 97 22:10:20 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >fiction; although 83.3% is a vast majority by any standards, it is >nowhere near total connectivity. FTN over telnet does not have a better support. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1319 [1995] Scn From : Marco d'Itri 2:335/680.666 04 Nov 97 14:18:14 To : Lawrence Garvin 04 Nov 97 22:10:20 Subj : Re: IP-access ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >I don't thihk that is so much an issue with anybody -wanting- to keep them >separate -- it's just that most of the SMTP<>FTN gating software that -I- >have looked at is lousy. It's poorly documented; it's way to complicated for >such a simple task; most of it is built to move news<>echomail as well as Looks like mine is simpler: md@wonderland:2:~$dir vmailer.pl -rwxr-xr-x 1 root root 8529 Oct 11 21:44 vmailer.pl* It needs the standard mail transport interface which every unix system has out of the box. It's free and it works with all unix tossers. >Of course, there's also the simple issue involving domain registrations, name >servers, et. al. that become major hurdles to many as well. You don't need a domain nor a name server. If you can't have one you don't even need another email address. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1320 [1995] Scn From : Marco d'Itri 2:335/680.666 04 Nov 97 14:33:30 To : Yuri Teterin 04 Nov 97 22:10:20 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Yuri.Teterin@f239.n5030.z2.fidonet.org wrote: > 'raw TCP' and 'ifcico proprietary' are the same. They are not. ifcico has an optional proprietary communication protocol (at the level of zmodem etc) that can be run in FTS-1 and EMSI sessions over telnet or over the raw socket. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1321 [1995] Scn From : Pedro Lima 2:362/21 02 Nov 97 18:48:30 To : Chris Maddock 05 Nov 97 05:49:48 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Hi, CM> I was more referring to the CM> likelyhood of someone not configuring the software with =any= CM> long-distance codes. Aaah, I see. CM> That is what I meant. That we can expand our horizons to encompass the CM> Internet, and =any= other technology, would be great! Yes, it would, although it would be even better if we changed the nodelist format. :-) CM> It needs to be expandable almost indefinitely. Precisely. CM> Agreed. That's why I'm here. Dunno if I can help, but I'll try, and CM> I'm here. Great! :-) Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1322 [1995] Scn From : Amir Shabashvili 2:5049/12 03 Nov 97 09:58:42 To : Dima Maloff 05 Nov 97 05:49:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dima! Replying to a message from Dima Maloff to Lech Szychowski: DM> Moreover, only 1 of 4 binkp-capable nodes with static IP addresses DM> from my net are in those lists. :) 0 of 4 from mine. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1323 [1995] Scn From : Pedro Lima 2:362/21 04 Nov 97 00:39:32 To : Kim Heino 05 Nov 97 05:49:48 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- Hello, KH> Can't FD filter out flags starting with IP? Not that I know of. KH> How do you filter out ISDN flags then? Filtering every existant variant. KH> How about filtering out all nodes having baud rate 300. KH> Can FD do that? Yes, but I do have an ISDN node running on FD. It would be perhaps simpler if ISDN nodes had a specific flag, but then again, ISDN nodes are PSTN and it makes sense to list both modem and ISDN access in one entry, so either way I'd have to list all the variants. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1324 [1995] Scn From : Amir Shabashvili 2:5049/12 03 Nov 97 10:56:26 To : Amir Shabashvili 05 Nov 97 05:49:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Amir! Replying to a message from Amir Shabashvili to Dima Maloff: AS> Fido-under-Policy4.07 except we shut ours eyes on some things. Only AS> thing I can imagine is IP-connectivity flag in my nodelist string. Any nodelist string, not my only, I mean:) Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1325 [1995] Scn From : Pedro Lima 2:362/21 03 Nov 97 06:39:52 To : Lech Szychowski 05 Nov 97 05:49:48 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Hi, LS> From my personal point of view it is acceptable. But it breaks the old LS> Fidonet rule of defining standards common to everyone and ensuring LS> total connectivity - and that frightens me a bit. That notion has proven in practice to be impossible to achieve, and there's even no need to call upon the existance of IDSN-only nodes for it, the problem is much wider than that. IMHO, the principle should be maintained for what it represents, i.e. the will of maintaining the highest level possible of inter-connectivity within FidoNet, but I also feel we can't stop a major development (and that would be the case for ISDN or more recently IP) because of it. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1326 [1995] Scn From : Pedro Lima 2:362/21 03 Nov 97 18:11:42 To : Rune Johansen 05 Nov 97 05:49:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, RJ> It reflects the requirement of being a node in Fidonet, the RJ> possibility to accept a FTS-0001 session handshake on the transport RJ> protocol that you have a mailer on. The idea of having a mandatory session protocol is to allow for a maximum of inter-connectivity as possible. A PSTN-only node can *never* connect to an IP-only one, no matter if both are running FTS-1 compatible mailers. This situation won't change a bit if we have a mandatory session protocol for IP nodes which isn't FTS-1. So the only reasoning left for having FTS-1 as the mandatory standard for IP nodes is politics. Politics which, in this case, is extremely counter-productive for the whole of FidoNet and serve no purpose at all beyond satisfying a regulation which didn't foresee the possibility of FidoNet ever being run on top of anything else than the PSTN in the first place. RJ> That is completely true. But, by ex-SU sysops only using BinkD, they RJ> fail to adhere to the basic rule of connectivity in Fidonet, namely RJ> the requirement of accepting a FTS-0001 session, if the caller has got RJ> no other session handshake protocol in common. Ok. Let those sysops support FTS-1 sessions over IP, and then you come over to my place and establish a FTS-1 session between my FTS-1 compatible PSTN mailer and their FTS-1 compatible IP mailers. If it works, then I'll admit that not supporting FTS-1 in IP mailers "fails to adhere to the basic rule of connectivity in Fidonet". Deal? :-) Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1327 [1995] Scn From : Amir Shabashvili 2:5049/12 03 Nov 97 10:47:20 To : Denis McMahon 05 Nov 97 05:49:48 Subj : IP-access ------------------------------------------------------------------------------- Hello Denis! Replying to a message from Denis McMahon to Lawrence Garvin: LG>> No... but SOMEWHERE, that node is going to have to be listed in LG>> somebody's nameserver in order to get IP service. It matters not LG>> who runs the server, the fact remains, it must exist. DM> Agreed, however I was disputing the suggestion that nameserver entries DM> should be handled by the NCs, how many NCs run nameservers? Some node in my net run nameserver for *.n5049.z2.fidonet.net, and I'm as NC talking to him all things I need from DNS.I see no problems with DNS using, only thing we need is some rules for that in case NC is't DNS-master. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1328 [1995] Scn From : Pedro Lima 2:362/21 04 Nov 97 00:46:56 To : Rune Johansen 05 Nov 97 05:49:48 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- RJ> To allow for other addresing schemes to not be called, you would only RJ> accept to call those trasnport mechanisms that your mailer support. Which means that I'd have to permanently review my configuration just in case flags were deleted or added. Mind you, I even might do it, but I'm sure many won't. It would be much simpler if a flag is attributed to a different transport. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1329 [1995] Scn From : Amir Shabashvili 2:5049/12 03 Nov 97 10:10:06 To : Dima Maloff 05 Nov 97 05:49:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dima! Replying to a message from Dima Maloff to Lawrence Garvin: LG>> 100% Policy 4 and FTS-0001 compliant. DM> The whole idea of an IP-only node is AGAINST the current Policy. Yes. And I have't idea how we can incorporate stuff like that in Fido-under-Policy4.07 except we shut ours eyes on some things. Only thing I can imagine is IP-connectivity flag in my nodelist string. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1330 [1995] Scn From : Amir Shabashvili 2:5049/12 03 Nov 97 12:38:58 To : Dieter Ringhofer 05 Nov 97 05:49:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dieter! Replying to a message from Dieter Ringhofer to Dima Maloff: DR> there should be a mandatory standard to ensure connectivity or we can DR> get rid of every ftn. the least common dominator in fidonet is DR> fts-0001, that's reality. FTS-0001 is more political thing (keep in mind it's place in Policy) then real appropriate technical standart. FTS0001 too bad not for IP only, but for PSTN connection also. I remember most connections of my system at last 5 years with FTS001 was failed, and now you wish we must see that on IP? Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1331 [1995] Scn From : Pablo Saratxaga 2:293/2219 03 Nov 97 03:48:40 To : Lech Szychowski 05 Nov 97 05:51:36 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Sat, 01 Nov 97 14:27:00 +0100, Lech Szychowski said: >> The reason is that it is already done in z2.fidonet.org, while on other >> zones DNS there are only MX entries (=Mail eXchangers=internet->fido mail >> gateways) and not A entries (=IP addresses=fidonet nodes TCP/IP pollables). LS> You mean they have all their MX'es in other domains? Strange idea... The domain used by the MX is pointless. I doubt there is one single machine whose primary (as the one in the PTR entries) domain is fidonet.org -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1332 [1995] Scn From : Pablo Saratxaga 2:293/2219 03 Nov 97 03:44:50 To : Pedro Lima 05 Nov 97 05:51:36 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Fri, 31 Oct 97 04:23:26 +0100, Pedro Lima said: PL> But, although I have full confidence in the managers of the fidonet.org PL> domain, I disagree to limit the possibilities of FQDN usage in FidoNet PL> to one particular domain (or a limited number of), be it fidonet.org, If there isn't a refrence domain then the whole idea of DNS can be drop, how can a mailer know the fqdn address of a node if the domain can be an arbitrary one ? -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1333 [1995] Scn From : Pablo Saratxaga 2:293/2219 03 Nov 97 04:05:40 To : Vilo Mlich 05 Nov 97 05:51:36 Subj : Re: BinkD (0.9.2) specification ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Fri, 31 Oct 97 09:41:00 +0100, Vilo Mlich said: PS> IPTEL : telnet-vmodem, port 23 PS> IPTxy : Same as the actual Txy flag, but denoting internet online time. PS> while the abscence of Txy flags imply ZMH only, the abscence of PS> IPTxy should imply it is 24h/24 on the internet (so no need for a PS> IPCM ;-) ) VM> Flag IPTEL is for node, which is on internet 4:00-1:00 UTC ? Ahem, yes I told a stupidity there, I saw the problem whith TEL and Txy but not whith IPTEL and IPTxy 8-) What about IPOxy for online time ? -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1334 [1995] Scn From : Pablo Saratxaga 2:293/2219 03 Nov 97 04:01:24 To : Lech Szychowski 05 Nov 97 05:51:36 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Sat, 01 Nov 97 14:37:00 +0100, Lech Szychowski said: >> BTW, what are the codes used by other TCP/IP protocols on EMSI ? >> ifcico compatibles use "TCP", what uses binkp ? LS> I can't remember I had any connections with BinkD or Argus, so I'm LS> afraid I can't help you here. Well, since there I learnt that BINKP is a session handshake too, somy question was pointless :) -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1335 [1995] Scn From : Pablo Saratxaga 2:293/2219 03 Nov 97 04:00:04 To : Lech Szychowski 05 Nov 97 05:51:36 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Sat, 01 Nov 97 15:01:00 +0100, Lech Szychowski said: >> Each fqdn that wants to receive email *MUST* have an MX, it can point to >> itseld. But whithout an MX there is no guarantee at all that mail will >> be sent. LS> Are you 101% sure about that? Yes. LS> I think vast majority of existing MTAs LS> will first try MX for a given FQDN and if it fails (ie DNS query returns LS> no MX type records) they go for the A record(s) instead. But not all, hence I said that there is no guarantee. sendmail for exemple doesn't do that by default, you must tell it explicitely on the config file: O TryNullMXList=True Here is what is told in the operations manual : TryNullMXList [...] you may want to try to connect directly to that host as though it had no MX records at all. Setting this option causes .i sendmail to try this. [...] This option is disrecommended. I also experienced the problem of undeclared MX recently when I was working whith my uplink on setting up his sendmail for forwarding *.chanae.stben.be to me; he had put a *.chanae.stben.be MX entry and an A entry for colargol.chanae.stben.be, and no MX for that last, the mail for it was bounced... >> f33.n480.z2.fidonet.org. A 123.45.67.89 >> is wrong. LS> Why? If 123.45.67.89 is an SMTP capable host, it will work. Only if the sender server is configured to reach directly the A address, which is not the case of all servers, and is likely to become less and less common as that feature is explicitely not recommended. >> f33.n480.z2.fidonet.org. A 123.45.67.89 >> MX 1 f33.n480.z2.fidonet.org. >> MX 10 elsewhere.net. >> * MX 10 f33.n480.z2.fidonet.org. >> MX 20 elsewhere.net. >> is right LS> Only if you put LS> $ORIGIN f33.n480.z2.fidonet.org. LS> in front of the wildcard record :) Yes, I should have written: f33.n480.z2.fidonet.org. A 123.45.67.89 MX 1 f33.n480.z2.fidonet.org. MX 10 elsewhere.net. *.f33.n480.z2.fidonet.org. MX 10 f33.n480.z2.fidonet.org. MX 20 elsewhere.net. sorry for the mistake -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1336 [1995] Scn From : Rune Johansen 2:210/20 04 Nov 97 17:56:12 To : Yuri Teterin 05 Nov 97 05:51:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > What for? Does any human caller, trying to connect your BBS with help of > telnet, fond of your EMSI and 'ESC-ESC' prompt? Or does any mailer connecting I don't have any Esc-Esc prompt. But, that's because my mailer and BBS is the same program. It is capable of detecting mailer and human user at the same time. > with your station, like to see every time the banner of your BBS? Mailers that is properly implemented does not care about banner, as long as they see the init of their implemented handshake protocols. > What is implemented at your site is just an _disadvantage_, connected with > 'modem history' of your software, and nothing more. Yes, connected with modem history, but does also allow me to run FTN and BBS on the same port, regardless of mailer handshake protocol. > An ordinary telnet client or server can not have anything 'running behind' > it. So your telnet software seems to be a special one, elaborated for BBS or > FTN, isn't it? Of course it is. If I run it on a unix machine, I can say (to my human callers that want shell access): type "unix" to get to shell login prompt. Then I would trigger on that, and run /bin/login. If it's a BBS user, he would just type his name, and log into my BBS. If it is a mailer, it would see my EMSI and BinkP handshake, or fallback to FTS-0001. >> Looks to me as a normal modem mailer on a telnet daemon. > We never heard about 'mailer on a telnet daemon'. What kind of telnet daemon > do you use? Not yours, I believe. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1337 [1995] Scn From : Lawrence Garvin 1:106/6018 03 Nov 97 22:24:20 To : Yuri Teterin 05 Nov 97 05:51:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Yuri Teterin said in a message to Lawrence Garvin: YT>> Why not? FTS-0001 does not suppose that the connection is YT>> error-free. And any non-errorfree connection can be implemented YT>> very well with help of UDP. LG> Ahh... if that is your impression of the differences between TCP LG> and UDP, then you've misunderstood much, Yuri. YT> My impression is that a modem link without ARP is much more like YT> an UDP-based session than a TCP-session. Huh? --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1338 [1995] Scn From : Lawrence Garvin 1:106/6018 03 Nov 97 22:25:16 To : Nick Soveiko 05 Nov 97 05:51:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Nick Soveiko said in a message to Lawrence Garvin: LG> However, Policy is quite clear on certain things, and gives no LG> leeway at all for 'interpretation' or 'common sense' modifications. NS> ok, let's forget 'common sense' for a minute. Okay. :) LG> One of those unequivocable requirements is that EVERY NODE listed LG> in the nodelist (except those flagged as PVT), must be capable of LG> negotiating an FTS-0001 session during Zone Mail Hour. NS> fts-0001 has a *really huge* hole in it: Just one? :) But that's okay... Fidonet Policy 4 has a few more holes in it as well. But we're not going to change either document before the turn of the century, so we might as well figure out how to make things happen -within- the constraints of those documents. NS> it leaves the question of physical layer open. That it does. And my kudos to Randy Bush for being the visionary. It is just very unfortunate that the drafters of Policy 4 were not half that visionary, in which case they would have left out much of the 'dated' material that was included. NS> it means that my system could be 100% fts-0001 compliant during NS> the zmh and at the same time you have 0% chances to connect to it. Yep. It certainly does. :) NS> here you go. However, elsewhere in Policy 4 it covers that 'hole' by requiring that you also have a MODEM connected to the published telephone number of your FTS-0001 compliant node, and that the MODEM must be capable of answering a call, and negotiating some sort of CARRIER, so that the calling node can take advantage of the presence of your FTS-0001 compliant node. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1339 [1995] Scn From : Rune Johansen 2:210/20 04 Nov 97 00:47:08 To : Lawrence Garvin 05 Nov 97 05:51:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> When it comes to nodelist generators, I have not played around with >> nlmake enough yet, to tell if it can do the job already. Nodelist >> compilers would be the task of existing compiler programmers, >> and/or the mailer programmers themselves. > Well, we might want to see about soliciting/encouraging one or more of 'em to >get involved with this process, before we discover we've created a monster tha > we can't even implement until months down the road 'cuz nobody's committed to > writing software. I have doen quick tests here with NLMake, and it will allow me to put FQDN's in phone field, it will allow me to use colons in phone field, it will allow me to put things in the phone field, even though it is a Pvt entry, also if it is a point entry. Seems like it does all we want? :-)) It is a OS/2 program, that uses EMX. EMX exist for DOS, doesn't it? :-) --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1340 [1995] Scn From : Rune Johansen 2:210/20 04 Nov 97 17:30:22 To : Nick Soveiko 05 Nov 97 05:51:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >neither policy, nor fts-0001 does not say that fidonode has to support fts-000 > on each and every port. they simply don't say anything about ports. Because on current implementations (PSTN/ISDN) there are only one port, and it is the one that you have on your modem. >> But it can be stated rather definitely that none of existing mailers run >> BinkP and FTS-0001 at the same port, and there is no reasons to >> suspect that some mailer will ever do this. >> BBBS (that I run) can do BinkP, EMSI and FTS-0001 on the same port. > so, you're trying to sell us a proposal that reflects your particular mailer >using one particular approach of miltiplexing different services and different You say that there is no reason to suspect that some mailer will ever do this. I say that I use a mailer that _do_ this. > protocols on one port. your proposal rules out the other approach which does > not contradict with policy and is in perfect agreement with current internet > technology and practices. The suggestion of including IP-only-BinkP-only nodes does not contradict with policy? First of all, you use a protocol that is not documented completely (to the public), and does not have the possibility to fallback to a commonly implemented mailer handshake protocol, that is required by policy to run to get nodestatus in todays fidonet. I call that contradiction to policy by the first degree. >> So your proposal will actualy cut all BinkP-based part of FIDO and leave it >> out of nodelist. >> It will cut all current BinkD 0.9.1-only IP-only nodes, > it will also prevent *anybody* from indicating port-multiplexed capabilities. > it will prevent sysops with dual (pstn and binkp/ip) from indicating their ip > capability in the nodelist. *that's really bad*. I know that it will not allow for two different transport mechanisms that has got two different ways of adressing (phone number versus IP address). But, if you look a little longer than this evening, you might see that we just can't take the system name field to use for IP address, the phone field for phone number, the sysop name field for X.25 address etc. And, I am also saying that BinkD mailer implementation of today does not alone meet the requirements of being a self-sustained node in Fidonet. Let's say that we have a intermediate solution to the problem with getting IP into the nodelist. Let's say that we include IP address in the system name field, and we get the ZC's to adapt several new user flags. Yes, we have got communication in the nodelist, on a temporary basis. But, it's of absolutely no use on a permanent basis. Or, do you want the nodelist to become a patchwork of temporary fixes? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1341 [1995] Scn From : Rune Johansen 2:210/20 04 Nov 97 17:49:06 To : Yuri Teterin 05 Nov 97 05:51:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> It reflects the requirement of being a node in Fidonet, the possibility to >> accept a FTS-0001 session handshake on the transport protocol that you >> have a mailer on. > We have alredy discussed this point. If you intend to follow Policy > literally, then you must run this 'session handshake' at _phone_ line, not at >IP (see sect.2.2). And if you reject this part of Policy - why do you insist o >literally following sect.2.1.8? So, you mean that "if we don't care about this little thing, we can just dump all of it"? If policy were rewritten from "State your phone number for your node" to "State your address for your node", would the phone requirement be gone then? > After all, it requires first of all "be able t receive mail during this time > using the protocol defined in the current FidoNe Technical Standards > Committee publication", and even now there exist not only FTS-0001, but also > FTS-0006, so the reference to FTS-0001 only in Policy is out of date. It states that you have to follow FTS-0001, not FTS-0006. It does not state that you have to follow all FTSC standards, only that single one. > And it is not written somethere that all further 'protocols defined i > the FidoNet Technical Standards Committee publications' should implement >autodetection and fallback to previous protocols - but your proposal assume fo > some reason that this must be true forever. Protocols defined in FTSC does include the possibility to detect other handshake protocols. If it does not, it is no FTS. If BinkP gets submitted as a standards proposal for the FTSC, it will not be acknowledged if it does not have the possibility to detect other protocols. I don't say that BinkP protocol needs to do FTS-0001. I say that the _mailer_ needs to do FTS-0001 (BinkD in this case). > And a modificated BinkD that I run at one of my stations can use BinkP as a > transport-level protocol for FTS-0001. So include, please, BNP in the list of > IP-flags as a transport protocol in your proposal too. I can see that this is your $999999999 protocol. Where is this protocol documented? If you are the only one running it, is has got only you as a beneficient of it, and there would be no other nodes capable of using it against you. Therefor it would have no interrest to the nodelist. I know that you just want to quarrel with me on this, so I have no intention to follow it further. > They'll never do that because this is senseless. The only result that you'll >get if your proposal will be accepted will be appearence of new fake 'FTS-0001 >compliant' IP-nodes. I personally don't care if the nodes lie to their NC, or their NC lies to the RC, or the RC lies to the ZC, or the ZC lies to the IC. Either policy has to be followed, or the policy has to be changed. The easiest path for us to go, is to follow policy. > This is not a real rule of connectivity, but only an anachronism now. A lot > of nodes can not really run FTS-0001 for years, and nobody complain (as the > matter of fact very often nobody, including the sysops of this nodes, even > knows of this fact). So, if someone tries to poll a existing node (a PSTN one for that sake) with FTS-0001 only, and does not get a handshake, they can file a technical policy complaint. If a oldtimer in Fidonet gets 5 other oldtimers with him, and files 6 different policy complaints and follows them right up to the top level, if they get denied in lower niveaus of *C structure, don't you think they will have the policy on their side? Don't you think that someone acutally will try to do this against BinkP-only-nodelisted-nodes? >> If BinkD (that is used in the ex-SU) would implement a FTS-0001 >> handshake if the BinkP handshake fails, it would be compliant with >> the current requirement of Fidonet. > What for? It would be much more easy to run another software at other port >if we are fond of FTS-0001. And why should somebody have such a strange idea a > to go with FTS-0001 to BinkP port? Maybe if the don't have BinkP themselves? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1342 [1995] Scn From : Rune Johansen 2:210/20 04 Nov 97 17:58:16 To : Yuri Teterin 05 Nov 97 05:51:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Then consider BinkP-only nodes like ISDN-only nodes (or vmodem-only nodes, > if you have no vmodem) and do not try to connect with them. That is the > problem? On ISDN-only nodes, I can (if I have ISDN adapter that can run the ISDN protocol indicated) connect to a mailer, and negotiate a mailer session handshake. Same thing with for example raw TCP. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1343 [1995] Scn From : Rune Johansen 2:210/20 04 Nov 97 18:20:06 To : Lawrence Garvin 05 Nov 97 05:51:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> If you take a look at the current nodelist you'll find that many >> nodes already have multiple nodenumbers. > Only in Zone 2, Kim. :( Look at 1:203/34 and /35. Same system, same sysop, two different modems (by looking at the capabilities). > If my IP node has a different node number, you would expect the downlinks to > configure their system to toss to -one- node, and actually -send- to another? Yes. That is what is being done today, and that is what is available with AKA listing in handshake. I toss and do all things out of my 2:210/20 AKA. But, those wanting to use my ISDN line has got to poll 2:210/21. They get 2:210/20 in the AKA list, and sees that they can send mail destined for 2:210/20 there. >What if a downlink's IP connection goes down, and they decide they want to pic > up their mail from the PSTN node? different node numbers means that I need to > have different -outbound- directories -- therefore, the downlink could not > pickup mail from the PSTN node in such a case. Same thing: AKA listing. >What really would happen is that both nodes, PSTN and IP, would present -both- > node numbers all of the time, and share a single outbound directory. But if > that is the configuration, then the second node number is totally redundant, > and thus, totally unnecessary. It is not redundant, as it gives you several possibilities to connect to the nodes. Do you actually mean that listing 10 different lines (if you don't have huntgroup phonenumber) is totally unneccessesary? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1344 [1995] Scn From : Lawrence Garvin 1:106/6018 03 Nov 97 22:13:18 To : Denis McMahon 05 Nov 97 05:51:42 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Denis McMahon said in a message to Lawrence Garvin: DM> Lawrence Garvin wrote to Denis McMahon: LG> Denis, methinks you missed my point. We're talking about mailers LG> that make OUTBOUND calls. Okay? :) DM> No, we're talking about the use of IP protocols in the Fidonet DM> environment. Okay. Fine. I'll try again. -I- am talking about MAILERS that make OUTBOUND calls. If you do not wish to discuss THAT topic with me, then do not reply to this message. DM> Whether any current individual fidonet mailer can use the DM> information or not is not the issue. Then please tell me what is the point of putting INFORMATION into the nodelist that cannot be used by the software for which the nodelist was designed in the first place? DM> The whole idea of this discussion is to place data in the nodelist DM> in some agreed format so that future generation mailers can use DM> that information. Well, then, we need to get some separation in this discussion in this echo. We've got two problems we need to deal with. (1) We need to deal with the PRESENT. (2) We need to deal with the FUTURE. I'm not interested in dealing with the FUTURE until we've completed the necessary work on the PRESENT. WHEN I can get my node listed in the nodelist with an IP address or a FQDN, and I can dial an IP address or FQDN with my CURRENT SOFTWARE -- which btw, can be done -- I'm already doing it 'unofficially' -- Then, and Only Then, will I be interested in worry about capabilities for some "future generation mailer". We need communication and interconnectivity TODAY, and we do not need to spend a lot of time talking about what might be someday in the future, until we can resolve the immediate needs of today. So... if you're interested in talking about today's needs, then by all means let's continue this conversation; however, if you're only interested in talking about that "future generation mailer", then I'm not the guy you should be wasting your words on. DM> It's of no benefit whatsoever to me at the moment either, LG> Thankyou for your candor. I suggest it's of no benefit to any LG> FIDONET SYSOP at this moment, DM> I agree with this, but Then let's talk about it SOME OTHER DAY. 'K? :) DM> With this I strongly disagree. We are both arguing about how the DM> future should be shaped, however I seem to be arguing that we DM> should provide information that software developers can use to DM> increase functionality and reduce sysop costs if they want to, DM> whilst you're arguing that there's no point because the software DM> developers won't be interested. Actually I wasn't arguing that point, but I do believe it has some truth to it. In fact, it bears out an even more fundamental problem. Very few software developers are even writing -ANY- FTN software today. And, btw, if you haven't noticed, NONE of the FTN software currently in use by the majority of people is Y2K compliant. So... we DO need a whole new generation of software, and we need in in the next 24 months, or Fidonet will implode upon itself anyway -- IP connectivity or not. :( But first we need to figure out how to get that IP connectivity that is already possible in the software we do have. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1345 [1995] Scn From : Rune Johansen 2:210/20 04 Nov 97 18:35:06 To : Lawrence Garvin 05 Nov 97 05:51:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Well, first, I think this concept of a "raw socket transport" is misleading. >There must be -some- protocol that works at the network layer to accomplish th > data transportation from one system to another. Yes, there are: IP. On the transport layer: TCP. On the session layer: mailer session handshake protocol (FTS-1, EMSI, FTS-6, BinkP) >my two VModem nodes. All four nodes will identify themselves as 1:106/6018. Th > only difference between nodes 2, 3, and 4 will be that node 4 will only be > accessible on port and will only support BinkP protocols, where as > nodes 2 and 3 will be available on ports 23, 3141, and 3142 and they will > support FTS-1 connects, along with FTS-6 and EMSI. That is true. That is also why a BinkD-ONLY IP node would not meet the current requirements of todays policy in Fidonet. >But for an IP-only node, in order to accomodate the implementation of BinkD an >other BinkP-only mailers -- I think that it's not unreasonable at all to say - > if you want to get an FTS-1 session via IP, you'll have to do it on port 23. > Except that is not necessary at all! Perhaps not in Europe, but in the U.S. I > can put an analog V.34 modem -and- a V.110/V.120 ISDN modem on the SAME >telephone number. The ISDN modem senses whether the inbound call is digital or >analog, and if it's analog, it'll route it to the POTS port and the V.34 modem > will answer. If it's digital, then the ISDN modem will answer and you get a > V.110/V.120 connection. Both happen at the same telephone number, though. Can you receieve a analog call on the POTS port if your ISDN adapter is busy doing a session? >Why not? Can you not plug your PSTN modem into the POTS port on the back of th >ISDN adapter? Or is this built in to the ISDN adapter? If it is built in, then > your limitation is the fact that you have two physical devices, not that your > ISDN adapter is incapable of providing both services on the same telephone > number. I have two pysical devices, alas two different phone numbers. Also, my analog modem has capabilities that the analog part of my ISDN adapter lack. So, the capabilities are not identical, so they could not be correctly put on the same nodenumber. >> True. I'd maybe start looking at NLMake to see if it needs changes. > I see that the latest version of Fastlist now has capabilities to compile IP >numbers from a source nodelist. That's a good start -- but now what we need is > a nodelist generator that will allow IP numbers in the telephone field. As stated here, NLMake will allow it. (nlmake13.zip) > nodelist. Hopefully, though, down the road, we'll have nodelist compilers and >mailers that have support for FQDNs in one of the text fields, and then a FQDN > and PSTN-telco number can coexist on the same node number. Where should future transport networks be placed then? >And.. while we're on that subject, I think I have a new idea for how to modify > the nodelist generator software, but still provide some protections for the > telno field. All it needs to do is accept * and # in the telno field, and > remove the restrictions that the first character must be 0-9. Then, use the > octothorpe (#) as the first character of an IP address. All quasi-solutions. It will still need a modification to existing software, so why not implement a generator that accepts all chars? > Or, I could configure my nodelist compiler to strip the octothrope on all > numbers, and configure a ModemTrans parameter to use ATDT# instead of ATDT if > it identifies a VMP flag in the nodelist, otherwise the default would be to > initiate a generic telnet call on port 23. This would be the prefferred solution. >For example, again, the presence of the # as the first character could indicat > an IP address with vmp services available on port 3141. > A $ could indicate a node with binkd/binkp running on port sixty thousand > something. And % would indicate a binary, no echo, no sga telnet connection with BinkP, and Ï would.... --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1346 [1995] Scn From : Rune Johansen 2:210/20 04 Nov 97 18:36:38 To : Nick Soveiko 05 Nov 97 05:51:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >via a triplet flag :port:. i've proposed it here a few day > ago. i can email it to you if you didn't get this message. Cannot find it. Searched for you as sender, and "triplet" as keyword. Only this message showed up. Please mail at rune@bbbs.net. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1347 [1995] Scn From : Ask Bjoern Hansen 2:235/10 04 Nov 97 13:52:34 To : Ward Dossche 05 Nov 97 05:51:42 Subj : IP - Call for opinion votes ------------------------------------------------------------------------------- Hello Ward! Sunday November 02 1997 18:43, Ward Dossche wrote to All: WD> 1. Where to position the IP#/FQDN WD> 1.1 [ ] node_name field WD> 1.2 [ ] location field WD> 1.3 [ ] phone number field WD> 1.4 [ ] flag field You miss the 'in DNS' option. WD> 6. Should IP-nodes fullfill standard claims like ZMH or at least WD> clearly stated online times according to the fidonet policy? IP nodes should be CM as standard, and only anything else if it's stated by a IPTxy or similar flag. ask --- GoldED/2 3.00.Alpha4+ * Origin: I think - therefore I am confused (2:235/10) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1348 [1995] Scn From : Lawrence Garvin 1:106/6018 03 Nov 97 22:21:04 To : Denis McMahon 05 Nov 97 05:51:42 Subj : IP-access ------------------------------------------------------------------------------- Denis McMahon said in a message to Lawrence Garvin: DM> Agreed, however I was disputing the suggestion that nameserver DM> entries should be handled by the NCs, how many NCs run nameservers? LG> Who said anything about the -NC- running the nameserver? ? ? ???? DM> Ask Bjorn Hansen (I hope I spelled it right), in the message that I DM> originally replied to suggested that the nameserver should operate DM> at the net level. Yeah... so.... my question stands: Who said anything about the -NC- running the nameserver? DM> It might be the case in your part of the world that individuals can DM> afford permanently connected machines at home, or work in an DM> environment where they have control of what is visible publicly to DM> the rest of the internet rather than kept behind a firewall, DM> however in other parts of the world this may not be the case. I'm quite well aware of that, Denis. But let's be practical for a minute. If there are "parts of the world" where individuals cannot obtain a permanent, or semi-permanent, or even switched on demand, connection to the Internet, then I think it's probably insignficant whether they have a DNS server running at the net level. In fact, I daresay it'll be nigh impossible. However.... for those NETs or REGIONs that -DO- have sysops who can get permanent connectivity to the Internet... I repeat myself: LG> SOMEBODY in the -NET- or -REGION- had better be capable and LG> willing to run a nameserver if they want IP-connectivity in LG> Fidonet. DM> My domestic connectivity is purely dial-up, and my employer has a DM> firewall that I have no control over whatsoever. Then you don't need a DNS server in your net, do you. :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1349 [1995] Scn From : Rune Johansen 2:210/20 04 Nov 97 17:13:16 To : Yuri Teterin 05 Nov 97 05:51:42 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- >> To try to make IP flags coherent, I will suggest using a prefix of IP to >> all of them, like Kim suggested. IPT - Telnet, IPR - Raw TCP, IPV - Vmodem >> Protocol, IPI - Raw TCP Ifcico proprietary (?) > That is from your point of view the difference between IPR and IPI ant how >this is connected with your classification of protocols from the point of view > of transport-layer only? > ifcico have an optimized protocol indeed, but this is a session-layer >protocol, that can be used both over IPR and over IPT. It is turned on by mean > of an (unregistered) EMSI prot code TCP. Aha, now I know that. It means that the optimized protocol of Ifcico is not a session handshake protocol, but a file transfer protocol used inside EMSI. I will withdraw my suggestion for IPI, as it would be negotiated inside the EMSI packet. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1350 [1995] Scn From : Rune Johansen 2:210/20 04 Nov 97 18:09:40 To : Pablo Saratxaga 05 Nov 97 05:51:42 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- >> True. So, a BinkP flag would also not be useful, if EMSI is not. > The fact is that: > "BinkP" is enough to describe how to connect to a node. > "IFC" is enough to describe how to connect to a node. > "Telnet" + port number is enough to describe how to connect to a node. Today, these are enough, yes. Maybe not tomorrow. >Those three aren't equivalent, for exemple BinkP describes a handshaking while >the two other not, but in practice the two others only use EMSI (there are eve That BinkP flag describes current BinkD implementation, using a TCP connection to a port, and handshaking with the BinkP protocol. > mailers compatible whith IFC raw TCP method that can do only EMSI). > So even if they aren't equivalent the fact is that they fully describe how to > connect to a node, whithout any need for additional info. > And also the fact is that using "RAW" + "handshake method" isn't enough, > as there can be several implementations of "RAW" What are these different implementations of a "raw" TCP connection? > Then the need for the four flags BINKP, IFC, TELNET and VMP (or whatever they > will finally be called) nothing more nothing less. There is need for 3 flags: Telnet (IPT), TCP connection (IPR) and VModem (IPV). To accomodate for nodes refusing to do FTS-0001 we would need additional handshake protocols within those three transport mechanisms. All three are assumed over IP. See Yuri's suggestion on the triplet flag. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1351 [1995] Scn From : Rune Johansen 2:210/20 04 Nov 97 18:11:20 To : Marco d'Itri 05 Nov 97 05:51:42 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- >> Also true. Then a IP-based mailer could trigger in the first two chars, and >> select the transport on the third (and beyond). I will restructure to > I don't like that. By changing all flag names you will confuse users. > I don't we need to save those three bytes. Some uses VMP, some uses VMO, some uses TCP, some uses IFC, some uses TEL, some uses TELN. By introducing these unique flags, some order might be accomodated. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1352 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 05 Nov 97 09:05:16 To : Rune Johansen Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Rune! On 04 Nov 97 wrote Rune Johansen to Nick Soveiko: RJ> Let's say that we have a intermediate solution to the problem with RJ> getting IP into the nodelist. Let's say that we include IP address in RJ> the system name field, Which would allow ip-connectivity in a combined entry beside pstn connectivity, as long as the online matches. RJ> and we get the ZC's to adapt several new user flags. Hmm, why only "user" flags? RJ> Yes, we have got communication in the nodelist, on a temporary RJ> basis. Which is based on the existing nodelist format without changing anything, except at the nodes, where this additional information for ip-access (at this moment) is needed. RJ> But, it's of absolutely no use on a permanent basis. At least one additional medium (ip) can be used on a very short term within the existing nodelist format, while another extended one, which takes care of more different services (X.25, X.400, X.500, etc.), will take quite some time, before it is supported on public scale. As the extended format proposal exists, it should be possible to use it within a year or two, if the required programs get spread. RJ> Or, do you want the nodelist to become a patchwork of temporary RJ> fixes? Do you call the addition of new flags like V32B, V34, ISDNx (and its successors) just temporary patchwork? IP-flags are of the same kind, beside the additional address. If the flag space wasn't so limited, i could support an address flag in place of node_name. It still shows another additional connectivity, added to conventional pstn-usage. The rule of universal direct access was clearly broken at that moment, when the first ISDN-only node arised in the nodelist, but on base of Bell-103/V.22 it never existed. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1353 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 05 Nov 97 09:12:00 To : Ask Bjoern Hansen Subj : IP - Call for opinion votes ------------------------------------------------------------------------------- Hello Ask! On 04 Nov 97 wrote Ask Bjoern Hansen to Ward Dossche: AH> Hello Ward! AH> Sunday November 02 1997 18:43, Ward Dossche wrote to All: WD>> 1. Where to position the IP#/FQDN WD>> 1.1 [ ] node_name field WD>> 1.2 [ ] location field WD>> 1.3 [ ] phone number field WD>> 1.4 [ ] flag field AH> You miss the 'in DNS' option. The pure DNS-solution (i.e. ...fidonet.org) works completely independant from the nodelist and does not give any advice of direct connectivity to a ftn-mailer. WD>> 6. Should IP-nodes fullfill standard claims like ZMH or at least WD>> clearly stated online times according to the fidonet policy? AH> IP nodes should be CM as standard, and only anything else if it's AH> stated by a IPTxy or similar flag. This might be ZMH-only too, i assume? Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1354 [1995] Scn From : Dieter Ringhofer 2:2476/14 05 Nov 97 18:07:32 To : Amir Shabashvili 05 Nov 97 21:29:40 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> there should be a mandatory standard to ensure connectivity or we can DR>> get rid of every ftn. the least common dominator in fidonet is DR>> fts-0001, that's reality. AS> FTS-0001 is more political thing (keep in mind it's place in Policy) then AS> real appropriate technical standart. FTS0001 too bad not for IP only, but AS> for PSTN connection also. I remember most connections of my system at last AS> 5 years with FTS001 was failed, and now you wish we must see that on IP? i can't agree to your statement because the seldom occurences of the need to use fts-0001 it worked and i was happy to be able to have it. as long as the major rule states the necessity to have it available it's more than a political question, it's a question of wether changing the rule or not to be a member of fidonet. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1355 [1995] Scn From : Pedro Lima 2:362/21 04 Nov 97 05:02:22 To : Lech Szychowski 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- LS> I want to be able to establish a session with any given one. "Abandon hope all ye enter here" Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1356 [1995] Scn From : Nick Soveiko 2:5030/69.101 03 Nov 97 18:02:08 To : Dieter Ringhofer 05 Nov 97 21:33:42 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Sun, 02 Nov 1997, 08:22, Dieter Ringhofer (2:2476/14) ==> Nick Soveiko: NS> A stream of data sent on a TCP connection is delivered reliably and in NS> order at the destination. DR> what about datagram oriented services? like? NS> An acknowledgment by TCP does not guarantee that the data has been NS> delivered to the end user, but only that the receiving TCP has taken NS> the responsibility to do so. DR> ! don't forget this. oh, yeah. the data should be successfully passed from the transport layer upstream. if your tcp/ip stack dumps the data to /dev/nul, shure it's unreliable like hell. DR> i say that some of underlaying protocols (remember: tcp is layer 4) DR> don't take care about some issues mentioned. this can cause (and DR> causes sometimes) loss of data or defect transmission. they take care about their own issues. tcp takes care about reliable connection between sockets. our mailers speak to sockets, not to the underlaying protocols. NS> did the protocol you've been using have autoresume? DR> i tried it with conventional tcp/ip services as well as via vmodem. DR> the link has been unreliable everytimes. unreliable you mean frequently dropped connection, right? DR>> see documentation of tcp/ip development kit from IBM as an example DR>> of explanation, please, it's written by native english speaking DR>> persons. most propably lack of knowledge of english language is on DR>> my side ;) NS> url? DR> no url except a password protected one at IBM, it's a commercial DR> product. then it's incorrect to refer to material that's not available to the public. post here a small quote that will elaborate your point of view. NS> what you claim. and i highly doubt than a tcp/ip stack from ibm would NS> be not rfc-793 compliant. DR> they are, but they know about the problems ;) i still have to hear about the problem(s). cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1357 [1995] Scn From : Dima Maloff 2:5047/13 04 Nov 97 13:50:00 To : Lech Szychowski 05 Nov 97 21:33:42 Subj : BinkD (0.9.2) specification ------------------------------------------------------------------------------- Saturday November 01 1997 14:46, Lech Szychowski wrote to Pablo Saratxaga: >> Then nodes whith common protocols can poll each other. imposing a >> standard now will de facto create less connectivity than before. LS> Perhaps for a while, yes. But just for a while. Do you really think that xmodem (which is used for file transfers per FTS-1) can be popular among IP sysops? Do you know that xmodem has a fixed-sized window (the size is 1)? That means that you'll have to wait RTT to get ACK for every sent packet. As xmodem has fixed size packets (about 128 bytes, AFAIR) it's extremly slow. LS> From my personal point of view it is acceptable. But it breaks the old LS> Fidonet rule of defining standards common to everyone and ensuring total LS> connectivity - and that frightens me a bit. I hate to repeat myself, but binkp DOES provide a better connectivity. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1358 [1995] Scn From : Nick Soveiko 2:5030/69.101 03 Nov 97 17:55:30 To : Lawrence Garvin 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sat, 01 Nov 1997, 18:32, Lawrence Garvin (1:106/6018) ==> Nick Soveiko: NS> presentation too vague to give examples NS> application e.g. mime, *.pkt, html, bink-style outbound NS> session e.g. ftp, http, smtp, pop3, binkp, emsi NS> transport e.g. tcp, udp NS> network e.g. ip, ipx/spx, ftn nodelist NS> datalink e.g. hdlc, xmodem, zmodem NS> physical e.g. v.34, g.703/g.704 LG> I question whether v.34, et.al are actually a physical link layer. yes it is. a physical layer is the one that's responsible for actually transferring bits over a physical medium. LG> The physical link layer in a PSTN system is actually hidden from LG> the user, and is managed by the telco switching equipment. Arguably LG> so is the datalink layer. v.34 actually moves bits over a pair of wire. the fact that somewhere is't being incapsulated into pcm and telco switching protocols doesn't sacrifice this fact. LG> I truly believe that modem communications protocols belong in the LG> network layer along with ip and ipx. nope. modem communication protocols are either physical layer (v.32, v.34, etc.) or datalink layer (v.42, v.42bis). LG> Incidentally, SPX is a transport layer protocol, just like TCP and LG> UDP. ok, i won't argue in this one while drifting way off topic here. at least, we've agreed on the basic terminology ;) cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1359 [1995] Scn From : Nick Soveiko 2:5030/69.101 03 Nov 97 17:56:14 To : Dieter Ringhofer 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sun, 02 Nov 1997, 10:50, Dieter Ringhofer (2:2476/14) ==> Nick Soveiko: DR> if you try to look at pstn and ip as a medium only it's not the DR> question how you access it. the question is the protocol being used DR> between 'caller' and 'called' system. both are the questions. DR> compare it with german and russian language: DR> we can talk together, each of us using his native language. as long DR> as there's a medium carrying the waves to the ear of the other one, DR> we can listen and talk. this does not mean that we understand what DR> the other one is talking. yeah, so it's useless for anything but shaking the air. DR> to achieve this we have to use a common language. DR> that's what we are discussing here: usage of another medium. DR> i'm in favour of it if it helps to improve something but we still DR> must have a common 'language' (read: handshake). this language quite well can be different for every given media. taking the slippery path of analogies, i'd say that imposing fts-0001 for tcp/ip connections now is the same as imposing latin as an official fidonet language. its time has gone. DR> i talked about this issue f.e. with Scott Dudley in june (he's a DR> canadian but currently living and working in u.s.). he has been DR> very surprised when he realized the cost scheme for telephone and DR> internet being in use in germany. his comment: much more expensive, DR> no real chance to become a common carrier at these prices. he is a DR> trustworthy person for me who has a lot of knowledge in DR> communication technologies and how to use it. i believe what he DR> told about situation on the other side of the pond and his DR> informations are 'first hand'. with my full respect to scott, he simply might be not aware of all bits and pieces of the game. i tell you: z1 is big and there are different telco pricing schemes. i sincerely doubt scott knows them all. i am myself is living in canada now (despite my 2:5030 address) and i am a telecom engineer. you can check telecom digest archives (http://www.telecom-digest.org) on this matter if you don't believe me. NS> i could argue that direct connect between any given pair of NS> fidonet nodes is not always possible over pstn too. so? is fidonet NS> *already* dead? DR> in parts, it is. see isdn-only systems, missing ic, ... i don't see any logical link again. would zcs miraculously throw out their disagreements and elect an ic if isdn nodes are out of nodelist? DR> a 'full account' at an isp without fixed ip-number and without own DR> domain takes DM 30.- (or 35) per month at the cheapest isp over DR> here for privat (personal) use. it does not include full featured DR> daemon configuration capability for personal adaption according DR> special needs, no directory at isp's server for continuous access DR> from all over the world, ... your unix shell account need not to be at your local isp. it can be anywhere in the world, with the current prices going at about $80/year. that works out to about 10 dm per month. that means: for a dialup cm capability you have to buy a second phone line and a second modem/isdn adapter, which works out to around 200 marks down and 44 marks/mo. right? for tcp/ip cm capability you buy ip access prom your local provider (35 marks/mo) and shell account in, e.g. california (10 marks/mo). and you use your existing phone line/modem to dialin a few times a day and pick up your mail. your monthly expences are approx the same, your installation expences are less for ip and you pay *no long distance* toll. will you still argue that tcp/ip is more expensive for you? DR> when one wants to have a domain it takes several hundred DM to get DR> it, it's additionally charged in dependancy of volume being DR> transferred (commercial account). you can be listed in fidonet.net domain right now and at no charges for you. NS> i assume that having a fidonode you already have a phoneline and NS> a modem. DR> if this line is in use i need to have another one for ip activities DR> as well as additional equipment. you don't have to maintain 24/7 connectivity from your home. a daemon runs on your shell account and receives mail for you. you pick it up a few times a day, at the time that's convenient for you. DR> we have another scheme which is based on defined length of a 'unit' DR> in dependancy of distance, daytime, etc (typically complicated like DR> every german ruling). f.e. calling somebody in u.s. charges with DR> price of one unit every seven seconds normally. this doesn't change the whole idea. NS> (1) is the same in both cases. (2) is obviously lower than (3), i've NS> given some examples here last week. even if you don't pay (1) when you NS> access long distance carrier, (1)+(2) will work out cheaper than (3). DR> not everytimes. if process to transfer something via an isp takes DR> more than the time of one 'cost unit' a simple crashmail being DR> transferred within one unit is cheaper and one knows that it's at DR> recipiant's system. that's again a rather rare case when dialup crashmail falls slightly below one 'cost unit' and sending it over the ip falls into more. from my side it works out quite different: i pay 1.5 times normal charges for the first minute of connection. so, a 1 min crashmail to germany would cost me ~1.50 bucks, for which i can buy 3 hours of online ip. NS>> but enforcing fts-0001 support for ip-only systems is not going to NS>> improve the situation in any way as they still won't be able to NS>> connect directly to pstn-only systems! DR>> for being the most common dominator i don't see a way DR>> around. NS> i still don't see any logical sequence here. DR> the 'club' decided that every member accepts incoming calls using DR> this handshake. so, if i want to be a member of the club, i've to DR> do the same. at the very first moment it's of no interest what i'm DR> using additionally. dieter, i start wondering if you're practicing zen here... this decision of the 'club' doesn't even specify the basic physical protocol. it means that two systems might be having perfectly matching handshake, but they have *no chances* to connect to each other. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1360 [1995] Scn From : Slava Filimonov 2:469/33 04 Nov 97 14:13:34 To : Lawrence Garvin 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Lawrence! 01 Nov 97 18:32, Lawrence Garvin wrote to Nick Soveiko: NS>> presentation too vague to give examples LG> I question whether v.34, et.al are actually a physical link layer. This is just unimportrant things. The main thing was about FTS-001, which try to cover all of the layers. You just can't see the forest behind trees. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1361 [1995] Scn From : Nick Soveiko 2:5030/69.101 03 Nov 97 17:54:28 To : Lawrence Garvin 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sat, 01 Nov 1997, 18:27, Lawrence Garvin (1:106/6018) ==> Nick Soveiko: LG> My whole purpose was to establish the fact that there was a LG> significant difference between the 'protocols' that are mandated by LG> Fidonet Policy (essentially the session protocols) and the ones LG> that Fidonet don't care about, but does document in the nodelist LG> (essentially transport protocols). i wish the policy didn't mandate too much, but it refers to fts-0001, and fts-0001 claims to cover every layer but the physical one. LG> Actually it doesn't Nick. Randy explicitly discounts issues of LG> physical transport layers from FTS-0001. and as a result we are left without definiton of the physical layer which immediately renders potential of total lack of connectivity between fidonet nodes. LG> I believe that was designed to specifically provide for LG> connectivity over something other than the PSTN. To that we should LG> be grateful to Randy for his vision. i understand that he probably did his best back in the 80s. but now we're stuck with a document that has very little to do with realities. now to change anything we have to change everything. LG> (2) Improperly references the document entitled FTS-0001 as the LG> minimum protocol standard. unfortunately :( cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1362 [1995] Scn From : Nick Soveiko 2:5030/69.101 03 Nov 97 16:34:22 To : Rune Johansen 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sun, 02 Nov 1997, 13:14, Rune Johansen (2:210/20) ==> Nick Soveiko: >> Specs should also allow for "junk" before finding the BinkP >> protocol chars, to allow for autosensing when calling another >> system. Just a way of being leniant on what is on the other end. >> "Be leniant in what you accept, and strict in what you send" is a >> good, old jungleword used by successfull software developers all >> over the world. >specs do allow junk. but for autodetect instead of just discard it, >you analyze it. think about such analisys as a pipe to the trashcan >;). no contradiction. RJ> OK, they might allow for it, but BinkD does not use it. yep. because binkd operates in the environment where multiplexing different protocols on the same port makes no sense. so binkd ignores everything that's not a proper binkp frame. at least, that's my understanding of how it works. RJ> Example: My RJ> mailer listens to a raw TCP port. It detects a incoming session. My RJ> mailer shows a banner, sends EMSI inits, and a BinkP init. All in RJ> the same packet. what do you mean by 'packet' here? RJ> Current BinkD does not see the BinkP init, and times out. dunno. never tried this. talk to max masiutin (max@ritlabs.com) on how this is done in argus. it works for sure, as i'm connecting with binkd to argus several times a day and never had a handshake timeout problem. i would be most happy to document it then. RJ> If BinkD (the most commonly used BinkP mailer around RJ> today) would scan the incoming packets for BinkP, I could run this RJ> solution, with only one port accomodating BinkD, Ifcico, BBBS, etc. RJ> etc. over raw TCP. no, seriously, are you running out of tcp ports? i can borrow you some ;) cheers, nick --- Handwritten * Origin: <-<-<- Houses of the hairy (Overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1363 [1995] Scn From : Nick Soveiko 2:5030/69.101 03 Nov 97 18:05:46 To : Rune Johansen 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sun, 02 Nov 1997, 13:16, Rune Johansen (2:210/20) ==> Nick Soveiko: RJ> So, you exclude the possibility of what a particular piece of RJ> software can do in the future? Do you only look at what's available RJ> today, and say "That's how it is, and will ever be!"? i don't exclude *any* possibility in the future, i am just saying that it's kind of premature to consider any possibility as a minimal requirement while this possibility is not widely available yet. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1364 [1995] Scn From : Nick Soveiko 2:5030/23.101 03 Nov 97 18:10:34 To : Rune Johansen 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sun, 02 Nov 1997, 13:25, Rune Johansen (2:210/20) ==> Nick Soveiko: >> Then we should list EMSI and FTS-6 and FTS-1 too. BinkP is a >> handshake alongside those mentioned. If it is to get a special flag >> in the nodelist, so should the others too. > so? what's the problem? list session level protocols alongside with > transport and port and make default the same as majority supports. RJ> How should majority be counted? approximately ;) by default i don't mean mandatory capability, but the capability which mailer assumes if it's not explicitly listed in the field. so it doesn't make much difference what capability to accept as default, as long as it can be identified in a unique way. RJ> Today in Fidonet, I believe (I RJ> don't have any numbers though) that the majority of nodes support RJ> EMSI. The majority of nodes I have connected to over the internet RJ> via telnet transport protocol supports EMSI. Before BinkD was known RJ> outside ex-SU, the majority of raw TCP nodes supported EMSI too. fine, then let's put default == 1YE. i.e. no session level protocol listed - read emsi with fallback to yoohoo and further down to fts-1. but please, allow flexibility and room for expansion! otherwise we could be stuck with the same problem as we do today with p4/fts-1. RJ> I agree with Lawrence when it comes to what we have to present to RJ> the rest of the Fidonet community. We want to have alternate RJ> transport mechanisms in the nodelist (namely telnet, raw socket, RJ> Vmodem and Ifcico). But then also say that "we won't do FTS-1" RJ> would be outrageus. outrageous is to require fts-1 *everywhere*. especially over tcp/ip. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1365 [1995] Scn From : Nick Soveiko 2:5030/23.101 03 Nov 97 18:08:30 To : Kim Heino 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sun, 02 Nov 1997, 12:07, Kim Heino (2:222/0) ==> Lawrence Garvin: > how does one deal with the desire to have the -same- node number on both > the PSTN node and the IP node? KH> Is that really needed? it would be quite advantageous to do so. KH> If you take a look at the current nodelist you'll find that many KH> nodes already have multiple nodenumbers. For example I have 4 KH> (plus two administrative) nodenumbers because I have 4 KH> phonenumbers. With IP the situation is the same, you have KH> two addresses, PSTN and IP, and therefore you should have two KH> nodenumbers. your case isn't that bad as all your nodenumbers have more or less the same capability (pstn). but if a system lists different capabilities (i.e. pstn, isdn, ip) under different nodenumbers, there's no general way for the software to identify these nodenumbers as referring to the same 'physical' system. so, the software can't automatically choose the most convenient transport to deliver mail to such system. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1366 [1995] Scn From : Dima Maloff 2:5047/13 04 Nov 97 20:11:00 To : Dieter Ringhofer 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sunday November 02 1997 10:01, Dieter Ringhofer wrote to Dima Maloff: DR> where's the problem with being compliant to the rest of the fido-world to DR> offer ftn-fallback even via ip? It's time to get rid of FTS-1 (as reproducing it again and again just wastes people's time), at least for IP nodes. Less code -- less bugs. DM>> 30.000+ will have to change something to use IP anyway. DR> no, there's absolutely no need for it. check available software (not only DR> binkd) and you must agree. we have the chance to use improved things but, DR> there's no need for it to get functionality. watch this little difference, DR> please! Well, they'll have to add either vmodem or binkd. What's the difference? DM>> And listen, after all, we do not want for BINKP to be a mandatory DM>> standard. We just hate to be forced to add vmodem. DR> there should be a mandatory standard to ensure connectivity or we can get DR> rid of every ftn. the least common dominator in fidonet is fts-0001, DR> that's reality. skipping it makes things more worse than they are in DR> between. think about what you want and accept needed things. Why do you need FTS-1 on IP node if you'll not able to connect a PSTN node anyway? DR>>> Maybe this leads to an understandable example for you: DR>>> How does Binkd react when a password error occures (caused by a DR>>> typo)? DM>> Reports a error. DR> will bundles be transferred and accepted than? Of course, no. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1367 [1995] Scn From : Dima Maloff 2:5047/13 04 Nov 97 20:15:00 To : Dieter Ringhofer 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sunday November 02 1997 11:06, Dieter Ringhofer wrote to Dima Maloff: DR> i already have it since longer time than binkp exists ;) You have. But thouse 30,000-no-yet-IP-connected do not. And wait, where did thouse vmodem drivers of x-SU sysops gone?.. :) DM>> Moreover, even if you'll use a Vmodem-like to run your old DM>> Fido-software, you'll have to run, say, 3 mailers to accept 3 DM>> concurrent inbound connections. Unlike Binkd or Argus (they start new DR> that's somewhat wrong because it's a question of implementation and DR> secure functionality. you forgot to mention Adept where every line is DR> a thread only ;) Sure. But as long as vmodem emulates COM-ports we will need separate mailers for each line. And when you are out of virtual COMs remote will get BUSYs. Not good. DR> the problem with such solutions is total loss of connectivity if ONE DR> process (task) is interrupted or (much more worse) 'hanging' in some way. DR> running several processes with the same program increases secure DR> functionality, /skipped/ I've talked about that starting a mailer only for a time while an incoming connection is active and closing it when the connection ends (like inetd does with most UNIX daemons) is impossible with vmodem drivers for OS/2 and NT. (But being reliable is not a problem for binkd at all, even for Binkd versions compiled to use threads, not processes. The biggest problem for Binkd -- bugs of OSs' TCP/IP stacks *sigh*) DR> if i try to connect at a FD or Xenia system and there's a typo at password DR> setup those frontends kick connection ASAP. without fts-0001 i have no DR> chance to ask the sysop of the other system why such reaction occured with DR> a crashmail. in such cases it's still in use and needed. f.e. with DR> Cantaloup there's no real need for it, it puts received packets into DR> insecure inbound and doesn't send anything in such sessions when being DR> called resp. does a password overwrite at an outgoing call and sends only DR> bundles for the aka being the called one. With binkd you can use some "test", unprotected address for this. Say, 2:your_net/999. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1368 [1995] Scn From : Nick Soveiko 2:5030/69.101 03 Nov 97 18:03:06 To : Kim Heino 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sun, 02 Nov 1997, 14:55, Kim Heino (2:222/0) ==> Nick Soveiko: KH> Let's consider a node that runs FrontDoor and BBS behind it. He KH> propably wants to allow telnet users into his BBS, so he gets com KH> port emulator. no fidonet member is required to run a bbs. they are required to be able to 'observe mail events'. so if you'd like to run a bbs that can run on com ports only, you have to get get a com port emulator. KH> Now you are saying that he should install yet another mailer KH> (BinkD), which won't even support his current system (FD)? if his system already has fd which receives mail during zmh according to fts-0001, he doesn't have to do anything else. however, if it does not, then he'll have to do something anyway. to *receive* mail using binkd you don't even have to have the same outbound. to send mail from arcmail attach outbound, you'll need scripts to convert ama bundles into bso. patrice boucher has done it. >> Specs should also allow for "junk" before finding the BinkP >> protocol chars, > specs do allow junk. KH> So, BinkD violates BinkP specs? afaik, binkd discards junk. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1369 [1995] Scn From : Dima Maloff 2:5047/13 04 Nov 97 20:00:00 To : Lech Szychowski 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Monday November 03 1997 01:23, Lech Szychowski wrote to Dima Maloff: LS> I'm not trying to say there is just a few binkp-capable nodes out LS> there> I'm just trying to make us realize that unless we adopt some LS> common standard protocol total connectivity is most likely pure LS> fiction; although 83.3% is a vast majority by any standards, it is LS> nowhere near total connectivity. LS> I don't want to be able to connect to eighty something percent of IP LS> nodes - I want to be able to establish a session with any given one. You can route you mail. But if we even REALLY needed a standard, why not binkp? Only a small number of nodes will have to change something then and thouse changes will be free for them. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1370 [1995] Scn From : Sean Rima 2:252/356 04 Nov 97 09:06:36 To : Rune Johansen 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen wrote in a message to Nick Soveiko: > btw, where can i check out this bbbs thing? RJ> www.bbbs.net RJ> Beware: BinkP capability and raw TCP capability is not in the RJ> version lying there. It's in alphatest only. So, another mailer/BBS adds BinkP to the list. Does it also use BinkP as a telephone protocol. Later, Sean DSP BBS & IPmailer Ipmailer alice.pcug.co.uk BinKD Mailer --- timEd/386 1.10 * Origin: DSP BBS Reading Berks {0118 961 4636} (2:252/356) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1371 [1995] Scn From : Sean Rima 2:252/356 04 Nov 97 09:08:06 To : Nick Soveiko 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Nick Soveiko wrote in a message to Lech Szychowski: > problem I would see with it, is if I get a non-error-correcting connect > with the other side. That way I could be in serious trouble. But, BinkP > assumes error-free connection, so I'll have to see what I can do on the > modem side. LS> IHMO if BinkP can't handle "no-error-correction-by-modem" LS> situation, it should let the other side know about it and LS> disconnect ASAP, to save money. NS> argus handles this arrangement (binkp-over-modem) by using a NS> proprietary error correction protocol that runs under binkp and NS> provides reliable mailer-to-mailer connection (smth like sockets NS> afaiu). i have no windows machines around me so i can't set it up NS> and explore further. maybe max masiutin can educate us more on NS> this? I have a couple of nodes and points that use Argus with the BinkP protocol over telephone and they (as well as I) think it is great. way better than EMSI handshaking and faster too. Later, Sean --- timEd/386 1.10 * Origin: DSP BBS Reading Berks {0118 961 4636} (2:252/356) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1372 [1995] Scn From : Slava Filimonov 2:469/33 04 Nov 97 12:53:46 To : Rune Johansen 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Rune! 30 Oct 97 19:34, Rune Johansen wrote to Slava Filimonov: RJ> For those people not having your automobiles on your highway, why RJ> would you not build a small horsetrail on the side, so they can use it RJ> until they get a automobile? If a horsetrail is the current minimum on RJ> a road today, why should the highway refuse to have it? It won't RJ> hinder any of the automobiles already running there. It enhances the RJ> possibility of people getting on your highway. Use phone lines as 'horsetrail', ok ? I wonder, why in real world there is no at all horsetrails along highway ;) Same reason - we still using horses only for a short distance and where no other motor roads exists. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1373 [1995] Scn From : Slava Filimonov 2:469/33 04 Nov 97 13:53:22 To : Dieter Ringhofer 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dieter! 30 Oct 97 19:10, Dieter Ringhofer wrote to Dima Maloff: DM>> Why not to skip ZMH? DR> because it's the onliest time at which a fidonode has a real chance to DR> connect any other one (if it's not a isdn-only counterpart :( ). If we relay only on direct node2node connection - sure. But we have to use years prooved technique - backup Mail Exchangers or MXs. But for this we have to skip ( or leave for backward compatibility ) nodelist in favor of DNS for ip-fido nodes. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1374 [1995] Scn From : Slava Filimonov 2:469/33 04 Nov 97 13:59:28 To : Pablo Saratxaga 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Pablo! 29 Oct 97 02:34, Pablo Saratxaga wrote to Slava Filimonov: SF>> We're talking about ip-connectivity isn't it ? As long as you use SF>> BINK-style outboud, you can keep your old phone mailer and add SF>> binkd mailer to exchange fido over ip. PS> BTW is there any TCP/IP able mailer that uses otherthing than a PS> binkley compatible in/outbound tree ? I know of none. It seems to me, that new T-Mail will do ip. (t-mail have it's own outbound style, but derived from bink'o'style ). We're talking 'bout binkley outbound, because it's simple and multisession/network-aware and can be shared among mailer, tosser, editor in of different types. Do you able to name another one having such fetures ? -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1375 [1995] Scn From : Slava Filimonov 2:469/33 04 Nov 97 14:03:36 To : Pablo Saratxaga 05 Nov 97 21:33:42 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Pablo! 29 Oct 97 03:03, Pablo Saratxaga wrote to Amir Shabashvili: AS>> The better way, IMHO, is got all info about protocol,... from DNS AS>> requests, PS> No, because there aren't standard libraries to request any DNS funny PS> field, get one from *unix* resolver or nslookup and make your own library. Or take it from sendmail source code. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1376 [1995] Scn From : Dima Maloff 2:5047/13 04 Nov 97 14:00:00 To : Rune Johansen 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Saturday November 01 1997 04:14, Rune Johansen wrote to Yuri Teterin: RJ> It reflects the requirement of being a node in Fidonet, the possibility to RJ> accept a FTS-0001 session handshake on the transport protocol that you RJ> have a mailer on. As per Policy4, you must have a telephone line first of all! >> So your proposal will actualy cut all BinkP-based part of FIDO and leave >> it out of nodelist. RJ> It will cut all current BinkD 0.9.1-only IP-only nodes, until it has RJ> implemented a fallback routine to the required minimum session handshake RJ> protocol in Fidonet. Sorry if I get you wrong, but understanding that 1) an IP-only node either w/FTS-1 or w/binkp is equally illegal per Policy; 2) binkp is technically better, as it made most x-SU sysops move to it from vmodem-likes; 3) a node to have an IP connectivity should add either vmodem or binkd, so "there are 30,000 FTS-1 installations" thesis cannot be used; 4) no one will use FTS-1 even if it's implemented in binkd I can interpret forcing of binkp-only sysops to support FTS-1 only one way -- authours and/or users of commercial software make problems for users/authours of free software (To increase their "market share" politically?) Not fair. RJ> That is completely true. But, by ex-SU sysops only using BinkD, they fail RJ> to adhere to the basic rule of connectivity in Fidonet, namely the Again -- the basic rule of connectivity in today's Fidonet is having of a telephone line. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1377 [1995] Scn From : Dima Maloff 2:5047/13 04 Nov 97 19:58:00 To : Lech Szychowski 05 Nov 97 21:33:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Monday November 03 1997 01:14, Lech Szychowski wrote to Dima Maloff: >>>> If having binkp support is enough a) to be compatible; b) to be fast; >>>> c) to be effective, why not allow binkp only nodes? >> LS> If all these conditions are met, there is no reason not to allow >> LS> them - "compatible" being the main keyword here. >> Dare you to say that binkp nodes are a minority? LS> No, why? Is there anything in the above quote that implies they are? :) ""Compatible" being the main keyword". "Be compatible" for a protocol means "to be in the majority", isn't it? --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1378 [1995] Scn From : Pablo Saratxaga 2:293/2219 04 Nov 97 03:43:48 To : Rune Johansen 05 Nov 97 21:33:44 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Sat, 01 Nov 97 04:02:36 +0100, Rune Johansen said: >> Let's not be ridiculous twice - we can use _another_ port for FTS-* and >> BinkP on it's own in single program/daemon. Why all of you stuck on word RJ> And how do you suggest that it should be indicated in a nodelist? Just like nodes whith both POTS and ISDN do: list both flags ! Is that easy. RJ> That's because if you have only one port available for a RJ> IP-only node There are 65535 ports, there should be at least 60,000 free ports on any server, so the case of 'only one port available' is only a theorical case which will never happen :) RJ> Today that required protocol is FTS-0001. Well, write a universal, multiplatform and multi OS implementation of fts-0001 over IP. Then it will be used. Today such thing does not exist. You can't force someone to use something that doesn't even exist !! So Policy-4 may well tell whatever it wants "minimum fts-0001 over IP" can't be done now. period. You have several options now: 1) decide that fido over IP should be forbidden until the common fts-0001 is created. 2) decide that we should use the existent protocols and fullfill P4 when the common fts-0001 is created in the future. 3) decide that fts-0001 is totally pointless for non-phone medium and drop it for fido over IP. My choice is 3. I can if really necessary admit 2. But I strongly refuse 1. RJ> Do you see the difference between the raw TCP and the BinkP? One is the RJ> connection type, the other is the session handshake. Anyway the mailers have to be rewritten in order to support either raw TCP or binkP. So why focuss the efforts on the worst solution ? We have currently no common protocol. We have to decide on one. On that choice will depend a lot the future of fidonet I think. What is more important, what is wrote on a more than 10 years old document, or the survival of fidonet on the long term ? -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1379 [1995] Scn From : Pablo Saratxaga 2:293/2219 04 Nov 97 03:13:50 To : Sean Rima 05 Nov 97 21:33:44 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Sat, 01 Nov 97 09:08:00 +0100, Sean Rima said: SR>>> Just a curious question. How many IFCICO mailers are there live SR>>> on the Net. I am curious. SR> The reason I asked is that I am thinking about running a IFCICO mailer as SR> well beside my BinkD so that I can offer much more. So, do it. In fact the reason I was looking for a way to implement binkp inside of ifcico instead of simply running binkd (what I'll do in the meantime) is to be able to use one single config file. SR> But yes, I agree, a standard SR> format would be great. What is needed is to define the flags, but no standadr should be imposed to anyone. In phone transport common standards are a very important point, as that is the glue of fidonet. But for IP transport that hasn't to be the case, it is a secondary and optional transport, if you really want to crash a given node you can do it by phone; but imposing standards on IP connectivity will have a very bad impact: several people won't declare heir IP capabilities only to get ride of all that hassle (remember most people run nodes to be kind whith others and provide them mail and areas; what is the point whith all that buraucracy ?). Only when IP connectivity could be considered as the primary transport whith lots of IP only nodes we will need to decrete a standard and mandatory protocol. But that is not for tomorrow, but for several years from now, and by that time it is much probable that a de facto standard will be widely in use. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1380 [1995] Scn From : Pablo Saratxaga 2:293/2219 04 Nov 97 03:26:34 To : Lech Szychowski 05 Nov 97 21:33:44 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Mon, 03 Nov 97 01:23:00 +0100, Lech Szychowski said: LS> I don't want to be able to connect to eighty something percent of IP LS> nodes - I want to be able to establish a session with any given one. Simple: * get a copy of a binkp able mailer (free) * get a copy of a VMP able mailer (if you can >:-> not free) * get a copy of telnet able mailer (free at least on unix) * get a copy of an IFC able mailer (free at least on unix) Now you can connect whith any give node, it is as simple as that ! I really don't see why all that problems about connectivity. Even better, most of the nodes allow two or three different protocols, so there is really no problem. Unless maybe you want to connect to a vmodem only node and you don't run OS/2, you are out of luck. But that isn't a reason to ban vmodem only nodes, I think they will slowly migrate to more common protocols. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1381 [1995] Scn From : Pablo Saratxaga 2:293/2219 04 Nov 97 03:01:54 To : Rune Johansen 05 Nov 97 21:33:44 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Sat, 01 Nov 97 03:50:40 +0100, Rune Johansen said: RJ> Oh? So, if I use a FOSSIL-able telnet daemon, giving my mailer a RING when RJ> a incoming connection is being made is not internet-able? No. The programs still think the yuse a modem, the yhave no idea of tcp/ip, thay can hardly be called internet-able. There also exist programs that encapsulate IPX paquets on TCP/IP ones. That doesn't mean an IPX-only program is TCP/IP-able. There also exist emulators for the MacOS allowing to run windows programs, that doesn't mean MacOS runs on an intel cpu. A car can be put inside of a plane to travel from Paris to NY, that doesn't mean that this is a flying car. I hope you see now the distinction I do between those two concepts. RJ> It's fully internet capable They work on internet, but they are not internet capable. RJ> Why is it that 2:20/11 has got a FrontDoor 2.30 running on telnet daemon RJ> then? It's a DOS program running behind a telnet daemon, with fallback to RJ> a BBS program. Looks to me as a normal modem mailer on a telnet daemon. RJ> For the polling, there has to be a special program, yes, but that has got RJ> nothing to do with the daemons running. What I meant is that additional software is needed anyway. So instead of that telnet hack why not to use a better thing ? Can you receive some 1,500 concurrent incoming calls whith your modem emulation over telnet ? If the mailer was really fully internet able it would be able to handle them whithout problem, just as an http or news server can do too. The only limits being the bandwith and the hardware capacities of the machine (RAM, disk, cpu). -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1382 [1995] Scn From : Pablo Saratxaga 2:293/2219 04 Nov 97 03:51:32 To : Rune Johansen 05 Nov 97 21:33:44 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Sun, 02 Nov 97 13:25:06 +0100, Rune Johansen said: RJ> All of these mailers also supports FTS-1 as a fallback. That's wrong. I know of at least two IP mailers, using IFC protocol that ca, do only EMSI. They have no fallback at all, no yoohoo, no fts-0001. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1383 [1995] Scn From : Pablo Saratxaga 2:293/2219 04 Nov 97 03:54:40 To : Dima Maloff 05 Nov 97 21:33:44 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Sat, 01 Nov 97 20:35:00 +0100, Dima Maloff said: DM> Grrr. This will cut off all UNIX systems. That is 90% of the IP nodes or more. In fact I know of only one non-unix IP node (on about 10 I connected to). -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1384 [1995] Scn From : Pablo Saratxaga 2:293/2219 04 Nov 97 02:47:06 To : Ward Dossche 05 Nov 97 21:33:46 Subj : Re: IP - Call for opinion votes ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Sun, 02 Nov 97 18:43:16 +0100, Ward Dossche said: WD> Some people announced proposals, which are discussed seperatly. I hope, WD> that this query sheet concentrates the different aspects and will lead to WD> one proposal. It seems some things have allready a consessus, I propose that the issue of IP connectivity doesn't be a monolithib thing but rather we split it so the parts that are accepted by everybody can be "officialized" ASAP. I think specially about the flags, it seems tht almost everybody agrees that they should be short, one per capability, and whith the option of telling an alternate port (IMHO that is only useful for telent capability). It also seems that these capabilites must be shown: "raw TCP - IFC compatible" "telnet-vmodem compatible (not VMP !)" "Vmodem (VMP)" "BinkP" But the names to use still nedd to be taken. As the use of such flags doesn't perturb at all the normal nodes, and as they can be of immediate benefit (even whithout any standardization of the way to know the IP address) I propose that we discuss on the names for those flags, so we can began to use them. WD> 1. Where to position the IP#/FQDN WD> WD> 1.1 [ ] node_name field WD> 1.2 [ ] location field WD> 1.3 [ ] phone number field WD> 1.4 [ ] flag field 1.5 [*] On DNS I don't see a reason why control on DNS would be much harder than control on nodelist. Also we can also have several ways of geting the IP address; I think that the use of the DNS even if not official should be permitted. About the IP address on system field whatever we decide here people will put it there too, as they currently are people who put there "ISDN" or things like that. The address on the phone field is not workable. WD> 2.1 [*] individual flags with optional port (colon separated) WD> 2.2 [ ] packed flags (decimal coded 32 bit) individual flags is extensible, packed ones is not. There is also the problem of the telnet capability which uses a quite good variety of alternate ports numbers, we need a way to tell alternate port numbers, at least for the telnet flag. WD> 2 Telnet (port 23) WD> 16 ifc-Telnet (port 60177) Those are the same protocol, only port differ, they don't desserve separate flags, only a way to tell the alternate port (once we decided on which should be the stabdard one, 23 and 60177 being the candidates). Also there is people that actually read the nodelist, the flags must be and remain human parseable. No bit XORing and the such. WD> 3. Direct Mailer handshake via IP required for nodelist entry WD> WD> 3.1 [*] Yes WD> 3.2 [ ] No WD> 4 Announcements of additional protocols allowed? If they are new mailer handwhakes yes. Otherwise (ftp, etc) no. WD> 5. IP may be used only as additional capability WD> WD> 5.1 [ ] Yes WD> 5.2 [ ] No Common sense is the key here. Generally it is preferred that a phone line is availble, but each net/region/zone may have very good reasons to allow an IP only node. We should also let it open for the time where IP will be more common than phone modems. So: no absolute rules graved on stone. WD> 6. Should IP-nodes fullfill standard claims like ZMH or at least clearly WD> stated online times according to the fidonet policy? ZMH is totally useless, even for POTS-only. I never knew a node that is ZMH-only, thay all run their mailer more than an hour. What is much more important is to know *when* we can call a node. In that the introduction of the Txy have been one of the most usefull flags since the las 10 years. We also need such flags for IP connectivity, but due to its nature the meaning need to be different. On phone lines the norm is minimal connectivity, but on internet the norm is full conectivit, so the abscence of the IPTxy flag must mean 24h/24 reachability (by internet). Also there should be a minimal online time to be allowable for any IP flag listing, otherwise people like me who is online only one hour or less could be tempted to ask to be listed, but due to the well known "BUSY" problem when calling your ISP the exact boundaries online time can be fully guarenteed, only an hour is not a secure enough time window. I think two or three hours should be the minimum. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1385 [1995] Scn From : Marco d'Itri 2:335/680.666 05 Nov 97 19:43:10 To : Rune Johansen 05 Nov 97 22:11:26 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >> "BinkP" is enough to describe how to connect to a node. >> "IFC" is enough to describe how to connect to a node. >> "Telnet" + port number is enough to describe how to connect to a node. >Today, these are enough, yes. Maybe not tomorrow. Tomorrow that will be the same. There is no reason to run binkp over telnet or over VMP. >There is need for 3 flags: Telnet (IPT), TCP connection (IPR) and VModem >(IPV). All of those flags implies that the handshake used is EMSI or FTS-1. BNP is a different handshake but is runs only over RAW. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1386 [1995] Scn From : Marco d'Itri 2:335/680.666 05 Nov 97 19:39:20 To : Rune Johansen 05 Nov 97 22:11:26 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >Some uses VMP, some uses VMO, some uses TCP, some uses IFC, some uses TEL, >some uses TELN. By introducing these unique flags, some order might be >accomodated. This is not true. Most people uses TCP (which is bad), VMP, IFC and TELN or TELNET. There is no reason to use a radically new naming system. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1387 [1995] Scn From : Marco d'Itri 2:335/680.666 05 Nov 97 19:37:52 To : Lawrence Garvin 05 Nov 97 22:11:26 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >I'm not interested in dealing with the FUTURE until we've completed the >necessary work on the PRESENT. With this attitude we will end with another broken nodelist format. >We need communication and interconnectivity TODAY, and we do not need to >spend a lot of time talking about what might be someday in the future, until >we can resolve the immediate needs of today. We need to develop a format that will work not just today, but also tomorrow. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1388 [1995] Scn From : Marco d'Itri 2:335/680.666 05 Nov 97 19:46:38 To : Pablo Saratxaga 05 Nov 97 22:11:26 Subj : Re: IP-access ------------------------------------------------------------------------------- srtxg@linux.chanae.stben.be wrote: >Each fqdn that wants to receive email *MUST* have an MX, it can point to >itseld. But whithout an MX there is no guarantee at all that mail will be >sent. In other words: Please point us to the relevant RFCs. When sendmail does not find an MX record it looks for an A. Before the MX RR mail was delivered only by looking at A records. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1389 [1995] Scn From : Marco d'Itri 2:335/680.666 05 Nov 97 19:58:52 To : Rune Johansen 05 Nov 97 22:11:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >Mailers that is properly implemented does not care about banner, as long as >they see the init of their implemented handshake protocols. This is not the point. The point is mailers does not needs any banner. >Yes, connected with modem history, but does also allow me to run FTN and BBS >on the same port, regardless of mailer handshake protocol. Well, maybe you should explain us why this is a good thing. You are not going to use all of them in the next centuries, so why don't you use one port for every service? It's more clean and let you free to start and stop and upgrade one service at time without shutting down the whole system. >> We never heard about 'mailer on a telnet daemon'. What kind of telnet >> daemon do you use? >Not yours, I believe. Looks like you don't use the one most linux users run. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1390 [1995] Scn From : Marco d'Itri 2:335/680.666 05 Nov 97 19:49:30 To : Rune Johansen 05 Nov 97 22:11:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >It is a OS/2 program, that uses EMX. EMX exist for DOS, doesn't it? :-) We have the source, so we can compile NlMake for any platform. I compiled it for linux with just "make", it should work with djgpp (the dos porting of gcc) too. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1391 [1995] Scn From : Pedro Lima 2:362/21 05 Nov 97 17:54:12 To : Rune Johansen 06 Nov 97 18:17:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- RJ> I call that contradiction to policy by the first degree. -=-=- 1 Overview (...) FidoNet is defined by a NodeList issued weekly by the International Coordinator. -=-=- Which degree is this? Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1392 [1995] Scn From : maciej grzeszczuk 2:480/70 04 Nov 97 22:09:34 To : Yuri Teterin 06 Nov 97 18:17:58 Subj : Re: FYI - FWIW ------------------------------------------------------------------------------- From: maciej grzeszczuk Sun, 02 Nov 97 17:02:35 +0100 Yuri Teterin napisal byl w fido.ip_connect: > I have already written - this is not VMP (because neither Argus nor ifcico > do suport VMP), this is FTN-over-telnet (and this should be written in the > logs of your ifcico too - look for the wotd 'telnet' there). i don't know what is implemented in os/2 (it claims to be vmodem), but it works with ifcico. 839 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9-kr0.4 * Origin: to jest lista? ja ta liste... uniewazniam. (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1393 [1995] Scn From : maciej grzeszczuk 2:480/70 04 Nov 97 22:26:44 To : Rune Johansen 06 Nov 97 18:17:58 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- From: maciej grzeszczuk Sun, 26 Oct 97 02:08:10 +0100 Rune Johansen napisal byl w fido.ip_connect: > It would be the same as a non-secure session uploading a pkt-file with the > same name as a pkt-file already lying in the inbound directory of the mailer. > How does the current mailers treat that? Do they overwrite the file, or do > they rename it? they do rename it. > >> actually exists already. If the file already exists, and is not a part > >> ^^^^^^^^^^ > >> of a broken transfer, most protocols would rename the file in current > >> ^^^^^^^^^^^^^^^^^^^^ > > Yes again. But is there any way for FTP to check for the condtion > > underlined above? i don't think so. 840 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9-kr0.4 * Origin: wole jak panienka obrabia jezykiem niz skrawaniem (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1394 [1995] Scn From : Pedro Lima 2:362/21 05 Nov 97 17:59:50 To : Rune Johansen 06 Nov 97 18:17:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- RJ> It states that you have to follow FTS-0001 Wrong. It states that you have to follow the =protocol= defined by =the current FTSC document=, which happened to be FTS-1 when P4.07 was written. But for Policy to be valid, you have to admit there's a FidoNet. And if you admit it, then you're in contradiction with Policy. Or can it be that common sense has in practice ammended Policy? What a dreadful thought... Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1395 [1995] Scn From : Pedro Lima 2:362/21 05 Nov 97 06:44:36 To : Pablo Saratxaga 06 Nov 97 18:17:58 Subj : IP-access ------------------------------------------------------------------------------- PS> If there isn't a refrence domain then the whole idea of DNS can be PS> drop, how can a mailer know the fqdn address of a node if the domain PS> can be an arbitrary one ? By specifying it in the nodelist. This is perhaps not what you meant as "the whole idea of DNS", though. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1396 [1995] Scn From : Pedro Lima 2:362/21 05 Nov 97 06:43:14 To : Marco d'Itri 06 Nov 97 18:17:58 Subj : Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- Md> What about separating IP nodes in an IP-list? This has been discussed before... Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1397 [1995] Scn From : Yuri Teterin 2:5030/239 05 Nov 97 16:58:06 To : Rune Johansen 06 Nov 97 18:19:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Rune ! Tue Nov 04 1997 Rune Johansen writes to Yuri Teterin: >> Then consider BinkP-only nodes like ISDN-only nodes (or vmodem-only >> nodes, if you have no vmodem) and do not try to connect with them. That >> is the problem? RJ> On ISDN-only nodes, I can (if I have ISDN adapter that can run the ISDN RJ> protocol indicated) connect to a mailer, and negotiate a mailer session RJ> handshake. The same is true for BinkP-only node too: on BinkP-only nodes you can (if you have BinkD or any other binkp-compatible mailer) connect to a mailer and negotiate a mailer session handshake. And to install BinkD is much more easy than to buy ISDN line and ISDN adapter, isn't it? So why are you against BinkP-only nodes but are not against ISDN-only nodes? Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1398 [1995] Scn From : Slava Filimonov 2:469/33 05 Nov 97 10:30:32 To : Rune Johansen 06 Nov 97 18:19:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Rune! 04 Nov 97 17:30, Rune Johansen wrote to Nick Soveiko: RJ> The suggestion of including IP-only-BinkP-only nodes does not RJ> contradict with policy? First of all, you use a protocol that is not RJ> documented completely (to the public), and does not have the RJ> possibility to fallback to a commonly implemented mailer handshake RJ> protocol, that is required by policy to run to get nodestatus in RJ> todays fidonet. I call that contradiction to policy by the first RJ> degree. Wake up, man! Who said that policy was written with taking into account ip? With closer look one can find policy in total contradiction with ip reality... -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1399 [1995] Scn From : Nick Soveiko 2:5030/23.101 04 Nov 97 20:55:24 To : Rune Johansen 06 Nov 97 18:19:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Tue, 04 Nov 1997, 18:36, Rune Johansen (2:210/20) ==> Nick Soveiko: >via a triplet flag :port:. i've proposed it here >a few day ago. i can email it to you if you didn't get this message. RJ> Cannot find it. Searched for you as sender, and "triplet" as RJ> keyword. Only this message showed up. Please mail at rune@bbbs.net. i have emailed it to you and i'm reposting an essential part it here for discussion. Area : ip_connect Date : Tue Oct 28, 23:24 snt loc From : Nick Soveiko 2:5030/23.101 To : Rune Johansen Subj : Rune's 1st proposal ------------------------------------------------------------------------------ -- Sun, 26 Oct 1997, 23:32, Rune Johansen (2:210/20) ==> All: [skip] RJ> This is the reason for me NOT including BINKP as a own flag in this RJ> proposal. now here your proposal falls into the same trap as many previous fidonet technical documents. that is, it describes the current situation and makes any changes very difficult as it's flexibility is minimal. your proposal is under assumptions: (1) all mailers should do autodetect on every listed port (2) policy requires fts-1 support on every port both assumptions seem questionable for me. so, i'd go for a triplet flag describing capabilities offered on each port. like this: transport:port:session 'transport' flag is as you described: IPT for telnet (default port 23 or 60177 - discussable) IPR (or IFC, really doesn't matter) for raw tcp/ip (default port 60179 or 24554 - discussable) VMO - proprietary sio's vmodem protocol (default port 3141) other transports may be introduced should such need arise. 'transport' field is mandatory. it can not be empty. 'port' is numeric value for the port. if port field is empty, i.e. VMO::XXX, it's assumed to be default value for current transport (see above). 'session' is a combination of characters '1', 'Y', 'E', 'B' and, possibly, some others in the future. each character indicates fts-1, yoohoo, emsi and binkp capability on current port/protocol combination respectively. combination of characters also implies that the software answering on this port is capable of autodetecting session level protocol. if this field is empty it means that this port supports fts-1 only. an example of node running a conventional mailer under vmodem and binkd both on default ports will carry flags: ,IPT::1YE,VMO::1YE,IPR:24554:B a node running ifcico (port 1234 for telnet and port 5678 for raw tcp) plus binkd (port 9876) will carry flags: ,IPT:1234:E,IPR:5678:E,IPR:9876,B RJ> ,Number,Name,Loc,SysOp,Address,Baud,Flags i still don't think it's a very good idea to place address in the phonenumber field due to the only reason that this leads to a separate nodelist entry to indicate ip-capabilities. this (a) increases size of nodelist against what fidonet coordinators have been struggling for so long and (b) makes procedure of identifying *all* capabilities of a particular system (not just a nodelist entry) quite nontrivial. more or less fundamental solution of the problem is the extended nodelist format, but while it's underway (i am afraid it'll take a while to deploy it) we can use this nodelist kludge. RJ> When policy will let the requirement of being FTS-1 capable, I will RJ> suggest a way of denoting what handshake protocol is available at RJ> which port. i don't see any contradiction between the two. in addition to the above, there's one more argument in favour of separating different session protocols on different ports. this argument is about higher level ftn services, e.g. netmail, echomail and fileechoes, that can also be segregated and each one assigned it's own port. in this way you can always be sure that your crash netmail will be delivered before this 12-hours-long fileecho session finishes. and yes, you can do such tricks with binkd even today: 2:5020/204 works in this manner. so, generally speaking i'd propose a 4d capability flag with the fourth field being type of service (in ftn sense). any opinions? cheers, nick -+- + Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1400 [1995] Scn From : Nick Soveiko 2:5030/69.101 04 Nov 97 20:00:24 To : Rune Johansen 06 Nov 97 18:19:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Tue, 04 Nov 1997, 17:30, Rune Johansen (2:210/20) ==> Nick Soveiko: >neither policy, nor fts-0001 does not say that fidonode has to >support fts-000 on each and every port. they simply don't say >anything about ports. RJ> Because on current implementations (PSTN/ISDN) there are only one RJ> port, and it is the one that you have on your modem. so what? that still does not automatically mean that for a multiport implementation mandate for fts-1 capability refers to each port. as a maximum it implies that there should be a way to connect to a node using fts-1. but that's it. the rest is your imagination. >> But it can be stated rather definitely that none of existing mailers run >> BinkP and FTS-0001 at the same port, and there is no reasons to >> suspect that some mailer will ever do this. >> BBBS (that I run) can do BinkP, EMSI and FTS-0001 on the same port. > so, you're trying to sell us a proposal that reflects your > particular mailer using one particular approach of miltiplexing > different services and different RJ> You say that there is no reason to suspect that some mailer will RJ> ever do this. *i* didn't say this. that's not a quote from my message. i would say that there's no reason to suspect why any mailer would *want* to do this over tcp/ip. > protocols on one port. your proposal rules out the other approach > which does not contradict with policy and is in perfect agreement > with current internet technology and practices. RJ> The suggestion of including IP-only-BinkP-only nodes does not RJ> contradict with policy? your proposal rules out even the nodes that already have fts-1 pstn capability and certainly would like to announce an extended capability that they have: binkp over tcp/ip multiplexed by ports. RJ> First of all, you use a protocol that is not documented completely RJ> (to the public), even the rather incomplete documentation (that was available before i assumed documenting this project) allowed to implement the protocol on a different platform and in a different programming language. and it proved to be 100% interoperable with binkd. RJ> and does not have the possibility to fallback to a commonly RJ> implemented mailer handshake protocol, wrong. it's done in argus. > it will also prevent *anybody* from indicating port-multiplexed > capabilities. it will prevent sysops with dual (pstn and binkp/ip) > from indicating their ip capability in the nodelist. *that's really > bad*. RJ> I know that it will not allow for two different transport RJ> mechanisms that has got two different ways of adressing (phone RJ> number versus IP address). But, if you look a little longer than RJ> this evening, you might see that we just can't take the system name RJ> field to use for IP address, the phone field for phone number, the RJ> sysop name field for X.25 address etc. right. only extended nodelist format can fundamentally resolve the problem of multiply transports. RJ> And, I am also saying that BinkD mailer implementation of today RJ> does not alone meet the requirements of being a self-sustained RJ> node in Fidonet. you are arguing for the wrong point here. binkd implementation of today can perfectly serve as an additional capability to any fidonode with ip access. your proposal doesn't take this into account. cheers, nick --- Handwritten * Origin: <-<-<- Houses of the hairy (Overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1401 [1995] Scn From : Nick Soveiko 2:5030/69.101 04 Nov 97 20:22:26 To : Lawrence Garvin 06 Nov 97 18:19:48 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Mon, 03 Nov 1997, 22:25, Lawrence Garvin (1:106/6018) ==> Nick Soveiko: NS> ok, let's forget 'common sense' for a minute. LG> Okay. :) fine ;) LG> One of those unequivocable requirements is that EVERY NODE listed LG> in the nodelist (except those flagged as PVT), must be capable of LG> negotiating an FTS-0001 session during Zone Mail Hour. NS> fts-0001 has a *really huge* hole in it: LG> Just one? :) one is enough for our purposes ;) NS> it leaves the question of physical layer open. LG> That it does. And my kudos to Randy Bush for being the visionary. yeah, it gives us some room now for [shaking the air] NS> it means that my system could be 100% fts-0001 compliant during NS> the zmh and at the same time you have 0% chances to connect to it. LG> Yep. It certainly does. :) NS> here you go. LG> However, elsewhere in Policy 4 it covers that 'hole' by requiring LG> that you also have a MODEM connected to the published telephone LG> number of your FTS-0001 compliant node, and that the MODEM must be LG> capable of answering a call, and negotiating some sort of CARRIER, LG> so that the calling node can take advantage of the presence of your LG> FTS-0001 compliant node. i've just searched p4.07 for the word 'modem' and there's only one reference to it in paragraph 2.2, where sysop has to communicate type of modem to the net coordinator when he applies for a nodenumber. it doesn't even say that the modem should support one of the standard protocols (sic!). and remember, we don't know any 'common sense' at this time - see above ;) cheers, nick --- Handwritten * Origin: <-<-<- Houses of the hairy (Overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1402 [1995] Scn From : Dieter Ringhofer 2:2476/14 06 Nov 97 17:55:52 To : Nick Soveiko 07 Nov 97 07:12:22 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> if you try to look at pstn and ip as a medium only it's not the DR>> question how you access it. the question is the protocol being used DR>> between 'caller' and 'called' system. NS> both are the questions. in last consequence, of course. at the moment we've the medium (independant what kind of daemon one is used), we need to have the common language now. DR>> compare it with german and russian language: NS> yeah, so it's useless for anything but shaking the air. than there's only one conclusion. DR>> i'm in favour of it if it helps to improve something but we still DR>> must have a common 'language' (read: handshake). NS> this language quite well can be different for every given media. taking NS> the slippery path of analogies, i'd say that imposing fts-0001 for tcp/ip NS> connections now is the same as imposing latin as an official NS> fidonet language. its time has gone. than fidonet's time is gone as well. NS> with my full respect to scott, he simply might be not aware of all bits NS> and pieces of the game. i tell you: z1 is big and there are different NS> telco pricing schemes. i sincerely doubt scott knows them all. i am myself NS> is living in canada now (despite my 2:5030 address) and i am a telecom NS> engineer. you can check telecom digest archives NS> (http://www.telecom-digest.org) on this matter if you don't believe me. i believe you so far but, here we've a very different environment. therefore you can't calculate the costs over here. NS>> i could argue that direct connect between any given pair of NS>> fidonet nodes is not always possible over pstn too. so? is fidonet NS>> *already* dead? DR>> in parts, it is. see isdn-only systems, missing ic, ... NS> i don't see any logical link again. would zcs miraculously throw out their NS> disagreements and elect an ic if isdn nodes are out of nodelist? no, these are TWO issues. DR>> a 'full account' at an isp without fixed ip-number and without own... NS> your unix shell account need not to be at your local isp. it can be NS> anywhere in the world, with the current prices going at about $80/year. NS> that works out to about 10 dm per month. ... and advicing the bank to send the money overseas takes more (at least DM 15) each time ;) NS> that means: for a dialup cm capability you have to buy a second phone NS> line and a second modem/isdn adapter, which works out to around 200 NS> marks down and 44 marks/mo. right? than i've TWO additional phonelines, not only one ;) NS> for tcp/ip cm capability you buy ip access prom your local provider (35 NS> marks/mo) and shell account in, e.g. california (10 marks/mo). and you use NS> your existing phone line/modem to dialin a few times a day and pick up NS> your mail. your monthly expences are approx the same, your installation NS> expences are less for ip and you pay *no long distance* toll. this makes about DM 60 aditionally per month without having done anything. a normal node's phonebill to get all mail is less than this over here per month. if i'm calling even only once a month i've a further add-on: the phonebill for the time being online. NS> will you still argue that tcp/ip is more expensive for you? yes, i do. DR>> when one wants to have a domain it takes several hundred DM to get DR>> it, it's additionally charged in dependancy of volume being DR>> transferred (commercial account). NS> you can be listed in fidonet.net domain right now and at no charges for NS> you. see above, currently it's of no interest for me. NS>> i assume that having a fidonode you already have a phoneline and NS>> a modem. DR>> if this line is in use i need to have another one for ip activities DR>> as well as additional equipment. NS> you don't have to maintain 24/7 connectivity from your home. i'm running a connectable ftn-system for 24hrs a day. if i compare this with anything i must compare it with 24hrs connectivity or i'm lying into my own pocket. a daemon might store something somewhere, to get this i need to do calls. DR>> we have another scheme which is based on defined length of a 'unit' DR>> in dependancy of distance, daytime, etc (typically complicated like DR>> every german ruling). f.e. calling somebody in u.s. charges with DR>> price of one unit every seven seconds normally. NS> this doesn't change the whole idea. but the monthly costs over all ;) NS>> (1) is the same in both cases. (2) is obviously lower than (3), i've NS>> given some examples here last week. even if you don't pay (1) when you NS>> access long distance carrier, (1)+(2) will work out cheaper than (3). DR>> not everytimes. if process to transfer something via an isp takes DR>> more than the time of one 'cost unit' a simple crashmail being DR>> transferred within one unit is cheaper and one knows that it's at DR>> recipiant's system. NS> that's again a rather rare case when dialup crashmail falls slightly below NS> one 'cost unit' and sending it over the ip falls into more. it doesn't bring me really more within the slot. connect = bill. NS> from my side it works out quite different: i pay 1.5 times normal NS> charges for the first minute of connection. so, a 1 min crashmail to NS> germany would cost me ~1.50 bucks, for which i can buy 3 hours of NS> online ip. ARGL!!! over here (even when calculating DM 1.8 / US$ => DM 2.70) at the most cheapest time it's good for one local call of 51 minutes duration :( NS>>> but enforcing fts-0001 support for ip-only systems is not going to NS>>> improve the situation in any way as they still won't be able to NS>>> connect directly to pstn-only systems! DR>>> for being the most common dominator i don't see a way DR>>> around. NS>> i still don't see any logical sequence here. DR>> the 'club' decided that every member accepts incoming calls using DR>> this handshake. so, if i want to be a member of the club, i've to DR>> do the same. at the very first moment it's of no interest what i'm DR>> using additionally. NS> dieter, i start wondering if you're practicing zen here... no, i don't. i refuse to change the rules for thousands of people and to kill fidonet for doing this. that's all. NS> this decision of the 'club' doesn't even specify the basic physical NS> protocol. it means that two systems might be having perfectly matching NS> handshake, but they have *no chances* to connect to each other. this mistake has been made with isdn-only system. shouldn't we learn from the past? --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1403 [1995] Scn From : Dieter Ringhofer 2:2476/14 06 Nov 97 18:16:54 To : Nick Soveiko 07 Nov 97 07:12:22 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- NS>> A stream of data sent on a TCP connection is delivered reliably and in NS>> order at the destination. DR>> what about datagram oriented services? NS> like? nfs NS>> An acknowledgment by TCP does not guarantee that the data has been NS>> delivered to the end user, but only that the receiving TCP has taken NS>> the responsibility to do so. DR>> ! don't forget this. NS> oh, yeah. the data should be successfully passed from the transport layer NS> upstream. if your tcp/ip stack dumps the data to /dev/nul, shure it's NS> unreliable like hell. this can happen by accident. DR>> i say that some of underlaying protocols (remember: tcp is layer 4) DR>> don't take care about some issues mentioned. this can cause (and DR>> causes sometimes) loss of data or defect transmission. NS> they take care about their own issues. tcp takes care about reliable NS> connection between sockets. our mailers speak to sockets, not to the NS> underlaying protocols. if transfer 'through' underlaying protocols doesn't work correct you can do whatever you want. NS>> did the protocol you've been using have autoresume? DR>> i tried it with conventional tcp/ip services as well as via vmodem. DR>> the link has been unreliable everytimes. NS> unreliable you mean frequently dropped connection, right? no, i mean to slow. very much to slow to be precise, because reliability is also a matter of costs (see other mail). traceroute showed several hops with at least 3 secs response time ... cu, Dieter --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1404 [1995] Scn From : Dieter Ringhofer 2:2476/14 06 Nov 97 19:09:54 To : Dima Maloff 07 Nov 97 07:12:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> where's the problem with being compliant to the rest of the fido-world DR>> to offer ftn-fallback even via ip? DM> It's time to get rid of FTS-1 (as reproducing it again and again just DM> wastes people's time), at least for IP nodes. Less code -- less bugs. get rid of fidonet and you've much less work. DM>>> 30.000+ will have to change something to use IP anyway. DR>> no, there's absolutely no need for it. check available software (not DR>> only binkd) and you must agree. we have the chance to use improved DR>> things but, there's no need for it to get functionality. watch this DR>> little difference, please! DM> Well, they'll have to add either vmodem or binkd. What's the difference? binkd needs to get a complete setup. using something like vmodem needs to assign a port and all is done. DM>>> And listen, after all, we do not want for BINKP to be a mandatory DM>>> standard. We just hate to be forced to add vmodem. DR>> there should be a mandatory standard to ensure connectivity or we can DR>> get rid of every ftn. the least common dominator in fidonet is fts-0001, DR>> that's reality. skipping it makes things more worse than they are in DR>> between. think about what you want and accept needed things. DM> Why do you need FTS-1 on IP node if you'll not able to connect a PSTN node DM> anyway? one must have a phoneline to be listed first ... ;) DR>>>> Maybe this leads to an understandable example for you: DR>>>> How does Binkd react when a password error occures (caused by a DR>>>> typo)? DM>>> Reports a error. DR>> will bundles be transferred and accepted than? DM> Of course, no. how do you get a privat mail to this recipient on direct way than? --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1405 [1995] Scn From : Dieter Ringhofer 2:2476/14 06 Nov 97 18:52:22 To : Slava Filimonov 07 Nov 97 07:12:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- SF> have to skip ( or leave for backward compatibility ) nodelist in favor of SF> DNS for ip-fido nodes. since when is dns maintained by fidonet? --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1406 [1995] Scn From : Dieter Ringhofer 2:2476/14 06 Nov 97 18:59:38 To : Dima Maloff 07 Nov 97 07:12:58 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> i already have it since longer time than binkp exists ;) DM> You have. But thouse 30,000-no-yet-IP-connected do not. And wait, where DM> did thouse vmodem drivers of x-SU sysops gone?.. :) why don't you found a new net if fidonet is that bad? DR>> that's somewhat wrong because it's a question of implementation and DR>> secure functionality. you forgot to mention Adept where every line is DR>> a thread only ;) DM> Sure. But as long as vmodem emulates COM-ports we will need separate DM> mailers for each line. And when you are out of virtual COMs remote will DM> get BUSYs. Not good. better than reduced bandwidth which causes additional costs. DR>> the problem with such solutions is total loss of connectivity if ONE DR>> process (task) is interrupted or (much more worse) 'hanging' in some DR>> way. running several processes with the same program increases DR>> secure functionality, DM> /skipped/ DM> I've talked about that starting a mailer only for a time while an incoming DM> connection is active and closing it when the connection ends (like inetd DM> does with most UNIX daemons) is impossible with vmodem drivers for OS/2 DM> and NT. shure? ;) i'll have a look about vmodems interface... DM> (But being reliable is not a problem for binkd at all, even for Binkd DM> versions compiled to use threads, not processes. The biggest problem for DM> Binkd -- bugs of OSs' TCP/IP stacks *sigh*) that's a problem of all protocols using those stacks. DM> With binkd you can use some "test", unprotected address for this. Say, DM> 2:your_net/999. WHO is the recipient than?? I want to get in contact with a specific one (and only with him)! --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1407 [1995] Scn From : Lawrence Garvin 1:106/6018 05 Nov 97 21:17:00 To : Marco d'Itri 08 Nov 97 02:12:12 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Marco d'Itri said in a message to Lawrence Garvin: Md> Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: > Md> I need to know which nodes supports email tunneling, e.g. to send > Md> them crash mail. > Can you program your FIDONET MAILER to make a decision on whether to > tunnel the stuff via email or dial 'em up on the PSTN? Md> Yes, I can write a program THAT -- was not the question, Marco. Nice try... but no bananas. But then I should have been more literal in my question so that there would have been less chance of you squirming out of it. Can you CONFIGURE your Fidonet mailer....??? --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1408 [1995] Scn From : Lawrence Garvin 1:106/6018 06 Nov 97 08:43:30 To : Nick Soveiko 08 Nov 97 02:12:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Nick Soveiko said in a message to Lawrence Garvin: LG> The physical link layer in a PSTN system is actually hidden from LG> the user, and is managed by the telco switching equipment. Arguably LG> so is the datalink layer. NS> v.34 actually moves bits over a pair of wire. the fact that NS> somewhere is't being incapsulated into pcm and telco switching NS> protocols doesn't sacrifice this fact. Then, because of that very fact, V.34 cannot be part of the -physical- layer, as you have just demonstrated that it is independent of the -physical- communications system used. V.34 is a communications protocol negotiated -after- the physical connection is established and stable. The -physical- connection is established wholly and exclusively by the switching equipment of the telephone company. Furthermore, the datalink layer is also a part of the telephone company, and that is evidenced by the fact that the sender need only pump audio sounds into to the telco line (either by voice, or modem) and the information will be transported by the telephone system. Since you do not use V.34 to transmit voice, nor does the telephone company have any association with those protocols, they are NOT part of the telephone system. The telephone -system- provides the datalink and physical layers. LG> I truly believe that modem communications protocols belong in the LG> network layer along with ip and ipx. NS> nope. modem communication protocols are either physical layer NS> (v.32, v.34, etc.) or datalink layer (v.42, v.42bis). I guess we'll just have to disagree on this one. But I will do some additional research, studying, and thinking. If'n I change my mind -- you'll be the first to know. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1409 [1995] Scn From : Rune Johansen 2:210/20 05 Nov 97 23:39:28 To : Pedro Lima 08 Nov 97 02:17:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> It states that you have to follow FTS-0001 > Wrong. It states that you have to follow the =protocol= defined by =the > current FTSC document=, which happened to be FTS-1 when P4.07 was > written. .. during ZMH. You can also support higher standards, it says, but you still have to follow FTS-0001. > But for Policy to be valid, you have to admit there's a FidoNet. And if > you admit it, then you're in contradiction with Policy. Or can it be > that common sense has in practice ammended Policy? What a dreadful > thought... Yes, nobody needs to adhere to anything, nobody needs to follow specs, nobody need to have a phone line. But, IF we get an IC, Policy would be valid again. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1410 [1995] Scn From : Rune Johansen 2:210/20 05 Nov 97 22:53:26 To : Sean Rima 08 Nov 97 02:17:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Beware: BinkP capability and raw TCP capability is not in the >> version lying there. It's in alphatest only. > So, another mailer/BBS adds BinkP to the list. Does it also use BinkP as a > telephone protocol. It can use BinkP as a mailer session handshake protocol, yes. If you don't specify anything, EMSI is preferred by default. But, due to BinkP's total reliance on a reliable underlying transport mechanism, it is not recommended. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1411 [1995] Scn From : Rune Johansen 2:210/20 05 Nov 97 23:02:36 To : Dima Maloff 08 Nov 97 02:17:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Sure. But as long as vmodem emulates COM-ports we will need separate mailers >for each line. And when you are out of virtual COMs remote will get BUSYs. Not > good. Same thing with every decent configuration: when the load of your machine gets too high, it refuses to do more connections. If I configure my system to accept up to 50 simultaneous incoming sessions over IP, I don't want to accept more. If I configure my Sendmail MTA to stop accepting inbound connections when the machine load rises above 5, I do so. There _is_ a limit to all systems, some are lower than others. > I've talked about that starting a mailer only for a time while an incoming > connection is active and closing it when the connection ends (like inetd does > with most UNIX daemons) is impossible with vmodem drivers for OS/2 and NT. Is it really impossible? Cannot a daemon spawn a mailer when it connects a incoming process, with a handle to the communication link? You don't necessarily need to use COMx ports, you could use pipes (or in NT: mapfiles). That's what I do with my system. I have a daemon listening, and spawns the mailer with mapfile as parameter. No system load when idle. Under unix, the inetd does this. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1412 [1995] Scn From : Rune Johansen 2:210/20 05 Nov 97 22:14:58 To : All 08 Nov 97 02:17:26 Subj : FTS-0001 in IP nodes ------------------------------------------------------------------------------- I seem to be one of the few that keeps on hammering at the FTS-0001 part. Just to make the records straight, this is my key things: - Todays policy says that a node needs to do FTS-0001. - Would Policy need a rewrite to acknowledge that not every port where there is a mailer need to do FTS-0001? Is it enough that ONE port on a nodenumber does it? - IF all ports need FTS-0001, I say that BinkD is not a valid mailer, per policy. - If only ONE port on a nodenumber needs to be FTS-0001, then a BinkD-ONLY node would not be valid (implicit from the point over this) In this, I regard a port as a IP port, OR a PSTN/ISDN number/connection. So, if a nodenumber has got two addresses, one PSTN and one IP, and the PSTN serves FTS-0001, then there are at least ONE port fulfilling policy. IF a node would need only one port with FTS-0001, does that mean that a node with multiple nodenumbers only requires FTS-0001 on ONE of it's nodenumbers? That's it. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1413 [1995] Scn From : Rune Johansen 2:210/20 05 Nov 97 23:25:18 To : Nick Soveiko 08 Nov 97 02:17:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Example: My >> mailer listens to a raw TCP port. It detects a incoming session. My >> mailer shows a banner, sends EMSI inits, and a BinkP init. All in >> the same packet. > what do you mean by 'packet' here? Let's say that my IP stack uses a MTU of 1500. The data mentioned over is a total of 300 bytes. All gets sent in one IP packet, since the buffers are not full in my IP stack until i want to send it. That's my "packet". Or, you might see it another way: My mailer sends EMSI init. Then it sends banner. Then it sends IEMSI init, and then it sends BinkP init. All happens so quick, that my IP protocol ships it all over at the same time to the other party. >> Current BinkD does not see the BinkP init, and times out. >dunno. never tried this. talk to max masiutin (max@ritlabs.com) on how this is >done in argus. it works for sure, as i'm connecting with binkd to argus severa >times a day and never had a handshake timeout problem. i would be most happy t > document it then. My test (I have been receiving party) shows that if I send "stuff" before I send BinkP init, the calling party times out. The calling party uses BinkD 0.9.1. If I don't send any "stuff" before the BinkP init, the calling party sees it, and sends M_PWD frame. > no, seriously, are you running out of tcp ports? i can borrow you some ;) I am not saying that I am running out of TCP ports. I am saying that you'd might want to run it all on ONE port. My FIreWall admin might be so kind to open up for ONE port for inbound connections to me, because of [events out of my control], as long as I agree to NOT let anything other than FTN mailer sessions come through. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1414 [1995] Scn From : Rune Johansen 2:210/20 05 Nov 97 23:34:52 To : Slava Filimonov 08 Nov 97 02:17:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >Use phone lines as 'horsetrail', ok ? That excludes IP-only nodes. Do we, or do we not want to include IP-only nodes in the nodelist? > I wonder, why in real world there is no at all horsetrails along highway ;) Because in the real world, you have rules that are more up-to-date than P4. > Same reason - we still using horses only for a short distance and where no > other motor roads exists. And, we use horses when there is only motor road, and we don't have the cars that can run on that specific motor road. Reminds me of a "joke" here in Norway: "What should we have done without the cars?" "The highways would have meter-high horseshit on them" Read this one too: :-)) "What should we have done without water?" "Carried the boats, and picked the fishes" And this: "What should we have done without water?" "Walked to the islands" ... "What should we do if the ocean was made of Vodka?" "Gone ashore to pee" Totally off-topic, but :-)) --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1415 [1995] Scn From : Rune Johansen 2:210/20 05 Nov 97 23:13:42 To : Dima Maloff 08 Nov 97 02:17:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> It reflects the requirement of being a node in Fidonet, the possibility to >> accept a FTS-0001 session handshake on the transport protocol that you >> have a mailer on. > As per Policy4, you must have a telephone line first of all! I know that I look away from that part of policy. But then again, how are we to include IP-only nodes in the nodelist if you need a telephone line and a modem to get in? > 2) binkp is technically better, as it made most x-SU sysops move to it from > vmodem-likes; Wether a protocol is technically better that other ones are not the issue here. > 3) a node to have an IP connectivity should add either vmodem or binkd, so > "there are 30,000 FTS-1 installations" thesis cannot be used; > 4) no one will use FTS-1 even if it's implemented in binkd That might be absolutely true. I don't say you must USE it, you must OFFER it to the party that connects to you, if they don't have your mailer session protocol available. > I can interpret forcing of binkp-only sysops to support FTS-1 only one way -- > authours and/or users of commercial software make problems for users/authours > of free software (To increase their "market share" politically?) Not fair. Is BinkleyTerm commercial? No. Does it use FTS-1? Yes. Life is not fair, and will never be. > Again -- the basic rule of connectivity in today's Fidonet is having of a > telephone line. That has been broken long ago. It also states you need a MODEM on the phoneline. Well, with ISDN adapters (NOT modems) you have broken that one. Why do we need to break the rest of it too? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1416 [1995] Scn From : Rune Johansen 2:210/20 05 Nov 97 23:36:06 To : Pedro Lima 08 Nov 97 02:17:28 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> I call that contradiction to policy by the first degree. > (...) FidoNet is defined by a NodeList issued weekly by the > International Coordinator. > Which degree is this? Ohmygod! I have been in a non-existant network for over three years! --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1417 [1995] Scn From : Rune Johansen 2:210/20 05 Nov 97 22:05:52 To : Pedro Lima 08 Nov 97 02:17:28 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- >> To allow for other addresing schemes to not be called, you would only >> accept to call those trasnport mechanisms that your mailer support. > Which means that I'd have to permanently review my configuration just in > case flags were deleted or added. Mind you, I even might do it, but I'm > sure many won't. It would be much simpler if a flag is attributed to a > different transport. Yes, you would actually have to pay attention to what happens around you. If you allow your mailer to call those flags that you know your transport is compatible with, you are in the safe zone for a long time. If a new flag comes up, that your transport can do, then you add it. If a new flag comes up that your transport cannot cope with, you ignore it, since you would not connect to it anyway. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1418 [1995] Scn From : Rune Johansen 2:210/20 05 Nov 97 22:16:44 To : Marco d'Itri 08 Nov 97 02:17:28 Subj : Re: Test of an IP-number in the nodelist / Proposal ------------------------------------------------------------------------------- > What about separating IP nodes in an IP-list? This way we would not need > any ugly kludge to maintain backward compatibility. > IP only nodes would get a Pvt entry in the standard nodelist. Yes, that is a solution, but that contradicts with the topic of this echo: How to incorporate IP nodes in the nodelist. I assume that it is without using extra nodelists. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1419 [1995] Scn From : Slava Filimonov 2:469/33 06 Nov 97 10:54:18 To : Ask Bjoern Hansen 08 Nov 97 02:20:24 Subj : IP - Call for opinion votes ------------------------------------------------------------------------------- Hello Ask! 04 Nov 97 13:52, Ask Bjoern Hansen wrote to Ward Dossche: WD>> 6. Should IP-nodes fullfill standard claims like ZMH or at least WD>> clearly stated online times according to the fidonet policy? AH> IP nodes should be CM as standard, and only anything else if it's AH> stated by a IPTxy or similar flag. In case we're using DNS and MX or MX-like fallback mail exchangers, CM will not be obligatory, as soon as at least one exchanger from MX records will accept mail. In internet world we're not using CM or IPTxy flags for SMTP servers. Why? It's obvious. I even can't imagine such stupid thing as internet with IPTxy flags for smtp servers. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1420 [1995] Scn From : Mario Mure' 2:33/505 06 Nov 97 19:57:54 To : Nick Soveiko 08 Nov 97 02:20:24 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- In a message dated 30 Oct 1997 about < Re: IMPORTANT! standard of protocol for ip-nodes proposal. >, Nick Soveiko wrote: NS> and yes, you can get binkd for amiga now). Where ??? I DO really need binkd for the Amiga. Ciao ! /mario/ mure@sistemia.it --- ifmail v.2.11-tx8.5 * Origin: Stay cool if your hard disk say goodbye (2:33/505@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1421 [1995] Scn From : Lawrence Garvin 1:106/6018 06 Nov 97 20:32:22 To : Nick Soveiko 08 Nov 97 02:20:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Nick Soveiko said in a message to Lawrence Garvin: LG> However, elsewhere in Policy 4 it covers that 'hole' by requiring LG> that you also have a MODEM connected to the published telephone LG> number of your FTS-0001 compliant node, and that the MODEM must be LG> capable of answering a call, and negotiating some sort of CARRIER, LG> so that the calling node can take advantage of the presence of your LG> FTS-0001 compliant node. NS> i've just searched p4.07 for the word 'modem' and there's only one NS> reference to it in paragraph 2.2, where sysop has to communicate NS> type of modem to the net coordinator when he applies for a NS> nodenumber. it doesn't even say that the modem should support one NS> of the standard protocols (sic!). No, but it does require the sysop to provide the NC with the telephone number that the modem is connected to. Ostensibly so that the NC can validate that the mailer is functioning before issuing the node number. NS> and remember, we don't know any 'common sense' at this time - see NS> above ;) Common sense had nothing to do with that. If it did, we would consider the possibility that Step 5 of that procedure specified in Paragraph 2.2 would also accept IP addresses, in addition to telephone numbers. :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1422 [1995] Scn From : Yuri Teterin 2:5030/239 06 Nov 97 17:11:32 To : Marco D'itri 08 Nov 97 02:20:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello, Marco ! Tue Nov 04 1997 Marco d'Itri writes to Yuri Teterin: >> 'raw TCP' and 'ifcico proprietary' are the same. MI> They are not. ifcico has an optional proprietary communication protocol MI> (at the level of zmodem etc) that can be run in FTS-1 and EMSI sessions MI> over telnet or over the raw socket. Exactly. But they say about transport-layer protocol only, and if there were suggestions not to make differences even between FTS-0001 and EMSI, were were no sence to distinguish ifcico's session-layer protocol that is just a modification of EMSI session. Best wishes, Yuri --- GoldED/W32 3.00.Alpha5 UNREG * Origin: Gauss Station, St.Petersburg, Russia (2:5030/239) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1423 [1995] Scn From : Slava Filimonov 2:469/33 06 Nov 97 10:45:58 To : Pablo Saratxaga 08 Nov 97 02:20:24 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Pablo! 04 Nov 97 03:43, Pablo Saratxaga wrote to Rune Johansen: PS> There are 65535 ports, there should be at least 60,000 free ports on PS> any server, so the case of 'only one port available' is only a PS> theorical case which will never happen :) btw, Nope, it can happen ;). On Micro$oft NT/95 you can run out of free client ports/resources/handles if you'll use non-stop program which will just opening/closing sockets. I saw this bug myself in MS NT 4, when MS proxy server was unable to open any connections reporting error - 'no buffer space available'. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1424 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 08 Nov 97 10:29:46 To : Lawrence Garvin Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Hello Lawrence! On 05 Nov 97 wrote Lawrence Garvin to Marco d'Itri: LG> But then I should have been more literal in my question so that there LG> would have been less chance of you squirming out of it. LG> Can you CONFIGURE your Fidonet mailer....??? Here it works very well (and transparently) for several protocols/mailers with the same outbound structure without additional programs, based on the existing nodelist format. Only ifcico is not implemented yet, but everything else. If the opposite system with ifcico supports the telnet port 60177, i can (and do) run sessions with them. In fact, as telnet is supported on most platforms, this might become a standard protocol, if that is really needed :) Regards, Lothar PS: Searching for OS/2 version of ifcico with binkley outbound structure to complete my mixture :) --- GoldED/2 3.00.Alpha5+ * Origin: Life/2: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1425 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 08 Nov 97 10:48:20 To : Rune Johansen Subj : FTS-0001 in IP nodes ------------------------------------------------------------------------------- Hello Rune! On 05 Nov 97 wrote Rune Johansen to All: RJ> I seem to be one of the few that keeps on hammering at the FTS-0001 RJ> part. Just to make the records straight, this is my key things: RJ> - Todays policy says that a node needs to do FTS-0001. FTS-0001 contains several parts, where the session description is focused on pstn connects via a modem. As paragraph H gives a hint about open implementation of non-dialing networks, i prefer to seperate between session handshake implementation and the rest of the document, as this would allow much flexibility without putting every document in the trashcan. Except the (analogue-based) session handshake everything else can be fullfilled even with BinkD (direct session authentication via nodelist entry with mail/file exchange with different flavours and ZMH-requirement), as described in chapter 1 (Basic requirements for a fidonet implementation). For example a FSC or FTS describing BinkP could be a "well tested extension", conformant to chapter 2 (Levels of compliance). As BinkP does not support FTS-1 handshake procedures, but fulfills any other requirements of it, i support it as usable protocol in fidonet, based on a not so narrow interpretation. RJ> - Would Policy need a rewrite to acknowledge that not every port RJ> where there is a mailer need to do FTS-0001? Does any conventional mailer support FTS-0001? As far as i know, some don't. RJ> Is it enough that ONE port on a nodenumber does it? That would be not such a problem with combined entries :) RJ> - IF all ports need FTS-0001, I say that BinkD is not a valid RJ> mailer, per policy. Correct, with this narrow interpretation. RJ> - If only ONE port on a nodenumber needs to be FTS-0001, then a RJ> BinkD-ONLY node would not be valid (implicit from the point over RJ> this) Correct, as above. RJ> In this, I regard a port as a IP port, OR a PSTN/ISDN RJ> number/connection. So, if a nodenumber has got two addresses, one RJ> PSTN and one IP, and the PSTN serves FTS-0001, then there are at RJ> least ONE port fulfilling policy. Correct, but you should differentiate between pstn and ISDN and ISDN only then, as ISDN only is another potentially un-connectable node. RJ> IF a node would need only one port with FTS-0001, does that mean that RJ> a node with multiple nodenumbers only requires FTS-0001 on ONE of it's RJ> nodenumbers? Why don't you think about combined entries? IP as strictly additional connectivity allows some more room than using it as a replacement for conventional. As long as most participants in the query require CM for additional ip-connectivity, it is much wiser to allow one or more additional protocols than part-time node entries :) RJ> That's it. Yes :) Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1426 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 08 Nov 97 13:14:16 To : Slava Filimonov Subj : IP - Call for opinion votes ------------------------------------------------------------------------------- Hello Slava! On 06 Nov 97 wrote Slava Filimonov to Ask Bjoern Hansen: WD>>> 6. Should IP-nodes fullfill standard claims like ZMH or at WD>>> least clearly stated online times according to the fidonet WD>>> policy? AH>> IP nodes should be CM as standard, and only anything else if it's AH>> stated by a IPTxy or similar flag. SF> In case we're using DNS and MX or MX-like fallback mail exchangers, CM SF> will not be obligatory, as soon as at least one exchanger from MX SF> records will accept mail. In internet world we're not using CM or SF> IPTxy flags for SMTP servers. Why? It's obvious. I even can't imagine SF> such stupid thing as internet with IPTxy flags for smtp servers. As we are talking about direct sessions between nodes with ip as alternate medium, these make sense. I don't know, how to implement a direct session with all capabilities of it (authenticated transmission and pickup of mail and files) via an mx within one call, so this email-based schedule does not include any kind of communication handling which is the advantage of the fido technology. If you want to run a email-based system, there are enough possibilities beside fidonet. Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1427 [1995] Scn From : Ward Dossche 2:292/854 07 Nov 97 09:51:32 To : All 08 Nov 97 18:46:04 Subj : Replying ------------------------------------------------------------------------------- Just a small thought ... when I look in my inbound for this conf every day I see 15 replies from "a", 12 reactions from "b", etc ... This is very confusing, it seems like if we're debating a religious issue here. At present I have stopped reading this flow and only picking-up messages to myself or to "all". \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1428 [1995] Scn From : Denis McMahon 2:251/20 06 Nov 97 09:45:52 To : Lawrence Garvin 09 Nov 97 05:43:18 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Lawrence Garvin wrote to Denis McMahon: LG> Denis, methinks you missed my point. We're talking about mailers LG> that make OUTBOUND calls. Okay? :) DM> No, we're talking about the use of IP protocols in the Fidonet DM> environment. LG> Okay. Fine. I'll try again. LG> -I- am talking about MAILERS that make OUTBOUND calls. LG> If you do not wish to discuss THAT topic with me, then do not reply LG> to this message. OK, then ... LG> WHEN I can get my node listed in the nodelist with an IP address or LG> a FQDN, and I can dial an IP address or FQDN with my CURRENT LG> SOFTWARE -- which btw, can be done -- I'm already doing it LG> 'unofficially' -- Then, and Only Then, will I be interested in LG> worry about capabilities for some "future generation mailer". LG> We need communication and interconnectivity TODAY, and we do not LG> need to spend a lot of time talking about what might be someday in LG> the future, until we can resolve the immediate needs of today. LG> So... if you're interested in talking about today's needs, then by LG> all means let's continue this conversation; however, if you're only LG> interested in talking about that "future generation mailer", then LG> I'm not the guy you should be wasting your words on. OK, the implication here is tht your software is capable of making outgoing IP connections (using transport level protocol x whatever x is) for FTN session level communication, yes? If so, the question as to what we put in the nodelist comes down to what your existing software requires in the nodelist, does it not? So, what information does your software look for in the nodelist to make these IP calls? Regards Denis --- timEd/386 1.10 * Origin: Vote Denis McMahon for ZEC2 (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1429 [1995] Scn From : Anatoli Gulidov 2:5020/388.1 07 Nov 97 19:57:02 To : Ward Dossche 09 Nov 97 05:43:18 Subj : !!!!!!!!!!!!!!!!!!!! ------------------------------------------------------------------------------- HELLO, Ward! 02 Nov 97 09:58, Ward Dossche (2:292/854) wrote to Ward Dossche: WD> No I don't enjoy writing mail to myself but obviously we have a WD> dupelink via the US again. >> PATH: 292/854 480/33 70 106/6018 8277 270/101 2433/225 1200 >> 2432/200 PATH: 292/854 I see multiple dupes of your (Ward Dossche) messages only, main cause of your dupes - your messages don't have Msgid. Not any other (from any other sysops) messages have dupes in my echomail, only all messages of you. This causes also too other problems (ekz. some message-editors search reply-address in msgid, but not found). WD> @PATH: 292/854 5100/8 5020/79 225 443 68 236 388 Also I have other messages with same text and date but other path, received in same day: @PATH: 292/854 5100/8 5030/115 5020/400 443 68 236 388 But have dupes from none of other senders, from you only. CHAO, Anatoli. ------------------------------------------------------(07 Nov 97 19:57) --- GEcho 1.11+ * Origin: http://members.wbs.net/homepages/a/n/h/anhtung.html (2:5020/388.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1430 [1995] Scn From : Frank Ellermann 2:240/5815.1 08 Nov 97 02:50:00 To : Pedro Lima 09 Nov 97 05:43:18 Subj : IP-node management (was: Proposal for listing [...]) ------------------------------------------------------------------------------- Hi Pedro... PL> I think these are "political" decisions, and that they can be left, PL> at least for the time being, to the discretion of the *Cs. ... continued in the V21-thread in ENET.SYSOP today, here all I can say is that I disagree, not the same old mistakes as with ISDN-only again, if possible. *Cs unable to verify IP-nodes would be in trouble, which technical solutions (except from dedicated IP-nets to begin with) do you have ? Maybe a volunteer offering IP-checks as function request or by some kind of mail robot ? It's not necessarily only a political question, if we could have some technical answers, _before_ it bites us... >:-) Best wishes, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1431 [1995] Scn From : Slava Filimonov 2:469/33 07 Nov 97 12:01:02 To : Dieter Ringhofer 09 Nov 97 05:43:18 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dieter! SF>> have to skip ( or leave for backward compatibility ) nodelist in SF>> favor of DNS for ip-fido nodes. DR> since when is dns maintained by fidonet? If i understood you right, there are f???.n5???.z2.fidonet.net domains already. The question is how to specify MX exchangers and use smtp-emulator in binkd or do not use MX-records for DNS-based routing. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1432 [1995] Scn From : Dima Maloff 2:5047/13 08 Nov 97 12:53:00 To : Mario Mure' 09 Nov 97 05:43:18 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thursday November 06 1997 19:57, Mario Mure' wrote to Nick Soveiko: MM> Where ??? I DO really need binkd for the Amiga. Ask Dmitry Yurtaev (or ? Sorry, don't know his fido address.) --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1433 [1995] Scn From : Dima Maloff 2:5047/13 08 Nov 97 12:53:00 To : Rune Johansen 09 Nov 97 05:43:18 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wednesday November 05 1997 23:25, Rune Johansen wrote to Nick Soveiko: RJ> I am not saying that I am running out of TCP ports. I am saying that you'd RJ> might want to run it all on ONE port. My FIreWall admin might be so kind RJ> to open up for ONE port for inbound connections to me, because of [events RJ> out of my control], as long as I agree to NOT let anything other than FTN RJ> mailer sessions come through. Good reason. So I'd suggest either to use binkp only ;), or to put all that EMSI/IEMSI/banner staff into one binkp's M_NUL frame. --- GoldED/2 3.00.Alpha5 UNREG * Origin: Beercan, Magadan, Russia (2:5047/13) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1434 [1995] Scn From : Denis McMahon 2:251/20 06 Nov 97 10:06:42 To : Lawrence Garvin 09 Nov 97 05:43:18 Subj : IP-access ------------------------------------------------------------------------------- Lawrence Garvin wrote to Denis McMahon: LG> Denis McMahon said in a message to Lawrence Garvin: DM> Agreed, however I was disputing the suggestion that nameserver DM> entries should be handled by the NCs, how many NCs run nameservers? LG> Who said anything about the -NC- running the nameserver? ? ? ???? DM> Ask Bjorn Hansen (I hope I spelled it right), in the message that I DM> originally replied to suggested that the nameserver should operate DM> at the net level. LG> Yeah... so.... my question stands: Who said anything about the -NC- LG> running the nameserver? Ask, in the message I was replying to when you joined in this particular thread. :-) DM> My domestic connectivity is purely dial-up, and my employer has a DM> firewall that I have no control over whatsoever. LG> Then you don't need a DNS server in your net, do you. :) Why not? I have two lines, two modems, and a multi-tasking OS, and could quite feasibly put up a ZMH IP system. The DNS would probably be provided by my ip, and the fido mapping required would be 2:251/20 => pickaxe.demon.co.uk, however that doesn't need a DNS at any level. It is possible that I could obtain an entry in the Z2 dns for f20.n251.z2.fidonet.org, and the software I have already running here would fully support that at the message (i.e. email / netmail) level. Regards Denis --- timEd/386 1.10 * Origin: Vote Denis McMahon for ZEC2 (2:251/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1435 [1995] Scn From : Frank Ellermann 2:240/5815.1 08 Nov 97 01:57:00 To : Amir Shabashvili 09 Nov 97 05:43:18 Subj : test-zone (was: Proposal for listing as IP-node) ------------------------------------------------------------------------------- Hello Amir... AS> if we use really organized echomail-gates between zones, there AS> is no problemo. For a IP-test-zone this might be possible, but generally the idea in FidoNet is to have _no_ centralized organization of mail-links, because such centralized systems could impose their personal rules on the free flow of mail... Of course this technical problem has to be solved very soon, the days when clubs and organizations like TipTop or OBO were still able to control international mail-flow are almost gone... Watch the rapidly growing number of interzone dup-rings... if John for reasons beyond me pulls the plug we're definitely in trouble with today's FTS-4-"standard" Greets, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1436 [1995] Scn From : Slava Filimonov 2:469/33 07 Nov 97 11:51:06 To : Rune Johansen 09 Nov 97 05:43:18 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Rune! >> Use phone lines as 'horsetrail', ok ? RJ> That excludes IP-only nodes. Do we, or do we not want to include RJ> IP-only nodes in the nodelist? In this case i have to give up with fido, cause i'm in ip-only mode due curcumstances. -- --< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >-- -- - ---< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >--- - --- MiB `o-o' 2.50+ * Origin: c[] Best experienced with Czech Beer c[] (2:469/33) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1437 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 09 Nov 97 09:12:30 To : Slava Filimonov Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Slava! On 07 Nov 97 wrote Slava Filimonov to Rune Johansen: RJ>> That excludes IP-only nodes. Do we, or do we not want to include RJ>> IP-only nodes in the nodelist? SF> In this case i have to give up with fido, cause i'm in ip-only mode SF> due curcumstances. Is participation in fidonet in R46 bound to a nodenumber? Don't they have a regional pointlist? Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1438 [1995] Scn From : Dieter Ringhofer 2:2476/14 09 Nov 97 12:48:30 To : Slava Filimonov 09 Nov 97 19:05:22 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- SF>>> have to skip ( or leave for backward compatibility ) nodelist in SF>>> favor of DNS for ip-fido nodes. DR>> since when is dns maintained by fidonet? SF> If i understood you right, there are f???.n5???.z2.fidonet.net domains SF> already. i don't know anything about, especially i don't know who is maintaining it. SF> The question is how to specify MX exchangers and use SF> smtp-emulator in binkd or do not use MX-records for DNS-based routing. forget about binkd and any special thing, we don't fight a religious war. it's not the task of a standard about inter-connectivity to be limiting at usage of a specific medium like usage of binkp-protocol over tcp does with current implementations. the question is how to introduce something which is capable to enable inter-operation between existing standards on different media. both sides need to move for this but the most easiest way to go is for existing ftn-standard because it's not limited to a specific medium: some simple flags are all what's needed by the software to distinguish type of connect to choose, a fallback is always possible. only the 'frontend' is affected when choosing this kind of implementation. specific problems about routing with non-ftn-software at ip-side must be solved there without exclusion of standard set by existing rules as long as those rules aren't changed as well as offering chance of maintenance from originating ftn's side without loss of control of it's own matters. such inter-operation leads to a can of worms which must be taken into account if one doesn't want to poor the child out with the bath. it takes it's time to find a set of common basic and proper working things on 'every side'. publishing a proper and detailed description of how things work and a proper definition of terms might be a first step on the way to find some points where we can put something in like glue. see false usage of already defined terms in ongoing discussion and you might see the need of methodical organized kind of work starting 'at the bottom' as well. the way it's done now is like stumbling through thick fog and causes a lot of unneeded traffic. as long as some people are 'blind' against the 'needs' of other people (independant of the reason causing it) we don't have a chance to move anything in longer terms, it'll always be a hack. aditionally don't forget that nobody enforces usage of basic standards. add-ons fitting better are welcome but they shouldn't be an isolating solution. a fallback to THE current common standard must be possible otherwise one achieves nothing than rejection! example: if there's the need (not only the wish of few people!) to change minimal requirenments to become a member of fidonet it needs to have an ic first to have the chance to change it's fundamental rules. otherwise it kills itself for ignoring it's own rules (independant of personal oppinion about the content of the rules). --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1439 [1995] Scn From : Marco d'Itri 2:335/680.666 09 Nov 97 15:56:46 To : Rune Johansen 09 Nov 97 21:54:34 Subj : Re: FTS-0001 in IP nodes ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: > - Todays policy says that a node needs to do FTS-0001. Policy says that a node needs a modem and a telephone number too. > - Would Policy need a rewrite to acknowledge that not every port where there > is a mailer need to do FTS-0001? Is it enough that ONE port on a > nodenumber does it? AFAIK there are already PSTN nodes that does not supports FTS-1 on all lines. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1440 [1995] Scn From : Marco d'Itri 2:335/680.666 09 Nov 97 15:52:12 To : Frank Ellermann 09 Nov 97 21:54:34 Subj : Re: IP-node management ------------------------------------------------------------------------------- Frank.Ellermann@p1.f5815.n240.z2.fidonet.org wrote: >*Cs unable to verify IP-nodes would be in trouble, which technical >solutions (except from dedicated IP-nets to begin with) do you have ? They can appoint someone who will verify IP nodes. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1441 [1995] Scn From : Marco d'Itri 2:335/680.666 08 Nov 97 13:26:34 To : Lawrence Garvin 09 Nov 97 21:54:34 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >Can you CONFIGURE your Fidonet mailer....??? Yes, I can configure my software in a way that it will send all netmail for those nodes encapsulated in internet email. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1442 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 09 Nov 97 23:02:06 To : All Subj : IP-Query-Sheet ------------------------------------------------------------------------------- Hello All! >-8------------------------ byte here ------------------------8-< About Question 6: Beside any defined Online-Time in 6.1, another selection "CM only" should be noted seperately as 6.3. If this should change any "old" query sheet (before Nov. 8th 1997), this dedicated selection may be sent directly to me. >-8------------------------ byte here ------------------------8-< If somebody sees any difference in using ip-numbers or fqdn, he should note that in the comment-field (7). >-8------------------------ byte here ------------------------8-< Question: I do not see any sense in CM (or any other defined online time) without a direct-session on the other hand :) Could somebody explain that to me, please? Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1443 [1995] Scn From : Rune Johansen 2:210/20 07 Nov 97 22:06:06 To : Pablo Saratxaga 09 Nov 97 23:19:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > What is needed is to define the flags, but no standadr should be imposed to > anyone. >In phone transport common standards are a very important point, as that is the > glue of fidonet. But for IP transport that hasn't to be the case, it is a > secondary and optional transport, if you really want to crash a given node > you can do it by phone; You assume that a node with IP capabilities would have a phone beside him that he would run a mailer on. In this echo we are (trying) to discuss the events of a IP-only node too. To be able to get IP-only nodes inside the nodelist, we have to have the technical part ready (flags, protocols etc.), before we can try to convince the other participants that it would do fidonet good. Fidonet would then be a service on the internet, alongside other services as news (Usenet, for example) the world wide web, gopher, ftp etc. > but imposing standards on IP connectivity will have > a very bad impact: several people won't declare heir IP capabilities only > to get ride of all that hassle (remember most people run nodes to be kind > whith others and provide them mail and areas; what is the point whith > all that buraucracy ?). I'm not sure if you have been following the discussions from the beginning here, but the raging discussions here (with me on one side, and almost every else on the other side) are based in the question: Should IP nodes have a protocol in common, to enable full connectivity between them? From that question arises a new question: Should different transport protocols (i.e.: Telnet, VModem and Raw TCP) have a common session level protocol within each transport protocol? I have stated that if we are to have a common session protocol, it should be the one defined in policy; FTS-0001. I do not believe that it would be logical to demand that all IP nodes should have at least one specific transport protocol in common. The session level protocol question would still be valid. To follow up on the FTS-0001 part, I have also stated that the BinkD mailer would not fulfill such a requirement, and that the BinkP protocol specification per date does not describe how to put in a hook for other, alternate protocols, so that a FTS-0001 session could be detected. I have never said that FTS-0001 is better than any other protocol, or that you must use it. All the discussions have come out from the part of the basic question reffered to over. > Only when IP connectivity could be considered as the primary transport whith > lots of IP only nodes we will need to decrete a standard and mandatory > protocol. But that is not for tomorrow, but for several years from now, > and by that time it is much probable that a de facto standard will be > widely in use. I agree with you that a defacto standard would be in use in some years. But, it is not for sure that it would be BinkP. Maybe it will be another, less efficient protocol, that includes greater support for failure? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1444 [1995] Scn From : Rune Johansen 2:210/20 07 Nov 97 21:51:48 To : Pablo Saratxaga 09 Nov 97 23:19:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Oh? So, if I use a FOSSIL-able telnet daemon, giving my mailer a RING when > a >> incoming connection is being made is not internet-able? > No. The programs still think the yuse a modem, the yhave no idea of tcp/ip, > thay can hardly be called internet-able. > There also exist programs that encapsulate IPX paquets on TCP/IP ones. > That doesn't mean an IPX-only program is TCP/IP-able. > There also exist emulators for the MacOS allowing to run windows programs, > that doesn't mean MacOS runs on an intel cpu. > A car can be put inside of a plane to travel from Paris to NY, that > doesn't mean that this is a flying car. > I hope you see now the distinction I do between those two concepts. I see what you want to say. I still say that the mailers in question is internet-able as they can "call" other services on the internet. > What I meant is that additional software is needed anyway. So instead of that > telnet hack why not to use a better thing ? Maybe (just maybe) it is not applicable for the system in question. Maybe the author of the mailer comes up with a version that _do_ use it? >Can you receive some 1,500 concurrent incoming calls whith your modem emulatio > over telnet ? Yes, if I configure it to do so. > If the mailer was really fully internet able it would be able > to handle them whithout problem, just as an http or news server can do too. > The only limits being the bandwith and the hardware capacities of the machine > (RAM, disk, cpu). As you say it, those are the limits, usually hardware limited, but sometimes also software limited. But, this is not the question, wether you have a fast mailer system, or a slow mailer system. The question is still if you can use what you have today, in the way you want to use it. It also gives the sysop of a system the option to choose where he wants to have the services put. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1445 [1995] Scn From : Rune Johansen 2:210/20 08 Nov 97 01:43:12 To : Ward Dossche 09 Nov 97 23:19:26 Subj : Replying ------------------------------------------------------------------------------- > Just a small thought ... when I look in my inbound for this conf every day I > see 15 replies from "a", 12 reactions from "b", etc ... You're correct in your observations. >This is very confusing, it seems like if we're debating a religious issue here True. > At present I have stopped reading this flow and only picking-up messages to > myself or to "all". Let me ask you, as a ZC, and your opinion: If a node are to have a extra functionality to it's existant nodenumber (adding IP capability), do you believe that the technical requirements of policy would apply (requiring FTS-0001)? If a node can be IP-only, would it be required to follow FTS-0001? If it is required to follow FTS-0001, should it be on one or all ports/transport protocols? Most of the debate is around these questions. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1446 [1995] Scn From : Rune Johansen 2:210/20 07 Nov 97 22:41:02 To : Marco d'Itri 09 Nov 97 23:19:26 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- > Tomorrow that will be the same. There is no reason to run binkp over telnet > or over VMP. Don't you see that there are other scenarios than your own? Don't you see that a non-ip-directly-implemented-in-the-mailer mailer might have BinkP implemented as a session level protocol, that can use a VMP connection? Regardless of the fact that a separate BinkD mailer can be run alongside. Sound like MS to me... There is no reason to run Linux, when you can run Windows on you machine. It also got a word processor :-) >> There is need for 3 flags: Telnet (IPT), TCP connection (IPR) and VModem > (IPV). > All of those flags implies that the handshake used is EMSI or FTS-1. BNP is > a different handshake but is runs only over RAW. BinkP runs over IPT and IPV too. You don't run it over other than IPR. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1447 [1995] Scn From : Rune Johansen 2:210/20 07 Nov 97 22:26:56 To : Nick Soveiko 09 Nov 97 23:19:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > so what? that still does not automatically mean that for a multiport > implementation mandate for fts-1 capability refers to each port. as a maximum > it implies that there should be a way to connect to a node using fts-1. but > that's it. the rest is your imagination. See my explanation to Pablo about why I write all of this. >> You say that there is no reason to suspect that some mailer will >> ever do this. > *i* didn't say this. that's not a quote from my message. OK, I did not see _who_ wrote it. I assumed it was you. >your proposal rules out even the nodes that already have fts-1 pstn capability > and certainly would like to announce an extended capability that they have: > binkp over tcp/ip multiplexed by ports. True. >> First of all, you use a protocol that is not documented completely >> (to the public), > even the rather incomplete documentation (that was available before i assumed > documenting this project) allowed to implement the protocol on a different > platform and in a different programming language. and it proved to be 100% > interoperable with binkd. By sheer luck then, I assume :-) >> and does not have the possibility to fallback to a commonly >> implemented mailer handshake protocol, > wrong. it's done in argus. Yes, it is absolutely being done in Argus, and in BBBS. But that's no thanks to the documentation of the protocol. >> And, I am also saying that BinkD mailer implementation of today >> does not alone meet the requirements of being a self-sustained >> node in Fidonet. > you are arguing for the wrong point here. binkd implementation of today can > perfectly serve as an additional capability to any fidonode with ip access. > your proposal doesn't take this into account. I am arguing it from the point of wether there should be a common session level protocol in the mailer handshake, and if that is to follow policy. My proposal does not take an extended nodelist format into accounts, but it takes the current format, with a minor modification, and applies it to the use on several different types of transportation. If we say that the IP part of a multi-functionality node does not need a common session level protocol, I will stop arguing that we in that case must use the one defined in policy. It would then also imply that a IP-only node would not need that either. If a common session level protocol is not needed, then a common IP transport protocol is not needed either. That means that a Telnet-protocol node cannot be contacted by a raw TCP node, even if they are using the same session level protocol. So, if you want to connect to another node that does not run the same transport protocol _and_ session level protocol as you, you have to get hold of software that is compatible with the one you want to contact. It's that simple. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1448 [1995] Scn From : Ward Dossche 2:292/854 08 Nov 97 10:05:52 To : Anatoli Gulidov 09 Nov 97 23:19:26 Subj : Re: !!!!!!!!!!!!!!!!!!!! ------------------------------------------------------------------------------- Anatoli, > your messages don't have Msgid. MSGID is not a technical requirement and dupes are caused by people with irresponsible links. \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1449 [1995] Scn From : Lawrence Garvin 1:106/6018 08 Nov 97 09:20:04 To : Rune Johansen 09 Nov 97 23:19:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: > Hopefully, though, down the road, we'll have nodelist compilers and > mailers that have support for FQDNs in one of the text fields, and > then a FQDN and PSTN-telco number can coexist on the same node number. RJ> Where should future transport networks be placed then? I'm not understanding your question. All I'm buckin' for is the right to put my domain name in one field and my PSTN telno in the other field, so that I can have the _SAME_ node number on both mailer sessions. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1450 [1995] Scn From : Rune Johansen 2:210/20 07 Nov 97 22:32:58 To : Marco d'Itri 09 Nov 97 23:19:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> It is a OS/2 program, that uses EMX. EMX exist for DOS, doesn't it? :-) > We have the source, so we can compile NlMake for any platform. Do you have it available for FREQ on your IP node? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1451 [1995] Scn From : Lawrence Garvin 1:106/6018 08 Nov 97 09:05:34 To : Rune Johansen 09 Nov 97 23:19:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: RJ> I have doen quick tests here with NLMake, and it will allow me to RJ> put FQDN's in phone field, it will allow me to use colons in phone RJ> field, it will allow me to put things in the phone field, even RJ> though it is a Pvt entry, also if it is a point entry. Seems like RJ> it does all we want? :-)) Sure does. RJ> It is a OS/2 program, that uses EMX. EMX exist for DOS, doesn't it? RJ> :-) As far as I know. The question is, does a DOS version of the program exist, or can be compiled? btw, where can I get a copy of this NLMAKE utility? --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1452 [1995] Scn From : Lawrence Garvin 1:106/6018 08 Nov 97 09:08:28 To : Rune Johansen 09 Nov 97 23:19:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: >> If you take a look at the current nodelist you'll find that many >> nodes already have multiple nodenumbers. > Only in Zone 2, Kim. :( RJ> Look at 1:203/34 and /35. Same system, same sysop, two different RJ> modems (by looking at the capabilities). I don't have a 203/34 and 203/35, but I do have a 205/34 and 205/35. I also note that those two nodes are at -different- telephone numbers. I'm referring to the situation where two different nodes are at the -same- telephone number, and -that- is generally not permitted in the nodelist. > If my IP node has a different node number, you would expect the > downlinks to configure their system to toss to -one- node, and > actually -send- to another? RJ> Yes. That is what is being done today, Caca... not on any system that -I- have observed. RJ> and that is what is available with AKA listing in handshake. I RJ> toss and do all things out of my 2:210/20 AKA. But, those wanting RJ> to use my ISDN line has got to poll 2:210/21. They get 2:210/20 in RJ> the AKA list, and sees that they can send mail destined for RJ> 2:210/20 there. Yeah.... and how do they make the translation between the tosser tossing to/from 210/20, and the mailer knowing it should send to /21? Last I heard, the tosser will address the packet to /20, and the only way to work around that is to -ROUTE- the echomail bundle. > What really would happen is that both nodes, PSTN and IP, would > present -both- node numbers all of the time, and share a single > outbound directory. But if that is the configuration, then the second > node number is totally redundant, and thus, totally unnecessary. RJ> It is not redundant, as it gives you several possibilities to RJ> connect to the nodes. Do you actually mean that listing 10 RJ> different lines (if you don't have huntgroup phonenumber) is RJ> totally unneccessesary? Not only unnecessary, but generally PROHIBITED. Only in Zone 2 have nodes been allowed to create redundant non-admin entries with the same telco number. Here in Zone 1 one is expected to have a -different- telephone number for an additional node listing. I challenge you to find a -legitimate- node entry in the Zone 1 nodelist segment where two different nodes have the same telno. Admin nodes do not count (e.g. /0, HUB). --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1453 [1995] Scn From : Lawrence Garvin 1:106/6018 08 Nov 97 09:15:36 To : Rune Johansen 09 Nov 97 23:19:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: > Except that is not necessary at all! Perhaps not in Europe, but in > the U.S. I can put an analog V.34 modem -and- a V.110/V.120 ISDN > modem on the SAME telephone number. The ISDN modem senses whether > the inbound call is digital or analog, and if it's analog, it'll > route it to the POTS port and the V.34 modem will answer. If it's > digital, then the ISDN modem will answer and you get a V.110/V.120 > connection. Both happen at the same telephone number, though. RJ> Can you receieve a analog call on the POTS port if your ISDN RJ> adapter is busy doing a session? If the ISDN router has a single 64K session running, the inbound analog call will be routed to the other 'channel' and it will be answered. If the ISDN router has a 128K session running, the user will receive a busy signal. > Why not? Can you not plug your PSTN modem into the POTS port on the > back of the ISDN adapter? Or is this built in to the ISDN adapter? If > it is built in, then your limitation is the fact that you have two > physical devices, not that your ISDN adapter is incapable of > providing both services on the same telephone number. RJ> I have two pysical devices, alas two different phone numbers. I have -THREE- physical devices, Rune. I have a Cisco 766 ISDN Router with two POTS ports. And two V.34 modems, each of which plugs into the POTS port on the back of the ISDN router. I have -two- telephone numbers on the router, one for each 64K channel. Each 64K channel shares a telephone number with one of the analog modems. See listings for 1:106/500 and 1:106/8277. RJ> Also, my analog modem has capabilities that the analog part of my RJ> ISDN adapter lack. So, the capabilities are not identical, so they RJ> could not be correctly put on the same nodenumber. But you did not answer my question. Can you plug your PSTN modem into the POTS port on the back of the IDSN adapter, and have it ring when the IDSN telno is called? --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1454 [1995] Scn From : Rune Johansen 2:210/20 07 Nov 97 22:36:22 To : Marco d'Itri 09 Nov 97 23:19:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Mailers that is properly implemented does not care about banner, as long as >> they see the init of their implemented handshake protocols. > This is not the point. The point is mailers does not needs any banner. I know they don't _need_ banners. I just say that some have got them! > Well, maybe you should explain us why this is a good thing. You are not > going to use all of them in the next centuries, so why don't you use one > port for every service? It's more clean and let you free to start and > stop and upgrade one service at time without shutting down the whole system. You are assuming things that applies to you, and maybe not to others. What do you know if I am to use those services in the next century or not? >> Not yours, I believe. > Looks like you don't use the one most linux users run. True. Actually, I don't run Linux at all. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1455 [1995] Scn From : Lech Szychowski 2:480/33.7 08 Nov 97 15:40:00 To : Lawrence Garvin 09 Nov 97 23:19:26 Subj : IP-access ------------------------------------------------------------------------------- [lotsa stuff about "SMTP<->Fido" gatewaying] > Therefore... while I'm sure the -desire- exists, the technological > hurdles to merge the two capabilities is difficult, at best, for > an experienced person to deal with. This still does not answer my original question, which was "why would one want to advertise a separate 'SMTP address' while he already has one - the default 'fX.nY.zZ.'?". > Of course, there's also the simple issue involving domain registrations, > name servers, et. al. that become major hurdles to many as well. Not for Fidonet if we stick to the default names as show above; "fidonet.org." is already registered and delegated, it's up to us to delegate further subdomains. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1456 [1995] Scn From : Lech Szychowski 2:480/33.7 08 Nov 97 16:46:00 To : Pablo Saratxaga 09 Nov 97 23:19:26 Subj : IP-access ------------------------------------------------------------------------------- >>> Each fqdn that wants to receive email *MUST* have an MX, it can point to >>> itseld. But whithout an MX there is no guarantee at all that mail will >>> be sent. > LS> Are you 101% sure about that? > Yes. I still dare to disagree a bit. I think you misinterpret a bit what you've quoted below. > LS> I think vast majority of existing MTAs will first try MX for > LS> a given FQDN and if it fails (ie DNS query returns no MX type > LS> records) they go for the A record(s) instead. > But not all, hence I said that there is no guarantee. Well, there is only one way of getting the right answer - look it up in RFCs. And that's something I'll do next week. > TryNullMXList > [...] > you may want to try to connect directly to that host > as though it had no MX records at all. First, it says "as though it had", not "when it has". Second, this option is supposed to deal with situations when host A that has mail to be delivered to addres B is itself listed as MX for address B, has not been configured to recognize mail addressed to B as local and there is no other better (ie lower priority) MX listed (see "sendmail, 2nd" p.766). I've done some tests: =================================================================== $ grep -i trynull /etc/sendmail.cf #O TryNullMXList $ echo /mx lech.pse.pl | sendmail -bt -d8.8 > ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter
> getmxrr(lech.pse.pl, droplocalhost=0) ;; res_querydomain(lech.pse.pl, , 1, 15) ;; res_query(lech.pse.pl, 1, 15) ;; res_mkquery(0, lech.pse.pl, 1, 15) ;; res_send() ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48007 ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; lech.pse.pl, type = MX, class = IN ;; Querying server (# 1) address = 194.92.3.7 ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48007 ;; flags: qr aa rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0 ;; QUESTIONS: ;; lech.pse.pl, type = MX, class = IN ;; AUTHORITY RECORDS: pse.pl. 345600 IN SOA ns.pse.pl. hostmaster.pse.pl. ( 97110502 ; serial 3600 ; refresh (1 hour) 3600 ; retry (1 hour) 7776000 ; expire (90 days) 345600 ) ; minimum (4 days) ;; rcode = 0, ancount=0 ;; res_querydomain(lech.pse.pl, pse.pl, 1, 15) ;; res_query(lech.pse.pl.pse.pl, 1, 15) ;; res_mkquery(0, lech.pse.pl.pse.pl, 1, 15) ;; res_send() ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48008 ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; lech.pse.pl.pse.pl, type = MX, class = IN ;; Querying server (# 1) address = 194.92.3.7 ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48008 ;; flags: qr aa rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0 ;; QUESTIONS: ;; lech.pse.pl.pse.pl, type = MX, class = IN ;; AUTHORITY RECORDS: pse.pl. 345600 IN SOA ns.pse.pl. hostmaster.pse.pl. ( 97110502 ; serial 3600 ; refresh (1 hour) 3600 ; retry (1 hour) 7776000 ; expire (90 days) 345600 ) ; minimum (4 days) ;; rcode = 3, ancount=0 ;; res_querydomain(lech.pse.pl, pse.dyster, 1, 15) ;; res_query(lech.pse.pl.pse.dyster, 1, 15) ;; res_mkquery(0, lech.pse.pl.pse.dyster, 1, 15) ;; res_send() ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48009 ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; lech.pse.pl.pse.dyster, type = MX, class = IN ;; Querying server (# 1) address = 194.92.3.7 ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48009 ;; flags: qr aa rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0 ;; QUESTIONS: ;; lech.pse.pl.pse.dyster, type = MX, class = IN ;; AUTHORITY RECORDS: pse.dyster. 86400 IN SOA poczta.pse.dyster. lech7.pse.pl. ( 97101602 ; serial 7200 ; refresh (2 hours) 3600 ; retry (1 hour) 1600000 ; expire (18 days 12 hours 26 mins 40 secs) 86400 ) ; minimum (1 day) ;; rcode = 3, ancount=0 ;; res_querydomain(lech.pse.pl, dyster, 1, 15) ;; res_query(lech.pse.pl.dyster, 1, 15) ;; res_mkquery(0, lech.pse.pl.dyster, 1, 15) ;; res_send() ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48010 ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; lech.pse.pl.dyster, type = MX, class = IN ;; Querying server (# 1) address = 194.92.3.7 ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48010 ;; flags: qr aa rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0 ;; QUESTIONS: ;; lech.pse.pl.dyster, type = MX, class = IN ;; AUTHORITY RECORDS: dyster. 86400 IN SOA pcunixpse01.dyster. lech7.pse.pl. ( 97102201 ; serial 7200 ; refresh (2 hours) 3600 ; retry (1 hour) 1600000 ; expire (18 days 12 hours 26 mins 40 secs) 86400 ) ; minimum (1 day) ;; rcode = 3, ancount=0 getmxrr: res_search(lech.pse.pl) failed (errno=0, h_errno=4) dns_getcanonname(lech.pse.pl, trymx=0) dns_getcanonname: trying lech.pse.pl. (ANY) ;; res_querydomain(lech.pse.pl, , 1, 255) ;; res_query(lech.pse.pl., 1, 255) ;; res_mkquery(0, lech.pse.pl., 1, 255) ;; res_send() ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48011 ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; lech.pse.pl, type = ANY, class = IN ;; Querying server (# 1) address = 194.92.3.7 ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48011 ;; flags: qr aa rd ra; Ques: 1, Ans: 2, Auth: 6, Addit: 6 ;; QUESTIONS: ;; lech.pse.pl, type = ANY, class = IN ;; ANSWERS: lech.pse.pl. 345600 IN HINFO i486 Linux 2.0.x lech.pse.pl. 345600 IN A 194.92.3.7 ;; AUTHORITY RECORDS: pse.pl. 345600 IN NS ns.pse.pl. pse.pl. 345600 IN NS ns1.pse.pl. pse.pl. 345600 IN NS ns2.pse.pl. pse.pl. 345600 IN NS psea8.pse.pl. pse.pl. 345600 IN NS bilbo.nask.org.pl. pse.pl. 345600 IN NS ns.polbox.pl. ;; ADDITIONAL RECORDS: ns.pse.pl. 345600 IN A 194.92.3.6 ns1.pse.pl. 345600 IN A 195.117.106.6 ns2.pse.pl. 345600 IN A 193.59.149.6 psea8.pse.pl. 345600 IN A 193.59.149.3 bilbo.nask.org.pl. 109918 IN A 148.81.16.51 ns.polbox.pl. 285490 IN A 195.116.5.14 YES dns_getcanonname: lech.pse.pl getmxrr(lech.pse.pl) returns 1 value(s): lech.pse.pl. $ sendmail -bd -d0.4 < /dev/null > Version 8.8.8 Compiled with: LOG MATCHGECOS MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETUNIX NEWDB QUEUE SCANF SMTP USERDB XDEBUG canonical name: lech.pse.pl a.k.a.: lech UUCP nodename: lech a.k.a.: lech7.pse.pl a.k.a.: lech a.k.a.: lech7 a.k.a.: [194.92.3.7] a.k.a.: [127.0.0.1] a.k.a.: [10.5.1.7] a.k.a.: [195.117.106.7] ============ SYSTEM IDENTITY (after readcf) ============ (short domain name) $w = lech (canonical domain name) $j = lech.pse.pl (subdomain name) $m = pse.pl (node name) $k = lech ======================================================== It shows that even if there are no MX records for an address and TryNullMXlist is not set, sendmail cares for A record. > I also experienced the problem of undeclared MX recently when I was > working whith my uplink on setting up his sendmail for forwarding > *.chanae.stben.be to me; he had put a *.chanae.stben.be MX entry FWIW, I think that if it was just about getting _his_ sendmail to do this, you'd have had less hassle if you went for putting one more rule in ruleset 0 - but it's just my $.02. I think now we are really a way out of scope of this echo :) It's time be better moved to email; you can reach me as lech7@pse.pl. > Yes, I should have written: > f33.n480.z2.fidonet.org. A 123.45.67.89 > MX 1 f33.n480.z2.fidonet.org. > MX 10 elsewhere.net. > *.f33.n480.z2.fidonet.org. MX 10 f33.n480.z2.fidonet.org. > MX 20 elsewhere.net. > sorry for the mistake Yes, the above is IMHO an excellent example of how things should be done. Even if MTAs can deliver to A in absence of MXs, listing a host as an MX for itself saves one delivery lookup (usually one out of two, that's actually 50% :). Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1457 [1995] Scn From : Lech Szychowski 2:480/33.7 08 Nov 97 15:54:00 To : Pablo Saratxaga 09 Nov 97 23:19:26 Subj : IP-access ------------------------------------------------------------------------------- > I doubt there is one single machine whose primary (as the one in the > PTR entries) domain is fidonet.org Well, you're most likely right. But - excusez les mots - so what? If we want IP-capable nodes, we want A records in fidonet.org (sub)domain(s). Yes, we could live without them (use CNAMEs instead and keep all MX'es out of fidonet.org) but it does not seem to me to have any significant advantages over having A RRs. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1458 [1995] Scn From : Rune Johansen 2:210/20 07 Nov 97 22:31:54 To : Slava Filimonov 09 Nov 97 23:19:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Wake up, man! Who said that policy was written with taking into account ip? >With closer look one can find policy in total contradiction with ip reality... That is exactly why we must ask these questions. To get the ip reality into the fidonet nodelist, we have to convince the other, that don't have the capability, that it would be a benefit to the fidonet to do so. Is this the correct (and most acceptable) way to do that: We want IP nodes to be listed in fidonet. It will not allow for FTS-0001 for a majority of the nodes, as they run compeletely proprietary protocol (seen from the modem side of the list), and it will not be completely certain that they even can talk to eachother (Telnet vs raw TCP nodes) ?? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1459 [1995] Rcv Scn From : Rune Johansen 2:210/20 07 Nov 97 22:12:40 To : Lothar Behet 09 Nov 97 23:19:26 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> and we get the ZC's to adapt several new user flags. > Hmm, why only "user" flags? Easies way of getting new flags in, and use them for a while, so they can be widely used, and included as a ordinary flag. If noone uses a proposed flag, it's of no use allowing it in the nodelist on a permanent basis either. >The rule of universal direct access was clearly broken at that moment, when th > first ISDN-only node arised in the nodelist, but on base of Bell-103/V.22 it > never existed. True, and that would allow us to also include IP-only nodes. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1460 [1995] Scn From : Lawrence Garvin 1:106/6018 08 Nov 97 17:51:08 To : Denis McMahon 10 Nov 97 05:39:52 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Denis McMahon said in a message to Lawrence Garvin: LG> WHEN I can get my node listed in the nodelist with an IP address LG> or a FQDN, and I can dial an IP address or FQDN with my CURRENT LG> SOFTWARE -- which btw, can be done -- I'm already doing it LG> 'unofficially' -- Then, and Only Then, will I be interested in LG> worry about capabilities for some "future generation mailer". DM> OK, the implication here is that your software is capable of DM> making outgoing IP connections (using transport level protocol x DM> whatever x is) for FTN session level communication, yes? Yes. DM> If so, the question as to what we put in the nodelist comes down to DM> what your existing software requires in the nodelist, does it not? Or any OTHER mailer as well. As of right now the -ONLY- field that an existing mailer can use to make a determination on where to place an outbound call is the telno field. DM> So, what information does your software look for in the nodelist to DM> make these IP calls? I compile a hand built local nodelist segment that places the IP address in the telno field, and my mailer tags that character string right on the back of an ATDT, and sends it to my virtual modem. It need not be an IP address, it could also be an FQDN -- but it DOES have to be in the telno field. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1461 [1995] Rcv Scn From : Pablo Saratxaga 2:293/2219 08 Nov 97 07:22:00 To : Lothar Behet 10 Nov 97 05:39:52 Subj : Re: IP - Call for opinion votes ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 05 Nov 97 09:12:00 +0100, Lothar Behet said: AH>> IP nodes should be CM as standard, and only anything else if it's AH>> stated by a IPTxy or similar flag. LB> This might be ZMH-only too, i assume? No, ZMH is useless, almost nobody uses it. The Txy flags are much more important as they show the *real* online time as opposed to the *theorical* online time. But anyway, if the default for IP is to be CM that obviously includes ZMH so there isn't any problem here :) -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1462 [1995] Scn From : Lawrence Garvin 1:106/6018 08 Nov 97 17:54:46 To : Denis McMahon 10 Nov 97 05:39:52 Subj : IP-access ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Denis McMahon said in a message to Lawrence Garvin: DM> Lawrence Garvin wrote to Denis McMahon: LG> Denis McMahon said in a message to Lawrence Garvin: DM> Agreed, however I was disputing the suggestion that nameserver DM> entries should be handled by the NCs, how many NCs run nameservers? LG> Who said anything about the -NC- running the nameserver? ? ? ???? DM> Ask Bjorn Hansen (I hope I spelled it right), in the message that I DM> originally replied to suggested that the nameserver should operate DM> at the net level. LG> Yeah... so.... my question stands: Who said anything about the -NC- LG> running the nameserver? DM> Ask, in the message I was replying to when you joined in this DM> particular thread. :-) Okay... then.. let me spell out my point, as it seems to be entirely missed. Just because one suggests that a nameserver -SHOULD- be run at the net level, does _NOT_ mean that the NC is the person who must do this. That, Denis, is my point: "Who said anything about the -NC- running the nameserver?" Ask merely suggested a NET-level nameserver, not an NC-run nameserver. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1463 [1995] Scn From : Southern Star 1:396/1 09 Nov 97 00:29:04 To : Moderator 10 Nov 97 05:41:28 Subj : Welcome to the Backbone ------------------------------------------------------------------------------- Hello. Your echo is now on the Zone 1 Backbone! This message to help get some of the links established. If you have any private Zone 1 feeds, now is the time to switch them to the Zone 1 Backbone. Thanks, Zone 1 Backbone Operations --- Harvey's Robot v6.00 * Origin: Southern Star - sstar.com - V.32b/V.34+ - 504-885-5928 - (1:396/1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1464 [1995] Scn From : GARY PETERSEN 1:290/111 09 Nov 97 10:41:00 To : RUNE JOHANSEN 10 Nov 97 05:41:28 Subj : RE: FTS-0001 in IP nodes ------------------------------------------------------------------------------- On Nov 05, 1997 10:14pm, RUNE JOHANSEN wrote to ALL: RJ> I seem to be one of the few that keeps on hammering at the FTS-0001 RJ> part. Just to make the records straight, this is my key things: RJ> - Todays policy says that a node needs to do FTS-0001. RJ> - Would Policy need a rewrite to acknowledge that not every port where RJ> there is a mailer need to do FTS-0001? Is it enough that ONE port on a RJ> nodenumber does it? RJ> IF a node would need only one port with FTS-0001, does that mean that a RJ> node with multiple nodenumbers only requires FTS-0001 on ONE of it's RJ> nodenumbers? I believe that every system in FidoNet should have at least one node that can be connected via modem and mailer, using the standard connection protocols for mailers. Other nodes could be designated as IP only, but every FidoNet system must be connectable via telephone front end. FWIW, my opinion is that FTS-0001 compliance should be scrapped altogether. That is an entirely different matter, however. Gary Petersen gary@mwx.paonline.com --- Platinum Xpress/Win/Wildcat5! v2.1b * Origin: Midwest Xpress Newton, Iowa (1:290/111) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1465 [1995] Scn From : Rune Johansen 2:210/20 09 Nov 97 01:52:18 To : Ward Dossche 10 Nov 97 05:41:38 Subj : Re: !!!!!!!!!!!!!!!!!!!! ------------------------------------------------------------------------------- >> your messages don't have Msgid. > MSGID is not a technical requirement and dupes are caused by people with > irresponsible links. True, they are not technical requirements, but they do keep the possibility for dupeloops lower than without. With fidonet echomail moving away from star-topology distribution, means for detecting such loops are getting more and more cruicial. With two parallell links that "interconnect" in each end, it is almost impossible to check it with seen-by control. I am certain that you know the technicalities behind this, so I won't explain it here. :) When it comes to the question about who is "responsible" for the loops, it can be equally difficult. If you get your message back through another of your links, _you_ can cut one of them, since they already get the echo "from the other side". It is difficult to point out _where_ the fault really lies, as all links in a loop are equally responsible. So, to keep dupe loops as small as possible, would you be so kind to activate a MSGID system at your system? It would also help systems that use MSGID/REPLY for thread linkage as a side effect. :-)) --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1466 [1995] Scn From : Rune Johansen 2:210/20 09 Nov 97 01:42:50 To : Dima Maloff 10 Nov 97 05:41:38 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Good reason. So I'd suggest either to use binkp only ;), or to put all that > EMSI/IEMSI/banner staff into one binkp's M_NUL frame. And then, I ask: Why should I consider putting my other protocol inits iside a fram that only one protocol needs to discard, when the mailer on "the other side" can do that himself? It's a matter of programming on the callers side, to scan the in-buffer for the init frame, not just looking at byte 1. Well, it's up to the mailers programmer to consider if he wants the program to talk to all BinkP implementations, or just parts of them. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1467 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 10 Nov 97 06:46:26 To : Pablo Saratxaga Subj : IP - Call for opinion votes ------------------------------------------------------------------------------- Hello Pablo! On 08 Nov 97 wrote Pablo Saratxaga to Lothar Behet: AH>>> IP nodes should be CM as standard, and only anything else if AH>>> it's stated by a IPTxy or similar flag. LB>> This might be ZMH-only too, i assume? PS> No, ZMH is useless, almost nobody uses it. It might get real important, if the definition of CM is read as "Nothing else than a mailer uses this line", as some guys in R24 try now. PS> The Txy flags are much more important as they show the *real* online PS> time as opposed to the *theorical* online time. Did you monitor the contents of Txy at change of time-offset between summer- and winter-time, as this is relative to UTC? PS> But anyway, if the default for IP is to be CM that obviously includes PS> ZMH so there isn't any problem here :) No Problem :) Regards, Lothar --- GoldED/2 3.00.Alpha5+ * Origin: Life: a bad game, but graphics is really good (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1468 [1995] Scn From : Pedro Lima 2:362/21 09 Nov 97 07:34:30 To : Frank Ellermann 10 Nov 97 18:18:44 Subj : IP-node management (was: Proposal for listing [...]) ------------------------------------------------------------------------------- Hi, FE> *Cs unable to verify IP-nodes would be in trouble, which technical FE> solutions (except from dedicated IP-nets to begin with) do you have ? Solutions as in general solutions, I have none. I also don't have them for ISDN nodes nor even for modem nodes, for that matter, because incompatibility does exist, be it by the different technologies, modems with odd behaviors, poor line conditions... It's somewhat logical however that, for a new node's request to reach the relevant *C (usually the NC), there's probably some kind of way of Fido communication possibility with him. FE> Maybe a volunteer offering IP-checks as function request or by some FE> kind of mail robot ? It's a possibility, but it doesn't stand as a general solution either. FE> It's not necessarily only a political question, Point taken. FE> if we could have some technical answers, _before_ it bites us... >:-) This problem may have technical solutions, but I'm sure these would require major changes on the current procedures and organization of FidoNet. So *for the time being*, I prefer the political solution, which is the NC to evaluate the connectivity possibilities he has with such nodes and decide accordingly, thus not fragmenting the social integrity of a network by us having to place these nodes in a different place. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1469 [1995] Scn From : Pedro Lima 2:362/21 09 Nov 97 05:22:34 To : Rune Johansen 10 Nov 97 18:18:44 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- RJ> .. during ZMH. You can also support higher standards, it says, but you RJ> still have to follow FTS-0001. Please quote it in the context it's being said. "FTS-0001" is obviously being used in that phrase as "the protocol defined by the current FTSC publication". FTS-1, although it remains the current FTSC publication, actually documents more than just the protocol. Let me just pick the first example I can find of this, there are several more: -=-=- 1. Basic Requirements for a FidoNet Implementation Compatibility is a set of abilities which, when taken as a whole, make it safe to list a net or node in the FidoNet nodelist. In other words, if another node should attempt contact, does it have a reasonable chance of successful communication? This is a social obligation, as the calling system pays money for the attempt. Conversely, an implementation should be able to successfully contact other systems, as life is not a one-way street. -=-=- Need I continue? Take for example IP nodes which have a leased line. Whether they use the line or not, they pay for it exactly the same. Relate this to the "social obligation" and to the "Basic requirements", and you'll begin to understand that the ideas upon which FTS-1 was constructed (and this includes the protocol) are limited to the specific set of circumstances found in the PSTN, and we're now talking about the Internet as an alternative transport which is a completely different piece of cake. Isn't this enough to *at least* question the validity of FTS-1 when what we're talking of are IP nodes? RJ> Yes, nobody needs to adhere to anything, nobody needs to follow specs, RJ> nobody need to have a phone line. No. Quite simply, common sense imposes that some principles are reviewed in different circumstances. This doesn't imply that in the previous circumstances those same principles loose their validity. RJ> But, IF we get an IC, Policy would be valid again. Actually, the last IC to issue a nodelist was not the last IC we had. What makes you think that having a new IC would suffice to us having FidoNet back without which we can't speak of Policy validity? Naturally, this is a purposefully strict reading of Policy. What is forcing us not to have such a strict view of Policy, if not common sense? So, what I'd like to have is a justification, per common sense, for keeping the FTS-1 protocol mandatory with IP nodes, as everything is indicating me that this would be a silly move by the technical point of view. Some of P4.07 considerations, as several of FTS-1 considerations, are "stained" by the concept of PSTN connectivity, and as they don't serve a meaningful and useful purpose to FidoNet in the IP scenario, I can hardly accept them (these considerations, not the whole documents) as valid justifiers. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1470 [1995] Scn From : Pedro Lima 2:362/21 07 Nov 97 06:36:06 To : Rune Johansen 10 Nov 97 18:18:44 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- RJ> Yes, you would actually have to pay attention to what happens around RJ> you. Yes. This is not the common behavior of sysops in general, though. If a flag existed for denoting a specific transport, filtering would be much simpler and safer, since even when new protocols are added, changed, or removed for that transport, the mailer would remain well configured. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1471 [1995] Scn From : Lawrence Garvin 1:106/6018 09 Nov 97 18:03:18 To : Ward Dossche 10 Nov 97 18:18:44 Subj : IP-connectivity ------------------------------------------------------------------------------- Ward Dossche said in a message to Pedro Lima: WD> Pedro, >> Is the reference 'FTS-0001' copyrighted? > WD> Yes. > Ok, then we'll have to interpret what's said in P4 in a different way > (as I believe it was intended in the first place anyway), or replace P4 > altogether, if we want to do it 'by the book'. WD> So far, concerning trying to get IP in, I think nothing is (nor can WD> be) according to the book. WD> WD> BTW, some guys are threatening me with formal complaints if I WD> continue this effort. I think they picked the wrong target to waste WD> ammunition. I thought we'd cleared this one up. :) The -reference-, aka the TITLE, is not copyrighted nor is it protected. At best it is merely an INDEX into a listing maintained by the FTSC (whatever that may be). Randy's biggest mistake in creating and publishing FTS-0001 was in not giving it a unique trademarkable name -- the -same- mistake Intel made when they make the 80x86 processor line. Wazoo is trademarkable, EMSI is trademarkable, the _CONTENTS_ of the document describing the protocol specifications contained in the document known as FTS-0001 are copyrightable, the _CONTENTS_ of the document describing the protocol specifications contained in the document known as FTS-0006 are copyrightable, the _CONTENTS_ of the document known as FSC-0056 are copyrightable. However, the -names- "FTS-0001", "FTS-0006", and "FSC-0056" ARE NOT! :) As for those who would threaten a complaint over taking an initiative to improve the use of technology in Fidonet, I say "call their bluff!". --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1472 [1995] Scn From : Pedro Lima 2:362/21 07 Nov 97 06:36:22 To : Rune Johansen 10 Nov 97 18:18:44 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- RJ> Ohmygod! I have been in a non-existant network for over three years! By your reasoning, that's 100% correct. Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1473 [1995] Scn From : Lawrence Garvin 1:106/6018 09 Nov 97 17:41:26 To : Yuri Teterin 10 Nov 97 18:18:44 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Yuri Teterin said in a message to Rune Johansen: RJ> As long as BinkD cannot do FTS-1 fallback, it will not meet the RJ> requirements of a Fidonet Nodestatus. If you have a mailer that RJ> has got the fallback, you can use it. YT> But it can be stated rather definitely that none of existing YT> mailers run BinkP and FTS-0001 at the same port, and there is no YT> reasons to suspect that some mailer will ever do this. Okay.. YT> So your proposal will actualy cut all BinkP-based part of FIDO YT> and leave it out of nodelist. Not necessarily true, Yuri. YT> This can not force somebody to add FTS-0001 compatibility to they YT> BinkP implementation, but will force all BinkP-comunity to relay YT> on themselves only and develop they own structures with own YT> nodelist (or Binkp-list, or own DNS, supporting first of all YT> BinkP-nodes), may be - with own policy of mail routing. All it would require is that BinkP users have -some- sort of FTN mailer running on their -NODE- that will support an FTS-0001 session. Heck, the compliant mailer could even be the -PSTN- mailer, for all that really matters -- of course, such a configuration would -require- that the nodelist support FQDN and TELNO entries for the same NODE number. :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1474 [1995] Scn From : Axel Golob 2:246/3001 09 Nov 97 23:43:00 To : Ward Dossche 11 Nov 97 07:08:04 Subj : !!!!!!!!!!!!!!!!!!!! ------------------------------------------------------------------------------- >> your messages don't have Msgid. > MSGID is not a technical requirement and dupes are > caused by people with irresponsible links. or ignorants like you. Gruss Axel. --- * Origin: MARS +49-7172-9191- 14 = V32B/V42B 15 = ISDN X75 (2:246/3001) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1475 [1995] Scn From : David Moufarrege 1:2613/404 09 Nov 97 17:47:10 To : Southern Star 11 Nov 97 07:08:04 Subj : Welcome to the Backbone ------------------------------------------------------------------------------- Hello Southern! In a message Southern Star wrote to Moderator: SS> Your echo is now on the Zone 1 Backbone! This message to help get SS> some of the links established. If you have any private Zone 1 feeds, SS> now is the time to switch them to the Zone 1 Backbone. Which Zone 1 backbone would that be? This echo has been carried by the FidoSpine Zone 1 backbone for several weeks. -=David=- _____________________________ | e-mail : david@kraut.xg.com | | FidoNet: 1:2613/404 | | 1:13/0 | ----------------------------- ... Nothing is ever constant, unless it is dead. --- * Origin: Kraut Haus * Rochester, NY * 716-359-0871 (1:2613/404) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1476 [1995] Scn From : Lawrence Garvin 1:106/6018 09 Nov 97 19:51:30 To : Lech Szychowski 11 Nov 97 07:11:46 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Lawrence Garvin: > Therefore... while I'm sure the -desire- exists, the technological > hurdles to merge the two capabilities is difficult, at best, for > an experienced person to deal with. LS> This still does not answer my original question, which was "why LS> would one want to advertise a separate 'SMTP address' while he LS> already has one - the default 'fX.nY.zZ.'?". Ahhhhh.... my apologies, then, I never grasped that as the question. Please, allow me to answer that question, at this time. Why, you ask, would I prefer (a) to (b), where: (a) Lawrence.Garvin@f6018.n106.z1.fidonet.org and (b) lawrence@eforest.houston.tx.us or lawrence@eforest.tcrs.org I think, based on appearance alone, not to mention ease of use, and simplicity when diseminating the address to others, (b) is the obvious preference. Now, if we're talking ONLY about Fidonet nodelist issues, then it makes no sense at all for me to 'reject' the idea of receiving mail at (a); however, it should also be noted that I don't control the mail gateway that handles (a), I -do- control the mail gateway that handles (b), and -that- is the technical reason for preferring an address of my own to the fidonet.org address. > Of course, there's also the simple issue involving domain registrations, > name servers, et. al. that become major hurdles to many as well. LS> Not for Fidonet if we stick to the default names as show above; LS> "fidonet.org." is already registered and delegated, it's up to us LS> to delegate further subdomains. Yeah... but therein comes the political problems. It's just been brought to my attention that the entire Zone 1 address pool is -not- delegated by default. A sysop in Net 346 does -not- have an inbound gateway to his fidonet mapped SMTP address. Also, as just pointed out, although I run a gateway in Houston, so do at least four other nodes. Guess who 'owns' the MX record for n106.z1.fidonet.org. It ain't me! So... you ask why I might have a preference to eforest.houston.tx.us or tcrs.org, instead of the fidonet.org address. Hopefully that answers -that- question. :) --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1477 [1995] Scn From : Lawrence Garvin 1:106/6018 09 Nov 97 19:30:16 To : All 11 Nov 97 07:11:46 Subj : I'm happy to announce.... ------------------------------------------------------------------------------- IP_CONNECT is now 'officially' in distribution in Zone 1. Send your thankyou's to Bob Seaborn, Zorch Frezberg, and Bob Kohl, for making the necessary requests in such a timely manner! * Forwarded (from: NET_SAVE) by Lawrence Garvin using timEd/2 1.10+. * Originally from Seal (1:106/500) to Lawrence Garvin (1:106/6018). * Original dated: Sun Nov 09, 18:19 NORTH AMERICAN BACKBONE STATUS OF ECHOLIST CONFERENCE CHANGES BACKSTAT.NA 09 Nov 1997 =========================================================================== 1. ADDED TO BACKBONE.NA =========================================================================== IP_CONNECT Topic: Fidonet IP Integration Discussions Moderator: Ward Dossche, 2:292/854 Requested: 02 Nov 97 Expiry: 09 Dec 97 Region Rqst: 17 10 --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1478 [1995] Scn From : Lawrence Garvin 1:106/6018 10 Nov 97 01:42:44 To : Marco d'Itri 11 Nov 97 07:11:46 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Marco d'Itri said in a message to Lawrence Garvin: Md> Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >Can you CONFIGURE your Fidonet mailer....??? Md> Yes, I can configure my software in a way that it will send all Md> netmail for those nodes encapsulated in internet email. Why do I get the feeling that you're fudging on the question. Can you configure your FIDONET MAILER??? You know.. that thing that does the FTS-0001 connections on your PSTN line! --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1479 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Nov 97 14:33:08 To : Rune Johansen 11 Nov 97 13:56:46 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >I have stated that if we are to have a common session protocol, it should be >the one defined in policy; FTS-0001. I do not believe that it would be >logical I do not believe that the common protocol should be one well known to be slow and insecure. >fulfill such a requirement, and that the BinkP protocol specification per >date does not describe how to put in a hook for other, alternate protocols, >so that a FTS-0001 session could be detected. Any sane implementation would run each protocol on a different port. >I agree with you that a defacto standard would be in use in some years. But, >it is not for sure that it would be BinkP. Maybe it will be another, less >efficient protocol, that includes greater support for failure? I can't see why. The current situation shows us that when the policy does not mandates an official standard binkd is going to win. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1480 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Nov 97 14:27:30 To : Rune Johansen 11 Nov 97 13:56:46 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >> Well, maybe you should explain us why this is a good thing. You are not >> going to use all of them in the next centuries, so why don't you use one >> port for every service? It's more clean and let you free to start and >> stop and upgrade one service at time without shutting down the whole >> system. >You are assuming things that applies to you, and maybe not to others. What do >you know if I am to use those services in the next century or not? I suppose that when computers able to support about 2^16 services will be widely available we will use something other than TCP/IP v4 or TCP/IP v6. Anyway, you still haven't explained why using a single daemon on one port for all services is a good tecnical solution. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1481 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Nov 97 13:49:36 To : Rune Johansen 11 Nov 97 13:56:46 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >> We have the source, so we can compile NlMake for any platform. >Do you have it available for FREQ on your IP node? I haven't. You can find it on the web page of the author. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1482 [1995] Scn From : Marco d'Itri 2:335/680.666 10 Nov 97 14:37:02 To : Rune Johansen 11 Nov 97 13:56:46 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >> Tomorrow that will be the same. There is no reason to run binkp over telnet >> or over VMP. >Don't you see that there are other scenarios than your own? Don't you see >that a non-ip-directly-implemented-in-the-mailer mailer might have BinkP >implemented as a session level protocol, that can use a VMP connection? >Regardless of the No, I can't see why someone would want to implemente or to use this solution. I can implement binkp or FTS-1 over talk or rsh, but this does not mean that we should support such a stupid idea. >>> There is need for 3 flags: Telnet (IPT), TCP connection (IPR) and VModem >> (IPV). >> All of those flags implies that the handshake used is EMSI or FTS-1. BNP is >> a different handshake but is runs only over RAW. >BinkP runs over IPT and IPV too. You don't run it over other than IPR. Can you point me an implementation of binkp over VMP? And then, can you explain us why running binkp over telnet or VMP is a good idea? -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1483 [1995] Scn From : Lawrence Garvin 1:106/6018 10 Nov 97 08:36:46 To : David Moufarrege 11 Nov 97 23:24:04 Subj : Welcome to the Backbone ------------------------------------------------------------------------------- David Moufarrege said in a message to Southern Star: DM> Hello Southern! DM> In a message Southern Star wrote to Moderator: SS> Your echo is now on the Zone 1 Backbone! This message to help get SS> some of the links established. If you have any private Zone 1 feeds, SS> now is the time to switch them to the Zone 1 Backbone. DM> Which Zone 1 backbone would that be? David... let's leave zone 1 politics in the zone 1 echos. 'K? :) There are only three or four Z1 people here right now, and so far it's been a GOOD experience, without any 'bickering'. Personally, I'd like to see it that way. DM> This echo has been carried by the FidoSpine Zone 1 backbone for DM> several weeks. Perhaps it has... perhaps it hasn't. The fact is that it wasn't in the Echolist until seven days ago, and if you look in ELIST711 you'll find it NOT listed. I'm skeptical that Bob & Jim were distributing it without it being elisted. Nonetheless, it -is- elisted now, and it -is- in distribution on all major Z1 systems (except perhaps Planet Connect who will take a few weeks to catch up anyway). --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1484 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Nov 97 22:49:00 To : Pedro Lima 11 Nov 97 23:26:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > LS> I want to be able to establish a session with any given one. > "Abandon hope all ye enter here" Why? There is just one IP we're tallking about (IPv4), there is just one Internet we're talking about ("the" Internet). IPv6 may be to IPv4 what ISDN is to PSTN, if you want a parallel - but why should I easily throw away a nice (and IMHO viable/feasible) idea of being able to have a session with every Fidonet mailer on the IPv4 Internet? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1485 [1995] Scn From : Frank Ellermann 2:240/5815.1 10 Nov 97 08:50:00 To : Rune Johansen 11 Nov 97 23:26:56 Subj : off topic (was: !!!!!!!!!!!!!!!!!!!!) ------------------------------------------------------------------------------- [MsgId] RJ> keep the possibility for dupeloops lower than without. MsgIds have nothing to do with dup-rings, each dup-ring causes dupes sooner or later. MsgId only helps to filter some of these dupes before they are forwarded even further... RJ> fidonet echomail moving away from star-topology distribution ... not yet, not based on the actual and still "optional" FTS-9. Topologies with dup-rings are illegal, period, except from very rare experimental areas (in R24 Gateways.Ger and R24.Discussion). RJ> almost impossible to check it with seen-by control. Cyclic path detection based on FSC-74 or FSC-93 works just fine _without_ MsgIds, and that's why I answer your message here in public, back on topic, somehow: With IP-nodes worldwide the number of interzone links multiplies in the next years. Current FidoNet-Software can't automatically detect interzone dup-rings. We'll have to change the software used at zonegates (i.e. _each_ node moving echomail from one zone to another) to "push" reduced seen-by-s in export, instead of simply stripping it, and "pop" these saved 2D-seen-by-infos at re-import in the zone of the originator. Done this way even old-fashioned Fido-soft not supporting dupe checks based on MsgIds will continue to work and automatically detect dup-rings, even interzone dup-rings. RJ> So, to keep dupe loops as small as possible [...] A dup-ring is a dup-ring, it won't be smaller if we all check and generate MsgIds. And each dup-ring causes dupes, as the "dup" in dup-ring suggests :-) Bye, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1486 [1995] Scn From : Ward Dossche 2:292/854 10 Nov 97 13:07:46 To : Lawrence Garvin 11 Nov 97 23:26:56 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Lawrence, > I thought we'd cleared this one up. :) You are right, I stand corrected! \x/ard --- DB 1.58/001877 * Origin: Many Glacier (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1487 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Nov 97 22:59:00 To : Marco d'Itri 11 Nov 97 23:26:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>fiction; although 83.3% is a vast majority by any standards, it is >>nowhere near total connectivity. > FTN over telnet does not have a better support. Yes, I am aware of that. I just don't like scratching off 1 node out of every 7 just like that... Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1488 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Nov 97 23:13:00 To : Dima Maloff 11 Nov 97 23:26:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > ""Compatible" being the main keyword". "Be compatible" for a protocol > means "to be in the majority", isn't it? No, it doesn't. I strongly believe we are not Microsoft here and we are not implementing the infamous "we'll do it our way and as long as we are the majority we won't give a f*ck", are we? "Compatible" stands for "compatible with ". And this "" is a well defined reference standard/point. It might happen to be the one used by the majority, it might happen not to be this one. We might go for adopting as a standard - but until we do so no matter how big the number of users is it is not compatible with the standard: it is just compatible with itself and anything it happens to be compatible with. Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1489 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Nov 97 23:52:00 To : Yuri Teterin 11 Nov 97 23:26:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > So why are you against BinkP-only nodes but are not against > ISDN-only nodes? I hate to admit that yes, I'm against them. More precisely, I'm against the problem started with introducing them into nodelist: allowing new completely incompatible (in terms of connectivity) nodes without creating proper official/formal base for this. If it had been done right, we wouldn't have had at least half of the problems we're struggling to solve in this echo... Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1490 [1995] Scn From : Lech Szychowski 2:480/33.7 10 Nov 97 00:17:00 To : Dieter Ringhofer 11 Nov 97 23:26:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > since when is dns maintained by fidonet? What's the formal status of "fidonet.org." then? Last time I checked it looked like this domain is maintaine by (at least some) Fidonet, represented by Georde Pace: ===================================================================== [rs.internic.net] FidoNet Public Relations (FIDONET-DOM) c/o Pennsylvania Online PO Box 6501 Harrisburg, PA 17112 US Domain Name: FIDONET.ORG Administrative Contact, Technical Contact, Zone Contact: Peace, George (GP11) george@PAONLINE.COM (717) 657-0000 (FAX) (717) 657-0132 Billing Contact: Peace, George (GP11) george@PAONLINE.COM (717) 657-0000 (FAX) (717) 657-0132 Record last updated on 19-Jun-97. Record created on 25-Feb-88. Database last updated on 9-Nov-97 04:54:23 EDT. Domain servers in listed order: FIDONET.FIDONET.ORG 198.69.90.5 NS1.SPYDERNET.COM 199.60.62.1 POLARIS.LLNL.GOV 128.115.14.19 ======================================================================= Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1491 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Nov 97 23:29:00 To : Dima Maloff 11 Nov 97 23:26:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > LS> nodes - I want to be able to establish a session with any given one. > You can route you mail. I can do it now as well, right? There are gateways. Following this direction, I may also route now all my mail via my net/region outbound gate, right? This may lead us to the conclusion we don't need Fidonet-wide nodelist at all: what for, if we can route mail? ;) > But if we even REALLY needed a standard, why not binkp? Frankly? Apart from one very selfish reason (my node is not BinkP capable) three other and more important ones: (1) I believe its full specs are not publicly available for the time being. (2) Given (1) I'm not personally convinced it's proven to be significantly better than, say, EMSI + Zmodem. (3) If an existing node gets a dial-up packet routing connection (PPP/SLIP) and an IP capable/aware FOSSIL - and if we declare as a standard something we all already know and use in the PSTN world - this node requires no further modifications to be able to connect to all IP mailers/nodes. > Only a small number of nodes will have to change something then > and thouse changes will be free for them. Again, I'm not saying it can't be BinkP. I just consider "because there is already quite a lot of systems running BinkP" a zero-weight argument when it comes to setting a proper standard; it's not about number of nodes, it's about technical efficiency/excellence/suitability. Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1492 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Nov 97 22:57:00 To : Dima Maloff 11 Nov 97 23:26:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > I can interpret forcing of binkp-only sysops to support FTS-1 only one > way -- authours and/or users of commercial software make problems for > users/authours of free software (To increase their "market share" > politically?) Not fair. Forget the marketing/money stuff. I doubt it's an issue here. And I believe the only reason we are talking about FTS-0001 here is we're trying to minimize the number of counterarguments we might have to face when we finally/eventually want to get the IP nodes listed on regular - not just trial - basis. Of course, there is "total connectivity" aspect in this discussion; but I'm almost sure nobody tries to talk about adopting FTS-0001 as common protocol for other reasons than purely political and P4-related ones :) Leszek. --- FastEcho+ 1.45 * Origin: Hmmm... Ehemm... Tego... No... (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1493 [1995] Scn From : Lech Szychowski 2:480/33.7 09 Nov 97 22:41:00 To : Nick Soveiko 11 Nov 97 23:26:56 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > fine, then let's put default == 1YE. i.e. no session level protocol > listed - read emsi with fallback to yoohoo and further down to fts-1. Sounds quite reasonable. And even acceptable from the "strict FTS/P4" point of view: the magic word FTS-0001 is there :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1494 [1995] Scn From : Marco d'Itri 2:335/680.666 11 Nov 97 14:26:56 To : Lawrence Garvin 11 Nov 97 23:28:20 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >Why do I get the feeling that you're fudging on the question. I get the feeling you are asking a pointless question. >Can you configure your FIDONET MAILER??? >You know.. that thing that does the FTS-0001 connections on your PSTN line! No, because that thing should only do FTS-1 or EMSI connections on my PSTN line, not manage an email tunnel. My tunneling software and my tosser can cooperate to automatically send netmail via email tunneling. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1495 [1995] Scn From : Rune Johansen 2:210/20 10 Nov 97 23:29:52 To : Lawrence Garvin 12 Nov 97 05:45:46 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> Where should future transport networks be placed then? >I'm not understanding your question. All I'm buckin' for is the right to put m > domain name in one field and my PSTN telno in the other field, so that I can > have the _SAME_ node number on both mailer sessions. I see that, and that is what most of the participants in this echo wants too. But, what when there comes another transport mechanism to town? What if I have one PSTN telno, one FQDN and one X25 address, and want it all in the same nodelist entry? The addresses are different, and they describe different ways of connection to me, to the same system, but over totally incompatible technologies. That's where either the nodelist format must change, or we must redefine the restrictions inside one of the fields in the nodelist. If we get another nodelist format, we can list all access methods on one line. If we redefine the phone field to an address field, we will get one line per access method. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1496 [1995] Scn From : Pablo Saratxaga 2:293/2219 09 Nov 97 21:36:02 To : Slava Filimonov 12 Nov 97 05:45:46 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Thu, 06 Nov 97 10:45:58 +0100, Slava Filimonov said: PS>> There are 65535 ports, there should be at least 60,000 free ports on PS>> any server, so the case of 'only one port available' is only a PS>> theorical case which will never happen :) SF> btw, Nope, it can happen ;). On Micro$oft NT/95 you can run out of free SF> client ports/resources/handles if you'll use non-stop program which will SF> just opening/closing sockets. I told "on any server", I don't consider WinNT much less Win95 as internet servers. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1497 [1995] Scn From : Pablo Saratxaga 2:293/2219 09 Nov 97 21:44:38 To : Dieter Ringhofer 12 Nov 97 05:45:46 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Thu, 06 Nov 97 18:52:23 +0100, Dieter Ringhofer said: DR> since when is dns maintained by fidonet? The DNS for *.fidonet.org are mantained by fidonet, that is what matters. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1498 [1995] Scn From : Pablo Saratxaga 2:293/2219 09 Nov 97 22:00:50 To : All 12 Nov 97 05:45:46 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 05 Nov 97 06:44:36 +0100, Pedro Lima said: PS>> If there isn't a refrence domain then the whole idea of DNS can be PS>> drop, how can a mailer know the fqdn address of a node if the domain PS>> can be an arbitrary one ? PL> By specifying it in the nodelist. This is perhaps not what you meant as PL> "the whole idea of DNS", though. Yes, my "whole idea of DNS" is to resolve the fido adress to a standard fqdn name (under the fidonet.org domain IMHO, as it is the current usage). Otherwise, if it is to put some fqdn related things in the nodelist we can as well put the entire fqdn, and the problem of where to put that info still remain. The problem of updating the DNS is only a politicla one, not a technical one. The problem of listing fqdn in the nodelist too. So if we can do one we can also do the other. And for me it is simpler to work whith the DNS. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1499 [1995] Scn From : Rune Johansen 2:210/20 10 Nov 97 23:24:38 To : Lawrence Garvin 12 Nov 97 05:45:46 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> I have two pysical devices, alas two different phone numbers. >I have -THREE- physical devices, Rune. I have a Cisco 766 ISDN Router with two >POTS ports. And two V.34 modems, each of which plugs into the POTS port on the >back of the ISDN router. I have -two- telephone numbers on the router, one for > each 64K channel. Each 64K channel shares a telephone number with one of the > analog modems. See listings for 1:106/500 and 1:106/8277. Why don't you have the same phone number for your two POTS ports, and only one nodenumber then? The 761 won't act as a ISDN device for you mailer, will it? >> Also, my analog modem has capabilities that the analog part of my >> ISDN adapter lack. So, the capabilities are not identical, so they >> could not be correctly put on the same nodenumber. >But you did not answer my question. Can you plug your PSTN modem into the POTS > port on the back of the IDSN adapter, and have it ring when the IDSN telno is > called? Yes, I _can_ do that, but as I pointed out, the capabilities of the analog modem part in my ISDN adapter is different from my analog-only modem. If I should have done that on my system, and listed all flags that I am capable of on the different devices, I would have a analog part of my setup that would not be consistent with the nodelisted flags. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1500 [1995] Scn From : Pablo Saratxaga 2:293/2219 09 Nov 97 21:52:00 To : Rune Johansen 12 Nov 97 05:45:46 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 05 Nov 97 23:13:42 +0100, Rune Johansen said: >> I can interpret forcing of binkp-only sysops to support FTS-1 only one way >> -- authours and/or users of commercial software make problems for >> users/authours of free software (To increase their "market share" >> politically?) Not fair. RJ> Is BinkleyTerm commercial? No. Does it use FTS-1? Yes. Does it work over TCP/IP ? No. So I don't see your point here. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1501 [1995] Scn From : Pablo Saratxaga 2:293/2219 09 Nov 97 22:30:14 To : Marco d'Itri 12 Nov 97 05:45:46 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Wed, 05 Nov 97 19:46:39 +0100, Marco d'Itri said: Md> srtxg@linux.chanae.stben.be wrote: >>Each fqdn that wants to receive email *MUST* have an MX, it can point to >>itseld. But whithout an MX there is no guarantee at all that mail will be >>sent. In other words: Md> Please point us to the relevant RFCs. In rfc1034 : | A.X.COM A 1.2.3.4 | A.X.COM MX 10 A.X.COM [...] | subtree by the explicit data for A.X.COM. Note also that the explicit | MX data at X.COM and A.X.COM is required, and that none of the RRs above note the use of *required* in rfc1123 the rfc974 is described as: | This RFC describes the use of MX records, a mandatory extension | to the mail delivery process. note the use of *mandatory* in rfc974 : | It is possible that the list of MXs in the response to the query will | be empty. This is a special case. If the list is empty, mailers | should treat it as if it contained one RR, an MX RR with a preference | value of 0, and a host name of REMOTE. (I.e., REMOTE is its only note the use of *should* Note also that rfc974 is from 1986. In it they told that when no MX is found the amil *should* be sent (and not *must* be sent) to the A entry, but at that time MX entries were no common, now they are. The description of rfc974 is also: ® Describes the transition from HOSTS.TXT based mail addressing to the more powerful MX system used with the domain system. ¯ Note the use of *transition* that implies that the old system will likely be dropped. Any way, "should" means that there ca be a high probability that it will be the case, but no certitude at all. Md> When sendmail does not find an MX Md> record it looks for an A. That's false. Look at the sendmail docs and/or source and you will find that it is only an option, if it is not enabled the default is to return the mail as undeliverable. I suspect that nowadays most sendmail distributions don't enable that by default (I think that Linux Redhat sendamil doesn't for exemple). I also know it by personal experiencing that (whith Linux and OS/2 versions of sendmail) Md> Before the MX RR mail was delivered only by Md> looking at A records. That's true. And it still does that when the address is formatted as someuser@[some.where] (note the [ ] that means to sendmail: don't use the DNS system for MX lookup) or when the TryNullMXList option is set to true. So, to summarize it: * when properly using MX you: 1) do it the right way, 2) ensure that the mail will allways reach the right place wherevever it comes from. * when you don't use MX you: 1) don't do it properly (is like using "void main()" in C ;-) ), 2) there is no more certitude that the mail will allways arrive. There is a percentage of sites that will be unable to send the mail as there is no MX entry. As it costs the same amount of work to do it correctly and not why not to do it correctly ? That way your DNS entry looks clean and you avoid any possible problem. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1502 [1995] Scn From : Rune Johansen 2:210/20 10 Nov 97 23:18:30 To : Lawrence Garvin 12 Nov 97 05:45:46 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > I'm referring to the situation where two different nodes are at the -same- > telephone number, and -that- is generally not permitted in the nodelist. Ah, I see. > Yeah.... and how do they make the translation between the tosser tossing >to/from 210/20, and the mailer knowing it should send to /21? Last I heard, th >tosser will address the packet to /20, and the only way to work around that is > to -ROUTE- the echomail bundle. I see what you mean. And I see the potential problems that you are suggesting. For those that poll me regularly (those that have a session password and are hooked up to echos at my place) toss their messages to 2:210/20. Then they poll 2:210/21. When they see my AKA in the handshake session, they send me the packets destined for 2:210/20 too. But, they could also let the packet itself be adressed to my 210/21 AKA, as my tosser recognises it too as a AKA for me. My tosser and mailer is the same program, so they share the configuration. > Only in Zone 2 have nodes been allowed to create redundant non-admin entries > with the same telco number. Here in Zone 1 one is expected to have a > -different- telephone number for an additional node listing. If you are reffering to _that_ I must agree that I have not seen them either. But, I haven't been looking too hard either. :-) --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1503 [1995] Scn From : Pablo Saratxaga 2:293/2219 09 Nov 97 21:54:14 To : Slava Filimonov 12 Nov 97 05:45:46 Subj : Re: IP - Call for opinion votes ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Thu, 06 Nov 97 10:54:18 +0100, Slava Filimonov said: SF> I even can't imagine such stupid thing as internet with IPTxy SF> flags for smtp servers. Not for smtp of course, for that there are the MX entries. The IPTxy are for the nodelist, not DNS, to tell the online time of IP nodes (not smtp servers). Of course it is to expect that a great number of IP nodes will also run a smtp server, but those are separate items. SF> ŽŽ ŽŽ< C0PiRATE Cy.b33r.Net >> slf@mrp.cz << zlin.mrp.cz/~slf >ŽŽ ŽŽ SF> Ž ŽŽŽ< binkd:fido.mrp.cz|SF396-RIPE|mobile:+420 603 228496 >ŽŽŽ Ž -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1504 [1995] Scn From : Pedro Lima 2:362/21 11 Nov 97 04:05:24 To : Lech Szychowski 12 Nov 97 18:39:16 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- LS> Why? There is just one IP we're tallking about (IPv4), there is just LS> one Internet we're talking about ("the" Internet). IPv6 may be to IPv4 LS> what ISDN is to PSTN, if you want a parallel - but why should I easily LS> throw away a nice (and IMHO viable/feasible) idea of being able to LS> have a session with every Fidonet mailer on the IPv4 Internet? There will always be reasons for not getting a connection, independently of the observance of the technical specs in Fido. Total connectivity is good as a principle, important as it may be, but not as a rule, because you can't enforce the impossible. If we're going to have a standard, then let it be a 'de facto' one, which allows for exceptions (in particular, those experimental) and widens the possibility for evolution. Without it, we're finished, truly dead. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1505 [1995] Scn From : Pedro Lima 2:362/21 11 Nov 97 04:54:38 To : Ward Dossche 12 Nov 97 18:39:16 Subj : IP-connectivity ------------------------------------------------------------------------------- WD> You are right, I stand corrected! Thanks. That makes things much simpler, then. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1506 [1995] Scn From : Dieter Ringhofer 2:2476/14 12 Nov 97 05:48:20 To : Pablo Saratxaga 12 Nov 97 18:39:22 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> since when is dns maintained by fidonet? PS> The DNS for *.fidonet.org are mantained by fidonet, that is what PS> matters. if it's still done it's allright. see my other mail, please ;) --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1507 [1995] Scn From : Dieter Ringhofer 2:2476/14 12 Nov 97 05:40:22 To : Lech Szychowski 12 Nov 97 18:39:22 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> since when is dns maintained by fidonet? LS> What's the formal status of "fidonet.org." then? don't ask me, please. i don't use spam-net when there's a way to avoid it. i prefer a to send a crashmail even to z6 before getting lots of spam for writing one message somewhere there ;) LS> Last time I checked it looked like this domain is maintaine by (at LS> least some) Fidonet, represented by Georde Pace: if this is a valid information, everything is ok. afair there has been some rumour about withdrawl of further maintenance of this domain (maybe it was only kind of limitation, don't remember all without rereading related mails). --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1508 [1995] Scn From : Dieter Ringhofer 2:2476/14 12 Nov 97 05:50:56 To : Rune Johansen 12 Nov 97 18:39:22 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen to Lawrence Garvin: >> But you did not answer my question. Can you plug your PSTN modem into the >> POTS port on the back of the IDSN adapter, and have it ring when the IDSN >> telno is called? RJ> Yes, I _can_ do that, but as I pointed out, the capabilities of the analog RJ> modem part in my ISDN adapter is different from my analog-only modem. If I RJ> should have done that on my system, and listed all flags that I am capable RJ> of on the different devices, I would have a analog part of my setup that RJ> would not be consistent with the nodelisted flags. it's always possible with ISDN. i'm also running two ISDN and two analog lines on one aka using one common phonenumber without any special hunter to ensure maximum of connectivity with two available channels. a problem occurs only if one uses different analog devices with different capabilities. such a system should use another phonenumber for the 'bad' device. if i want to list all devices being attached to a line and connectable, i should get some more akas to enable best fitting connection to everyone ;) --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1509 [1995] Scn From : Marco d'Itri 2:335/680.666 12 Nov 97 18:41:22 To : Lech Szychowski 12 Nov 97 22:09:36 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Lech.Szychowski@p7.f33.n480.z2.fidonet.org wrote: >(1) I believe its full specs are not publicly available for the > time being. If this is a real problem it can be solved in just a cople of weeks. >(2) Given (1) I'm not personally convinced it's proven to be > significantly better than, say, EMSI + Zmodem. You should try it. Documentation can't say if it performs better than some other solution. >(3) If an existing node gets a dial-up packet routing connection > (PPP/SLIP) and an IP capable/aware FOSSIL - and if we declare > as a standard something we all already know and use in the PSTN > world - this node requires no further modifications to be able > to connect to all IP mailers/nodes. The same node could install binkd. It would be even simpler, I can install and configure binkd on Debian Linux just by adding my AKA to a file. >Again, I'm not saying it can't be BinkP. I just consider "because >there is already quite a lot of systems running BinkP" a zero-weight >argument when it comes to setting a proper standard; it's not about >number of nodes, it's about technical efficiency/excellence/suitability. Then EMSI and zmodem will never win. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1510 [1995] Scn From : Pablo Saratxaga 2:293/2219 11 Nov 97 09:59:20 To : Lech Szychowski 13 Nov 97 05:39:08 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Sat, 08 Nov 97 15:54:00 +0100, Lech Szychowski said: >> I doubt there is one single machine whose primary (as the one in the >> PTR entries) domain is fidonet.org LS> Well, you're most likely right. But - excusez les mots - so what? LS> If we want IP-capable nodes, we want A records in fidonet.org LS> (sub)domain(s). I fully agree whith you. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1511 [1995] Scn From : Pablo Saratxaga 2:293/2219 11 Nov 97 10:30:20 To : Lech Szychowski 13 Nov 97 05:39:08 Subj : Re: IP-access ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Sat, 08 Nov 97 16:46:00 +0100, Lech Szychowski said: >>>> Each fqdn that wants to receive email *MUST* have an MX, it can point to >>>> itseld. But whithout an MX there is no guarantee at all that mail will >>>> be sent. >> LS> Are you 101% sure about that? >> Yes. LS> Well, there is only one way of getting the right answer - look it up LS> in RFCs. And that's something I'll do next week. Well, according to RFC it seems I'm right, however I finally did some tests whith my sendmail and indeed it used the A address as a last ressort, so at least for the unix version of sendmail I was wrong. LS> It shows that even if there are no MX records for an address LS> and TryNullMXlist is not set, sendmail cares for A record. Yes. >> I also experienced the problem of undeclared MX recently when I was >> working whith my uplink on setting up his sendmail for forwarding >> *.chanae.stben.be to me; he had put a *.chanae.stben.be MX entry LS> FWIW, I think that if it was just about getting _his_ sendmail to LS> do this, you'd have had less hassle if you went for putting one more LS> rule in ruleset 0 - but it's just my $.02. I wonder if that isn't another particularity of the OS/2 version of sendmail. -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1512 [1995] Scn From : Rune Johansen 2:210/20 11 Nov 97 21:52:10 To : Pedro Lima 13 Nov 97 05:58:52 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- >> Yes, you would actually have to pay attention to what happens around >> you. > Yes. This is not the common behavior of sysops in general, though. If a > flag existed for denoting a specific transport, filtering would be much > simpler and safer, since even when new protocols are added, changed, or > removed for that transport, the mailer would remain well configured. You want a plain "IP" flag or equivavelt to be denoted in a nodelist entry if some of the abilities are to transfer via IP (if nodelist entries are to be shared with phone entries)? That is what I want too, but I want to include that part if the flag in the separate flags for the transport. So, I suggested IPT, IPR and IPV. All flags start with a common string. But, yes, I see your point too. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1513 [1995] Scn From : Rune Johansen 2:210/20 11 Nov 97 23:57:30 To : Marco d'Itri 13 Nov 97 05:58:52 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > Anyway, you still haven't explained why using a single daemon on one port > for all services is a good tecnical solution. I thought that I had explained why I have them on the same port. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1514 [1995] Scn From : Rune Johansen 2:210/20 11 Nov 97 21:57:10 To : GARY PETERSEN 13 Nov 97 05:58:52 Subj : RE: FTS-0001 in IP nodes ------------------------------------------------------------------------------- > I believe that every system in FidoNet should have at least one node that can >be connected via modem and mailer, using the standard connection protocols for >mailers. Other nodes could be designated as IP only, but every FidoNet system > must be connectable via telephone front end. On that point we differ. We don't want to be stuck in the telephone world. Adding IP functionality to existant phone nodes for now, yes, but we also want a FidoNet system to use IP as only mean of transport. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1515 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Nov 97 08:36:46 To : Rune Johansen 13 Nov 97 05:58:52 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Rune Johansen said in a message to Lawrence Garvin: >> Where should future transport networks be placed then? > I'm not understanding your question. All I'm buckin' for is the right > to put my domain name in one field and my PSTN telno in the other > field, so that I can have the _SAME_ node number on both mailer > sessions. RJ> I see that, and that is what most of the participants in this echo RJ> wants too. Good! RJ> But, what when there comes another transport mechanism to town? Well..... we should deal with that '[an]other transport mechanism' then! I really think that dealing with present reality is more than enough to keep all of us busy. I'm not opposed to 'looking ahead', and I admire visionary people immensely, but there does come a time when the -best- course of action is to deal with the immediate challenge. Ye ol' concept of setting reachable goals. :) If we try to provide for "everything" on this first effort, we may not accomplish anything successsful at all. RJ> What if I have one PSTN telno, one FQDN and one X25 address, and RJ> want it all in the same nodelist entry? What transport mechanism is your X.25 coming across? RJ> The addresses are different, and they describe different ways of RJ> connection to me, to the same system, but over totally RJ> incompatible technologies. True. But the bottom line is that the FQDN is merely an already existing substitute for the 'address' of the device (i.e. IP address == telno). I guess the answer to the question is -how- is traffic for your X.25 address transported -physically-. I'm not real familiar with X.25 so I need some basic info to answer your question. I see where you're going, but I'm not sure it's really an issue, yet. RJ> That's where either the nodelist format must change, or we must RJ> redefine the restrictions inside one of the fields in the nodelist. Of course.. sticking with my original principle.. we're just trying to solve the -IP- problem, not all the rest of the X.*** problems. Perhaps somebody should start an X25 echo. RJ> If we get another nodelist format, we can list all access methods RJ> on one line. If we redefine the phone field to an address field, we RJ> will get one line per access method. But at some point there needs to be a finite definition of the fields in the nodelist, and at some point -some- technology won't fit. :( --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1516 [1995] Scn From : Rune Johansen 2:210/20 11 Nov 97 23:56:18 To : Marco d'Itri 13 Nov 97 05:58:52 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>> We have the source, so we can compile NlMake for any platform. >> Do you have it available for FREQ on your IP node? > I haven't. You can find it on the web page of the author. Ah, but where is that? In the docs there are no such references as I could find. I only found a email address. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1517 [1995] Scn From : Lech Szychowski 2:480/33.7 11 Nov 97 13:24:00 To : Lawrence Garvin 13 Nov 97 05:58:52 Subj : IP-access ------------------------------------------------------------------------------- > (a) Lawrence.Garvin@f6018.n106.z1.fidonet.org > (b) lawrence@eforest.houston.tx.us or lawrence@eforest.tcrs.org > I think, based on appearance alone, not to mention ease of use, and > simplicity when diseminating the address to others, (b) is the obvious > preference. Couldn't agree more :) Still, if someone wants to contact you for the very first time, (a) will work as much as (b), right? And in your reply you can include something like "PS: you can reach me as (b), if you find this address easier to remember/use"; you can include (b) in your sig, you can use (b) in "Reply-To:/Sender:/From:" RFC header fields. There are many ways in which you can achieve switching the other party to using (b) rather than (a)... > Now, if we're talking ONLY about Fidonet nodelist issues, then it makes > no sense at all for me to 'reject' the idea of receiving mail at (a); Even more: it makes a very little sense to me to advertise in Fidonet nodelist something that is completely not connected with Fido, ie some arbitrary email address. > however, it should also be noted that I don't control the mail gateway > that handles (a), I -do- control the mail gateway that handles (b), and > -that- is the technical reason for preferring an address of my own to > the fidonet.org address. Yes, in your case it is. In my case it's not, because I happen to control both. But our cases are, I'm afraid, not the most typical ones. I think majority of us have email addresses/accounts without having admin authority over the systems that carry them. Anyway, this IMHO should not be an issue here. If we believe ?Cs to maintain nodelist segments/entries properly, if we believe our hubs/hosts to route mail properly, why shouldn't we belive somebody indicated/appointed by ?C to do his job of maintaining DNS/gateway properly? > Yeah... but therein comes the political problems. It's just been brought > to my attention that the entire Zone 1 address pool is -not- delegated > by default. A sysop in Net 346 does -not- have an inbound gateway to his > fidonet mapped SMTP address. Well, that's (a) very unfortunate, (b) very sad, (c) technically very easy to change, (d) quite a surprise for me. And I agree it may be quite a political problem... :( > Also, as just pointed out, although I run a gateway in Houston, so do > at least four other nodes. Guess who 'owns' the MX record for > n106.z1.fidonet.org. It ain't me! We had the same situation with R48 in zone 2. It took a bit of effort to convince the z2.fidonet.org. maintainer (and our ZC) to list some of our systems as MXes in our region, but finally we managed to. Have you already tried? Well, most likely you have; otherwise we wouldn't talk about it. Anyway, I think we are slightly off-topic, so let's move to netmail/email. > So... you ask why I might have a preference to eforest.houston.tx.us or > tcrs.org, instead of the fidonet.org address. > Hopefully that answers -that- question. :) I'd rather say it anwers _unfortunately_ ;) And IMHO the situation you described is a strange and twisted one. What is fidonet.org. domain for if not also for registering regional/netional/local MXes? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1518 [1995] Scn From : Rune Johansen 2:210/20 12 Nov 97 00:02:30 To : Marco d'Itri 13 Nov 97 05:58:52 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- >> BinkP runs over IPT and IPV too. You don't run it over other than IPR. > Can you point me an implementation of binkp over VMP? Yes -> BBBS running behind a VModem FOSSIL driver. That's one. > And then, can you explain us why running binkp over telnet or VMP is a > good idea? OK, let's say that I don't have BinkD (the mailer), but I have the BinkP protocol implemented in my mailer. My mailer cannot connect directly to the IP stack of my computer, but a FOSSIL can. My FOSSIL software can connect to a telnet daemon mailer or another mailer, behind another FOSSIL based mailer that also have got BinkP implemented. That's where you would run it. Even though BinkD has got BinkP implemented over a TCP socket, does not mean that everybody MUST use it that way. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1519 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Nov 97 08:33:20 To : Rune Johansen 13 Nov 97 05:58:52 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune Johansen said in a message to Lawrence Garvin: > I have -THREE- physical devices, Rune. I have a Cisco 766 ISDN Router > with two POTS ports. And two V.34 modems, each of which plugs into > the POTS port on the back of the ISDN router. I have -two- telephone > numbers on the router, one for each 64K channel. Each 64K channel > shares a telephone number with one of the analog modems. See listings > for 1:106/500 and 1:106/8277. RJ> Why don't you have the same phone number for your two POTS ports, RJ> and only one nodenumber then? Well, in the instant case, both of those 'nodes' were created for uniquely separate purposes, intended to be at separate sites, but it's only coincidence, and lack of other volunteers, that keep them both on my own systems. RJ> The 761 won't act as a ISDN device for you mailer, will it? No, it won't. Those two nodes are available via V.34 only. > But you did not answer my question. Can you plug your PSTN modem into > the POTS port on the back of the IDSN adapter, and have it ring when > the IDSN telno is called? RJ> Yes, I _can_ do that, but as I pointed out, the capabilities of the RJ> analog modem part in my ISDN adapter is different from my RJ> analog-only modem. AH!! My apologies. I -missed- that point earlier. That does make a difference. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1520 [1995] Scn From : Lawrence Garvin 1:106/6018 12 Nov 97 19:49:56 To : Marco d'Itri 13 Nov 97 18:14:12 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- Marco d'Itri said in a message to Lawrence Garvin: Md> Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: >Why do I get the feeling that you're fudging on the question. Md> I get the feeling you are asking a pointless question. Not any more. :) >Can you configure your FIDONET MAILER??? >You know.. that thing that does the FTS-0001 connections on your PSTN line! Md> No, because that thing should only do FTS-1 or EMSI connections on Md> my PSTN line, not manage an email tunnel. Which is -exactly- why that information does not need to be in the NODELIST. Md> My tunneling software and my tosser can cooperate to automatically Md> send netmail via email tunneling. Fine! Which -proves- that you do not need the information in the nodelist to make use of it. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1521 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Nov 97 17:48:50 To : Rune Johansen 13 Nov 97 22:10:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >> Anyway, you still haven't explained why using a single daemon on one port >> for all services is a good tecnical solution. >I thought that I had explained why I have them on the same port. No, you explained me that your software can't listen on multiple ports. The fact that the design of a program is broken is not a technical explanation. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1522 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Nov 97 17:42:46 To : Rune Johansen 13 Nov 97 22:10:26 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >> And then, can you explain us why running binkp over telnet or VMP is a >> good idea? >OK, let's say that I don't have BinkD (the mailer), but I have the BinkP >protocol implemented in my mailer. My mailer cannot connect directly to the >IP stack of my computer, but a FOSSIL can. My FOSSIL software can connect to >a telnet daemon mailer or another mailer, behind another FOSSIL based mailer >that also have got BinkP implemented. That's where you would run it. This does mean that using binkp over VMP is a good idea. This just means that you can't use a different transport. I asked for technical motivations. >Even though BinkD has got BinkP implemented over a TCP socket, does not mean >that everybody MUST use it that way. Logic tells me that only good protocols should be used. There is no reason to run Binkp over any protocol other than RAW, the problem is in bbbs that can't do better. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1523 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Nov 97 17:49:38 To : Rune Johansen 13 Nov 97 22:10:26 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Rune.Johansen@f20.n210.z2.fidonet.org wrote: >> I haven't. You can find it on the web page of the author. >Ah, but where is that? In the docs there are no such references as I could >find. I only found a email address. http://www.blaze.net.au/~davidn/BETA/ -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1524 [1995] Rcv Scn From : Pedro Lima 2:362/21 12 Nov 97 05:07:40 To : Lothar Behet 13 Nov 97 22:38:08 Subj : IP - Call for opinion votes ------------------------------------------------------------------------------- LB> It might get real important, if the definition of CM is read as LB> "Nothing else than a mailer uses this line", as some guys in R24 try LB> now. You mean, the MO flag would be redundant with the CM flag? Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1525 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 13 Nov 97 22:49:06 To : Pedro Lima Subj : Flags, especially CM and MO ------------------------------------------------------------------------------- Hello Pedro! On 12 Nov 97 wrote Pedro Lima to Lothar Behet: LB>> It might get real important, if the definition of CM is read as LB>> "Nothing else than a mailer uses this line", as some guys in R24 LB>> try now. PL> You mean, the MO flag would be redundant with the CM flag? No, not in my opinion. CM = this line accepts mailer calls (normally) for 24h a day MO = not for human caller applicable (i.e. no bbs behind mailer) Txy = specified online time beside ZMH no flag = node at least available at ZMH, without any additional online time specified or required I added section 6.3 CM (meaning 24 hours a day) to the ip-query sheet, as some answers especially asked for it above a specified online-time. Please correct me, if I should have misinterpreted the flags as defined i.e. in the nodelist. The discussed new interpretation is as follows: Some people interprete CM as nothing else than a mailer takes up the line, but the mailer may not always answer a call at any time. It is just a dedicated line for mailer connects, but the mailer may answer or not at any time (beside ZMH). As from some countries every try for a pstn-call has to be paid (AFAIK), a repeated call to a system with "busy" or "not available" might get expensive for a foreign sysop. This is just "bad luck", if you follow the new interpretation, as you can not rely on any connection at any time :( For IP this point of view would also have certain drawbacks. Regards, Lothar --- GoldED/2 3.00.Beta1+ * Origin: tea allocation error, operator halted (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1526 [1995] Scn From : Kim Heino 2:222/0 12 Nov 97 23:42:34 To : Yuri Teterin 14 Nov 97 05:42:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > 'telnet-module/.../whatever' can provide us a transport for FTS-session > instead of saying "NO CARRIER" - we can not include corresponding flag > (TELN, or IPT, or what it should be) in nodelist. As I said, binary, no echo and sga should be enough. They are needed to get suitable data link for FTN mailers. Do you think we need more obligatory options? Other options are ok, but optional. > BTW, there is no common understanding, that should do telnet-module if get > IAC followed by a byte that it can not idenify with a command of > telnet-protocol. Ignore it. >> Is there a telnetd which does not support binary, no echo and sga options? > Why should we be interested in telnetd? FTN-software can not cooperate with FTN-mailer's telnetd-module, then. Is there any that doesn't support binary, no echo and sga? --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1527 [1995] Scn From : maciej grzeszczuk 2:480/70 12 Nov 97 23:39:14 To : Frank Ellermann 14 Nov 97 05:42:10 Subj : Re: IP-node management (was: Proposal for listing [...]) ------------------------------------------------------------------------------- From: maciej grzeszczuk Sat, 08 Nov 97 02:50:00 +0100 Frank Ellermann napisal byl w fido.ip_connect: > Maybe a volunteer offering IP-checks as function request or by some > kind of mail robot ? It's not necessarily only a political question, if you really want to, i can make such robot... 956 -- = wasza KrAp = krap@psych.uw.edu.pl = http://www.psych.uw.edu.pl/~krap = = phone 602-339173 = PGP 50D98803B12327E7 216A787AB7EFD5FA * in arp we trust * --- ifmail v.2.9-kr0.4 * Origin: CANTTOUCHTHIS**7 - EMSI hammer (2:480/70) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1528 [1995] Scn From : Kim Heino 2:222/0 13 Nov 97 02:35:48 To : Lawrence Garvin 14 Nov 97 05:42:10 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> If you take a look at the current nodelist you'll find that many >> nodes already have multiple nodenumbers. > Only in Zone 2, Kim. :( Also in zones 1, 3 and 4. For example see nodes 1:103/123, 3:632/344 and 4:840/1. Or do you say that zone1-edition of nodelist.311 doesn't have those nodes? >> For example I have 4 (plus two administrative) nodenumbers because > So... how would you suggest that I toss echomail then? I use 2:222/0 for almost all FidoNet-echomail, 2:222/2 for some unofficial echos and 2:22/222 for BBBS-echos. My other akas (22, 222 and 2222) are used only for polling me. Where's the problem? > If my IP node has a different node number, you would expect the downlinks > to configure their system to toss to -one- node, and actually -send- to > another? Yes. Or, if you want to, you can use _both_ nodenumbers in echos. I don't know which software you use, but I know that mine can do that. > What if a downlink's IP connection goes down, and they decide they want to > pick up their mail from the PSTN node? Again I can't see any problem here. > What really would happen is that both nodes, PSTN and IP, would present > -both- node numbers all of the time, and share a single outbound directory. Exactly. > But if that is the configuration, then the second node number is totally > redundant, and thus, totally unnecessary. As I said in my original message, we need some better nodelist format. With current nodelist multiple PSTN is much bigger problem than PSTN+IP. Putting IP into name/location field doesn't solve anything but instead will create more problems when we want to add yet another addressing method. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BCG-Box 4 (2:222/0) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1529 [1995] Scn From : Pedro Lima 2:362/21 13 Nov 97 07:44:44 To : Pablo Saratxaga 14 Nov 97 13:28:58 Subj : IP-access ------------------------------------------------------------------------------- Hi, PS> Yes, my "whole idea of DNS" is to resolve the fido adress to a PS> standard fqdn name (under the fidonet.org domain IMHO, as it is the PS> current usage). Yes, that's what I thought. What's more, I even think it's a very good idea. However, I'd like to have the possibility of listing directly an IP# or/and a FQDN, because I don't want to be "forced" (or better said, to force unto others) to use the fidonet.org hierarchy. PS> Otherwise, if it is to put some fqdn related things in PS> the nodelist we can as well put the entire fqdn, and the problem of PS> where to put that info still remain. I already made some suggestions regarding this, namely using the phone field for IP# and the system name for FQDN. PS> The problem of updating the DNS is only a politicla one, not a PS> technical one. The problem of listing fqdn in the nodelist too. So if PS> we can do one we can also do the other. We agree on this. Can we study a way of including both the IP# and FQDN into the nodelist (both as optional, perhaps) and still allow for the (maybe default) fidonet.org addresses? Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1530 [1995] Scn From : Pedro Lima 2:362/21 13 Nov 97 07:25:02 To : Rune Johansen 14 Nov 97 13:28:58 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- RJ> You want a plain "IP" flag or equivavelt to be denoted in a nodelist RJ> entry if some of the abilities are to transfer via IP (if nodelist RJ> entries are to be shared with phone entries)? That could be useful to isolate IP-connectable nodes, however my idea was also to be able to easily filter them out, leaving the modem-dialable ones intact, because I think that IP should have a different entry than modems (if not for the fact of the possibility of both sharing the same "address" as modems, I'd have the same opinion about ISDN nodes too). I admit I've seen one or two strong arguments (strict Policy compliance ain't one of those) in favor of the inclusion in the same entry, but I still think it's best to have them separated. I'm specially thinking about the versatility of adoption of other technologies besides IP. Also, if using the same entry, behavioral differences between the modem access and the IP access (such as on-line time or FREQ capabilities or the ability to handle compressed packets or...) would need their own set of flags, and the flag space is indeed limited, besides making the line more difficult to read (the nodelist isn't solely for machine consumption). RJ> That is what I want too, RJ> but I want to include that part if the flag in the separate flags for RJ> the transport. So, I suggested IPT, IPR and IPV. All flags start with RJ> a common string. Yes, a good idea if most nodes are running mailers capable of accepting wildcards in flag declaration for filtering purposes, although I find them not very "readable". And of course, making them readable such as 'IPTELN' or something of the sort would probably be a waste of nodelist space. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1531 [1995] Scn From : Marco d'Itri 2:335/680.666 13 Nov 97 21:56:24 To : Lawrence Garvin 14 Nov 97 23:09:46 Subj : Re: Defining a standard protocol - why? ------------------------------------------------------------------------------- Lawrence.Garvin@f6018.n106.z1.fidonet.org wrote: > Md> No, because that thing should only do FTS-1 or EMSI connections on > Md> my PSTN line, not manage an email tunnel. >Which is -exactly- why that information does not need to be in the NODELIST. Only because my software is different from your? The name of the sysop is used only by some mail reader, should we remove it too? > Md> My tunneling software and my tosser can cooperate to automatically > Md> send netmail via email tunneling. >Fine! Which -proves- that you do not need the information in the nodelist to >make use of it. They can cooperate if they find EMAIL-type extended entries in the nodelist. If we'd have to use a separate nodelist for email tunnelling why not using it for IP connections too? My PSTN mailer does not needs to know about internet addresses... I'm not saying we should add email tunnelling contact informations NOW, but your arguments are really weak. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1532 [1995] Scn From : Lawrence Garvin 1:106/6018 13 Nov 97 08:52:12 To : Lech Szychowski 15 Nov 97 06:04:10 Subj : IP-access ------------------------------------------------------------------------------- * Reply to a message in PERSONAL. Lech Szychowski said in a message to Lawrence Garvin: > (a) Lawrence.Garvin@f6018.n106.z1.fidonet.org > (b) lawrence@eforest.houston.tx.us or lawrence@eforest.tcrs.org > I think, based on appearance alone, not to mention ease of use, and > simplicity when diseminating the address to others, (b) is the obvious > preference. LS> Couldn't agree more :) Still, if someone wants to contact you for LS> the very first time, (a) will work as much as (b), right? Not necessarily! As has already been documented, not all Nets in Zone 1 have active MX records. I have no control over whether the n106.z1.fidonet.org continues to have a gateway available -- therefore, there is _NO_ guarantee that I will be able to receive mail at the fidonet.org address at any given time in the future. However, I -can- guarantee that as long as I have a Fidonet node, I will continue to be available at eforest.houston.tx.us, and probably tcrs.org. LS> Even more: it makes a very little sense to me to advertise in LS> Fidonet nodelist something that is completely not connected with LS> Fido, ie some arbitrary email address. Except that tcrs.org is -exclusively- associated with Fido. It is the registered domain name of my CRP. And eforest.houston.tx.us is the registered domain name of my -BBS-. LS> I think majority of us have email addresses/accounts without LS> having admin authority over the systems that carry them. True, but most have some sort of contractual arrangement which guarantees access to those accounts as long as the bill is paid. LS> If we believe ?Cs to maintain nodelist segments/entries properly, LS> if we believe our hubs/hosts to route mail properly, why shouldn't LS> we belive somebody indicated/appointed by ?C to do his job of LS> maintaining DNS/gateway properly? No reason I can think of, except that the *C has no authority to appoint anybody to maintain a DNS zone. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1533 [1995] Scn From : Lech Szychowski 2:480/33.7 14 Nov 97 01:10:00 To : Marco d'Itri 15 Nov 97 18:21:20 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>(1) I believe its full specs are not publicly available for the >> time being. > If this is a real problem it can be solved in just a cople of weeks. We better do it before we start seriously think about declaring it a standard. >>(2) Given (1) I'm not personally convinced it's proven to be >> significantly better than, say, EMSI + Zmodem. > You should try it. Documentation can't say if it performs better than > some other solution. Documentation can't prove it runs better/well. But it can surely prove it has weak points; "can", not "will" - and "if it has", not "that it has" :) > The same node could install binkd. It would be even simpler, I can > install and configure binkd on Debian Linux just by adding my AKA > to a file. And on DOS, W95, OS/2, NT etc? >>number of nodes, it's about technical efficiency/excellence/suitability. > Then EMSI and zmodem will never win. If they are actually that much worse I'd hate to see them winning. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1534 [1995] Scn From : Lech Szychowski 2:480/33.7 14 Nov 97 01:03:00 To : Dieter Ringhofer 15 Nov 97 18:21:20 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > LS> Last time I checked it looked like this domain is maintaine by (at > LS> least some) Fidonet, represented by Georde Pace: > if this is a valid information, everything is ok. Last update took place 4 months ago, so it looks like it has all chances of reflecting the actual state of things. > afair there has been some rumour about withdrawl of further maintenance > of this domain (maybe it was only kind of limitation, don't remember all Do you remember how long ago you heard those rumors? Maybe someone should try to contact George Pace to find out what's going on? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1535 [1995] Scn From : Lech Szychowski 2:480/33.7 14 Nov 97 00:36:00 To : Pedro Lima 15 Nov 97 18:21:20 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > you can't enforce the impossible. If we're going to have a standard, > then let it be a 'de facto' one, Sure. But let's not say "that's the way we do it, so a standard it shall be"... ;) > which allows for exceptions (in particular, those experimental) I've no problem with that. Experimental stuff is experimental, but regular nodes are IMHO not exeprimental. > and widens the possibility for evolution. Without it, we're finished, > truly dead. Without a standard we are a bunch of separate groups. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1536 [1995] Scn From : Lech Szychowski 2:480/33.7 14 Nov 97 00:59:00 To : Pablo Saratxaga 15 Nov 97 18:21:20 Subj : IP-access ------------------------------------------------------------------------------- > Well, according to RFC it seems I'm right, however I finally did some Yes, it seems you are right. Having an MX RR is something one can call mandatory for a host/entity to be able to receive mail addressed to it. And of course it was clear from the very beginning that it is the recommended configuration :) > I wonder if that isn't another particularity of the OS/2 version of > sendmail. It shouldn't be. It might be the peculiarity of the compiled version you use, but I expect the non altered sources compiled on OS/2 to behave consistently with its un*x brothers. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1537 [1995] Scn From : GARY PETERSEN 1:290/111 13 Nov 97 20:32:42 To : RUNE JOHANSEN 15 Nov 97 21:17:40 Subj : RE: FTS-0001 in IP nodes ------------------------------------------------------------------------------- On Nov 11, 1997 09:57pm, RUNE JOHANSEN wrote to GARY PETERSEN: RJ> On that point we differ. We don't want to be stuck in the telephone RJ> world. Adding IP functionality to existant phone nodes for now, yes, RJ> but we also want a FidoNet system to use IP as only mean of transport. I'm not so sure we should make it difficult for non-IP sysops to contact IP-only sysops, though. With no front-end to receive a direct netmail from another system, it gets quite difficult to get netmail from one place to another, at least as quickly as has always been possible with a direct telephone call between systems. Gary Petersen gary@mwx.paonline.com --- Platinum Xpress/Win/Wildcat5! v2.1b * Origin: Midwest Xpress Newton, Iowa (1:290/111) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1538 [1995] Scn From : Patrick Rosenheim 1:101/204 13 Nov 97 23:23:00 To : Rune Johansen 15 Nov 97 21:17:40 Subj : FTS-0001 in IP nodes ------------------------------------------------------------------------------- RJ> > I believe that every system in FidoNet should have at least one RJ> node that can >be connected via modem and mailer, using the standard RJ> connection protocols for >mailers. Other nodes could be designated RJ> as IP only, but every FidoNet system > must be connectable via RJ> telephone front end. RJ> On that point we differ. We don't want to be stuck in the telephone RJ> world. Adding IP functionality to existant phone nodes for now, yes, RJ> but we also want a FidoNet system to use IP as only mean of RJ> transport. EMFBI, but.... Why not just have two nodelists? Just like we now have BACKBONE.NA & BACKBONE.NO, as well as FILEBONE.NA & FILEBONE.NO.... We could have NODELIST.xxx & IPMAILER.xxx Or, am I missing the point? --- þ RM 1.31 0391 þ Remember, 640k is 4480k in FidoNet - we use dog bytes. * Origin: PandA's Den BBS * Danvers, MA * 508-777-6009 (1:101/204) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1539 [1995] Scn From : Marco d'Itri 2:335/680.666 16 Nov 97 11:01:24 To : Patrick Rosenheim 16 Nov 97 22:13:18 Subj : Re: FTS-0001 in IP nodes ------------------------------------------------------------------------------- Patrick.Rosenheim@f204.n101.z1.fidonet.org wrote: >Why not just have two nodelists? This is what i suggest some days ago. This way we would not have to worry about old nodelist compilers and mailers. -- ciao, Marco --- ifmail v.2.12-tx8.6 * Origin: Md's Linux Box - On the Internet: md@linux.it (2:335/680.666) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1540 [1995] Scn From : Amir Shabashvili 2:5049/12 11 Nov 97 11:31:48 To : Dieter Ringhofer 17 Nov 97 06:02:40 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dieter! Replying to a message from Dieter Ringhofer to Dima Maloff: DR> binkd needs to get a complete setup. using something like vmodem needs DR> to assign a port and all is done. I've binkd.cfg 1600 bytes long, with comments and several nodes-specific lines. With 0.9.2 version I'm planning to install now I do't need some lines (this version use DNS resolving). So it is so simple to install binkd, I mean... Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1541 [1995] Rcv Scn From : Pedro Lima 2:362/21 15 Nov 97 06:26:12 To : Lothar Behet 17 Nov 97 06:02:40 Subj : Flags, especially CM and MO ------------------------------------------------------------------------------- LB> Please correct me, if I should have misinterpreted the flags as LB> defined i.e. in the nodelist. You're 100% correct, AFAIK. LB> The discussed new interpretation is as follows: LB> Some people interprete CM as nothing else than a mailer takes up the LB> line, but the mailer may not always answer a call at any time. It is LB> just a dedicated line for mailer connects, but the mailer may answer LB> or not at any time (beside ZMH). I'd then ask what's the purpose of the flag? That's the same as not having it, since ZMH compliance is mandatory by Policy and not because I fly flag A or B. That interpretation is obviously absurd, to say the least. LB> As from some countries every try for a pstn-call has to be paid LB> (AFAIK) You're correct. LB> a repeated call to a system with "busy" or "not available" LB> might get expensive for a foreign sysop. This is just "bad luck", if LB> you follow the new interpretation, as you can not rely on any LB> connection at any time :( The inventiveness of stupidity (of which selfishness is only one aspect) never ceases to amaze me... LB> For IP this point of view would also have certain drawbacks. Indeed. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1542 [1995] Scn From : Amir Shabashvili 2:5049/12 11 Nov 97 11:53:54 To : Dieter Ringhofer 17 Nov 97 06:02:40 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dieter! Replying to a message from Dieter Ringhofer to Dima Maloff: DM>> It's time to get rid of FTS-1 (as reproducing it again and again just DM>> wastes people's time), at least for IP nodes. Less code -- less DM>> bugs. DR> get rid of fidonet and you've much less work. i.e. FTS-0001 == fidonet, you mean? Really? Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1543 [1995] Scn From : Amir Shabashvili 2:5049/12 11 Nov 97 11:58:14 To : Dieter Ringhofer 17 Nov 97 06:02:40 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dieter! Replying to a message from Dieter Ringhofer to Dima Maloff: DR>>>>> Maybe this leads to an understandable example for you: DR>>>>> How does Binkd react when a password error occures (caused by a DR>>>>> typo)? DM>>>> Reports a error. DR>>> will bundles be transferred and accepted than? DM>> Of course, no. DR> how do you get a privat mail to this recipient on direct way than? Is it usial for you - install protected link, and then use wrong password? But, in case you describe, if you fordot right pwds: - use any password-unprotected AKA for connection with this node Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1544 [1995] Scn From : Chris Maddock 3:640/302 15 Nov 97 21:45:16 To : Ward Dossche + others 17 Nov 97 06:02:42 Subj : IP Nodes In The Fidonet Nodelist ------------------------------------------------------------------------------- Hi Ward (and others), I have been thinking of ways to include IP nodes in the nodelist and still have it easily distinguished from the PSTN dialable nodes. This seems to be the biggest problem/obstacle as I percieve peoples comments, when it is all boiled down. Mulling on this, is it practical to have PSTN, ISDN only and IP only nodes in their own respective sections of the nodelist ?? i.e. Have the traditional PSTN listings first with standard entries and flags etc., followed by the ISDN only nodes with their respective flags etc, followed by the IP only nodes with their respective flags etc. I'm not entirely sure of the total ramifications of this on the current compilers but I'm sure that it is possible to make the extra sections so they can be either ignored or compiled into a list of non-dialable nodes for those without ISDN and IP equipment (like me ! - but I would very much like to see ISDN and IP nodes in/involved with Fidonet). Maybe an extra program that can be set to make a PSTN =or= a ISDN =or= a IP sub-list that passes as a valid segment may make it easier for "normal" nodes - of whatever flavour. But the idea is to be able to send out nodediff's that are fully functional in all respects. A parallel thought suggests to me that the IP nodes really only need point to a Nameserver or DNS on the Internet. Now I know that this has holes in it but we need a "standard" point of contact so that non-IP nodes can communicate with the IP nodes. Maybe each zone will need to have their own main gateway(s) but a normal mail addressed to, say, "Z2IP" (for instance) should be able to be routed to this gateway and forwarded to the best of that networks ability whether it is Fidonet or whatever. I'll throw this in everyones court. I don't know enough about the total ramifications to be able to contribute a whole lot more than this except maybe the concept if it isn't clear. Best Regards, Chris Maddock chrism@bbs.st.net.au --- Msged/386 4.20 beta 2 * Origin: Diagnostic CBBS - DownUnder - (3:640/302) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1545 [1995] Scn From : Amir Shabashvili 2:5049/12 11 Nov 97 11:09:34 To : Dieter Ringhofer 17 Nov 97 06:02:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Dieter! Replying to a message from Dieter Ringhofer to Amir Shabashvili: DR> i can't agree to your statement because the seldom occurences of the DR> need to use fts-0001 it worked and i was happy to be able to have it. DR> as long as the major rule states the necessity to have it available DR> it's more than a political question, it's a question of wether DR> changing the rule or not to be a member of fidonet. Only thing I trying to say is - FTS-0001 too bad when it used over IP , and if we'll choose it as basic protocol it will be wrong way. Cheers, Amir. --- * Origin: Double Dozen Station (2:5049/12) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1546 [1995] Scn From : Pedro Lima 2:362/21 15 Nov 97 06:34:54 To : Lech Szychowski 17 Nov 97 06:02:42 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- LS> Sure. But let's not say "that's the way we do it, so a standard it LS> shall be"... ;) I defend that we don't have a mandatory IP protocol, as I doubt we even need one. LS> I've no problem with that. Experimental stuff is experimental, LS> but regular nodes are IMHO not exeprimental. I also defend that we should regard IP nodes inclusion in FidoNet as experimental. If a standard is needed, it will show up in practice. LS> Without a standard we are a bunch of separate groups. Not as long as bridging between the different technologies is possible. Having such gateways in FidoNet is usually a natural process, more social than political, but if it doesn't happen in a satisfactory way, we'll be anyway in a better position to decide what the best solution is, because we'll be working on top of acquired experience. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1547 [1995] Scn From : Nick Soveiko 2:5030/69.101 08 Nov 97 17:16:52 To : Lawrence Garvin 17 Nov 97 06:02:52 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thu, 06 Nov 1997, 08:43, Lawrence Garvin (1:106/6018) ==> Nick Soveiko: [skip] NS> nope. modem communication protocols are either physical layer NS> (v.32, v.34, etc.) or datalink layer (v.42, v.42bis). LG> I guess we'll just have to disagree on this one. But I will do some LG> additional research, studying, and thinking. If'n I change my mind LG> -- you'll be the first to know. this iso/osi reference layer model is a pretty abstract thing. projecting real life onto it gives you quite a bit of fuzzyness. but the classification given above can be found in any basic textbook on networking. so, let's stuck with traditional terminology and not invent bicycle here ;) you're entitled to your own opinion nevertheless. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1548 [1995] Scn From : Nick Soveiko 2:5030/69.101 08 Nov 97 17:12:40 To : Rune Johansen 17 Nov 97 06:02:52 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Wed, 05 Nov 1997, 23:25, Rune Johansen (2:210/20) ==> Nick Soveiko: >> Example: My mailer listens to a raw TCP port. It detects a incoming >> session. My mailer shows a banner, sends EMSI inits, and a BinkP >> init. All in the same packet. > what do you mean by 'packet' here? RJ> Let's say that my IP stack uses a MTU of 1500. The data mentioned RJ> over is a total of 300 bytes. All gets sent in one IP packet, since RJ> the buffers are not full in my IP stack until i want to send it. RJ> That's my "packet". your mailer listens to a *tcp* port. you should not make any assumptions about what's going on the ip level. all you can do with confidence with tcp socket is sending push flag. that's it. ====[ rfc-793 ]==== A sending TCP is allowed to collect data from the sending user and to send that data in segments at its own convenience, until the push function is signaled, then it must send all unsent data. When a receiving TCP sees the PUSH flag, it must not wait for more data from the sending TCP before passing the data to the receiving process. ====[ rfc-793 ]==== RJ> My test (I have been receiving party) shows that if I send "stuff" RJ> before I send BinkP init, the calling party times out. The calling RJ> party uses BinkD 0.9.1. If I don't send any "stuff" before the RJ> BinkP init, the calling party sees it, and sends M_PWD frame. send your 'stuff' encapsulated into m_nul frames. no problem as long as your 'stuff' is in pieces less than 32k each. > no, seriously, are you running out of tcp ports? i can borrow you some ;) RJ> I am not saying that I am running out of TCP ports. I am saying RJ> that you'd might want to run it all on ONE port. My FIreWall admin RJ> might be so kind to open up for ONE port for inbound connections to RJ> me, because of [events out of my control], as long as I agree to RJ> NOT let anything other than FTN mailer sessions come through. that's easy: use the most efficient protocol available. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1549 [1995] Scn From : Nick Soveiko 2:5030/69.101 08 Nov 97 17:15:04 To : Dieter Ringhofer 17 Nov 97 06:02:52 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thu, 06 Nov 1997, 17:55, Dieter Ringhofer (2:2476/14) ==> Nick Soveiko: NS> taking the slippery path of analogies, i'd say that imposing NS> fts-0001 for tcp/ip connections now is the same as imposing latin NS> as an official fidonet language. its time has gone. DR> than fidonet's time is gone as well. i agree with you on this one. and as so, i'm wrapping up with this discussuion as it became pointless. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1550 [1995] Scn From : Nick Soveiko 2:5030/23.101 12 Nov 97 16:23:38 To : Rune Johansen 17 Nov 97 06:02:52 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Fri, 07 Nov 1997, 22:26, Rune Johansen (2:210/20) ==> Nick Soveiko: > so what? that still does not automatically mean that for a multiport > implementation mandate for fts-1 capability refers to each port. as > a maximum it implies that there should be a way to connect to a node > using fts-1. but that's it. the rest is your imagination. RJ> See my explanation to Pablo about why I write all of this. afaiu, you point is inclining towards ip-only nodes. that's fine, i'm not going to argue (at least right now) about common mandatory protocol for ip-only nodes. but the chances are that your proposal is accepted while ip-only nodes are ruled out until some unspecified time in the future. in this case you proposal plays against dual capability nodes. >your proposal rules out even the nodes that already have fts-1 pstn >capability and certainly would like to announce an extended >capability that they have: binkp over tcp/ip multiplexed by ports. RJ> True. that's bad. it's my strong opinion that binkp-capable nodes won't stop using binkp even if they won't be able to announce this capability in the nodelist. what will happen is that they will seek other means of announcing it - be it dns, binkp-list, alternate nodelist, whatever. binkp will still be in use as an 'underground' transport, as it is today. so, what's the point of your proposal - to legalise 'underground' ip-based transports or to hide some of them because they are not 'kosher'? ;) > allowed to implement the protocol on a different platform and in a > different programming language. and it proved to be 100% > interoperable with binkd. RJ> By sheer luck then, I assume :-) as you like. the fact is such as i said. >> and does not have the possibility to fallback to a commonly >> implemented mailer handshake protocol, > wrong. it's done in argus. RJ> Yes, it is absolutely being done in Argus, and in BBBS. so, *the protocol* has this possibility. q.e.d. RJ> But that's no thanks to the documentation of the protocol. i can only repeat myself here: a soon as somebody tells me *what* do document, i.e. what is the exact tested and working fallback procedure, i'll do it. and i think we're close to working out the procedure in binkp mailing list. >> And, I am also saying that BinkD mailer implementation of today >> does not alone meet the requirements of being a self-sustained >> node in Fidonet. > you are arguing for the wrong point here. binkd implementation of today can > perfectly serve as an additional capability to any fidonode with ip access. > your proposal doesn't take this into account. RJ> I am arguing it from the point of wether there should be a common RJ> session level protocol in the mailer handshake, and if that is to RJ> follow policy. My proposal does not take an extended nodelist RJ> format into accounts, but it takes the current format, with a minor RJ> modification, and applies it to the use on several different types RJ> of transportation. your proposal also does not take into account a nodelist entry that looks like following: ,999,ip-bbs,fido.domain.name,joe_sysop,99-123-456-7890,9600,MO,MN,V34 what's wrong with adding a user flag U,IPR::B to this nodelist entry? RJ> If we say that the IP part of a multi-functionality node does not RJ> need a common session level protocol, generally speaking, that would be advantageous. but for nodes already supporting fts-0001 during zmh on nodelisted phonenumber that's an absolutely unnecessary demand. RJ> I will stop arguing that we in that case must use the one defined RJ> in policy. It would then also imply that a IP-only node would not RJ> need that either. well, ip-only nodes are a different issue. i don't see why *this* might imply anything for ip-only. RJ> If a common session level protocol is not needed, then a common IP RJ> transport protocol is not needed either. That means that a RJ> Telnet-protocol node cannot be contacted by a raw TCP node, even RJ> if they are using the same session level protocol. So, if you want RJ> to connect to another node that does not run the same transport RJ> protocol _and_ session level protocol as you, you have to get hold RJ> of software that is compatible with the one you want to contact. RJ> It's that simple. yep. and the difference from the existing situation of modem/isdn incompatibility is that such software might be available for free. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1551 [1995] Scn From : Pedro Lima 2:362/21 14 Nov 97 19:05:44 To : Lawrence Garvin 17 Nov 97 06:02:52 Subj : Defining a standard protocol - why? ------------------------------------------------------------------------------- LG> Which is -exactly- why that information does not need to be in the LG> NODELIST. Do you know GoldEd, RemoteAccess or O-T/Track just to mention a few? These aren't mailers, but they do use the nodelist, and particularly the latter would be almost worthless without one. A similar reasoning would apply to an e-mail tunneling software of some kind. The nodelist isn't solely for mailer consumption. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1552 [1995] Scn From : Nick Soveiko 2:5030/23.101 12 Nov 97 17:58:42 To : Lech Szychowski 17 Nov 97 06:02:52 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sun, 09 Nov 1997, 22:57, Lech Szychowski (2:480/33.7) ==> Dima Maloff: > I can interpret forcing of binkp-only sysops to support FTS-1 only one > way -- authours and/or users of commercial software make problems for > users/authours of free software (To increase their "market share" > politically?) Not fair. LS> Forget the marketing/money stuff. I doubt it's an issue here. i doubt so too. but when somebody rolls out a nodelist proposal that requires binkp-capable systems to support fts-0001 on the same port, and at the same time this person runs a registration site for the only one mailer that is going to implement this requirement, *this* makes one suspitious. disclaimer: the above situation is just a result of my sick imagination. ;) cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1553 [1995] Scn From : Nick Soveiko 2:5030/23.101 12 Nov 97 17:52:26 To : Lech Szychowski 17 Nov 97 06:02:54 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Sun, 09 Nov 1997, 23:29, Lech Szychowski (2:480/33.7) ==> Dima Maloff: LS> it's not about number of nodes, it's about technical LS> efficiency/excellence/suitability. well, in this respect you can't beat binkp with emsi/zmodem/hydra/fts-1 either. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1554 [1995] Scn From : Nick Soveiko 2:5030/69.101 08 Nov 97 17:17:20 To : Lawrence Garvin 17 Nov 97 06:02:54 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Thu, 06 Nov 1997, 20:32, Lawrence Garvin (1:106/6018) ==> Nick Soveiko: NS> i've just searched p4.07 for the word 'modem' and there's only one NS> reference to it in paragraph 2.2, where sysop has to communicate NS> type of modem to the net coordinator when he applies for a NS> nodenumber. it doesn't even say that the modem should support one NS> of the standard protocols (sic!). LG> No, but it does require the sysop to provide the NC with the LG> telephone number that the modem is connected to. Ostensibly so that LG> the NC can validate that the mailer is functioning before issuing LG> the node number. so, the only thing required from this modem is to be compatible with the one at nc side. this in no way guarantees compatibility with all other members of fidonet. it does guarantee functionality of hostrouting though. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1555 [1995] Scn From : Nick Soveiko 2:5030/23.101 08 Nov 97 17:16:06 To : Dieter Ringhofer 17 Nov 97 06:02:54 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- Thu, 06 Nov 1997, 18:16, Dieter Ringhofer (2:2476/14) ==> Nick Soveiko: NS>> A stream of data sent on a TCP connection is delivered reliably and in NS>> order at the destination. DR>> what about datagram oriented services? NS> like? DR> nfs nfs is an rpc-application and uses udp as a transport. we're speaking about tcp. NS> oh, yeah. the data should be successfully passed from the NS> transport layer upstream. if your tcp/ip stack dumps the data to NS> /dev/nul, shure it's unreliable like hell. DR> this can happen by accident. anything can happen by accident. consider amount of data being carried by tcp everyday (http, ftp, smtp, nntp to name a few) and chances of it arriving corrupted. for all practical purposes it's reliable. NS>> did the protocol you've been using have autoresume? DR>> i tried it with conventional tcp/ip services as well as via vmodem. DR>> the link has been unreliable everytimes. NS> unreliable you mean frequently dropped connection, right? DR> no, i mean to slow. very much to slow to be precise, because DR> reliability is also a matter of costs (see other mail). traceroute DR> showed several hops with at least 3 secs response time ... both are not a problem for binkp. i have rtt to one of my uplinks varying from 700 to 12000ms with up to 40% icmp packet loss - zmodem doesn't work, hydra doesn't work, ftp barely works, binkp works just fine. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1556 [1995] Scn From : Nick Soveiko 2:5030/23.101 12 Nov 97 17:06:10 To : Rune Johansen 17 Nov 97 06:02:54 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- Fri, 07 Nov 1997, 22:41, Rune Johansen (2:210/20) ==> Marco d'Itri: RJ> Sound like MS to me... There is no reason to run Linux, when you RJ> can run Windows on you machine. It also got a word processor :-) actually, it's the other way around - there's no need to run windows if you can run linux. at least, you don't have to pay for linux and you won't stuck up with proprietary stuff. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1557 [1995] Scn From : Roger Sen Montero 2:343/106 27 Oct 97 22:26:06 To : Lech Szychowski 17 Nov 97 06:03:04 Subj : A bit of steering ... ------------------------------------------------------------------------------- Hola Lech! 23 Oct 97 03:00, Lech Szychowski wrote to Marco d'Itri: >> Every modern BIND version supports round robin. LS> Are you 101% sure? I'm pretty sure it is not possible for BIND LS> to guarantee that host X (possibly having more that one IP address) LS> issuing N requests (possibly randomly distributed in quite a long LS> period of time) for a type A record of a host Y (that has N addresses) LS> will get all (ie N) addresses. If I recall correctly, RFC does not enforce round-robbin. Saludos. Roger. - rogersm@tau.uab.es ... We ride ... to hell. Or to glory. It depends on your point of view. --- Squish/386 v1.11 * Origin: Pro-Line BBS - Nuevo Telefono: (93) 442-7950 (2:343/106) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1558 [1995] Rcv Scn From : Frank Ellermann 2:240/5815.1 15 Nov 97 01:24:00 To : Lothar Behet 17 Nov 97 06:03:04 Subj : Flags, especially CM and MO ------------------------------------------------------------------------------- Hello Lothar... LB> This is just "bad luck", if you follow the new interpretation ...............................................^^^...............??? I'm very sorry, but there's nothing new about this interpretation, it's exactly as old as the flag CM itself. Take a look into P4.07, section 2.3: > In short, the only thing which should ever answer the telephone > during periods when the nodelist indicates that your node will > accept mail is FidoNet-compatible software which accepts mail. The difference between CM and ZMH is defined in section 2.1.8, so CM was never meant as "24-hours-ZMH". The simple reason for this, single-tasking systems online 24/365 fly CM, what else ? And even multi-tasking systems may be BUSY almost the whole day except from ZMH, and of course they fly CM. If you want a new guarantee of availability, you need a new flag, or what's your idea ? Force all systems not available the whole day to fly U,Tdc maybe ? Bye, Frank --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1559 [1995] Scn From : Nick Soveiko 2:5030/23.101 15 Nov 97 21:35:50 To : Patrick Rosenheim 17 Nov 97 18:36:12 Subj : FTS-0001 in IP nodes ------------------------------------------------------------------------------- Thu, 13 Nov 1997, 23:23, Patrick Rosenheim (1:101/204) ==> Rune Johansen: PR> Why not just have two nodelists? PR> Just like we now have BACKBONE.NA & BACKBONE.NO, as well as PR> FILEBONE.NA & FILEBONE.NO.... PR> We could have NODELIST.xxx & IPMAILER.xxx PR> Or, am I missing the point? kind of... right now we already have many kinds of more or less unofficial lists for ip-connectivity (last year ip-list for r50 was maintained by no one else, but r50c himself). ip should finally be legalised in fidonet. and the only way to legalise this transport is to indicate ip capabilities in *the* nodelist. otherwise the nodelist will eventually become useless. e.g. my mailer don't use it at all already - it forms fqdn from ftn address and resolves ip addresses through fidonet.net dns. the only thing i'd like to see in the nodelist is the flag indicating binkp capability. voila... that's the point as i see it. cheers, nick --- Handwritten * Origin: <-<-<- houses of the hairy (overseas) ->->-> (2:5030/23.101) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1560 [1995] Scn From : Udo Zaydowicz 2:2446/317 17 Nov 97 18:41:48 To : Frank Ellermann 17 Nov 97 18:47:04 Subj : Flags, especially CM and MO ------------------------------------------------------------------------------- Moin Frank! Frank Ellermann -> Lothar Behet, 15.11.97: "Flags, especially CM and MO" [new interpretation] FE> I'm very sorry, but there's nothing new about this interpretation, FE> it's exactly as old as the flag CM itself. Take a look into P4.07, FE> section 2.3: >> In short, the only thing which should ever answer the telephone >> during periods when the nodelist indicates that your node will >> accept mail is FidoNet-compatible software which accepts mail. You forgot at least one vital aspect - the reason why (also see 2.1.8.): P4.07> racking up large phone bills, which is very annoying. If - according to the "new interpretation" - the only requirement is, that a mailer answers a call but there is no requirement, that a mailer is answering a call 24 hours/day, "racking up large phone bills" is guaranteed in some regions. Another point: P4.07> indicates that your node will accept mail Well, nothing else is indicated by the CM-Flag: FTS-5> CM Node accepts mail 24 hours a day Simple reasoning: You can not accept mail 24 hours/day if the mailer isn't up for 24 hours/day. FE> The difference between CM and ZMH is defined in section 2.1.8, so CM FE> was never meant as "24-hours-ZMH". There is no such definition. On the contrary: P4.07> It is permissible to have greater capability (for example, to P4.07> support additional protocols or extended mail hours), That is exactly what is done by the CM-flag: the mail hour is extended from ZMH to 24 hours/day. Next sentence states the requirement regarding this mail hour: P4.07> This time is exclusively reserved for netmail. => According to Policy Your interpretation IMO is wrong. And, more important => , according to common sense Your interpretation is wrong, too: carrying a CM-flag is of no use at all, if the node concerned is not willing to or able to accept mail 24 hours/day. Therefore You would'nt need a new flag: FE> If you want a new guarantee of availability, you need a new flag, Just use the CM-flag ;-). [...] FE> Force all systems not available the whole day to fly U,Tdc maybe ? Why not. It's just fair. It could save time, effort and - more important - money. Well, so far for the 'academic' part of this discussion. In praxi, however, it is a different story: technical problems, sense or nonsense of ZMH or of some requirements acc. FTS-1, observance and enforcement of rules and regs etc.. Quite normal in Fido . Tschuess, Udo! --- FleetStreet 1.18+ * Origin: Wat mutt dat mutt (2:2446/317) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1561 [1995] Scn From : Lech Szychowski 2:480/33.7 17 Nov 97 11:43:00 To : Nick Soveiko 18 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > i doubt so too. but when somebody rolls out a nodelist proposal that > requires binkp-capable systems to support fts-0001 on the same port, and > at the same time this person runs a registration site for the only one Yes, that would seem at least unfair for me, too. > disclaimer: the above situation is just a result of my sick imagination. ;) And most likely/hopefully it will remain so :) Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1562 [1995] Scn From : Lech Szychowski 2:480/33.7 17 Nov 97 11:42:00 To : Nick Soveiko 18 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > LS> it's not about number of nodes, it's about technical > LS> efficiency/excellence/suitability. > well, in this respect you can't beat binkp with emsi/zmodem/hydra/fts-1 > either. Once again: I'm not saying I can; what I'm saying is we need some real technical reasons, not just "we use it and for us it's better". Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1563 [1995] Scn From : Lech Szychowski 2:480/33.7 17 Nov 97 11:59:00 To : Pedro Lima 18 Nov 97 05:43:12 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > I defend that we don't have a mandatory IP protocol, as I doubt we even > need one. Well, then it's one point we surely disagree on. > I also defend that we should regard IP nodes inclusion in FidoNet as > experimental. If a standard is needed, it will show up in practice. If we stick to this "purely experimental" attitude, we might just say: use Pvt entries, put FQDN as system name, IP address as phone numer (dots replaced with dashes), agree on some basic flags and there we go. > LS> Without a standard we are a bunch of separate groups. > Not as long as bridging between the different technologies is possible. We do have email<->netmail gateways now. What else do we need then? Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1564 [1995] Scn From : Lech Szychowski 2:480/33.7 17 Nov 97 11:53:00 To : Lawrence Garvin 18 Nov 97 05:43:12 Subj : IP-access ------------------------------------------------------------------------------- > LS> the very first time, (a) will work as much as (b), right? > Not necessarily! > As has already been documented, not all Nets in Zone 1 have active MX > records. And that completely wrong, at least IMHO. Forgetting about all political issues, is there any real reasons behind it? > However, I -can- guarantee that as long as I have a Fidonet node, I will > continue to be available at eforest.houston.tx.us, and probably tcrs.org. Yes, but it has nothing to do with Fido. True, it has everything to do with ways to contact you, Lawrence Garvin. But you are much more than a sysop of 1:106/6018, right? :) > Except that tcrs.org is -exclusively- associated with Fido. If all the MX stuff was maintained properly in your zone, would you still really need this additional name? > LS> I think majority of us have email addresses/accounts without > LS> having admin authority over the systems that carry them. > True, but most have some sort of contractual arrangement which > guarantees access to those accounts as long as the bill is paid. Speaking about "as long as the bill is paid", I doubt this is true. I'm pretty sure ISPs have legal ways of dropping the deal, as customers have. > No reason I can think of, except that the *C has no authority to appoint > anybody to maintain a DNS zone. Point taken. That's one more thing we have to keep in mind when trying to create any "Fido & IP/Internet" proposal. Leszek. --- FastEcho+ 1.45 * Origin: Abandon hope all ye enter here (2:480/33.7) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1565 [1995] Scn From : Dieter Ringhofer 2:2476/14 18 Nov 97 05:28:54 To : Amir Shabashvili 18 Nov 97 18:18:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>> i can't agree to your statement because the seldom occurences of the DR>> need to use fts-0001 it worked and i was happy to be able to have it. DR>> as long as the major rule states the necessity to have it available DR>> it's more than a political question, it's a question of wether DR>> changing the rule or not to be a member of fidonet. AS> Only thing I trying to say is - FTS-0001 too bad when it used over IP , AS> and if we'll choose it as basic protocol it will be wrong way. it works bad on pstn connects as well but: it works in case of need. the problem settles down somewhere in 'political areas', the can of worms is opened: some people are discussing the definition of CM flag an use ip-nodes as an example. when there's no chance for a 'conventional' node to have a common handshake with ip-nodes, we can skip all. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1566 [1995] Scn From : Dieter Ringhofer 2:2476/14 18 Nov 97 05:32:28 To : Amir Shabashvili 18 Nov 97 18:18:14 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- DR>>>>>> Maybe this leads to an understandable example for you: DR>>>>>> How does Binkd react when a password error occures (caused by a DR>>>>>> typo)? DM>>>>> Reports a error. DR>>>> will bundles be transferred and accepted than? DM>>> Of course, no. DR>> how do you get a privat mail to this recipient on direct way than? AS> Is it usial for you - install protected link, and then use wrong password? AS> But, in case you describe, if you fordot right pwds: AS> - use any password-unprotected AKA for connection with this node there's no need for this with fts-0001. --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1567 [1995] Scn From : Dieter Ringhofer 2:2476/14 18 Nov 97 05:22:12 To : Nick Soveiko 18 Nov 97 18:18:14 Subj : Proposal for listing as IP-node ------------------------------------------------------------------------------- NS>> unreliable you mean frequently dropped connection, right? DR>> no, i mean to slow. very much to slow to be precise, because DR>> reliability is also a matter of costs (see other mail). traceroute DR>> showed several hops with at least 3 secs response time ... NS> both are not a problem for binkp. but it's a problem of the phonebill. if a direct call is cheaper (even when being long distance), which kind of connect would you prefer? NS> i have rtt to one of my uplinks varying from 700 to 12000ms with up to NS> 40% icmp packet loss - zmodem doesn't work, NS> hydra doesn't work, ftp barely works, binkp works just fine. fine. btw, would you send me a complete specification of binkp, please? i'm sorry, but i don't have the time to search in distributed (incomplete) specs and source of binkd as well to get a real imagination about it. you can send it to diri@quattro.bb.bawue.de to reduce ftn-traffic ;) --- * Origin: LOGO - Telekom's Darling (2:2476/14) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1568 [1995] Rcv Scn From : Pablo Saratxaga 2:293/2219 14 Nov 97 01:11:30 To : Lothar Behet 19 Nov 97 05:38:20 Subj : Re: IP - Call for opinion votes ------------------------------------------------------------------------------- From: Pablo Saratxaga Kaixo! on Mon, 10 Nov 97 06:46:26 +0100, Lothar Behet said: PS>> The Txy flags are much more important as they show the *real* online PS>> time as opposed to the *theorical* online time. LB> Did you monitor the contents of Txy at change of time-offset between LB> summer- and winter-time, as this is relative to UTC? My mailer does check the current time and the allowed (U,Txy) call time. My OS does the summer/winter hour change. And it is told in the proposal of Txy flags to keep in mind that summer/winter hour problem when choosing the x and y values, that is for exemple if a given node is online from 22:00 to 07:30, in Belgium, that is either from 20:00 to 05:30 or from 21:00 to 06:30 in UTC, depending on the date. So that nodes must show an online time of 21:00 to 05:30 UTC, so there is no more problem of summer/winter time. Yes we loose two hours, but that is still much better than ZMH, which BTW has the same winter/summer problem, but with only one hour listed the two hours incertitude is a little too much :) -- Agur eta gero arte, Pablo Saratxaga PGP keyID: 0x8F0E4975 --- ifmail v.2.12-tx8.7 * Origin: Unknown (2:293/2219@fidonet) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1569 [1995] Scn From : Pedro Lima 2:362/21 17 Nov 97 05:04:06 To : Frank Ellermann 19 Nov 97 05:38:20 Subj : Flags, especially CM and MO ------------------------------------------------------------------------------- > the only thing which should ever answer the telephone (...) > is FidoNet-compatible software which accepts mail. FE> The difference between CM and ZMH is defined in section 2.1.8, so FE> CM was never meant as "24-hours-ZMH". There is a difference between what answers the phone and what is available by calling that number. Mailers can and do exit to other programs using the same line (like a BBS or fax software) if it's not a mail call. Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1570 [1995] Scn From : Lawrence Garvin 1:106/6018 18 Nov 97 08:14:18 To : Lech Szychowski 19 Nov 97 19:28:06 Subj : IP-access ------------------------------------------------------------------------------- Lech Szychowski said in a message to Lawrence Garvin: > As has already been documented, not all Nets in Zone 1 have active MX > records. LS> And that completely wrong, at least IMHO. Forgetting about all LS> political issues, is there any real reasons behind it? My guess is that it's a simple oversight, perhaps even an innocent error in the zone files at z1.fidonet.org. On the other hand, it may be that George Peace is only adding MX records as requested, and that some nets simply haven't submitted a request. It could also be that there's no regional gate for those nets as well. Perhaps I'll take a 'trip' into z1.fidonet.org, and do a dump of the MX records and see what I can see. LS> Yes, but it has nothing to do with Fido. True, it has everything to LS> do with ways to contact you, Lawrence Garvin. But you are much more LS> than a sysop of 1:106/6018, right? :) > Except that tcrs.org is -exclusively- associated with Fido. LS> If all the MX stuff was maintained properly in your zone, would you LS> still really need this additional name? It's not about _NEED_, it's about _WANT_. And quite frankly, it's about the rather awkwardly long naming conventions of an email address using the fidonet.org conventions. It's bad enough that my work address is as long as it is, at least my personal address can be short enough to be functional. LS> Speaking about "as long as the bill is paid", I doubt this is true. LS> I'm pretty sure ISPs have legal ways of dropping the deal, as LS> customers have. I'm sure that, at least in our country, ISPs are covered by retail contracting laws, just as most other service agencies are. In the U.S. there is much consideration given to the plight of the customer. Essentially, the courts cut the seller very little slack. About the only way to "drop" the deal is with notice at the end of the contract period. --- * Origin: lawrence@eforest.houston.tx.us | The Enchanted Forest (1:106/6018) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1571 [1995] Snt Loc Scn From : Lothar Behet 2:2446/301 20 Nov 97 00:15:14 To : Lech Szychowski Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- Hello Lech! On 17 Nov 97 wrote Lech Szychowski to Pedro Lima: >> I defend that we don't have a mandatory IP protocol, as I doubt we >> even need one. LS> Well, then it's one point we surely disagree on. Possibilties for IP: - BinkD is available for nearly every OS except DOS - Telnet is suported on every platform (afaik) - VModem (includes Telnet additionally) is supported at least on OS/2 and Wxx Possibilities for conventional connects: - analog (Vxx, Bell, PEP, HST,... not all compatible with each other) - ISDN 56K (i.e. US) - ISDN 64K Before you require one standard protocol for ip you should first solve the in-connectivity on conventional level :) >> I also defend that we should regard IP nodes inclusion in FidoNet >> as experimental. If a standard is needed, it will show up in >> practice. LS> If we stick to this "purely experimental" attitude, we might just LS> say: use Pvt entries, put FQDN as system name, IP address as phone LS> numer (dots replaced with dashes), agree on some basic flags and LS> there we go. If you scratch the ip# in the phone-field, we just need additional flags for most ip-nodes in combined entries :) >> LS> Without a standard we are a bunch of separate groups. >> Not as long as bridging between the different technologies is >> possible. LS> We do have email<->netmail gateways now. What else do we need then? You don't need gateways for ip-tunneling with any mailer sessions, just known routing systems with specified protocol flags :) Regards, Lothar --- GoldED/2 3.00.Beta1+ * Origin: tea allocation error, operator halted (2:2446/301) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1572 [1995] Scn From : Rune Johansen 2:210/20 17 Nov 97 23:36:16 To : Nick Soveiko 20 Nov 97 00:31:40 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >'underground' transport, as it is today. so, what's the point of your proposal >- to legalise 'underground' ip-based transports or to hide some of them becaus > they are not 'kosher'? ;) My proposal was based on FTS-0001 demand for all ports and means of connection. It was also based on one address field only, to allow for future transport mechanisms in existing nodelist format. Something will have to loose in that situation. I have not said that it _has_ to be that way, if we want to have it another way. >>> and does not have the possibility to fallback to a commonly >>> implemented mailer handshake protocol, >> wrong. it's done in argus. >> Yes, it is absolutely being done in Argus, and in BBBS. > so, *the protocol* has this possibility. q.e.d. The implementation of the mailer has made it possible. I just say that the BinkD mailer does not accomplish this per date. >i can only repeat myself here: a soon as somebody tells me *what* do document, >i.e. what is the exact tested and working fallback procedure, i'll do it. and > think we're close to working out the procedure in binkp mailing list. Great, I look forward to see it. >your proposal also does not take into account a nodelist entry that looks like > following: > ,999,ip-bbs,fido.domain.name,joe_sysop,99-123-456-7890,9600,MO,MN,V34 > what's wrong with adding a user flag U,IPR::B to this nodelist entry? I keep on repeating myself, as it seems that several people has misunderstood the basis of my proposal: ONE address field, not TWO (or more). And FTS-0001 requirement to all means of connection. I can write a second proposal that use the system name field, or location field as IP address (or FQDN), to allow for dual capability nodes. That would be written on a different basis than my first proposal. > yep. and the difference from the existing situation of modem/isdn > incompatibility is that such software might be available for free. Wether the software is free or not has nothing to do with the technical specifications of the sessions or transports. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1573 [1995] Scn From : Rune Johansen 2:210/20 17 Nov 97 23:00:28 To : Lawrence Garvin 20 Nov 97 00:31:40 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >> But, what when there comes another transport mechanism to town? > Well..... we should deal with that '[an]other transport mechanism' then! In the meantime we would get tangled up in Yet Another Fuzzy Way Of Doing Things. :-)) >> What if I have one PSTN telno, one FQDN and one X25 address, and >> want it all in the same nodelist entry? > What transport mechanism is your X.25 coming across? It can come across a modem that dials a PAD, or over a X.25 interface card. > I guess the answer to the question is -how- is traffic for your X.25 address >transported -physically-. I'm not real familiar with X.25 so I need some basic > info to answer your question. X.25 is defined as the three lowest layers in the protocol hierarchy. X.25 layer 1 deals with the electrical, mechanical, procedural and functional interface between the DCE and DTE, via the X.21 and X.21bis, wich is digital and analog interfaces, respectively (X.21bis resembles the RS232-C standard). Layer 2 ensures reliable communication between DCE and DTE, by using LAP and LAPB protocols. Layer 3 manages connections between a pair of DTEs. The addressing system used in X.25 is defined in CCITT recommendation X.121. Each host is defined by a decimal number consisting of a country code, a network code, and an address within the specified network. It is similar to a PSTN number. The X.25 standard was written in 1976. > But at some point there needs to be a finite definition of the fields in the > nodelist, and at some point -some- technology won't fit. :( That's why the finite definition must be so flexible that it can fit. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1574 [1995] Scn From : Rune Johansen 2:210/20 17 Nov 97 23:04:16 To : Marco d'Itri 20 Nov 97 00:31:40 Subj : Re: IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- >>> Anyway, you still haven't explained why using a single daemon on one port >>> for all services is a good tecnical solution. >> I thought that I had explained why I have them on the same port. > No, you explained me that your software can't listen on multiple ports. My software cannot listen on multiple ports simultaneoulsy, no. Inetd can spawn my software. In my NT system I run one daemon per port, that can spawn multiple clients. > The fact that the design of a program is broken is not a technical > explanation. I did not give you a technical explanation either. I gave you _my_ reasons for having all FTN-related services on _one_ port. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1575 [1995] Scn From : Rune Johansen 2:210/20 17 Nov 97 23:16:38 To : Pedro Lima 20 Nov 97 00:31:40 Subj : Rune's 1st proposal ------------------------------------------------------------------------------- > That could be useful to isolate IP-connectable nodes, however my idea was > also to be able to easily filter them out, leaving the modem-dialable It would be equally easy to only include those that have flags you can connect to. If you have a modem that can do only analog connects, you would filter out anything that does not have your compatible flags. That way new transports can be introduced without you having to worry about dialling the litte old lady next door by mistake :-) > Also, if using the same entry, behavioral differences between the modem > access and the IP access (such as on-line time or FREQ capabilities or > the ability to handle compressed packets or...) would need their own set > of flags, and the flag space is indeed limited, besides making the line > more difficult to read (the nodelist isn't solely for machine > consumption). If a nodes capabilites and online times differ significantly, I would urge them to use separate node entrys, based on current nodelist format. > Yes, a good idea if most nodes are running mailers capable of accepting > wildcards in flag declaration for filtering purposes, although I find > them not very "readable". And of course, making them readable such as > 'IPTELN' or something of the sort would probably be a waste of nodelist > space. At least, a IPT entry is easier to read (by humans or text finders) than a compressed flag field based on bit location. :-) In my mailer I adjust the dial string based on the flags. If IPT is encountered, I dial with telnet protocol. If IPR is found, I dial raw TCP socket. If V34 is found, I leave it up to my modem node to dial. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1576 [1995] Scn From : Rune Johansen 2:210/20 17 Nov 97 23:38:38 To : Nick Soveiko 20 Nov 97 00:31:40 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- > i doubt so too. but when somebody rolls out a nodelist proposal that requires > binkp-capable systems to support fts-0001 on the same port, and at the same >time this person runs a registration site for the only one mailer that is goin > to implement this requirement, *this* makes one suspitious. > disclaimer: the above situation is just a result of my sick imagination. ;) :)) I can surely differ between my BBBS-regsite-role and my IP-in-the-nodelist-role. I don't advocate you or anyone else to use BBBS base on the IP-in-nodelist discussion. I just point out that things can be done, like it has been done here. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1577 [1995] Scn From : Rune Johansen 2:210/20 17 Nov 97 22:37:14 To : Chris Maddock 20 Nov 97 00:31:40 Subj : IP Nodes In The Fidonet Nodelist ------------------------------------------------------------------------------- > I'm not entirely sure of the total ramifications of this on the current > compilers but I'm sure that it is possible to make the extra sections so they > can be either ignored or compiled into a list of non-dialable nodes for those > without ISDN and IP equipment (like me ! - but I would very much like to see > ISDN and IP nodes in/involved with Fidonet). The easiest part is that _you_ list the flags that you can connect to as dialable, and make the nodes that don't have any of them undiallable. If you come across a node that has got none of your compatible flags, you can't dial. >A parallel thought suggests to me that the IP nodes really only need point to >Nameserver or DNS on the Internet. Now I know that this has holes in it but we > need a "standard" point of contact so that non-IP nodes can communicate with >the IP nodes. Maybe each zone will need to have their own main gateway(s) but > normal mail addressed to, say, "Z2IP" (for instance) should be able to be > routed to this gateway and forwarded to the best of that networks ability > whether it is Fidonet or whatever. I would guess that the nodes that have got capabilites that are not in the reach of current "required" technology (read: analog modem) is responsible for making arrangements with nodes higher up, so that they can recieve routed mail. So, if your analog modem cannot contact a node, due to ISDN or IP (or whatever), you should route it via the HUB, HOST, REGION or ZONE, where you find it suitable. If you can check in that order, you would get closest to the node in question. The node itself would have to be sure that it would actually work that way. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1578 [1995] Scn From : Rune Johansen 2:210/20 17 Nov 97 23:40:30 To : Patrick Rosenheim 20 Nov 97 00:31:40 Subj : FTS-0001 in IP nodes ------------------------------------------------------------------------------- > EMFBI, but.... OK. > Why not just have two nodelists? Because we are discussing how to include IP nodes in the nodelist in this echo. > Just like we now have BACKBONE.NA & BACKBONE.NO, as well as FILEBONE.NA > & FILEBONE.NO.... You have that in zone 1. We don't have that in zone 2. > We could have NODELIST.xxx & IPMAILER.xxx > Or, am I missing the point? Yep. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1579 [1995] Scn From : Rune Johansen 2:210/20 17 Nov 97 23:07:16 To : Marco d'Itri 20 Nov 97 00:31:40 Subj : Re: Rune's 1st proposal ------------------------------------------------------------------------------- > Logic tells me that only good protocols should be used. There is no reason to > run Binkp over any protocol other than RAW, the problem is in bbbs that can't > do better. Wrong. BBBS can run BinkP over Telnet, RAW, VModem and modem. Try to connect to the ports defined at 2:2/3011, and you will see BinkP init in all of them. I have included a BinkP only listener too, to support those using BinkD mailer. --- BBBS/2 v3.42 ToMmIk-6v * Origin: BarCode BBS - now with ISDN at 47-67061044 (2:210/20) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1580 [1995] Scn From : Ask Bjoern Hansen 2:235/10 18 Nov 97 20:30:54 To : Slava Filimonov 21 Nov 97 06:02:04 Subj : IP - Call for opinion votes ------------------------------------------------------------------------------- Hello Slava! Thursday November 06 1997 10:54, Slava Filimonov wrote to Ask Bjoern Hansen: WD>>> 6. Should IP-nodes fullfill standard claims like ZMH or at WD>>> least clearly stated online times according to the fidonet WD>>> policy? AH>> IP nodes should be CM as standard, and only anything else if it's AH>> stated by a IPTxy or similar flag. [..] SF> Why? It's obvious. I even can't imagine such stupid thing as internet SF> with IPTxy flags for smtp servers. Who are talking about smtp servers? I'm not. :-) ask --- GoldED/2 3.00.Alpha4+ * Origin: Windows? WINDOWS?!? Hahahahahehehehehohohoho... (2:235/10) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1581 [1995] Scn From : Frank Ellermann 2:240/5815.1 19 Nov 97 05:28:00 To : Udo Zaydowicz 21 Nov 97 06:07:40 Subj : Flags, especially CM and MO ------------------------------------------------------------------------------- Hello Udo... OOTC: What's the technical problem with future non-CM IP-nodes ? Bye, Frank ~~~ off topic ~~~ UZ> "racking up large phone bills" is guaranteed in some regions. ... of course, that's why ZMH is very different from CM. In some regions each call-attempt causes costs, whether the other side is BUSY or free or answers with a mailer: no free ride. To be BUSY is quite normal for a BBS, it's its purpose, and to be free is quite normal for a single line system, therefore this "new" interpretation of CM is plain nonsense. UZ> That is exactly what is done by the CM-flag: the mail hour UZ> is extended from ZMH to 24 hours/day. Nope... the only flags extending mail hours are #nn and !nn, CM has nothing to do with mail hours. UZ> According to Policy Your interpretation IMO is wrong. I didn't "interprete" something, I simply quoted it, just read and understand it, maybe imagine that you have a DOS based BBS. Available 24/365 except from times needed for tossing, callers, polling, backup, compiling nodelists, and so on, you guess it... this is CM, what else ? --- * Origin: xyzzy (2:240/5815.1) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1582 [1995] Scn From : Pedro Lima 2:362/21 19 Nov 97 05:42:42 To : Lech Szychowski 21 Nov 97 06:09:40 Subj : IMPORTANT! standard of protocol for ip-nodes proposal. ------------------------------------------------------------------------------- LS> Well, then it's one point we surely disagree on. Ok. :-) LS> If we stick to this "purely experimental" attitude, we might just LS> say: use Pvt entries, put FQDN as system name, IP address as phone LS> numer (dots replaced with dashes), agree on some basic flags and LS> there we go. I didn't say "purely experimental". Many of the gory details have already been sorted out by now, and that's why we have BinkD, VModem, ifcico and possibly others... There are still however some things to work out, like the technical impact of these nodes appearing in the nodelist (these entries would have to be tested against the mailers in use throughout FidoNet which excludes the use of the Pvt flag) and the social impact which is unforseeable and of which having or not a minimum standard is just an aspect. LS> We do have email<->netmail gateways now. What else do we need then? For one, we need to extend the direct connectivity possibilities. Although some modem or ISDN nodes won't be able to profit directly from the inclusion of IP nodes, some others, although not listed as IP-capable, could be able to do so. For two, to be open to new technologies may improve Fidonet's usage and consequently its partitipation. Naturally, lots of junk would appear, but also some good stuff, as with everything. For three, to have connections worldwide at the cost of a local call is a FidoNetter's dream. This may in fact provide the solution for cost-and-time-efficient netmail routing. Imagine (purely fictional as of yet) if all hosts had an IP connection, no need for complicated and (at least collectively) expensive routing. Even if only some of them would be doing it, it would still be better than what we have nowadays. Shall I continue? Regards, Pedro --- * Origin: Kaos BBS * +351-1-3572525 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- IP_CONNECT - Msg : #1583 [1995] Scn From : Amir Shabashvili