- 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