• linked

    From Bob Short@1:105/38 to All on Wednesday, December 11, 2002 15:03:04
    Hiya everyone,

    It was suggested to me that this echo would be a great place to start discussing possible nodelist format changes, and the software which
    would utilize them.

    I just did a 30 day rescan of the echo, and was returned one message.
    If this is due to a pass-thru on my uplink's system, please let me
    know what has beed going on the last month or so (in nutshells please).

    Some of you are aware that elections are ongoing for new standing
    members of the FTSC. Once elected, it is my hope that the new panel
    will take a different approach to reaching and applying standards that
    can incorporate IP listings, without compromising current PSTN methods.

    A lot has been debated regarding flags and fields in the current NL
    format, but recent tests have (so far) shown promise for an extended
    NL format that make use of ;E(rror) lines, which could be used by
    modifying currently developing mailers, and a seg editor to compile it.

    I would ask all IP programmers to chime in here on this, and express
    their collective thoughts of feasibility. :)

    Bob Short

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From Frank Vest@1:124/6308.1 to Bob Short on Wednesday, December 11, 2002 18:09:17
    On (11 Dec 02) Bob Short wrote to All...

    Hello Bob,

    Hiya everyone,

    Umm... maybe? If anyone is here. :)

    I just did a 30 day rescan of the echo, and was returned one message.
    If this is due to a pass-thru on my uplink's system, please let me
    know what has beed going on the last month or so (in nutshells
    please).

    I keep 10 days on my Point system. You are the first in at least that
    long. :/ The echo is passthrough on my Node/BBS system.

    I would ask all IP programmers to chime in here on this, and express
    their collective thoughts of feasibility. :)

    I'm not a programmer.... My $.02 is that Fidonet really doesn't need a
    new format.


    Frank

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

    ... Who wrote this tagline? I don't like it.

    --- PPoint 3.01
    * Origin: Holy Cow! I'm A Point!! (1:124/6308.1)
  • From Bob Short@1:105/38 to Frank Vest on Wednesday, December 11, 2002 17:30:43
    On 11 Dec 02 18:09:17, Frank Vest said the following to Bob Short:

    Hiya everyone,

    Umm... maybe? If anyone is here. :)

    <sigh>

    I keep 10 days on my Point system. You are the first in at least that
    long. :/ The echo is passthrough on my Node/BBS system.

    The single msg I got was Dale's. Not sure when he posted that reply,
    but given that this echo was referred to in FTSC_PUB, I assumed there
    was -some- sort of traffic.

    Be that as it may, we should do what we can to get people here to touch
    bases and discuss implimentation of the different ideas debated there.

    I would ask all IP programmers to chime in here on this, and express their collective thoughts of feasibility. :)

    I'm not a programmer.... My $.02 is that Fidonet really doesn't need a
    new format.

    You'll agree it needs /something/ though, right? ;-)

    I've read several threads on this and that solution, and believe that
    an expanded NL format will be the easiest to accomplish and distribute.
    At least, I'd like the possibility investigated... :)

    Bob

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From Bob Short@1:105/38 to Mark Lewis on Thursday, December 12, 2002 00:24:39
    On 11 Dec 02 23:41:54, Mark Lewis said the following to Bob Short:

    I just did a 30 day rescan of the echo, and was returned
    one message. If this is due to a pass-thru on my uplink's
    system, please let me know what has beed going on the
    last month or so (in nutshells please).

    i go back to Nov 11 and yours is the 24th message... frakn vest's reply is and this one will be 26... there hasn't been a whole lot going on because s backbone distributions do not view this area as an "official" "admin-type"

    Understood. My ulink has had this for some time now, but I think as 'pass-thru', so there whould be nothing to rescan before linking.

    additionally, traditionally, this has been the gathering place of developer and spec creators while the FTSC gathered here and in other places...

    Then there should be little trouble in getting them back to hash out
    some ideas. :)

    Bob

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From Peter Knapper@3:772/1.10 to Mark Lewis on Thursday, December 12, 2002 21:55:46
    Hi Mark,

    I just did a 30 day rescan of the echo, and was returned
    one message. If this is due to a pass-thru on my uplink's
    system, please let me know what has beed going on the
    last month or so (in nutshells please).

    i go back to Nov 11 and yours is the 24th message...

    I have about 350 messages here, dating back to Feb 2002. Yell if you want them,
    I can rescan and deliver them (binkD of course...;-)) to whatever address you wish.

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From mark lewis@1:3634/12 to Peter Knapper on Thursday, December 12, 2002 09:39:14
    I just did a 30 day rescan of the echo, and was returned
    one message. If this is due to a pass-thru on my uplink's
    system, please let me know what has beed going on the
    last month or so (in nutshells please).

    i go back to Nov 11 and yours is the 24th message...

    I have about 350 messages here, dating back to Feb 2002. Yell
    if you want them, I can rescan and deliver them (binkD of
    course...;-)) to whatever address you wish.

    that would be fine... send'em to this address... please also include a netmail so that i will know they are here... i don't think i'll import them into this echo, though... don't wanna take a chance on reexporting them back out at everyone...

    )\/(ark


    * Origin: (1:3634/12)
  • From Frank Vest@1:124/6308.1 to Bob Short on Thursday, December 12, 2002 08:57:24
    On (11 Dec 02) Bob Short wrote to Frank Vest...

    Hello Bob,

    [Nodelist]
    Be that as it may, we should do what we can to get people here to
    touch bases and discuss implimentation of the different ideas debated there.

    I would ask all IP programmers to chime in here on this, and express their collective thoughts of feasibility. :)

    I'm not a programmer.... My $.02 is that Fidonet really doesn't need a
    new format.

    You'll agree it needs /something/ though, right? ;-)

    No (wrong).

    I've read several threads on this and that solution, and believe that
    an expanded NL format will be the easiest to accomplish and
    distribute. At least, I'd like the possibility investigated... :)

    Please tell me what is wrong /with/ the Nodelist /format/ that Fidonet
    needs a new one?

    I once thought that the Nodelist had problems. I'm now more convinced
    that the Nodelist is not the problem. The problems are:

    1. Lack of specifications and standards

    2. Programs that haven't kept up with new technology as well as
    specs/standards. (because there haven't been any specs/standards
    written to keep up with)

    3. Programs that were written without following specs and standards
    because those specs and standards didn't exist.

    4. Various other programming and/or use problems... many due to lack
    of or outdated specs/standards.

    The Fidonet Nodelist is nothing more (or less) than a comma delimited
    file. This Nodelist file doesn't care what it contains. The programs,
    scripts and other things that use the Nodelist file care a /lot/ about
    what is in there, but the file itself couldn't care less. :-)

    The trick, IMHO, is to get the standards and specifications in order
    without causing major problems with older software and then get the
    software that is still under development to adjust to those
    specs/standards.

    As an example: The "PVT/-UNPUBLISHED-" problem. The Nodelist file
    doesn't care if there is a PVT, HUB, HOST, REGION, ZONE or any other
    word as/in the first field in it. The programs that the *Cs use to
    compile the Node Segments into their respective Nodelists and
    ultimately into the master Nodelist care a lot. The problem isn't in
    the Nodelist... The problem is in the programs (NLMake, MakeNL and
    such) and the specs/standards.

    I've been through this before in this echo. It's a mess. :-) What
    needs to be done, IMHO, is to get the specs/standards in order. Then
    get programs that are still being developed to follow those specs and standards.

    Please feel free to Netmail me or to e-mail me at "flv (at) sbcglobal
    (dot) net" with any Nodelist /format/ problems. :-)


    Regards,

    Frank

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

    ... Well, there you go. Are you sorry you asked?

    --- PPoint 3.01
    * Origin: Holy Cow! I'm A Point!! (1:124/6308.1)
  • From mark lewis@1:3634/12 to Bob Short on Wednesday, December 11, 2002 23:41:54
    I just did a 30 day rescan of the echo, and was returned
    one message. If this is due to a pass-thru on my uplink's
    system, please let me know what has beed going on the
    last month or so (in nutshells please).

    i go back to Nov 11 and yours is the 24th message... frakn vest's reply is 25 and this one will be 26... there hasn't been a whole lot going on because some backbone distributions do not view this area as an "official" "admin-type" "carry all the time" echo ;-( thus many systems dropped it when they removed it
    for low traffic... some of us are still waiting on the "moderator" to (re)request it to be carried... additionally, the "moderator" may want to alter
    the echo's description in the echolist to make it more "official" appearing...

    i use "moderator" in quotes because the "moderator of record" has traditionally
    been a custodian and contact person only for the purpose of updating the elist to avoid this very situation...

    additionally, traditionally, this has been the gathering place of developers and spec creators while the FTSC gathered here and in other places... FTSC-PUBLIC was created by the last FTSC as a place akin to the IC, and ZCC-PUBLIC echos... somewhere where folk could talk with the FTSC rather than what has been taking place in there recently... IMO, since there is an election
    for FTSC members, FTSC-PUBLIC should be totally about the election and nothing else until the end of the election...

    anyway, that's all that... i didn't rescan the existing messages to see what they were about though i have read them and possibly even wrote a few of them...

    )\/(ark


    * Origin: (1:3634/12)
  • From Jasen Betts@3:640/1042 to Bob Short on Thursday, December 12, 2002 21:19:09
    Hi Bob.

    It was suggested to me that this echo would be a great place to
    start discussing possible nodelist format changes, and the
    software which would utilize them.

    we were kicking that ball around a bit a few months back,
    we came up with a few different proposals for a new (IE non-slf)
    nodelist formats and little else

    I just did a 30 day rescan of the echo, and was returned one
    message. If this is due to a pass-thru on my uplink's system,
    please let me know what has beed going on the last month or so (in nutshells please).

    very little. I thought that possibly the echo had fallen of the backbone(s)

    Some of you are aware that elections are ongoing for new standing
    members of the FTSC. Once elected, it is my hope that the new
    panel will take a different approach to reaching and applying
    standards that can incorporate IP listings, without compromising
    current PSTN methods.

    uunfortunately FTSC doesn't make the rules, the ZCC does AFAICT.

    A lot has been debated regarding flags and fields in the current
    NL format, but recent tests have (so far) shown promise for an
    extended NL format that make use of ;E(rror) lines, which could be
    used by modifying currently developing mailers, and a seg editor
    to compile it.

    I would ask all IP programmers to chime in here on this, and
    express their collective thoughts of feasibility. :)

    it'll require programmers to think a bit more when reading the nodelist and code their software to look-ahead a bit, but that shouldn't be a problem
    for experienced programmers.

    Bye <=-

    ---
    * Origin: Ban the bomb. Save the world for conventional warfare (3:640/1042)
  • From Bob Short@1:105/38 to Frank Vest on Friday, December 13, 2002 10:55:17
    On 12 Dec 02 08:57:24, Frank Vest said the following to Bob Short:

    I'm not a programmer.... My $.02 is that Fidonet really doesn't need a
    new format.

    You'll agree it needs /something/ though, right? ;-)

    No (wrong).

    I have a lot of respect for you and your opinions on many topics, but
    in this I think you are a bit blinded. Why, I have no idea. Nearly
    everyone here has agreed that the current NLF is insufficient to deal
    with current (much less emerging) technology.

    I've been through this before in this echo. It's a mess. :-) What
    needs to be done, IMHO, is to get the specs/standards in order. Then
    get programs that are still being developed to follow those specs and standards.

    My point exactly. I'd like to see both happen at the same time.

    We have to condescend to the lowest common denominator (legacy SW),
    and concentrate of current and emerging software.

    Bob

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From Bob Short@1:105/38 to Jasen Betts on Friday, December 13, 2002 11:10:56
    On 12 Dec 02 21:19:09, Jasen Betts said the following to Bob Short:

    It was suggested to me that this echo would be a great place to
    start discussing possible nodelist format changes, and the
    software which would utilize them.

    we were kicking that ball around a bit a few months back,
    we came up with a few different proposals for a new (IE non-slf)
    nodelist formats and little else

    So far, I have seen only two potential solutions (in FTSC_PUBLIC) to
    the problems of SLF limitations. One involves XML, an external prog.
    language which will require too many steps to utilize. The other an
    expansion (through re-arrangement or addition) of the SLF, requiring modificatons to IP software, and (probably) a new IP seg editor(s).

    uunfortunately FTSC doesn't make the rules, the ZCC does AFAICT.

    In a way they do, by standardizing established practices. The panel's
    mission in this respect should change, with the placement of people who
    have the ability to look at proposals from the programmer's POV.

    A lot has been debated regarding flags and fields in the current
    NL format, but recent tests have (so far) shown promise for an extended NL format that make use of ;E(rror) lines, which could be used by modifying currently developing mailers, and a seg editor
    to compile it.

    it'll require programmers to think a bit more when reading the nodelist and code their software to look-ahead a bit, but that shouldn't be a problem for experienced programmers.

    Like those worling with IP software? ;-)

    Bob

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From Peter Knapper@3:772/1.10 to Mark Lewis on Friday, December 13, 2002 21:35:14
    Hi Mark,

    I have about 350 messages here, dating back to Feb 2002. Yell
    if you want them, I can rescan and deliver them (binkD of
    course...;-)) to whatever address you wish.

    that would be fine... send'em to this address... please
    also include a netmail so that i will know they are
    here...

    A ZIP file is being dropped off as I type...

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Frank Vest@1:124/6308.1 to Bob Short on Friday, December 13, 2002 18:37:39
    On (13 Dec 02) Bob Short wrote to Frank Vest...

    Hello Bob,

    You'll agree it needs /something/ though, right? ;-)
    No (wrong).
    I have a lot of respect for you and your opinions on many topics, but
    in this I think you are a bit blinded. Why, I have no idea. Nearly everyone here has agreed that the current NLF is insufficient to deal
    with current (much less emerging) technology.

    Agreement? Everyone?

    I've been through this before in this echo. It's a mess. :-) What
    needs to be done, IMHO, is to get the specs/standards in order. Then
    get programs that are still being developed to follow those specs and standards.

    My point exactly. I'd like to see both happen at the same time.

    We have to condescend to the lowest common denominator (legacy SW),
    and concentrate of current and emerging software.

    <sigh>

    Let me go through this a little better and see what gets stirred up.

    Binkp, telnet and ftp are protocols for IP. Just as zedzap, emsi,
    zmodem and others are protocols for POTS.

    The Nodelist is a comma delimited file used by Fidonet mailers (and
    other programs) to determine /where/ to connect.

    Now, using that and your statement, along with the arguments of others
    that the Nodelist can not show binkp, telnet and other connection
    information or emerging technologies, I put it forth that the Nodelist
    could not and did not work properly with POTS to begin with. There is
    no indication that my POTS mailer can do emsi, zedzap or other
    protocols.

    The Nodelist gives information on where to contact Nodes. In the POTS
    realm, that is the phone number. In the IP world, that is the IP
    address or domain name. Protocols are not shown in the Nodelist, and
    for good reason. Imagine if there had to be a flag for emsi, zedzap
    and all the other POTS protocols. Taking this further, consider POTS
    Nodes with multiple phone lines. What if each one wanted to list each
    line with different protocols? One line does emsi only while others
    will handle other protocols. <whew!>

    Of course, the argument is that with POTS, the protocols are
    negotiated upon connection. There is a thread in the FTSC_PUBLIC echo
    that is attempting to work out just such a thing for IP Nodes. It
    might be done with a "Fidonet Finger Daemon" or some other method,
    but, if successful, this would remove the need for protocol flags in
    the Nodelist for IP Nodes (IE: IBN, IFT and such). This, in turn would
    bring the Nodelist back to what it should be. A comma delimited file
    for Fidonet mailers to determining "how" to contact other Fidonet
    mailers instead of what "protocols" to use to make contact.

    Even in the IP mailers, there is no indication that the telnet mailer
    can do emsi, zedzap or other protocols... but some can. :-)

    Now, put this into operation. Put the IP or domain in the "name" field
    of the Nodelist. Standardize an IP flag ("IP" would do) that tells IP
    mailers to access the finger daemon on the default "Fidonet" port at
    the IP/domain address listed to get the information on what the Node
    is capable of and what port(s).

    With this in place, the current Nodelist would work for "legacy"
    mailers since there is nothing really changed in it... just the
    addition of /one/ flag (instead of several). I think it would also
    work for emerging technologies since the method of determining the
    ports, protocols and other such is via "emerging" technologies (the
    Internet and a finger daemon).

    To go one step further... It has been pointed out that many IP mailers
    don't rely on the Fidonet Nodelist anyway.

    To anyone that wants to chop this reply up and argue each paragraph,
    sentence or word, please don't. Please read all of this reply before
    your beat me up. :-) I think I have covered legacy software as well
    as emerging software.

    Regards,

    Frank

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

    ... Well, there you go. Are you sorry you asked?

    --- PPoint 3.01
    * Origin: Holy Cow! I'm A Point!! (1:124/6308.1)
  • From mark lewis@1:3634/12 to Frank Vest on Friday, December 13, 2002 20:08:00
    Let me go through this a little better and see what gets
    stirred up.

    you got it! <<GG>>

    Binkp, telnet and ftp are protocols for IP. Just as zedzap,
    emsi, zmodem and others are protocols for POTS.

    i use zedzap, emsi, zmodem, and others on IP with relatively no problems...

    Of course, the argument is that with POTS, the protocols
    are negotiated upon connection. There is a thread in the
    FTSC_PUBLIC echo that is attempting to work out just such
    a thing for IP Nodes.

    it can be done in IP mailers just exactly like it is done in POTS mailers... trouble is, it seems, that coders don't want to or haven't figured out how ;-(

    )\/(ark


    * Origin: (1:3634/12)
  • From Frank Vest@1:124/6308.1 to mark lewis on Friday, December 13, 2002 22:16:07
    On (13 Dec 02) mark lewis wrote to Frank Vest...

    Hello mark,


    Let me go through this a little better and see what gets
    stirred up.
    you got it! <<GG>>

    Oh gawd! You're here too?? <GD&R> :)

    Binkp, telnet and ftp are protocols for IP. Just as zedzap,
    emsi, zmodem and others are protocols for POTS.
    i use zedzap, emsi, zmodem, and others on IP with relatively no problems...

    With telnet?? i wager?

    Of course, the argument is that with POTS, the protocols
    are negotiated upon connection. There is a thread in the
    FTSC_PUBLIC echo that is attempting to work out just such
    a thing for IP Nodes.

    it can be done in IP mailers just exactly like it is done in POTS mailers... trouble is, it seems, that coders don't want to or haven't figured out how ;-(

    Yup. Always go with the new, no matter what, just because. :(


    Was my description/proposal/argument accurate and well presented? Did
    I make sense? What is your opinion on the idea? You can answer in
    Netmail if desired.

    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)
  • From mark lewis@1:3634/12 to Peter Knapper on Friday, December 13, 2002 21:13:56
    I have about 350 messages here, dating back to Feb 2002. Yell
    if you want them, I can rescan and deliver them (binkD of
    course...;-)) to whatever address you wish.

    that would be fine... send'em to this address... please
    also include a netmail so that i will know they are
    here...

    A ZIP file is being dropped off as I type...

    i'll say... thanks! <<GG>>

    - 13 Dec 03:34:22 [1] incoming from 203-79-64-102.adsl.paradise.net.nz (203.79.6
    + 13 Dec 03:34:23 [3] session with 203-79-64-102.adsl.paradise.net.nz (203.79.64
    - 13 Dec 03:34:23 [3] SYS Maxie BBS
    - 13 Dec 03:34:23 [3] ZYZ Peter Knapper
    - 13 Dec 03:34:23 [3] LOC maxie.fdns.net Auckland, Nz
    - 13 Dec 03:34:24 [3] NDL TCP,FTP,BINKP
    - 13 Dec 03:34:24 [3] TIME 2002/12/13 21:34:20
    - 13 Dec 03:34:24 [3] VER binkd/0.9.3h/OS/2 binkp/1.1
    + 13 Dec 03:34:24 [3] addr: 3:772/1@fidonet
    + 13 Dec 03:34:25 [3] addr: 3:772/10@fidonet
    + 13 Dec 03:34:26 [3] addr: 3:57/0@fidonet
    - 13 Dec 03:34:26 [3] OPT NR
    + 13 Dec 03:34:26 [3] Remote requests NR mode
    - 13 Dec 03:34:26 [3] we are in NR mode
    - 13 Dec 03:34:27 [3] remote is in NR mode
    + 13 Dec 03:34:27 [3] have 0 byte(s) of NETDEV.ZIP
    - 13 Dec 03:34:28 [3] receiving NETDEV.ZIP (198738 byte(s), off 0)
    + 13 Dec 03:35:41 [3] NETDEV.ZIP -> d:\bink\inbound\unknown\NETDEV.ZIP
    + 13 Dec 03:35:41 [3] rcvd: NETDEV.ZIP (198738, 2722.44 CPS, 3:772/1@fidonet)
    + 13 Dec 03:35:41 [3] done (from 3:772/1@fidonet, OK, S/R: 0/1 (0/198738 bytes))
    13 Dec 03:35:41 [3] session closed, quitting...

    NR mode was set by my recent addition of the defnode setting in binkd...

    one thing that i've discovered that that has led to is that i must define all the fidonet addresses of those nodes connecting to me... at least, it appears that way, so far... two other systems could not connect due to their presentation of all fidonet akas instead of just the one we use between us... i
    have to wait on the others to connect and see what happens with them... several
    are flying akas in other networks...

    )\/(ark


    * Origin: (1:3634/12)
  • From Peter Knapper@3:772/1.10 to Frank Vest on Saturday, December 14, 2002 16:36:48
    Hi Frank,

    Ok, I read the entire message first, however there is at least one major section that I feel needs further discussion.

    Put the IP or domain in the "name" field of the Nodelist.

    The probem I see is this. The "System Name" field was designed for ... the System name. If you now wish to use it for something else, you are going to confuse a lot of people and S/W, simply because of this one apparently simple change.

    No person, and no S/W, will be able to guarantee what data they are reading from that field. There is also, no "safe" way to determine if one should use the field or not. As an IP node, I may prefer to have my system name distinct, and not follow any particular Domain name, and yet you are now saying that I can't do that any more. The net result from doingthis will make it VERY hard for Fidonet members to accept this convention (IMHO).


    Standardize an IP flag ("IP" would do) that tells IP
    mailers to access the finger daemon on the default "Fidonet" port at
    the IP/domain address listed to get the information on what the Node
    is capable of and what port(s).

    A couple of things here, I can't really see a "Finger" daemon as being necessary, the functionality is minimal, and the similar capability can be determined by "testing" the result of each "open". Locating the service ports can be done in the DNS (with SRV records), again negating "finger". Years ago, Finger was useful, but with more recent advances to the way IP has evolved, its
    not really used a lot these days. These days an application can be much smarter
    at handling this, similar to our PSTN S/W.


    With this in place, the current Nodelist would work for "legacy"
    mailers since there is nothing really changed in it...

    Agreed, with all the new bits added elsewhere, the current Nodelist will work purfectly for PSTN nodes.

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Peter Knapper@3:772/1.10 to Mark Lewis on Saturday, December 14, 2002 16:45:36
    Hi Mark,

    NR mode was set by my recent addition of the defnode setting in binkd...

    Interesting... The docs I read said that NR mode was better enabled for "ad-hoc" connections, so it was set to NR for defnode anyway. I have removed it
    now, to see how it goes next time. Oh, the connection was found using * for the
    DNS name.......;-)

    one thing that i've discovered that that has led to is
    that i must define all the fidonet addresses of those
    nodes connecting to me... at least, it appears that
    way, so far... two other systems could not connect due
    to their presentation of all fidonet akas instead of
    just the one we use between us... i have to wait on the
    others to connect and see what happens with them...
    several are flying akas in other networks...

    I remember seeing something about problems with AKA's and BinkD but I can't remember the detail, because its never restricted my operation (as far as I know). I am still using the older 0.93h that I have been using for years. I have 0.94 here so I must upgrade (one day).....;-).

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Frank Vest@1:124/6308.1 to Peter Knapper on Saturday, December 14, 2002 00:30:13
    On (14 Dec 02) Peter Knapper wrote to Frank Vest...

    Hello Peter,

    Ok, I read the entire message first, however there is at least one
    major section that I feel needs further discussion.

    Ok. Thank you. :)

    Put the IP or domain in the "name" field of the Nodelist.

    The probem I see is this. The "System Name" field was designed for ...
    the System name. If you now wish to use it for something else, you are going to confuse a lot of people and S/W, simply because of this one apparently simple change.

    It seems that people and software are already confused on many things.
    :)

    No person, and no S/W, will be able to guarantee what data they are reading from that field. There is also, no "safe" way to determine if
    one should use the field or not. As an IP node, I may prefer to have
    my system name distinct, and not follow any particular Domain name,
    and yet you are now saying that I can't do that any more. The net
    result from doingthis will make it VERY hard for Fidonet members to
    accept this convention (IMHO).

    No software now uses XML either. The 'trick" with any idea is to get
    it in use and software to surpport it. The rest is getting the idea to
    become a standard.

    You don't have to use the name field if you don't want to. No one is
    going to force you to list your contact phone number, IP address or
    domain. If you don't list your IP or domain, you don't fly the IP
    flag. If you don't list a phone number in the Nodelist, you fly the
    PVT flag. Simple, eh?

    It was hard for Fidonet members to accept the Internet as a transport
    medium a few years ago too. Will it be easier to accept any other
    convention? :)

    Standardize an IP flag ("IP" would do) that tells IP
    mailers to access the finger daemon on the default "Fidonet" port at
    the IP/domain address listed to get the information on what the Node
    is capable of and what port(s).

    A couple of things here, I can't really see a "Finger" daemon as being necessary, the functionality is minimal, and the similar capability
    can be determined by "testing" the result of each "open". Locating the service ports can be done in the DNS (with SRV records), again

    Ok. DNS is fine. I really don't care what is used. Telepathy is ok for
    all I care... as long as it works. :-)

    With this in place, the current Nodelist would work for "legacy"
    mailers since there is nothing really changed in it...

    Agreed, with all the new bits added elsewhere, the current Nodelist
    will work purfectly for PSTN nodes.

    I think it will work for IP nodes as well. YMMV.


    I just don't see having two Nodelists... one for my pots mailer and
    one for my IP mailer. Or, one that is converted to another where
    needed. To maintain two Nodelist formats on my system seems redundant
    and taking up space for the sake of taking up space.

    One Nodelist with a flag that tells the IP mailer that this is an IP
    capable Node with a "phone number" of <some.domain> while the pots
    mailer will look for a phone number in the "phone" field and use it if configured to do so seems better to me. Both legacy and IP are covered
    by the respected technologies of POTS and/or Internet.


    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)
  • From Bill Birrell@2:25/200 to Frank Vest on Friday, December 13, 2002 22:33:00
    Umm... maybe? If anyone is here. :)

    Lotsa lurkers.

    Best Wishes,
    Bill.

    ---
    * Origin: Escan BBS (2:25/200)
  • From Gordon Lewicky@1:153/307 to Frank Vest on Saturday, December 14, 2002 07:55:12
    Quoting Frank Vest to Bob Short
    Subj. linked, dated 13-Dec-2002 18:37

    Hi ya Frank,

    Now, put this into operation. Put the IP or domain in the "name" field
    of the Nodelist. Standardize an IP flag ("IP" would do) that tells IP mailers to access the finger daemon on the default "Fidonet" port at
    the IP/domain address listed to get the information on what the Node
    is capable of and what port(s).

    Yup, read the whole thing, and agree in general.

    Just like to make one comment on what to do with the domain name.
    It might be vanity on my part, or ego, but my bbs /IS/ called
    Milky Way.

    It's not milkyway.somewhere.com just as my name isn't
    glewicky@somewhere.com

    You may most certainly send me a msg to my email address but I
    would hope that you would address me by my given name. Likewise
    you may binkp to my bbs at it's address but I do hope that when
    you speak of it, you use it's given name, just like you use my
    given name when speaking of me, hopefully. :)

    I'll be binkp capable by the next nodelist, already am to
    my inet links, but I will be adding my address in the IBN flag,
    because I see no reason why I should have to change my bbs's given
    name to suit the nodelist, for exactly the same reason why I see
    no reason why I should have to change my own name to suit the
    nodelist.

    Small point? Maybe, but in this day and age of de-personalization,
    I think we should do whatever it takes to retain a modicum of
    personality within the nodelist.

    If we are going to fix things, then I think that there should be a
    way to have the ip address in some other place on the line as well.

    We can keep the usage of the bbs name field for the domain name in
    ions, or for pots/ions for those who don't care and for brevity's
    sake as well, but not make it manditory.

    Dammit, I am 2 personae. I am Gordon Lewicky and I am Milky Way
    and I am damn proud of both names! :)

    Cheers...
    Gordon Lewicky (Pdk)

    Sysop - Milky Way 1:153/307 NC 153
    AdventureNet 33:500/150
    email glewicky@telus.net

    --- EzyBlueWave/2 V2.00 00F90260
    * Origin: Milky Way, Langley, BC [604] 532-4367 (1:153/307)
  • From Peter Knapper@3:772/1.10 to Frank Vest on Saturday, December 14, 2002 22:45:24
    Hi Frank,

    The net
    result from doing this will make it VERY hard for Fidonet members to accept this convention (IMHO).

    No software now uses XML either. The 'trick" with any idea is to get
    it in use and software to surpport it. The rest is getting the idea to become a standard.

    Thats why I can't see it flying, people need to see value with the idea, and if
    the idea adds confusion, then there is lttle value...

    If you don't list your IP or domain, you don't fly the IP flag.

    You are of course, then saying there is no other possible way to find out how to contact that node, which of course is not correct....;-)

    If you don't list a phone number in the Nodelist, you fly the
    PVT flag. Simple, eh?

    Because there was no other way to do it for PSTN nodes, however with IP nodes we have other ways. Why propagate something that is no longer valid?

    It was hard for Fidonet members to accept the Internet as a transport medium a few years ago too. Will it be easier to accept any other convention? :)

    The speed of acceptance of the Internet was directly related to how long it took for the benefits to be seen as worthwhile to the end node. Certain nodes had no troube using the Internet back in 1992, however most agreed the cost of doing that was quite high. As the cost droppped, more and more people moved over to that way of working, its really just a natural progression.


    Ok. DNS is fine. I really don't care what is used. Telepathy is ok for
    all I care... as long as it works. :-)

    I would need to see DIRECT proof that it works first........;-)

    Agreed, with all the new bits added elsewhere, the current Nodelist
    will work purfectly for PSTN nodes.

    I think it will work for IP nodes as well. YMMV.

    Yes, it CAN work for IP, however I am still slightly concerned with some of the
    suggestions and the possible ramifications that might result.


    I just don't see having two Nodelists... one for my pots mailer and
    one for my IP mailer. Or, one that is converted to another where
    needed. To maintain two Nodelist formats on my system seems redundant
    and taking up space for the sake of taking up space.

    Agreed, One Nodelist, but UNMANGLED and using other resources (eg DNS) where it
    helps.


    One Nodelist with a flag that tells the IP mailer that this is an IP capable Node with a "phone number" of <some.domain> while the pots
    mailer will look for a phone number in the "phone" field and use it if configured to do so seems better to me.

    Its this type of mangling that concerns me....;-(

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Frank Vest@1:124/6308.1 to Gordon Lewicky on Saturday, December 14, 2002 10:35:07
    On (14 Dec 02) Gordon Lewicky wrote to Frank Vest...

    Hello Gordon,

    Now, put this into operation. Put the IP or domain in the "name" field
    of the Nodelist. Standardize an IP flag ("IP" would do) that tells IP mailers to access the finger daemon on the default "Fidonet" port at
    the IP/domain address listed to get the information on what the Node
    is capable of and what port(s).

    Yup, read the whole thing, and agree in general.

    Ok. :)

    Just like to make one comment on what to do with the domain name.
    It might be vanity on my part, or ego, but my bbs /IS/ called
    Milky Way.

    It's not milkyway.somewhere.com just as my name isn't glewicky@somewhere.com

    Understood. I do not like putting the domain or IP in the name field
    either. I also don't like putting the e-mail address in the Sysop name
    field.

    Dammit, I am 2 personae. I am Gordon Lewicky and I am Milky Way
    and I am damn proud of both names! :)

    I understand your point. Would the "location" field be better? Or is
    where you live as important to you as your name and your system name?

    Using a flag to indicate the IP or domain address is fine too. As long
    as it is /one/ flag instead of one for every IP protocol.


    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)
  • From Frank Vest@1:124/6308.1 to Peter Knapper on Saturday, December 14, 2002 10:50:16
    On (14 Dec 02) Peter Knapper wrote to Frank Vest...

    Hello Peter,

    No software now uses XML either. The 'trick" with any idea is to get
    it in use and software to surpport it. The rest is getting the idea to become a standard.
    Thats why I can't see it flying, people need to see value with the
    idea, and if the idea adds confusion, then there is lttle value...

    Ok?

    If you don't list your IP or domain, you don't fly the IP flag.
    You are of course, then saying there is no other possible way to find
    out how to contact that node, which of course is not correct....;-)

    Not at all. Each Node can set up contacts with each other without the
    use of any Nodelist. Even POTS Nodes can do this. :)

    If you don't list a phone number in the Nodelist, you fly the
    PVT flag. Simple, eh?
    Because there was no other way to do it for PSTN nodes, however with
    IP nodes we have other ways. Why propagate something that is no longer valid?

    See above. :)

    It was hard for Fidonet members to accept the Internet as a transport medium a few years ago too. Will it be easier to accept any other convention? :)
    The speed of acceptance of the Internet was directly related to how
    long it took for the benefits to be seen as worthwhile to the end
    node. Certain nodes had no troube using the Internet back in 1992,
    however most agreed the cost of doing that was quite high. As the cost droppped, more and more people moved over to that way of working, its really just a natural progression.

    And as a method of listing Fidonet Nodes in the Nodelist becomes used
    more, it will be moved to as well.

    Ok. DNS is fine. I really don't care what is used. Telepathy is ok for
    all I care... as long as it works. :-)
    I would need to see DIRECT proof that it works first........;-)

    You and me both. (I'm sending you my connection info via telepathy
    right now. Did you receive it??) :-))

    Agreed, with all the new bits added elsewhere, the current Nodelist
    will work purfectly for PSTN nodes.
    I think it will work for IP nodes as well. YMMV.
    Yes, it CAN work for IP, however I am still slightly concerned with
    some of the suggestions and the possible ramifications that might
    result.

    Ok?

    I just don't see having two Nodelists... one for my pots mailer and
    one for my IP mailer. Or, one that is converted to another where
    needed. To maintain two Nodelist formats on my system seems redundant
    and taking up space for the sake of taking up space.
    Agreed, One Nodelist, but UNMANGLED and using other resources (eg DNS) where it helps.

    Agreed.

    One Nodelist with a flag that tells the IP mailer that this is an IP capable Node with a "phone number" of <some.domain> while the pots
    mailer will look for a phone number in the "phone" field and use it if configured to do so seems better to me.
    Its this type of mangling that concerns me....;-(

    How so? All that is being done is adding a flag to tell the IP mailer
    to look in the DNS record for <IP or domain> or poll a finger daemon
    or some such "standard" Internet listing to get the connection
    information (IE: protocol-port).


    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)
  • From Bob Short@1:105/38 to Frank Vest on Saturday, December 14, 2002 10:38:31
    On 13 Dec 02 18:37:39, Frank Vest said the following to Bob Short:

    I have a lot of respect for you and your opinions on many topics, but in this I think you are a bit blinded. Why, I have no idea. Nearly everyone here has agreed that the current NLF is insufficient to deal with current (much less emerging) technology.

    Agreement? Everyone?

    Please read me correctly. I said 'nearly everyone'.

    Let me go through this a little better and see what gets stirred up.

    OK... but you may not like licking the spoon. ;-)

    The Nodelist is a comma delimited file used by Fidonet mailers (and
    other programs) to determine /where/ to connect.

    And 'how/to what extent' to connect.

    Now, using that and your statement, along with the arguments of others
    that the Nodelist can not show binkp, telnet and other connection

    Correct... in it's current format.

    information or emerging technologies, I put it forth that the Nodelist could not and did not work properly with POTS to begin with. There is

    I beg to differ. FTS were written FOR pots, and "adjusted" for IP. All
    known analog modem connection methods can be so indicated in the NL.

    no indication that my POTS mailer can do emsi, zedzap or other
    protocols.

    This is independant of the NL, as session protocols are inherently
    negotiated at connect. No such info is needed in the NL (for POTS).

    The Nodelist gives information on where to contact Nodes. In the POTS realm, that is the phone number. In the IP world, that is the IP
    address or domain name. Protocols are not shown in the Nodelist, and
    for good reason. Imagine if there had to be a flag for emsi, zedzap
    and all the other POTS protocols. Taking this further, consider POTS

    <handing over box of Kleenex>

    You're making this sound more complex than it needs. This is because
    you're putting different connection types in the same basket. I will
    help by understanding that this is NOT about POTS, or POTS session
    connect methods. Those are well documented and applied, and are not
    in need of revision.

    Nodes with multiple phone lines. What if each one wanted to list each
    line with different protocols? One line does emsi only while others
    will handle other protocols. <whew!>

    Again, this session information is automatically negotiated between the
    two mailers (not users, btw). Why would one need to differentiate this
    in the NL? If a particular mailer cannot negotiate a connection, it's
    not writte within FTS specs.

    <retrieving Kleenex, wiping brow>

    Of course, the argument is that with POTS, the protocols are
    negotiated upon connection. There is a thread in the FTSC_PUBLIC
    echo that is attempting to work out just such a thing for IP Nodes.

    Been reading that, and there are some good ideas there... all of which
    should follow the same methods as POTS... built into the mailer, not
    the nodelist. I'm pretty sure that some of the IP authors neglected
    to take into consideration future technologies, just as the FTSC...
    which is why we are here today.

    but, if successful, this would remove the need for protocol flags in
    the Nodelist for IP Nodes (IE: IBN, IFT and such). This, in turn would bring the Nodelist back to what it should be. A comma delimited file
    for Fidonet mailers to determining "how" to contact other Fidonet
    mailers instead of what "protocols" to use to make contact.

    I'm not sure this is entirely possible, or even desired. There are
    too many factors in IP connection and transport. Too much depends
    on 3rd parties (ISP's, DS's, FW's, etc) to incorporate every sort
    of possible condition into a mailer(s). We'll still need the NL for
    a good share of it.

    Even in the IP mailers, there is no indication that the telnet mailer
    can do emsi, zedzap or other protocols... but some can. :-)

    Again, the abaility to determine that should be built into the mailers.
    If it isn't, it's not compliant, and shouldn't be used.

    Now, put this into operation. Put the IP or domain in the "name" field
    of the Nodelist. Standardize an IP flag ("IP" would do) that tells IP mailers to access the finger daemon on the default "Fidonet" port at
    the IP/domain address listed to get the information on what the Node
    is capable of and what port(s).

    Fine.... show me an example entry that can do this... without breaking
    current software.

    To go one step further... It has been pointed out that many IP mailers don't rely on the Fidonet Nodelist anyway.

    Don't they extract the IP info from the NL to create their proprietary
    dialing list? If not, who/what tells them?

    To anyone that wants to chop this reply up and argue each paragraph,

    <putting away jigsaw>

    I did read your entire message before replying, as I usually do. :)

    I'll leave the technical arguments to the techies, and try to learn
    as I read. I don't perport to know a whole lot about the Inet end
    of this debate... only that what we have isn't working, and will get
    worse as time and technology progress.

    Bob

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From Frank Vest@1:124/6308.1 to Bob Short on Saturday, December 14, 2002 13:30:46
    On (14 Dec 02) Bob Short wrote to Frank Vest...

    Hello Bob,

    Agreement? Everyone?
    Please read me correctly. I said 'nearly everyone'.

    My apologies.

    Let me go through this a little better and see what gets stirred up.
    OK... but you may not like licking the spoon. ;-)

    Depends. :)

    The Nodelist is a comma delimited file used by Fidonet mailers (and
    other programs) to determine /where/ to connect.
    And 'how/to what extent' to connect.

    Exactly.

    Now, using that and your statement, along with the arguments of others
    that the Nodelist can not show binkp, telnet and other connection
    Correct... in it's current format.

    Not relevant in the context of the rest of the sentence.

    information or emerging technologies, I put it forth that the Nodelist could not and did not work properly with POTS to begin with. There is
    I beg to differ. FTS were written FOR pots, and "adjusted" for IP.
    All known analog modem connection methods can be so indicated in the
    NL.

    Yes and No. The phone number is listed and the type (name flag of the)
    mailer. XA for Frontdoor and so forth. Nothing about connection
    methods as far as protocols are concerned.

    no indication that my POTS mailer can do emsi, zedzap or other
    protocols.
    This is independant of the NL, as session protocols are inherently negotiated at connect. No such info is needed in the NL (for POTS).

    No need for binkp to be listed either. That protocol can be listed in
    the "mailer name" as above for POTS mailers. In reality, I don't know
    why the mailer flags (XA, XX and such) need to be there anyway. I'm
    sure there is a good reason, but using this same good reason, the IP
    flag that is proposed could be made into a "mailer" flag.

    The Nodelist gives information on where to contact Nodes. In the POTS realm, that is the phone number. In the IP world, that is the IP
    address or domain name. Protocols are not shown in the Nodelist, and
    for good reason. Imagine if there had to be a flag for emsi, zedzap
    and all the other POTS protocols. Taking this further, consider POTS

    <handing over box of Kleenex>

    You're making this sound more complex than it needs. This is because you're putting different connection types in the same basket. I will
    help by understanding that this is NOT about POTS, or POTS session
    connect methods. Those are well documented and applied, and are not
    in need of revision.

    Nodes with multiple phone lines. What if each one wanted to list each
    line with different protocols? One line does emsi only while others
    will handle other protocols. <whew!>

    Again, this session information is automatically negotiated between
    the two mailers (not users, btw). Why would one need to differentiate this in the NL? If a particular mailer cannot negotiate a connection, it's not writte within FTS specs.

    Beg to differ. The only protocol required for POTS by Fidonet is FTS-1
    (Xmodem, I believe). If my mailer only does Xmodem, I'm still within requirements.

    <retrieving Kleenex, wiping brow>

    Take a break if you need. :-)

    Of course, the argument is that with POTS, the protocols are
    negotiated upon connection. There is a thread in the FTSC_PUBLIC
    echo that is attempting to work out just such a thing for IP Nodes.
    Been reading that, and there are some good ideas there... all of which should follow the same methods as POTS... built into the mailer, not
    the nodelist. I'm pretty sure that some of the IP authors neglected
    to take into consideration future technologies, just as the FTSC...
    which is why we are here today.

    Good possibility. That is what needs to be fixed.

    but, if successful, this would remove the need for protocol flags in
    the Nodelist for IP Nodes (IE: IBN, IFT and such). This, in turn would bring the Nodelist back to what it should be. A comma delimited file
    for Fidonet mailers to determining "how" to contact other Fidonet
    mailers instead of what "protocols" to use to make contact.

    I'm not sure this is entirely possible, or even desired. There are
    too many factors in IP connection and transport. Too much depends
    on 3rd parties (ISP's, DS's, FW's, etc) to incorporate every sort
    of possible condition into a mailer(s). We'll still need the NL for
    a good share of it.

    We need the Nodelist to give the "phone number" (IP/domain address for
    IP mailers). That's all that is needed. That is all that was done for
    POTS mailers in that day and age.

    Even in the IP mailers, there is no indication that the telnet mailer
    can do emsi, zedzap or other protocols... but some can. :-)
    Again, the abaility to determine that should be built into the
    mailers. If it isn't, it's not compliant, and shouldn't be used.

    Then BinkD, Irex and several other mailers are not compliant. I can
    not connect to BinkD or Irex and make a negotiated connection. I have
    to tell them that the system I'm calling does binkp, ftp or whatever
    protocol. It's not negotiated.

    Now, put this into operation. Put the IP or domain in the "name" field
    of the Nodelist. Standardize an IP flag ("IP" would do) that tells IP mailers to access the finger daemon on the default "Fidonet" port at
    the IP/domain address listed to get the information on what the Node
    is capable of and what port(s).
    Fine.... show me an example entry that can do this... without breaking current software.

    That's not relevant in this context. There is no software that can
    currently do this. That is the point. This is a proposal. Just like
    the proposals for new Nodelist formats. If you mean a Nodelist
    listing, then;

    ,6308,web-idiot.d2g.com,McKinney_TX,Frank_Vest,1-972-562-8064,33600,CM,XA, V34,V42b,IBN

    The "IBN" flag would be replaced with "IP" (or whatever "standard" is
    decided on). Current POTS software is not affected and IP software can
    adapt... some IP software is already adapted except for the use of the
    "IP" (or whatever) flag.

    To allow the "system name" and "sysop name" fields to be kept as some
    desire;

    ,6308,Collin_County_Station,web-idiot.d2g.com,Frank_Vest,1-972-562-8064, 33600,CM,XA,V34,V42b,IP

    If "push comes to shove":

    ,6308,Collin_County_Station,McKinney_Tx,Frank_Vest,1-972-562-8064, 33600,CM,XA,V34,V42b,IP:web-idiot.d2g.com

    To go one step further... It has been pointed out that many IP mailers don't rely on the Fidonet Nodelist anyway.
    Don't they extract the IP info from the NL to create their proprietary dialing list? If not, who/what tells them?

    Some do, and some don't. Those that don't must be given the type of
    protocol to use by configuration of the Sysop.

    To anyone that wants to chop this reply up and argue each paragraph,
    <putting away jigsaw>
    I did read your entire message before replying, as I usually do. :)
    I'll leave the technical arguments to the techies, and try to learn
    as I read. I don't perport to know a whole lot about the Inet end
    of this debate... only that what we have isn't working, and will get
    worse as time and technology progress.

    I'll agree in part with this. The main problem, I think, is the lack
    of standards. That, I believe, is what got Fidonet into these problems
    to begin with.


    FWIW, I don't think you and I are that far apart on this thing. I hope
    that with time, we will get closer.


    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)
  • From Peter Knapper@3:772/1.10 to Frank Vest on Sunday, December 15, 2002 08:51:12
    Hi Frank,

    If you don't list your IP or domain, you don't fly the IP flag.
    You are of course, then saying there is no other possible way to find
    out how to contact that node, which of course is not correct....;-)

    Not at all. Each Node can set up contacts with each other without the
    use of any Nodelist. Even POTS Nodes can do this. :)

    Ok, I think I can see where you are heading. Let me re-phrase my statement slightly. By saying a sysop can't list an IP FLAG if he does not list the his domain name in the Nodelist, you are placing a limitation on the PUBLIC method of telling people about your system that can work perfectly well.

    A PVT listing tells you its PVT, but it does not list its Phone number in the Nodelist and yet you may still be able to contact that node if privately given the number and hours of service.

    I don't see why there is a need to penalise IP operations over PSTN in such a manner.


    As the cost
    droppped, more and more people moved over to that way of working, its really just a natural progression.

    And as a method of listing Fidonet Nodes in the Nodelist becomes used more, it will be moved to as well.

    When Fidonet started, it NEEDED to create the Nodelist, there was no common PHONE directory available to look up. With IP, such a directory already exists (the DNS). If Fidonet ignores that, then you will end up with exactly the problem we now have, a HUGE section of Fidonet nodes in the Soviet union doing their own thing because Fidonet is too slow to work out that the DNS is REALLY what is needed for IP connectivity. Its like trying to force tooth paste back into the tube........;-)


    Telepathy is ok forall I care... as long as it works. :-)
    I would need to see DIRECT proof that it works first........;-)

    You and me both. (I'm sending you my connection info via telepathy
    right now. Did you receive it??) :-))

    First prove to me that you sent it, before I confirm if I did receive it (or not).........;-))


    One Nodelist with a flag that tells the IP mailer that this is an IP capable Node with a "phone number" of <some.domain> while the pots
    mailer will look for a phone number in the "phone"
    field and use it if configured to do so seems better to me.
    Its this type of mangling that concerns me....;-(

    How so?

    Well it depends on how you read what you said above. If the DATA for <some.domain> goes INTO the nodelist, just where are you going to put it without breaking existing functionality of the Nodelist? Change the System name
    or Location fields, and you difuse the functionality of those fields for all nodes (not just PSTN). Current standards prohibit using a FLAG for that info, so I don't see how one can keep that info in the Nodelist without breaking SOMETHING at least.

    However, if you NOT suggesting to put <some.domain> into the Nodelist, then the
    MOST practical place left is the DNS, which is fine with me.

    I just thought of another possibilty. Fidonet constructs a server that provides
    ALL that info from one single point (an online Nodelist???), allowing Fidonet to retain "control" over its own destiny. Except that means Fidonet re-invents the wheel by re-creating what already exists, but that may just keep some people happy........;-)


    All that is being done is adding a flag to tell the IP mailer
    to look in the DNS record for <IP or domain> or poll a finger daemon
    or some such "standard" Internet listing to get the connection
    information (IE: protocol-port).

    However we don't really need a Finger Daemon, the IBN flag in the Nodelist is all thats needed to tell people to find BinkP by looking up the DNS for that node.

    Now IF its also necessary to advise people that a different PORT is to be used,
    then we have a couple of options, list the PORT in the FLAGS field, or use SRV type DNS records for this purpose. Personally, I prefer to use the DNS for this
    (although I doubt that any Fidonet S/W currently exists that can use SRV records), because its related more to DNS than Nodelist type data.

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Gordon Lewicky@1:153/307 to Frank Vest on Saturday, December 14, 2002 21:32:06
    Quoting Frank Vest to Gordon Lewicky
    Subj. linked, dated 14-Dec-2002 10:35

    Hi ya Frank,

    I understand your point. Would the "location" field be better? Or is where you live as important to you as your name and your system name?

    Well, if we're gonna throw out the geography rule, then to me at
    least, location is important since we can no longer depend on
    zone, region, net! And I sure can't figure out where
    bbs.micronet.com is! :)

    Actually, I'm getting somewhat annoyed at this trend to
    impersonality in this supposed network of computer enthusiasts.
    If I want impersonality, I'll go on the net.

    I happen to enjoy knowing who the sysop is, what their bbs name is,
    and where they park their butt! :)

    Using a flag to indicate the IP or domain address is fine too. As long
    as it is /one/ flag instead of one for every IP protocol.

    I may be wrong, but basically there are only 2 different connect
    addresses, domain name or ip, and email addy. Surely we can
    accomodate these 2 somewhere in the line without mucking around
    with sticking them where they shouldn't be.

    Seems to me that the coupling the addy with the applicable inet
    connect flag works or we develop new fields or files for inet
    addressing and leave the connect flags denoting non-standard
    ports.

    But this kludging addys into various former fields is
    exacly that, kludging.

    Cheers...
    Gordon Lewicky (Pdk)

    Sysop - Milky Way 1:153/307 NC 153
    AdventureNet 33:500/150
    email glewicky@telus.net

    --- EzyBlueWave/2 V2.00 00F90260
    * Origin: Milky Way, Langley, BC [604] 532-4367 (1:153/307)
  • From Bob Short@1:105/38 to Frank Vest on Saturday, December 14, 2002 19:42:27
    On 14 Dec 02 13:30:46, Frank Vest said the following to Bob Short:

    Now, using that and your statement, along with the arguments of others
    that the Nodelist can not show binkp, telnet and other connection
    Correct... in it's current format.

    Not relevant in the context of the rest of the sentence.

    information or emerging technologies, I put it forth that the Nodelist could not and did not work properly with POTS to begin with.

    Again... currently... and quite relevant. AAMOF, we find ourselves
    in a worse position than back then. Up until now, there was room to
    add provisions for additional modem protocols (which were the only
    type of changes). We are now at a crossroad, where the NL can no
    longer be kludged to accomodate all the desired info, and still fall
    within the limitations of SW that reads/processes it.

    All known analog modem connection methods can be so indicated in the NL.

    Yes and No. The phone number is listed and the type (name flag of the) mailer. XA for Frontdoor and so forth. Nothing about connection
    methods as far as protocols are concerned.

    no indication that my POTS mailer can do emsi, zedzap or other
    protocols.

    There is no NEED for session negotiation info for POTS, nor should
    there be for IP. It is (and should) be built into the mailers.

    <hearing echo>

    No need for binkp to be listed either. That protocol can be listed in
    the "mailer name" as above for POTS mailers. In reality, I don't know
    why the mailer flags (XA, XX and such) need to be there anyway. I'm
    sure there is a good reason, but using this same good reason, the IP
    flag that is proposed could be made into a "mailer" flag.

    That's a possibility. I think the mailer-specific flag was because
    not all mailers had all session capacities, and was a means to help
    newer mailers connect easier, and still maintain backward compatibility.

    Someone will correct me if I'm wr...wr...wro... well, you know. ;-)

    Protocols are not shown in the Nodelist, and
    for good reason. Imagine if there had to be a flag for emsi, zedzap
    and all the other POTS protocols. Taking this further, consider POTS

    I don't undersatnd why you leep bringing session negotiation methods
    up... we are beyond that for POTS, and for IP, able to address with
    either built in mailer query, or listing fields in an expanded NL.
    (remember... whatever direction we take, there will be room for new information, so long as we look forward).

    Again, this session information is automatically negotiated between the two mailers (not users, btw). Why would one need to differentiate this in the NL? If a particular mailer cannot negotiate a connection, it's not writte within FTS specs.

    Beg to differ. The only protocol required for POTS by Fidonet is FTS-1 (Xmodem, I believe). If my mailer only does Xmodem, I'm still within requirements.

    Now you're complicating things further by bring in another variety
    of fruit... transfer protocols. Focus on the areas that need to be
    addressed.

    but, if successful, this would remove the need for protocol flags in
    the Nodelist for IP Nodes (IE: IBN, IFT and such). This, in turn would bring the Nodelist back to what it should be. A comma delimited file
    for Fidonet mailers to determining "how" to contact other Fidonet
    mailers instead of what "protocols" to use to make contact.

    If the standards favor DNS, yes. I don't think that's going to
    fly as the only method of addressing. My money's on ESLNL format,
    or (Gawd<tm> forbid) XML.

    Even in the IP mailers, there is no indication that the telnet mailer
    can do emsi, zedzap or other protocols... but some can. :-)
    Again, the abaility to determine that should be built into the mailers. If it isn't, it's not compliant, and shouldn't be used.

    Then BinkD, Irex and several other mailers are not compliant. I can
    not connect to BinkD or Irex and make a negotiated connection. I have
    to tell them that the system I'm calling does binkp, ftp or whatever protocol. It's not negotiated.

    I don't believe standards have been written for IP session connections.
    I'd have to read the FTS docs to know for sure. Have minimum connect requirements been set by the FTSC?

    Fine.... show me an example entry that can do this... without breaking current software.

    That's not relevant in this context. There is no software that can...

    I think it is, since we're debating on whether the SLNF can continue
    to be used. You have some interesting examples, but none seem to go
    futher than (most of) todays technology.

    FWIW, I don't think you and I are that far apart on this thing. I hope
    that with time, we will get closer.

    Where you and I meet will mean little, since we won't be making the
    decisions. I just hope that our voices are heard and taken for face
    value. :)

    Bob

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From Frank Vest@1:124/6308.1 to Peter Knapper on Saturday, December 14, 2002 23:59:29
    On (15 Dec 02) Peter Knapper wrote to Frank Vest...

    Hello Peter,

    If you don't list your IP or domain, you don't fly the IP flag.
    You are of course, then saying there is no other possible way to find
    out how to contact that node, which of course is not correct....;-)

    Not at all. Each Node can set up contacts with each other without the
    use of any Nodelist. Even POTS Nodes can do this. :)

    Ok, I think I can see where you are heading. Let me re-phrase my
    statement slightly. By saying a sysop can't list an IP FLAG if he does
    not list the his domain name in the Nodelist, you are placing a
    limitation on the PUBLIC method of telling people about your system
    that can work perfectly well.

    A PVT listing tells you its PVT, but it does not list its Phone number
    in the Nodelist and yet you may still be able to contact that node if privately given the number and hours of service.

    I don't see why there is a need to penalise IP operations over PSTN in such a manner.

    No penalty involved there. Why would one fly a PVT flag in the
    Nodelist and then list a phone number? Same for IP Nodes. Why fly an
    IP flag and not list your IP/domain?

    I think we're on the same wave here. We just don't know it. :-))

    droppped, more and more people moved over to that way of working, its really just a natural progression.
    And as a method of listing Fidonet Nodes in the Nodelist becomes used more, it will be moved to as well.

    When Fidonet started, it NEEDED to create the Nodelist, there was no common PHONE directory available to look up. With IP, such a directory already exists (the DNS). If Fidonet ignores that, then you will end

    Without listing the IP/domain in the Nodelist, there is little way to
    use the DNS except for a default domain like fidonet.net or something
    like that.

    Telepathy is ok forall I care... as long as it works. :-)
    I would need to see DIRECT proof that it works first........;-)
    You and me both. (I'm sending you my connection info via telepathy
    right now. Did you receive it??) :-))
    First prove to me that you sent it, before I confirm if I did receive
    it (or not).........;-))

    I'm concentrating, dag nab it! <EG>

    One Nodelist with a flag that tells the IP mailer that this is an IP capable Node with a "phone number" of <some.domain> while the pots
    mailer will look for a phone number in the "phone"
    field and use it if configured to do so seems better to me.
    Its this type of mangling that concerns me....;-(
    How so?

    Well it depends on how you read what you said above. If the DATA for <some.domain> goes INTO the nodelist, just where are you going to put
    it without breaking existing functionality of the Nodelist? Change the System name or Location fields, and you difuse the functionality of
    those fields for all nodes (not just PSTN). Current standards prohibit using a FLAG for that info, so I don't see how one can keep that info
    in the Nodelist without breaking SOMETHING at least.

    Create a new standard.

    However, if you NOT suggesting to put <some.domain> into the Nodelist, then the MOST practical place left is the DNS, which is fine with me.

    And use some default domain for Fidonet?

    I just thought of another possibilty. Fidonet constructs a server that provides ALL that info from one single point (an online Nodelist???), allowing Fidonet to retain "control" over its own destiny. Except that means Fidonet re-invents the wheel by re-creating what already exists,
    but that may just keep some people happy........;-)

    To do this would require that Fidonet become a "legal" entity. I'm not
    sure how that would fly. :/

    All that is being done is adding a flag to tell the IP mailer
    to look in the DNS record for <IP or domain> or poll a finger daemon
    or some such "standard" Internet listing to get the connection
    information (IE: protocol-port).
    However we don't really need a Finger Daemon, the IBN flag in the
    Nodelist is all thats needed to tell people to find BinkP by looking
    up the DNS for that node.

    And for those that use telnet mailers? or FTP? What about future
    protocols and mailers? Do we add flags to no end for them?

    Now IF its also necessary to advise people that a different PORT is to
    be used, then we have a couple of options, list the PORT in the FLAGS field, or use SRV type DNS records for this purpose. Personally, I
    prefer to use the DNS for this (although I doubt that any Fidonet S/W currently exists that can use SRV records), because its related more
    to DNS than Nodelist type data.

    You got me on the technical end there. I'm not a tech person.


    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)
  • From Frank Vest@1:124/6308.1 to Gordon Lewicky on Sunday, December 15, 2002 00:33:53
    On (14 Dec 02) Gordon Lewicky wrote to Frank Vest...

    Hello Gordon,

    I understand your point. Would the "location" field be better? Or is where you live as important to you as your name and your system name?
    Well, if we're gonna throw out the geography rule, then to me at
    least, location is important since we can no longer depend on
    zone, region, net! And I sure can't figure out where
    bbs.micronet.com is! :)
    Actually, I'm getting somewhat annoyed at this trend to
    impersonality in this supposed network of computer enthusiasts.
    If I want impersonality, I'll go on the net.
    I happen to enjoy knowing who the sysop is, what their bbs name is,
    and where they park their butt! :)

    Ok. I'll agree with that as well. I don't like it either.

    Using a flag to indicate the IP or domain address is fine too. As long
    as it is /one/ flag instead of one for every IP protocol.
    I may be wrong, but basically there are only 2 different connect addresses, domain name or ip, and email addy. Surely we can
    accomodate these 2 somewhere in the line without mucking around
    with sticking them where they shouldn't be.
    Seems to me that the coupling the addy with the applicable inet
    connect flag works or we develop new fields or files for inet
    addressing and leave the connect flags denoting non-standard
    ports.
    But this kludging addys into various former fields is
    exacly that, kludging.

    With one flag to denote IP capabilities and the IP/domain to that
    would work for me. It's better than a flag for each IP protocol.


    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)
  • From Frank Vest@1:124/6308.1 to Bob Short on Sunday, December 15, 2002 00:37:17
    On (14 Dec 02) Bob Short wrote to Frank Vest...

    Hello Bob,

    Now, using that and your statement, along with the arguments of others
    that the Nodelist can not show binkp, telnet and other connection
    Correct... in it's current format.

    Not relevant in the context of the rest of the sentence.

    information or emerging technologies, I put it forth that the Nodelist could not and did not work properly with POTS to begin with.

    Again... currently... and quite relevant. AAMOF, we find ourselves
    in a worse position than back then. Up until now, there was room to
    add provisions for additional modem protocols (which were the only
    type of changes). We are now at a crossroad, where the NL can no
    longer be kludged to accomodate all the desired info, and still fall within the limitations of SW that reads/processes it.

    That is a limit of the software, not the Nodelist format.

    <hearing echo>

    No need for binkp to be listed either. That protocol can be listed in
    the "mailer name" as above for POTS mailers. In reality, I don't know
    why the mailer flags (XA, XX and such) need to be there anyway. I'm
    sure there is a good reason, but using this same good reason, the IP
    flag that is proposed could be made into a "mailer" flag.

    That's a possibility. I think the mailer-specific flag was because
    not all mailers had all session capacities, and was a means to help
    newer mailers connect easier, and still maintain backward
    compatibility.

    Someone will correct me if I'm wr...wr...wro... well, you know. ;-)

    I don't know for sure either and I'm figuring that we will both be
    corrected. :-)

    Protocols are not shown in the Nodelist, and
    for good reason. Imagine if there had to be a flag for emsi, zedzap
    and all the other POTS protocols. Taking this further, consider POTS

    I don't undersatnd why you leep bringing session negotiation methods

    Because protocols are being listed in the current Fidonet Nodelist.
    They shouldn't be listed there.

    Beg to differ. The only protocol required for POTS by Fidonet is FTS-1 (Xmodem, I believe). If my mailer only does Xmodem, I'm still within requirements.

    Now you're complicating things further by bring in another variety
    of fruit... transfer protocols. Focus on the areas that need to be addressed.

    This is an area that needs to be addressed. Protocols are being listed
    in the current Fidonet Nodelist. Binkp is /not/ a mailer. Binkp is a
    transfer protocol. BinkD is a mailer. There is a difference.

    but, if successful, this would remove the need for protocol flags in
    the Nodelist for IP Nodes (IE: IBN, IFT and such). This, in turn would bring the Nodelist back to what it should be. A comma delimited file
    for Fidonet mailers to determining "how" to contact other Fidonet
    mailers instead of what "protocols" to use to make contact.

    If the standards favor DNS, yes. I don't think that's going to
    fly as the only method of addressing. My money's on ESLNL format,
    or (Gawd<tm> forbid) XML.

    Well... at least we agree on XML. ;-) Not that I totally disagree on
    DNS and/or ESLNL either.

    Again, the abaility to determine that should be built into the mailers. If it isn't, it's not compliant, and shouldn't be used.
    Then BinkD, Irex and several other mailers are not compliant. I can
    not connect to BinkD or Irex and make a negotiated connection. I have
    to tell them that the system I'm calling does binkp, ftp or whatever protocol. It's not negotiated.

    I don't believe standards have been written for IP session
    connections. I'd have to read the FTS docs to know for sure. Have
    minimum connect requirements been set by the FTSC?

    I don't think so. That is.. er.. was the point of my proposal/idea/thought/whatever you call it.

    Fine.... show me an example entry that can do this... without breaking current software.

    That's not relevant in this context. There is no software that can...

    I think it is, since we're debating on whether the SLNF can continue
    to be used. You have some interesting examples, but none seem to go futher than (most of) todays technology.

    The examples give the IP mailer the knowledge that the Node is IP
    capable and where (domain/IP address) to go on the Internet for a
    connect. What is left to do is figure out how to determine if the
    domain/Ip address is for binkp or other protocol.

    FWIW, I don't think you and I are that far apart on this thing. I hope
    that with time, we will get closer.
    Where you and I meet will mean little, since we won't be making the decisions. I just hope that our voices are heard and taken for face value. :)

    Agreed.

    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)
  • From Peter Knapper@3:772/1.10 to Frank Vest on Sunday, December 15, 2002 22:14:06
    Hi Frank,

    No penalty involved there. Why would one fly a PVT flag in the
    Nodelist and then list a phone number?

    I have no idea why someone might do that, however its still possible to contact
    the end node and request a phone number for direct PRIVATE communications. Remember this paragraph as REF #1 for below....

    Same for IP Nodes. Why fly an IP flag and not list your IP/domain?

    As I alluded in my previous mail, thats one place where the PSTN and the Internet differ. When Fidonet started using the PSTN there was no common index (phone book) that could be used, so the Nodelist was born to contain that detail. However the Internet does already have such an index (the DNS), so why not use it? Why does Fidonet have to re-invent the wheel?


    When Fidonet started, it NEEDED to create the Nodelist, there was no common PHONE directory available to look up. With IP, such a directory already exists (the DNS). If Fidonet ignores that, then you will end

    Without listing the IP/domain in the Nodelist, there is little way to
    use the DNS except for a default domain like fidonet.net or something
    like that.

    Well for all the times I have used fidonet.net to reach an end IP node, its worked fine for me. If the node is not listed, the mail is Routed.

    I can only see Fidonet requiring everyone to use a Nodelist entry for DNS info,
    as a truely backward step, and as is currently done by Zones 2 & 7 (yes 7!) the
    "rest" of Fidonet will continue doing it THEIR way because Fidonet does not want to work they way THEY want to work. Now is Fidonet here FOR its Sysops, or
    are the Sysops here FOR Fidonet?

    As a guide, a quick analysis of the fidonet.net Domain shows to me that at least 150+ defined NETWORKS of IP nodes exist in the Zone 2 and Zone 7 sections
    of fidonet.net, while a TOTAL of round 50-100 NODES exist within the rest of Fidonet combined. Are we going to totally ignore the way a vast majority of Fidonet IP users appear to wish to work? Surely this should tell us something?

    I suspect the prime reason the English speaking Zones have not been aware of the growth of fidonet.net usage is simply because of the language differences, we (the English speaking Zones) really are ignorant of how non-English speaking
    Zones operate.


    Current standards prohibit using a FLAG for that info, so I don't
    see how one can keep that info in the Nodelist without breaking
    SOMETHING at least.

    Create a new standard.

    A new standard what, Nodelist? You really DO like taking on big tasks....;-)

    However, if you are NOT suggesting to put <some.domain> into the Nodelist, then the MOST practical place left is the DNS, which is PK>
    fine with me.

    And use some default domain for Fidonet?

    That really does seem to be the most obvious workable solution to me. It requires ZERO additions to the existing Nodelist, perhaps just some tidy up and
    agreement on what FLAGS should be used, and is very easily implemented (from a technical perspective). At least it would not split fidonet in half.


    Except that means Fidonet re-invents the wheel by re-creating
    what already exists, but that may just keep some people
    happy........;-)

    To do this would require that Fidonet become a "legal" entity. I'm not sure how that would fly. :/

    Yes, I said that a bit "tongue-in-cheek"....;-)


    However we don't really need a Finger Daemon, the IBN flag in the
    Nodelist is all thats needed to tell people to find BinkP by looking
    up the DNS for that node.

    And for those that use telnet mailers? or FTP? What about future
    protocols and mailers? Do we add flags to no end for them?

    No, Fidonet needs to settle on an IP transmission standard fairly quickly (probably based on the existing BinkP protocol), similar to the PSTN standard. We currently use several flags to help the PSTN side of things (V24,V32,V42b, etc), a few similar ones for IP should not be too onerous. While FTP is excellent for moving files around the IP world, it has a few disadvantages in other areas that leave it less than desirable for ad-hoc connectivity (IMHO).

    Telnet is another strange one, it was designed for Human interactive use, so it
    actually places a quite high demand on the network because it usually attempts to send data character by character (as per keyboard entry) rather than sending
    it a block at a time. Some Telnet implementations allow a mode that does a form
    of "demand buffering" that helps in this regard, but as this is only optional, not all implementations allow for it.

    Thats actually one of the nice but dangerous things about the Internet, so much
    of it is interoperable with other components, but can leave you wanting in other (unexpeced) areas....;-)

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Gordon Lewicky@1:153/307 to Frank Vest on Sunday, December 15, 2002 09:21:44
    Quoting Frank Vest to Gordon Lewicky
    Subj. linked, dated 15-Dec-2002 00:33

    Hi Frank,

    With one flag to denote IP capabilities and the IP/domain to that
    would work for me. It's better than a flag for each IP protocol.

    I dunno, but reveiwing all the "I" flags, they all seem
    reasonable. Each is a distinct connectivity method, no different
    then all the modem flags.

    I can definately see any one system having any 1 or 2 of these
    methods, and would assume that somebody might want to accomodate
    all of them, and wish that fact to be known.

    Flying them all only leads currently to problems with line length
    restrictions, but that is easily fixed and is being worked on as
    we speak.

    The real problem is what do we do with the inet connect addy.
    Where do we place it, should it be in a field of it's own, and
    maintaining a cross-over for legacy by allowing the kludges into
    system name or phone num fields.

    And along with that, let's get a fixed definition of PVT. And I
    see nothing wrong with defining it to mean a non directly
    contactable system which must be routed to, and if direct contact
    is needed then arrangements must be made with that node for the
    means. And that is all it should stand for, IMO! :)

    Cheers...
    Gordon Lewicky (Pdk)

    Sysop - Milky Way 1:153/307 NC 153
    AdventureNet 33:500/150
    email glewicky@telus.net

    --- EzyBlueWave/2 V2.00 00F90260
    * Origin: Milky Way, Langley, BC [604] 532-4367 (1:153/307)
  • From Jan Vermeulen@2:280/100 to Bill Birrell on Sunday, December 15, 2002 00:00:00
    Quoting Bill Birrell on Fri 13 Dec 2002 22:33 to Frank Vest:

    Lotsa lurkers.

    What kept you so long, Bill?

    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From Frank Vest@1:124/6308.1 to Peter Knapper on Sunday, December 15, 2002 18:08:18
    On (15 Dec 02) Peter Knapper wrote to Frank Vest...

    Hello Peter,

    Same for IP Nodes. Why fly an IP flag and not list your IP/domain?
    As I alluded in my previous mail, thats one place where the PSTN and
    the Internet differ. When Fidonet started using the PSTN there was no common index (phone book) that could be used, so the Nodelist was born
    to contain that detail. However the Internet does already have such an index (the DNS), so why not use it? Why does Fidonet have to re-invent
    the wheel?

    No reason to re-invent the wheel. The wheel (Nodelist) is fine. The
    wheel (DNS) is fine. The other wheels are fine too. The problem is
    that there are too many wheels? How the heck do we steer this thing?!?
    :-)

    When Fidonet started, it NEEDED to create the Nodelist, there was no common PHONE directory available to look up. With IP, such a directory already exists (the DNS). If Fidonet ignores that, then you will end

    Fidonet still needs the Nodelist. IMHO, it always will. When Fidonet
    doesn't need its own Nodelist, Fidonet will not be Fidonet.

    Without listing the IP/domain in the Nodelist, there is little way to
    use the DNS except for a default domain like fidonet.net or something
    like that.
    Well for all the times I have used fidonet.net to reach an end IP
    node, its worked fine for me. If the node is not listed, the mail is Routed.

    There's the key. Routed. If the Node is not listed in the Nodelist or
    the DNS, the message is routed. If the default DNS is fidonet.net,
    then all Nodes that wish to be contactable would need to be listed in
    the fidonet.net DNS?

    I can only see Fidonet requiring everyone to use a Nodelist entry for
    DNS info, as a truely backward step, and as is currently done by Zones
    2 & 7 (yes 7!) the "rest" of Fidonet will continue doing it THEIR way because Fidonet does not want to work they way THEY want to work. Now
    is Fidonet here FOR its Sysops, or are the Sysops here FOR Fidonet?

    Ok. The majority rules... no matter what?

    As a guide, a quick analysis of the fidonet.net Domain shows to me
    that at least 150+ defined NETWORKS of IP nodes exist in the Zone 2
    and Zone 7 sections of fidonet.net, while a TOTAL of round 50-100
    NODES exist within the rest of Fidonet combined. Are we going to
    totally ignore the way a vast majority of Fidonet IP users appear to
    wish to work? Surely this should tell us something?

    How many NODES of the 9000+ in Fidonet use fidonet.net?

    I suspect the prime reason the English speaking Zones have not been
    aware of the growth of fidonet.net usage is simply because of the
    language differences, we (the English speaking Zones) really are
    ignorant of how non-English speaking Zones operate.

    Many Zones don't know how other Zones operate.

    Current standards prohibit using a FLAG for that info, so I don't
    see how one can keep that info in the Nodelist without breaking
    SOMETHING at least.
    Create a new standard.
    A new standard what, Nodelist? You really DO like taking on big tasks....;-)

    I'm gonna start telepathy again if you don't behave. :->

    A new standard flag.

    However, if you are NOT suggesting to put <some.domain> into the
    Nodelist, then the MOST practical place left is the DNS, which is
    fine with me.

    DNS is fine as a fallback default. I just think that there needs to be
    some indication in the Nodelist that the Node is IP capable. For POTs
    or IP, Fidonet must have a Nodelist and entries for the Nodes in the
    Nodelist telling where to "call" to contact that Node. Until Fidonet
    starts using nothing but IP addresses for access, Fidonet will need
    the Nodelist and entries to indicate the Nodes in Fidonet with where
    to "call" to transfer mail. I hope we never get to the point of not
    needing a Nodelist.

    And for those that use telnet mailers? or FTP? What about future
    protocols and mailers? Do we add flags to no end for them?

    No, Fidonet needs to settle on an IP transmission standard fairly
    quickly (probably based on the existing BinkP protocol), similar to

    How? There are too many already. binkp, ftp, telnet. Of which, telnet
    seems to handle the old POTS protocols.

    the PSTN standard. We currently use several flags to help the PSTN
    side of things (V24,V32,V42b, etc), a few similar ones for IP should

    The flags you mention are not protocol flags. They are connection
    ability flags. None of the flags you mention tell what protocols can
    be used by the Node. Flags for DSL, cable modem, dial-up isp and such
    would fit better in your above statement.

    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)
  • From Frank Vest@1:124/6308.1 to Gordon Lewicky on Sunday, December 15, 2002 19:48:39
    On (15 Dec 02) Gordon Lewicky wrote to Frank Vest...

    Hello Gordon,

    With one flag to denote IP capabilities and the IP/domain to that
    would work for me. It's better than a flag for each IP protocol.
    I dunno, but reveiwing all the "I" flags, they all seem
    reasonable. Each is a distinct connectivity method, no different
    then all the modem flags.

    One picky technical difference. :) Binkp and the other IP flags are
    protocol flags, not connectivity flags in the respect that the Fidonet
    Nodelist expects.

    Flying them all only leads currently to problems with line length restrictions, but that is easily fixed and is being worked on as
    we speak.

    Agreed... to a point. Not all should be needed.

    The real problem is what do we do with the inet connect addy.
    Where do we place it, should it be in a field of it's own, and
    maintaining a cross-over for legacy by allowing the kludges into
    system name or phone num fields.

    That seems to be the problem... and the base for some of the ideas
    here... both pro and con.

    And along with that, let's get a fixed definition of PVT. And I
    see nothing wrong with defining it to mean a non directly
    contactable system which must be routed to, and if direct contact
    is needed then arrangements must be made with that node for the
    means. And that is all it should stand for, IMO! :)

    That's as good an opinion as any other. Thanks for sharing it with us.
    :)

    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)
  • From Frank Vest@1:124/6308.1 to Bob Short on Sunday, December 15, 2002 20:06:40
    On (15 Dec 02) Bob Short wrote to Frank Vest...

    Hello Bob,


    That is a limit of the software, not the Nodelist format.
    That's the whole point, Frank. But because the software now in use
    is limited, it make the file they read limited. We need to make it de-limited, period. ;-)

    That's part of my point as well. Many of the POTS mailers are no
    longer under development. Many of the IP mailers are still
    under development. It seems better to have the IP mailers make some
    changes than to try to get POTS mailers that are "dead" to be
    upgraded.

    I don't undersatnd why you keep bringing session negotiation methods

    Because protocols are being listed in the current Fidonet Nodelist.
    They shouldn't be listed there.**

    What I'm tring to point out is the differences between protocol types,
    and their relevance. Until such time that all mailers are able to auto-detect a transport protocol, some indicator will be needed as
    a stop-gap measure. However, in the proper format, one can have as
    many as one wants in the NL without taking up too much room.

    And it would be just as easy to have the IP mailers look in a DNS
    entry or poll a finger daemon or some other IP technology to get the
    protocol information.

    Well... at least we agree on XML. ;-) Not that I totally disagree on
    DNS and/or ESLNL either.

    You will eventually "see the light", meaning the need for change,
    since that need goes beyond our current situation(s). :)

    I see more light than some. :-)


    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)
  • From mark lewis@1:3634/12 to Frank Vest on Monday, December 16, 2002 00:04:12
    Let me go through this a little better and see what gets
    stirred up.
    you got it! <<GG>>

    Oh gawd! You're here too?? <GD&R> :)

    hehehe...

    Binkp, telnet and ftp are protocols for IP. Just as zedzap,
    emsi, zmodem and others are protocols for POTS.
    i use zedzap, emsi, zmodem, and others on IP with relatively no
    problems...

    With telnet?? i wager?

    yup!

    Of course, the argument is that with POTS, the protocols
    are negotiated upon connection. There is a thread in the
    FTSC_PUBLIC echo that is attempting to work out just such
    a thing for IP Nodes.

    it can be done in IP mailers just exactly like it is done in POTS
    mailers... trouble is, it seems, that coders don't want to or haven't
    figured out how ;-(

    Yup. Always go with the new, no matter what, just because. :(

    that and not having to figure out how to make the others or get them all to work together... i remember the dance that EMSI caused when it was originally introduced...

    Was my description/proposal/argument accurate and well
    presented?

    yes, pretty much...

    Did I make sense?

    yes...

    What is your opinion on the idea?

    hummm... need to go back and reread it again... that was several days ago and i've been "occupied" since then <<wink>>

    You can answer in Netmail if desired.

    'k...

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to Peter Knapper on Monday, December 16, 2002 00:06:28
    NR mode was set by my recent addition of the defnode
    setting in binkd...

    Interesting... The docs I read said that NR mode was better
    enabled for "ad-hoc" connections, so it was set to NR for
    defnode anyway.

    that's how i'm set here, too...

    I have removed it now, to see how it goes next time.

    'k...

    Oh, the connection was found using * for the DNS
    name.......;-)

    yes, that's a recent addition... hasn't been in place but only a week or two <<GG>>

    one thing that i've discovered that that has led to is
    that i must define all the fidonet addresses of those
    nodes connecting to me... at least, it appears that
    way, so far... two other systems could not connect due
    to their presentation of all fidonet akas instead of
    just the one we use between us... i have to wait on the
    others to connect and see what happens with them...
    several are flying akas in other networks...

    I remember seeing something about problems with AKA's and
    BinkD but I can't remember the detail, because its never
    restricted my operation (as far as I know). I am still using
    the older 0.93h that I have been using for years. I have 0.94
    here so I must upgrade (one day).....;-).

    i think that 0.9.4 is what i'm running, as well...

    )\/(ark


    * Origin: (1:3634/12)
  • From Frank Vest@1:124/6308.1 to mark lewis on Monday, December 16, 2002 01:26:07
    On (16 Dec 02) mark lewis wrote to Frank Vest...

    Hello mark,

    What is your opinion on the idea?

    hummm... need to go back and reread it again... that was several days
    ago and i've been "occupied" since then <<wink>>

    I'll look forward to your thoughts.... umm... you're not going to
    throw a cream pie at me while I'm looking forward, are you? <EG>

    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)
  • From Peter Knapper@3:772/1.10 to Frank Vest on Monday, December 16, 2002 20:24:22
    Hi Frank,

    No reason to re-invent the wheel. The wheel (Nodelist) is fine. The
    wheel (DNS) is fine. The other wheels are fine too. The problem is
    that there are too many wheels? How the heck do we steer this thing?!?:-)

    So you are a unicycle expert then?......;-) My view is that the nodelist (the Captain) steer's the ship, however I also do not see the captain doing all the work, when appropropriate, he uses the right man for the job.


    Fidonet still needs the Nodelist. IMHO, it always will. When Fidonet doesn't need its own Nodelist, Fidonet will not be Fidonet.

    I don't think the NEED for the Nodelist is in dispute, its just what tasks are best left to the Nodelist, as opposed to what tasks are passed elsewhere...


    There's the key. Routed. If the Node is not listed in the Nodelist or
    the DNS, the message is routed.

    Thats not quite how I view it. My scenario runs like this -
    1. If the Node is NOT Nodelisted, then it is bounced back to the sender.
    2. If pre-existing arrangements are in place, then they will be used.
    3. If the Node is Nodelisted, AND uses BinkP (IBN), then I will attempt to deliver direct using BinkP.
    4. If the node is Nodelisted, PSTN and local, then I will either place it on HOLD (by arrangement), attempt to deliver direct, otherwise I Route that traffic.
    5. In all cases if DIRECT connection fails, I will Route the mail.

    This is how its worked for me for many years.


    If the default DNS is fidonet.net, then all Nodes that wish to be contactable would need to be listed in the fidonet.net DNS?

    IP Contactable?... then yes. It is up to the destiniation node to decide if they wish to be listed (and therefore contactable) or not.


    Ok. The majority rules... no matter what?

    No, not majority, and certainly not "no matter what"... Its simply a case of those that have something that works well, will continue to use it until they see good reason to not use it.

    If Fidonet implements something that ends up competing with existing setups, then Fidonet will be the loser, because regardless of "standards", Sysops will continue to use something that works better for them, than the supposed "standard" they are asked to implement, UNLESS there is some clear reason why the "something new" is better...


    Are we going to
    totally ignore the way a vast majority of Fidonet IP users appear to
    wish to work? Surely this should tell us something?

    How many NODES of the 9000+ in Fidonet use fidonet.net?

    No idea sorry, that would need quite a bit more work than what I have done, as I said above, it was only a quick analysis.


    However, if you are NOT suggesting to put <some.domain> into the
    Nodelist, then the MOST practical place left is the DNS, which is
    fine with me.

    DNS is fine as a fallback default. I just think that there needs to be some indication in the Nodelist that the Node is IP capable.

    Agreed...

    For POTs or IP, Fidonet must have a Nodelist and entries for the
    Nodes in the Nodelist telling where to "call" to contact that Node.

    Agreed for PSTN (I prefer calling POTS nodes PSTN nodes because PSTN works for both POTS and ISDN nodes, whereas POTS is not strictly valid for ISDN nodes because they use an enhaced "POTS" type service that is not always compatible with ISDN).

    However for IP nodes, this is part of the problem. The REAL issue seems to be over HOW this could be done without breaking anything. Using the DNS means those issues are almost non-existant (IMHO).


    I hope we never get to the point of not needing a Nodelist.

    I can't see Fidonet existing without something like the Nodelist, either in its
    current form, or something completely different, however yes, I think "the Nodelist" will always (see next paragraph) be part of Fidonet.

    As a small diversion here, if you can see a bit into the future, say when nothing but IP is used for transport within Fidonet, do you think you can see where things might end up? My own thoughts in this area are... interesting... to say the least. I am not sure a lot of people have given it much thought though (some of them might have a heart attack.......;-)).

    Now back to our regular program...

    No, Fidonet needs to settle on an IP transmission standard fairly
    quickly (probably based on the existing BinkP protocol), similar to

    How? There are too many already. binkp, ftp, telnet. Of which, telnet seems to handle the old POTS protocols.

    How? Easy, Fidonet MUST set down an IP standard, the same as it did with the PSTN. All the other "flavours" of IP can fit around that standard, but defining
    an IP standard would actually help Fidonet get things IP going better than they
    are now. Its the variations in IP connectivity that are causing the issues over
    how to document what it being done...


    the PSTN standard. We currently use several flags to help the PSTN
    side of things (V24,V32,V42b, etc), a few similar ones for IP should

    The flags you mention are not protocol flags. They are connection
    ability flags.

    No, the PSTN flags above really are protocol flags, its those protocols that define HOW 2 nodes will be able to use the telephone line between them. Thats why we currently have several IP flags, they match the PSTN protocol flags at the basic connection level. With PSTN, the FLAG's are used down at ISO layer 2 for Dial-up connections. With IP (which is ISO layer 3), the FLAG's define the ISO layer 4 standard for the connection. Its the same functionality, just at different layers of the protocol stack...


    Flags for DSL, cable modem, dial-up isp and such would fit better
    in your above statement.

    Nope, because all those define is the MEDIA that is used by the Node for connection to the Internet. With PSTN the phone line was the begining of the transport layer, however with the Internet, IP fills that same role. Once the IP layer is established, the Media doesn't matter in the slightest.

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Gordon Lewicky@1:153/307 to Frank Vest on Monday, December 16, 2002 07:46:52
    Quoting Frank Vest to Gordon Lewicky
    Subj. linked, dated 15-Dec-2002 19:48

    Hi Frank,

    One picky technical difference. :) Binkp and the other IP flags are protocol flags, not connectivity flags in the respect that the Fidonet Nodelist expects.

    Yes they are, and so are all those V flags for modems. Or in
    otherwords, the handshake. Do we do away with all the V flags
    because they sure as beans are protocols as well! :)

    Now, for PSTN the address is the phone num.
    For internet the address can be in 2 forms.

    So maybe one solution, since the phone num field accepts alpha
    numerics, is to have the first character of the phone field be I for
    inet addressing. This way, there is only one address field, good
    for both POTS and ION

    As to whether this will puke every nodelist accessing processor,
    compiler out there, I don't know. And neither do I know if the
    string length is long enough to accept email addys or domain
    names.

    But if you want to stick with the strict technical definition of a
    protocol flag, and not have attached addys, then this would be the
    only and and most elegent soultion. One common field for the
    address, and then we can just use modem or inet flags.

    This would work great if one was POTS or ION, but not both!

    So that means we need 3 address fields, a phone num, a domain
    name/IP and a email addy, since we should allow for a system which
    has the 3 means of addressing, or are you saying we should only allow
    1 INET method and not 2 or 3 or 4?

    Now, I do know that adding 2 new addressing fields to the line will
    most certainly blow up all the existing software.

    And we don't want to get into the nodelist stuffing argument where
    we decide that we must separate out the 3 types and just have one
    type addressing per node.

    So I see the existing method of either placing the addy in the
    system name field or attaching it to the I flags as being the best
    method so far, since it is already working for just about all
    software. The only thing holding back the ability to have a system
    fly all means, is the line length limitations in the current
    processors, and that is a very easy thing to fix. Much easier then
    farting around with adding new fields and changing location fields
    to addy fields.

    And I certainly see no need or justification for telling any node
    that they can only fly 1 or 2 Inet protocols. If they have the
    means for all methods, then let them, and if each method has a
    different name, port, then that only means increasing the line
    length to fix!

    The real problem is how to distinguish the difference between a
    POTS and ION, without having to force them to use PVT or HOLD!

    But I just can't see how holding the I protocol flags to just being
    them by themselves is going to fix anything. It would only make
    things worse. And for what? Because of a strict technical
    definition? Nah... doesn't make any common sense doing it that way.
    Why fix something that really isn't broken?


    Agreed... to a point. Not all should be needed.

    No they are not normally needed, but who are we to tell someone that
    they can't make themselves available by all means, or tell their
    downlinks that they must use this or that because we resticted
    their uplink to a few methods?

    The real problem is differentiating between POTS ands ION and line
    length, not how we enter inet protocols.

    Just a few of my rambling thoughts. :)

    Cheers...
    Gordon Lewicky (Pdk)

    Sysop - Milky Way 1:153/307 NC 153
    AdventureNet 33:500/150
    email glewicky@telus.net

    --- EzyBlueWave/2 V2.00 00F90260
    * Origin: Milky Way, Langley, BC [604] 532-4367 (1:153/307)
  • From Bob Short@1:105/38 to Frank Vest on Monday, December 16, 2002 10:57:10
    On 15 Dec 02 20:06:40, Frank Vest said the following to Bob Short:

    That's the whole point, Frank. But because the software now in use
    is limited, it make the file they read limited. We need to make it de-limited, period. ;-)

    That's part of my point as well. Many of the POTS mailers are no
    longer under development. Many of the IP mailers are still
    under development. It seems better to have the IP mailers make some
    changes than to try to get POTS mailers that are "dead" to be
    upgraded.

    'Zacly...

    What I'm tring to point out is the differences between protocol types, and their relevance. Until such time that all mailers are able to auto-detect a transport protocol, some indicator will be needed as
    a stop-gap measure. However, in the proper format, one can have as many as one wants in the NL without taking up too much room.

    And it would be just as easy to have the IP mailers look in a DNS
    entry or poll a finger daemon or some other IP technology to get the protocol information.

    No reason any or all of these options can't be made available in the IP
    section of a ESLF nodelist. It's time to start demonstrating some of
    this theory, so people can fully understand the potential.

    I see more light than some. :-)

    :)

    Bob

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From Frank Vest@1:124/6308.1 to Gordon Lewicky on Monday, December 16, 2002 13:05:28
    On (16 Dec 02) Gordon Lewicky wrote to Frank Vest...

    Hello Gordon,

    Just a few of my rambling thoughts. :)

    And I thank you for them. :)

    I think I agree with you. (Wow! That's scary) :-)


    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)
  • From Jasen Betts@3:640/531.42 to Bob Short on Saturday, December 14, 2002 19:26:21
    Hi Bob.

    13-Dec-02 11:10:56, Bob Short wrote to Jasen Betts

    it'll require programmers to think a bit more when reading the
    nodelist and code their software to look-ahead a bit, but that
    shouldn't be a problem for experienced programmers.

    Like those worling with IP software? ;-)

    hopefully. (don't ge me started on crapware)

    open source stuff is easily to deal with, but even closed
    source stuff can be "destruction tested" with artificial scenariaos.

    nets with 10000 nodes, nodelist lines longer than the available memory,
    that sort of stuff :)

    Hmm, has anyone made a lex/yacc parser for SLF nodelists...
    it doesn't produce tidy code, but it does produce bulletproof code.

    personally I don't feel XML is the answer at the moment
    I lean more towards a lightweight structuered list

    one format dreamt up by Frank Vest an I went like this:


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

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

    then there'd be a single field with all the "system flags" - flags that
    apply to a fido system rather thanto the connection requirements,
    (flags like NEC or GUUCP flags would be examples of this)
    instead of commas "," they'd be separated using semicolons. ";"
    that'd 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 field 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 both IP and dialup might look like this:
    (but all on a single line)

    ,1701,Some_BBS_Name,Some_Town,Some,Sysop,sys;tem;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,sys;tem;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,sys;tem;flags,
    IP,IP.or.url.com,CM;MO;LO;IBN;ITN,

    someone with multiple dial-up modems could 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)
    and maybe
    VIA - specify some other node to accept the packets.

    Bye <=-

    *---/


    Bye <=-

    ---
    * Origin: Drive defensively. Buy a tank. (3:640/531.42)
  • From Bill Birrell@2:25/200 to Jan Vermeulen on Monday, December 16, 2002 23:35:02
    Hey Jan,

    What kept you so long, Bill?

    There's not a lot of point in my taking part in a discussion unless I understand it, Jan. :-)

    OTOH, I do understand Fido style nodelists. :-)

    Best Wishes,
    Bill.

    ---
    * Origin: Escan BBS (2:25/200)
  • From Bob Short@1:105/38 to Frank Vest on Sunday, December 15, 2002 11:15:47
    On 15 Dec 02 00:37:17, Frank Vest said the following to Bob Short:

    Again... currently... and quite relevant. AAMOF, we find ourselves
    in a worse position than back then. Up until now, there was room to add provisions for additional modem protocols (which were the only type of changes). We are now at a crossroad, where the NL can no longer be kludged to accomodate all the desired info, and still fall within the limitations of SW that reads/processes it.

    That is a limit of the software, not the Nodelist format.

    That's the whole point, Frank. But because the software now in use
    is limited, it make the file they read limited. We need to make it
    de-limited, period. ;-)

    I don't undersatnd why you keep bringing session negotiation methods

    Because protocols are being listed in the current Fidonet Nodelist.
    They shouldn't be listed there.**

    What I'm tring to point out is the differences between protocol types,
    and their relevance. Until such time that all mailers are able to
    auto-detect a transport protocol, some indicator will be needed as
    a stop-gap measure. However, in the proper format, one can have as
    many as one wants in the NL without taking up too much room.

    Well... at least we agree on XML. ;-) Not that I totally disagree on
    DNS and/or ESLNL either.

    You will eventually "see the light", meaning the need for change, since
    that need goes beyond our current situation(s). :)

    Bob

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From Gordon Lewicky@1:153/307 to Frank Vest on Monday, December 16, 2002 22:56:18
    Quoting Frank Vest to Gordon Lewicky
    Subj. linked, dated 16-Dec-2002 13:05

    Hi ya Frank,

    Just a few of my rambling thoughts. :)

    I think I agree with you. (Wow! That's scary) :-)

    What's really scary is that you read them! ;-)

    Cheers...
    Gordon Lewicky (Pdk)

    Sysop - Milky Way 1:153/307 NC 153
    AdventureNet 33:500/150
    email glewicky@telus.net

    --- EzyBlueWave/2 V2.00 00F90260
    * Origin: Milky Way, Langley, BC [604] 532-4367 (1:153/307)
  • From Bob Short@1:105/38 to Jasen Betts on Tuesday, December 17, 2002 10:30:07
    On 14 Dec 02 19:26:21, Jasen Betts said the following to Bob Short:

    open source stuff is easily to deal with, but even closed
    source stuff can be "destruction tested" with artificial scenariaos.

    But unnecessesary. The fields for POTS entries is fine.

    nets with 10000 nodes, nodelist lines longer than the available memory, that sort of stuff :)

    We only WISH we had that many node in a new. <g>
    The rest is insignificant when using newer SW to read/write the info.

    personally I don't feel XML is the answer at the moment
    I lean more towards a lightweight structuered list

    Restructured, and it may be that an ESLNL would be a bit larger. It
    will require a short enrty for the POTS 1/2, and the expanded enrty
    for the IP section... though it will allow merging of data currently
    spread over several enrties into a single one (multiple connectivity).

    one format dreamt up by Frank Vest an I went like this:

    <snip>

    Except that this concept would require rearranging the POTS listings
    too, thus making people change SW to read it. :( But if that format
    is used in the IP section...

    Bob

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From Jasen Betts@3:640/1042 to Peter Knapper on Tuesday, December 17, 2002 16:19:44
    Hi Peter.

    14-Dec-02 22:45:24, Peter Knapper wrote to Frank Vest

    If you don't list a phone number in the Nodelist, you fly the PVT
    flag. Simple, eh?

    Because there was no other way to do it for PSTN nodes, however
    with IP nodes we have other ways. Why propagate something that is
    no longer valid

    PVT should be used for IONs because, as you said, there's no other way for
    POTS nodes to understand the nodelist entry correctly.

    Bye <=-

    ---
    * Origin: I'm pink, therefore I'm SPAM. (3:640/1042)
  • From Jasen Betts@3:640/1042 to Gordon Lewicky on Tuesday, December 17, 2002 16:25:01
    Hi Gordon.

    14-Dec-02 21:32:06, Gordon Lewicky wrote to Frank Vest


    Quoting Frank Vest to Gordon Lewicky Subj. linked, dated
    14-Dec-2002 10:35

    Hi ya Frank,

    I understand your point. Would the "location" field be better?
    Or is where you live as important to you as your name and your
    system name?

    Well, if we're gonna throw out the geography rule, then to me at
    least, location is important since we can no longer depend on
    zone, region, net! And I sure can't figure out where
    bbs.micronet.com is! :)

    Actually, I'm getting somewhat annoyed at this trend to
    impersonality in this supposed network of computer enthusiasts. If
    I want impersonality, I'll go on the net.

    I happen to enjoy knowing who the sysop is, what their bbs name
    is, and where they park their butt! :)

    Using a flag to indicate the IP or domain address is fine too. As
    long as it is /one/ flag instead of one for every IP protocol.

    I may be wrong, but basically there are only 2 different connect addresses, domain name or ip, and email addy.

    Surely we can accomodate these 2 somewhere in the line without
    mucking around with sticking them where they shouldn't be.

    They can go in the flags.. INA and IEM (or attached to the mailer flags)
    the 157 limit though may meed that there is less room got other fields
    like sysop name, location, and system namee.

    But this kludging addys into various former fields is exacly that, kludging.

    so is attaching data to flags,
    possibly in the future they'll work out a multi-line format so there;s more room, or maybe go to a totally different format.

    Bye <=-

    ---
    * Origin: How to make Kleenex dance? Blow a little boogie in it. (3:640/1042)
  • From Gordon Lewicky@1:153/307 to Jasen Betts on Wednesday, December 18, 2002 18:16:56
    Quoting Jasen Betts to Gordon Lewicky
    Subj. linked, dated 17-Dec-2002 16:25

    Hi Jasen,

    They can go in the flags.. INA and IEM (or attached to the mailer
    flags) the 157 limit though may meed that there is less room got other fields like sysop name, location, and system namee.

    Yup, I know, and I think that is a sensable place to put them.
    Plus it already works, and see no reason why we must hold to the
    absolute definition of a flag, by not attaching an addy to it.

    The only problem it can lead to is line length limitaions or field
    length limitations and in most cases, this is a simple fix in the
    code.

    A hell of a lot easier then adding new fields, or moving addys
    from the bbs name field to the location field.

    As I've said, the real key is how do we differentiate between pots
    and ion without having to force the use of PVT.

    PVT should mean a non-directly contactable node, routable only,
    until such time as one gets direct contact info from the node
    holder. And that is all PVT should mean.

    If we're to fix the nodelist, that is where we should start.

    Cheers...
    Gordon Lewicky (Pdk)

    Sysop - Milky Way 1:153/307 NC 153
    AdventureNet 33:500/150
    email glewicky@telus.net

    --- EzyBlueWave/2 V2.00 00F90260
    * Origin: Milky Way, Langley, BC [604] 532-4367 (1:153/307)
  • From Peter Knapper@3:772/1.10 to Jasen Betts on Thursday, December 19, 2002 21:05:16
    Hi Jasen,

    If you don't list a phone number in the Nodelist, you fly the PVT
    flag. Simple, eh?

    Because there was no other way to do it for PSTN nodes, however
    with IP nodes we have other ways. Why propagate something that is
    no longer valid

    PVT should be used for IONs because, as you said, there's no other way for POTS nodes to understand the nodelist entry correctly.

    I tried that, but there seems to be a school of thought that a non-PSTN node should not be PVT because they are still accessible via IP. Apparently it suggests some sort of stigma to flying PVT...

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Jasen Betts@3:640/1042 to Bob Short on Wednesday, December 18, 2002 22:07:47
    Hi Bob.

    17-Dec-02 10:30:07, Bob Short wrote to Jasen Betts


    On 14 Dec 02 19:26:21, Jasen Betts said the following to Bob
    Short:

    open source stuff is easily to deal with, but even closed source
    stuff can be "destruction tested" with artificial scenariaos.

    But unnecessesary. The fields for POTS entries is fine.

    huh??? I'm talking software, you seem to be discussing file formats?

    nets with 10000 nodes, nodelist lines longer than the available
    memory, that sort of stuff :)

    We only WISH we had that many node in a new. <g>

    2:5020 is pretty big (1423 nodes) and that breaks some software.

    10000 is not IMO radically larger,

    The rest is insignificant when using newer SW to read/write the info.

    nope. it shows that the programmer wasn't following the specification.
    stuff shopuld be tested so it can be fixed before it gets abandoned.

    personally I don't feel XML is the answer at the moment I lean
    more towards a lightweight structuered list

    Restructured, and it may be that an ESLNL would be a bit larger.

    I figure about 5% before compression, mybe a little more once people start listing multiple connections, and using fields like "system name" for their original purpose once again.

    It will require a short enrty for the POTS 1/2, and the expanded
    enrty for the IP section...

    huh? half... there is no pots half. pots is optional as is IP.

    though it will allow merging of data
    currently spread over several enrties into a single one (multiple connectivity).

    yeah, sosmthing that a new nodelist format should provide.

    one format dreamt up by Frank Vest an I went like this:

    Except that this concept would require rearranging the POTS
    listings too, thus making people change SW to read it.

    yes, or run a converter, preferably one tuned to their software type.
    IE ione for current POTS software and a different one for current IP
    software

    But if that format is used in the IP section...

    I'm not shre what youre proposing there...

    is it a segregated nodelist (all posts info then all extended info) or multi-line (lie ESLF)

    if the former it'd be easier to just convert the new format for legacy
    software and use the new format for new software,

    if the latter, you'd still need a converter for existing IP software
    or maybe you'd need redundant data....

    Bye <=-

    ---
    * Origin: Success is a journey, not a destination. (3:640/1042)
  • From Bob Short@1:105/38 to Jasen Betts on Thursday, December 19, 2002 13:36:01
    On 18 Dec 02 22:07:47, Jasen Betts said the following to Bob Short:

    open source stuff is easily to deal with, but even closed source
    stuff can be "destruction tested" with artificial scenariaos.

    But unnecessesary. The fields for POTS entries is fine.

    huh??? I'm talking software, you seem to be discussing file formats?

    One plays upon the other. Software that can't process the data in
    a nodelist that can't be limited to the data that the software can
    process. A vicious circle. Victor Frankel would have a field day.

    We only WISH we had that many nodes in a net. <g>

    2:5020 is pretty big (1423 nodes) and that breaks some software.

    Perhaps the POTS seg editors, but the majority of these are IP nodes. New/updated SW for an IP section of an ESLNL would eliminate that, as
    it would do the processing for IP's and leave the PORS as is.

    10000 is not IMO radically larger,

    If you think we'll ever have that number in a single net, your a bigger
    dreamer than I am. ;-) That's larger than the total number of nodes in
    the entire network. <sigh>

    The rest is insignificant when using newer SW to read/write the info.

    nope. it shows that the programmer wasn't following the specification. stuff shopuld be tested so it can be fixed before it gets abandoned.

    OK.. let me rephrase that: The rest /should/ be redundant. I'll bet
    that once a clear and complete set of standards are arrived at, the
    programmers remaining will be happy to meet the challenge.

    It will require a short enrty for the POTS 1/2, and the expanded
    enrty for the IP section...

    huh? half... there is no pots half. pots is optional as is IP.

    I don't think we're one the same page(s) here. I'm suggesting that
    a new NL format enclude 2 separate section... one for POTS (read and
    used by legacy software), and one for IP (read and used by new or
    updated software).

    An abbreviated entry in the POTS section will tell my POTS mailer
    to route mail to an IP node, while the actual expanded listing in
    the IP section gives all the data needed to connect betewwn IP's.

    yes, or run a converter, preferably one tuned to their software type.
    IE ione for current POTS software and a different one for current IP software

    Steps that need mot be required, if this is done right.

    Bob

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From Jan Vermeulen@2:280/100 to Bill Birrell on Friday, December 20, 2002 02:50:50
    Quoting Bill Birrell on Mon 16 Dec 2002 23:35 to Jan Vermeulen:

    What kept you so long, Bill?

    There's not a lot of point in my taking part in a discussion
    unless I understand it, Jan. :-)

    Never knew you to be so modest, Bill ;-)

    OTOH, I do understand Fido style nodelists. :-)

    That's really you again...


    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From Bill Birrell@2:25/200 to Jan Vermeulen on Sunday, December 22, 2002 00:08:00
    There's not a lot of point in my taking part in a discussion
    unless I understand it, Jan. :-)

    Never knew you to be so modest, Bill ;-)

    It isn't modesty Jan. I really don't understand what's wrong with the FTS nodelist. In its heyday it kept more than a million people in touch with each other. Even now we all depend on it for direct communication via the PSTN.

    OTOH, I do understand Fido style nodelists. :-)

    That's really you again...

    It's just the truth. Anybody who has ever worn a *C hat has had to get to grips with his own segment of the nodelist. The present form is easy, understandable and widely used.

    G'night, Jan.
    Bill.

    ---
    * Origin: Escan BBS (2:25/200)
  • From Jasen Betts@3:640/1042 to Bob Short on Saturday, December 21, 2002 17:05:06
    Hi Bob.

    19-Dec-02 13:36:01, Bob Short wrote to Jasen Betts

    OK.. let me rephrase that: The rest /should/ be redundant. I'll
    bet that once a clear and complete set of standards are arrived
    at, the programmers remaining will be happy to meet the challenge.


    it doesn't work like that... for example try sending a 100K meg netmail some time... too mnay programmers see "unlimited" and then just set the limit wherever they find convenient...

    An abbreviated entry in the POTS section will tell my POTS mailer
    to route mail to an IP node, while the actual expanded listing in
    the IP section gives all the data needed to connect betewwn IP's.

    yes, or run a converter, preferably one tuned to their software
    type. IE ione for current POTS software and a different one for
    current IP software

    Steps that need mot be required, if this is done right.

    what's the right way then?


    Bye <=-

    ---
    * Origin: You think "I'm no fool!" but I am! - Spike Milligan (3:640/1042)
  • From Bob Short@1:105/38 to Jasen Betts on Sunday, December 22, 2002 16:53:44
    On 21 Dec 02 17:05:06, Jasen Betts said the following to Bob Short:

    OK.. let me rephrase that: The rest /should/ be redundant. I'll
    bet that once a clear and complete set of standards are arrived
    at, the programmers remaining will be happy to meet the challenge.

    it doesn't work like that... for example try sending a 100K meg netmail som time... too mnay programmers see "unlimited" and then just set the limit wherever they find convenient...

    That's because those programmers didn't sit down and help set the standards. What I would like to do, is get a clear example(s) of possible application
    of ESFNL formats, and present them to author for input.

    If we can work out a political document amendment, surely we can come up
    with technical solution. ;-)))

    Steps that need mot be required, if this is done right.

    what's the right way then?

    Waiting... PLEASE work!... <grin>

    I'm attempting to get some examples from Mark and Jan (Hi guys!).
    Let's see what they come up with... :)

    Bob

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From Jan Vermeulen@2:280/100 to Bob Short on Monday, December 23, 2002 13:39:40
    Quoting Bob Short on Sun 22 Dec 2002 16:53 to Jasen Betts:

    I'm attempting to get some examples from Mark and Jan (Hi guys!).

    Hi yerself, Bob!

    Let's see what they come up with... :)

    I'm afraid I won't make it for today as I promised; with Christmas so near and my help being needed... oh well, you're understand.

    But that bit of gray matter I have is still working on it ;-)


    -=<[ JV ]>=-


    * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100)
  • From Bob Short@1:105/38 to Jan Vermeulen on Monday, December 23, 2002 12:13:05
    On 23 Dec 02 13:39:40, Jan Vermeulen said the following to Bob Short:

    I'm attempting to get some examples from Mark and Jan (Hi guys!).

    Hi yerself, Bob!

    Not since my last Grateful Dead concert... ;-)

    Let's see what they come up with... :)

    I'm afraid I won't make it for today as I promised; with Christmas so near and my help being needed... oh well, you're understand.

    Sointenly. You know whay kinda patience I have (p4)... <grin>

    But that bit of gray matter I have is still working on it ;-)

    Let see how much is left after the 1st. <vbeg>

    Bob

    --- GEcho 1.00
    * Origin: -= BS BBS =- Portland, OregUn (1:105/38)
  • From mark lewis@1:3634/12 to Jasen Betts on Friday, December 27, 2002 14:32:42
    OK.. let me rephrase that: The rest /should/ be redundant. I'll
    bet that once a clear and complete set of standards are arrived
    at, the programmers remaining will be happy to meet the challenge.


    it doesn't work like that... for example try sending a 100K
    meg netmail some time... too mnay programmers see "unlimited"
    and then just set the limit wherever they find convenient...

    and that takes me to my oft-stated comment about "lazy programers"... too lazy to figure out how to work around the limitations of their chosen language in most cases...

    yes, i'm guilty, too... but i'm getting better <<GG>>

    )\/(ark


    * Origin: (1:3634/12)