• proposed new nodelist [2]

    From Jasen Betts@3:640/531.42 to mark lewis on Friday, July 26, 2002 10:23:39
    Hi mark.

    24-Jul-02 17:01:50, mark lewis wrote to Jasen Betts

    are they three nodes ot is it one?

    i would have to say yes,

    yes=3 or yes=1 ? or yes="that's an unfair question"

    Bye <=-

    ---
    * Origin: BLISS is ignorance (3:640/531.42)
  • From Neil Walker@1:218/903 to mark lewis on Wednesday, July 17, 2002 17:08:10
    Hello mark!

    Monday July 15 2002 19:13, you wrote to me:

    Besides, I've yet to come across a program that amkes any use of
    that field in the nodelist other than to simply display it. ;-) It's
    more for human readability than anything else.

    my FrontDoor sure makes use of it... i've settings to call systems
    with speeds above and below certain thresholds... i can even set up certain modem inits based on the speed field, if i need to...

    Considering the nodelist can only contain speeds up to 9600 (yes, I know Zone 1

    does it's own thing ;-) ), the other modem flags are far more useful for that.

    I also need to seperate calls according to the receivers capability (ISDN, V34,

    V32, etc.) and I do it with those flags.


    Be lucky,

    Neil

    This OS/2 system uptime is 2 days 12:21 hours and 22 seconds

    ... You have the capacity to learn from mistakes. You'll learn a lot today.
    --- GoldED/2 3.0.1
    # Origin: The Electric Pigeon, Telford, UK (2:250/501)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to Malcolm Miles on Tuesday, July 16, 2002 13:25:36
    Hi Malcolm.

    15-Jul-02 16:16:42, Malcolm Miles wrote to Jasen Betts

    On Jul 14, 2002 Jasen Betts wrote to Peter Knapper:

    My current messages have been aimed at something completely new
    JUST for IP nodes, leave the PSTN side of things alone as they
    are

    Leave them broken? why?

    The current Nodelist is NOT broken to me.

    you are not all of fidonet...

    It is not broken for me either. Seeing that the current nodelist
    format has kept Fidonet running for at over 10 years, including
    supporting IP nodes, I don't think you could say it is broken.

    It's brokren because it provides bogus contact information in some
    instances.

    Granted, although the current format does support IP nodes, it is
    a kludge and what we are looking for here is a more ideal
    solution. If we can use standard Internet protocols and services
    then I believe that is the correct way to go. No point in
    inventing our own protocols and services which, in reality, nobody
    is going to code up

    That's a good thing, but you're still relying on a nodelist of
    sorts, all you've trimmed from it are the capability flags. if
    you're a dedicated anarchist you may want to to a less structured
    model like gnutella for instance. - something like that could
    probably be modified for ftn

    Gnutella-type models are based on content, not nodes.

    What I mean is some sort of host-less peer-to-peer information service. practically indestructable.

    Is this about some *Cs disallowing certain nodelist entries
    (mainly those notconforming to FTS0005) they claim to do this
    because those "bad" entries cause problems with some systems.

    And why is this a bad thing?

    I dodn't say it was (and I'm not convinced that it is).
    I was asking peter if that was one of his motives.

    This is why I want to transform the nodelist into something that
    can contany any useful information and is fututre proof and easy
    to extend. then the won't have a technical argument against those
    nodes.

    Totally disagree, a technical argument should be the only argument
    used to disallow nodes. If a node is causing problems on the
    network, they should be denied access to the network until they
    fix the problem

    that makes sense... what I mean is whole debate over 000- "phone numbers"
    and other related topics.

    Of course it does. If the node is NOT listed as crash, then its
    the callers fault for attempting to do so when they are not
    supposed to. If I am unable to send mail direct to a node (for
    whatever reason), then I Host Route it via the NC/HUB

    There are HUBS (and NCs and atleast one RC) with no published
    POTS connection.

    I believe that every Host node (and a host node does not have to
    be the NC)

    Yeah the NC just cracks the whip right (if he can convice some other node
    to be host that's fime) as I read the "rules" the NC is "resposible" for
    seing that netmail moves...

    should have a POTS connection and should have the
    capability to get a netmail to any of the nodes in the net.

    yeah, haing nodes in a net that can't get mail from the host would be a problem.

    RCs don't have to route mail to their nets

    They probably should if they have ION region independants...
    (I expect you don't like them either)


    There's a guy in zone 1 called Gregory_Deyss who seems to have found a way
    to tunnel V32 over IP if the nodelist can be believed ;)

    Bye <=-

    ---
    # Origin: Misery loves company, but company does not reciprocat (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to Peter Knapper on Tuesday, July 16, 2002 13:59:12
    Hi Peter.

    15-Jul-02 20:58:58, Peter Knapper wrote to Jasen Betts

    Malcolm Miles has found a solution that looks like it fits the
    bill nicely.

    Yeah it does indeed.

    manually? The nodelist is distributed automatically (it says so
    in P4 so it must be true :)

    If we are using the Internet, why not go and get the info, rather
    than waiting for it to arrive?

    yeah it mahkes sense to me now...

    The nodelist had to be manually distributed when Fidoent was PSTN based, however as it moves to an IP base, we have a chance to make it work
    much better by doing this automatically using the DNS..

    PSTN nodes would still need the weekly nodediff, as would those Iinternat capable nodes using existing software.

    why do you want to cut the off-internet nodes off from the
    nodelist?

    I dont. The Nodelist will still continue for all the PSTN nodes
    left in the network. The Nodelist is not really needed by IP
    Nodes, except when communicating with PSTN nodes. Hhowever even
    that could be handled by a PSTN <> IP Gateway that used some
    intelligence on behalf of the traffic using it

    could PSTN nodes could have DNS entries without having IP addresses
    (I expect malcolm knows the answer to this), that could help.

    nodelist generation for thr use of PSTN nodes still appears to be a problem though.

    doing without it does have its merits. but really withpout the
    nodelist it's not fidonet. (says that in p4 too)

    The reality is that any FTN node can communicate with any other
    FTN node, provided they know how to contact each other (IE phone
    numbers). No Nodelist is actually needed

    Yeah, but if they do are not nodelisted that are not part of fidonet.

    If you must (and my prefernce is to have no such entry at all),
    all you need is a simple indicator against a node number, that a
    specific DNS entry should be the reference point for ALL further
    communication with that node

    it seems that doesn't catually need anything added to the nodelist.
    fidonet.org domain names can be built from the nodes fidonet address.

    We can't add anything to the SLF nodelist it's full already.

    No its not, it had 37,000 entries in it at its peak,

    longer is possible, wider causes problems (reportedly).

    All an ION node entry needs is A PVT listing,

    unless it's a host(etc)... - yucky can of worms that one.

    Remote copy of what? If they are PSTN, then all the info they need
    should be in the Nodelist. If they are IP, then they can use the
    DNS for it

    Yes, thanks, I see that now.

    Bye <=-
    ---
    # Origin: Brain fried -- Core dumped (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to Peter Knapper on Tuesday, July 16, 2002 14:16:15
    Hi Peter.

    15-Jul-02 21:17:38, Peter Knapper wrote to Jasen Betts


    Hi Jasen,

    A new format YES, but as an addition to the current nodelist, NOT
    a replacement

    Why not duplicate the nodelist information in the new file, it
    would make its use easier ...

    Because its not needed.

    true.... I see that now. there's no need to improve the nodelist for
    internet nodes, but a tool to "downgrade" the nodelist so that POTS
    mailers that have problems with some current conventions can make sensible choices when given crashmail for IONs.

    Leave them broken? why?

    The current Nodelist is NOT broken to me.

    you are not all of fidonet...

    I never said I was, however I am a member who has no problems with
    the current Nodelist data, I just understand that it will not
    always work for some.

    And that's valid not motivation to fix it?

    (do you really want me to list my gripes with what is again?)

    Well never having seen your previous comments I have no idea what
    you are talking about. If you are talking about the way people
    have mangled Nodelist entries to do something they wanted and
    "broke" the way the Nodelist works for others, then I am not
    surprised.

    yeah, basically that.

    but I see no way that this plan of yours can benefit users of
    existing software.

    Its not designed to, it is only for IP nodes, the PSTN segment
    always has the nodelist to satisfy their needs

    It won't benefit users of existing ip fido software either.
    but it does seem to be a good addition to fidonet.

    like the nodelist? like echomail routing? you're relying on
    others every day when you use fidonet.

    So minimise the amount you have to repy on them.

    I favour maximising the reliability of the rest of fidonet...
    same goal different strategy.

    One thing a lot of people forget is that just about the entire
    Fidonet Backbone is moved using IP these days. All these IP nodes
    work using something other than Nodelist info. Amazing how they
    manage to do this without using the Nodelist.......;-)

    true, the nodelist sn't used for moving echomail (except in some
    errorchecks)

    And this is not somethoing than cold be implemented overnight.

    Exactly the reason why it needs to be worked out properly and
    agreed with as many Fidonet people as possible, before something
    is started

    what I mean is that intiallly most IP nodes won't support this...
    it'll be a gradual change-over not a sudden one, and there's no way that I
    can for existing IP mailers to send crashmail without using a nodelist
    unless they are modified in some way...

    The nodelist is already in the control for the *C structure, it's
    their main reason for existing (as i read P4), if they kick you
    out of the nodelist a server on ypur PC will do you not good
    whatsoever.

    Something somewhere has to define what makes up Fidonet so others
    can get a feel for what Fidonet really is. The Nodelist is the
    current master list. The Nodelist and the DNS records could be the
    furture master list..

    yeah, that would work.

    If you get kicked out of the Nodelist, then you have exactly the
    same procedures available to rectify that (via a Policy complaint
    to the *C structure)

    The end node then has the ability to manage THEIR membership as
    they wish, OR use a "shared" server

    Is this about some *Cs disallowing certain nodelist entries
    (mainly those notconforming to FTS0005) they claim to do this
    because those "bad" entries cause problems with some systems.

    Nothing like that at all, its just another option for distributing responsibility

    ok... I was wondering what you were trying to achieve with this scheme
    I think I understand it now.

    don't worry about that, it's alreadly lost.

    No it isn't. It just needs putting back on the rails by giving
    those that made the "invalid" changes the option to correct the
    mistakes

    Good luck with trying.

    No. The Mailer uses the Nodelist to perform the action defined by
    the Operator. The decision to Host Route, Network Route, Crash or
    Hold mail, is all with the Sysop. It is up to the Sysops(s) to
    ensure their system has the best chance possible of succeeding

    each time I read that it makes more sense.

    however the present nodelist doesn't evem provide a way fr a

    If I wish to crash a Netmail to someone, and a crash poll fails
    for a reason I can't determine remotely, I then Host Route that
    Netmail. The most likely reason for Crash failing that I have
    found, is because the Nodelist entry is not strictly telling the
    truth for some reason. This is becoming more and more of the real situation these days, which is why I usually Route all my Netmail,
    I don't usually bother to even try Crashing it

    ah.....

    There are HUBS (and NCs and atleast one RC) with no published
    POTS connection.

    Then (IMHO) strictly speaking, it sounds like the *C above them is
    not doing their job, an *C should ALWAYS be PSTN contactable
    somehow to be compliant with P4.

    it does make some sense,
    the argument against it is that it's anacronistic, which also makes sense
    but so is the whole concept of zones nets for IP nodes,

    Requiring Hosts to be POTS capable is unlikely to be a permanent solution unless IP nodes can exist without a host.

    I believe this is most important
    for NC's, and also why it can be a huge bone of contention with
    some people. I also understand that some Zones may view this
    differently

    how's a mailer supposed to know that it's the same destination
    with just a different "name"

    But its not the same destination, its a different node number.

    < text deleted >

    some of them _may_ be one sysop running multiple fido systems but
    most of them appear to me to be the same BBS but with too many
    connections to list on a single nodleist line (either line
    length, flags conflict, or some other cruft is forcing them to
    list multiple times)

    Initial appearances can be very deceptive. A different type of
    modem may require different flags to be shown, or hours of service
    for different reasons.

    yes I understand many of the reasons. In my opinion it would be good if
    they could put all that in a single nodelist entry... obviously doing that without losing functionality would require major changes to the nodelist format.

    I'm aware of 1900 others.

    Have you considered that you may be too picky over other peoples
    reasons for doing this?

    I'm not saying they shouldn do it, I'm saying to could be done better.
    with a bnew nodelist format.

    As I described above, and they are being used like that.

    The main problem I see with multi-listed systems is the mailer being able to recognise it as multi-listed and pick the most appropriate node so send the mail to.

    Bye <=-
    ---
    # Origin: Sturgeon's Law: 90% of everything is crud. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to Frank Vest on Tuesday, July 16, 2002 15:27:39
    Hi Frank.

    I'm not against change if:

    1. It will do some good. 2. There is software to support the new
    format. 3. There is a way to support the old software currently in
    use.

    yeah, I'm in favor of all that too.

    Bye <=-
    ---
    # Origin: Xerox does it again and again and again and ... (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to Frank Vest on Thursday, July 18, 2002 01:27:20
    Hi Frank.

    15-Jul-02 18:49:52, Frank Vest wrote to Malcolm Miles


    On (15 Jul 02) Malcolm Miles wrote to Frank Vest...

    Hello Malcolm,

    True, but those originate from the Internet. As I described, the spam would originate from a Fidonet Node in the Fidonet Nodelist operating Fidonet mailer and no way to stop them since they added their own
    Nodes listing to the Fidonet Nodelist. Yes, the *C could remove the listing, but the Node just adds it back in.... and the battle rages.
    "It's out!"
    "It's in!!"
    "It's OUT!!!"
    "It's IN!!!!!"


    Only give the *C authority to add/remove entries, let the node modify their entry but not add new ones.

    Bye <=-

    ---
    # Origin: Tomorrow will be canceled due to lack of interest. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Frank Vest on Wednesday, July 17, 2002 19:13:36
    "spam bots" could be made to "harvest" Node addresses for spam
    purposes. In reality, harvesting would not be needed. Just grab a
    copy of the Nodelist, add yourself into it and spam away. :(
    It is happening already. I throw away hundreds of Fidonet-
    addressed spam daily at my Internet gateway.

    True, but those originate from the Internet. As I described,
    the spam would originate from a Fidonet Node in the Fidonet
    Nodelist operating Fidonet mailer and no way to stop them
    since they added their own Nodes listing to the Fidonet
    Nodelist. Yes, the *C could remove the listing, but the Node
    just adds it back in.... and the battle rages.

    there would be a lock mechanism... has to be... and the
    "controlling commitee" (if you will) would have that
    capability...

    In the Internet world, the control is in large part by the
    ISP and you pay the ISP for access. Fidonet has no such t
    hing... therefore, there would be no controlling committee

    wanna bet? if the WWB can design and implement an ELIST type service that is controlled by a committee of its members, then i know that there can also be a committee of nodes that can control this "automatic node list"... for that matter, don't even go that far... it would be incumbent on the *C that assigned

    the new node a number to make the update...

    except the *Cs and they would have little power with a
    Nodelist that is open to addition by anyone. My biggest
    fear for Fidonet is that it will be opened up to the
    point that anyone can just add themselves into Fidonet
    without any questions asked.

    the internet is already like that...

    If Fidonet is not careful, it could become a place that is
    little different from the Internet is regards to spam. Much
    like the spammers, a person could jump from Node number to
    Node number. Having the ability for "anyone off the street"
    to add themselves into the Fidonet nodelist is not a good
    thing for Fidonet.

    they can do that, already! have been able to for many many many years...

    Anyway, this is getting off the topic of a Nodelist format.
    :-)

    true...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Neil Walker on Wednesday, July 17, 2002 19:21:30
    Besides, I've yet to come across a program that
    amkes any use of that field in the nodelist other
    than to simply display it. ;-) It's more for human
    readability than anything else.

    my FrontDoor sure makes use of it... i've settings
    to call systems with speeds above and below certain
    thresholds... i can even set up certain modem inits
    based on the speed field, if i need to...

    Considering the nodelist can only contain speeds up to 9600

    where do you get that "can only contain" from?? FTS-0005 states differently... and FTS-5000 also states differently... and we won't even go into the reasons why MAKENL has a specific verb allowing for additional connect speeds to be allowed...

    (yes, I know Zone 1 does it's own thing ;-) ),

    i just named three reasons why that's not totally true...

    the other modem flags are far more useful for that.

    that's all fine and good... however, if i never want to directly contact a system that can only do 9600, then i can block that or whatever...

    I also need to seperate calls according to the receivers
    capability (ISDN, V34, V32, etc.) and I do it with those
    flags.

    show me which of those flags is the one that indicates 9600? i, too, can make adjustments based on the flags...

    my POINT in this was to prove to you that the SPEED field ~is~ useful and not there just for human convienience...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From Neil Walker@1:218/903 to mark lewis on Thursday, July 18, 2002 04:12:55
    Hello mark!

    Wednesday July 17 2002 17:21, you wrote to me:

    Considering the nodelist can only contain speeds up to 9600

    where do you get that "can only contain" from??

    Dunno. ;-) Clearly, I was mistaken.

    Looking through the current nodelist suggests that the maority of nodes have made the same mistake as I did. Try counting the number of entries with "9600" but also with flags indicating higher capabilities. I wonder how this came about?

    the other modem flags are far more useful for that.

    that's all fine and good... however, if i never want to directly
    contact a system that can only do 9600, then i can block that or whatever...

    Not very reliable considering the above. ;-)

    I also need to seperate calls according to the receivers
    capability (ISDN, V34, V32, etc.) and I do it with those
    flags.

    show me which of those flags is the one that indicates 9600?

    V32.

    my POINT in this was to prove to you that the SPEED field ~is~ useful
    and not there just for human convienience...

    It's not very useful if most nodes have it wrong. :-(


    Be lucky,

    Neil

    This OS/2 system uptime is 2 days 23:26 hours and 07 seconds

    ... You have the capacity to learn from mistakes. You'll learn a lot today.
    --- GoldED/2 3.0.1
    # Origin: The Electric Pigeon, Telford, UK (2:250/501)
    * Origin: Baddog BBS (1:218/903)
  • From Malcolm Miles@1:218/903 to Jasen Betts on Thursday, July 18, 2002 15:31:55
    On Jul 16, 2002 Jasen Betts wrote to Peter Knapper:

    Requiring Hosts to be POTS capable is unlikely to be a permanent
    solution unless IP nodes can exist without a host.

    Why not? The PSTN system is not going to go away in the future. Requiring a host node to have a phone line that can receive calls at ZMH is not an onerous requirement. If all nodes in a net are IP-capable then the net can be quite large so fewer hosts in a region/zone would be required than today.

    The main problem I see with multi-listed systems is the mailer being
    able to recognise it as multi-listed and pick the most appropriate
    node so send the mail to.

    It is not the mailer's responsibility to determine which node a message should be sent to. It is the mailer's responsibility to select the most appropriate transport mechanism to use to send a message to a particular node.

    Best wishes,
    Malcolm

    --- timEd/386 1.10.y2k+
    # Origin: Tardis BBS +61 3 9819 7093 (3:633/260)
    * Origin: Baddog BBS (1:218/903)
  • From Malcolm Miles@1:218/903 to Jasen Betts on Thursday, July 18, 2002 15:47:46
    On Jul 16, 2002 Jasen Betts wrote to Peter Knapper:

    Malcolm Miles has found a solution that looks like it fits the
    bill nicely.

    Yeah it does indeed.

    Now all we have to do is find some developers that will include the proposal in

    their product. There is virtually zero development being done on Fidonet software except for some in Russia. I am sure that the Russian developers don't

    read this echo.

    PSTN nodes would still need the weekly nodediff, as would those
    Iinternat capable nodes using existing software.

    All nodes would still need the nodelist as it defines who belongs to Fidonet. Sysop details, location, status (down, hold) would only be included in the nodelist.

    could PSTN nodes could have DNS entries without having IP addresses
    (I expect malcolm knows the answer to this), that could help.

    Doesn't make any sense. The DNS is a mechanism for converting names to IP addresses. No IP address, no need for a DNS entry.

    Best wishes,
    Malcolm

    --- timEd/386 1.10.y2k+
    # Origin: Tardis BBS +61 3 9819 7093 (3:633/260)
    * Origin: Baddog BBS (1:218/903)
  • From Frank Vest@1:218/903 to Jasen Betts on Thursday, July 18, 2002 03:06:46
    On (17 Jul 02) Jasen Betts wrote to Frank Vest...

    Hello Jasen,

    True, but those originate from the Internet. As I described, the spam would originate from a Fidonet Node in the Fidonet Nodelist operating Fidonet mailer and no way to stop them since they added their own
    Nodes listing to the Fidonet Nodelist. Yes, the *C could remove the listing, but the Node just adds it back in.... and the battle rages.
    "It's out!"
    "It's in!!"
    "It's OUT!!!"
    "It's IN!!!!!"

    Only give the *C authority to add/remove entries, let the node modify their entry but not add new ones.

    Ok. If that can be done.

    Regards,

    Frank

    http://pages.sbcglobal.net/flv
    http://biseonline.com/r19

    --- PPoint 3.01
    # Origin: Holy Cow! I'm A Point!! (1:124/6308.1)
    * Origin: Baddog BBS (1:218/903)
  • From Peter Knapper@1:218/903 to Malcolm Miles on Friday, July 19, 2002 00:29:16
    Hi Malcolm,

    could PSTN nodes could have DNS entries without having IP addresses
    (I expect malcolm knows the answer to this), that could help.

    Doesn't make any sense. The DNS is a mechanism for
    converting names to IP addresses. No IP address, no need for a DNS entry.

    It could make sense if it could be used by IP only nodes to find an IP ==> PSTN

    Gateway to reach the target PSTN node. This takes the "conversion" point closer

    to the target system, rather than just assuming it will be handled by a "Default Fidonet Master Gateway" somewhere. One thing I havbe always liked about Fidonet is the ability for Node to Node communciatins whenever it is physically possible. Splitting ourselves between PSTN and IP will start to break that ability, however if we can keep the option available wherever possible, then it would help to convince people the changes are not as great as

    they might think.

    Cheers............pk.


    --- Maximus/2 3.01
    # Origin: Another Good Point About OS/2 (3:772/1.10)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to mark lewis on Friday, July 19, 2002 10:36:51
    Hi Mark.

    17-Jul-02 17:21:30, mark lewis wrote to Neil Walker


    show me which of those flags is the one that indicates 9600? i,
    too, can make adjustments based on the flags..

    the following flags mean 9600 or faster

    ;S V29 CCITT V.29 9600 bps half duplex
    ;S V32 CCITT V.32 9600 bps full duplex
    ;S V32b ITU-T V.32 bis 14400 bps full duplex
    ;S V32T V.32 Terbo
    ;S VFC V.Fast Class
    ;S V90C ITU-T V.90 modem Client
    ;S V90S ITU-T V.90 Server.

    ;S HST USR Courier HST
    ;S H14 USR Courier HST 14.4
    ;S H16 USR Courier HST 16.8

    ;S H96 Hayes V9600

    ;S CSP Compucom Speedmodem

    ;S ZYX Zyxel series
    ;S Z19 Zyxel 19,200 modem protocol

    ;S X2C US Robotics x2 client.
    ;S X2S US Robotics x2 server.

    ;S MAX Microcom AX/96xx series

    dunno which ones your hardware is compatible with though.


    Bye <=-

    ---
    # Origin: Pro is to con as progress is to Congress. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to Malcolm Miles on Friday, July 19, 2002 12:19:39
    Hi Malcolm.

    18-Jul-02 13:47:46, Malcolm Miles wrote to Jasen Betts


    On Jul 16, 2002 Jasen Betts wrote to Peter Knapper:

    Malcolm Miles has found a solution that looks like it fits the
    bill nicely.

    Yeah it does indeed.

    Now all we have to do is find some developers that will include
    the proposal in their product. There is virtually zero development
    being done on Fidonet software except for some in Russia. I am
    sure that the Russian developers don't read this echo

    It'll be a few months atleast before Im in any position to develop IP
    capable fido software (no internet connection here yet so I'd just be
    testing on a lan...)

    PSTN nodes would still need the weekly nodediff, as would those
    Iinternat capable nodes using existing software.

    All nodes would still need the nodelist as it defines who belongs
    to Fidonet. Sysop details, location, status (down, hold) would
    only be included in the nodelist

    nah noded using existing software still need all the info they needed
    yesterday and if they don't know how to get it from a DNS they'll need
    to get it from the nodelist... after a while most nodes will probably
    upgrade their software... but when?

    Bye <=-

    ---
    # Origin: Know thyself. If you need help, call the C.I.A. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to Malcolm Miles on Friday, July 19, 2002 12:23:55
    Hi Malcolm.

    18-Jul-02 13:31:55, Malcolm Miles wrote to Jasen Betts


    On Jul 16, 2002 Jasen Betts wrote to Peter Knapper:

    Requiring Hosts to be POTS capable is unlikely to be a permanent
    solution unless IP nodes can exist without a host.

    Why not? The PSTN system is not going to go away in the future.

    it;s already gone. making rules in this echo won't force the existing
    IP-only or uncontactable zone 1 hosts to install phone lines and modems.

    Requiring a host node to have a phone line that can receive calls
    at ZMH is not an onerous requirement. If all nodes in a net are
    IP-capable then the net can be quite large so fewer hosts in a
    region/zone would be required than today

    yeah, that requires reorganisation and loss of political power and the Z1 people take the politics seriously - what else can explain their two
    echomail distribution systems.

    The main problem I see with multi-listed systems is the mailer
    being able to recognise it as multi-listed and pick the most
    appropriate node so send the mail to.

    It is not the mailer's responsibility to determine which node a
    message should be sent to. It is the mailer's responsibility to
    select the most appropriate transport mechanism to use to send a
    message to a particular node

    yeah, what's a node if the same system is in the nodelist three times with three different phone numbers (maybe with different brands of modem) but
    all attached to the same messagebase is it one node or three?

    Bye <=-

    ---
    # Origin: Computer programmers do it byte by byte (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Frank Vest@1:218/903 to Jasen Betts on Saturday, July 20, 2002 03:36:46
    On (19 Jul 02) Jasen Betts wrote to Frank Vest...

    Hello Jasen,

    Here I've grouped all the flags for each connection into a
    single JB>> field and put the modem speed in there too.
    That would work. Like I said, the format of the new list is not a
    problem and is expandable. The old list is generated from the new list
    and has no way to be wrong...
    depends what you mean by "wrong"... a certain zone 1 sysop who I meantioned earlier has some ususual ideas about what comprises a valid nodelist entry.

    Well... My thought was that since the person operating the conversion
    program decides which fields to put in what order in the old style
    list, it would be hard to make the old style list incorrect (wrong).

    Since the new style list will have fields that aren't allowed in the
    old style list, and the new list will have all the information for
    both POTS and IP, the conversion would be in the proper format for the
    old style. Kinda like:

    New style:
    -2- -3- -4- -5- -6- -7- -8- ,6308,192.168.0.1,McKinney_TX,Frank_Vest,IBN_FTP,CM,Collin_County_Station
    -9- -10- -11-
    ,1-972-562-8064,33600,XA_V42

    Old style:
    -2- -8- -4- -5- -9- -10- ,6308,Collin_County_Station,McKinney_TX,Frank_Vest,1-972-562-8064,33600
    -7- -11- -6-
    ,CM,XA,V42,IBN,FTP

    The translation software would make the old style list and take only
    what is required for that list from the new style. No matter what the
    Node put in the new style, the old style would almost certianly be
    correct... I think.

    Of course, nothing is fool proof. :-))

    if the conversion program is done right.
    The new list could have a flag at position 11 that indicated the type
    of connection.. IE: ION for Internet only - no POTS. IPN for Internet
    and POTS. Then the other flags could tell what "protocol" is available
    at that Node. IE: IBN for binkp and so on.
    no. that's not what I mean at all. one connectio-type flag per
    connection. if they're posts only they start with a pots
    connection-type flag and omit the IP flag, if they're IP only then
    they omit the POTS connection.

    ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
    IP,IP.or.url.com,CM_MO_LO_IBN_ITN,
    POTS,<phone number or unlisted>,33600_V34_V42b_CM_XA

    ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
    POTS,<phone number or unlisted>,33600_V34_V42b_CM_XA

    ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
    IP,IP.or.url.com,CM_MO_LO_IBN_ITN,

    Ah ha! I think I see what you mean. The new style list would have two
    or three lines for each Node. The first line would always be the
    "basic" Node information. The next line(s) would depend on the type of connection capabilities and be designated by either the POTS or IP
    flag, or both, as needed? If I got this thought my thick head right?

    This would work just fine with me... Probably be easier to read and
    translate to boot.

    the fact that you can't fit all the information from this into a
    regular nodelist isn't a problem. users of the conversion software
    would set up some rules about which connection types they prefer and
    the software would examine the fileds and spit out a SLF nodeline with
    the most suitable
    connection type listed (or possibly PVT etc if nothing was suitable)

    I was thinking that the *Cs would be the ones running the conversion
    program to generate the old style list for distribution along with the
    new list... IE:

    New Style List = nodeip.*
    Old Style from conversion program = nodelist.* (just as always).

    I think that with the old nodelist being generated from the new list, there will be a lot of problems solved. :-)
    yeah. but not all of them. uncontactable hubs and some other strange
    zone 1 inventions won't be deterred by a new nodelist and will come
    out of the converter just as bogus .... unless we put some
    tricks in the converter (like replacing connection info of the bogus
    hub with that of their netmail feed, (or that of a local, or global,
    IP gateway)

    Remember, Nothing is fool proof because fools are so ingenious. :-))

    Actually, you are right. There will still be some problems, but it
    might be easier to deal with those problems... I dunno.


    Regards,

    Frank

    http://pages.sbcglobal.net/flv
    http://biseonline.com/r19

    --- PPoint 3.01
    # Origin: Holy Cow! I'm A Point!! (1:124/6308.1)
    * Origin: Baddog BBS (1:218/903)
  • From Frank Vest@1:218/903 to Jasen Betts on Saturday, July 20, 2002 04:16:17
    On (19 Jul 02) Jasen Betts wrote to Malcolm Miles...

    Hello Jasen,


    Requiring Hosts to be POTS capable is unlikely to be a permanent
    solution unless IP nodes can exist without a host.
    Why not? The PSTN system is not going to go away in the future.
    it;s already gone. making rules in this echo won't force the existing IP-only or uncontactable zone 1 hosts to install phone lines and
    modems.

    No comment on this. :-)

    Requiring a host node to have a phone line that can receive calls
    at ZMH is not an onerous requirement. If all nodes in a net are
    IP-capable then the net can be quite large so fewer hosts in a
    region/zone would be required than today
    yeah, that requires reorganisation and loss of political power and the
    Z1 people take the politics seriously - what else can explain their
    two echomail distribution systems.

    Umm... at least four:

    backbone.na
    backbone.z1b
    backbone.pa
    fidospine

    Insanity, IMNSHO. :( But, this is not the echo to discuss this
    subject and I'm a little different than most in Z1. :)


    Frank - in Zone 1

    http://pages.sbcglobal.net/flv
    http://biseonline.com/r19

    --- PPoint 3.01
    # Origin: Holy Cow! I'm A Point!! (1:124/6308.1)
    * Origin: Baddog BBS (1:218/903)
  • From Johannes Lundberg@1:218/903 to mark lewis on Saturday, July 20, 2002 17:01:31
    that will likely remain as many are on dialup connections and unless fidonet also sets up a ddns, there's few ways for one to have a static domain name for a dynamic dialup...

    You can point your fidonet.net (or whatever) to your selected DynDNS-provider with a CNAME. All DNS-resolvers follow CNAMEs until they find an A-record, so dynamic IPs and dialups is not a problem, if you don't mind using existing DynDNS-providers.


    * Origin: ... (2:206/149.13)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to Frank Vest on Sunday, July 21, 2002 09:58:10
    Hi Frank.

    20-Jul-02 01:36:46, Frank Vest wrote to Jasen Betts
    The translation software would make the old style list and take only
    what is required for that list from the new style. No matter what the
    Node put in the new style, the old style would almost certianly be correct... I think.

    Maybe syntatically correct... there'd still be uncontactable hosts, etc,
    so it wouldn't be functionally correct.

    Of course, nothing is fool proof. :-))

    Ah ha! I think I see what you mean. The new style list would have two
    or three lines for each Node

    nah, one line, I just split them that way for easier reading. (I should
    have said) the POTS section has the same number of commas as the IP section
    or any other type or connection, so if old(future) sofrware finds something
    it doesn't understand it knows to just skip 3 commas and there'll be another
    connection to look at (or a new line with a new node).

    . The first line would always be the
    "basic" Node information. The next line(s) would depend on the type of connection capabilities and be designated by either the POTS or IP
    flag, or both, as needed? If I got this thought my thick head right?

    Pretty much, but also ISDN atleast where where it's incompatible with POTS
    PACNet too if it's still running, even packet radio if someone's got X25
    fido software and there's no rules against it...

    This would work just fine with me... Probably be easier to read and translate to boot.

    I hadn't thought of that but, having a reminder (int the form of connection-type keyword) every three fields would reduce the "forest of
    commas" problem

    I was thinking that the *Cs would be the ones running the conversion program to generate the old style list for distribution along with the
    new list... IE:

    they could but the node in their net may be sing different software and therfore want different information in their nodelist.

    those with IP nodes would want IP numbers, those with modems would want
    phone numbers, those with a different brand of modem might want a different phone number etc...

    And for each of these nodes the NC has to keep a current nodelist and then build a new one, compare the two and then produce a diff.

    the NC would could end up with 10 copies of the nodelist produced with different options turned on or off sitting on his hard disk taking up
    space.

    If the new nodelist could be produced with correnspnding line numbers
    holding the same information as the old nodelist that could help, (then the nodediff could jut be translated for each different node) I'm not sure how practical that would be. (personally I don't like that idea because it would put restrictions on the new nodelist)

    possibly a nodediff translater could be made that would work without an existing old nodelist (just using the week-old new nodelist and the new nodediff) it'd be an interesting challenge... especially a multi-headed
    version that could produce multiple old nodediffs simultaneously....

    New Style List = nodeip.*
    Old Style from conversion program = nodelist.* (just as always).

    yeah. but not all of them. uncontactable hubs and some other strange
    zone 1 inventions won't be deterred by a new nodelist and will come
    out of the converter just as bogus ....

    Remember, Nothing is fool proof because fools are so ingenious. :-))

    yeah, you've got a point there....

    Actually, you are right. There will still be some problems, but it
    might be easier to deal with those problems... I dunno.

    It'll help I expect.

    Bye <=-

    ---
    # Origin: To err is human - two curs canine. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Frank Vest@1:218/903 to Jasen Betts on Sunday, July 21, 2002 20:48:07
    On (21 Jul 02) Jasen Betts wrote to Frank Vest...

    Hello Jasen,

    The translation software would make the old style list and take only
    what is required for that list from the new style. No matter what the
    Node put in the new style, the old style would almost certianly be correct... I think.
    Maybe syntatically correct... there'd still be uncontactable hosts,
    etc, so it wouldn't be functionally correct.

    That will happen anyway. Until humans can be made perfect, there will
    be errors and uncontactable Nodes. :-)

    Ah ha! I think I see what you mean. The new style list would have two
    or three lines for each Node
    nah, one line, I just split them that way for easier reading. (I
    should have said) the POTS section has the same number of commas as
    the IP section or any other type or connection, so if old(future) sofrware finds something it doesn't understand it knows to just skip
    3 commas and there'll be another connection to look at (or a new line with a new node).

    Oh. Ok. I see. Still, I can see a good thing in having "tags" for each
    section and having them in a separate line.

    . The first line would always be the
    "basic" Node information. The next line(s) would depend on the type of connection capabilities and be designated by either the POTS or IP
    flag, or both, as needed? If I got this thought my thick head right?
    Pretty much, but also ISDN atleast where where it's incompatible with POTS PACNet too if it's still running, even packet radio if someone's
    got X25 fido software and there's no rules against it...

    That would be the "good" in having separate lines for each tag. The
    ability to list different types of connection types and such.

    This would work just fine with me... Probably be easier to read and translate to boot.
    I hadn't thought of that but, having a reminder (int the form of connection-type keyword) every three fields would reduce the "forest
    of commas" problem

    Probably. I'm not sure I'm technical enough to get int this area.

    I was thinking that the *Cs would be the ones running the conversion program to generate the old style list for distribution along with the
    new list... IE:
    they could but the node in their net may be sing different software
    and therfore want different information in their nodelist.

    Well... I assumed that both Nodelist formats would be distributed and
    that the conversion program would be available for Nodes to use if
    desired. A Node that wanted different information in a Nodelist could
    simply use the new format and convert it to their liking. :-)

    those with IP nodes would want IP numbers, those with modems would
    want phone numbers, those with a different brand of modem might want a different phone number etc...

    And for each of these nodes the NC has to keep a current nodelist and
    then build a new one, compare the two and then produce a diff.

    See above. :-)


    Regards,

    Frank

    http://pages.sbcglobal.net/flv
    http://biseonline.com/r19

    --- PPoint 3.01
    # Origin: Holy Cow! I'm A Point!! (1:124/6308.1)
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Malcolm Miles on Tuesday, July 23, 2002 00:04:02
    Doesn't make any sense. The DNS is a mechanism for converting
    names to IP addresses. No IP address, no need for a DNS entry.

    unless we did something like the older software used to do for host routed stuff and put in the *C's or the bossnode's phone number in place of the system's number... if systems were able to be designated as gateway systems, something maybe similar to zonegates, then one could have the DNS convert the domain name to the IP of the (zone)gate system and drop off the mail there for further processing...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Jasen Betts on Tuesday, July 23, 2002 00:59:58
    show me which of those flags is the one that indicates 9600? i,
    too, can make adjustments based on the flags..

    the following flags mean 9600 or faster

    yup... but...

    ;S V29 CCITT V.29 9600 bps half duplex
    ;S V32 CCITT V.32 9600 bps full duplex
    ;S V32b ITU-T V.32 bis 14400 bps full duplex
    ;S V32T V.32 Terbo
    ;S VFC V.Fast Class
    ;S V90C ITU-T V.90 modem Client
    ;S V90S ITU-T V.90 Server.

    ;S HST USR Courier HST
    ;S H14 USR Courier HST 14.4
    ;S H16 USR Courier HST 16.8

    these cannot talk to...

    ;S H96 Hayes V9600

    ;S CSP Compucom Speedmodem

    this at 9600...

    ;S ZYX Zyxel series
    ;S Z19 Zyxel 19,200 modem protocol

    and this one won't talk to either of those at 9600...

    ;S X2C US Robotics x2 client.
    ;S X2S US Robotics x2 server.

    ;S MAX Microcom AX/96xx series

    dunno which ones your hardware is compatible with though.

    that's why all the flags are necessary (in answer to someone else's query some messages back)...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Jasen Betts on Tuesday, July 23, 2002 01:28:40
    nah noded using existing software still need all the
    info they needed yesterday and if they don't know
    how to get it from a DNS they'll need to get it from
    the nodelist... after a while most nodes will probably
    upgrade their software... but when?

    i can't see a commodore64 on the net doing these lookups... there are still some in existance and active as full nodes... at least to my knowledge, anyway...

    heck, i'm sure there are also trs-80s still out there as well as amigas and other non-PC (PC == personal computer) systems...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Jasen Betts on Tuesday, July 23, 2002 01:35:20
    Requiring a host node to have a phone line that can
    receive calls at ZMH is not an onerous requirement.
    If all nodes in a net are IP-capable then the net can
    be quite large so fewer hosts in a region/zone would
    be required than today

    yeah, that requires reorganisation and loss of political
    power and the Z1 people take the politics seriously -
    what else can explain their two echomail distribution
    systems.

    two?!!? i can count no less than 5... only two "at the top" though... then again, those "top two" are linked by a "bridge node"... seems to me that they may unknowingly be part of yetanother distribution system <<GG>>

    [trim]

    It is not the mailer's responsibility to determine
    which node a message should be sent to. It is the
    mailer's responsibility to select the most appropriate
    transport mechanism to use to send a message to a
    particular node

    yeah, what's a node if the same system is in the
    nodelist three times with three different phone
    numbers (maybe with different brands of modem) but
    all attached to the same messagebase is it one node
    or three?

    a messagebase does NOT a node make... remember, fidonet does not require a bbs,

    message bases or files areas for one to be a node... contrary to popular belief

    or what P4 may happen to state WRT bbs'... it only takes two (three for active participation) things to be a full node in fidonet...

    1. a mailer
    2. a message tosser
    3. an editor/reader for local use (optional)

    PKTs used to be read/treated like QWK mail... in fact, other than the format and access method, there is little difference between them...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Frank Vest on Tuesday, July 23, 2002 01:40:38
    Well... My thought was that since the person operating the
    conversion program decides which fields to put in what
    order in the old style list, it would be hard to make the
    old style list incorrect (wrong).

    that's an incorrent assumption to start with...

    [trim]

    Of course, nothing is fool proof. :-))

    of course... there's always a "better" fool... that's why it is the developers who will determine the format and the conversion rules...

    [trim]

    Ah ha! I think I see what you mean. The new style list
    would have two or three lines for each Node. The first
    line would always be the "basic" Node information. The
    next line(s) would depend on the type of connection
    capabilities and be designated by either the POTS or IP
    flag, or both, as needed? If I got this thought my
    thick head right?

    hummm... that's sounding like my 2nd proposal...

    [trim]

    I was thinking that the *Cs would be the ones running
    the conversion program to generate the old style list
    for distribution along with the new list... IE:

    no need for the *Cs to be involved in the conversion process at all... only those with machines incapable of executing the conversion software would need _someone_ to convert the new list to the old list for them...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Johannes Lundberg on Tuesday, July 23, 2002 01:44:02
    that will likely remain as many are on dialup connections
    and unless fidonet also sets up a ddns, there's few ways
    for one to have a static domain name for a dynamic dialup...

    You can point your fidonet.net (or whatever) to your selected DynDNS-provider with a CNAME. All DNS-resolvers follow CNAMEs
    until they find an A-record, so dynamic IPs and dialups is not
    a problem, if you don't mind using existing DynDNS-providers.

    true... very true... until you run into some system that insists on IP number instead of domain name... i'm thinking of a situation where one wants to go the

    other way...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From Frank Vest@1:218/903 to mark lewis on Tuesday, July 23, 2002 07:29:19
    On (22 Jul 02) mark lewis wrote to Frank Vest...

    Hello mark,


    Ah ha! I think I see what you mean. The new style list
    would have two or three lines for each Node. The first
    line would always be the "basic" Node information. The
    next line(s) would depend on the type of connection
    capabilities and be designated by either the POTS or IP
    flag, or both, as needed? If I got this thought my
    thick head right?

    hummm... that's sounding like my 2nd proposal...

    Yes. Once it soaked through my thick head, it makes sense. :-)

    I was thinking that the *Cs would be the ones running
    the conversion program to generate the old style list
    for distribution along with the new list... IE:
    no need for the *Cs to be involved in the conversion process at all... only those with machines incapable of executing the conversion
    software would need _someone_ to convert the new list to the old list
    for them...

    True. However, the *Cs will most likely be the ones doing this job. I
    don't see a lot of individual Nodes running software to convert the
    new format to the old one. In such an case, if the *Cs don't do the
    conversion and distribute the old style list, I see a lot of Nodes
    packing up and saying "Forget this. I'm not messing with some other
    software just to make you @#$s happy!".

    :-(


    Regards,

    Frank

    http://pages.sbcglobal.net/flv
    http://biseonline.com/r19

    --- PPoint 3.01
    # Origin: Holy Cow! I'm A Point!! (1:124/6308.1)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to mark lewis on Wednesday, July 24, 2002 15:43:09
    Hi mark.

    22-Jul-02 23:28:40, mark lewis wrote to Jasen Betts


    nah noded using existing software still need all the info they
    needed yesterday and if they don't know how to get it from a DNS
    they'll need to get it from the nodelist... after a while most
    nodes will probably upgrade their software... but when?

    i can't see a commodore64 on the net doing these lookups... there
    are still some in existance and active as full nodes... at least
    to my knowledge, anyway..

    C=64 IP nodes ? I was meaning that the IP data nas to me maintained in the nodelist for the benefitt of existing IP mailers

    heck, i'm sure there are also trs-80s still out there as well as
    amigas and other non-PC (PC == personal computer) systems..

    I think you mean PC="IBM-PC compatible", an TRS-80s, Amigas, Macs etc are personal computers.

    Bye <=-
    ---
    # Origin: Today is the first day of the rest of the mess (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to mark lewis on Wednesday, July 24, 2002 15:48:27
    Hi mark.

    22-Jul-02 23:35:20, mark lewis wrote to Jasen Betts

    what's a node if the same system is in the nodelist three
    times with three different phone numbers (maybe with different
    brands of modem) but all attached to the same messagebase is it
    one node or three?

    a messagebase does NOT a node make...

    true, do you intend to answer the question? I'll rephrase it in more
    general language, if three SLF nodelist lines are functionally equivalent
    as far as the handling of mail, FREQs etc sent to them but inly differ in
    their conection mechanisms (mailer type, transport mendiam, etc) are they three nodes ot is it one?

    Bye <=-

    ---
    # Origin: Love is sentimental measles. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to mark lewis on Wednesday, July 24, 2002 16:01:09
    no need for the *Cs to be involved in the conversion process at
    all... only those with machines incapable of executing the
    conversion software would need _someone_ to convert the new list
    to the old list for them..

    P4 says the *C are responsible for providing the nodelist si I Envisage intially a rather general conversion being done by them, but yeah,
    it could be converted on someone elses computer, they needn't even be a
    fidonet member.


    Bye <=-

    ---
    # Origin: Every man is as God mand him, ay, and often worse. (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Jasen Betts on Wednesday, July 24, 2002 19:01:50
    what's a node if the same system is in the nodelist three
    times with three different phone numbers (maybe with different
    brands of modem) but all attached to the same messagebase is it
    one node or three?

    a messagebase does NOT a node make...

    true, do you intend to answer the question? I'll rephrase it
    in more general language, if three SLF nodelist lines are
    functionally equivalent as far as the handling of mail, FREQs
    etc sent to them but inly differ in their conection mechanisms
    (mailer type, transport mendiam, etc) are they three nodes ot
    is it one?

    i would have to say yes, whether it is one machine or more than one that is actually processing the data behind the connection type... i'm thinking of a network where one machine is doing POTS and another doing IP and they both drop

    their inbounds into a central directory and maybe a third machine processes it all...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From Edward Hevlund@1:218/903 to Frank Vest on Sunday, August 04, 2002 03:27:35
    On a technical basis, Fidonet should operate as follows.... One Zone
    and one Net. When that Net becomes full, start another Net. Fill

    Didn't you just say "one zone and one net"?

    I've got a better idea: 64bit integers.

    Your net numbers will _never_ run out, unless air particles themselves start getting IP addresses.


    --- JEdPoint
    # Origin: Redneck: You've vacationed in a rest area (2:200/486.4)
    * Origin: Baddog BBS (1:218/903)
  • From Frank Vest@1:218/903 to Edward Hevlund on Friday, August 09, 2002 00:23:25
    On (04 Aug 02) Edward Hevlund wrote to Frank Vest...

    Hello Edward,


    On a technical basis, Fidonet should operate as follows.... One Zone
    and one Net. When that Net becomes full, start another Net. Fill

    Didn't you just say "one zone and one net"?

    I've got a better idea: 64bit integers.

    Your net numbers will _never_ run out, unless air particles themselves start getting IP addresses.

    True, but not within Fidonet specs... I think.


    Regards,

    Frank

    http://pages.sbcglobal.net/flv
    http://biseonline.com/r19

    --- PPoint 3.01
    # Origin: Holy Cow! I'm A Point!! (1:124/6308.1)
    * Origin: Baddog BBS (1:218/903)
  • From mark lewis@1:218/903 to Frank Vest on Friday, August 09, 2002 14:34:50
    On a technical basis, Fidonet should operate as
    follows.... One Zone and one Net. When that Net
    becomes full, start another Net. Fill

    Didn't you just say "one zone and one net"?

    I've got a better idea: 64bit integers.

    Your net numbers will _never_ run out, unless
    air particles themselves start getting IP
    addresses.

    True, but not within Fidonet specs... I think.

    you forgot the word "current" in there... "current fidonet specs"... in the beginning, fidonet addressing was "flat"... then, as it grew, they went to net/node addressing... in don't know if regions or zones came next but regional

    addressing was never instituted... and also, at some point in there, point addresses were created and maintained by a "central authority"... this also led

    to pointnets where a point system had a node number just like a normal fullnode

    but the net address was greater than 32000 (IIRC)... a pointnet was assigned to

    a specific node and thus conversion was easy to go to zone:net/node.point...

    ie: if pointnet 45678 was assigned to 1:3634/12
    1:45678/42 == 1:3634/12.42

    pointnet addresses were not allowed to appear on the outside of the pointnet...

    the above was a form of zonegating... i guess it would more accurately be called netgating <<GG>>

    there have been a lot of changes over the years... i remember my first multinode bbs setup... i configured each node as a seperate point address, thus, if you saw mail from blah:blah/blah.1, you knew it was from node 1, mail from blah:blah/blah.45 was from node 45... since that software was limited to 255 nodes, my methods caused me to list point systems starting at 300... at one

    time, i was managing/hosting some 150 point systems and something like 40 or 50

    nodes on the bbs...

    )\/(ark


    * Origin: (1:3634/12)
    --- SBBSecho/Win32 v2.00
    * Origin: Baddog BBS (1:218/903)
  • From Jasen Betts@1:218/903 to mark lewis on Friday, July 26, 2002 11:23:39
    Hi mark.

    24-Jul-02 17:01:50, mark lewis wrote to Jasen Betts

    are they three nodes ot is it one?

    i would have to say yes,

    yes=3 or yes=1 ? or yes="that's an unfair question"

    Bye <=-

    ---
    # Origin: BLISS is ignorance (3:640/531.42)
    * Origin: Baddog BBS (1:218/903)
  • From Edward Hevlund@2:200/486.4 to Frank Vest on Sunday, August 11, 2002 00:07:12
    Didn't you just say "one zone and one net"?

    True, but not within Fidonet specs... I think.

    Oh. I thought you people were making up new specs.

    Thought it was kinda dumbassed to still old fidonet software for the new specs...



    --- JEdPoint
    * Origin: Redneck: You ever lost a tooth opening a beer bottle (2:200/486.4)
  • From mark lewis@1:3634/12 to Jasen Betts on Friday, August 16, 2002 14:05:18
    are they three nodes ot is it one?

    i would have to say yes,

    yes=3 or yes=1 ? or yes="that's an unfair question"

    yep!

    )\/(ark


    * Origin: (1:3634/12)
  • From Jasen Betts@3:640/531.42 to Edward Hevlund on Friday, August 16, 2002 20:34:02
    Hi Edward.

    10-Aug-02 23:07:12, Edward Hevlund wrote to Frank Vest


    Didn't you just say "one zone and one net"?

    True, but not within Fidonet specs... I think.

    Oh. I thought you people were making up new specs.

    Thought it was kinda dumbassed to still old fidonet software for
    the new specs..

    yeah, part of the spec was to provide for a tranalstion tool...

    there hasn't been any traffic since the advert went into the fidonews.


    before that there were a few proposed formats being discussed
    mainly two of them, one like this:

    the line would start much like a regular nodelist line, with the

    heirachy, address number, BBS-name, location, sysop name,

    then there'd be a sible field with all the "system flags" - flags that
    apply to a fido system rather thanto the connection requirements,
    (flags like NEC or UUCP flags would be examples of this)
    instead of commas "," they'd be separated using semicolons. ";"
    that's mean that they could be treated as a lump when reading the line and
    the start of the connection information is indicated by the next comma.

    following that on the same line would come any number of connections,
    a connection consists of three fields, the first filed is type specifier,
    to specify the type of the connection, for example POTS (regular dial-up modem) or IP (internet), ISDN, the second fields is the address,
    for a dialup node it's be the international telephone number, for IP it's
    be the IP address or domain name, etc...

    private, down, or other uncontactable nodes nodes wouldn't have any connections listed
    eg:

    ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags

    a system with bith IP and dialup might look like this:
    (but all on a single line)

    ,1701,Some_BBS_Name,Some_Town,Some,Sysop,system_flags
    IP,IP.or.url.com,CM;MO;LO;IBN;ITN,
    POTS,phone-number,33600;V34;V42b;CM;XA

    one with dialup only: (but as a single line)

    ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
    POTS,phone-umber,33600;V34;V42b;CM;XA

    one with IP only: (again it would be a single line in the nodelist)

    ,1701,Some_BBS_Name,Some_Town,Some_Sysop,system_flags,
    IP,IP.or.url.com,CM;MO;LO;IBN;ITN,

    someone with multiple dial-up modems cpould list them all against a single
    node entry in the nodelist,just by repeating the POTS,phone-numbe,flags
    for each modem or possibly listing all the phone numbers with semicolons
    if the modems all have the same capabilities.

    new types of conection could be added by using a different connection-type keyword as mailers would be written to ignore connection types they
    couldn't handle...

    some exalples of connection types.

    POTS - regular dialup modem
    ISDN - isdn digital connection
    IP - intenrnet connection (maybe it should be divided into
    protocols like TELNET,IREX,FTP,EMAIL,BINKP)
    VIA - specify some other node to accept the packets.

    Mark Lewis has a different proposal that in some ways follows the existing nodelist more closely and uses multiple lines to list some nodes,
    I'll let him explain it as he understands its intracisies better than me.

    Bye <=-

    *---/


    Bye <=-

    ---
    * Origin: Drive defensively. Buy a tank. (3:640/531.42)
  • From Johannes Lundberg@2:206/149 to mark lewis on Tuesday, September 17, 2002 12:14:50
    You can point your fidonet.net (or whatever) to your selected DynDNS-provider with a CNAME. All DNS-resolvers follow CNAMEs
    until they find an A-record, so dynamic IPs and dialups is not
    a problem, if you don't mind using existing DynDNS-providers.

    true... very true... until you run into some system that insists on IP number instead of domain name... i'm thinking of a situation where one wants to go the other way...

    I don't get your point here about situations where one would want to go the other way around. Please explain. :)

    --- GoldED/LNX 3.0.1
    * Origin: (2:206/149)
  • From mark lewis@1:3634/12 to Johannes Lundberg on Wednesday, September 18, 2002 01:28:42
    You can point your fidonet.net (or whatever) to your selected
    DynDNS-provider with a CNAME. All DNS-resolvers follow CNAMEs
    until they find an A-record, so dynamic IPs and dialups is not
    a problem, if you don't mind using existing DynDNS-providers.

    true... very true... until you run into some system that
    insists on IP number instead of domain name... i'm thinking of
    a situation where one wants to go the other way...

    I don't get your point here about situations where one would
    want to go the other way around. Please explain. :)

    i believe that i was thinking of rDNS... my system currently has f4 (four) valid rDNS entries... some software only gets the first one and if it doesn't match what they are expecting, out ya go...

    )\/(ark


    * Origin: (1:3634/12)
  • From Malcolm Miles@3:633/260 to Peter Knapper on Thursday, October 10, 2002 01:00:36
    On Jul 18, 2002 Peter Knapper wrote to Malcolm Miles:

    could PSTN nodes could have DNS entries without having IP addresses
    (I expect malcolm knows the answer to this), that could help.

    It could make sense if it could be used by IP only nodes to find an
    IP ==> PSTN Gateway to reach the target PSTN node.

    All PSTN nodes could have DNS entries with the listed host
    pointing to the host used by its IP ==> PSTN gateway.

    Alternatively you could only list net, region or zone gateways. If the mailer software didn't find a DNS entry for a particular node it would walk up the net/region/zone tree until it found a
    gateway.

    For example if no DNS entry for
    "_binkp._tcp.f260.n633.z3.fidonet.net" was found, a search would be made for a net gateway at "_binkp._tcp.n633.z3.fidonet.net" and if not found it could then
    try looking for a zone gateway at "_binkp._tcp.z3.fidonet.net".

    Just realised that this option doesn't allow for region gateways as they aren't
    included in the node address structure.

    Perhaps the first option of giving all PSTN nodes a DNS entry that points to their IP gateway is the most flexible.

    Best wishes,
    Malcolm

    --- timEd/386 1.10.y2k+
    * Origin: Tardis BBS +61 3 9819 7093 (3:633/260)